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

Mark, I'm not familiar with DBC. I only found partial community infos and examples and an 11 year old PDF that seems to be available in two versions -- is that the current specification? https://kupdf.net/download/dbc-format-2007_59c7d97e08bbc5f7236872bc_pdf https://wenku.baidu.com/view/41c36d25ed630b1c59eeb534 Is it possible to define a command/query scheme in DBC? Thanks, Michael Am 26.07.2018 um 11:13 schrieb Mark Webb-Johnson:

I’ve spent quite some time looking at the alternatives, with the result that no matter how much I hate the specification, how horrible I think the format is, how terribly designed is the syntax, DBC is the standard that everyone seems to want to follow.

For our holy grain of DBC signals -> OVMS metrics, we can use ‘attributes’ to define OVMS specific stuff (like signal name to OVMS metric names).

So, I’ve created a DBC component, and put in the basic structures to define the objects in a DBC file. I’ve also started the work to parse DBC files and load them in. The basic idea is:

* There is a core MyDBC object.

* DBC files can be loaded into that object (either from VFS, or as static strings), unloaded, etc.

* The MyDBC object will contain functions to access DBC files, and maintain them.

* Functions will also be provided to export DBC files.

* Statically loaded (via strings) DBC objects can be overwritten and modified (especially during development).

* The vehicle base class will be extended to allow a DBC file to be associated with a particular CAN bus - that will then automatically handle metrics from DBC signals.

* RE TOOLS will be changed to use DBC files directly (in particular to use DBC modifiers, rather than the current unique ID approach, but also for things like DBC signal extraction and display).

The overall goal is:

* The ‘old’ (current) way of doing things is to write C++ code in a vehicle module to match CAN bus #1, ID 0x102, and treat byte #3 an unsigned integer to set it as the SOC metric.

* The DBC way is to instead create a DBC file describe CAN bus #2, message ID 0x102, and a signal at byte #3 (16 bits in, length 8 bits) mapped to the SOC metric. Then, just tell the vehicle base module where that DBC file is and let it handle the mapping automatically. No code. Just DBC description files.

* We can still have custom C++ code, for custom metrics.

* When reverse engineering, we can dynamically modify a loaded DBC and instantly see the metrics change. We can then export that DBC out, and include it in the firmware for others to use.

The biggest amount of work is the DBC file handling itself. The changes to the vehicle base class are pretty simple.

Regards, Mark.

...

On 19 Apr 2018, at 11:06 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

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.

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Forgot to mention that there is also “ODX” (ISO 22901-1:2008). Regards, Mark.

On 27 Jul 2018, at 9:01 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Those are the same spec, and that is the best there is.

DBC is Data Base for CAN, and is really designed around documenting the CAN bus: messages (by ID), signals (on those messages), sending and receiving nodes, etc. It would document the PID request protocol, over CAN, but not the content/meaning of each PID.

I guess it could be used to document the PIDs themselves, using the multiplexor facility, but doesn’t seem that suited. There are some other standards for that (like ASAP2, I think). The vector site has some links, but it is all very proprietary:

https://vector.com/vi_asap2_toolset_en.html <https://vector.com/vi_asap2_toolset_en.html>

Regards, Mark.

...

On 27 Jul 2018, at 4:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

Mark,

I'm not familiar with DBC. I only found partial community infos and examples and an 11 year old PDF that seems to be available in two versions -- is that the current specification?

https://kupdf.net/download/dbc-format-2007_59c7d97e08bbc5f7236872bc_pdf <https://kupdf.net/download/dbc-format-2007_59c7d97e08bbc5f7236872bc_pdf> https://wenku.baidu.com/view/41c36d25ed630b1c59eeb534 <https://wenku.baidu.com/view/41c36d25ed630b1c59eeb534>

Is it possible to define a command/query scheme in DBC?

Thanks, Michael

Am 26.07.2018 um 11:13 schrieb Mark Webb-Johnson:

...

I’ve spent quite some time looking at the alternatives, with the result that no matter how much I hate the specification, how horrible I think the format is, how terribly designed is the syntax, DBC is the standard that everyone seems to want to follow.

For our holy grain of DBC signals -> OVMS metrics, we can use ‘attributes’ to define OVMS specific stuff (like signal name to OVMS metric names).

So, I’ve created a DBC component, and put in the basic structures to define the objects in a DBC file. I’ve also started the work to parse DBC files and load them in. The basic idea is:

There is a core MyDBC object.

DBC files can be loaded into that object (either from VFS, or as static strings), unloaded, etc.

The MyDBC object will contain functions to access DBC files, and maintain them.

Functions will also be provided to export DBC files.

Statically loaded (via strings) DBC objects can be overwritten and modified (especially during development).

The vehicle base class will be extended to allow a DBC file to be associated with a particular CAN bus - that will then automatically handle metrics from DBC signals.

RE TOOLS will be changed to use DBC files directly (in particular to use DBC modifiers, rather than the current unique ID approach, but also for things like DBC signal extraction and display).

The overall goal is:

The ‘old’ (current) way of doing things is to write C++ code in a vehicle module to match CAN bus #1, ID 0x102, and treat byte #3 an unsigned integer to set it as the SOC metric.

The DBC way is to instead create a DBC file describe CAN bus #2, message ID 0x102, and a signal at byte #3 (16 bits in, length 8 bits) mapped to the SOC metric. Then, just tell the vehicle base module where that DBC file is and let it handle the mapping automatically. No code. Just DBC description files.

We can still have custom C++ code, for custom metrics.

When reverse engineering, we can dynamically modify a loaded DBC and instantly see the metrics change. We can then export that DBC out, and include it in the firmware for others to use.

The biggest amount of work is the DBC file handling itself. The changes to the vehicle base class are pretty simple.

Regards, Mark.

...

On 19 Apr 2018, at 11:06 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

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.

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev