<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">DBC does seem an acceptable format. Ugly as hell, though.<div class=""><br class=""></div><div class="">A couple of references I found:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><a href="https://github.com/stefanhoelzl/CANpy/blob/master/docs/DBC_Specification.md" class="">https://github.com/stefanhoelzl/CANpy/blob/master/docs/DBC_Specification.md</a></div><div class=""><a href="http://www.socialledge.com/sjsu/index.php?title=DBC_Format" class="">http://www.socialledge.com/sjsu/index.php?title=DBC_Format</a></div></blockquote><div class=""><br class=""></div><div class="">I also found a 2007 protocol document, but not sure if that is supposed to be shareable.</div><div class=""><br class=""></div><div class="">And then there is CAN babel (as you mentioned). Urgh, java…</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><a href="https://github.com/julietkilo/CANBabel" class="">https://github.com/julietkilo/CANBabel</a></div></blockquote><div class=""><br class=""></div><div class="">Here’s KCD:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><a href="https://github.com/julietkilo/kcd" class="">https://github.com/julietkilo/kcd</a></div></blockquote><div class=""><br class=""></div><div class="">Anyway, this for ‘down the road’. Let’s put it aside for now.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 27 Oct 2017, at 12:05 AM, Collin Kidder <<a href="mailto:collink@kkmfg.com" class="">collink@kkmfg.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Well, not really. Vector doesn't seem particularly interested in<br class="">releasing documentation on the file format. There are several open<br class="">source implementations. None of us have been visited by men in black<br class="">suits yet. But, we all kind of found bits and pieces throughout the<br class="">internet and looked at each other's implementations. This isn't<br class="">particularly ideal. Because of that maybe it would be better for you<br class="">to use the KCD format. But, a lot of existing information you could<br class="">use is already in DBC format so you'd likely be converting. CANBabel<br class="">can be used to convert DBC files so this isn't especially troublesome.<br class=""><br class="">I suppose it depends on your level of worry regarding Vector and their<br class="">DBC format. Lots of libraries exist to read it (including canbabel)<br class="">and so far no one seems to have gotten in trouble for reading the DBC<br class="">files. I'm even writing to them and no one has said a word. But, it's<br class="">a rather gray area and perhaps Vector might get testy at any moment.<br class="">This makes KCD the potentially safer format. But, it's also a lot more<br class="">verbose. If you have memory or processing constraints then it might be<br class="">a bit bloated to load on an embedded processor. However, the ESP32 is<br class="">rather fast so I don't think you'd have much of an issue there. I<br class="">suppose the only real downside I could see to using KCD files is that<br class="">they're a lot more obscure and less supported. Kayak is the only<br class="">program I know of that uses them. This somewhat limits their<br class="">usefulness in other projects.<br class=""><br class="">On Thu, Oct 26, 2017 at 10:45 AM, Mark Webb-Johnson<br class=""><<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:<br class=""><blockquote type="cite" class="">Either DBC or KCD seems suitable.<br class=""><br class="">Is there an open specification for the DBC format, that is shareable?<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 26 Oct 2017, at 9:52 PM, Collin Kidder <<a href="mailto:collink@kkmfg.com" class="">collink@kkmfg.com</a>> wrote:<br class=""><br class="">Would the DBC format be of use here? It seems you primarily want to<br class="">store mappings between data items and where they can be found within<br class="">CAN messages. That's exactly what DBC files do. If you stored data<br class="">definitions in DBC you could load the proper one for the car and parse<br class="">the file to get all of the definitions. There are already lots of DBC<br class="">files floating around for all sorts of cars. They don't tend to change<br class="">the message format much between years and cars (unless you're Tesla -<br class="">they sure seem to have a lot of different formats for CAN messages<br class="">between cars, regions, and years).<br class=""><br class="">The problem is that it isn't geared toward polled data. The OBDII/UDS<br class="">polled system is completely separate. But then most cars I've seen<br class="">conform fairly closely to UDS for polled traffic so perhaps a second<br class="">format that specifies the service/subfunction could work?<br class=""><br class="">Just observations from the outside looking in. I've done a lot with<br class="">DBC files so I'm inclined to think in that direction.<br class=""><br class="">On Wed, Oct 25, 2017 at 7:31 PM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">Interesting, but do we have the processing power and memory to run this in<br class="">real time?<br class=""><br class="">We're hopefully on the cusp of an explosion of new BEVs, which potentially<br class="">need support from a device such as OVMS, so building in a more generic CAN<br class="">decoder engine could facilitate that support much more easily. But, how<br class="">different are the cars within each manufacturer? Is the GM Volt's<br class="">EV-related metrics that different from the Bolt EV? "Conway's Law" * tells<br class="">me that they will be, but what have we seen? Roadster 1.5 vs 2.0 vs 2.5 are<br class="">very similar, I think. Leaf 1 vs Leaf 2 - also pretty close, right? How<br class="">will Ford's offerings work? WAG, Jaguar, and all the Chinese mfgrs etc. are<br class="">just getting started. Is this problem sufficiently bound in scope that we<br class="">don't need to get too exotic with the decoders?<br class=""><br class="">Greg<br class=""><br class="">* Conway's Law states that the structure of a product matches the structure<br class="">of the organization that invented it. Two cars, from two different<br class="">divisions, would therefore have different CAN bugs messages, unless a lot of<br class="">energy was put into standardizing them internally.<br class=""><br class=""><br class="">Michael Balzer wrote:<br class=""><br class="">P.S. I’ve always thought that long-term, descriptor files (rather than<br class="">individual vehicle modules) is a better way to go for what we are trying to<br class="">do (map bits of can bus messages -> metrics). Something that says<br class="">’v.bat.soc’ is bus #1, ID 0x100, B1=0x80, data byte #2, as uint8_t - rather<br class="">than code to extract that. Doing it that way means no coding (just reverse<br class="">engineering), and it is bi-directional (great for simulators).<br class=""><br class="">ddt4all (proprietary DDT2000 XML based) as well as CANZE follow this<br class="">generic approach. A DDT specification file defines device addressing,<br class="">data types, requests/responses and screens.<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""><br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></blockquote><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>