[Ovmsdev] Polling keeps car awake (VW e-Up at least)
Michael Balzer
dexter at expeedo.de
Sun Aug 9 01:47:45 HKT 2020
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/d8e96384/attachment.htm>
More information about the OvmsDev
mailing list