April 2018 - OvmsDev - Open Vehicles

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 7aa91a: SD card: fix insertion/removal detection
by Mark Webb-Johnson 14 Apr '18

14 Apr '18

Thanks for this, @Michael. My bad. Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 7aa91a: SD card: fix insertion/removal detection > Date: 14 April 2018 at 5:46:35 PM HKT > To: mark(a)webb-johnson.net > Reply-To: GitHub <noreply(a)github.com> > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 7aa91acd0b1554fa5918c68b4484e72fc97c33b9 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7aa… > Author: Michael Balzer <balzer(a)expeedo.de> > Date: 2018-04-14 (Sat, 14 Apr 2018) > > Changed paths: > M vehicle/OVMS.V3/components/sdcard/src/sdcard.cpp > M vehicle/OVMS.V3/components/sdcard/src/sdcard.h > > Log Message: > ----------- > SD card: fix insertion/removal detection > >

1 0

changes.txt
by Michael Balzer 13 Apr '18

13 Apr '18

A suggestion for the changes.txt: I thought and now suggest this file is intended as an extract of high level changes, i.e. changes that extend or change the user interface and/or features of the system, but not bug fixes or internal reworks. A log of all changes can be created automatically from the git log, no need to do that manually. git log --oneline --no-merges 3.1.000.. If we add all commits, users will stop reading this file. If we reduce it to high level entries, it becomes a valuable info for users. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 8

Support Help
by Mark Webb-Johnson 12 Apr '18

12 Apr '18

The 3.1 boxes have started arriving, and requests for support start coming in. So far, mostly just things due to lack of documentation (things like baud rate for USB serial connection not being documented anywhere). The users seem to be reasonable technically competent so far (which was the original plan). We have a new support ticket system now running at www.openvehicles.com. If anyone can volunteer to help support users, that would be most appreciated. Just take on the cases you can, or answer those that you have particular expertise with. It would be helpful if those responsible for individual vehicles / functionality could sign up anyway and just take on the cases (or be assigned them) when someone asks about those specific area of expertise. Another way to help out is to have a periodic review of the support tickets, and take common requests and provided answers, to update the User Guide with the information. If you can volunteer some support time, just let me have your login ID or eMail address you use on www.openvehicles.com, and I will upgrade your permissions to let you view and/or help with support tickets. The tickets themselves are relatively easy to handle. Once you have permissions set on your account, you’ll see a “Support tickets” link appear in the navigation side bar. Users raise tickets, and they are assigned to support volunteers. The tickets can be answered, and everyone involved on that particular ticket is automatically emailed the response. I’m trying to get the eMail integration working, but for the moment the tickets need to be updated from the web site interface. No specific time commitment necessary. Just help out whenever you can. Thanks, Mark.

2 3

Re: [Ovmsdev] leaf odometer
by Dean MacGregor 12 Apr '18

12 Apr '18

