[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.htm>


More information about the OvmsDev mailing list