[Ovmsdev] Help me get my first data item on the I3

Michael Balzer dexter at expeedo.de
Mon Dec 14 00:24:02 HKT 2020


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201213/135f8b70/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/20201213/135f8b70/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/20201213/135f8b70/attachment-0001.sig>


More information about the OvmsDev mailing list