Incorrect (backwards) numbering for Bit Mode
Posted: Sun Aug 16, 2020 12:56 pm
There is a mistake in the numbering for Bit Mode. It's backwards. 0 should start from the other end of the byte. It's incorrect in the current implementation. Offset 0 looks at bit 7, and vice versa.
To prove this I added a message to a CAN DB, made individual signal names TEST_b0 for Startbit 0 and so on.
Configured RaceCapture the same way, TEST_b0 had offset 0, and so on.
Used an external device to send the CAN message. (Ignore the "improper" naming convention where B1 is really Byte 0.)
Sent 0x01h on B1 (Byte 0 / bit 0) and you can see that TEST_b0 is illuminated.
Sent 0x80h on B3 (Byte 3 / bit 31) and you can see that TEST_b31 is illuminated.
What showed up in RaceCapture was exactly wrong.
See that TEST_b7 was set instead of TEST_b0, and TEST_b24 was set instead of TEST_b31.
Attached is the .rcp config file for reference.
Conclusion, the bit numbering started counting at the wrong end of the Byte in the RaceCapture App. Please correct this!
- bit_backwards.png (148.69 KiB) Viewed 7519 times
Configured RaceCapture the same way, TEST_b0 had offset 0, and so on.
Used an external device to send the CAN message. (Ignore the "improper" naming convention where B1 is really Byte 0.)
Sent 0x01h on B1 (Byte 0 / bit 0) and you can see that TEST_b0 is illuminated.
Sent 0x80h on B3 (Byte 3 / bit 31) and you can see that TEST_b31 is illuminated.
What showed up in RaceCapture was exactly wrong.
- incorrect_bits.jpg (120.53 KiB) Viewed 7519 times
Attached is the .rcp config file for reference.
Conclusion, the bit numbering started counting at the wrong end of the Byte in the RaceCapture App. Please correct this!