October 2021 - OvmsDev - Open Vehicles

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

IOS app reported GSM signal strength
by Craig Leres 17 Oct '22

17 Oct '22

I've noticed for awhile but never asked the question; why does the IOS app report wifi signal strength when I'm connected to wifi as gsm signal strength? I would expect gsm to always be gsm and maybe wifi would also be shown (and identified as such) when present. Note that I run my modules in wifi client-only mode. Craig

2 2

OVMS v3.3 hardware
by Mark Webb-Johnson 23 Feb '22

23 Feb '22

For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it. The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board. So far, I have come up with this minimal list: Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better. Modem board v1.3: Add support for SIM7600 module. Modem board v1.3: Fix support for DTR sleep/awake support. Is there anything else required for this update? Regards, Mark.

4 37

TLS CA question
by Stephen Casner 29 Jan '22

29 Jan '22

I find that I need to enable the following option in my testing of the possible replacement of MEDTLS with WolfSSL, otherwise I get an "ASN no signer to confirm" error: WOLFSSL_ALT_CERT_CHAIN allows CA's to be presented by peer, but not part of a valid chain. Default wolfSSL behavior is to require validation of all presented peer certificates. This also allows loading intermediate CA's as trusted and ignoring no signer failures for CA's up the chain to root. The alternate certificate chain mode only requires that the peer certificate validate to a trusted CA. Is that expected for the trust arrangements we are using? A possibly related question: do we expect the server to validate clients, or only the clients to validate the server? -- Steve

4 60

MCP2515 driver bug?
by Mark Webb-Johnson 20 Jan '22

20 Jan '22

