[Ovmsdev] V3 CAN frames missing last four data bytes

[Mark Webb-Johnson]

That’s the sort of thing RE is supposed to help with.

First stage is getting a baseline set of normal messages. For that we need to know how things are keyed. Then you put it in a mode where it ignores all those baseline messages and only tells you about anything new it finds on the bus. It can also be extended to show those new messages in real time. So, press a button in the car, and immediately see the new message appear as a trace style message. Something like this is great for finding out what message is sent when the heater is turned on, for example. I used it (in can-re-tool) for reverse engineering the roadster VDS command messages.

Long-term, that leads on to the discussion of a vehicle database with labels saying message keyed by X, byte Y, bits Z1-Z4, type W, is the TPMS pressure. If that could be extended in real time on the car, it becomes a very powerful tool. The database documents all that is known, maps to metrics, and shows what is yet to be discovered. Uploaded in real time to the cloud, for others to benefit.

But, work will need to be done to extend the base I’ve put in just now. Use cases like your should drive that.

RE on the module is really just for quick dirty investigations, though. We also need to be able to just get full CAN bus dumps and export those out for offline analysis.

I suspect for TPMS, you’re not going to see anything until a tpms reset tool is put on the network to upload tire sensor ids to the tpms module. But that is on the K-Line bus, so not sure if you are going to see anything on CAN.

Regards, Mark

> On 25 Oct 2017, at 12:46 PM, HONDA S-2000 <s2000 at audiobanshee.com> wrote:
> 
> Thanks for this!
> 
> One of my first experiments will be CAN logging, in an attempt to isolate the TPMS programming commands for the Tesla Roadster (I’ve got two sets of wheel for summer and winter, and I hate scheduling time at the dealer twice a year just to swap them). I’ll probably find some way to detect “out of ordinary” messages and log them for analysis - especially since the 32-bit ID for each TPMS sensor is probably the bulk of the payload.
> 
> Brian
> 
> 
>> On Oct 24, 2017, at 7:19 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>> This was fun. And I need some fun after that GSM 07.10 stuff.
>> 
>> I made a first pass at putting in a CAN Reverse Engineering framework. Seems to work ok, but there are so many opportunities here.
> […]
>> For normal operation, all you need to do is ‘re start’ and it will start recording statistics on CAN bus activity. The default key is the canbus/ID (with extended/standard formatted differently to differentiate them). For each key, it will create a record and store a count of the number of records received, as well as the last CAN frame of that type received.
>> 
>> The ‘re list’ command will show you the keys, and their records. You’ll see the record count, the time interval between records (in milliseconds, calculated as now-started / number of records), and the data bytes of the last packet seen. You can use ‘re clear’ to clear the records, and restart the counters for a new capture. You can also add a search filter to ‘re list’ to restrict the records shown.
>> 
>> For more advanced users, you can set the key bytes for particular IDs. The example given is for Tesla Roadster, where CAN ID 0x100 has a sub-command key in the first byte. So, ‘re key set 100 1’ tells the RE system to treat CAN 100 keys as 100:<databyte1>. Another example would be ‘re key set 100 1 2 3’ to cause the key to be 100:<B1>:<B2>:<B3>.
>> 
>> Remember you can use ‘can <canX> rx …’ to simulate reception of data and play with this.
>> 
>> Regards, Mark
>> 
>> P.S. I moved ‘reset’ to ‘module reset’, to make it a bit harder to mis-type when using ‘re’.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev