[Ovmsdev] Please test: poller protocol extension

Thu Dec 17 16:21:53 HKT 2020

Everyone,

in case you missed the BMW i3 thread: I've added support for the ISO-TP 
"extended addressing scheme" to our poller (see below for details).

The extension should not affect standard polling, but I had to touch all 
polling lists to add the protocol tag.

I've tested the change with my car (Twizy) but would like to get some 
test results for other vehicle modules before merging into the master.

Please pull, checkout and build from the "isotp-extadr" branch to test 
this with your car, and report your results.

Thanks!

Regards,
Michael

Am 13.12.20 um 17:24 schrieb Michael Balzer:
> Steve,
>
> please try the poller rework I just pushed to the new "isotp-extadr" 
> branch.
>
> These poll_pid_t records would define the example shown in the ELM327 
> manual:
>
>     { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, {  20, 
> 0, 0 }, 0, ISOTP_EXTADR },
>     { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP,   0xa2, { 30, 0, 
> 0 }, 0, ISOTP_EXTADR },
>
> I've used these + matching faked rx frames to verify the implementation.
>
> Your SOC poll should look like this:
>
>     { 0x6F107, 0x607F1, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, {  0, 
> 10, 60 }, 0, ISOTP_EXTADR },
>
> …and your IncomingPollReply() should receive the reply with pid == 
> 0x607F1.
>
> Please report your results.
>
> Thanks,
> Michael
>
>
> Am 13.12.20 um 11:33 schrieb Michael Balzer:
>> Steve,
>>
>> sorry, totally missed that. That's very unusual, haven't seen that 
>> before. I first thought maybe that's using CAN extended frame mode, 
>> but that's a totally different thing: it seems the i3 uses the 
>> *ISO-TP extended addressing scheme*.
>>
>> Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2
>>
>>> ISO-TP can be operated with its own addressing as so-called/Extended 
>>> Addressing/or without address using only the CAN ID 
>>> (so-called/Normal Addressing/). Extended addressing uses the first 
>>> data byte of each frame as an additional element of the address, 
>>> reducing the application payload by one byte.
>>
>> So it's standard frames, with just an additional byte inserted before 
>> the protocol, used to extend the CAN ID.
>>
>> The OVMS poller doesn't support this yet.
>>
>> But it shouldn't be hard to add support for this, as it basically 
>> just fills the first frame byte from the lower 8 bits of the TX and 
>> RX IDs, reduces the payload size by one byte and shifts the offsets 
>> by one. PollerSend() and PollerReceive() need to be extended for 
>> this, and poll_pid_t needs to be extended by an addressing scheme tag.
>>
>> I'll have a look. Tell me if you'd like to take care of this.
>>
>> Regards,
>> Michael
>>
>>
>> Am 13.12.20 um 09:58 schrieb Steve Davies:
>>>
>>>
>>> On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter at expeedo.de 
>>> <mailto:dexter at expeedo.de>> wrote:
>>>
>>>     with log level verbose for canlog, you can simply activate CAN
>>>     logging via:
>>>
>>>     can log start monitor crtd
>>>
>>>     …that will log all frames, if that's too much, add a filter like
>>>     this:
>>>
>>>     can log start monitor crtd 600-7ff
>>>
>>>
>>>
>>> To see what was happening I had to "log level verbose canlog-monitor"
>>>
>>> I see this being transmitted:
>>>
>>> V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 
>>> 00 00 00 00
>>>
>>> There is no reply.
>>>
>>> The other app I looked at does this on the LM327 as setup before 
>>> sending the request:
>>>
>>> 2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07
>>> 2020-11-15 10:34:35.127 <-- OK⏎⏎>
>>>
>>> Looking at the LM327 data sheet this configures an "extended 
>>> address" which is sent after the 0x6F1
>>>
>>> I'm not sure if that 0x03 in what OVMS is sending is that byte, and 
>>> I need to somehow replace it wih 07, or if I have to get another 
>>> inserted?
>>>
>>> Perhaps this is old hat to those more experienced than me.
>>>
>>> From the data sheet and the trace it seems I'm also responsible to 
>>> customise the flow control messages :-
>>>
>>>
>>> 2020-11-15 10:34:35.129 --> ATFCSH6F1⏎ Flow control header
>>> 2020-11-15 10:34:35.141 <-- OK⏎⏎>
>>> 2020-11-15 10:34:35.143 --> ATFCSD07300800⏎ Flow control data
>>> 2020-11-15 10:34:35.156 <-- OK⏎⏎>
>>> 2020-11-15 10:34:35.157 --> ATFCSM1⏎ Flow control mode
>>> 2020-11-15 10:34:35.170 <-- OK⏎⏎>
>>>
>>> I think that comes down to a flow control being "06 F1 07 30 08 00"
>>>
>>> Here's the page in the LM327 to help understand what it does:
>>>
>>> image.png
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/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.openvehicles.com
>> http://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201217/495e4f16/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 316302 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201217/495e4f16/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201217/495e4f16/attachment-0001.sig>