[Ovmsdev] V3 CAN frames missing last four data bytes

[Mark Webb-Johnson]

From a reverse engineering point of view, I find the broadcast method easier to handle. There is just a stream of broadcast data. Wait long enough, and you’ll see everything there is to see. The issue is then decoding that.

The PID polling mechanism could fit into the retool framework without too much difficulty. We’d just have to understand the different variants of OBDII style polling, and pickup the request and response PIDs (along with their poll types). I presume it would just need to know the range of IDs to look for (OBDII has a standard range of, I think, 8 controllers - but there are often more than that in the car).

I don’t think CAN uses masks in any ways. Most commonly each controller has one PID it transmits on (or sometimes many grouped together closely). The ordering and numbering is based more on priority than anything else.

Regards, Mark.

> On 25 Oct 2017, at 12:41 PM, HONDA S-2000 <s2000 at audiobanshee.com> wrote:
> 
> 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
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev