<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Steve,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 13.12.20 um 19:15 schrieb Steve
Davies:<br>
</div>
<blockquote type="cite"
cite="mid:CABFTEGXpS_+kqbHxK=ZqJQ26mzQ=oJrcAaFKNJ2QtDbKxWc=WQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><img
src="https://api2.activeinboxhq.com/1.0/anon/rr/3ceb4a1e1676dbea326796182816d69e"
style="display:none !important" moz-do-not-send="true"
width="1" height="1">Hi,
<div><br>
</div>
<div>It seems to do what is expected - thanks, you are very
fast!</div>
<div><br>
</div>
<div><font face="monospace">D (706161) vehicle: PollerSend(1):
send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1<br>
V (706161) canlog-monitor: 1607882591.310736 1T11 6F1 07 03
22 dd bc 00 00 00<br>
</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">D (708161) vehicle: PollerSend(1):
send [bus=0, type=22, pid=DD68], expecting 6f107/607f1-607f1<br>
V (708161) canlog-monitor: 1607882593.310901 1T11 6F1 07 03
22 dd 68 00 00 00<br>
</font></div>
<div><br>
</div>
<div>But most times I don't get a reply.</div>
<div><br>
</div>
<div>But not never - here's an example that worked:</div>
<div><br>
</div>
<div><font face="monospace">D (896161) vehicle: PollerSend(1):
send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1<br>
D (896211) vehicle: PollerReceive[607F1]: got OBD/UDS info
22(DDBC) code=78 (pending)<br>
D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS
response 22(DDBC) frm=0 len=2 off=0 rem=4<br>
D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS
response 22(DDBC) frm=1 len=4 off=2 rem=0<br>
D (896211) v-bmwi3: BMWI3: got SOC=86.7%<br>
D (897161) vehicle: PollerSend(1): send [bus=0, type=22,
pid=DD68], expecting 6f107/607f1-607f1<br>
D (897211) vehicle: PollerReceive[607F1]: got OBD/UDS info
22(DD68) code=78 (pending)<br>
D (897211) vehicle: PollerReceive[607F1]: process OBD/UDS
response 22(DD68) frm=0 len=2 off=0 rem=0<br>
D (897211) v-bmwi3: BMWI3: got Volts=388.77V<br>
</font></div>
<div><br>
</div>
<div>The car is charging but otherwise "off" and locked.
Perhaps that has something to do with the lack of replies.</div>
<div><br>
</div>
<div>Steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 13 Dec 2020 at 18:24,
Michael Balzer <<a href="mailto:dexter@expeedo.de"
moz-do-not-send="true">dexter@expeedo.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> Steve,<br>
<br>
please try the poller rework I just pushed to the new
"isotp-extadr" branch.<br>
<br>
These <font face="monospace">poll_pid_t</font> records
would define the example shown in the ELM327 manual:<br>
<br>
<font face="monospace"> { 0x7b004, 0x7c0f1,
VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, { 20, 0, 0 }, 0,
ISOTP_EXTADR },<br>
{ 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP,
0xa2, { 30, 0, 0 }, 0, ISOTP_EXTADR },</font><br>
<br>
I've used these + matching faked rx frames to verify the
implementation.<br>
<br>
Your SOC poll should look like this:<br>
<br>
<font face="monospace"> { 0x6F107, 0x607F1,
VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 0, 10, 60 },
0, ISOTP_EXTADR },<br>
</font><br>
…and your <font face="monospace">IncomingPollReply()</font>
should receive the reply with <font face="monospace">pid ==
0x607F1</font>.<br>
<br>
Please report your results.<br>
<br>
Thanks,<br>
Michael<br>
<br>
<br>
<div>Am 13.12.20 um 11:33 schrieb Michael Balzer:<br>
</div>
<blockquote type="cite"> Steve,<br>
<br>
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 <b>ISO-TP extended addressing
scheme</b>.<br>
<br>
Quoting from Wikipedia: <a
href="https://en.wikipedia.org/wiki/ISO_15765-2"
target="_blank" moz-do-not-send="true">https://en.wikipedia.org/wiki/ISO_15765-2</a><br>
<br>
<blockquote type="cite"><span
style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">ISO-TP
can be operated with its own addressing as so-called<span> </span></span><i
style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Extended
Addressing</i><span
style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>or
without address using only the CAN ID (so-called<span> </span></span><i
style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Normal
Addressing</i><span
style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">).
Extended addressing uses the first data byte of each
frame as an additional element of the address,
reducing the application payload by one byte.</span></blockquote>
<br>
So it's standard frames, with just an additional byte
inserted before the protocol, used to extend the CAN ID.<br>
<br>
The OVMS poller doesn't support this yet.<br>
<br>
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.<br>
<br>
I'll have a look. Tell me if you'd like to take care of
this.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 13.12.20 um 09:58 schrieb Steve Davies:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><img
src="https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b"
style="display: none;" moz-do-not-send="true"
width="1" height="1"><img
src="https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b"
style="display: none;" moz-do-not-send="true"
width="1" height="1"><img
src="https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b"
style="display: none;" moz-do-not-send="true"
width="1" height="1"><img
src="https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b"
style="display: none;" moz-do-not-send="true"
width="1" height="1"><img
src="https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b"
style="display: none;" moz-do-not-send="true"
width="1" height="1">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 12 Dec
2020 at 17:28, Michael Balzer <<a
href="mailto:dexter@expeedo.de" target="_blank"
moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>with log level verbose for canlog, you can
simply activate CAN logging via:<br>
<br>
<font face="monospace">can log start monitor
crtd</font><br>
<br>
…that will log all frames, if that's too much,
add a filter like this:<br>
<br>
<font face="monospace">can log start monitor
crtd 600-7ff</font></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>To see what was happening I had to "log level
verbose canlog-monitor"</div>
<div><br>
</div>
<div>I see this being transmitted:</div>
<div><br>
</div>
<div>V (62436161) canlog-monitor: 1607847148.142477
1T11 6F1 03 22 dd bc 00 00 00 00<br>
</div>
<div><br>
</div>
<div>There is no reply.</div>
<div><br>
</div>
<div>The other app I looked at does this on the
LM327 as setup before sending the request:</div>
<div><br>
</div>
<div><font face="monospace">2020-11-15 10:34:35.115
--> ATCEA07⏎ "extended address" 0x07<br>
2020-11-15 10:34:35.127 <-- OK⏎⏎><br>
</font></div>
<div><br>
</div>
<div>Looking at the LM327 data sheet this configures
an "extended address" which is sent after the
0x6F1 </div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Perhaps this is old hat to those more
experienced than me.</div>
<div><br>
</div>
<div>From the data sheet and the trace it seems I'm
also responsible to customise the flow control
messages :-</div>
<div><br>
</div>
<div><br>
</div>
<div><font face="monospace">2020-11-15 10:34:35.129
--> ATFCSH6F1⏎ Flow control header<br>
2020-11-15 10:34:35.141 <-- OK⏎⏎><br>
2020-11-15 10:34:35.143 --> ATFCSD07300800⏎
Flow control data<br>
2020-11-15 10:34:35.156 <-- OK⏎⏎><br>
2020-11-15 10:34:35.157 --> ATFCSM1⏎ Flow
control mode<br>
2020-11-15 10:34:35.170 <-- OK⏎⏎><br>
</font></div>
<div><br>
</div>
<div>I think that comes down to a flow control being
"06 F1 07 30 08 00"</div>
<div><br>
</div>
<div>Here's the page in the LM327 to help understand
what it does:</div>
<div><br>
</div>
<div><img
src="cid:part10.E6887E42.2803DCAC@expeedo.de"
alt="image.png" style="margin-right: 25px;"
class=""><br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>