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.