Incorrect (backwards) numbering for Bit Mode

Found a bug or got a feature request? Post it here.
Post Reply
GTIspirit
Posts: 249
Joined: Wed Jan 09, 2013 11:20 am
Location: SE Michigan

Incorrect (backwards) numbering for Bit Mode

Post by GTIspirit »

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.
bit_backwards.png
bit_backwards.png (148.69 KiB) Viewed 8573 times
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.
incorrect_bits.jpg
incorrect_bits.jpg (120.53 KiB) Viewed 8573 times
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!
Attachments
bitTesting.zip
(5.54 KiB) Downloaded 332 times

brentp
Site Admin
Posts: 6282
Joined: Wed Jan 24, 2007 6:36 am

Re: Incorrect (backwards) numbering for Bit Mode

Post by brentp »

Hi,

Thanks for the note. We'll work with you to investigate and resolve this issue.

Post Reply