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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev