Forums
Forums
Notifications
Clear all
Topic starter
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!
Posted : 07/09/2023 4:07 pm
do you have data on the bus
most car these days have a bridge on the obdii port
in the old days the obdii port was directly on the bus so you could sniff the bus
now a day there is a bridge and you don't see any data on the obdii port , you just see data when you do a request
Posted : 08/09/2023 3:35 pm
Topic starter
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.
Posted : 09/09/2023 1:46 am
yes that could be it
if you use the same request in two place the software doesn't know the answer is if for whom and just steal all the answer lol
i have seen that on obd gage in the past..
i you had one gage you had all the value
if you had 2 gage, the second one didn't have all the value to make sure to not conflict with the other gage
Posted : 10/09/2023 6:42 pm
Topic starter
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!
Posted : 13/09/2023 10:31 pm
Topic starter
bump
Posted : 19/09/2023 8:05 pm
Topic starter
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.
Posted : 27/09/2023 12:36 am
Topic starter
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.
Posted : 27/09/2023 12:37 am
