[Ovmsdev] V3 CAN frames missing last four data bytes

[Mark Webb-Johnson]

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