[Ovmsdev] Polling keeps car awake (VW e-Up at least)

Soko ovms at soko.cc
Sun Aug 9 02:23:11 HKT 2020


OK, thanks heaps. Just to clarify: So if I know my session code I replace your 0xC0 with it, correct?
Is this session code global for all ECUs and static? The wiki link for UDS speaks about different sessions...
Does this one source code line also take care about the "tester present" message?

Your pacience with me is highly appreciated :)
Soko

On 8 August 2020 19:47:45 CEST, Michael Balzer <dexter at expeedo.de> wrote:
>Soko,
>
>https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_obd2.cpp#L64
>
>as simple as that. But you need to know the session code you need to
>use
>for the gateway. 0xC0 is in the manufacturer specific range.
>
>I would test the gateway behaviour using manual CAN commands, a script
>or a web plugin. That way you're much more flexible.
>
>Regards,
>Michael
>
>
>Am 08.08.20 um 19:09 schrieb Soko:
>> Hmmm... ok lets forget the 2nd log and talk about the first one.
>> It must somehow be related to OVMS though as the replies get in
>> immediately I swap the poll states. If I change the threshold from 5
>> secs to 3 or to 6 its always the same: once the poll state swaps the
>> replies come in. So it must be related to the poll stat switch. The
>> canlog shows all polls look the same... so the gateway must get
>> confused every time exactly when the threshold*4 is over?
>> Hmmm... or maybe the gateway gets confused after a certain number of
>> polls. So the threshold doesnt matter.
>> When I change the factor 4 to i.e. 6 I could validate this
>hypothesis.
>>
>> Havent had time for session implementation yet.
>> Is there a OVMS framework for a tester session? Or at least a vehicle
>> implementation which does it?
>>
>> On 8 August 2020 16:58:25 CEST, Michael Balzer <dexter at expeedo.de>
>wrote:
>>
>>     Soko,
>>
>>     lines 33 and 34 of your second log are due to the CAN TX buffer,
>>     which seems to have held back the frame until the bus became
>>     available.
>>
>>     Besides that, I don't see an RX in that log after switching the
>>     polling state. So I assume the RX in your first log also isn't
>>     related to the poll state switch.
>>
>>     There is an RX buffer, but that's just the internal queue of the
>>     vehicle CAN listener task. There is no delay on the processing
>>     unless you block the task somehow, for example by doing long term
>>     loops / communication in that context (which you shouldn't do).
>>
>>     You still don't send a session login or tester presence, so maybe
>>     the gateway is simply confused by the requests, runs into some
>>     timeout, then restarts… something like that.
>>
>>     Regards,
>>     Michael
>>
>>
>>     Am 08.08.20 um 13:20 schrieb Soko:
>>>
>>>     Soooo....
>>>
>>>     I've finally found time to test this again.
>>>
>>>     Basically the same behaviour as described below.
>>>
>>>     *VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log*
>>>     Car was locked initially. Unlocked the car before line 21
>(around
>>>     time mark 60.000). Locked around time mark 80.000. Car stayed
>>>     responsive until line 108 (time mark 100.000).
>>>     At line 130 (tm=116.814) I swap back to PollState=0. The poll
>for
>>>     PollState=0 gets an immediate reply (line 131-133) and therefore
>>>     I swap back to PollState=1.
>>>     The weird thing is that line 132 (which got a reply) is exactly
>>>     the same as 126 (or 118 or 110) which didn't get a reply!?!? So
>>>     the car has no idea of the poll states as the data is the same?
>>>     There must be some issue/bug/behavior inside OVMS (maybe even in
>>>     the hardware buffer) which gets triggered by a PollState change.
>>>     Or the canlog-monitor uses somehow a cache and doesn't show the
>>>     messages immediately.
>>>
>>>     *VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log*
>>>     Same as below. One thing I've noticed though: Car was locked
>>>     until line 32 (tm=63.814). Then I've unlocked it and the lines
>33
>>>     and 34 showed up immediately. This indicates a buffer/cache/etc.
>>>     issue with the canlog-monitor as well (imho).
>>>
>>>     Soko
>>>
>>>     On 03.08.2020 13:10, Michael Balzer wrote:
>>>>     Soko,
>>>>
>>>>     I don't see any obvious mistakes on a first check.
>>>>
>>>>     Please do the tests again with CAN monitoring, so we can see
>>>>     what's actually going on on the bus.
>>>>
>>>>     An OBD device normally logs into the device sending a UDS diag
>>>>     session command (0x10), then keeps that session alive by
>sending
>>>>     tester present (0x3E) evers 30-60 seconds. See the UDS
>>>>     documentation I sent you, or for an overview, see
>>>>     https://de.wikipedia.org/wiki/Unified_Diagnostic_Services
>>>>
>>>>     You should be able to get the session type and protocol by
>>>>     logging what your VCDS does on the bus.
>>>>
>>>>     Regards,
>>>>     Michael
>>>>
>>>>
>>>>     Am 03.08.20 um 06:19 schrieb Soko:
>>>>>
>>>>>     Mornin,
>>>>>
>>>>>     Source is here:
>>>>>    
>https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/tree/master/vehicle/OVMS.V3/components/vehicle_vweup/src
>>>>>
>>>>>     Attached are two logs. I haven't had the can-monitor active
>>>>>     unfortuantely..
>>>>>
>>>>>     *VWUP_OFF_TICKER_THRESHOLD 5 with 4 trys.log*
>>>>>     As the name says it polls every 5 seconds in PollState=1 and
>>>>>     swaps back to PollState=0 after 5*4=20 seconds.
>>>>>     Until line 35 you see the CAN errors as the vehicle is OFF.
>>>>>     Then I unlocked the car and in line 38 I get the first reply.
>>>>>     Around line 90 I locked the car again. It polls, but gets no
>>>>>     reply, _but not error either_ (?!).
>>>>>     Line 118 sets the PollState=0 and suddenly a response comes
>in.
>>>>>     So in Line 123 I set the PollState=1 again.
>>>>>     The the game starts again: Polls get send, no reply but no
>>>>>     error either. After 21 CarOffTickers I switch to PollState=0
>>>>>     and suddenly a reply comes in...
>>>>>
>>>>>     *VWUP_OFF_TICKER_THRESHOLD 10 with 4 trys.log
>>>>>     *Here I unlocked at line 57 and locked around line 100. After
>>>>>     that polls get send, no reply, _but errors happen_. And the
>car
>>>>>     is finally off.
>>>>>     Although I've tried the same thing later that day and the car
>>>>>     didn't even go to sleep with Threshold=30!?!? So the behavior
>>>>>     is not 100% reproducible (yet)...
>>>>>
>>>>>     @gateway throttling: In VCDS (which - hopefully - does only
>>>>>     polling too) I have a little number showing me the refresh
>>>>>     rates of the values. It indicates ~8 refreshes per second. So
>>>>>     with 1 second shouldn't be any throttling.
>>>>>
>>>>>     @OBD "tester": I have no clue what this is ;) So if the
>polling
>>>>>     framework doesn't do it, I don't do it. All I do is in the
>>>>>     obd_eup.* files.
>>>>>
>>>>>     Soko
>>>>>
>>>>>     On 02.08.2020 20:12, Michael Balzer wrote:
>>>>>>     Soko,
>>>>>>
>>>>>>     polling may keep the car awake, that's also an issue on the
>>>>>>     Kia e-Niro IIRC.
>>>>>>
>>>>>>     Changing the PollState can only affect the car indirectly via
>>>>>>     the changed polls. Maybe you could add your code & a log?
>>>>>>
>>>>>>     Regarding the poll replies stopping, is that also reflected
>in
>>>>>>     a CAN log? Maybe the OBD gateway throttles if it sees too
>many
>>>>>>     requests? (Hopefully not…)
>>>>>>
>>>>>>     If the gateway does throttling: do you login to the OBD as a
>>>>>>     "tester" and keep the session active by periodically sending
>>>>>>     the "tester present" frame?
>>>>>>
>>>>>>     Regards,
>>>>>>     Michael
>>>>>>
>>>>>>
>>>>>>     Am 02.08.20 um 19:30 schrieb Soko:
>>>>>>>
>>>>>>>     Heya again,
>>>>>>>
>>>>>>>     I'm trying to develop a detection for when the car is
>>>>>>>     off/locked but I'm encountering a weird phenomena:
>>>>>>>
>>>>>>>       * Car is shut down and locked
>>>>>>>       * OVMS connected
>>>>>>>       * CAN poll for voltage (only one poll value active) with
>30
>>>>>>>         secs fails with error (so far nothing weird)
>>>>>>>       * Unlock the car via car-key remote
>>>>>>>       * Poll succeeds and I'm switching from PollState=0 to
>>>>>>>         PollState=1 where I poll every 2 secs
>>>>>>>       * Lock the car via car-key remote
>>>>>>>       * _After 1 hour the polls still work and the car is
>active_
>>>>>>>
>>>>>>>     Is something like this known from other vehicles? So
>>>>>>>     basically my car never shuts down :(
>>>>>>>
>>>>>>>     Another secondary weird thing:
>>>>>>>     When increasing the time to 5 secs for PollState=1 the polls
>>>>>>>     get no reply and after 20 secs I swap back to PollState=0.
>>>>>>>     BUT the second the PollState changes the car replies
>again...
>>>>>>>     Even more weirdness: When PollState=1 time is 10 secs and I
>>>>>>>     swap back to Pollstate=0 after 40 secs the same thing
>>>>>>>     happens! Immediately I swap to PollState=0 the car replies
>again.
>>>>>>>     As if the PollState switching somehow wakes the car up??!
>>>>>>>
>>>>>>>     Any ideas?
>>>>>>>
>>>>>>>     Soko
>>>>>>>
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     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
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OvmsDev mailing list
>>>>>>     OvmsDev at lists.openvehicles.com
>>>>>>     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
>>>>
>>>>     _______________________________________________
>>>>     OvmsDev mailing list
>>>>     OvmsDev at lists.openvehicles.com
>>>>     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
>>
>>
>> _______________________________________________
>> 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/20200808/07628982/attachment.htm>


More information about the OvmsDev mailing list