I’m working on an implementation of IP stack over CAN for the Tesla Roadster. IP frames are encoded as a length followed by a sequence of CAN frames, all on the same ID. This runs over a 1MHz bus, so presumably the traffic volume could be high at times. I was having problems with this running on CAN2, so tried CAN1 and it worked perfectly. Here are some simple dumps of a single PING packet (and single PING response packet): ID #111 is used to transmit an IP packet, and ID #110 is used to receive an IP packet. The special empty data frame is an acknowledgment. Using latest master branch code (3.2.016-196-g0aad1a9f/ota_1/edge (build idf v3.3.4-848-g1ff5e24b1 Jun 2 2021 09:28:58)). So, first let’s test with traffic on CAN1 (active, 1Mbps), and listening on CAN2 (listen, 1Mbps): TCPDUMP: 05:57:55.980291 IP (tos 0x0, ttl 64, id 43101, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.99.3 > 10.10.99.2: ICMP echo request, id 23372, seq 1, length 64 0x0000: 4500 0054 a85d 4000 4001 b832 0a0a 6303 E..T.]@.@..2..c. 0x0010: 0a0a 6302 0800 7df8 5b4c 0001 5361 b860 ..c...}.[L..Sa.` 0x0020: 19f5 0e00 0809 0a0b 0c0d 0e0f 1011 1213 ................ 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050: 3435 3637 4567 05:57:56.436190 IP (tos 0x0, ttl 64, id 14937, offset 0, flags [none], proto ICMP (1), length 84) 10.10.99.2 > 10.10.99.3: ICMP echo reply, id 23372, seq 1, length 64 0x0000: 4500 0054 3a59 0000 4001 6637 0a0a 6302 E..T:Y..@.f7..c. 0x0010: 0a0a 6303 0000 85f8 5b4c 0001 5361 b860 ..c.....[L..Sa.` 0x0020: 19f5 0e00 0809 0a0b 0c0d 0e0f 1011 1213 ................ 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050: 3435 3637 4567 Traffic (as shown on PC the other end of the can log tcp connection): tx: #111 54 00 tx: #111 45 00 00 54 a8 5d 40 00 tx: #111 40 01 b8 32 0a 0a 63 03 tx: #111 0a 0a 63 02 08 00 7d f8 tx: #111 5b 4c 00 01 53 61 b8 60 tx: #111 19 f5 0e 00 08 09 0a 0b tx: #111 0c 0d 0e 0f 10 11 12 13 tx: #111 14 15 16 17 18 19 1a 1b tx: #111 1c 1d 1e 1f 20 21 22 23 tx: #111 24 25 26 27 28 29 2a 2b tx: #111 2c 2d 2e 2f 30 31 32 33 tx: #111 34 35 36 37 rx: #110 rx: #110 54 00 rx: #110 45 00 00 54 3a 59 00 00 rx: #110 40 01 66 37 0a 0a 63 02 rx: #110 0a 0a 63 03 00 00 85 f8 rx: #110 5b 4c 00 01 53 61 b8 60 rx: #110 19 f5 0e 00 08 09 0a 0b rx: #110 0c 0d 0e 0f 10 11 12 13 rx: #110 14 15 16 17 18 19 1a 1b rx: #110 1c 1d 1e 1f 20 21 22 23 rx: #110 24 25 26 27 28 29 2a 2b rx: #110 2c 2d 2e 2f 30 31 32 33 rx: #110 34 35 36 37 CAN1 active: 1T11 111 54 00 1R11 110 1CER TX_Queue T11 111 40 01 b8 32 0a 0a 63 03 1T11 111 45 00 00 54 a8 5d 40 00 1T11 111 40 01 b8 32 0a 0a 63 03 1CER TX_Queue T11 111 5b 4c 00 01 53 61 b8 60 1T11 111 0a 0a 63 02 08 00 7d f8 1T11 111 5b 4c 00 01 53 61 b8 60 1CER TX_Queue T11 111 0c 0d 0e 0f 10 11 12 13 1T11 111 19 f5 0e 00 08 09 0a 0b 1T11 111 0c 0d 0e 0f 10 11 12 13 1CER TX_Queue T11 111 1c 1d 1e 1f 20 21 22 23 1T11 111 14 15 16 17 18 19 1a 1b 1T11 111 1c 1d 1e 1f 20 21 22 23 1CER TX_Queue T11 111 2c 2d 2e 2f 30 31 32 33 1T11 111 24 25 26 27 28 29 2a 2b 1T11 111 2c 2d 2e 2f 30 31 32 33 1T11 111 34 35 36 37 1R11 110 54 00 1R11 110 45 00 00 54 3a 59 00 00 1R11 110 40 01 66 37 0a 0a 63 02 1R11 110 0a 0a 63 03 00 00 85 f8 1R11 110 5b 4c 00 01 53 61 b8 60 1R11 110 19 f5 0e 00 08 09 0a 0b 1R11 110 0c 0d 0e 0f 10 11 12 13 1R11 110 14 15 16 17 18 19 1a 1b 1R11 110 1c 1d 1e 1f 20 21 22 23 1R11 110 24 25 26 27 28 29 2a 2b 1R11 110 2c 2d 2e 2f 30 31 32 33 1R11 110 34 35 36 37 CAN2 listen: 2R11 111 54 00 2R11 110 2R11 111 45 00 00 54 a8 5d 40 00 2R11 111 40 01 b8 32 0a 0a 63 03 2R11 111 0a 0a 63 02 08 00 7d f8 2R11 111 5b 4c 00 01 53 61 b8 60 2R11 111 19 f5 0e 00 08 09 0a 0b 2R11 111 0c 0d 0e 0f 10 11 12 13 2R11 111 14 15 16 17 18 19 1a 1b 2R11 111 1c 1d 1e 1f 20 21 22 23 2R11 111 24 25 26 27 28 29 2a 2b 2R11 111 2c 2d 2e 2f 30 31 32 33 2R11 111 34 35 36 37 2R11 110 54 00 2CER Error intr=10 rxpkt=14 txpkt=0 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 2R11 110 40 01 66 37 0a 0a 63 02 2R11 110 19 f5 0e 00 08 09 0a 0b 2R11 110 34 35 36 37 2R11 110 45 00 00 54 3a 59 00 00 Conclusion is that the CAN1 traffic looks fine, and the PING packet gets a good reply. All successful. But the CAN2 listen is missing a few packets and the last packet is out of order. Now, let’s test with traffic on CAN2 (active, 1Mbps), and listening on CAN1 (listen, 1Mbps): TCPDUMP: 06:00:33.004060 IP (tos 0x0, ttl 64, id 58240, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.99.3 > 10.10.99.2: ICMP echo request, id 23393, seq 1, length 64 0x0000: 4500 0054 e380 4000 4001 7d0f 0a0a 6303 E..T..@.@.}...c. 0x0010: 0a0a 6302 0800 7cc8 5b61 0001 f161 b860 ..c...|.[a...a.` 0x0020: 8b0f 0000 0809 0a0b 0c0d 0e0f 1011 1213 ................ 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050: 3435 3637 4567 Traffic (as shown on PC the other end of the can log tcp connection): tx: #111 54 00 tx: #111 45 00 00 54 e3 80 40 00 tx: #111 40 01 7d 0f 0a 0a 63 03 tx: #111 0a 0a 63 02 08 00 7c c8 tx: #111 5b 61 00 01 f1 61 b8 60 tx: #111 8b 0f 00 00 08 09 0a 0b tx: #111 0c 0d 0e 0f 10 11 12 13 tx: #111 14 15 16 17 18 19 1a 1b tx: #111 1c 1d 1e 1f 20 21 22 23 tx: #111 24 25 26 27 28 29 2a 2b tx: #111 2c 2d 2e 2f 30 31 32 33 tx: #111 34 35 36 37 rx: #110 rx: #110 54 00 rx: #110 45 00 00 54 3a 5a 00 00 rx: #110 0a 0a 63 03 00 00 84 c8 rx: #110 8b 0f 00 00 08 09 0a 0b rx: #110 34 35 36 37 rx: #110 40 01 66 36 0a 0a 63 02 CAN2 active: 2T11 111 54 00 2R11 110 2CER TX_Queue T11 111 40 01 7d 0f 0a 0a 63 03 2T11 111 45 00 00 54 e3 80 40 00 2T11 111 40 01 7d 0f 0a 0a 63 03 2CER TX_Queue T11 111 5b 61 00 01 f1 61 b8 60 2T11 111 0a 0a 63 02 08 00 7c c8 2T11 111 5b 61 00 01 f1 61 b8 60 2CER TX_Queue T11 111 0c 0d 0e 0f 10 11 12 13 2T11 111 8b 0f 00 00 08 09 0a 0b 2T11 111 0c 0d 0e 0f 10 11 12 13 2CER TX_Queue T11 111 1c 1d 1e 1f 20 21 22 23 2T11 111 14 15 16 17 18 19 1a 1b 2T11 111 1c 1d 1e 1f 20 21 22 23 2CER TX_Queue T11 111 2c 2d 2e 2f 30 31 32 33 2T11 111 24 25 26 27 28 29 2a 2b 2T11 111 2c 2d 2e 2f 30 31 32 33 2T11 111 34 35 36 37 2R11 110 54 00 2R11 110 45 00 00 54 3a 5a 00 00 2CER Error intr=15 rxpkt=3 txpkt=12 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=5 txfail=0 wdgreset=0 errreset=0 2R11 110 0a 0a 63 03 00 00 84 c8 2R11 110 8b 0f 00 00 08 09 0a 0b 2R11 110 34 35 36 37 2R11 110 40 01 66 36 0a 0a 63 02 CAN1 listen: 1R11 111 54 00 1R11 110 1R11 111 45 00 00 54 e3 80 40 00 1R11 111 40 01 7d 0f 0a 0a 63 03 1R11 111 0a 0a 63 02 08 00 7c c8 1R11 111 5b 61 00 01 f1 61 b8 60 1R11 111 8b 0f 00 00 08 09 0a 0b 1R11 111 0c 0d 0e 0f 10 11 12 13 1R11 111 14 15 16 17 18 19 1a 1b 1R11 111 1c 1d 1e 1f 20 21 22 23 1R11 111 24 25 26 27 28 29 2a 2b 1R11 111 2c 2d 2e 2f 30 31 32 33 1R11 111 34 35 36 37 1R11 110 54 00 1R11 110 45 00 00 54 3a 5a 00 00 1R11 110 40 01 66 36 0a 0a 63 02 1R11 110 0a 0a 63 03 00 00 84 c8 1R11 110 5b 61 00 01 f1 61 b8 60 1R11 110 8b 0f 00 00 08 09 0a 0b 1R11 110 0c 0d 0e 0f 10 11 12 13 1R11 110 14 15 16 17 18 19 1a 1b 1R11 110 1c 1d 1e 1f 20 21 22 23 1R11 110 24 25 26 27 28 29 2a 2b 1R11 110 2c 2d 2e 2f 30 31 32 33 1R11 110 34 35 36 37 Conclusion is that the CAN2 transmit traffic looks fine, but no PING reply received via CAN. The CAN1 listen shows the reply just fine. Here is that last CAN1 listen, with timestamps: 1622696433.080107 1R11 111 54 00 1622696433.081657 1R11 110 1622696433.227479 1R11 111 45 00 00 54 e3 80 40 00 1622696433.228318 1R11 111 40 01 7d 0f 0a 0a 63 03 1622696433.245727 1R11 111 0a 0a 63 02 08 00 7c c8 1622696433.246214 1R11 111 5b 61 00 01 f1 61 b8 60 1622696433.248219 1R11 111 8b 0f 00 00 08 09 0a 0b 1622696433.248772 1R11 111 0c 0d 0e 0f 10 11 12 13 1622696433.250774 1R11 111 14 15 16 17 18 19 1a 1b 1622696433.251338 1R11 111 1c 1d 1e 1f 20 21 22 23 1622696433.253380 1R11 111 24 25 26 27 28 29 2a 2b 1622696433.253944 1R11 111 2c 2d 2e 2f 30 31 32 33 1622696433.265937 1R11 111 34 35 36 37 1622696433.269221 1R11 110 54 00 1622696433.272095 1R11 110 45 00 00 54 3a 5a 00 00 1622696433.272125 1R11 110 40 01 66 36 0a 0a 63 02 1622696433.272156 1R11 110 0a 0a 63 03 00 00 84 c8 1622696433.272193 1R11 110 5b 61 00 01 f1 61 b8 60 1622696433.272245 1R11 110 8b 0f 00 00 08 09 0a 0b 1622696433.272277 1R11 110 0c 0d 0e 0f 10 11 12 13 1622696433.272314 1R11 110 14 15 16 17 18 19 1a 1b 1622696433.272354 1R11 110 1c 1d 1e 1f 20 21 22 23 1622696433.272387 1R11 110 24 25 26 27 28 29 2a 2b 1622696433.272420 1R11 110 2c 2d 2e 2f 30 31 32 33 1622696433.272452 1R11 110 34 35 36 37 It is 1Mbps, with 30us or so between each packet. This is the only traffic on the bus. Everything else is turned off. Roughly 12 packets each way. Surely even if we were hitting a performance limit, our buffers can handle 12 packets? The good news is that I have a good environment to replicate this issue now, so any fix should be easy to test. I haven’t worked on the MCP2515 driver in our code in a long time, but it certainly seems something is messed up and that could be badly affecting vehicle modules using anything other than CAN1. I will start to look at this over the weekend, but has anyone got any ideas/suggestions? Perhaps the bit timing registers are off by a small amount (so it works on CAN1 but not on CAN2)? Or something more serious in our driver? Regards, Mark.

