[Ovmsdev] Please test: poller protocol extension

Wed Dec 23 02:22:17 HKT 2020

Thanks, I’ll resync my branch.

Steve

On Tue, 22 Dec 2020 at 17:50, Michael Balzer <dexter at expeedo.de> wrote:

> 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> 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: image.png]
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-- 
Stephen Davies
Chief Technical Officer, Telviva (PTY) Ltd (previously Connection Telecom
(PTY) Ltd
Direct: 0878200262 / Reception: 0878200200
Written on the go, please excuse brevity/typos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201222/3c10311c/attachment-0003.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/3c10311c/attachment-0003.png>