<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Steve,<br>
<br>
as described before: there's an API method to change the poll state,
the poll state is intended for that purpose. Poll state 0 is
normally used for the "vehicle off" state, you need to pick an
appropriate method to determine the car state.<br>
<br>
CAN errors are normal if the vehicle switches off the CAN bus when
sleeping. If you want to avoid them, check for live data frames. To
handle live data frames, override <font face="monospace">IncomingFrameCan1()</font>.
That method will be called on all frames received (on can1). There
will most probably be a frame containing the vehicle state info. Use
the RE toolkit to identify it, if you don't have that info on the
net.<br>
<br>
Some vehicles read the 12V level to determine if the vehicle is
alive, but that's more a last resort solution.<br>
<br>
Aborting CAN transmissions and/or flushing the TX queue hasn't been
necessary up to now, but an API method for this can be added if you
need it.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 14.12.20 um 15:04 schrieb Steve
Davies:<br>
</div>
<blockquote type="cite"
cite="mid:CABFTEGViUOsmfhPC1dakQBp0RzVpP79LBTo=JG3G7BD+APa0gg@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/3e281f88d3c522df9f727bbc624680e5"
style="display:none !important" moz-do-not-send="true"
width="1" height="1">
<div>Hi,</div>
<div><br>
</div>
<div>I notice that my OVMS is sending poll requests but the OBD
on my car is apparently off / non-responsive (but the 12v
power on the OBD is obviously still there since the OVMS is
running...</div>
<div><br>
</div>
<div>OVMS logs:</div>
<div><br>
</div>
<div><font face="monospace">E (4672161) can: can1: intr=16491786
rxpkt=2794 txpkt=12 errflags=0x8040d9 rxerr=0 txerr=128
rxovr=0 txovr=107 txdelay=30 wdgreset=0 errreset=0<br>
</font></div>
<div><br>
</div>
<div>"txovr" - overrun? I guess? And I saw that txdelay climb
from 0 to 30 after a reboot and as packets queued up for
sending.</div>
<div><br>
I also see I'm not receiving any frames - the car normally
sends a steady stream of idle or keep-alives or something - so
from that I take it the BDC is off.</div>
<div><br>
"can can1 status" is showing that interrupts are still being
received but no packets.</div>
<div><br>
</div>
<div>When I did turn on the car it sent a stream of those
frames. OVMS I think dumped a backlog, then a message about
overflow started streaming by and then the OVMS rebooted.</div>
<div><br>
So it seems important that I stop sending polls in this
situation (and perhaps flush the outbound queue?).</div>
<div><br>
Perhaps I can just watch what's coming in and if I haven't
seen any packets arrive for some seconds I should stop polling
and if possible flush pending transmits. Can start again when
something turns up.<br>
Can I find an example as to how to do something like this?</div>
<div><br>
</div>
<div>I guess I could manipulate the poll state, but for me it
seems like this is actually a lower level thing since the
canbus is actually dead and no polls can be done.</div>
<div><br>
At the moment the blocked transmits seem to pile up in the
queue and we end up sending many at once when the link comes
back.<br>
<br>
</div>
<div>I found an argument "maxqueuewait" in the canbus calls
(like Write) but it defaults to 0 which I guess is forever.
So for me it does make sense that polls should have a
maxqueuewait that is less than the poll interval.<br>
</div>
<div><br>
</div>
<div>Or is there a well established way to deal with this?<br>
<br>
</div>
<div>Thanks,</div>
<div>Steve<br>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 13 Dec 2020 at
20:47, Michael Balzer <<a href="mailto:dexter@expeedo.de"
target="_blank" 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>
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>Am 13.12.20 um 19:15 schrieb Steve Davies:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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" target="_blank"
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">
<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:part6.46EFE876.1B4FD239@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></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>
</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>