6 22

for-v3.3: ota flash http crashes
by Michael Balzer 23 Nov '21

23 Nov '21

There is another fatal issue with OvmsSyncHttpClient besides the issue with running in the mongoose context: OTA updates are no longer possible. When flashing via HTTP, the OvmsSyncHttpClient tries to allocate memory for a full firmware image, which of course fails: OVMS# ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/firmware/ota/v3.1/edge/ovms3.bin to ota_0 Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled. Core 1 register dump: PC : 0x4022438b PS : 0x00060a30 A0 : 0x802245cd A1 : 0x3ffe9c70 A2 : 0x00000000 A3 : 0x3ffe6f5c A4 : 0x00000001 A5 : 0xffffffff A6 : 0x3fabad7c A7 : 0xff000000 A8 : 0x00000000 A9 : 0x3ffe9c50 A10 : 0x00000000 A11 : 0x3ffe6f5c A12 : 0x00000001 A13 : 0x0000000a A14 : 0x00000037 A15 : 0x00000057 SAR : 0x00000018 EXCCAUSE: 0x0000001d EXCVADDR: 0x00000000 LBEG : 0x4008b179 LEND : 0x4008b19b LCOUNT : 0xffffffff ELF file SHA256: 94a8e191baae33a5 Backtrace: 0x4022438b:0x3ffe9c70 0x402245ca:0x3ffe9c90 0x40132f93:0x3ffe9cc0 0x40132e51:0x3ffe9d10 0x40133609:0x3ffe9d40 0x402e7472:0x3ffe9d70 0x4010e229:0x3ffe9d90 0x4010fbd5:0x3ffe9dd0 0x40110015:0x3ffe9e00 0x401102de:0x3ffe9e70 0x4010c51a:0x3ffe9ed0 0x400f5a4f:0x3ffe9ef0 0x400f5afd:0x3ffe9f40 Rebooting... 0x4022438b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy(char*, char const*, unsigned int) (/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/esp32-psram/libstdc++-v3/include/bits/char_traits.h:243). 0x402245ca is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned int) (/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/esp32-psram/libstdc++-v3/include/bits/basic_string.tcc:298). 0x40132f93 is in OvmsSyncHttpClient::ConnectionHeaders(mg_connection*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:381). 376 else 377 { 378 if (header.compare(0,15,"Content-Length:") == 0) 379 { 380 m_bodysize = atoi(header.substr(15).c_str()); *381 m_body.reserve(m_bodysize+1);* 382 } 383 else if (header.compare(0,5,"HTTP/") == 0) 384 { 385 size_t space = header.find(' '); 0x40132e51 is in OvmsSyncHttpClient::ConnectionData(mg_connection*, unsigned char*, unsigned int) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:316). 311 data += len; 312 consumed += len; 313 len = 0; 314 } 315 316 ConnectionHeaders(nc); 317 } 318 319 if (! m_inheaders) 320 { 0x40133609 is in OvmsSyncHttpClient::MongooseCallback(mg_connection*, int, void*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:124). 119 m_mgconn = NULL; 120 } 121 break; 122 123 case MG_EV_RECV: 124 mbuf_remove(&nc->recv_mbuf, ConnectionData(nc,(uint8_t*)nc->recv_mbuf.buf, nc->recv_mbuf.len)); 125 break; 126 127 default: 128 break; Can we switch back to using the old async client? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 6

