[Ovmsdev] Detecting dead CAN bus - stop polling etc
Michael Balzer
dexter at expeedo.de
Tue Dec 15 04:40:08 HKT 2020
Steve,
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.
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 IncomingFrameCan1(). 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.
Some vehicles read the 12V level to determine if the vehicle is alive,
but that's more a last resort solution.
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.
Regards,
Michael
Am 14.12.20 um 15:04 schrieb Steve Davies:
> Hi,
>
> 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...
>
> OVMS logs:
>
> 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
>
> "txovr" - overrun? I guess? And I saw that txdelay climb from 0 to
> 30 after a reboot and as packets queued up for sending.
>
> 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.
>
> "can can1 status" is showing that interrupts are still being received
> but no packets.
>
> 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.
>
> So it seems important that I stop sending polls in this situation (and
> perhaps flush the outbound queue?).
>
> 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.
> Can I find an example as to how to do something like this?
>
> 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.
>
> 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.
>
> 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.
>
> Or is there a well established way to deal with this?
>
> Thanks,
> Steve
>
>
> On Sun, 13 Dec 2020 at 20:47, Michael Balzer <dexter at expeedo.de
> <mailto:dexter at expeedo.de>> wrote:
>
> 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 at expeedo.de
>> <mailto: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
>>> <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 <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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
>> <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>
>
> _______________________________________________
> 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/20201214/cd83e221/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/20201214/cd83e221/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/20201214/cd83e221/attachment-0001.sig>
More information about the OvmsDev
mailing list