I don't know if this helps since it's not OVMS databut I have US Leaf with miles on instrument panel but leaf spy shows odometer in km On Wed, Apr 11, 2018 at 12:14 PM, ovmsdev-request(a)lists.openvehicles.com<ovmsdev-request(a)lists.openvehicles.com> wrote: Send OvmsDev mailing list submissions to ovmsdev(a)lists.openvehicles.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.openvehicles.com/mailman/listinfo/ovmsdev or, via email, send a message with subject or body 'help' to ovmsdev-request(a)lists.openvehicles.com You can reach the person managing the list at ovmsdev-owner(a)lists.openvehicles.com When replying, please edit your Subject line so it is more specific than "Re: Contents of OvmsDev digest..." Today's Topics: 1. Leaf Odometer Units (Tom Parker) 2. Re: changes.txt (Michael Balzer) ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Apr 2018 21:55:14 +1200 From: Tom Parker <tom(a)carrott.org> To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> Subject: [Ovmsdev] Leaf Odometer Units Message-ID: <6496e407-cef0-ef76-96d2-86c174107291(a)carrott.org> Content-Type: text/plain; charset=utf-8; format=flowed Hi, I'm parsing the Leaf odometer out of the car can bus messages (something that wasn't possible on the ovms v2). The leaf apparently sends the odometer in km or miles, depending on the dashboard units. I'm detecting the units and setting them on the ovms metric, but I can only test on a car that records km. If it doesn't understand the units it does not populate the odometer value at all. When someone gets an OVMS on Leaf which shows it's odometer in miles can you please let me know if your odometer metric remains zero, is reported with the correct units, or reported with the wrong units. Thanks. ------------------------------ Message: 2 Date: Wed, 11 Apr 2018 18:13:41 +0200 From: Michael Balzer <dexter(a)expeedo.de> To: ovmsdev(a)lists.openvehicles.com Subject: Re: [Ovmsdev] changes.txt Message-ID: <5777c152-653e-5af7-ba9f-98ed48f2c3ac(a)expeedo.de> Content-Type: text/plain; charset="utf-8" Mark, I would reduce this much further to: ????-??-?? ???? ???????? OTA release - Tesla Model S: Support v.bat.soc, v.pos.speed and park/drive status metrics This is IMO the only change from the current log a normal user needs to know about. The SD card configuration is on the edge, I would remove that entry from the user info as well, as a normal user will (should) not need to touch these configs: - SD CARD: Provide configurable sdcard parameters: ??? sdcard [maxfreq.khz] = 16000???????? Maximum frequency (in kHz) of SD CARD bus ??? sdcard [automount] = yes???????????? Automatically mount SD CARD on insertion The DebugCrash records info is also on the edge, I would now also remove that from the changes file as no normal user can make use of that info: - Boot: store & send crash debug info (*-OVM-DebugCrash records) The remaining changes are bug fixes or internal stuff no user needs to know, only developers: - Wifi: Increase scan responsiveness (60 seconds -> 10, on first scan) - Server v2: Introduce a 50ms delay between setting charge mode and current in same command - Core: Changes to housekeeping and events tasks to move event delivery and housekeeping actions ? to the event task (removing housekeeping task) - Core: Enable watchdogs for production builds - SD CARD: Reliability improvements to SD CARD auto-mounting on insertion - Core: Introduce protection for thread safety while logging, to workaround ESP IDF bug ? https://github.com/espressif/esp-idf/issues/1837 All this can be reduced to a single line "lots of bug fixes and optimizations". Am I too radical on this? Regards, Michael Am 11.04.2018 um 02:06 schrieb Mark Webb-Johnson: > > Yes, that is the intention. For v2, I generally did this for each firmware release by doing a ?git lola? (like your 'git log --oneline --no-merges?), going > through the changelog, and updating the changes.txt with non technical translations of core functionality changes. Trivial changes were not recorded in > changes.txt. > > I just reviewed the latest, and this is what I came up with: > > $ git log --oneline --no-merges 3.1.003 master > aeb7728 (HEAD -> master) Tesla Model S: Refinements for v.e.handbrake and Mph/Kph support > 52e8214 (origin/master, origin/HEAD) Web shell: touch keyboard optimization > 2eab5d3 Provide configurable parameters for sdcard: sdcard [maxfreq.khz] = 16000 sdcard [automount] = yes > a2804b8 Add ovms_utils.h for FormatHexDump. > 343ad45 Reimplement setting console prompt for secure mode > 09f6f6b Tesla Model S: Use 32bit arithmetic for data decoding > ed4d700 Tesla Model S: Use 32bit arithmetic for data decoding > 6f732b2 Improve hexdump of 're list' to show ascii printable characters. > 82cccc7 Tesla Model S: Gear selector - on/awake > 3e0d5b1 TeslaModelS: v.bat.soc and v.pos.speed metrics > e898c1b TeslaModelS: Fix for metric v.bat.soc > c5bc34a TeslaModelS: Fix for metric v.pos.speed > ad46fb2 Clone data passed to SignalEvent > ed32467 Default production config support for ESP IDF panic stub > b38b0ef Mutex protect fsync function call, on logging, to workaround ESP IDF bug https://github.com/espressif/esp-idf/issues/1837 > 37c5f4b Boot: store & send crash debug info (*-OVM-DebugCrash records) Note: needs esp-idf update (daef4b5c11a646b7149bf3534e338f3070ae3abf) > 1bcbef9 Clone data passed to SignalEvent > d9931cb Changelog update > be39917 Run SD CARD automount in Events task context, not Timer. > f0969a3 Refactor housekeeping/events tasks to use Events task for signal dispatch and housekeeping. > 97775cf OVMS task naming cleanup > 90c00b8 Enable watchdog reset for production builds > fde6d8d OVMS task naming cleanup > f6a8de5 changes.txt update > 7ea18b4 Server v2: Delay 50ms on cmd #16 (between setting mode and current) > 21e4110 Increase wifi scan responsiveness > > > Becomes: > > ????-??-?? ??? ???????? ?OTA release > ? ? ? ? ? ? ? ? ? ? ? ? ?- Wifi: Increase scan responsiveness (60 seconds -> 10, on first scan) > ? ? ? ? ? ? ? ? ? ? ? ? ?- Server v2: Introduce a 50ms delay between setting charge mode and current in same command > ? ? ? ? ? ? ? ? ? ? ? ? ?- Core: Changes to housekeeping and events tasks to move event delivery and housekeeping actions > ? ? ? ? ? ? ? ? ? ? ? ? ? ?to the event task (removing housekeeping task) > ? ? ? ? ? ? ? ? ? ? ? ? ?- Core: Enable watchdogs for production builds > ? ? ? ? ? ? ? ? ? ? ? ? ?- SD CARD: Reliability improvements to SD CARD auto-mounting on insertion > ? ? ? ? ? ? ? ? ? ? ? ? ?- SD CARD: Provide configurable sdcard parameters: > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sdcard [maxfreq.khz] = 16000 ? ? ? ? Maximum frequency (in kHz) of SD CARD bus > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sdcard [automount] = yes ? ? ? ? ? ? Automatically mount SD CARD on insertion > ? ? ? ? ? ? ? ? ? ? ? ? ?- Boot: store & send crash debug info (*-OVM-DebugCrash records) > ? ? ? ? ? ? ? ? ? ? ? ? ?- Core: Introduce protection for thread safety while logging, to workaround ESP IDF bug > ? ? ? ? ? ? ? ? ? ? ? ? ? ?https://github.com/espressif/esp-idf/issues/1837 > ? ? ? ? ? ? ? ? ? ? ? ? ?- Tesla Model S: Support v.bat.soc, v.pos.speed and park/drive status metrics > > > This process is helped if people can include full information in their commit messages - in particular for changes that impact features, usage, provide new > options, etc - anything that is going to affect or be visible to the user. > > Currently, the firmware download server has a file (http://api.openvehicles.com/firmware/ota/[v3.0|v3.1]/<tag>/ovms3.ver > <http://api.openvehicles.com/firmware/ota/%5Bv3.0%7Cv3.1%5D/%3Ctag%3E/ovms3.…>) that stores a one-line ?current version?. I plan to change that to include > the last few releases for changes.txt (as well as the version). That way, ?ota status? can show the changes in the latest version as well as the version > number itself). > > Regards, Mark. > >> On 11 Apr 2018, at 5:31 AM, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >> >> A suggestion for the changes.txt: >> >> I thought and now suggest this file is intended as an extract of high level changes, i.e. changes that extend or change the user interface and/or features of >> the system, but not bug fixes or internal reworks. >> >> A log of all changes can be created automatically from the git log, no need to do that manually. >> >> git log --oneline --no-merges 3.1.000.. >> >> If we add all commits, users will stop reading this file. If we reduce it to high level entries, it becomes a valuable info for users. >> >> 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 > > > > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Leaf Odometer Units
by Tom Parker 11 Apr '18

11 Apr '18

Hi, I'm parsing the Leaf odometer out of the car can bus messages (something that wasn't possible on the ovms v2). The leaf apparently sends the odometer in km or miles, depending on the dashboard units. I'm detecting the units and setting them on the ovms metric, but I can only test on a car that records km. If it doesn't understand the units it does not populate the odometer value at all. When someone gets an OVMS on Leaf which shows it's odometer in miles can you please let me know if your odometer metric remains zero, is reported with the correct units, or reported with the wrong units. Thanks.

