[Ovmsdev] CAN bus hacking
Mark Webb-Johnson
mark at webb-johnson.net
Thu Apr 19 11:06:25 HKT 2018
For those of us working on vehicle support, I am concentrating on the last pieces for Tesla Roadster, ongoing work on Tesla Model S, and helping out Chris (in AU) to try to get Volt/Ampera ported (he has the car, I don’t). We have a lot of users waiting for Volt/Ampera support.
For all of this, I’m trying to extend the RE tools and CAN frameworks to allow for OVMS to be used for CAN bus analysis and simulation. It is really coming together nicely, and it looks like the system is powerful enough to handle this admirably. I’m trying hard not to plug a USB-CAN adaptor into my car, or use any other desktop tools. This should bring the barrier to entry right down for new vehicle support.
A few examples…
Using ‘can rx’ to simulate an incoming CAN bus message and see what happens to metrics:
OVMS# metrics trace on
Metric tracing is now on
OVMS# vehicle module VA
I (26522) v-voltampera: Volt/Ampera vehicle module
I (26522) metrics: Modified metric v.type: VA
I (26582) metrics: Modified metric v.e.parktime: 26Sec
I (27582) metrics: Modified metric v.e.parktime: 27Sec
I (28582) metrics: Modified metric v.e.parktime: 28Sec
OVMS# can can1 rx standard 135 01
I (49462) metrics: Modified metric v.e.on: yes
I (49462) metrics: Modified metric v.e.awake: yes
I (49462) metrics: Modified metric v.e.handbrake: no
I (49582) metrics: Modified metric v.e.parktime: 0Sec
OVMS# can can1 rx standard 4e1 42 55 31 30 32 36 38 39
OVMS# can can1 rx standard 514 47 31 52 44 36 45 34 36
I (94402) metrics: Modified metric v.vin: 1G1RD6E46BU102689
OVMS# can can1 rx standard 135 00
I (103342) metrics: Modified metric v.e.on: no
I (103342) metrics: Modified metric v.e.awake: no
I (103342) metrics: Modified metric v.e.handbrake: yes
I (103582) metrics: Modified metric v.e.parktime: 1Sec
I (104582) metrics: Modified metric v.e.parktime: 2Sec
I (105582) metrics: Modified metric v.e.parktime: 3Sec
I (106582) metrics: Modified metric v.e.parktime: 4Sec
I (107582) metrics: Modified metric v.e.parktime: 5Sec
I (108582) metrics: Modified metric v.e.parktime: 6Sec
I (109582) metrics: Modified metric v.e.parktime: 7Sec
I (110582) metrics: Modified metric v.e.parktime: 8Sec
Showing CAN message changes, and discovering new messages (or bytes within that were not previously changing but now are):
OVMS# re start
OVMS# re mode analyse
Now running in analyse mode
OVMS# can can1 rx standard 100 01 02 03 04
OVMS# can can1 rx standard 101 01 02 03 04
OVMS# can can1 rx standard 102 01 02 03 04
OVMS# re discover list changed
key records ms last
can1/100 1 8000 01 02 03 04 | ....
can1/101 1 8000 01 02 03 04 | ....
can1/102 1 8000 01 02 03 04 | ....
OVMS# re discover clear changed
Cleared all change flags
OVMS# can can1 rx standard 102 01 02 13 04
OVMS# re discover list changed
key records ms last
can1/102 2 15500 01 02 13 04 | ....
OVMS# re mode discover
Now running in discover mode
OVMS# can can1 rx standard 102 01 02 13 04
OVMS# re discover list discovered
key records ms last
OVMS# can can1 rx standard 102 01 12 13 04
OVMS# re discover list discovered
key records ms last
can1/102 4 14500 01 12 13 04 | ....
OVMS# can can1 rx standard 110 01 02 03 04
OVMS# re discover list discovered
key records ms last
can1/102 4 17500 01 12 13 04 | ....
can1/110 1 70000 01 02 03 04 | ....
A CRTD format can bus dump:
I (372613) re: Log service connection from 10.8.8.83
OVMS# can can1 rx standard 120 01 02 03 04
OVMS# can can1 rx standard 121 01 02 03 04
OVMS# can can1 rx standard 121 DE AD BE AT
I (466333) re: Log service disconnection from 10.8.8.83
$ telnet devbench.local 3000
Connected to devbench.local.
1524105901.244120 1R11 120 01 02 03 04
1524105905.794094 1R11 121 01 02 03 04
1524105915.194145 1R11 121 de ad be at
The TODO list for this is huge, so it will progress as I have time to work on it (and as I hit a requirement for each unfinished part). For example, simulating CAN bus traffic (replaying) would be nice (something like ‘$ cat mylogfile.crtd | nc devbench.local 3000’) - and that is something I need now, so will probably come next (and is pretty trivial - just pickup on data coming in the tcp/3000, decode it, and either simulate reception or transmit it on the actual car bus).
The whole decoding/encoding thing (where we use DBC or whatever to say key X byte Y is converted to v.bat.soc using this formula) is of course the holy grain of this; and is built upon all the foundation I’m laying now. The end goal remains for vehicle modules with just a DBC (or whatever) and no actual code.
It is all command line at the moment, but this could be very very cool using Michael’s web framework (particularly with real-time websocket updates).
Regards, Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180419/c1da3def/attachment-0001.html>
More information about the OvmsDev
mailing list