[Ovmsdev] OBD/UDS Poller receiver rework

Michael Balzer dexter at expeedo.de
Sun Sep 6 14:50:54 HKT 2020 

Thomas found a bug in the new poll response identification. Fix is
pushed, please update.

Regards,
Michael


Am 05.09.20 um 21:36 schrieb Soko:
>
> 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
>
> _______________________________________________
> 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/20200906/f2fcb6f3/attachment.htm>

More information about the OvmsDev mailing list