[Ovmsdev] OBD/UDS Poller receiver rework

Sun Aug 30 15:05:58 HKT 2020

Merged into the master.

Derek's multi bus polling extension is still in the works and not
included in the merge.

Regards,
Michael

Am 28.08.20 um 21:15 schrieb Michael Balzer:
> Thanks to Soko (UpMiiGo tests) and Thomas (Smart rewrite & tests).
>
> The Smart code makes extensive use of polling, so we're probably good
> to go.
>
> If other vehicle maintainers would like to test before merging into
> the master, please let me know.
>
> Regards,
> Michael
>
>
> Am 28.08.20 um 15:28 schrieb Soko:
>>
>> Hi Michael,
>>
>> I can give you a :thumbup: from the UpMiiGo department. First test of
>> the changes (including a short drive) showed no issues. Neither with
>> the fast-polling nor with the multi-frame-processing with OBDIIEXTENDED.
>>
>> thanks
>>
>> Soko
>>
>> On 27.08.2020 22:00, Michael Balzer wrote:
>>> Everyone,
>>>
>>> I've just pushed the poller receiver changes I announced into the
>>> new "poller-rework" branch:
>>>
>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/0b306ad4f5e7a1eb63a471a11ec7f1a6d69d8647
>>>
>>> OBD/UDS Poller Receiver Rework:
>>>
>>>   - Fix race condition between CAN RX and PollerReceive
>>>   - Separation of ISO-TP & OBD/UDS layer meta data analysis
>>>   - Fix incomplete meta data validation
>>>   - Allow single/multi frame responses on all service types
>>>   - Validate multi frame response sequences
>>>   - Fix single frame payload lengths
>>>   - Fix type 0x22 first frame payload offset & overall length
>>>   - Add negative response code handling → IncomingPollError()
>>>   - Add response frame timing control → PollSetResponseSeparationTime()
>>>
>>> This rework has been on my list for some time before, as the
>>> previous solution had some general shortcomings, especially by it's
>>> hard coded coupling of the expected response transport form with the
>>> request type, which fails already on some type 0x01 requests.
>>>
>>> The major bug in the receiver that now triggered the rework was in
>>> the overall payload length calculation and the first frame payload
>>> passing of the type 0x22 (VEHICLE_POLL_TYPE_OBDIIEXTENDED) multi
>>> frame response handling. That up to now basically only turned up as
>>> a visible issue for the Smart ED, as all other vehicles either don't
>>> get multi frame responses on 0x22 queries or (like the Kia)
>>> generally discard the first frame and don't use the overall length
>>> at all.
>>>
>>> On the Smart ED, all handlers have been deliberately written
>>> assuming the bug was a feature -- all payload addressing is shifted
>>> by one byte. This needs to be rewritten now.
>>>
>>> All other vehicles should not see any difference and should not need
>>> to change any code. Except maybe in the UpMiiGo development, which
>>> isn't yet part of the master.
>>>
>>> Other bugs like the missing frame sequence validation and late
>>> response detection may have been the causes for some spurious and
>>> hard to track crashes and data errors. We should try to get this
>>> change tested short term on "edge", so we can see if this actually
>>> improves stability as I hope.
>>>
>>> As this is a major rework (mainly of the PollerReceive() method),
>>> audits and tests are very welcome. I can only test on the Twizy,
>>> which doesn't make much use of the poller yet.
>>>
>>> You can see what the new poller does by raising the log level for
>>> "vehicle" to debug. Example of some Twizy regular polling:
>>>
>>> D (136323) vehicle: PollerSend(1): send [type=10, pid=C0], expecting
>>> 743/763-763
>>> D (136343) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 10(C0) frm=0 len=0 off=0 rem=0
>>> V (136343) v-twizy: OBD2: ignored reply [10 c0]
>>> D (137323) vehicle: PollerSend(1): send [type=21, pid=81], expecting
>>> 743/763-763
>>> D (137343) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(81) frm=0 len=4 off=0 rem=15
>>> D (137373) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(81) frm=1 len=7 off=4 rem=8
>>> D (137403) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(81) frm=2 len=7 off=11 rem=1
>>> D (137423) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(81) frm=3 len=1 off=18 rem=0
>>> D (137433) v-twizy: OBD2: got VIN='XXXXXXXXXXXXXXXXX'
>>> D (138323) vehicle: PollerSend(1): send [type=21, pid=13], expecting
>>> 743/763-763
>>> D (138343) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=0 len=4 off=0 rem=106
>>> D (138373) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=1 len=7 off=4 rem=99
>>> D (138403) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=2 len=7 off=11 rem=92
>>> D (138423) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=3 len=7 off=18 rem=85
>>> D (138453) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=4 len=7 off=25 rem=78
>>> D (138483) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=5 len=7 off=32 rem=71
>>> D (138513) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=6 len=7 off=39 rem=64
>>> D (138543) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=7 len=7 off=46 rem=57
>>> D (138563) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=8 len=7 off=53 rem=50
>>> D (138593) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=9 len=7 off=60 rem=43
>>> D (138623) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=10 len=7 off=67 rem=36
>>> D (138653) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=11 len=7 off=74 rem=29
>>> D (138683) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=12 len=7 off=81 rem=22
>>> D (138703) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=13 len=7 off=88 rem=15
>>> D (138733) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=14 len=7 off=95 rem=8
>>> D (138763) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=15 len=7 off=102 rem=1
>>> D (138793) vehicle: PollerReceive[763]: process OBD/UDS response
>>> 21(13) frm=16 len=1 off=109 rem=0
>>> W (141323) v-twizy: OBD2 Cluster DTC NEW #01: 4/21 rev0 G1 INT MEM
>>> Ef|   @ 57871km 11kph SOC=60% BV=14V TC=0 IC=255
>>> W (141333) v-twizy: OBD2 Cluster DTC NEW #02: 4/1 rev0 G1 MEM|   @
>>> 57892km -1kph SOC=86% BV=14V TC=0 IC=255
>>> W (141343) v-twizy: OBD2 Cluster DTC NEW #03: 1/37 rev0 G1 INT MEM
>>> Ef|   @ 57892km -1kph SOC=86% BV=14V TC=0 IC=255
>>> W (141353) v-twizy: OBD2 Cluster DTC NEW #04: 3/59 rev0 G2 INT
>>> MEM|   @ 57926km 34kph SOC=78% BV=14V TC=0 IC=255
>>> W (141363) v-twizy: OBD2 Cluster DTC NEW #05: 4/40 rev0 G2 MEM Ef|  
>>> @ 57926km 35kph SOC=78% BV=14V TC=0 IC=255
>>> W (141373) v-twizy: OBD2 Cluster DTC NEW #06: 3/58 rev0 G2 INT
>>> MEM|   @ 58711km 41kph SOC=46% BV=14V TC=0 IC=255
>>>
>>> A manual multi frame poll:
>>>
>>> I (147723) webcommand: HttpCommandStream[0x3f8540f4]: 3801804 bytes
>>> free, executing: x o r bm 2104
>>> D (148323) vehicle: PollerSend(1): send [type=21, pid=4], expecting
>>> 79b/7bb-7bb
>>> D (148343) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=0 len=4 off=0 rem=70
>>> D (148353) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=1 len=7 off=4 rem=63
>>> D (148393) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=2 len=7 off=11 rem=56
>>> D (148433) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=3 len=7 off=18 rem=49
>>> D (148473) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=4 len=7 off=25 rem=42
>>> D (148513) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=5 len=7 off=32 rem=35
>>> D (148553) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=6 len=7 off=39 rem=28
>>> D (148593) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=7 len=7 off=46 rem=21
>>> D (148633) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=8 len=7 off=53 rem=14
>>> D (148673) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=9 len=7 off=60 rem=7
>>> D (148713) vehicle: PollerReceive[7BB]: process OBD/UDS response
>>> 21(4) frm=10 len=7 off=67 rem=0
>>> OVMS# x o r bm 2104
>>> Response:
>>> 08 cc 3c 08 d4 3c 08 cb 3c 08 d6 3c 08 ce 3c 08 | ..<..<..<..<..<.
>>> d1 3c 08 d2 3c ff ff ff ff ff ff ff ff ff ff ff | .<..<...........
>>> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................
>>> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................
>>> ff ff ff ff ff ff ff ff 3c 3c                   | ........<<     
>>>
>>> An example of the new error response handling:
>>>
>>> I (165023) webcommand: HttpCommandStream[0x3f8479f4]: 3791052 bytes
>>> free, executing: x o r bm 221405
>>> D (165323) vehicle: PollerSend(1): send [type=22, pid=1405],
>>> expecting 79b/7bb-7bb
>>> D (165343) vehicle: PollerReceive[7BB]: process OBD/UDS error
>>> 22(1405) code=11
>>> OVMS# x o r bm 221405
>>> ERROR: request failed with response error code 11
>>>
>>> Code 11 = "serviceNotSupported" (see ISO 14229 Annex A.1 for more codes)
>>>
>>>
>>> Feedback is welcome.
>>>
>>> Regards,
>>> Michael
>>>
>>> -- 
>>> 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/20200830/8645884b/attachment.htm>