Hello.

I’ve been using TP for many years, but haven’t messed around with the more advanced stuff since 2021. Now I see TP has a CAN monitor mode, which is awesome! However, I keep getting an error when testing in the CAN/DBC Editor window.

I get the following when I tap on test:

No can frame seen for can id 264 (0x0108)
CAN frame decode: 264 (0x108)
10802BD08EC019F60EE

I get this same result from several different frame id’s (entered in decimal or 0xHex), and usually when I’m trying to read either more than 8 bits, or bits across 2 bytes. For the frame id above, I have tested each bit individually in the editor and get an expected value, but once I try viewing 2 or more bits at once that cross a byte, and sometimes multiple bits within the same byte, I get the above response. Obviously there is data in that frame (and for that particular id it’s changing data) so what am I doing wrong?

Thanks for any help!

No bridge and no firewall. I did lots of logging via terminal apps well before CAN monitoring was a thing in TP, so there’s lots of data available on each of the busses in my truck, all accessible via the OBD port. And, in TP it displays the updating bytes within the frame in the test popup. If I choose just a few bits and don’t cross a byte and save that frame, it will show the data in a gauge on the dashboard. The problem it seems is TP appears to think there’s no data when it’s receiving data in the monitored frame.

I’m not having issues with gauges on the dashboard other than receiving no data, I’m just not getting results when editing/testing signals in the editor even though it’s receiving data.

It seems part of my troubles has to do with TP reading the bits in reverse order when set for Little Endian, even when only reading 8 bits or less from within a single byte. For example, in the sample data result from my initial post, byte 1 (of the message) is 0x02 which TP will report as decimal 2 when tested using start bit 7 length 8 bits and Big Endian. But when switched to Little Endian TP reports the same 0x02 message byte as decimal 64 which is the bits for 0x02 reversed…00000010 gets read in reverse as 01000000.

Please straighten me out on this, but it’s my understanding that Endianess only changes byte order and not bit order. Is there some setting somewhere I’m missing, or some bit of knowledge I’m missing that changes which bit is the LSB and MSB in TP when Endianess changes?

Thanks!

Ian, I sent a debug log with just 1 gauge. It is CAN frame 264, little endian, starting bit 7 for 8 bits…it’s reading the bits in reverse order.