UDS write by identifier help
by Shane ＠ Kilve Engineering 25 Oct '21

25 Oct '21

Hi all, Can anyone give me some help trying to write data to the TPMS ecu? I can read for example FL tyre using can can1 tx standard 735 03 22 e0 10 00 00 00 00 (FL id e010 FR e020 etc.) And get back 07 62 e0 10 80 2d b9 d4 I have confirmed that the tyre id is "80 2d b9 d4” with a tmps reader wireless at the wheel I have then done a session control with can can1 tx standard 735 02 10 03 00 00 00 00 00 And get back 06 50 03 00 32 01 f4 00 So that looks ok ? So I then try can can1 tx standard 735 07 2e e0 10 40 ea 85 ce (the new id) And get back 03 7f 2e 7f So ive tried issuing can can1 tx standard 735 02 27 01 00 00 00 00 00 But get no response?? any pointers? p.s. do I also need to be sending tester present to the ecu? Or does the fact im doing a session control take care of this? Regards Shane

2 3

Newbie Git question
by Michael Iimura 24 Oct '21

24 Oct '21

Since my OVMS module automatically updated to 3.2.017, I want to rebuild my RAV4 EV vehicle module based on this version. I have pushed the button in my branch on GitHub to bring it up to that version, but I don't know how to get it down into the Mingw32 environment on my PC so I can recompile it and upload it to my OVMS device. What command line git commands will do this? Thanks, - Mike

5 4

