February 2023 - OvmsDev - Open Vehicles

Warning in Duktape
by Michael Geddes 09 Aug '24

09 Aug '24

There's an unused variable 'dcc' warning in the below code. It seems that the 'Perform the callback' is not being 'performed! Is this deliberate? //.ichael void DukOvmsCommandRegisterRun(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) { ESP_LOGD(TAG, "DukOvmsCommandRegisterRun(%s)",cmd->GetName()); auto it = MyDuktape.m_cmdmap.find(cmd); if (it == MyDuktape.m_cmdmap.end()) { ESP_LOGE(TAG, "Command '%s' cannot be found in registry",cmd->GetName ()); return; } else { DuktapeConsoleCommand* dcc = it->second; // Perform the callback } }

3 6

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

Subaru Solterra
by Solterra 10 Jun '23

10 Jun '23

Any interest in adding support for Subaru Solterra?

4 9

ESP-IDF v4 / v5 - baby steps
by Ludovic LANGE 05 Mar '23

05 Mar '23

Hi list, I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc... In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ). I'm now trying to revive this effort, and after some work managed to have: * OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing) (/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/ The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic) You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimenta… (In the README.md, there is a short notice at the top with a few useful informations) I'm now reaching out here mostly for : * gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files My next steps could be (of course, subject to feedback) : 1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same. (Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.) # The guidelines I tried to follow: * Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refer… * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… # Missing features: In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon: * I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/514… and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment. Let me know your comments and questions. Best regards,

4 27

Re: [Ovmsdev] Hyundai Kona Electric devs?
by Christos Oscar Kambiselis 23 Feb '23

23 Feb '23

I have, for my 2019 Kona Electric, the maps of the whole CAN bus network, pinouts of connectors and schematics of the wiring on PDF, these can all be found at service.hyundai-motor (dot) com, when accessed from Europe, the access costs 15€ for 24h or 60€ for a whole week, it's all official service manual info and much more for independent repair shops. I also have a couple of contactless CAN bus readers plus the direct connection to D-CAN through the OBD. My car only has the 8inch Standard Navi without the mobile data connection, but from the info I have gathered the only CAN bus connected to the larger "conected" navi is the same M-CAN that the standard version has, so the remote AC control should be possible, through M-CAN. I was thinking to connect the contactless readers to my logic analyzer plus one channel to a button to act as a marker, and record a known sequence of events, marking each event start with the button for easier searching. I also have access to 100kW DC fast chargers and 22kW AC chargers, including their CAN data when I have my car charging. Oscar

3 4

Android Auto?
by Mark Webb-Johnson 23 Feb '23

23 Feb '23

It seems easier to get onto Android Auto now (although still not trivial and certain things must be locked down ‘while driving’). Is there any interest in this? https://developer.android.com/training/cars/distribute Regards, Mark.

3 2

Advice on mechanism for responsive ECU -> HUD.
by Michael Geddes 21 Feb '23

21 Feb '23

Hi all, Now that I have a functional HUD connection, I've been tweaking some things to make sure it is responsive. The HUD itself is polling multiple times (4?) per second, so it's making sure the speed (particularly) metric is kept up-to-date. Initially, it was really slow because I had left the message throttle as its default of 1. Which means that at most 1 ISOTP message was being executed a second and speed was being updated every 3-4 seconds, which was unusable. I upped that to 8, and that was an improvement, and now I have this sub-ticker mechanism (below) implemented, and it appears to increase responsiveness and decrease latency between the dashboard speedo and the HUD speedo. It's really hard to observe as it requires that you be driving! It's also hard to be objective. Without the sub-ticker it's workable. With the sub-ticker, I think it just tightens it up that much more. So I have implemented the following: a) I added a new ticker timer in 'housekeeping' which sends an event every 1 ms "ticker.ms.100". (Though I'm thinking that every 2ms might be sufficient). The message is blocked from being sent to the web (now). b) In vehicle.h I have a (protected) function PollSetSubtick(bool) that can turn off and on the use of this 'sub-second' ticker (first time it's turned on is when it actually registers for the event). This then sets up a count that is reset whenever the polling ticker is incremented (m_poll_ticker) and the sub-ticker is enabled. c) When enabled, from sub-ticker count 4 onwards every 2 sub-ticks (0.1s), it calls PollerSend(false) as long as 1) It hasn't reach the end of the list, and 2) we aren't waiting for more parts of the current ISOTP message. The idea of this is that it keeps the queue moving in case there were protocol errors or other hiccoughs that stopped it continuing! d) I have implemented events for when the ecu is turned on and off: vehicle.ecu.start and vehicle.ecu.stop respectively called from the constructor/destructor of the ECU class. e) For (currently) the Ioniq 5, I register a listener for these events and then call a function ECUStatusChange(bool). 1) For 'enabled' this calls PollSetThrottling(8) and PollSetSubtick(true) 2) For 'disabled' this calls PollSetThrottling(4) and PollSetSubtick(false) f) The other thing I did for Ioniq 5 was to put an extra 'Speed' check at the end of the poll list - (for car 'on' only). Which means it checks speed twice per poll tick. Any feedback on any of this would be greatly appreciated. I'm worried about * Thread safety (would these events be executed in the same thread?) * Overloading the system somehow / causing battery drain when system off. * Do I need to turn off the ticker.ms.100 event at some point for power-saving? When? * Stuff I haven't thought of. //.ichael Geddes

