Metrics seems quite expensive, and limited, for storing this. Although good as a short-term kludge. I suggest a separate module completely independent (just listens on any CAN buses producing frames). This can be enabled on development systems if required. This is very similar to what I did for the can-re-tool project. Simply keying on Bus+MsgID is not enough for some cars (for example, Tesla Roadster has almost everything on ID 0x100 - but with the first byte indicating the sub-command). A facility is required to tell the module what is a unique identifier (e.g. for ID=0x100 then Bus+ID+B1 is the key). As well as the last CAN frame, it is also useful to keep counters so that we can show frequency/interval for that particular type. I haven’t really thought about how this could be done for polling systems (such as OBDII), or even command-response based systems (such as a start/stop charge command), but it works well as described for broadcast based CAN buses. I’m happy to rough something up for this, unless anybody has any better ideas for how to achieve it? Regards, Mark. P.S. I’ve always thought that long-term, descriptor files (rather than individual vehicle modules) is a better way to go for what we are trying to do (map bits of can bus messages -> metrics). Something that says ’v.bat.soc’ is bus #1, ID 0x100, B1=0x80, data byte #2, as uint8_t - rather than code to extract that. Doing it that way means no coding (just reverse engineering), and it is bi-directional (great for simulators).

On 24 Oct 2017, at 8:53 AM, Tom Parker <tom@carrott.org> wrote:

On 24/10/17 09:50, Michael Balzer wrote:

...

Is this a known problem?

In all of my can1 frames bytes 5-8 are zero:

OVMS > metrics list can d.can1.f.080 d.can1.f.155 07 97 cf 54 00 00 00 00 d.can1.f.196 00 ff e7 7f 00 00 00 00

Ooh a freeze-frame function. I built a very limited one of those for the v2 to help with leaf reverse engineering and I miss it on the v3. How do I enable this?

OVMS > metrics list can Unrecognised metric name

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

This was fun. And I need some fun after that GSM 07.10 stuff. I made a first pass at putting in a CAN Reverse Engineering framework. Seems to work ok, but there are so many opportunities here. OVMS > can can1 start active 1000000 Can bus can1 started in mode active at speed 1000000Kbps OVMS > re start OVMS > re key set 100 1 Set ID 100 to bytes 0x00 OVMS > re list key records ms last can1/001 21 1619 00 00 00 00 can1/100:07 4 8500 07 64 can1/100:80 11 3090 80 48 89 00 f7 00 7e 00 can1/100:81 2 17000 81 00 00 00 a9 f1 b8 4e can1/100:82 2 17000 82 1a can1/100:83 11 3090 83 00 00 00 a7 5a d3 09 can1/100:84 11 3090 84 00 00 00 ce bb 26 32 can1/100:85 11 3090 85 00 47 00 00 00 can1/100:86 2 17000 86 00 84 01 f0 ff ff ff can1/100:87 2 17000 87 21 ff ff 00 00 00 00 can1/100:88 30 1133 88 00 2c 00 ff ff 46 can1/100:89 30 1133 89 00 ff ff 7f ff can1/100:8b 2 17000 8b 04 a9 7d 1d 03 1e 12 can1/100:8d 2 17000 8d 00 84 01 c1 00 c0 00 can1/100:93 3 11333 93 00 ff ff 00 00 00 00 can1/100:94 2 17000 94 00 can1/100:95 30 1133 95 04 07 64 3c 00 0e 08 can1/100:96 24 1416 96 2a 00 02 21 0c 00 00 can1/100:97 2 17000 97 00 29 00 2b 96 00 00 can1/100:9b 4 8500 9b 50 a0 31 00 92 02 06 can1/100:9c 11 3090 9c 00 92 00 can1/100:9d 2 17000 9d 00 b2 00 b3 43 01 00 can1/100:a3 2 17000 a3 22 29 00 00 00 1e can1/100:a4 30 1133 a4 53 46 5a 52 45 38 42 can1/100:a5 30 1133 a5 31 35 42 33 30 30 30 can1/100:a6 30 1133 a6 35 36 39 can1/102 4 8500 06 bc 02 00 10 00 00 00 can1/280 21 1619 00 00 03 00 00 00 00 00 can1/400 425 80 02 a1 01 80 ca 80 55 00 can1/402 22 1545 fa 00 c2 2b 96 00 92 00 can1/420 21 1619 00 98 98 can1/588 21 1619 00 00 86 can1/590 21 1619 01 00 00 00 00 00 00 00 OVMS > re list can1/4 key records ms last can1/400 425 80 02 a1 01 80 ca 80 55 00 can1/402 22 1545 fa 00 c2 2b 96 00 92 00 can1/420 21 1619 00 98 98 OVMS > re ? clear Clear RE records key RE KEY framewrok list List RE records start Start RE tools stop Stop RE tools For normal operation, all you need to do is ‘re start’ and it will start recording statistics on CAN bus activity. The default key is the canbus/ID (with extended/standard formatted differently to differentiate them). For each key, it will create a record and store a count of the number of records received, as well as the last CAN frame of that type received. The ‘re list’ command will show you the keys, and their records. You’ll see the record count, the time interval between records (in milliseconds, calculated as now-started / number of records), and the data bytes of the last packet seen. You can use ‘re clear’ to clear the records, and restart the counters for a new capture. You can also add a search filter to ‘re list’ to restrict the records shown. For more advanced users, you can set the key bytes for particular IDs. The example given is for Tesla Roadster, where CAN ID 0x100 has a sub-command key in the first byte. So, ‘re key set 100 1’ tells the RE system to treat CAN 100 keys as 100:<databyte1>. Another example would be ‘re key set 100 1 2 3’ to cause the key to be 100:<B1>:<B2>:<B3>. Remember you can use ‘can <canX> rx …’ to simulate reception of data and play with this. Regards, Mark P.S. I moved ‘reset’ to ‘module reset’, to make it a bit harder to mis-type when using ‘re’.

