[Ovmsdev] V3 CAN frames missing last four data bytes

[Collin Kidder]

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
>