Urgent TLS root certificate issue (Let's Encrypt)
by Michael Balzer 12 Oct '21

12 Oct '21

Everyone, the DST root certificate we include (DST Root CA X3) expires on September 30, i.e. in two days. OVMS# tls trust list DST Root CA X3 length 1200 bytes 1200 byte certificate: DST Root CA X3 cert. version : 3 serial number : 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 subject name : O=Digital Signature Trust Co., CN=DST Root CA X3 issued on : 2000-09-30 21:12:19 * expires on : 2021-09-30 14:01:15* signed using : RSA with SHA1 RSA key size : 2048 bits basic constraints : CA=true key usage : Key Cert Sign, CRL Sign AFAICT, this root certificate is currently used by the OVMS to validate Let's Encrypt certificates. * https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ * https://letsencrypt.org/docs/certificate-compatibility/ Unfortunately, we missed adding the followup LE root certificate "ISRG Root X1" in time. I've just added that certificate to our builtin certificate repository, but it's too late now to roll out a "main" update in time (isn't it?). So, to prevent losing TLS connectivity with LE servers, users need to manually add the ISRG Root X1 certificate to their TLS repositories. I've added a section on this to our user manual: * https://docs.openvehicles.com/en/latest/userguide/ssltls.html If users contact you, point them to that page. We probably should also remove the expired DST root certificate after September 30. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

6 38

Re: [Ovmsdev] Coding help
by Shane ＠ Kilve Engineering 12 Oct '21

12 Oct '21

Ok thanks Michael sorry I thought it was your doing. Ive added this to the dev mail now BTW I do have direct with sensors in the wheels, I have fitted them myself in my summer wheels, and can read the same id’s in the tpms ecu. If anyone has any help on how to read and write these using the shell and how to implement this it will be much appreciated Regards Shane Hunns > On 10 Oct 2021, at 08:33, Michael Balzer <dexter(a)expeedo.de> wrote: > > Shane, > > first of all, just in case…: you only need to read & write tyre ID sets if you've got a "direct" TPMS with tyre integrated sensors. An indirect system using the ABS & ESP sensor readings doesn't need sensor ID sets. > > I haven't used the ID set part of the tpms framework yet, my car has an indirect TPMS. > > My understanding of Mark's framework is you simply need to implement the read & write hooks, i.e. OvmsVehicle::TPMSRead() & ::TMPSWrite(). They work on an uint32 vector using the same order as the wheel layout. > > For inspiration, see the implementations for these hooks in the Model S (via CAN) and the Roadster (via K-Line extension board). > > I've added Mark to the cc… and btw, this type of question is actually best suited for the developer list. > > Regards, > Michael > > > Am 10.10.21 um 08:53 schrieb Shane(a)Kilve-Engineering.co.uk <mailto:Shane@Kilve-Engineering.co.uk>: >> Morning Michael >> >> Thank you for your email and help, >> I think I have figured out the sensor and pressure part, but in the console the tpms command has the commands to read and write tyre Id sets >> But it says it’s not implemented in this vehicle >> How do I get this implemented? Or will this work once the pressure and temps bit set up? >> >> Regards >> Shane Hunns >> >> >>> On 9 Oct 2021, at 10:23, Michael Balzer <dexter(a)expeedo.de> <mailto:dexter@expeedo.de> wrote: >>> >>> Shane, >>> >>> the metrics system doesn't know about the TPMS sensor IDs, you need to map them in your module. >>> >>> Then simply assign the pressures and temperatures to the metrics. The default sequence is FL,FR,RL,RR. >>> >>> See my mails: >>> - http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/014953.html <http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/014953.html> >>> - http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html <http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html> >>> >>> The metrics are vector metrics, you can set single values in them by position, or simply fill a new vector and assign that as a whole. Template: >>> >>> std::vector<float> tpms_health(4); >>> … >>> tpms_health[i] = read_value; >>> … >>> StdMetrics.ms_v_tpms_health->SetValue(tpms_health); >>> >>> You can use "health" and/or "alert" as you like, for example with some user configurable thresholds. The "alert" metric automatically sends respective alert notifications on change. >>> >>> You can test/simulate this manually by using "metrics set". >>> >>> Regards, >>> Michael >>> >>> >>> Am 07.10.21 um 22:53 schrieb Shane @ Kilve Engineering: >>>> Hi Michael, >>>> >>>> I see that ovms has the ability to read and write tpms ID’s >>>> Ive found the pressure, temp's and id’s in the maxus >>>> >>>> Can you give some guidance on how I can get the read and write id’s part added? >>>> >>>> Regards >>>> Shane >>>> >>>>> On 11 Aug 2021, at 18:28, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>> >>>>> Shane, >>>>> >>>>> simple way: override stub OvmsVehicle::CommandHomelink() with your handler. >>>>> >>>>> Extensible way: implement a custom OvmsVehicle::ProcessMsgCommand(), see Twizy vehicle for an example. >>>>> >>>>> Handler Template: >>>>> >>>>> StringWriter res; >>>>> MyScripts.DuktapeEvalNoResult("abrp.send(1)", &res); >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 11.08.21 um 19:10 schrieb Shane @ Kilve Engineering: >>>>>> Hi Michael, >>>>>> >>>>>> I would like to use the homelink buttons on the iOS app to start and stop the ABRP scrip "script eval abrp.send(1)” & "script eval abrp.send(0)” >>>>>> >>>>>> I think ive figured out the set up of the hoteling button to get it into the .cpp & .h files but dont know how to call the script from within the CPP file >>>>>> >>>>>> Any help appreciated >>>>>> >>>>>> Regards >>>>>> Shane Hunns >>>>>> Kilve Engineering Ltd. >>>>>> 0792 0729 316 >>>>>> >>>>>>> On 5 Apr 2021, at 16:01, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>> >>>>>>> Shane, >>>>>>> >>>>>>> the standard deviation isn't the distance between the minimum and maximum, it's a measure of variation from the mean value. >>>>>>> >>>>>>> Standard deviation is one of the main basic statistical analysis tools. Read more on this on the web: https://duckduckgo.com/?q=standard+deviation <https://duckduckgo.com/?q=standard+deviation> >>>>>>> >>>>>>> In the battery chart, the standard deviation is shown as the horizontal stripe with light blue background. The maximum standard deviation observed since the last reset is shown by the two blue lines. >>>>>>> >>>>>>> A high standard deviation, especially under load, means a high cell drift = defective / aged / poorly selected pack. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> Am 05.04.21 um 16:40 schrieb Shane @ Kilve Engineering: >>>>>>>> Hi Michael look as the data below, ignoring there is some rounding up done somewhere >>>>>>>> >>>>>>>> Max 4.240 >>>>>>>> Min 4.200 >>>>>>>> >>>>>>>> That’s 40mv deviation >>>>>>>> Stddev showing 4.35mv 0.00435 its one decimal place out >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Shane >>>>>>>> >>>>>>>>> On 5 Apr 2021, at 07:50, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>> >>>>>>>>> Shane, >>>>>>>>> >>>>>>>>> what makes you think so? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 04.04.21 um 20:47 schrieb Shane @ Kilve Engineering: >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> Me again >>>>>>>>>> It look like the bus framework does the calc incorrect? >>>>>>>>>> Surly stddev should be 0.0435 >>>>>>>>>> And stddev.max should be 0.0437147V >>>>>>>>>> >>>>>>>>>> v.b.p.voltage.avg 4.23496V >>>>>>>>>> v.b.p.voltage.grad -0.00026V >>>>>>>>>> v.b.p.voltage.max 4.24V >>>>>>>>>> v.b.p.voltage.min 4.2V >>>>>>>>>> v.b.p.voltage.stddev 0.00435V >>>>>>>>>> v.b.p.voltage.stddev.max 0.00437147V >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Shane >>>>>>>>>> >>>>>>>>>> <Screenshot 2021-04-04 at 19.45.35.png> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 4 Apr 2021, at 13:26, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>> >>>>>>>>>>> Shane, >>>>>>>>>>> >>>>>>>>>>> vector metrics in general can be set by passing a vector or by using the element setters provided (see API). >>>>>>>>>>> >>>>>>>>>>> But you don't need to set the cell max/min/stddev metrics at all, you only need to feed the cell voltages (and/or temperatures). The BMS framework automatically extracts all statistics values from them. >>>>>>>>>>> >>>>>>>>>>> Btw, regarding your cell voltages: >>>>>>>>>>> >>>>>>>>>>>> 748[7c8]:e113 10 90 10 92 10 93 10 93 10 8e 10 92 10 8f 10 90 10 92 10 6c 10 93 10 93 10 8f 10 91 10 92 10 92 10 92 10 92 10 92 10 92 10 90 10 8e 10 90 10 92 10 8d 10 90 10 91 10 8f 10 8e 10 8f 10 91 10 90 10 90 10 91 10 8e 10 91 10 8e 10 91 10 90 10 8e 10 90 10 92 10 90 10 94 10 91 10 91 10 93 10 90 10 91 10 90 10 8f 10 93 10 92 10 8e 10 90 10 91 10 8b 10 92 10 90 10 91 10 8e 10 90 10 90 10 90 10 91 10 90 10 8f 10 90 10 90 10 8e 10 92 10 8e 10 91 10 89 10 91 10 91 10 91 10 8d 10 8f 10 8d 10 86 10 8a 10 8e 10 8f 10 91 10 90 10 92 10 94 10 88 10 8f 10 94 10 91 10 91 10 91 10 93 10 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>>>>>>>>> >>>>>>>>>>> This looks like 96 cells with a factor of 0.001, e.g. 0x1090 = 4240 * 0.001 = 4.24V. >>>>>>>>>>> >>>>>>>>>>> Assuming you fix your IncomingPollReply() handler to actually use the rxbuf string and you copy the RXB_* macros from the Ioniq VFL code, you can simply do this to process the values: >>>>>>>>>>> >>>>>>>>>>> case 0xe113: >>>>>>>>>>> { >>>>>>>>>>> // Read battery cell voltages 1-96: >>>>>>>>>>> BmsRestartCellVoltages(); >>>>>>>>>>> for (int i = 0; i < 96; i++) { >>>>>>>>>>> BmsSetCellVoltage(i, RXB_UINT16(i*2) * 0.001f); >>>>>>>>>>> } >>>>>>>>>>> break; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Doesn't look that hard, does it? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Michael >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Am 04.04.21 um 12:37 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>> morning peeps, sorry for the newbie question whats different about the cell vmax/vmin i see in metrics_standard.h its a vector? >>>>>>>>>>>> (OvmsMetricVector<float>* ms_v_bat_cell_vmax; // Cell maximum voltages [V]) >>>>>>>>>>>> does that mean i have ot handle these different? if so how? >>>>>>>>>>>> as all i get is errors trying to setvalue to this metric >>>>>>>>>>>> >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp: In member function 'void OvmsVehicleMaxed3::IncomingBmsReply(canbus*, uint16_t, uint16_t, uint8_t*, uint8_t, uint16_t)': >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:159:82: error: no matching function for call to 'OvmsMetricVector<float>::SetValue(float)' >>>>>>>>>>>> StandardMetrics.ms_v_bat_cell_vmax->SetValue((float)value2 / 1000); >>>>>>>>>>>> ^ >>>>>>>>>>>> In file included from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle/vehicle.h:40:0, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.h:32, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:32: >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(std::__cxx11::string) [with ElemType = float; Allocator = std::allocator<float>; std::__cxx11::string = std::__cxx11::basic_string<char>] >>>>>>>>>>>> virtual bool SetValue(std::string value) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: no known conversion for argument 1 from 'float' to 'std::__cxx11::string {aka std::__cxx11::basic_string<char>}' >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(const std::vector<_Tp, _Alloc>&, metric_unit_t) [with ElemType = float; Allocator = std::allocator<float>] >>>>>>>>>>>> bool SetValue(const std::vector<ElemType, Allocator>& value, metric_unit_t units = Other) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: no known conversion for argument 1 from 'float' to 'const std::vector<float, std::allocator<float> >&' >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:162:82: error: no matching function for call to 'OvmsMetricVector<float>::SetValue(float)' >>>>>>>>>>>> StandardMetrics.ms_v_bat_cell_vmin->SetValue((float)value2 / 1000); >>>>>>>>>>>> ^ >>>>>>>>>>>> In file included from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle/vehicle.h:40:0, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.h:32, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:32: >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(std::__cxx11::string) [with ElemType = float; Allocator = std::allocator<float>; std::__cxx11::string = std::__cxx11::basic_string<char>] >>>>>>>>>>>> virtual bool SetValue(std::string value) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: no known conversion for argument 1 from 'float' to 'std::__cxx11::string {aka std::__cxx11::basic_string<char>}' >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(const std::vector<_Tp, _Alloc>&, metric_unit_t) [with ElemType = float; Allocator = std::allocator<float>] >>>>>>>>>>>> bool SetValue(const std::vector<ElemType, Allocator>& value, metric_unit_t units = Other) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: no known conversion for argument 1 from 'float' to 'const std::vector<float, std::allocator<float> >&' >>>>>>>>>>>> make[1]: *** [src/vehicle_med3.o] Error 1 >>>>>>>>>>>> make: *** [component-vehicle_maxus_edeliver3-build] Error 2 >>>>>>>>>>>> shane@Shanes-MacBook-Pro OVMS.V3 % >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Shane >>>>>>>>>>>> >>>>>>>>>>>>> On 3 Apr 2021, at 12:02, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> OVMS# obd can1 request device -t1000 7e4 7ec 2102 >>>>>>>>>>>>> 7e4[7ec] 2102: Response: >>>>>>>>>>>>> ff ff ff ff c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c5 | ................ >>>>>>>>>>>>> c5 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c4 c4 c4 | .... >>>>>>>>>>>>> >>>>>>>>>>>>> OVMS# obd can1 request device -t1000 7e4 7ec 2103 >>>>>>>>>>>>> 7e4[7ec] 2103: Response: >>>>>>>>>>>>> ff ff ff ff c4 c4 c4 c4 c4 c4 c4 c5 c5 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c4 c4 c4 c4 c5 c5 c5 c4 c5 c5 c5 c4 c5 c4 c4 | ................ >>>>>>>>>>>>> c5 c4 c4 c4 | .... >>>>>>>>>>>>> >>>>>>>>>>>>> OVMS# obd can1 request device -t1000 7e4 7ec 2104 >>>>>>>>>>>>> 7e4[7ec] 2104: Response: >>>>>>>>>>>>> ff ff ff ff c4 c4 c5 c4 c4 c4 c4 c4 c4 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c5 c4 c4 | .... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Your voltages obviously are 16 bit values, so you'll need to use RXB_UINT16() and multiply your loop index by 2. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Michael >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Am 03.04.21 um 12:04 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>> Hi has anyone got a sample of the data for the cell voltages on the ioniq vfl just so I can see how the macro is handling it? Or is it played out the same as below? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Shane >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 29 Mar 2021, at 22:20, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 29.03.21 um 20:17 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>> can any one tell me what the "v.e.c.login" is and is it need for something to work? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> v.e.c.config yes = ECU/controller in configuration state >>>>>>>>>>>>>>> It's not used by the framework currently. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> also any one with any ideas how to deal with cell voltages in a string this long? took me blumim ages to find the bms when the tx and rx are 128 address apart!! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 748[7c8]:e113 10 90 10 92 10 93 10 93 10 8e 10 92 10 8f 10 90 10 92 10 6c 10 93 10 93 10 8f 10 91 10 92 10 92 10 92 10 92 10 92 10 92 10 90 10 8e 10 90 10 92 10 8d 10 90 10 91 10 8f 10 8e 10 8f 10 91 10 90 10 90 10 91 10 8e 10 91 10 8e 10 91 10 90 10 8e 10 90 10 92 10 90 10 94 10 91 10 91 10 93 10 90 10 91 10 90 10 8f 10 93 10 92 10 8e 10 90 10 91 10 8b 10 92 10 90 10 91 10 8e 10 90 10 90 10 90 10 91 10 90 10 8f 10 90 10 90 10 8e 10 92 10 8e 10 91 10 89 10 91 10 91 10 91 10 8d 10 8f 10 8d 10 86 10 8a 10 8e 10 8f 10 91 10 90 10 92 10 94 10 88 10 8f 10 94 10 91 10 91 10 91 10 93 10 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Simply loop over the cells contained. Have a look at the buffer macro utils, e.g.: >>>>>>>>>>>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/maste… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/maste…> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Shane >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 5 Mar 2021, at 20:45, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OvmsVehicle::PollSetPidList(m_can1, obdii_polls); >>>>>>>>>>>>>>>>> OvmsVehicle::PollSetState(0); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> needs to be done in your vehicle init, i.e. the constructor after RegisterCanBus(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please read the vehicle_obdii module source for a complete polling example. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 05.03.21 um 17:59 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>>>> Thanks Michael, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Had a try and ended up with this bit added but return anything >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Where am I going wrong? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Shane >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ******* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #include "ovms_log.h" >>>>>>>>>>>>>>>>>> static const char *TAG = "v-edeliver3"; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #include "vehicle_edeliver3.h" >>>>>>>>>>>>>>>>>> #include "metrics_standard.h" >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> namespace { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> const OvmsVehicle::poll_pid_t obdii_polls[] = >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> { 0x7e3, 0x7eb, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xf194, { 10, 10, 10, 10 }, 0, ISOTP_STD }, //VIN >>>>>>>>>>>>>>>>>> { 0x7e3, 0x7eb, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xe003, { 10, 10, 10, 10 }, 0, ISOTP_STD }, //SOH >>>>>>>>>>>>>>>>>> POLL_LIST_END >>>>>>>>>>>>>>>>>> }; >>>>>>>>>>>>>>>>>> }; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OvmsVehicleEdeliver3::OvmsVehicleEdeliver3() >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> ESP_LOGI(TAG, "Start eDeliver3 vehicle module"); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> RegisterCanBus(1,CAN_MODE_ACTIVE,CAN_SPEED_500KBPS); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OvmsVehicleEdeliver3::~OvmsVehicleEdeliver3() >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> ESP_LOGI(TAG, "Stop eDeliver3 vehicle module"); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> memset(m_vin, 0, sizeof(m_vin)); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> //testing polls >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> void OvmsVehicleEdeliver3::IncomingPollReply( >>>>>>>>>>>>>>>>>> canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain) >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> string& rxbuf = med_obd_rxbuf; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OvmsVehicle::PollSetPidList(m_can1, obdii_polls); >>>>>>>>>>>>>>>>>> OvmsVehicle::PollSetState(0); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // init / fill rx buffer: >>>>>>>>>>>>>>>>>> if (m_poll_ml_frame == 0) { >>>>>>>>>>>>>>>>>> rxbuf.clear(); >>>>>>>>>>>>>>>>>> rxbuf.reserve(length + mlremain); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> rxbuf.append((char*)data, length); >>>>>>>>>>>>>>>>>> if (mlremain) >>>>>>>>>>>>>>>>>> return; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // complete: >>>>>>>>>>>>>>>>>> switch (pid) { >>>>>>>>>>>>>>>>>> case 0xe003: { >>>>>>>>>>>>>>>>>> unsigned int soh_raw = ((unsigned int)rxbuf[0] << 8) | (unsigned int)rxbuf[1]; >>>>>>>>>>>>>>>>>> float soh = soh_raw / 10; >>>>>>>>>>>>>>>>>> StdMetrics.ms_v_bat_soh->SetValue(soh); >>>>>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // end testing polls >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 5 Mar 2021, at 12:37, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> on OBD polling basics: http://lists.openvehicles.com/pipermail/ovmsdev/2020-December/014758.html <http://lists.openvehicles.com/pipermail/ovmsdev/2020-December/014758.html> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 04.03.21 um 19:45 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>>>>>> Good evening Michael, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Or any one that has the time to help, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Ive now successfully retrieved as much info as I can without polling any info for the maxus, but I have have now found an ecu that responds to pid requests. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> For example if I use the obdii pid scanner I get the loads of data back and I’ve decoded some of it, just need a bit of guidance how to write the code to get the same info >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> A part of a scan is as follows >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Scan complete (7e3 e000-e100) >>>>>>>>>>>>>>>>>>>> Scan started : 2021-03-04 18:32:36 GMT >>>>>>>>>>>>>>>>>>>> Last response: 2021-03-04 18:32:39 GMT >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e000 00 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e001 64 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e002 4b >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e003 26 bc >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e004 00 07 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e005 2f >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e006 2e >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e007 02 00 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e008 01 ff >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e009 02 00 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e010 02 00 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I know that e003 is SOH = 26bc = 9916 /100 = 99.16% SOH >>>>>>>>>>>>>>>>>>>> And e002 is a temp 4b = 75 / 10 = 7.5 degrees >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So if some one can help me with an example of how to correctly code this one I can work out the rest, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Ive looked through various vehicles but everyone uses different methods and I can’t seem to get one to work for me. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Any help much appreciated >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Shane >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 15 Feb 2021, at 08:05, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I forgot to mention: if you're working on a new vehicle module, you'll also need to start the bus somewhere in your initialization code. Example: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> RegisterCanBus(1, CAN_MODE_ACTIVE, CAN_SPEED_500KBPS); >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Am 15.02.21 um 08:36 schrieb Michael Balzer: >>>>>>>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Am 14.02.21 um 16:42 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>>>>>>>>> can any one help me with a bit of code to retrieve ve some data from ecu can1/6f2 00 4c 00 00 01 97 bc 00 as i cant poll this ecu it just broadcasts when its active, ive tried polling it but does not respond, i need to choose one byte and allocate it to a PID. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I don't know what you mean by "allocating a byte to a PID", but if you want to process frames received directly, simply override IncomingFrameCan1() (or …2/3/4 depending on your bus). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Reduced example: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> void OvmsVehicleXYZ::IncomingFrameCan1(CAN_frame_t *p_frame) >>>>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>>>> uint8_t *d = p_frame->data.u8; >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> switch (p_frame->MsgID) >>>>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>>>> case 0x6f2: >>>>>>>>>>>>>>>>>>>>>> // for example, assuming the SOC is in byte 1: >>>>>>>>>>>>>>>>>>>>>> StdMetrics.ms_v_bat_soc->SetValue(d[1]); >>>>>>>>>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If you're outside a vehicle context, you can register your own CAN receiver by creating a queue and calling MyCan.RegisterListener(). See the vehicle module for an example. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>>>>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OvmsDev mailing list >>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OvmsDev mailing list >>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>> >>>>> >>>>> -- >>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>> >>> >>> -- >>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1