OBD/UDS Poller receiver rework
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/0b30... 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
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/0b30...
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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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/0b30...
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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
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/0b30...
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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@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
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/0b30...
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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@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@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
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/0b30...
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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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/0b30...
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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
I see some strange behaviour on the T26A e-Up with the new code. I don't get all values from the bus after a fresh reboot (mostly no VIN, sometimes also no SOC)). I have to sent a wakeup call first: I (160137) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,- 1,0,0,0,0,0,0,0,0.00,0.00,0I (160137) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,159,0,0,0,0,11.83,0,12.6,0,0,0,0I (160147) ovms- server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf v3.3.2-881-g22d636b7b Sep 6 2020 09:04:40),,18,1,VWUP.T26,CWLANI (169127) webserver: HTTP POST /api/executeI (169147) webcommand: HttpCommandStream[0x3f852fcc]: 3964692 bytes free, executing: wakeupI (171147) v-vweup-t26: Sent Wakeup Command - stage 1I (171267) v-vweup- t26: Sent Wakeup Command - stage 2OVMS# wakeupVehicle has been wokenI (193527) v-vweup-t26: Comfort CAN calls for sleepI (221137) ovms- server-v2: Send MP-0 S100.0,K,0,0,stopped,standard,260,241,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0 ,-1,0,0,0,0,0,0,0,0.00,0.00,0I (221147) ovms-server-v2: Send MP-0 D0,0,5,16,0,0,0,36030,0,220,25,0,1,1,11.47,0,12.6,0,0,0,0I (221147) ovms-server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf v3.3.2-881-g22d636b7b Sep 6 2020 09:04:40),xxxxxxxxxxxxxxxx,18,1,VWUP.T26,CWLAN I did not change my code and have never seen this before. Perhaps a problem with the new polling code? Regards Chris
Chris, did you pull the fix already? Also, please enable at least debug logging on the "vehicle" component when reporting issues with the poller. Thanks, Michael Am 06.09.20 um 09:39 schrieb Chris van der Meijden:
I see some strange behaviour on the T26A e-Up with the new code. I don't get all values from the bus after a fresh reboot (mostly no VIN, sometimes also no SOC)). I have to sent a wakeup call first:
I (160137) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (160137) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,159,0,0,0,0,11.83,0,12.6,0,0,0,0 I (160147) ovms-server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf v3.3.2-881-g22d636b7b Sep 6 2020 09:04:40),,18,1,VWUP.T26,CWLAN I (169127) webserver: HTTP POST /api/execute I (169147) webcommand: HttpCommandStream[0x3f852fcc]: 3964692 bytes free, executing: wakeup I (171147) v-vweup-t26: Sent Wakeup Command - stage 1 I (171267) v-vweup-t26: Sent Wakeup Command - stage 2 OVMS# wakeup Vehicle has been woken I (193527) v-vweup-t26: Comfort CAN calls for sleep I (221137) ovms-server-v2: Send MP-0 S100.0,K,0,0,stopped,standard,260,241,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (221147) ovms-server-v2: Send MP-0 D0,0,5,16,0,0,0,36030,0,220,25,0,1,1,11.47,0,12.6,0,0,0,0 I (221147) ovms-server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf v3.3.2-881-g22d636b7b Sep 6 2020 09:04:40),xxxxxxxxxxxxxxxx,18,1,VWUP.T26,CWLAN
I did not change my code and have never seen this before. Perhaps a problem with the new polling code?
Regards
Chris
_______________________________________________ OvmsDev mailing list OvmsDev@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
On a second thought: you don't use the poller at all in the current T26A e-Up code. Regards, Michael Am 06.09.20 um 09:57 schrieb Michael Balzer:
Chris,
did you pull the fix already?
Also, please enable at least debug logging on the "vehicle" component when reporting issues with the poller.
Thanks, Michael
Am 06.09.20 um 09:39 schrieb Chris van der Meijden:
I see some strange behaviour on the T26A e-Up with the new code. I don't get all values from the bus after a fresh reboot (mostly no VIN, sometimes also no SOC)). I have to sent a wakeup call first:
I (160137) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (160137) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,159,0,0,0,0,11.83,0,12.6,0,0,0,0 I (160147) ovms-server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf v3.3.2-881-g22d636b7b Sep 6 2020 09:04:40),,18,1,VWUP.T26,CWLAN I (169127) webserver: HTTP POST /api/execute I (169147) webcommand: HttpCommandStream[0x3f852fcc]: 3964692 bytes free, executing: wakeup I (171147) v-vweup-t26: Sent Wakeup Command - stage 1 I (171267) v-vweup-t26: Sent Wakeup Command - stage 2 OVMS# wakeup Vehicle has been woken I (193527) v-vweup-t26: Comfort CAN calls for sleep I (221137) ovms-server-v2: Send MP-0 S100.0,K,0,0,stopped,standard,260,241,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (221147) ovms-server-v2: Send MP-0 D0,0,5,16,0,0,0,36030,0,220,25,0,1,1,11.47,0,12.6,0,0,0,0 I (221147) ovms-server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf v3.3.2-881-g22d636b7b Sep 6 2020 09:04:40),xxxxxxxxxxxxxxxx,18,1,VWUP.T26,CWLAN
I did not change my code and have never seen this before. Perhaps a problem with the new polling code?
Regards
Chris
_______________________________________________ OvmsDev mailing list OvmsDev@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@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
Yes I applied the fix. The new behaviour started with the fix. And also yes, I don't use the poller :-) Greetinx Chris
Hey guys, I'm wondering a while now how the firmware release process is working in OVMS. I have found in the OVMS settings that I can choose "main", "eap" or "edge" as the update channel... How does this relate to the github branches? https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main" channel? VWUP.OBD is not listed there... but in the user docs it is already: https://docs.openvehicles.com/en/latest/components/vehicle_vweup_obd/docs/in... changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th... Not that all the details here need to be perfectly matching. Was just wondering about a coarse grained info about the process... thanks Soko
Soko, From the original announcement on this: To try to avoid a repeat of the 3.1.007 issue with OTA updates, I’ve set things up as below: edge: Bleeding edge developer, built automatically each night with 3.1.XXX-N-HHHHHH style versioning eap: Early Access Program pre-releases, usually with 3.1.XXX style versioning main: Stable releases that have completed testing in EAP, with 3.1.XXX style versioning. Before moving things edge -> eap, I’ll have a checklist of regression tests to run (including ota update). Other functional problems should have been picked up by developer cars while in ‘edge’ release. I suggest to leave a particular build in ‘edge’ for a week, to make sure no problems reported to those early real-world testers, before moving to ‘main’. I have an automated nightly build script that runs at 4pm UTC (midnight HKT). That pulls the latest masters for esp-idf and ovms firmware, then builds as appropriate. If there is something to build (something in git changed), it does it automatically and produces an email summary like this: Subject: OVMS Nightly Firmware Build 3.1.008-13-g272697e 3.1.008-13-g272697e Thu Jun 28 00:57:19 UTC 2018 Automated build (markhk8) Total sizes: DRAM .data size: 17116 bytes DRAM .bss size: 33536 bytes Used static DRAM: 50652 bytes ( 130084 available, 28.0% used) Used static IRAM: 102096 bytes ( 28976 available, 77.9% used) Flash code: 1279002 bytes Flash rodata: 598168 bytes Total image size:~1996382 bytes (.bin may be padded larger) * 272697e (HEAD, origin/master, origin/HEAD, master) Twizy: no sufficient level info on charge done * 8497d9f Web dashboard: range display min/max exchanged * 5d8f96d Webserver: fix u64 alignment * 5363ab8 TeslaRoadster: Vehicle cooldown command and implementation * bf3b0d5 TeslaRoadster: Digital Speedo implementation * d0221bf TeslaRoadster: Refuse to lock a car that is ON * 7179600 Update project status files * b3bef78 TeslaRoadster: Digital Speedo implementation * cfbd297 TeslaRoadster: Vehicle cooldown command and implementation * ec4bc37 Add VehicleModeKey helper function At the moment, that summary comes to me. Is there any use sending it to the ovmsdev mailing list? With developer cars set to ‘edge’, and automatically updating each night, hopefully with this three stage process we can pickup on problems before they hit the main stable trunk. Regards, Mark. This is all from ‘master’ and unrelated to braches (which are experimental and usually hand-built).
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main” channel
Usually, unless we explicitly say ’to early access program’.
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th…
The v3.2.015 code was fixed and tagged on 2nd Sep, then release to EAP. It went to MAIN on 8th Sep (after EAP testing). Regards, Mark
On 8 Sep 2020, at 3:47 PM, Soko <ovms@soko.cc> wrote:
Hey guys,
I'm wondering a while now how the firmware release process is working in OVMS.
I have found in the OVMS settings that I can choose "main", "eap" or "edge" as the update channel...
How does this relate to the github branches?
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main" channel? VWUP.OBD is not listed there... but in the user docs it is already: https://docs.openvehicles.com/en/latest/components/vehicle_vweup_obd/docs/in...
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th...
Not that all the details here need to be perfectly matching. Was just wondering about a coarse grained info about the process...
thanks
Soko
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Thanks Mark, got it! Just to be complete: The user docs are a live view of the master branch, correct? Soko On 08.09.2020 09:58, Mark Webb-Johnson wrote:
Soko,
From the original announcement on this:
To try to avoid a repeat of the 3.1.007 issue with OTA updates, I’ve set things up as below:
* edge: Bleeding edge developer, built automatically each night with 3.1.XXX-N-HHHHHH style versioning * eap: Early Access Program pre-releases, usually with 3.1.XXX style versioning * main: Stable releases that have completed testing in EAP, with 3.1.XXX style versioning.
Before moving things edge -> eap, I’ll have a checklist of regression tests to run (including ota update). Other functional problems should have been picked up by developer cars while in ‘edge’ release. I suggest to leave a particular build in ‘edge’ for a week, to make sure no problems reported to those early real-world testers, before moving to ‘main’.
I have an automated nightly build script that runs at 4pm UTC (midnight HKT). That pulls the latest masters for esp-idf and ovms firmware, then builds as appropriate. If there is something to build (something in git changed), it does it automatically and produces an email summary like this:
Subject: OVMS Nightly Firmware Build 3.1.008-13-g272697e
3.1.008-13-g272697e Thu Jun 28 00:57:19 UTC 2018 Automated build (markhk8)
Total sizes: DRAM .data size: 17116 bytes DRAM .bss size: 33536 bytes Used static DRAM: 50652 bytes ( 130084 available, 28.0% used) Used static IRAM: 102096 bytes ( 28976 available, 77.9% used) Flash code: 1279002 bytes Flash rodata: 598168 bytes Total image size:~1996382 bytes (.bin may be padded larger)
* 272697e (HEAD, origin/master, origin/HEAD, master) Twizy: no sufficient level info on charge done * 8497d9f Web dashboard: range display min/max exchanged * 5d8f96d Webserver: fix u64 alignment * 5363ab8 TeslaRoadster: Vehicle cooldown command and implementation * bf3b0d5 TeslaRoadster: Digital Speedo implementation * d0221bf TeslaRoadster: Refuse to lock a car that is ON * 7179600 Update project status files * b3bef78 TeslaRoadster: Digital Speedo implementation * cfbd297 TeslaRoadster: Vehicle cooldown command and implementation * ec4bc37 Add VehicleModeKey helper function
At the moment, that summary comes to me. Is there any use sending it to the ovmsdev mailing list?
With developer cars set to ‘edge’, and automatically updating each night, hopefully with this three stage process we can pickup on problems before they hit the main stable trunk.
Regards, Mark.
This is all from ‘master’ and unrelated to braches (which are experimental and usually hand-built).
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main” channel
Usually, unless we explicitly say ’to early access program’.
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th…
The v3.2.015 code was fixed and tagged on 2nd Sep, then release to EAP.
It went to MAIN on 8th Sep (after EAP testing).
Regards, Mark
On 8 Sep 2020, at 3:47 PM, Soko <ovms@soko.cc <mailto:ovms@soko.cc>> wrote:
Hey guys,
I'm wondering a while now how the firmware release process is working in OVMS.
I have found in the OVMS settings that I can choose "main", "eap" or "edge" as the update channel...
How does this relate to the github branches?
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main" channel? VWUP.OBD is not listed there... but in the user docs it is already: https://docs.openvehicles.com/en/latest/components/vehicle_vweup_obd/docs/in...
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th...
Not that all the details here need to be perfectly matching. Was just wondering about a coarse grained info about the process...
thanks
Soko
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Yes. They are built from a GitHub trigger.
On 8 Sep 2020, at 5:15 PM, Soko <ovms@soko.cc> wrote:
Thanks Mark, got it!
Just to be complete: The user docs are a live view of the master branch, correct?
Soko
On 08.09.2020 09:58, Mark Webb-Johnson wrote:
Soko,
From the original announcement on this:
To try to avoid a repeat of the 3.1.007 issue with OTA updates, I’ve set things up as below:
edge: Bleeding edge developer, built automatically each night with 3.1.XXX-N-HHHHHH style versioning eap: Early Access Program pre-releases, usually with 3.1.XXX style versioning main: Stable releases that have completed testing in EAP, with 3.1.XXX style versioning.
Before moving things edge -> eap, I’ll have a checklist of regression tests to run (including ota update). Other functional problems should have been picked up by developer cars while in ‘edge’ release. I suggest to leave a particular build in ‘edge’ for a week, to make sure no problems reported to those early real-world testers, before moving to ‘main’.
I have an automated nightly build script that runs at 4pm UTC (midnight HKT). That pulls the latest masters for esp-idf and ovms firmware, then builds as appropriate. If there is something to build (something in git changed), it does it automatically and produces an email summary like this:
Subject: OVMS Nightly Firmware Build 3.1.008-13-g272697e
3.1.008-13-g272697e Thu Jun 28 00:57:19 UTC 2018 Automated build (markhk8)
Total sizes: DRAM .data size: 17116 bytes DRAM .bss size: 33536 bytes Used static DRAM: 50652 bytes ( 130084 available, 28.0% used) Used static IRAM: 102096 bytes ( 28976 available, 77.9% used) Flash code: 1279002 bytes Flash rodata: 598168 bytes Total image size:~1996382 bytes (.bin may be padded larger)
* 272697e (HEAD, origin/master, origin/HEAD, master) Twizy: no sufficient level info on charge done * 8497d9f Web dashboard: range display min/max exchanged * 5d8f96d Webserver: fix u64 alignment * 5363ab8 TeslaRoadster: Vehicle cooldown command and implementation * bf3b0d5 TeslaRoadster: Digital Speedo implementation * d0221bf TeslaRoadster: Refuse to lock a car that is ON * 7179600 Update project status files * b3bef78 TeslaRoadster: Digital Speedo implementation * cfbd297 TeslaRoadster: Vehicle cooldown command and implementation * ec4bc37 Add VehicleModeKey helper function
At the moment, that summary comes to me. Is there any use sending it to the ovmsdev mailing list?
With developer cars set to ‘edge’, and automatically updating each night, hopefully with this three stage process we can pickup on problems before they hit the main stable trunk.
Regards, Mark.
This is all from ‘master’ and unrelated to braches (which are experimental and usually hand-built).
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main” channel
Usually, unless we explicitly say ’to early access program’.
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th…
The v3.2.015 code was fixed and tagged on 2nd Sep, then release to EAP.
It went to MAIN on 8th Sep (after EAP testing).
Regards, Mark
On 8 Sep 2020, at 3:47 PM, Soko <ovms@soko.cc> wrote:
Hey guys,
I'm wondering a while now how the firmware release process is working in OVMS.
I have found in the OVMS settings that I can choose "main", "eap" or "edge" as the update channel...
How does this relate to the github branches?
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main" channel? VWUP.OBD is not listed there... but in the user docs it is already: https://docs.openvehicles.com/en/latest/components/vehicle_vweup_obd/docs/in...
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th...
Not that all the details here need to be perfectly matching. Was just wondering about a coarse grained info about the process...
thanks
Soko
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (4)
-
Chris van der Meijden -
Mark Webb-Johnson -
Michael Balzer -
Soko