April 2021 - OvmsDev - Open Vehicles

CAN LOG rework
by Mark Webb-Johnson 15 Apr '21

15 Apr '21

I’ve committed a rather large patch to the CAN LOG framework in master. Changes include: Move to a connection-based framework, to better support multi-connection loggers Support single connection loggers as a simple use case of multi-connection loggers Move some functionality to the base canlog class, to remove burden from individual loggers Re-work the formatter transmit callback mechanism to work off the connection objects (rather than the nasty transmit callback previously used) Add support for dynamic per-connection pausing Add support for dynamic per-connection filtering Add support for control commands via CAN LOG clients Implement control commands in CRTD formatter Improve documentation for the CRTD format Apart from the change in appearance to the ‘can log status’ command, this should be backwards compatible. It seems to work for me, but I will do a lot more testing over the coming few evenings. Trying to get ready for some other work that leverages this capability. Regards, Mark

1 0

Android App wiki page on image additions
by Michael Balzer 13 Apr '21

13 Apr '21

I've added an info on adding vehicle image sets: https://github.com/openvehicles/Open-Vehicle-Android/wiki/Adding-Vehicle-Im… Mark, maybe you can copy some of this to the iOS App wiki? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

First commit for the Jaguar IPace module
by didier＠ernotte.com 08 Apr '21

08 Apr '21

Hi, I am done for a very first initial V0.0.1 version for the Jaguar IPace module.It compiles and runs ok localy. I am ready to push the code, but my knowledge of git commands is limited to "git clone" ... :-)I did not create any branch locally.Can someone tell me , a step by step list of git command I should do to push the code are create a PR ? Didier

1 0

Coding help
by Shane ＠ Kilve Engineering 05 Apr '21

05 Apr '21

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.

3 22

List of MQTT commands for Leaf
by Pedro Pinheiro 04 Apr '21

04 Apr '21

Hello to all, thank you for accepting me into the list. I have developed a Node-RED/Mosquitto system to allow us to interact with our cars, chargers, energy meters, to allow me to limit the SoC to a certain percentage, change the wallbox available power dynamically depending on how much power the rest of house installation is drawing, programmed charging, and to start/stop charging. I’m now adding functions to start/stop the remote climate control (done), and now I’m trying to lock/unlock the doors via my system. I have looked far and wide, I have tried to find it in the source code, but I cannot find if I can find if I can publish to a MQTT topic to lock/unlock the doors of a Leaf. If anyone could point me in the right direction, I would be very grateful. Warm regards, and thank you for all the work you have put into the project! Pedro Pinheiro

1 0

Re: [Ovmsdev] Coding help
by henrik.scheel＠spjeldager.dk 04 Apr '21

04 Apr '21

2 1

ESP32 CAN controller hardware bug / interrupt issue
by Michael Balzer 03 Apr '21

03 Apr '21