On 24 Oct 2017, at 4:42 PM, Michael Balzer <dexter@expeedo.de> wrote:

I second that, haven't thought that far, but also thought metrics are probably the wrong place for this.

If someone wants to use my simple approach as an intermediate solution, it's as simple as this:

/** * CAN debugging: log frame to metric */

void OvmsVehicleRenaultTwizy::LogFrame(CAN_frame_t* p_frame) { // get/make debug metric: char nbuf[30]; snprintf(nbuf, sizeof(nbuf), (p_frame->FIR.B.FF == CAN_frame_ext) ? "d.%s.f.%08x" : "d.%s.f.%03x", p_frame->origin->GetName(), p_frame->MsgID); OvmsMetric *ms = MyMetrics.Find(nbuf); if (!ms) ms = new OvmsMetricString(strdup(nbuf), 10);

// format frame data: char vbuf[30]; char *s = vbuf; for (int i=0; i < p_frame->FIR.B.DLC && i < 8; i++) s += sprintf(s, "%02x ", p_frame->data.u8[i]);

ms->SetValue(vbuf); }

…so can be fed any frame coming along.

...

P.S. I’ve always thought that long-term, descriptor files (rather than individual vehicle modules) is a better way to go for what we are trying to do (map bits of can bus messages -> metrics). Something that says ’v.bat.soc’ is bus #1, ID 0x100, B1=0x80, data byte #2, as uint8_t - rather than code to extract that. Doing it that way means no coding (just reverse engineering), and it is bi-directional (great for simulators).

ddt4all (proprietary DDT2000 XML based) as well as CANZE follow this generic approach. A DDT specification file defines device addressing, data types, requests/responses and screens.

Here's an example from the Twizy DDT definition:

<Data Name="UserSOC"> <Bits count="13"> <Scaled Unit="%" Step=" .02"/> </Bits> </Data>

<Data Name="HVBatInstantCurrent"> <Bits count="12"> <Scaled Unit="A" Offset="-2000" DivideBy=" 4"/> </Bits> </Data>

<Request Name="Read CAN Battery Parameter"> <Sent> <SentBytes>2101</SentBytes> </Sent> <Received MinBytes="26"> <ReplyBytes>6101</ReplyBytes> … <DataItem Name="HVBatInstantCurrent" FirstByte="17" BitOffset="4"/> … <DataItem Name="UserSOC" FirstByte="22" BitOffset="3"/> … </Received> </Request>

This example is an OBD poll, but the scheme applies to the process data frames as well. CANZE extracts the address info, bit field size & position, scaling and units from this into a compact CSV syntax:

https://github.com/fesch/CanZE/blob/master/app/src/main/java/lu/fisch/canze/...

Regards, Michael