1 0

ssh: secure mode prompt not set #31
by Mark Webb-Johnson 11 Apr '18

11 Apr '18

Steve, Can you have a look at this one: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/31 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/31> When connecting to the box via ssh, using a trusted ssh.keys mechanism, it seems that the session is correctly put into secure mode (enable). But, the prompt is OVMS> (should be OVMS#). The full set of enable commands is shown, so pretty sure the session is in enable mode. I think the issue is purely the prompt being incorrect. I think (hope) it should be simple. Thanks, Mark.

3 4

Crash debugging
by Michael Balzer 11 Apr '18

11 Apr '18

I've pushed an update to enable saving crash data over a reset and automatically send that to the server using the history record "*-OVM-DebugCrash". Note: you will need to pull the esp-idf as well. As the support for exception handlers was insufficient for our needs, I have added a separate error handler registration that catches all three kinds of crashes (exceptions, panics and aborts). Crash reason, registers (if available) and backtrace are available via "boot status", with "make monitor" automatically mapping the addresses: OVMS# boot status Last boot was 16 second(s) ago This is reset #1 since last power cycle Detected boot reason: Crash Crash counters: 1 total, 0 early CPU#0 boot reason was 12 CPU#1 boot reason was 12 Last crash: abort() was called on core 1 Backtrace: 0x4008f698 0x4008f86f 0x400e7027 0x400edb76 0x400edc8d 0x400edc7f 0x400edcb5 0x400e3908 0x400f11c9 0x400f1230 0x400e3937 0x401cb613 0x400e3f49 0x400e82e5 0x400e84d1 0x400e3df5 0x400e3e04 0x400e69dd 0x4008f698: invoke_abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x4008f86f: abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x400e7027: module_fault(int, OvmsWriter*, OvmsCommand*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:823 0x400edb76: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc8d: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc7f: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edcb5: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e3908: Execute(microrl*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47 0x400f11c9: new_line_handler at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:620 0x400f1230: microrl_insert_char at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:668 0x400e3937: OvmsShell::ProcessChar(char) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:70 0x401cb613: OvmsShell::ProcessChars(char const*, int) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:77 (discriminator 2) 0x400e3f49: ConsoleAsync::HandleDeviceEvent(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:169 0x400e82e5: OvmsConsole::Poll(unsigned int, void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:152 0x400e84d1: OvmsConsole::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:132 (discriminator 1) 0x400e3df5: ConsoleAsync::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:80 0x400e3e04: non-virtual thunk to ConsoleAsync::Service() at ??:? 0x400e69dd: TaskBase::Task(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:156 The "*-OVM-DebugCrash" record has this structure: // H type "*-OVM-DebugCrash" // ,<firmware_version> // ,<bootcount>,<bootreason_name>,<bootreason_cpu0>,<bootreason_cpu1> // ,<crashcnt>,<earlycrashcnt>,<crashtype>,<crashcore>,<registers>,<backtrace> …with registers and backtraces separated by spaces. Example: *-OVM-DebugCrash,0,2592000,3.1.003-11-g37c5f4b/factory/main (build idf v3.1-dev-453-g0f978bcb-dirty Apr 8 2018 14:42:07),1,Crash,12,12,1,0,abort(),1,,0x4008f698 0x4008f86f 0x400e7027 0x400edb76 0x400edc8d 0x400edc7f 0x400edcb5 0x400e3908 0x400f11c9 0x400f1230 0x400e3937 0x401cb613 0x400e3f49 0x400e82e5 0x400e84d1 0x400e3df5 0x400e3e04 0x400e69dd To decode the backtrace, feed it to addr2line: balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> xtensa-esp32-elf-addr2line -pfiaC -e build/ovms3.elf 0x4008f698 0x4008f86f 0x400e7027 0x400edb76 0x400edc8d 0x400edc7f 0x400edcb5 0x400e3908 0x400f11c9 0x400f1230 0x400e3937 0x401cb613 0x400e3f49 0x400e82e5 0x400e84d1 0x400e3df5 0x400e3e04 0x400e69dd 0x4008f698: invoke_abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x4008f86f: abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x400e7027: module_fault(int, OvmsWriter*, OvmsCommand*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:823 0x400edb76: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc8d: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc7f: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edcb5: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e3908: Execute(microrl*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47 0x400f11c9: new_line_handler at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:620 0x400f1230: microrl_insert_char at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:668 0x400e3937: OvmsShell::ProcessChar(char) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:70 0x401cb613: OvmsShell::ProcessChars(char const*, int) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:77 (discriminator 2) 0x400e3f49: ConsoleAsync::HandleDeviceEvent(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:169 0x400e82e5: OvmsConsole::Poll(unsigned int, void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:152 0x400e84d1: OvmsConsole::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:132 (discriminator 1) 0x400e3df5: ConsoleAsync::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:80 0x400e3e04: non-virtual thunk to ConsoleAsync::Service() at ??:? 0x400e69dd: TaskBase::Task(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:156 There is also an option to write core dumps in esp-idf, but a core has 64K, and crashes are still too many. I think the backtrace is sufficient in most situations. We should keep a central archive of .elf files for the releases rolled out, so we don't need to recompile for debugging. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 8

Commit 6f732b2 issue without CONFIG_OVMS_COMP_OBD2ECU
by Julien “JaXX” Banchet 10 Apr '18

10 Apr '18

Hi, Just a heads up, seems commit 6f732b2 doesn’t like missing CONFIG_OVMS_COMP_OBD2ECU CXX build/pcp/pcp.o AR build/pcp/libpcp.a CC build/pthread/pthread.o CC build/pthread/pthread_cond_var.o CC build/pthread/pthread_local_storage.o AR build/pthread/libpthread.a CXX build/retools/src/retools.o /Users/jaxx/Projects/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/retools/src/retools.cpp: In function 'void re_list(int, OvmsWriter*, OvmsCommand*, int, const char* const*)': /Users/jaxx/Projects/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/retools/src/retools.cpp:260:91: error: 'FormatHexDump' was not declared in this scope FormatHexDump(&s, (const char*)it->second->last.data.u8, it->second->last.FIR.B.DLC, 8); ^ make[1]: *** [/Users/jaxx/Projects/esp-idf/make/component_wrapper.mk:274: src/retools.o] Error 1 make: *** [/Users/jaxx/Projects/esp-idf/make/project.mk:450: component-retools-build] Error 2 With CONFIG_OVMS_COMP_OBD2ECU=y it compiles fine. Regards, JB./.

2 1

Lost both modem and WiFi
by Greg D. 10 Apr '18

10 Apr '18

Hi folks, This occurred twice over the weekend... I took a trip in my Roadster with the OVMSv3 module hooked up. After the drive, I went to check on the car via the Android application, and it wouldn't connect. Thought perhaps it wasn't getting a good 3G signal where it was, and forgot about it overnight. But when I checked again in the morning, sill no connection. I looked in the car and saw that the modem was off (nothing blinking). Unplugged the module, and plugged it back in. All fine at that point. Charged the car for the trip home, and was able to monitor the charging just fine. Drove home late Sunday night, and when I looked at it again this morning (Monday), no modem blinks. Also failed connecting to it on the home WiFi, which it is configured to automatically connect to. I hooked up a serial port to the USB connector, and found that the module was running (OVMS prompts), but both the modem and wifi were reporting their status powered off! I just updated to today's code, and will try to reproduce the issue. In the mean time, any ideas what is going on? I do have scripts to control the ext12v power with vehicle_on and vehicle_off (to manage a HUD), but the HUD was not attached. Greg

2 1

Event task
by Mark Webb-Johnson 09 Apr '18

09 Apr '18

I’m seeing a timing/stack/mutex/whatever issue with the new 3.1 modules, regarding sd card auto-mounting at boot. Currently we are using a freertos timer to auto-mount this 500ms after insertion. That fires off some events (sd.inserted, sd.mounted) and I have a script on sd.mounted that does some things like turn on log file to /sd/ovms.log. That is failing (locking up SD). In general, as Michael pointed out, doing big things in freertos timers is not recommended. I tried a quick fix to change to use ticker.1 and housekeeping timers. But, then in ticker.1 we SignalEvent sd.inserted and sd.mounted, and that leads to a whole new set of problems (raising a signal inside a signal handler). Overall, it seems messy. The housekeeping task (where we like to run these things) is also very basic at the moment. I think the better solution maybe to remove the housekeeping task completely, and replace it with an event task reading events off a queue and firing them to all listeners. Then change SignalEvent to queue an event to the event task so that the event task fires the actual event in it’s own time and in it’s own large stack. The slight change here is that we would still guarantee in-order delivery of events raised, but the caller of SignalEvent would immediately get back control (even if the signal had not been dispatched to all listeners yet). OK? Any better suggestions? Regards, Mark

2 8