Steve,

thanks for testing, glad it's working already. I'll do some more tests to be sure it doesn't affect normal polling, and merge into the master then. Probably not today though.

Regarding the missing replies, most vehicles need some sort of diagnostic session to know they need to react to requests. That's normally done with the request type VEHICLE_POLL_TYPE_OBDIISESSION (0x10) plus a session type. There are a few standard session types, but most vehicles use custom types you need to know.

Sessions expire, so the request needs to be sent e.g. once per minute. But be aware that may lead to the vehicle staying awake indefinitely, so it's usually a good idea to detect the vehicle state by something you can determine without the need of a session.

As your CAN statistics showed lots of received frames before you started transmitting some, it seems there are live data frames on the bus. I suggest looking for a vehicle status indicator in those frames. The RE toolkit is good for this.

Regards,
Michael


Am 13.12.20 um 19:15 schrieb Steve Davies:
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@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@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@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@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@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