[Ovmsdev] Polling keeps car awake (VW e-Up at least)
Michael Balzer
dexter at expeedo.de
Sun Aug 9 04:12:17 HKT 2020
Am 08.08.20 um 20:23 schrieb Soko:
> OK, thanks heaps. Just to clarify: So if I know my session code I
> replace your 0xC0 with it, correct?
Yes.
> Is this session code global for all ECUs and static? The wiki link for
> UDS speaks about different sessions...
Yes and no. There are standard codes, but they need not apply. See the
PDF I sent you on diagnostic sessions.
> Does this one source code line also take care about the "tester
> present" message?
Yes. You either do a login and keep that active by sending "tester
presence", or repeat the login. See the PDF I sent you on tester presence.
Regards,
Michael
>
> 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
>
>
> _______________________________________________
> 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/4525112a/attachment.htm>
More information about the OvmsDev
mailing list