October 2022 - 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

SIM7600 Registration Denied
by Mark Webb-Johnson 18 Jan '23

18 Jan '23

I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: Finally, with a good high gain antenna on my external wall facing the nearest cellular tower a couple of km away, I can get cellular (and even GPS with the little black puck) connectivity. So back to the two issues we are having: The FPLMN blacklist in the modem lists a bunch of cellular networks we are blocked from connecting to (including the ones we need). There have been reports that the connection to hologram works and is maintained, but the OVMS never connects to the v2 server. To address #1, I have extended the “cellular cmd” command to try to capture the output from the modem. There is no simple way of knowing when the command has completed, so for the moment I just look at data returned from the modem on the command channel, and stop when it hasn’t changed for a second or so. That now works like this: OVMS# cellular cmd AT+CRSM=176,28539,0,0,12 +CRSM: 144,0,"FFFFFFFFFFFFFFFFFFFFFFFF" OK OVMS# cellular cmd ATI Manufacturer: SIMCOM INCORPORATED Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 SVN: 01 IMEI: (redacted) +GCAP: +CGSM OK If required, we can send a relatively simple command to clear the FPLMN blacklist. It seems to work well, but I still need to test it wider (especially over v2 protocol commands, where I think we might have a recursion problem). So on to issue #2 that has been much harder to find. Finally, working with Hologram, I discovered that the problem seems to be in our handling of CREG network registration messages. I found a module with this problem, and manually issuing commands I found: AT+CREG? Registration Denied AT+CGREG? Registration Denied AT+CEREG? Registered Roaming It seems that the E-UTRANS (some 4G LTE carriers) won’t show the registration status correctly in AT+CREG. I guess they are refusing GSM (3G) connections from us (aka ‘Registration Denied’) while allowing 4G LTE. But as we only use the AT+CREG status to know whether we are connected to the network, the result is we can’t detect the E-UTRANS LTE connection and think registration has been denied. Connected to Hologram, but no data (or v2 server) connection. I did some research, and can’t find a definitive answer to how best to do this (especially as we have both 3G and 4G options, still support 2G, and a lot seems to depend on the individual cellular carrier options). So I implemented it as best I could. I re-ordered the registration statuses to be in lowest priority order, then created m_netreg_d[3] to store the registration status for each of the three types. Finally, I changed it so that m_netreg reflects the highest registration status. That way if CREG says RegistrationDenied, and CEREG says RegisteredRoaming, I treat it as RegisteredRoaming. This seems to work (on my test bench at least), and I now plan to deploy for wider testing. Code is committed and built as 3.3.002-45-g42546636 on the main firmware site. I would gratefully appreciate feedback on this. Regards, Mark.

4 21

Fiat500e Quirks
by William Reading 18 Nov '22

18 Nov '22

Howdy there, I recently got an OVMS set up with my Fiat 500e and was happy to see that it works, but I noticed noticed a few oddities. The first one is that it uses Valet Mode (CommandActivateValet) for preconditioning instead of CommandClimateControl: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/bd192… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/bd192…> Is there a downside to changing the code to where it uses Climate Control instead? It seems like that would fit better with the intended functionality. The other is that it seems to rapidly generate spurious charging / not charging events, which en masse seems to make the websocket connection on the web server time out. I can put together a pull request to try to fix these issues, but was wondering if there are any thoughts on these two things before getting started. There's also no pictures of the Fiat on the iOS App, but I assume that's because the last release of the iOS App predates support. Thanks, William Reading

2 3

HUD Connected to OVMS not working
by Michael Geddes 08 Nov '22

08 Nov '22

Hi all, Anybody got any experience with HUDs? I bought this simple HUD from FastTech: https://www.fasttech.com/products/9686283 When connected direct to the OBDII port, it powers on and seems to function. When I connect it to the OVMS module with the standard https://www.fasttech.com/products/9652027 the HUD doesn't even power on. It's stated draw is 200ma which afaict should be fine. I'm pretty sure the 12V power is getting to PIN 16... though I will try again to make sure. I only have a crappy little Multimeter. On the Troubleshooting it states: "HUD only available for cars with OBD2 and EU-OBD agreements ... HUD Products don't support JOBD and OBDI protocol." The OBD HUD connector has the following pins: 4* Chassis 5* Signal Ground 6 CAN High 7 *ISO9141 K Line* 14 CAN Low 15 *ISO9141 L Line* 16 Vehicle Battery +ve * Long pins These are the standard OVMS supplied pins: 4 Chassis Ground 5 Chassis Ground 6 CAN H (Primary) 14 CAN L (Primary) 16 +12V So obviously the main difference is the lack of K / L lines in the OVMS ... but I wouldn't have thought that would have prevented it from powering up. Does anybody have any thoughts on this? //.ichael