3 9

Using Ovms to display information on a HUD
by Michael Geddes 09 Feb '23

09 Feb '23

Hi all, Now that I have an OVMS board that can actually sustain the HUD display power (not sure what was wrong with the previous one), I've certainly been making some inroads and found having the HUD a useful tool. I've got the internal ECU running, although I had to add a script for RPM to get the absolute value since the HUD doesn't like -ve numbers! I'm not sure I need RPM, but at least I now know that I'm retrieving sane values... so that was quite useful. Interestingly at 100km/h, the RPM gets up to 7000 which the HUD doesn't expect and with alarms on, it engages the 'shift now' HUD alarm as well as the 'that's definitely too high an RPM' HUD alarm!!! lol. (I worked out how to turn the HUD alarms off). One of the issues I'm having is that the refresh rate is 1 every 3 to 4 seconds, even after I upped the POLL time entry for the Ioniq 5 OBDII messages that contain 'speed' and 'rpm' to be every 1 tick. I'm not sure how long it takes to complete receiving .. or how often '1 tick' is happening in reality, but I'm guessing that might be some of the problem. What do other people who have a HUD experience? The other problem is that the ECU seems to occasionally stop working/responding to HUD requests.. so I'm going to have to look at that. I don't even have file logging at the moment on the new OVMS.. but once I get that up and going again I may have some more data. I have noticed that the OVMS itself isn't resetting .. so it's not a system crash. Closing the ECU down along with the power using *power.off* event and starting them both up again on *power.on* certainly means I'm more likely to start off with it working! Any thoughts on diagnosis welcome. //.ichael

2 3

CAN bus logging not working
by Christos Oscar Kambiselis 07 Feb '23

07 Feb '23

Hi, Has anyone had any problems with CAN bus logging? I have a 32GB SD card installed and "SD status" gives: *SD CARD is inserted* *Status: available* *Name: SD32G* *Size: 30419 MB* *Free: 29767 MB* *Card type: SDHC/SDXC* *Max speed: 25000 kHz* *Capacity: 30436 MB* *CSD: ver=1; sector_size=512; capacity=62333952 read_bl_len=9* *SCR: sd_spec=2; bus_width=5* I have setup CAN1 and 2 to "listen" and started the logging like it's mentioned in the user guide, checked the status, I stopped it some time later, and when I go to open it from the Web UI it is empty, also tried from the Editor and it is also empty, removing the card is a bit tricky since the hardware is pretty tucked away in the console. I searched the manual for a format command but can't find anything. I do get messages and readings on the OVMS Android app, so at least the OBD CAN is fine. Oscar

3 7

Active GPS power consumption
by Mark Webb-Johnson 07 Feb '23

07 Feb '23

Re: https://www.openvehicles.com/node/3545 I think it worthwhile having this discussion here. Synopsis seems to be: Our modem design uses the SIMCOM reference design to power the active GPS antenna from VBAT. This increases power consumption (powering the active antenna), even if the GPS is turned off in software. There is an alternative approach using pin 44 and the AT+CVAUXV / AT+CVAUXS commands to enable/disable and/or adjust voltage. Would be interesting to see the exact power readings and impact this change would make. I will try to get these this weekend. Regards, Mark

2 2