CANBed Dual Incorrect data byte contents in dtaGet

Products & Technology Arduino & Seeeduino
#1

Hello all,
I’m working on a CAN gateway that takes traffic in on CAN0, filters down for one particular message ID, modifies 2 data bytes from that message, then retransmits on CAN1 at a different rate and different data format. Works okay so far, except that occasionally the filtered ID matches but the contents in dtaGet array are incorrect. I verified with Peak CAN software that the incoming data bytes are unchanging.
By using additional checks in the MID match I’ve managed to filter out most of the incorrect data bytes, but I’d like to get a proper fix in place.

   if ( ( id == 0x0CF091F3 )  && ( byte6 == 0 ) && ( byte7 == 0) )   //found data with extra data bytes filter applied, eliminates most of the error messages
   //if ( id == 0x0CF091F3 )                //just filter by id

16 bytes of dtaGet contents each time the if(id==) matches:

|48|21|1|128|0|0|0|0|194|45|0|32|255|255|255|255| |
|128|234|1|16|255|15|0|0|194|45|0|32|255|255|255|255| |
|47|21|1|128|0|0|0|0|3|0|0|0|255|255|255|255| |
|128|234|2|16|255|15|0|0|3|0|0|0|255|255|255|255| |
|128|234|1|16|255|15|0|0|3|0|0|0|255|255|255|255| |
|48|21|1|128|0|0|0|0|3|0|0|0|255|255|255|255| |
|128|234|1|16|255|15|0|0|3|0|0|0|255|255|255|255| |
|88|1|76|0|122|4|253|124|3|0|0|0|255|255|255|255| |
|128|234|1|16|255|15|0|0|3|0|0|0|255|255|255|255| |
|125|4|115|22|0|0|0|0|3|0|0|0|255|255|255|255| |
|128|234|1|16|255|15|0|0|3|0|0|0|255|255|255|255| |
|128|234|2|16|255|15|0|0|3|0|0|0|255|255|255|255| |
|128|234|2|16|255|15|0|0|3|0|0|0|255|255|255|255| |
|128|234|1|16|255|15|0|0|3|0|0|0|255|255|255|255||

The lines starting with 128, 234 match the actual traffic seen at the Peak adapter. You can see some of the incorrect messages still get through with the 2 data byte contents checks in place.
Working on testing and documenting over here. Anybody ever notice something like this?
Thanks,
Mark

#2

Hi there,

Just a hip shot here, What about a CRC , generate one and check b4 hand, that way you can "filter: b4 you retransmit. I have seen this implemented on a long line transmission and work.
HTH
GL :slight_smile: PJ :v:

#3

If I understand your suggestion I would need design control over my original transmitting module, which is not the case. Data bytes being correct and associated with an incoming message ID is a pretty basic requirement for a CAN node, currently I can’t trust any data coming in to be correct. I’m relatively lucky for now, since I can use the 2 empty data bytes for an additional band-aid filter, and the receiving module is relatively tolerant of brief incorrect data. Definitely not suitable for 98% of the CAN tasks we set up though.

#4

Hi there,
I see, Yes the incoming is as it is… good or Bad. I would send an email to SUPPORT on this specific issue, If it’s a systemic thing maybe they can figure it out.

HTH
GL :slight_smile: PJ :v: