[Ovmsdev] CAN bus hacking

Fri Apr 20 21:32:55 HKT 2018

Perhaps just a starting point would be enough. A single page to show the discovered keys (like ‘re list’), auto-updating. With an example like that, I can probably expand on it.

Regards, Mark

> On 20 Apr 2018, at 2:09 AM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Mark,
> 
> very cool, very helpful.
> 
> I'll have a look at the web UI for this ASAP.
> 
> Regards,
> Michael
> 
> 
> Am 19.04.2018 um 05:06 schrieb Mark Webb-Johnson:
>> 
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180420/859a6cba/attachment.htm>