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

Mon Dec 14 02:15:03 HKT 2020

Hi,

It seems to do what is expected - thanks, you are very fast!

D (706161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC],
expecting 6f107/607f1-607f1
V (706161) canlog-monitor: 1607882591.310736 1T11 6F1 07 03 22 dd bc 00 00
00

D (708161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68],
expecting 6f107/607f1-607f1
V (708161) canlog-monitor: 1607882593.310901 1T11 6F1 07 03 22 dd 68 00 00
00

But most times I don't get a reply.

But not never - here's an example that worked:

D (896161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC],
expecting 6f107/607f1-607f1
D (896211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DDBC) code=78
(pending)
D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC)
frm=0 len=2 off=0 rem=4
D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC)
frm=1 len=4 off=2 rem=0
D (896211) v-bmwi3: BMWI3: got SOC=86.7%
D (897161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68],
expecting 6f107/607f1-607f1
D (897211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DD68) code=78
(pending)
D (897211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DD68)
frm=0 len=2 off=0 rem=0
D (897211) v-bmwi3: BMWI3: got Volts=388.77V

The car is charging but otherwise "off" and locked.  Perhaps that has
something to do with the lack of replies.

Steve

On Sun, 13 Dec 2020 at 18:24, Michael Balzer <dexter at expeedo.de> wrote:

> 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
> 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
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201213/7dfb9e83/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/20201213/7dfb9e83/attachment-0003.png>