Am 24.10.2017 um 04:03 schrieb Mark Webb-Johnson:

...

Metrics seems quite expensive, and limited, for storing this. Although good as a short-term kludge.

I suggest a separate module completely independent (just listens on any CAN buses producing frames). This can be enabled on development systems if required. This is very similar to what I did for the can-re-tool project. Simply keying on Bus+MsgID is not enough for some cars (for example, Tesla Roadster has almost everything on ID 0x100 - but with the first byte indicating the sub-command). A facility is required to tell the module what is a unique identifier (e.g. for ID=0x100 then Bus+ID+B1 is the key).

As well as the last CAN frame, it is also useful to keep counters so that we can show frequency/interval for that particular type.

I haven’t really thought about how this could be done for polling systems (such as OBDII), or even command-response based systems (such as a start/stop charge command), but it works well as described for broadcast based CAN buses.

I’m happy to rough something up for this, unless anybody has any better ideas for how to achieve it?

Regards, Mark.

P.S. I’ve always thought that long-term, descriptor files (rather than individual vehicle modules) is a better way to go for what we are trying to do (map bits of can bus messages -> metrics). Something that says ’v.bat.soc’ is bus #1, ID 0x100, B1=0x80, data byte #2, as uint8_t - rather than code to extract that. Doing it that way means no coding (just reverse engineering), and it is bi-directional (great for simulators).

...

On 24 Oct 2017, at 8:53 AM, Tom Parker <tom@carrott.org> wrote:

On 24/10/17 09:50, Michael Balzer wrote:

...

Is this a known problem?

In all of my can1 frames bytes 5-8 are zero:

OVMS > metrics list can d.can1.f.080 d.can1.f.155 07 97 cf 54 00 00 00 00 d.can1.f.196 00 ff e7 7f 00 00 00 00 Ooh a freeze-frame function. I built a very limited one of those for the v2 to help with leaf reverse engineering and I miss it on the v3. How do I enable this?

OVMS > metrics list can Unrecognised metric name

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/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.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

That’s the sort of thing RE is supposed to help with. First stage is getting a baseline set of normal messages. For that we need to know how things are keyed. Then you put it in a mode where it ignores all those baseline messages and only tells you about anything new it finds on the bus. It can also be extended to show those new messages in real time. So, press a button in the car, and immediately see the new message appear as a trace style message. Something like this is great for finding out what message is sent when the heater is turned on, for example. I used it (in can-re-tool) for reverse engineering the roadster VDS command messages. Long-term, that leads on to the discussion of a vehicle database with labels saying message keyed by X, byte Y, bits Z1-Z4, type W, is the TPMS pressure. If that could be extended in real time on the car, it becomes a very powerful tool. The database documents all that is known, maps to metrics, and shows what is yet to be discovered. Uploaded in real time to the cloud, for others to benefit. But, work will need to be done to extend the base I’ve put in just now. Use cases like your should drive that. RE on the module is really just for quick dirty investigations, though. We also need to be able to just get full CAN bus dumps and export those out for offline analysis. I suspect for TPMS, you’re not going to see anything until a tpms reset tool is put on the network to upload tire sensor ids to the tpms module. But that is on the K-Line bus, so not sure if you are going to see anything on CAN. Regards, Mark

On 25 Oct 2017, at 12:46 PM, HONDA S-2000 <s2000@audiobanshee.com> wrote:

Thanks for this!

One of my first experiments will be CAN logging, in an attempt to isolate the TPMS programming commands for the Tesla Roadster (I’ve got two sets of wheel for summer and winter, and I hate scheduling time at the dealer twice a year just to swap them). I’ll probably find some way to detect “out of ordinary” messages and log them for analysis - especially since the 32-bit ID for each TPMS sensor is probably the bulk of the payload.

Brian

...

On Oct 24, 2017, at 7:19 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: This was fun. And I need some fun after that GSM 07.10 stuff.

I made a first pass at putting in a CAN Reverse Engineering framework. Seems to work ok, but there are so many opportunities here. […] For normal operation, all you need to do is ‘re start’ and it will start recording statistics on CAN bus activity. The default key is the canbus/ID (with extended/standard formatted differently to differentiate them). For each key, it will create a record and store a count of the number of records received, as well as the last CAN frame of that type received.