Second finding & commit: TL;DR: * ESP32 CAN controller is broken, delivers trashed & duplicated RX frames * we need to optimize interrupt latency Users have been reporting occasional false BMS readings on the Twizy for more than a year. The error always trashed the reading of voltage #10 and/or temperature #8, so I initially thought that must be a variant of the SPIRAM/cache bug. But the SPIRAM fix didn't help, and the bug still occured with all BMS data in internal RAM. The issue correlated with high load situations and the SIMCOM UART issue. On testing the latest changes by Marko, my car module began showing that issue regularly, so I could take a closer look. It turned out the wrong data came from the CAN bus. Checking with a CAN logger didn't show any wrong data on the bus. So I scanned our CAN driver for potential issues, found & solved some (even a serious race condition) but that didn't fix it. I then added debug dumps of all frames read, dug into the SJA1000 spec sheet and found this: The SJA1000 RX FIFO has a capacity of 64 bytes. It's supposed to work as a ring buffer, with frames wrapping around as necessary. If no space is left in the FIFO for a new frame coming in, that frame should be discarded completely, not counted, just the overflow indicator should be set & the according interrupt be generated. Reality differs. The frame causing the overflow is added to the FIFO partially. It's also counted both in the RMC register and indicated by RBS as a valid frame when retrieving the FIFO contents. The read buffer delivers the partial frame + some trashed bytes up to the nominal frame length. In the BMS frame sequence it would normally trash bytes 7 & 8 on the sixth frame of length 8 in a sequence. A standard frame needs a 3 byte header + the data bytes in the FIFO, so 6 frames would add up to 66 bytes => 64 + 2 trash. The first trash byte normally is "08", the second "84" or "2a" or sometimes "ab", possibly some internal SJA1000 data. Better yet, if you rely on the indicators of the SJA1000 when reading the FIFO, the SJA1000 will repeat the first frame within the FIFO after the invalid frame. Mostly once or twice, and sometimes 7 times or more: inv_msg: framecnt=13, invindex=6 inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 24 04 00 00 11 40 10 22 37 55 00 37 | 4..?........$....@."7U.7 inv_msg: 25 04 00 00 0a 1b 44 ff fe 4e 01 26 | 4..?........%.....D..N.& inv_msg: 54 05 00 00 37 37 37 37 37 37 37 00 | 4..?........T...7777777. inv_msg: 56 05 00 00 31 63 14 31 53 14 31 4a | 4..?........V...1c.1S.1J inv_msg: 57 05 00 00 31 43 14 31 53 15 *08 2a* | 4..?........W...1C.1S..* ^^^^^ trashed bytes … followed by 7 repetitions of the first frame: inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n If you had occasional strange false readings leading to strange effects, this may be the explanation. Note: the SJA1000 FIFO bug may need specific circumstance to occur in addition to the overflow, maybe the overflow happening on a specific byte position in the FIFO -- I haven't tried to determine that. I've tried clearing the overflow ASAP, looping on the IR indicator and looping on the RMC, the fault is always the same. The workaround I've now done is adding up the message lengths read during a FIFO run and discard all frames exceeding the 64 byte border. Not pretty, but functional. That keeps the trashed frames from being forwarded to the OVMS application level. As with the SIMCOM UART, these overflows wouldn't happen if the interrupt handler would react fast enough. It seems we've got a general interrupt latency issue. And just as with the SIMCOM I saw a reduction of overflows when allocating the CAN IRQ on core #0, another one with raising the IRQ level to 3, so that's also part of my commit. The esp-idf CAN driver apparently has the same issue even in the latest release, I'll contact the author about this or post another issue to Espressif. So our interrupt allocation is now: Task Run# Lvl ISR# Usage Source ---------------------------------------------------------------------------------------- - 0 1 0 RTC Core ETS_RTC_CORE_INTR_SOURCE esp_timer 0 1 0 RTOS esp_timer ETS_TIMER2_INTR_SOURCE ipc0 0 1 0 RTOS Scheduler Core0 ETS_FROM_CPU_INTR0_SOURCE ipc1 1 1 1 RTOS Scheduler Core1 ETS_FROM_CPU_INTR1_SOURCE main 0 1 0 RTOS Watchdog ETS_TG0_WDT_LEVEL_INTR_SOURCE OVMS Events 1 1 1 Peripherals (GPIO ISR) ETS_GPIO_INTR_SOURCE OVMS Events 1 1 1 MAX7317 (spi_nodma) ETS_SPI3_INTR_SOURCE *esp32can init 0 3 0 ESP32 CAN ETS_CAN_INTR_SOURCE** **OVMS SIMCOM 0 2 0 SIMCOM UART ETS_UART1_INTR_SOURCE* OVMS Events 1 1 1 USB console (UART) ETS_UART0_INTR_SOURCE OVMS Events 1 1 1 SD card ETS_SDIO_HOST_INTR_SOURCE ---------------------------------------------------------------------------------------- I think we need to find the source of the interrupt latency and/or find some better scheme to distribute the tasks & interrupts over the cores. I still don't know why core #1 already got an issue with just our 6 interrupts. This may be related to the SPIRAM fix adding overhead, but I've seen the FIFO overflows before applying the fix, and the CAN issue also has been present for over a year. My working hypothesis is some task/driver disabling interrupts for too often / too long, or non-IRAM ISRs getting delayed for too often / too long. And it seems this is an issue especially on core #1. Please verify & comment. Regards, Michael PS: a little side mystery: the netmanager task starts with priority 5, then gets raised to 22 (probably a mutex priority inheritance), but never gets lowered back to 5 afterwards. A FreeRTOS bug? -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 11

Multi frame query
by didier＠ernotte.com 02 Apr '21

02 Apr '21

Hi, I am investigating some PID with very long data. I am using the PID scanner for this.When I turn on the log level debug , I can see this as the first repy D (1456677) obd2ecu: Rcv 7ec: 8 (15 df 62 48 83 0 0 0) >From the Canbus doc, I understand that the first "1x (15)" tells me that this is the first frame of a multi frame, and the length is "5df" . The Pid scanner seems to return only "df", not "5df" data, and I can see in the log that I have around 1500 byte returned, not 220. Any explanation ? anyone see this problem as well ? The scan command is (I had to hack the code to allow timeout > 10sec) re obdii scan start 1 7e4 4883 4883 -r500-7ff -t22 -x30 Didier

5 16