- OvmsDev - Open Vehicles

LCD Car Mount Display
by Mark Webb-Johnson 07 Apr '18

07 Apr '18

Having completed the v3.x hardware, and being a complete masochist for this, I’m now working with China to see what is possible as a display (for OVMS and other projects). The idea is to have a small enclosure that includes: A 3.5” backlit LCD display. Four touch buttons (as touch-screen too hard to use in a moving vehicle) - Up, Down, Enter, Back/Cancel. A WROVER32 (probably 4MB flash to keep costs down, but perhaps 16MB is possible). This has 4MB SPIRAM. MicroSD or SD card slot (full speed 4 wire). USB for firmware flashing and console access. Bluetooth Wifi Connection for: Power (12V regulated) Data (async bus) CAN (one single CAN bus) Expansion via internal GPIO headers OVMS firmware This could be a display for OVMS, or in general be a very flexible form of in-car or general purpose hacker display. The entire project would be geared towards getting the cost down. I’m trying to get an idea of what we can get this done for. What do people think? Is this any use? Regards, Mark. 1] Easily obtainable enclosure The idea being to use this along with a standard car mount (perhaps magnetic - there are lots) 2] Other examples, for comparison

4 13

LWIP lock-up
by Mark Webb-Johnson 06 Apr '18

06 Apr '18

