October 2017 - OvmsDev - Open Vehicles

C++
by Mark Webb-Johnson 23 Oct '17

23 Oct '17

2 1

Open Vehicles clone of Espressif's ESP IDF
by Mark Webb-Johnson 23 Oct '17

23 Oct '17

I’ve just updated the developer’s guide with a change regarding the github path for Espressif’s ESP IDF. We’re now suggesting people use the Open Vehicles clone of this, at: https://github.com/openvehicles/esp-idf <https://github.com/openvehicles/esp-idf> Not much difference between that and the Espressif master repository, but we have made some small changes for memory debugging, to make things easier for what we need to do. Also, if we find any bugs in the ESP IDF, we can make fixes directly ourselves (without waiting for Espressif). Regards, Mark.

1 0

Enable/disable mode, and secure commands
by Mark Webb-Johnson 14 Oct '17

14 Oct '17

We’ve implemented the ‘enable’ and ‘disable’ commands, and corresponding secure module for the consoles. The module password is in: Config Param: password Instance: module Value: <plaintextpassword> If there is no password defined (default case), you can just type ‘enable’ without password, and you’ll get into enable mode. Everything will be as it was before. If a module password has been set, then you must type ‘enable <password>’ and the password must match, to enter enable mode. If the password you enter is wrong, then there will be a five second delay before you can try again (to limit brute force attacks). The ‘disable’ command will switch back to insecure mode (the default), and some (most) commands will be restricted. If there is no password/module defined, then the consoles will default to secure (enable) mode. For example: Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console OVMS > vfs ls /store Error: Secure command requires 'enable' mode OVMS > enable <password> Secure mode OVMS > vfs ls /store ovms_config events OVMS > disable OVMS > vfs ls /store Error: Secure command requires 'enable' mode Regards, Mark.

1 0

v2 simcom, gsm, and ancient protocols
by Mark Webb-Johnson 11 Oct '17

11 Oct '17