The ‘re list’ command will show you the keys, and their records. You’ll see the record count, the time interval between records (in milliseconds, calculated as now-started / number of records), and the data bytes of the last packet seen. You can use ‘re clear’ to clear the records, and restart the counters for a new capture. You can also add a search filter to ‘re list’ to restrict the records shown.

For more advanced users, you can set the key bytes for particular IDs. The example given is for Tesla Roadster, where CAN ID 0x100 has a sub-command key in the first byte. So, ‘re key set 100 1’ tells the RE system to treat CAN 100 keys as 100:<databyte1>. Another example would be ‘re key set 100 1 2 3’ to cause the key to be 100:<B1>:<B2>:<B3>.

Remember you can use ‘can <canX> rx …’ to simulate reception of data and play with this.

Regards, Mark

P.S. I moved ‘reset’ to ‘module reset’, to make it a bit harder to mis-type when using ‘re’.

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

I just tried a full ‘make clean; make' re-compile on mine, and it worked fine. Can you check: 1. ESP-IDF version $ cd ~/esp/esp-idf $ git status On branch release/v2.1 Your branch is up-to-date with 'origin/release/v2.1'. nothing to commit, working tree clean $ git remote -v origin https://github.com/openvehicles/esp-idf.git (fetch) origin https://github.com/openvehicles/esp-idf.git (push) 2. Version of xtensa crosstool-NG $ xtensa-esp32-elf-c++ -v 2>&1 | tail -1 gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-61-gab8375a) Then check 'git diff sdkconfig.default sdkconfig’ in your OVMS tree, to make sure that looks ok. Perhaps you don’t have PPP enabled? $ fgrep PPP sdkconfig CONFIG_PPP_SUPPORT=y CONFIG_PPP_PAP_SUPPORT=y CONFIG_PPP_CHAP_SUPPORT=y # CONFIG_PPP_MSCHAP_SUPPORT is not set # CONFIG_PPP_MPPE_SUPPORT is not set # CONFIG_PPP_DEBUG_ON is not set And also that your OVMS tree is up-to-date? Regards, Mark.

On 26 Oct 2017, at 1:16 AM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:

Mark,

I just pulled the latest changes and now simcom and lwip won’t compile.

Here’s the compiler output:

CXX esp32can.o In file included from /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_peripherals.h:45:0, from /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/./esp32can.cpp:39: /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:135:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:136:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^ In file included from /Users/goev/esp/esp-idf/components/lwip/include/lwip/lwip/ip_addr.h:38:0, from /Users/goev/esp/esp-idf/components/tcpip_adapter/include/tcpip_adapter.h:47, from /Users/goev/esp/esp-idf/components/esp32/include/esp_event.h:23, from /Users/goev/esp/esp-idf/components/esp32/include/esp_wifi.h:68, from /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/./esp32wifi.h:38, from /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_peripherals.h:39, from /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/./esp32can.cpp:39: /Users/goev/esp/esp-idf/components/lwip/include/lwip/lwip/ip4_addr.h:86:8: note: forward declaration of 'struct netif' struct netif; ^ make[1]: *** [esp32can.o] Error 1 make: *** [esp32can-build] Error 2 Sylfest:OVMS.V3 goev$ make

Am I missing something?