My car managed to repeat the issue with the task lockup I have seen occasionally. The symptom is that network connectivity fails and the async console becomes unresponsive when you issue a command to bring up/down wifi, simcom, etc. The new housekeeping 10 minute ticker worked well for this, and stopped in the middle of the night: … I (134401020) housekeeping: Local time: Sat Mar 24 20:15:45 2018 I (135001020) housekeeping: Local time: Sat Mar 24 20:25:45 2018 I (135601020) housekeeping: Local time: Sat Mar 24 20:35:45 2018 I (136201020) housekeeping: Local time: Sat Mar 24 20:45:45 2018 Looking at the logs after Sat Mar 24 20:45:45, I see: D (136543060) simcom: rx line ch=4 len=19 : +PPPD: DISCONNECTED I (136543070) simcom: PPP Connection disconnected I (136544020) simcom: Lost network connection (+PPP disconnect in NetMode) I (136544020) simcom: State: Enter NetLoss state ... I (136544030) gsm-ppp: Shutting down (hard)... I (136544040) events: Signal(system.modem.down) I (136544040) netmanager: Interface priority is st1 (x.y.z.212/255.255.248.0 gateway x.y.z.64) I (136544050) events: Signal(network.modem.down) I (136544050) netmanager: MODEM down (with WIFI client up): staying with WIFI client priority I (136544060) events: Signal(network.interface.change) OK, so ppp went down (lost network connectivity), and WIFI client was up so we kept with that. The GSM signal is still up (CREG), so we try to reconnect PPP: I (136558160) simcom: PPP Connection is ready to start I (136559020) simcom: State: Enter NetMode state I (136559020) gsm-ppp: Initialising.. ... D (136589180) simcom: rx line ch=4 len=8 : +CREG: 2 I (136589190) simcom: CREG Network Registration: Searching ... D (136589250) simcom: rx line ch=4 len=8 : +CREG: 5^[[0m ^[[0;32mI (136589250) simcom: CREG Network Registration: RegisteredRoaming ... D (136589320) simcom: rx line ch=4 len=8 : +CREG: 2^[[0m ^[[0;32mI (136589320) simcom: CREG Network Registration: Searching ... D (136589380) simcom: rx line ch=4 len=8 : +CREG: 5^[[0m ^[[0;32mI (136589390) simcom: CREG Network Registration: RegisteredRoaming ... D (136601690) simcom: rx line ch=3 len=8 : +CREG: 2^[[0m ^[[0;32mI (136601690) simcom: CREG Network Registration: Searching ... D (136601780) simcom: rx line ch=3 len=8 : +CREG: 5^[[0m ^[[0;32mI (136601780) simcom: CREG Network Registration: RegisteredRoaming ... V (136617440) gsm-ppp: tx: 7e ff 7d 23 c0 21 7d 25 7d 2c 7d 20 20 4e 6f 20 | ~.}#.!}%},} No V (136617440) gsm-ppp: tx: 6e 65 74 77 6f 72 6b 20 70 72 6f 74 6f 63 6f 6c | network protocol V (136617450) gsm-ppp: tx: 73 20 72 75 6e 6e 69 6e 67 4b 8f 7e | s runningK.~ V (136617450) simcom: tx: f9 09 ff 59 7e ff 7d 23 c0 21 7d 25 7d 2c 7d 20 | ...Y~.}#.!}%},} V (136617450) simcom: tx: 20 4e 6f 20 6e 65 74 77 6f 72 6b 20 70 72 6f 74 | No network prot V (136617460) simcom: tx: 6f 63 6f 6c 73 20 72 75 6e 6e 69 6e 67 4b 8f 7e | ocols runningK.~ V (136617460) simcom: tx: a6 f9 | .. V (136617490) simcom: rx: f9 09 ff 25 7e ff 7d 23 c0 21 7d 26 7d 2c 7d 20 | ...%~.}#.!}&},} V (136617500) simcom: rx: 7d 24 8f 7d 3d 7e fb f9 | }$.}=~.. V (136617510) gsm-mux: ProcessFrame(CHAN=2, ADDR=09, CTRL=ff, FCS=fb, LEN=24) V (136617520) gsm-mux: ChanProcessFrame(CHAN=2, ADDR=09, CTRL=ff, LEN=21, IFP=3) V (136617520) gsm-ppp: rx: 7e ff 7d 23 c0 21 7d 26 7d 2c 7d 20 7d 24 8f 7d | ~.}#.!}&},} }$.} V (136617530) gsm-ppp: rx: 3d 7e | =~ I (136617540) gsm-ppp: StatusCallBack: Connection Lost E (136617540) gsm-ppp: status_cb: Connection lost I (136617550) gsm-ppp: Shutdown (via status callback) I (136617550) events: Signal(system.modem.down) I (136617560) netmanager: Interface priority is st1 (x.y.z.212/255.255.248.0 gateway z.y.z.64) I (136617560) gsm-ppp: Attempting PPP reconnecting in 30 seconds... So, while initialising PPP we’ve been told that the cellular network is down (CREG: 2). Then, it flaps up and down like a yoyo, until the PPP connect finally fails. At this point, things go screwy. The simcom tells us the PPP is down, and then we lose the ability to transmit to the modem (or at least log those transmits): V (136618650) simcom: rx: 50 50 50 44 3a 20 44 49 53 43 4f 4e 4e 45 43 54 | PPPD: DISCONNECT V (136618660) simcom: rx: 45 44 0d 0a d4 f9 f9 11 ff 2f 0d 0a 2b 50 50 50 | ED......./..+PPP V (136618660) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=d4, LEN=29) V (136618670) gsm-mux: ChanProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, LEN=26, IFP=3) D (136618680) simcom: rx line ch=3 len=19 : +PPPD: DISCONNECTED I (136618690) simcom: PPP Connection disconnected V (136618690) simcom: rx: 44 3a 20 44 49 53 43 4f 4e 4e 45 43 54 45 44 0d | D: DISCONNECTED. V (136618700) simcom: rx: 0a d9 f9 | ... V (136618710) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=d9, LEN=29) V (136618710) gsm-mux: ChanProcessFrame(CHAN=4, ADDR=11, CTRL=ff, LEN=26, IFP=3) D (136618720) simcom: rx line ch=4 len=19 : +PPPD: DISCONNECTED I (136618730) simcom: PPP Connection disconnected I (136619020) simcom: Lost network connection (+PPP disconnect in NetMode) I (136619020) simcom: State: Enter NetLoss state V (136619030) simcom: tx: f9 0d ff 19 41 54 2b 43 47 41 54 54 3d 30 0d 0a | ....AT+CGATT=0.. V (136619030) simcom: tx: 14 f9 | .. I (136619030) gsm-ppp: Shutting down (hard)...^[[0m I (136619040) events: Signal(system.modem.down)^[[0m I (136619040) netmanager: Interface priority is st1 (x.y.z.212/255.255.248.0 gateway x.y.z.64) V (136632920) simcom: rx: f9 0d ff 0d 0d 0a 4f 4b 0d 0a 0f f9 | ......OK.... V (153076210) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 31 2c 39 39 | ......+CSQ: 1,99 V (153076220) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (153076220) simcom: rx: 31 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 1,99..........+C V (153076230) simcom: rx: 53 51 3a 20 31 2c 39 39 0d 0a 1e f9 | SQ: 1,99.... V (153202470) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 34 2c 39 39 | ......+CSQ: 4,99 V (153202480) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (153202490) simcom: rx: 34 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 4,99..........+C V (153202500) simcom: rx: 53 51 3a 20 34 2c 39 39 0d 0a 1e f9 | SQ: 4,99.... V (179212720) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 30 2c 39 39 | ......+CSQ: 0,99 V (179212730) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (179212730) simcom: rx: 30 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 0,99..........+C V (179212740) simcom: rx: 53 51 3a 20 30 2c 39 39 0d 0a 1e f9 | SQ: 0,99.... V (179242750) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 30 2c 39 39 | ......+CSQ: 0,99 V (179242760) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (179242770) simcom: rx: 30 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 0,99..........+C V (179242770) simcom: rx: 53 51 3a 20 30 2c 39 39 0d 0a 1e f9 | SQ: 0,99.... V (179246100) simcom: rx: f9 09 ff 19 0d 0a 2b 43 52 45 47 3a 20 32 0d 0a | ......+CREG: 2.. V (179246110) simcom: rx: d6 f9 f9 0d ff 19 0d 0a 2b 43 52 45 47 3a 20 32 | ........+CREG: 2 V (179246110) simcom: rx: 0d 0a 14 f9 f9 11 ff 19 0d 0a 2b 43 52 45 47 3a | ..........+CREG: V (179246120) simcom: rx: 20 32 0d 0a 19 f9 | 2.... V (179251580) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 34 2c 39 39 | ......+CSQ: 4,99 V (179251590) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (179251600) simcom: rx: 34 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 4,99..........+C V (179251600) simcom: rx: 53 51 3a 20 34 2c 39 39 0d 0a 1e f9 | SQ: 4,99.... I (179290100) wifi: bcn_timout,ap_probe_send_start I (179292610) wifi: ap_probe_send over, resett wifi status to disassoc I (179292610) wifi: state: run -> init (1) I (179292620) wifi: pm stop, total sleep time: 0/138543477 I (179292620) wifi: n:13 0, o:13 0, ap:255 255, sta:13 0, prof:1 The simcom itself seems to be up, and is giving us unsolicited notifications. Finally, the wifi stack falls over (bcn_timeout.ap_probe_sent). This is very nasty, and I suspect will take some time to resolve. We can probably make it more stable by introducing a check for network loss, and requiring the network to be up and stable for N seconds before even attempting a reconnection; but I don’t think that addresses the core issue (which is most likely in the lwip ppp stack). Code-wise, the simcom driver entering ‘NetLoss’ state calls m_ppp.Shutdown(true) (which issues the shutting down (hard) message). Our pppos driver issues the system.modem.down event (which causes netmanager to do it’s thing), and then calls ppapi_close(m_ppp, nocarrier). I suspect that never returns (but don’t know for sure). The other workaround is to enable watchdog timers. I’m 99% certain this sort of lockup would mess up the idle tasks and those would pickup and fire a watchdog timer. So, I’ve gone ahead and committed code to enable the watchdog timers (2 minutes), and make that available as an OTA update: OVMS# ota status Firmware: 3.1.001/ota_0/main (build idf v3.1-dev-453-g0f978bcb Mar 25 2018 14:45:59) Server Available: 3.1.001 The module in my car is now running OTA, so I can verify the OTA update process is smooth (it seems so). Regards, Mark.

3 9

OVMS v3.1 stock
by Mark Webb-Johnson 05 Apr '18

05 Apr '18

I now have stock of OVMS v3.1. I need some for HK installs, but there are some spare (both US and EU kits, as well as bare OVMS modules without modems). You guys have got priority, but I don’t want to hold on to these too long. I would rather get them out into cars. If you need one, let me know ASAP. Email mark(a)webb-johnson.net with what you need. Price is same as Fasttech - US$130 (including $20 developer discount) plus US$12 postage (EU or US). Regards, Mark

3 3

OVMS v3 Unboxing
by Mark Webb-Johnson 04 Apr '18

04 Apr '18

Enjoy. Please share among your communities. Regards, Mark https://youtu.be/HpyI1q4Y89I

2 1

Task stack optimization
by Michael Balzer 04 Apr '18

04 Apr '18

I've done some stack size watching and pushed some optimizations: - CanRxTask: 4K → 1K - COrx Task: 4K → 3K [+config] - COwrk Task: 4K → 1.5K [+config] - Vrx Task: 4K → 3K [+config] - Tmr Svc: 6K → 3K Much better now, nearly no crashes during normal operation, so most crashes now have been memory related (I had normally 2-3 crashes during a normal drive). A single crash I had when getting back home may have been due to my PC reconnecting to the webserver in parallel to my phone. There are more stacks we possibly can reduce: - SIMCOMTask normally maxes out at 2.3K (of 4) - wifi ditto - mdns normally uses 1.7K of 4 (no config for that one, defined in esp mdns_private.h) These should normally have no larger stack requirements as their operation is pretty much fixed, so that would be another 4.5 - 5K to get. As stacks need to be pinned to the internal RAM, hw3.1 also should benefit from these optimizations. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 1

OBDII ECU Documentation, and a request for help
by Greg D. 04 Apr '18

04 Apr '18

Hi folks In a fit of prose, if not Shakespeare, I took a pass at creating the documentation chapter for the OBD2ECU task. Comments, corrections, and general feedback is requested. Is there anything significant missing? Mark, if this looks acceptable, can it be posted to the Google Doc, or send me an invite such that I can do so? Note that I don't have any reference material on the OBDII-to-DB26 cable, other than the wiring. If we eventually have a purchase source, that should get referenced, or lacking that, perhaps pointers to where the connectors can be purchased? Placeholders are noted, but only that. For the EEs in the group, a question: I have both signal and chassis grounds connected together on the OBDII connector; should they be, or just signal ground? I think it would also be helpful to include a table of what metrics are available (supported) on what vehicles, as an aid to those who want to remap things for monitoring on an OBDII HUD or Dongle. A glance at the available documentation didn't turn up anything, so I took a first pass at the table. See the attached, which includes what I know of the Roadster's implementation (since I have one and have studied the code a bit). I would rather not try to guess at the other cars. Could the various vehicle authors contribute their columns to the table? Send me an updated spreadsheet, and I will do the merge. Thanks! Greg

5 14

Time for an unboxing
by Mark Webb-Johnson 04 Apr '18

04 Apr '18

10xEU and 10xUS. I’ll try to get an unboxing video out later today.

2 2

Crash / reboot loop with log level Info
by Greg D. 03 Apr '18

03 Apr '18

4 24

Re: [Ovmsdev] OVMS v3.1 Availability
by Mark Webb-Johnson 02 Apr '18

02 Apr '18

And we’re sold out of EU kits in the first 5 hours. I’ve even had to redirect some of the stock coming to me, to Fasttech, to cope with demand. There are still US kits available (I guess USA is just waking up now). I hope everyone here who needs one got one. If not, let me know and I’ll see what can be done. Regards, Mark. > On 24 Mar 2018, at 3:52 PM, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > > > Attn: All OVMS users > > The first batch of production OVMS v3 modules and modems is now available for pre-order from fasttech.com <https://www.fasttech.com/search?ovms>. Specifications, Pricing, and details, follow. > > Bundle Kit: OVMS v3.1 module (US$90) + OVMS v3.1 modem (US$60) > > Existing users: US$130 (uses US$20 Fasttech discount coupon code offered to all existing OVMS v1/v2 users) > New users: US$150. > > Black injection-moulded plastic enclosure > ESP32 WROVER processor (16MB flash, 4MB SPI RAM, 520KB SRAM, dual core 160/240MHz Xtensa LX6 processor) > WIFI 802.11 b/g/n > Bluetooth v4.2 BR/EDR and BLE > 3x CAN buses > 1x Micro USB connector (for flash download and serial console) > 1x Micro SD card slot > 1x Internal expansion slot > 8x EGPIO, 2x GPIO > 1x GSM antenna connector > 1x GPS antenna connector > 1x DB9 vehicle connector > 1x DB26 expansion connector > OVMS v3.1 SIM5360E 3G modem module (either US or EU edition) > Modem is an optional plug-in module, that can be changed in future (to allow for new technology) > 3G (EV-DO/HSPA+) dual band modem > Includes 2G (GSM/GPRS) and 2.5G (EDGE) quad band > GPS/GNSS > Nano (4FF) SIM slot > HOLOGRAM.IO nano sim > US edition is SIM5360A (Dual-Band UMTS/HSPA+ 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz) > EU edition is SIM5360J(E) (Dual-Band UMTS/HSPA+ 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz) > > First Production Batch > > This first production batch is intended for experienced OVMS v2 users and v3 developers. Please note: > > Firmware is not complete, and should be considered beta > Functionality is approximately equivalent to basic OVMS v2 firmware, but some advanced features (such as ACC, SMS control, etc) are not available yet > Firmware is far in advance of v2 in other aspects (such as built in web server, metrics, console, tcp/ip support, diagnostics, geofencing, scripting, etc) > Firmware can be updated either Over The Air (OTA), by Micro SD card, or over USB interface > Vehicle support currently includes: Kia Soul EV, Nissan Leaf, Renault Twizy, Tesla Roadster > > Antenna and Vehicle Connectors > > The antenna and vehicle connectors for OVMS v3 are the same as for OVMS v2, and existing cables/antennas can generally be re-used for OVMS v3. Note, however, that the frequency ranges supported by individual 3G networks may be different than 2G, so may benefit from an antenna specifically designed for the 3G frequency ranges used. > > Coupon Code and Ordering Arrangements > > For existing OVMS v1 or v2 users, please login to www.openvehicles.com <http://www.openvehicles.com/>, then click My Account, then Vehicles. You will see the Fasttech coupon code next to your registered vehicle. When using the Fasttech ordering system, add the products you want to your cart, click View Cart, then “Have a coupon code?” to enter the code. > > We expect the first stock to arrive next week, and first shipments will start pretty soon after that. > > Should you wish to donate to the project, you can use this link to donate via PayPal: > > https://www.openvehicles.com/helpme <https://www.openvehicles.com/helpme> > > Regards, Mark. >

6 16

Anyone with a Tesla Roadster v1.5?
by Greg D. 01 Apr '18

01 Apr '18

Hi folks, I've added support for metrics v.b.current and v.b.power for the Tesla Roadster, but I can only test it on my 2.x car. Anyone with a 1.5, could you check to see that they working on that platform too? Also, if you have a HUD, I tried running the OBDII ECU task with a short script to replace the RPM display with something resembling battery power. Seems to work. The 2.x cars display this on the right-hand gauge on the instrument panel. The 1.5's only display RPM there, which is redundant with vehicle speed, so this might be an interesting real-world application for those cars. Many HUDs display the engine RPM in a big graphical arc, so it has a similar feel. The script is: OVMS> vfs cat /store/obd2ecu/12 speed=OvmsMetricFloat("v.p.speed"); power=OvmsMetricFloat("v.b.power"); out = 500.0; if(speed > 1) { out=power*40; } out; This should also work for other cars that support the vehicle speed and battery power metrics. Feedback requested, Greg

1 0