I’m having a fascinating time with the new SIMCOM modem support for OVMS v3. I’ve wanted to use the CMUX protocol for some time, as it allows the single async line to be split to multiple separate logic communication channels, and for each of those channels to be used for different things. So, we can: Create a channel for the GPS. Then, that can be straight NMEA protocol, streaming from the GPS, with no need to poll. Create a channel for the PPP connection used to provide data service (GPRS, etc). This means we can handle our own networking (with lwip) and expose the modem network as a pure network accessible to normal networking stacks in the ESP32 framework. A “connect” would work the same way, no matter if it is over Wifi, or GSM modem. Create a channel for AT commands. The real advantage is that these are all separate, so we can issue AT commands while reading a GPS NMEA message, while sending telemetry to the server. Those of you familiar with OVMS v2 net.c code will recognise the issue; synchronising all the different accesses to a single async link used for AT, GPRS, SMS, and DATA, was a nightmare. CMUX was actually in the 2G SIMCOM chips as well, but we just didn’t have the ram or flash space in v2 to do it. So, now v3 is here, and I start to work on it. Turns out that the CMUX protocol is not SIMCOM’s. Instead, they use an industry standard protocol called "GSM 07.10 Multiplexing protocol”, in basic mode. The specification I am using dates back to 1997. Also of note is that the AT command set has also been standardised by the same body as GMS 07.07. Reading that specification, and working with that protocol, is like a journey back in history. Most of it seems based on the X.25 protocol from back in the 1980’s (my I.T. career started with messing around with X.25 systems, and asynchronous RPADs, so it is dredging up old memories dealing with Set Asynchronous Balanced Mode (SABM) and Unnumbered Acknowledgement (UA) responses). Great fun… Anyway, it is a big specification, with lots of nuances, but I am making progress. To leave normal single channel AT command mode, and enter GSM 07.10 multiplexor mode, we send some AT commands to program the multiplexor channel connections that we want: Channel 0 is mapped to the DIAG service Channel 1 is mapped to the NMEA (GPS) service Channel 2 is mapped to the DATA (AT) service Channel 3 is mapped to the DATA (AT) service Then we send “AT+CMUX=0” and wait for the OK: SIMCOM tx 41 54 2b 43 4d 55 58 53 52 56 50 4f 52 54 3d 30 AT+CMUXSRVPORT=0 SIMCOM tx 2c 30 3b 2b 43 4d 55 58 53 52 56 50 4f 52 54 3d ,0;+CMUXSRVPORT= SIMCOM tx 31 2c 35 3b 2b 43 4d 55 58 53 52 56 50 4f 52 54 1,5;+CMUXSRVPORT SIMCOM tx 3d 32 2c 31 3b 2b 43 4d 55 58 53 52 56 50 4f 52 =2,1;+CMUXSRVPOR SIMCOM tx 54 3d 33 2c 31 3b 2b 43 4d 55 58 3d 30 0d 0a T=3,1;+CMUX=0.. SIMCOM rx 0d 0a 4f 4b 0d 0a ..OK.. Now, we start talking GSM 07.10. We need three channels, so send SABM messages and wait for UA acknowledgements, for each in sequence: I (88695) gsm-mux: Start MUX I (88695) gsm-mux: StartChannel(0) SIMCOM tx f9 03 3f 01 1c f9 ..?... SIMCOM rx f9 03 73 01 d7 f9 ..s... I (88705) gsm-mux: ProcessFrame(CHAN=0, ADDR=03, CTRL=73, FCS=d7, LEN=6) I (88705) gsm-mux: Channel #0 is open I (88705) gsm-mux: StartChannel(1) SIMCOM tx f9 07 3f 01 de f9 ..?... SIMCOM rx f9 07 73 01 15 f9 ..s... I (88705) gsm-mux: ProcessFrame(CHAN=1, ADDR=07, CTRL=73, FCS=15, LEN=6) I (88705) gsm-mux: Channel #1 is open I (88705) gsm-mux: StartChannel(2) SIMCOM tx f9 0b 3f 01 59 f9 ..?.Y. SIMCOM rx f9 0b 73 01 92 f9 ..s... I (88715) gsm-mux: ProcessFrame(CHAN=2, ADDR=0b, CTRL=73, FCS=92, LEN=6) I (88715) gsm-mux: Channel #2 is open I (88715) gsm-mux: StartChannel(3) SIMCOM tx f9 0f 3f 01 9b f9 ..?... SIMCOM rx f9 0f 73 01 50 f9 ..s.P. I (88715) gsm-mux: ProcessFrame(CHAN=3, ADDR=0f, CTRL=73, FCS=50, LEN=6) I (88715) gsm-mux: Channel #3 is open Once the channels are open, then the SIMCOM modem sends messages: SIMCOM rx f9 0d ff 1f 0d 0a 2b 43 53 51 3a 20 31 34 2c 39 ......+CSQ: 14,9 SIMCOM rx 39 0d 0a f0 f9 9.... I (403335) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f0, LEN=21) That is a signal quality report (+CSQ) coming in on the data channel. Here is what an incoming SMS message (+CMT) looks like: SIMCOM rx f9 0d ff c3 0d 0a 2b 43 4d 54 3a 20 22 2b 34 34 ......+CMT: "+44 SIMCOM rx 37 39 33 37 34 30 xx xx xx xx 22 2c 22 22 2c 22 793740xxxx",""," SIMCOM rx 31 37 2f 31 30 2f 31 31 2c 30 31 3a 35 33 3a 35 17/10/11,01:53:5 SIMCOM rx 31 2b 30 34 22 2c 31 34 35 2c 34 2c 30 2c 30 2c 1+04",145,4,0,0, SIMCOM rx 22 2b 34 34 37 37 39 37 37 30 xx xx xx xx 22 2c "+44779770xxxx", SIMCOM rx 31 34 35 2c 31 31 0d 0a 48 45 4c 4c 4f 20 57 4f 145,11..HELLO WO SIMCOM rx 52 4c 44 0d 0a xx f9 RLD..u. I (1727775) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=xx, LEN=103) It is a lot of work getting this working, but the result should be worth it. Regards, Mark

2 2

En route...
by Mark Webb-Johnson 10 Oct '17

10 Oct '17

The first 10 developer modules (and modems, and 3D printed cases) are on the way to me. China->HK SF-Express is pretty amazing, so I should get them tomorrow morning. We’ve identified 10 worthy developers, so I’ll turn these around and get them out to you guys as soon as I can. In other news, I’ve started work on the documentation. Mostly a placeholder at the moment, but I’ll expand on it over the next few days so at least the developers getting these modules should have *some* documentation to get them started. V3 documentation is in Google Docs, and the following links will allow you to view and comment: OVMS v3 Developer Guide <https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWE…> OVMS v3 User Guide <https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oE…> Regards, Mark

2 2

Newbie question & initial report
by HONDA S-2000 09 Oct '17

09 Oct '17

