[Ovmsdev] OBD/UDS Poller receiver rework
Soko
ovms at soko.cc
Sun Sep 6 03:36:19 HKT 2020
Thanks Michael, will give this a try and report back.
On 05.09.2020 16:31, Michael Balzer wrote:
> Everyone,
>
> the multi bus polling extension is now merged, and I have just added
> support for more service types, and requests w/o PIDs and/or with
> additional non-PID parameters.
>
> This is meant to support e.g. read & clear DTC operations (UDS service
> types 0x19 & 0x14). I have added some more UDS service types I think
> might be useful.
>
> Please test & report issues if any.
>
> To add parameter data to a poll entry, use the template shown in
> vehicle.c:
>
> // const OvmsVehicle::poll_pid_t twizy_poll_default[] = {
> // { TXID, RXID, VEHICLE_POLL_TYPE_READDTC, {.args={ PID, DATALEN,
> DATA1, … }}, { 0, 10, 60, 0 }, 0 },
> // …
>
> @Soko: this UDS service could be especially useful for you, if the
> e-Up supports this:
>
> #define VEHICLE_POLL_TYPE_READSCALING 0x24 // UDS:
> ReadScalingDataByIdentifier (16 bit PID)
>
> If you can get the scaling info for the "weird" Ah & kWh counters,
> that may give you an exact info on how to interpret these. On decoding
> the response see the ISO 14229 PDF, section 10.4 and annex C.
>
>
> Example for a DTC read:
>
> OVMS# xrt obd request bms 19020f
> Response:
> 4f 3b 2d 00 48 3a 2d 00 48 53 2d 60 48 54 2d 60 | O;-.H:-.HS-`HT-`
> 48 02 00 00 48 | H...H
>
> This is a standard DTC response, but the codes are mostly
> non-standard Renault or LG codes:
>
> 4f = StatusAvailabilityMask
>
> 3b 2d 00 = DTC #1: P3B2D = unknown: ISO/SAE reserved code
> … 48 = DTC Status: s.b. -- confirmedDTC +
> testNotCompletedThisOperationCycle
> 3a 2d 00 = DTC #2: P3A2D = unknown: ISO/SAE reserved code
> 53 2d 60 = DTC #3: C132D-60 = custom
> 54 2d 60 = DTC #4: C142D-60 = custom
> 02 00 00 = DTC #5: P0200 = "Injector Circuit/Open" (?)
>
> DTC High Byte:
> bit 7+6: 00 = 'P' (powertrain), 01 = 'C' (chassis), 10 = B (body),
> 11 = U (network/user)
> bit 5+4: digit 1: 01 = manufacturer controlled, 00/10/11 = ISO/SAE
> controlled
> bit 3-0: digit 2
>
> DTC Status Byte:
> bit # hex state description
> 0 0x01 testFailed DTC failed at the time of the request
> 1 0x02 testFailedThisOperationCycle DTC failed on the
> current operation cycle
> 2 0x04 pendingDTC DTC failed on the current or previous
> operation cycle
> 3 0x08 confirmedDTC DTC is confirmed at the time of the
> request
> 4 0x10 testNotCompletedSinceLastClear DTC test not
> completed since the last code clear
> 5 0x20 testFailedSinceLastClear DTC test failed at least
> once since last code clear
> 6 0x40 testNotCompletedThisOperationCycle DTC test not
> completed this operation cycle
> 7 0x80 warningIndicatorRequested Server is requesting
> warningIndicator to be active
>
>
> Regards,
> Michael
>
>
> Am 30.08.20 um 09:05 schrieb Michael Balzer:
>> 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
>>
>> _______________________________________________
>> 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/20200905/1f560020/attachment.htm>
More information about the OvmsDev
mailing list