4 12

Ioniq 5 - Pushing up some prerequisite changes to components/vehicles
by Michael Geddes 04 Nov '22

04 Nov '22

Hi all, I have 6 commits that I would _like_ to get pushed up that are changes to components/vehicles required for my Ioniq 5 changes to work. I can push them all up in a single merge request for review, or separate them out into bits. Some of them I am expecting there to be opinions on. I'm prepared to simplify some, and one in particular has grounds for nixing. I think it's a good change, but I could manage without it. One is a simple bugfix - a literal one-character change: void OvmsVehicle::BmsRestartCellTemperatures() { m_bms_bitset_t.clear(); - m_bms_bitset_v.resize(m_bms_readings_t); + m_bms_bitset_t.resize(m_bms_readings_t); m_bms_bitset_ct = 0; } On is a simple code readability change. Using an enum instead of magic status values for m_bms_talerts. Simple enough, but I'm prepared to simplify that to a standard enum or get rid of it. There's some battery related ones where I want to be able to not quite know the number of cells from the start and let the OBD responses specify. There's also a battery one where the info for the cells have different timings (because one has other info), so I want to be able to clear a range of cells rather than just reset and start filling the info again. I've modified slightly the dump for the battery cell voltage/temperature, allowing for either or both columns to be visible if available. It also copes with the above 'not set' scenario. Finally, the controversial one: I am using std::vector<uint8_t> as a buffer in my ioniq5 code.. and I wanted to be able to use it for the polling instead of std::string. I've not replaced the std::string but added the ability to have either. If my aversion to using std::string for binary data is misplaced, then I'm ok with the currently small modification to my code that would use the std::string version. Thoughts? Shall I just push the code up to my own repo? Merge request? //.ichael

2 16

Reboot under some load
by Ludovic LANGE 02 Nov '22

02 Nov '22

