[Ovmsdev] V3 CAN frames missing last four data bytes
Mark Webb-Johnson
mark at webb-johnson.net
Tue Oct 24 22:19:01 HKT 2017
This was fun. And I need some fun after that GSM 07.10 stuff.
I made a first pass at putting in a CAN Reverse Engineering framework. Seems to work ok, but there are so many opportunities here.
OVMS > can can1 start active 1000000
Can bus can1 started in mode active at speed 1000000Kbps
OVMS > re start
OVMS > re key set 100 1
Set ID 100 to bytes 0x00
OVMS > re list
key records ms last
can1/001 21 1619 00 00 00 00
can1/100:07 4 8500 07 64
can1/100:80 11 3090 80 48 89 00 f7 00 7e 00
can1/100:81 2 17000 81 00 00 00 a9 f1 b8 4e
can1/100:82 2 17000 82 1a
can1/100:83 11 3090 83 00 00 00 a7 5a d3 09
can1/100:84 11 3090 84 00 00 00 ce bb 26 32
can1/100:85 11 3090 85 00 47 00 00 00
can1/100:86 2 17000 86 00 84 01 f0 ff ff ff
can1/100:87 2 17000 87 21 ff ff 00 00 00 00
can1/100:88 30 1133 88 00 2c 00 ff ff 46
can1/100:89 30 1133 89 00 ff ff 7f ff
can1/100:8b 2 17000 8b 04 a9 7d 1d 03 1e 12
can1/100:8d 2 17000 8d 00 84 01 c1 00 c0 00
can1/100:93 3 11333 93 00 ff ff 00 00 00 00
can1/100:94 2 17000 94 00
can1/100:95 30 1133 95 04 07 64 3c 00 0e 08
can1/100:96 24 1416 96 2a 00 02 21 0c 00 00
can1/100:97 2 17000 97 00 29 00 2b 96 00 00
can1/100:9b 4 8500 9b 50 a0 31 00 92 02 06
can1/100:9c 11 3090 9c 00 92 00
can1/100:9d 2 17000 9d 00 b2 00 b3 43 01 00
can1/100:a3 2 17000 a3 22 29 00 00 00 1e
can1/100:a4 30 1133 a4 53 46 5a 52 45 38 42
can1/100:a5 30 1133 a5 31 35 42 33 30 30 30
can1/100:a6 30 1133 a6 35 36 39
can1/102 4 8500 06 bc 02 00 10 00 00 00
can1/280 21 1619 00 00 03 00 00 00 00 00
can1/400 425 80 02 a1 01 80 ca 80 55 00
can1/402 22 1545 fa 00 c2 2b 96 00 92 00
can1/420 21 1619 00 98 98
can1/588 21 1619 00 00 86
can1/590 21 1619 01 00 00 00 00 00 00 00
OVMS > re list can1/4
key records ms last
can1/400 425 80 02 a1 01 80 ca 80 55 00
can1/402 22 1545 fa 00 c2 2b 96 00 92 00
can1/420 21 1619 00 98 98
OVMS > re ?
clear Clear RE records
key RE KEY framewrok
list List RE records
start Start RE tools
stop Stop RE tools
For normal operation, all you need to do is ‘re start’ and it will start recording statistics on CAN bus activity. The default key is the canbus/ID (with extended/standard formatted differently to differentiate them). For each key, it will create a record and store a count of the number of records received, as well as the last CAN frame of that type received.
The ‘re list’ command will show you the keys, and their records. You’ll see the record count, the time interval between records (in milliseconds, calculated as now-started / number of records), and the data bytes of the last packet seen. You can use ‘re clear’ to clear the records, and restart the counters for a new capture. You can also add a search filter to ‘re list’ to restrict the records shown.
For more advanced users, you can set the key bytes for particular IDs. The example given is for Tesla Roadster, where CAN ID 0x100 has a sub-command key in the first byte. So, ‘re key set 100 1’ tells the RE system to treat CAN 100 keys as 100:<databyte1>. Another example would be ‘re key set 100 1 2 3’ to cause the key to be 100:<B1>:<B2>:<B3>.
Remember you can use ‘can <canX> rx …’ to simulate reception of data and play with this.
Regards, Mark
P.S. I moved ‘reset’ to ‘module reset’, to make it a bit harder to mis-type when using ‘re’.
> On 24 Oct 2017, at 4:42 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> 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
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171024/0e85694e/attachment.htm>
More information about the OvmsDev
mailing list