I’ll start with my priority question, then summarize a few things I’ve learned that might be of interest. Q: How do I convince git to update the esp-idf branch? I grabbed the v2.1 release branch and built it without any obvious errors, but I don’t know how to pull or otherwise check that I have the latest. Here’s a snapshot of my current state: $ git status HEAD detached at origin/release/v2.1 nothing to commit, working directory clean $ git branch * (detached from origin/release/v2.1) master $ git pull remote: Counting objects: 189, done. remote: Compressing objects: 100% (50/50), done. remote: Total 189 (delta 141), reused 185 (delta 137), pack-reused 0 Receiving objects: 100% (189/189), 27.68 KiB | 0 bytes/s, done. Resolving deltas: 100% (141/141), completed with 55 local objects. From https://github.com/espressif/esp-idf e6afe28..de750e9 master -> origin/master You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> $ git pull You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> $ A: After reading the warnings about the Silicon Labs driver crashes, I decided to host my efforts on OS X Yosemite, 10.10.5, instead of any newer macOS. Therefore, I installed the legacy driver. So far, I’ve not had any problems. I’m able to connect to the OVMS v3 and communicate. I am using a cheap, $4.99 Full Speed USB hub (unpowered, because I’m too lazy to hunt for the wall wart adaptor). I realize that a powered hub is recommended, but I’ve not had any issues yet. B: Those of you who may not be familiar with the ‘screen’ application might be interested to read that I am able to connect to the USB serial converter using that program without running ‘make monitor’ - the only drawback is that I have to type Control-j instead of return/enter (but that might be resolved by another command line option that I’m not familiar with yet). The command is ‘screen /dev/tty.SLAB_USBtoUART 115200’ I’m avoiding /dev/cu.SLAB_USBtoUART because I assume it might activate the RTS / DTR / etc lines and cause unexpected results. C: I’m often quite paranoid about checking that new hardware is functional before I try building my own firmware, erasing any existing firmware, and therefore basically avoid trying too many steps in the first volley. Although I’ve build the esp-idf environment, I haven’t run ‘make monitor’ yet, so I was happy to see that the OVMS v3 shipped with a working firmware already installed (*). Using the ‘screen’ command detailed above, I am able to connect to the device, turn on the wifi, and execute commands. OVMS > ota status Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb02) Sep 21 2017 20:33:27 Running partition: factory Boot partition: factory OVMS > wifi mode ap TR25 Starting WIFI as access point... I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE W (576526) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration I (576706) phy: phy_version: 355.1, 59464c5, Jun 14 2017, 20:25:06, 0, 2 I (575846) wifi: wifi firmware version: 407bb27 I (575846) wifi: config NVS flash: enabled I (575846) wifi: config nano formating: disabled I (575866) wifi: Init dynamic tx buffer num: 32 I (575866) wifi: Init dynamic rx buffer num: 32 I (575866) wifi: wifi driver task: 3ffe9ad8, prio:23, stack:4096 I (575866) wifi: Init static rx buffer num: 10 I (575866) wifi: Init dynamic rx buffer num: 32 I (575866) wifi: Init rx ampdu len mblock:7 I (575866) wifi: Init lldesc rx ampdu entry mblock:4 I (575866) wifi: wifi power manager task: 0x3ffef880 prio: 21 stack: 2560 I (576526) wifi: wifi timer task: 3fff0af0, prio:22, stack:3584 I (576706) wifi: mode : softAP (30:ae:a4:37:25:85) I (576716) ovms-mdns: Launching MDNS service [Join...] I (643136) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1 I (643146) wifi: station: f4:5c:89:a3:64:cd join, AID=1, g, 20 [Leave...] I (789976) wifi: station: f4:5c:89:a3:64:cd leave, AID = 1 I (789976) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1 D: My next step is obviously to build the latest OVMS v3 firmware from git. I’m not having any trouble pulling the latest source updates because we’re not working on a branch, and it’s much easier to use git commands when working from the head / master (at least for me - I’m way more familiar with Subversion). Brian Willoughby * I don’t know whether Mark had to manually install the OVMS v3 firmware on each of these preliminary units, or if the assembly / manufacturing process is already set up to install an initial firmware on new boards. Either way, it’s nice that it didn’t arrive with a blank Flash!

5 8

v3 sdkconfig
by Mark Webb-Johnson 09 Oct '17

09 Oct '17

Just a short note to say I’ve added sdkconfig to .gitignore That makes it easier for developers to have their own version. The OVMS defaults are easy (we can provide the default values we require, as necessary). Still thinking about how to resolve the issue with other system settings we want to change default values for (such as stack sizes, buffers, etc). Regards, Mark.

2 1

SIMCOM modem getting started
by Mark Webb-Johnson 06 Oct '17

06 Oct '17