(I'm reposting because I had the impression that my message didn't get through. If it appears as a duplicate, please forgive me - and delete the double post if necessary. Still learning how to handle this delay between post and list visibility (moderation ?)) Hello List, I'm facing some reboots which looks like they are load-related (watchdog not triggered). I'll try to troubleshoot / diagnose it further but I thought it would be interesting to have your feedback on this. I'm currently tweaking a dashboard ; the idea is to have an in-vehicle display (WiFi-connected) showing a few important metrics to the driver (RPM / Speed / Voltage / SOC / multiple temperatures / range / controller status / BMS and cell status / ...) Don't know if images are OK in the list, here is a sample of the dashboard - you'll recognize the obvious lineage from the official OVMS dashboard: The metrics are coming from DBC analysis of the CAN bus traffic. For the tests I'm not in a vehicle, but am replaying CAN bus traffic and feeding it to OVMS (Not via the CAN play famework, as I still not had to time to look at https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/747 in details, but via a local CAN bus). There are (approximately) : * 1 message repeating each 3ms (333Hz) * 10 messages that are occurring each 10ms (100Hz) * 5 messages that are spaced by 100ms (10Hz) * 3 messages each 500ms (2Hz) CAN bus speed is 250.000. Metrics are properly generated (from DBC), and properly displayed on the dashboard. However, the combination of the "intense" bus traffic, + number of generated metrics seems to be, in some way, overflowing the capacity of the WebSocketHandler, which results in a reboot from time to time: > W (5111095) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow resolved, 14 drops > W (5111095) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow detected > I (5111105) metrics: Modified metric v.g.current: 0A > I (5111105) metrics: Modified metric v.m.rpm: 763 > I (5111115) metrics: Modified metric v.i.temp: 34.1°C > W (5111115) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow detected > W (5111125) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow detected > I (5111125) metrics: Modified metric v.m.rpm: 765 > W (5111135) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow detected > I (5111145) metrics: Modified metric v.m.rpm: 758 > W (5111145) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow detected > I (5111155) metrics: Modified metric v.m.rpm: 756 > W (5111155) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow resolved, 7 drops > I (5111165) metrics: Modified metric v.m.rpm: 760 > W (5111175) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow resolved, 1 drops > W (5111185) websocket: WebSocketHandler[0x3f8d1654]: job queue > overflow E (5111845) task_wdt: Task watchdog got triggered. The > following tasks did not reset the watchdog in time: > E (5111845) task_wdt: - IDLE1 (CPU 1) > E (5111845) task_wdt: Tasks currently running: > E (5111845) task_wdt: CPU 0: wifi > E (5111845) task_wdt: CPU 1: OVMS Console > E (5111845) task_wdt: Aborting. > abort() was called at PC 0x400e9920 on core 0 > > ELF file SHA256: 51b422e8c864d36f > > Backtrace: 0x4008ddca:0x3ffb0690 0x4008e065:0x3ffb06b0 > 0x400e9920:0x3ffb06d0 0x40084176:0x3ffb06f0 > > Rebooting... > ets Jul 29 2019 12:21:46 > > rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) > configsip: 0, SPIWP:0xee > clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 > mode:DIO, clock div:2 > load:0x3fff0018,len:4 > load:0x3fff001c,len:4796 > load:0x40078000,len:0 > load:0x40078000,len:14896 > entry 0x40078d74 > I (1068) psram: This chip is ESP32-D0WD > I (1068) spiram: Found 64MBit SPI RAM device Please note that the Lab setup has: * OVMS connected to the Lab network * The computer (displaying the dashboard) also connected to the Lab network (While, in the car, the computer / tablet would be directly connected to OVMS' wifi) That's it for the context, now a few questions: * As I don't know about the capabilities of the OVMS for CAN bus traffic analysis, does it looks like the number / frequency of messages I'm injecting is unreasonable ? * It seems like there is a buffering / consolidation of the metrics before sending them to the web socket ; is this tweakable in some way ? * Does the DBC processor add a significant processing time (compared to a dedicated vehicle module) when processing CAN data ? * What would be the best way to diagnose / confirm the health of the processes involved here ? * any similar use case / feedback from you ? Thanks for any feedback. Regards, Ludovic.

3 3

Improvements to BMS command display
by Michael Geddes 01 Nov '22

01 Nov '22

Hi all, I'll create a PR soon, but just wanted to ask something first. I've made the 'bms' command so that it will work with temperature OR voltages and only display that one column. For example: OVMS# bms Temperature: Average: 3.6C [ 3.6C - 3.6C] Deviation: SD 0.00C [max 0.48C], 0 warnings, 0 alerts Cells: +--------+ 1 | 14.0C | +--------+ 2 | 14.0C | +--------+ 3 | 14.0C | +--------+ 4 | 15.0C | +--------+ 5 | 14.0C | +--------+ 6 | 3.6C | +--------+ 7 | 3.6C | +--------+ 8 | 3.6C | +--------+ 9 | 3.6C | +--------+ 10 | 3.6C | +--------+ 11 | 3.6C | +--------+ 12 | 3.6C | +--------+ 13 | 3.6C | +--------+ 14 | 3.6C | +--------+ 15 | 3.6C | +--------+ 16 | 3.6C | +--------+ The other improvement I'm trying, and want some feedback on is when you have readings-per-module set > 4. Here I don't have it set quite right.. but you get the idea. The setting is at 12, which ends up being quite wide (yes, there's one temperature sensor off on its own, so my setting is not quite right yet). At the moment the column count is capped at 4 (and will cope with it not dividing properly), but the idea would be something along the lines of trying n % 3 and n % 5 first and then 4. So cap the column count at 3, 5 or 4 depending. The idea is that this becomes readable in the APP! Thoughts? OVMS# bms Voltage: Average: 3.632V [3.620V - 3.640V] Deviation: SD 9.75mV [max 0.00mV], 0 warnings, 0 alerts Temperature: Average: 14.0C [ 13.0C - 15.0C] Deviation: SD 0.35C [max 0.48C], 0 warnings, 0 alerts Cells: +-----------------------------+--------+ 1 | 3.640V 3.640V 3.640V 3.640V | 14.0C | | 3.640V 3.620V 3.640V 3.640V | | | 3.640V 3.640V 3.640V 3.620V | | +-----------------------------+--------+ 2 | 3.620V 3.620V 3.640V 3.640V | 14.0C | | 3.620V 3.620V 3.640V 3.640V | | | 3.640V 3.640V 3.640V 3.620V | | +-----------------------------+--------+ 3 | 3.620V 3.640V 3.640V 3.640V | 14.0C | | 3.640V 3.620V 3.640V 3.640V | | | 3.640V 3.640V 3.640V 3.620V | | +-----------------------------+--------+ 4 | 3.620V 3.640V 3.640V 3.640V | 14.0C | | 3.640V 3.620V 3.640V 3.640V | | | 3.640V 3.640V 3.620V 3.620V | | +-----------------------------+--------+ 5 | 3.620V 3.620V 3.640V 3.640V | 14.0C | | 3.640V 3.640V 3.640V 3.640V | | | 3.640V 3.640V 3.620V 3.620V | | +-----------------------------+--------+ 6 | 3.640V 3.640V 3.640V 3.640V | 15.0C | | 3.640V 3.620V 3.620V 3.640V | | | 3.640V 3.620V 3.620V 3.620V | | +-----------------------------+--------+ 7 | 3.640V 3.640V 3.640V 3.640V | 13.0C | | 3.620V 3.620V 3.620V 3.620V | | | 3.640V 3.640V 3.620V 3.620V | | +-----------------------------+--------+ 8 | 3.620V 3.640V 3.620V 3.640V | 14.0C | | 3.640V 3.620V 3.620V 3.620V | | | 3.640V 3.640V 3.620V 3.620V | | +-----------------------------+--------+ 9 | 3.640V 3.640V 3.640V 3.640V | 14.0C | | 3.620V 3.620V 3.620V 3.620V | | | 3.640V 3.620V 3.640V 3.640V | | +-----------------------------+--------+ 10 | 3.620V 3.640V 3.640V 3.620V | 14.0C | | 3.640V 3.620V 3.640V 3.640V | | | 3.640V 3.640V 3.640V 3.640V | | +-----------------------------+--------+ 11 | 3.620V 3.640V 3.640V 3.640V | 14.0C | | 3.640V 3.620V 3.640V 3.640V | | | 3.620V 3.620V 3.640V 3.620V | | +-----------------------------+--------+ 12 | 3.620V 3.620V 3.620V 3.620V | 14.0C | | 3.620V 3.620V 3.640V 3.640V | | | 3.640V 3.640V 3.640V 3.620V | | +-----------------------------+--------+ 13 | 3.620V 3.620V 3.640V 3.640V | 14.0C | | 3.640V 3.620V 3.620V 3.640V | | | 3.640V 3.640V 3.640V 3.620V | | +-----------------------------+--------+ 14 | 3.620V 3.620V 3.640V 3.640V | 14.0C | | 3.620V 3.620V 3.620V 3.620V | | | 3.620V 3.620V 3.640V 3.620V | | +-----------------------------+--------+ 15 | 3.620V 3.640V 3.640V 3.640V | 14.0C | | 3.640V 3.640V 3.640V 3.640V | | | 3.640V 3.640V 3.640V 3.640V | | +-----------------------------+--------+ 16 | | 14.0C | | | | | | | +-----------------------------+--------+ OVMS#

2 5

Absence
by Mark Webb-Johnson 31 Oct '22

31 Oct '22

Apologies for my abrupt absence from this group for the past month. It started with my getting COVID-19 quite bad, and then immediately on recovery had to rush to UK to deal with my father’s emergency health issues. It has not been a good month, and I have been quite overwhelmed. Anyway, I am back in HK and things are somewhat stable now. I’m catching up. If there is anything urgent that anyone is waiting for, please forward on to my personal eMail. Otherwise, I’ll review what I missed here and answer as soon as I can. Regards, Mark.

1 0

Support system comment on Twizy and Smart EQ
by Mark Webb-Johnson 31 Oct '22

31 Oct '22

Received this comment in the support system. Passing it on here for general information only, and no response needed: first of all thank you for your awesome work. I have buyed an OVMS v3 almost two years ago for my renault Twizy and I'm very happy, also for your kindly support. I have a suggestion: if the OVMS module can sense the press of D and R buttons on the Twizy, it could be possible to change tuning maps simply by pushing and mantaining pressed for 2 secs the D button (when not in motion) in order to set the next tuning map. What do you think about it? And I have another question: I'll probably change my Twizy with a 2019 Smart EQ. Do you think I will still able to tune the regen brake and maybe the motor power? I have read the compatibility list for the Smart and it seams less compatible than Twizy Regards, Mark.

1 0