November 2022 - OvmsDev - Open Vehicles

Fwd: Tesla Model 3 LR development
by Michael Balzer 13 Nov '22

13 Nov '22

Adam Pisl offers to help in developing the Model 3 adapter. Is anyone working on this or able to help Adam in getting an initial setup? If so please contact him directly (cc me if you like). Regards, Michael -------- Weitergeleitete Nachricht -------- Datum: Sun, 13 Nov 2022 08:27:00 +0100 (CET) Von: carprofi(a)carprofi.cz An: dexter(a)dexters-web.de Hello, I have purchased Tesla 3 LR, and want to participate on testing of OVMS development. Could You help me with getting the proper OVMS kit? Adam Pisl <carprofi(a)carprofi.cz> -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Advice regarding BmsSetCell...
by Mark Webb-Johnson 12 Nov '22

12 Nov '22

The original Model S had a fairly simple to decode CAN bus message 0x6f2 with the first byte in range 0..1f and each message encoding 3 battery bricks, for a total of 96 bricks. However, things have now got more complicated. A 75kWh Model X, and a replacement pack for a 85kWh Model S, contain cut-down packs with modules missing, so 0x6f2 only contains 28 messages, for 84 bricks, with bricks #15, #16, #17 and #31 missing from the message. When we feed this into BmsSetCell… calls, the OVMS BMS support code sees the missing bricks, assumes things are missing, and refuses to give an output. So my (hopefully simple) question, is how to tell it the brick arrangement? Or how to deal with these missing bricks? Regards, Mark.

3 3

Re: [Ovmsdev] Automatic naming of CAN log files
by Ludovic LANGE 10 Nov '22

10 Nov '22

I do agree with you, and I do the same on any system which has a battery-backed RTC and a persistent network connexion (taking care also of timezone issues)... However, I'm afraid that after a module reboot it may take a few seconds to retrieve a correct time. Also, when running without GPS, without network and without modem (which seems a supported, even if unusual, configuration), it seems that I'll never have a correct time at all. In both cases, the module will always start with Unix epoch (1970-01-01-00:00:00) for at least a few seconds, and so risk the risk to overwrite log files do exist (as the log starts as soon as possible). Of course, I'm running in that configuration (no modem, very often without Wifi, GPS not always having time) otherwise it would not be fun... :-( So that's why I wanted to be independent of time. But it would not be complex to support both syntaxes, to offer this choice. Ludovic Le 09/11/2022 à 22:57, Craig Leres a écrit : > On 11/9/22 13:52, Ludovic LANGE wrote: >> Naming would be 'automatic' with something like : >> `/sd/log/<vehicleid>/<#power on>/<log prefix>/<#rotations>.<log >> extension>` > > When I auto-name log or trace files I like to use the date and time. > This format sorts nicely and makes it easy to find the file that > contains the date+time of interest. So I would counter-propose: > > YYYY-MM-DD-HH:MM:SS.<log extension> > > Craig

1 0

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

09 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

netreg and new crash?
by Craig Leres 09 Nov '22

09 Nov '22

