[Ovmsdev] V3 CAN frames missing last four data bytes

[HONDA S-2000]

Forgive me for asking, since I have limited experience with CAN message formats, but what is it about the “polled” or “command-response” systems that makes them more difficult than other keying challenges?

Is it that there would be too many matches on the keys in a polled or command-response system unless there were also some intelligent state tracking to turn on and off the matching at the right times?

I do understand the need for Bus+MsgID keying, especially since every vehicle has potentially a different format for their CAN bus(es). For this issue, would it be possible to specify both a bit mask and a key, such that the bit mask determines which bits are compared against the key for a match?

I see that the CAN protocol has a priority code / ID that is not a multiple of 8 bits (it’s 11 or 29 bits *), so the “mask” and key could prove complicated. I’m assuming that the Data field section of every CAN packet is composed of 8-bit bytes, but I don’t know whether that’s true for every message on every vehicle.

Brian

* Not sure whether the OVMS v3 platform supports CAN 2.0 bus protocols.


On Oct 23, 2017, at 7:03 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> Metrics seems quite expensive, and limited, for storing this. Although good as a short-term kludge.
> 
> I suggest a separate module completely independent (just listens on any CAN buses producing frames). This can be enabled on development systems if required. This is very similar to what I did for the can-re-tool project. Simply keying on Bus+MsgID is not enough for some cars (for example, Tesla Roadster has almost everything on ID 0x100 - but with the first byte indicating the sub-command). A facility is required to tell the module what is a unique identifier (e.g. for ID=0x100 then Bus+ID+B1 is the key).
> 
> As well as the last CAN frame, it is also useful to keep counters so that we can show frequency/interval for that particular type.
> 
> I haven’t really thought about how this could be done for polling systems (such as OBDII), or even command-response based systems (such as a start/stop charge command), but it works well as described for broadcast based CAN buses.
> 
> I’m happy to rough something up for this, unless anybody has any better ideas for how to achieve it?
> 
> Regards, Mark.
> 
> 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).
> 
> On 24 Oct 2017, at 8:53 AM, Tom Parker <tom at carrott.org> wrote:
>> On 24/10/17 09:50, Michael Balzer wrote:
>>> Is this a known problem?
>>> 
>>> In all of my can1 frames bytes 5-8 are zero:
>>> 
>>> OVMS > metrics list can
>>> d.can1.f.080
>>> d.can1.f.155                   07 97 cf 54 00 00 00 00
>>> d.can1.f.196                   00 ff e7 7f 00 00 00 00
>> 
>> Ooh a freeze-frame function. I built a very limited one of those for the v2 to help with leaf reverse engineering and I miss it on the v3. How do I enable this?
>> 
>> OVMS > metrics list can
>> Unrecognised metric name