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 <https://github.com/stefanhoelzl/CANpy/blob/master/docs/DBC_Specification.md> http://www.socialledge.com/sjsu/index.php?title=DBC_Format <http://www.socialledge.com/sjsu/index.php?title=DBC_Format> I also found a 2007 protocol document, but not sure if that is supposed to be shareable. And then there is CAN babel (as you mentioned). Urgh, java… https://github.com/julietkilo/CANBabel <https://github.com/julietkilo/CANBabel> Here’s KCD: https://github.com/julietkilo/kcd <https://github.com/julietkilo/kcd> Anyway, this for ‘down the road’. Let’s put it aside for now. Regards, Mark.
On 27 Oct 2017, at 12:05 AM, Collin Kidder <collink@kkmfg.com> wrote:
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
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev