[Ovmsdev] V3 CAN frames missing last four data bytes

Fri Oct 27 15:04:47 HKT 2017

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171027/4f0835c3/attachment.htm>