[Ovmsdev] V3 CAN frames missing last four data bytes

[Michael Balzer]

I second that, haven't thought that far, but also thought metrics are
probably the wrong place for this.

If someone wants to use my simple approach as an intermediate solution,
it's as simple as this:

/**
 * CAN debugging: log frame to metric
 */

void OvmsVehicleRenaultTwizy::LogFrame(CAN_frame_t* p_frame)
{
  // get/make debug metric:
  char nbuf[30];
  snprintf(nbuf, sizeof(nbuf),
    (p_frame->FIR.B.FF == CAN_frame_ext) ? "d.%s.f.%08x" : "d.%s.f.%03x",
    p_frame->origin->GetName(), p_frame->MsgID);
  OvmsMetric *ms = MyMetrics.Find(nbuf);
  if (!ms)
    ms = new OvmsMetricString(strdup(nbuf), 10);
 
  // format frame data:
  char vbuf[30];
  char *s = vbuf;
  for (int i=0; i < p_frame->FIR.B.DLC && i < 8; i++)
    s += sprintf(s, "%02x ", p_frame->data.u8[i]);
 
  ms->SetValue(vbuf);
}

…so can be fed any frame coming along.

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

Here's an example from the Twizy DDT definition:

      <Data Name="UserSOC">
        <Bits count="13">
          <Scaled Unit="%" Step=" .02"/>
        </Bits>
      </Data>

      <Data Name="HVBatInstantCurrent">
        <Bits count="12">
          <Scaled Unit="A" Offset="-2000" DivideBy=" 4"/>
        </Bits>
      </Data>

      <Request Name="Read CAN Battery Parameter">
        <Sent>
          <SentBytes>2101</SentBytes>
        </Sent>
        <Received MinBytes="26">
          <ReplyBytes>6101</ReplyBytes>
          …
          <DataItem Name="HVBatInstantCurrent" FirstByte="17"
BitOffset="4"/>
          …
          <DataItem Name="UserSOC" FirstByte="22" BitOffset="3"/>
          …
        </Received>
      </Request>

This example is an OBD poll, but the scheme applies to the process data
frames as well. CANZE extracts the address info, bit field size &
position, scaling and units from this into a compact CSV syntax:

https://github.com/fesch/CanZE/blob/master/app/src/main/java/lu/fisch/canze/actors/EcuDiagLBC.java


Regards,
Michael


Am 24.10.2017 um 04:03 schrieb Mark Webb-Johnson:
> 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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26