[Ovmsdev] OBD/UDS Poller receiver rework

Sat Sep 5 22:31:29 HKT 2020

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200905/08e5e6dd/attachment-0001.html>