[Ovmsdev] Polling keeps car awake (VW e-Up at least)
Soko
ovms at soko.cc
Sun Aug 9 20:06:47 HKT 2020
Hi,
Last time I investigated this as I will use the 12V to determine if the
car is running (>13.5V means on. Also true for charging). So out of
curiosity and so we have my tests in one email combined. In addition I
felt I've mixed up some tests & results so I wanted to do it one more
time to make sure...
I've tried the same source again. Just polling the HV-Battery voltage.
In Pollstate=0 every 30 seconds. Once a Poll gets an reply I swap to
Pollstate=1 with polling every "threshold" seconds. Tries=X mean how
many counts do I wait until I swap the PollState back to 0. Tries=4
means 4 times the threshold.
The test workflow is:
1. Car is locked and shut down (no fan noise heard)
2. Wait until I get an CAN error
3. Unlock car
4. Wait until I get the first Poll reply
5. Lock car
There are 3 possible outcomes after step 5:
1. The car stays on, fan noise heard, it replies to every poll, never
swap back to PollState=0
2. The car stays on, fan noise heard, it doesn't reply to the polls,
swap back to PollState=0 happens, but immediately after I get one reply
3. The car shuts down, no fan noise, CAN errors happen for polls, swap
back to PollState=0 happens
I really don't understand whats going on here, but here is the table.
Columns=tries, Rows=threshold, cell=outcome
threshold/tries 3 4 5 6 8
3
1
4
1
5 3 2 2 2 2
6
3
7
3
10
3
What I really don't get is why with shorter tries the car shuts off (as
it should) and longer tries keep it awake
so long
Soko
On 08.08.2020 16:58, Michael Balzer 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200809/3b66958a/attachment-0001.html>
More information about the OvmsDev
mailing list