Geir

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Would the DBC format be of use here? It seems you primarily want to store mappings between data items and where they can be found within CAN messages. That's exactly what DBC files do. If you stored data definitions in DBC you could load the proper one for the car and parse the file to get all of the definitions. There are already lots of DBC files floating around for all sorts of cars. They don't tend to change the message format much between years and cars (unless you're Tesla - they sure seem to have a lot of different formats for CAN messages between cars, regions, and years). The problem is that it isn't geared toward polled data. The OBDII/UDS polled system is completely separate. But then most cars I've seen conform fairly closely to UDS for polled traffic so perhaps a second format that specifies the service/subfunction could work? Just observations from the outside looking in. I've done a lot with DBC files so I'm inclined to think in that direction. On Wed, Oct 25, 2017 at 7:31 PM, Greg D. <gregd2350@gmail.com> wrote:

Interesting, but do we have the processing power and memory to run this in real time?

We're hopefully on the cusp of an explosion of new BEVs, which potentially need support from a device such as OVMS, so building in a more generic CAN decoder engine could facilitate that support much more easily. But, how different are the cars within each manufacturer? Is the GM Volt's EV-related metrics that different from the Bolt EV? "Conway's Law" * tells me that they will be, but what have we seen? Roadster 1.5 vs 2.0 vs 2.5 are very similar, I think. Leaf 1 vs Leaf 2 - also pretty close, right? How will Ford's offerings work? WAG, Jaguar, and all the Chinese mfgrs etc. are just getting started. Is this problem sufficiently bound in scope that we don't need to get too exotic with the decoders?

Greg

* Conway's Law states that the structure of a product matches the structure of the organization that invented it. Two cars, from two different divisions, would therefore have different CAN bugs messages, unless a lot of energy was put into standardizing them internally.

Michael Balzer wrote:

P.S. I’ve always thought that long-term, descriptor files (rather than individual vehicle modules) is a better way to go for what we are trying to do (map bits of can bus messages -> metrics). Something that says ’v.bat.soc’ is bus #1, ID 0x100, B1=0x80, data byte #2, as uint8_t - rather than code to extract that. Doing it that way means no coding (just reverse engineering), and it is bi-directional (great for simulators).

ddt4all (proprietary DDT2000 XML based) as well as CANZE follow this generic approach. A DDT specification file defines device addressing, data types, requests/responses and screens.

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Well, not really. Vector doesn't seem particularly interested in releasing documentation on the file format. There are several open source implementations. None of us have been visited by men in black suits yet. But, we all kind of found bits and pieces throughout the internet and looked at each other's implementations. This isn't particularly ideal. Because of that maybe it would be better for you to use the KCD format. But, a lot of existing information you could use is already in DBC format so you'd likely be converting. CANBabel can be used to convert DBC files so this isn't especially troublesome. I suppose it depends on your level of worry regarding Vector and their DBC format. Lots of libraries exist to read it (including canbabel) and so far no one seems to have gotten in trouble for reading the DBC files. I'm even writing to them and no one has said a word. But, it's a rather gray area and perhaps Vector might get testy at any moment. This makes KCD the potentially safer format. But, it's also a lot more verbose. If you have memory or processing constraints then it might be a bit bloated to load on an embedded processor. However, the ESP32 is rather fast so I don't think you'd have much of an issue there. I suppose the only real downside I could see to using KCD files is that they're a lot more obscure and less supported. Kayak is the only program I know of that uses them. This somewhat limits their usefulness in other projects. On Thu, Oct 26, 2017 at 10:45 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Either DBC or KCD seems suitable.

Is there an open specification for the DBC format, that is shareable?

Regards, Mark.

...

On 26 Oct 2017, at 9:52 PM, Collin Kidder <collink@kkmfg.com> wrote:

Would the DBC format be of use here? It seems you primarily want to store mappings between data items and where they can be found within CAN messages. That's exactly what DBC files do. If you stored data definitions in DBC you could load the proper one for the car and parse the file to get all of the definitions. There are already lots of DBC files floating around for all sorts of cars. They don't tend to change the message format much between years and cars (unless you're Tesla - they sure seem to have a lot of different formats for CAN messages between cars, regions, and years).

The problem is that it isn't geared toward polled data. The OBDII/UDS polled system is completely separate. But then most cars I've seen conform fairly closely to UDS for polled traffic so perhaps a second format that specifies the service/subfunction could work?

Just observations from the outside looking in. I've done a lot with DBC files so I'm inclined to think in that direction.

On Wed, Oct 25, 2017 at 7:31 PM, Greg D. <gregd2350@gmail.com> wrote:

...

Interesting, but do we have the processing power and memory to run this in real time?

We're hopefully on the cusp of an explosion of new BEVs, which potentially need support from a device such as OVMS, so building in a more generic CAN decoder engine could facilitate that support much more easily. But, how different are the cars within each manufacturer? Is the GM Volt's EV-related metrics that different from the Bolt EV? "Conway's Law" * tells me that they will be, but what have we seen? Roadster 1.5 vs 2.0 vs 2.5 are very similar, I think. Leaf 1 vs Leaf 2 - also pretty close, right? How will Ford's offerings work? WAG, Jaguar, and all the Chinese mfgrs etc. are just getting started. Is this problem sufficiently bound in scope that we don't need to get too exotic with the decoders?

Greg

* Conway's Law states that the structure of a product matches the structure of the organization that invented it. Two cars, from two different divisions, would therefore have different CAN bugs messages, unless a lot of energy was put into standardizing them internally.

Michael Balzer wrote:

P.S. I’ve always thought that long-term, descriptor files (rather than individual vehicle modules) is a better way to go for what we are trying to do (map bits of can bus messages -> metrics). Something that says ’v.bat.soc’ is bus #1, ID 0x100, B1=0x80, data byte #2, as uint8_t - rather than code to extract that. Doing it that way means no coding (just reverse engineering), and it is bi-directional (great for simulators).

ddt4all (proprietary DDT2000 XML based) as well as CANZE follow this generic approach. A DDT specification file defines device addressing, data types, requests/responses and screens.

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

On 27/10/17 20:04, Mark Webb-Johnson wrote:

DBC does seem an acceptable format. Ugly as hell, though.

A couple of references I found:

https://github.com/stefanhoelzl/CANpy/blob/master/docs/DBC_Specification.md http://www.socialledge.com/sjsu/index.php?title=DBC_Format

DBC is being used by comma.ai see https://github.com/commaai/opendbc

Here’s KCD:

https://github.com/julietkilo/kcd

I've been documenting the Leaf Can bus using KCD and I built a man in the middle for the LBC controller with can4python. It turned out fairly ugly because can4python doesn't support multiplex signals. https://carrott.org/git/leaf-can-utils.git/blob/HEAD:/nissan-leaf.kcd and https://carrott.org/git/leaf-can-utils.git/blob/HEAD:/nissan-leaf-mitm.py I haven't had time to do it, but I'd really like to implement multiplex signal support in can4python so I can simplify the mitm. I'm not sure why so many open source can bus efforts have been abandoned before they're fully done.

Forgive me for asking, since I have limited experience with CAN message formats, but what is it about the “polled” or “command-response” systems that makes them more difficult than other keying challenges? Is it that there would be too many matches on the keys in a polled or command-response system unless there were also some intelligent state tracking to turn on and off the matching at the right times? I do understand the need for Bus+MsgID keying, especially since every vehicle has potentially a different format for their CAN bus(es). For this issue, would it be possible to specify both a bit mask and a key, such that the bit mask determines which bits are compared against the key for a match? I see that the CAN protocol has a priority code / ID that is not a multiple of 8 bits (it’s 11 or 29 bits *), so the “mask” and key could prove complicated. I’m assuming that the Data field section of every CAN packet is composed of 8-bit bytes, but I don’t know whether that’s true for every message on every vehicle. Brian * Not sure whether the OVMS v3 platform supports CAN 2.0 bus protocols. On Oct 23, 2017, at 7:03 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Metrics seems quite expensive, and limited, for storing this. Although good as a short-term kludge.

I suggest a separate module completely independent (just listens on any CAN buses producing frames). This can be enabled on development systems if required. This is very similar to what I did for the can-re-tool project. Simply keying on Bus+MsgID is not enough for some cars (for example, Tesla Roadster has almost everything on ID 0x100 - but with the first byte indicating the sub-command). A facility is required to tell the module what is a unique identifier (e.g. for ID=0x100 then Bus+ID+B1 is the key).

As well as the last CAN frame, it is also useful to keep counters so that we can show frequency/interval for that particular type.

I haven’t really thought about how this could be done for polling systems (such as OBDII), or even command-response based systems (such as a start/stop charge command), but it works well as described for broadcast based CAN buses.

I’m happy to rough something up for this, unless anybody has any better ideas for how to achieve it?

Regards, Mark.

P.S. I’ve always thought that long-term, descriptor files (rather than individual vehicle modules) is a better way to go for what we are trying to do (map bits of can bus messages -> metrics). Something that says ’v.bat.soc’ is bus #1, ID 0x100, B1=0x80, data byte #2, as uint8_t - rather than code to extract that. Doing it that way means no coding (just reverse engineering), and it is bi-directional (great for simulators).

On 24 Oct 2017, at 8:53 AM, Tom Parker <tom@carrott.org> wrote:

...

On 24/10/17 09:50, Michael Balzer wrote:

...

Is this a known problem?

In all of my can1 frames bytes 5-8 are zero:

OVMS > metrics list can d.can1.f.080 d.can1.f.155 07 97 cf 54 00 00 00 00 d.can1.f.196 00 ff e7 7f 00 00 00 00

Ooh a freeze-frame function. I built a very limited one of those for the v2 to help with leaf reverse engineering and I miss it on the v3. How do I enable this?

OVMS > metrics list can Unrecognised metric name