[Ovmsdev] Please test: poller protocol extension

Tue Dec 22 23:50:02 HKT 2020

I've merged the rework into the master now.

Regards,
Michael

Am 17.12.20 um 09:21 schrieb Michael Balzer:
> 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
>
> _______________________________________________
> 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/20201222/4f55ea54/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/20201222/4f55ea54/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/20201222/4f55ea54/attachment-0001.sig>