I have been having a lot of issues with netreg over the last few weeks. But Sunday when I built a new image I noticed some stack sizes had changed between my sdkconfig and support/sdkconfig.default.hw31. (I normally run with basically the support version but with most vehicles turned off and ) I remember a thread I didn't follow closely about the increasing the size of the stack. Anyway, I built and booted that version (3.3.003-71-g5c873b72). And hadn't had a netreg issue for more than a day across my three active modules. Arriving home a few minutes ago I had a fresh netreg issue (the first with this build). But it turned out to maybe be a crash... Last boot was 521 second(s) ago Time at boot: 2022-11-07 22:53:04 PST This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Reset reason: Exception/panic (4) Crash counters: 3 total, 0 early Last crash: abort() was called on core 1 Current task on core 0: IDLE0, 524 stack bytes free Current task on core 1: OVMS NetMan, 512 stack bytes free Backtrace: 0x400891af 0x40089449 0x40261021 0x4023d1a2 0x40236f4a 0x4023893f 0x40247d73 0x40238c0e 0x40238c39 0x40127340 0x401289ec 0x4012a135 0x4012a65b 0x40126b4e 0x4011b053 0x4011b0f1 Version: 3.3.003-71-g5c873b72-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Nov 6 2022 10:35:33) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 Which decodes as: xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891af 0x40089449 0x40261021 0x4023d1a2 0x40236f4a 0x4023893f 0x40247d73 0x40238c0e 0x40238c39 0x40127340 0x401289ec 0x4012a135 0x4012a65b 0x40126b4e 0x4011b053 0x4011b0f1 .../esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 .../esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 .../esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272 .../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349 .../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 .../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 .../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894 .../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 .../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 main/ovms_netmanager.cpp:1036 main/ovms_netmanager.cpp:1036 diff'ing my sdkconfig against support/sdkconfig.default.hw31 I was surprised to find that CONFIG_MDNS_TASK_STACK_SIZE was missing from mine; I added it back (again), nuked the build directory and rebuilt... and it was missing again: ice 616 % diff sdkconfig support/sdkconfig.default.hw31 | fgrep -v CONFIG_OVMS_VEHICLE 209c209 < CONFIG_SPIRAM_CACHE_WORKAROUND= --- > CONFIG_SPIRAM_CACHE_WORKAROUND=y 667,684c667,685 --- 687,692c688,693 --- 833a835 > CONFIG_MDNS_TASK_STACK_SIZE=3072 What's the story with CONFIG_MDNS_TASK_STACK_SIZE? Craig

2 1

Thoughts on Metrics - new 'standard metric' candidates and right drive cars
by Michael Geddes 09 Nov '22

09 Nov '22

Hi all, I started this thought following up on my Ioniq 5 thread - but figured it might be worth a new conversation. Michael B talked about having some new standard metrics (and also some consistent metric names in my i5 code: patch coming now that I understand a bit better why those exist). The Door Locked series is obviously a good start - the candidate names being pretty straight forward imho. v.d.l.fl v.d.l.fr v.d.l.rl v.d.l.rr Most cars these days would have seatbelt sensors - so they might also be a candidate. v.sb.fl etc. That being said, I have some issues related to 'right-hand-drive' vehicles which are quite popular in Australia ;). For a start, there's no metric for it; obviously some cars implementations will have a setting. For the Hyundai this is important as it seems many left/right settings are actually based on drive/passenger side in the OBD bits. Sooo.. I was considering some of the issues: 1) When it's on a diagram or in a user message, we want left/right because that's how we want to deal with it. 2) In general scared scripts, we probably care more about whether it is drive/passenger side rather than left/right! Could we have some metric alias's for left/right metrics that would be drive/passenger that would allow * Setting via either metric * Reading via either metric * Adding events based on either metric. For eg v.d.l.fl links to * v.d.l.fd (front driver) for Left-hand drive and * v.d.l.fp (front passenter) for Right-hand drive cars. I mean we could set both metrics.. but would that work? Thoughts on this? //.ichael

2 5

Introduction
by Douglas Urner 08 Nov '22

08 Nov '22

Hello, I’m interested in “rationalizing” our EV experience — and having a coding project to share with my daughter and nephews — so I’ve decided to see what I can do with OVMS. We have a 2022 Kia Niro EV and a 2023 Chevrolet Bolt 2LT. My hope is to be able to use the OVMS app in place of the Kia UVO and Chevrolet On Star apps, so I’m quite interested in working on Bolt support, and the possibility of getting the remote start (e.g., cabin preheat) working on the Niro. My software development background is primarily with OS development and maintenance (BSD Unix). These days I’m teaching high school CS, so I’m eager to have a “real” project to work on. With luck, my OVMS hardware will be arriving this week. Best, Doug — Douglas Urner (he/they) | dlu(a)canishe.com | +1 360.769.5565

3 3

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

Ovms Module availability for Australia / Asia
by Michael Geddes 02 Nov '22

02 Nov '22

Hi, was talking to somebody on facebook who is interested in OVMS but all the 4G Ovms modules on Fasttech are discontinued, (and the base one without 4g is out of stock). Is there some known reason why this is so? I'm also assuming that the EU ones have some differing Telcoms standards or something? Or are they OK? I do know that the SIM is not going to work here.. but apart from that... //.ichael

2 2

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