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@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@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