[Ovmsdev] OBD/UDS Poller receiver rework
Soko
ovms at soko.cc
Fri Aug 28 21:28:26 HKT 2020
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200828/d9bab42a/attachment.htm>
More information about the OvmsDev
mailing list