search

Equipment-and-Tool-Institute / j1939-84

J1939-84 implementation for etools.org
MIT License
7 stars 6 forks source link

Correct CAL ID and CVN outcomes in 6.1.7 #1201

Closed ericthomasswenson closed 1 month ago

ericthomasswenson commented 1 year ago

Correct Cal ID and CVN Outcomes, these examples are from 3.1.6

Start Test 1.7 - DM19: Calibration information 13:58:44.4597 Global DM19 Request 13:58:44.4616 18EAFFF9 [3] 00 D3 00 (TX) 13:58:45.3721 1CD3FF00 [100] 76 A4 C2 C8 52 41 44 58 53 55 41 41 00 00 00 00 00 00 00 00 A8 73 89 13 4E 4F 78 2D 53 41 45 31 34 61 20 41 54 49 31 00 8C 4B F9 C9 4E 4F 78 2D 53 41 45 31 34 61 20 41 54 4F 31 00 AC FF 33 00 30 32 30 31 30 31 30 30 30 32 00 00 00 00 00 00 D2 BF 0F A9 50 4D 53 31 32 33 34 31 41 31 30 31 00 00 00 00 DM19 from Engine #1 (0): [ CAL ID of RADXSUAA and CVN of 0xC8C2A476 CAL ID of NOx-SAE14a ATI1 and CVN of 0x138973A8 CAL ID of NOx-SAE14a ATO1 and CVN of 0xC9F94B8C CAL ID of 0201010002 and CVN of 0x0033FFAC CAL ID of PMS12341A101 and CVN of 0xA90FBFD2 ]

INFO: 6.1.7.3.b - Engine #1 (0) provided more than one CAL ID and CVN pair in a single DM19 message WARN: 6.1.7.3.c - CAL ID 0201010002 has 00h is in either the first or fourth bytes // CVN FAIL: 6.1.7.2.b.ii - OBD ECU Engine #1 (0) CAL ID not formatted correctly (contains non-printable ASCII) FAIL: 6.1.7.2.b.ii - OBD ECU Engine #1 (0) CAL ID not formatted correctly (contains non-printable ASCII) FAIL: 6.1.7.2.b.ii - OBD ECU Engine #1 (0) CAL ID not formatted correctly (contains non-printable ASCII) FAIL: 6.1.7.2.b.ii - OBD ECU Engine #1 (0) CAL ID not formatted correctly (contains non-printable ASCII) FAIL: 6.1.7.2.b.ii - OBD ECU Engine #1 (0) CAL ID not formatted correctly (contains non-printable ASCII)

// Binary zeros are acceptable padding for ASCII data in fixed width fields. // Perhaps 6.1.7.3.c should have said, // “For CVN responses from OBD ECUs, warn if 00h is observed in either the first or fourth bytes”. // And then the warning message could have more naturally said. // WARN: 6.1.7.3.c - Engine #1 (0) CVN 0x0033FFAC contains 00h in either the first or fourth bytes

ericthomasswenson commented 1 year ago

See also #1120 #1192 #766

Other DM19 complaints are believed to be related to BAM message reception.

battjt commented 1 year ago

The bug was not caught due to the method of testing with "strings" which do not have null charaacters instead of byte[] which may contian 0. New tests are based on provided CAN data.

ericthomasswenson commented 1 year ago

Revised Text:

c. For CVN responses from OBD ECUs, warn if 00h is observed in either the first or fourth bytes.

naroner commented 1 year ago

I would argue that the revised text can still affect valid CVNs. If some form of CRC (polynomial) is used it is possible to get leading or trailing zeros as a valid CVN. Currently -73 doesn't have a way to denote if DM19 contains a padded 16bit CVN or a 32bit CVN that just happens to have zeros in byte 1 or 4. I would propose changing this to an info instead of a warning, or checking to see if byte 1 and 2 are zeros or byte 3 and 4 are zeros.