With OTA working, I’m now moving on to the SIMCOM driver. For those of you trying to get it working, here are some starting points: You can toggle modem power on/off with: OVMS > egpio output 0 0 OVMS > egpio output 0 1 OVMS > egpio output 0 0 You can talk to the modem with: OVMS > power simcom on I (16814) uart: queue free spaces: 10 OVMS > egpio output 3 0 OVMS > simcom tx AT SIMCOM rx 41 54 0d 0d 0a 4f 4b 0d 0a AT...OK.. OVMS > simcom tx AT+CGMI SIMCOM rx 41 54 2b 43 47 4d 49 0d AT+CGMI. SIMCOM rx 0d 0a 53 49 4d 43 4f 4d 20 49 4e 43 4f 52 50 4f ..SIMCOM INCORPO SIMCOM rx 52 41 54 45 44 0d 0a 0d 0a 4f 4b 0d 0a RATED....OK.. OVMS > simcom tx AT+CGMM SIMCOM rx 41 54 2b 43 47 4d 4d 0d AT+CGMM. SIMCOM rx 0d 0a 53 49 4d 43 4f 4d 5f 53 49 4d 35 33 36 30 ..SIMCOM_SIM5360 SIMCOM rx 45 0d 0a 0d 0a 4f 4b 0d 0a E....OK.. OVMS > simcom tx AT+CGMR SIMCOM rx 41 54 2b 43 47 4d 52 0d AT+CGMR. SIMCOM rx 0d 0a 2b 43 47 4d 52 3a 20 33 35 33 31 36 42 31 ..+CGMR: 35316B1 SIMCOM rx 31 53 49 4d 35 33 36 30 45 0d 0a 0d 0a 4f 4b 0d 1SIM5360E....OK. OVMS > simcom tx AT+CGSN SIMCOM rx 41 54 2b 43 47 53 4e 0d AT+CGSN. SIMCOM rx 0d 0a 38 36 33 37 38 ... SIMCOM rx 34 0d 0a 0d 0a 4f 4b 0d 0a 4....OK.. OVMS > simcom tx AT+CIMI SIMCOM rx 41 54 2b 43 49 4d 49 0d AT+CIMI. SIMCOM rx 0d 0a 32 33 34 35 ... SIMCOM rx 31 0d 0a 0d 0a 4f 4b 0d 0a 1....OK.. OVMS > simcom tx AT+CICCID SIMCOM rx 41 54 2b 43 49 43 43 49 44 0d AT+CICCID. SIMCOM rx 0d 0a 2b 49 43 43 49 44 ... SIMCOM rx 0a 4f 4b 0d 0a .OK.. (note that the 'egpio output 3 0’ is needed at the moment, to set DTR and wake up the modem, you can also ‘egpio output 3 1’ to make it sleep) Regards, Mark.

1 0

Re: [Ovmsdev] OVMS v3 getting started
by mr23＠comcast.net 05 Oct '17

05 Oct '17

I don't have the circuit handy.Does the sdcard chip and processor chip have filter caps and stabilization caps (for current draw surge)? ------ Original message------From: Stephen CasnerDate: Wed, Oct 4, 2017 6:51 PMTo: OVMS Developers;Cc: Subject:Re: [Ovmsdev] OVMS v3 getting started On Mon, 25 Sep 2017, Mark Webb-Johnson wrote: > I’m having problems getting SD CARDs to work reliably. Some work > recognise at all (a timeout error when mounting), and some will > recognise but fail under heavy writes to the sd card. Frustrating as > hell. I don’t think it is a hardware issue (even the googling that > error message points to pull-up resistors as the culprit), but > suspect some issue with the ESP IDF 2.1 library we are using. We’re > working on this one at the moment. I would appreciate your feedback, > when you get the boards, as to whether you get any success with SD > CARDs. I have a SanDisk Ultra 32GB micro SD card left over from playing with a Raspberry Pi. It is formatted FAT32 with name RECOVERY. When I insert it into the OVMS v3 and try the sd mount command, I get: OVMS > sd mount Error: SD CARD could not be mounted E (75093) sdmmc_cmd: sdmmc_card_init: send_scr returned 0x107 -- Steve _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

2 1

Painful, but done
by Mark Webb-Johnson 05 Oct '17

05 Oct '17

Well, that was painful, with a large number of new components required, but it is done… OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Checksum is 9cb76af286c00ed61a404cf8256f5c07 and expected file size is 853265 Preparing flash partition... Downloading... (100943 bytes so far) Downloading... (201683 bytes so far) Downloading... (301835 bytes so far) Downloading... (402139 bytes so far) Downloading... (503031 bytes so far) Downloading... (603183 bytes so far) Downloading... (703487 bytes so far) Downloading... (803639 bytes so far) Download file length is 853232 and digest 9cb76af286c00ed61a404cf8256f5c07 Setting boot partition... OTA flash was successfull Flashed 853232 bytes from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin Next boot will be from 'ota_0' I (12222) wifi: pm start, type:0 OVMS > ota status Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb02) Oct 5 2017 17:38:07 Running partition: factory Boot partition: ota_0 Regards, Mark.

1 0