- OvmsDev - Open Vehicles

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

OVMS v3 getting started
by Mark Webb-Johnson 04 Oct '17

04 Oct '17

For those of you about to receive OVMS v3 modules, and for others listening in, here is a ‘getting started’ guide. Follow the instructions in the developer’s guide to download the ESP IDF, extensa tools, and OVMS firmware source tree. Connect a powered USB hub to your PC, and then connect the OVMS v3 module to that hub, using a micro-usb cable. OVMS v3 is currently in prototype stage, and is not yet FCC/CE approved, so we don’t recommend directly connecting it to your PC’s USB ports. Do a “make” and “make flash”. Do a “make monitor” and enjoy the “Welcome” prompt and cursor awaiting your commands. Developer’s documentation is here: https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWE… <https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWE…> You can check the Over-The-Air update system with: OVMS > ota status Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb0) Sep 22 2017 13:33:43 Running partition: factory Boot partition: factory The adventurous can put an firmware image on SD card, push it into the OVMS slot, and then “ota flash vfs /sd/<imagename>”. Now, let’s do some radio stuff and bring up a wifi connection: OVMS > config set wifi.ssid <SSID> <PASSWORD> (replace <SSID> with your wifi’s SSID, and <PASSWORD> with it’s password - no spaces supported at the moment) OVMS > wifi mode client <SSID> I (1446306) wifi: connected with STUBBY, channel 11 I (1448626) event: ip: 192.168.1.100, mask: 255.255.255.0, gw: 192.168.1.1 I (1448626) ovms-mdns: Launching MDNS service I (1448626) obd2wifi: Launching telnet server Cool. Now OVMS is a wifi client on your network. You can even “telnet 192.168.1.100” (or whatever address is shown) to remotely access it over wifi. If you want to be really fancy, try taking advantage of the Bonjour mDNS system and “telnet OVMS.local”. If you don’t have a wifi network to connect to (seriously?), OVMS can be a wifi Access Point itself: OVMS > config set wifi.ap <SSID> <PASSWORD> (replace <SSID> with the SSID you choose, and <PASSWORD> with a password that clients will use to connect - no spaces supported at the moment) OVMS > wifi mode ap <SSID> Then connect to the OVMS module using your phone/PC, as required. Telnet is your friend. Let’s try to configure some vehicle parameters, so we can connect to an OVMS v2 server: OVMS > config set vehicle id <VEHICLEID> OVMS > config set server.v2 server api.openvehicles.com <http://api.openvehicles.com/> OVMS > config set server.v2 password <SERVERPASSWORD> (The <VEHICLEID> and <SERVERPASSWORD> are whatever you registered with openvehicles.com <http://openvehicles.com/>). OVMS > server v2 start Launching OVMS Server V2 connection (oscv2) I (1881896) ovms-server: Launching OVMS Server V2 connection task (oscv2) I (1881936) ovms-server-v2: Connected to OVMS Server V2 at api.openvehicles.com <http://api.openvehicles.com/> I (1881966) ovms-server-v2: OVMS V2 login successful, and crypto channel established I (1881976) ovms-server-v2: Incoming Msg: MP-0 Z0 Note that this will have the side-effect of changing that mDNS advertisement to be <VEHICLEID>.local. We can now see some metrics: OVMS > metrics list m.freeram 46716 m.hardware OVMS WIFI BLE BT cores=2 rev=ESP32/1 m.serial aa:bb:cc:dd:ee:ff m.tasks 18 m.version 3.0.0/factory/main build (idf v2.1-2-g7138fb0) Sep 22 2017 06:33:43 s.v2.connected yes s.v2.peers 0 v.b.12v 0 Looks good. Try connecting an App to the server (on the same vehicle ID) and watch s.v2.peers go from 0 to 1. Now, start up a vehicle module: OVMS > vehicle module TR I (2016816) v-teslaroadster: Tesla Roadster v1.x, v2.x and v3.0 Vehicle Module Plug it into the car, and watch the other metrics arrive. Power it from the vehicle’s 12V, and watch v.b.12v show your voltage. Don’t forget that we’ve got a modem as well: OVMS > power simcom on Power mode of simcom is now on OVMS > simcom tx AT So, how do we make this work automatically at startup? We’ve still got a lot of work to do on this, but one way at the moment is to take a SD card and format it as FAT32. Then, create directories: /events /events/system.start /events/system.wifi.sta.gotip Create two scripts: /events/system.start/myscript wifi mode client <SSID> vehicle module TR /events/system.wifi.sta.gotip server v2 start Unmount the SD from your computer, and put it in the OVMS module. On boot, you’ll see it mounted under ESP-32’s vfs as /sd. You’ll also see your scripts run (the first at boot, and the second once the wifi comes up). The scripting system will automatically run all scripts it can find in the /store/events/<eventname> and /sd/events/<eventname> directories. There’s a lot more there, and it is early days, but that should give you a start and a better idea how this is coming together. Regards, Mark.

5 16

I believe we have a winner in the OVMS v3 delivery set
by Mark Webb-Johnson 28 Sep '17

28 Sep '17

Tom is in New Zealand. It looks like France may be a close second place. Regards, Mark

2 2

Early Xmas
by Mark Webb-Johnson 22 Sep '17

22 Sep '17

Christmas has come early for 10. They all seem ok. Just doing a quick test flash. If no issues, I’ll pack them up and send them on. Regards, Mark

2 1

It’s alive!
by Mark Webb-Johnson 17 Sep '17

17 Sep '17

First attempt at porting Tesla Roadster vehicle module to v3 framework. Looking good. Still quite a bit to do at the framework level, but there’s a good chance I can have a v3 module in my car this week (at least using WiFi connectivity). Mark

1 0

OVMS v3 CE/FCC
by Mark Webb-Johnson 14 Sep '17

14 Sep '17

Just a short note to say that we haven’t forgotten about OVMS v3 CE/FCC certification. The plan has always been to get the initial build out of the way - to get some very stable hardware before we attempt certification. That is now done, and we are starting full production of these v3.0 boards next month. For the ‘active emissions’, we have chosen CE and FCC certified modules (ESP32 and SIMCOM), and these are included unmodified in OVMS v3. Nevertheless, the initial v3 modules as a whole are not CE or FCC certified and will still be sold from China as hobbyist kits (just as OVMS v2 was). We have now started the process of selecting a certification laboratory for CE and FCC approval. This will take some time, and most likely require a v3.1 hardware revision (in particular for ESD protection, but we maybe also require some extra power line filtering). Once we achieve CE and FCC approval, we’ll see if we can find local distributors in EU and US to help get the product out (and simplify local supply). If anybody has any experience with CE and FCC approval of such devices, and is willing to help out, please let me know. Any advise you can give would be most appreciated. Regards, Mark.

1 0

OVMS v3 Hardware
by Mark Webb-Johnson 13 Sep '17

13 Sep '17

No major problems found on the RC1 hardware, and the SIMCOM SIM5360 modem is now working well. Just a few minor layout improvements. So I just gave the go-ahead for the first small pre-production run of OVMS v3 hardware. 10 sets for developers. I should have them in a week or so. As I said before: If you are interested in helping out with development / porting vehicle support, and want one of these early boards, please could you eMail me personally to mark(a)webb-johnson.net <mailto:mark@webb-johnson.net> with the following details: Contact eMail address Full name Postal address Postal contact telephone number What area of the firmware are you willing to help out with Whether you want a prototype 3D printed case now (or we can send injection moulded case later when ready) Whether you want a modem board now, your preference for 3G or 4G, and if so what 3G AND 4G frequency ranges your cellular provider uses (That is private information, so please don’t reply to this mailing list - send to me privately). I am not sure what the pricing will be (I’ll confirm nearer the time), so nothing committed yet; just trying to get an indication of interest. I am tying to arrange some sponsorship for this, for the first few boards to go free to developers who have done the most for the project; so if you can commit to do something specific, please let me know. Once those boards go out to developers, my plan is to wait a month to ensure that no problems are found and we can get some basic functionality in the firmware similar to v2 basic capabilities (using v2 protocols and v2 apps). Assuming no hardware problems are found in that time, I’ll then push the button to start a first full production run of 100 to 200 sets. Regards, Mark.

2 3

Scripting
by Mark Webb-Johnson 10 Sep '17

10 Sep '17

Short story: Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console OVMS > test javascript Javascript 1+2=3 Long story: The overall design of OVMS v3 is to use the command system for _everything_. That makes it extensible, flexible, and very very powerful. Then we have ‘events’ that trigger whenever important things happen (such as entering a geolocation, leaving a geolocation, starting a charge, completing a charge, etc). Users of OVMS v2 have done incredible things with external server-based scripting (such as reacting to a charge start to control home automation), and things like ACC brought rudimentary scripting to v2. But, I’m interested in what could be done with a robust scripting language running _on_ the module itself. Not as a server-based function, but running on the actual device in the car (even in cases of no cellular connectivity). We have a few use cases for this: Startup configuration scripts. Things like enabling option modules, configuring wifi, etc. General event reaction scripts. Doing things in response to events (like homelink when you enter a certain geolocation). Mathematical evaluation. Things like the OBD ECU simulator reading values from metrics and outputting them as OBDII PID values (but highly customisable). Custom scripts. Things we haven’t thought of. I’ve looked at a bunch of scripting engines, and the most complete, standards compliant, flexibly licensed, seems to be ‘duktape’. A javascript library. Code side wise it is pretty big (to be standards compliant), but RAM usage is pretty optimal and highly configurable. C/C++ integration is simple and we can what we need to be callable from javascript. Overall, it is big and complex, but the clear winner in what is out there. The other advantage is that it doesn’t use exceptions, or other nasty C++ stuff, that causes problems with ESP32 use of other libraries. So, with the commit I just made, Duktape is in OVMS v3. I’m now integrating it as the scripting library of choice. This takes our based framework firmware to about 1MB of flash. Say another 1/2MB for all the fancy stuff we want to add for networking and CAN bus tracing. That leaves 2.5MB for vehicle support. Should be fine. I’m looking forward to seeing what people do with this. Regards, Mark.

1 0

ESP-IDF 2.1 and OTA
by Mark Webb-Johnson 04 Sep '17

04 Sep '17

I’ve been trying to keep OVMS v3 firmware up-to-date and compatible with the latest bleeding-edge ESP-IDF from Espressif, but it is proving too time consuming. Espressif keep changing things, breaking things, then un-breaking them, and it is starting to get frustrating. The latest Espressif commits have messed around with CR/LF line endings in the monitor terminal, and broken SD card support. The idea was to handle lots of little changes, rather than try to deal with them all in one big lump down the road, but it is just not working out. To try to speed things up, I’ve decided to standardise, for the moment, on the latest released ESP-IDF v2.1. With the commits today, the OVMS v3 firmware will cleanly build against this version only. If you are building OVMS, you should checkout this release of ESP-IDF as follows: $ git pull $ git checkout remotes/origin/release/v2.1 $ git submodule update —init $ git status HEAD detached at origin/release/v2.1 nothing to commit, working tree clean Then, you can ‘make clean’ and ‘make’ OVMS as usual. In other news, OTA is working (at least as a proof of concept). Here’s an OTA flash from VFS (SD card): OVMS > ota status Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb0) Sep 5 2017 08:01:38 Running partition: factory Boot partition: factory OVMS > sd mount Name: SD Type: SDHC/SDXC Speed: default speed Size: 15120MB CSD: ver=1, sector_size=512, capacity=30965760 read_bl_len=9 SCR: sd_spec=2, bus_width=5 Mounted SD CARD OVMS > ota flash vfs /sdcard/ovms3.bin Current running partition is: factory Target partition is: ota_0 Source image is 798912 bytes in size Preparing flash partition... Flashing image partition... Setting boot partition... OTA flash was successfull Flashed 798912 bytes from /sdcard/ovms3.bin Next boot will be from ‘ota_0' OVMS > ota status Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb0) Sep 5 2017 08:01:38 Running partition: factory Boot partition: ota_0 (reboot) OVMS > ota status Firmware: 3.0.0/ota_0/main build (idf v2.1-2-g7138fb0) Sep 5 2017 08:01:38 Running partition: ota_0 Boot partition: ota_0 This means that end-users can simply put an image on SD card, plug it in, and type a few simple commands on the console to get the image loaded and running. No need to install SDKs, or flashing tools. Just a simple USB console (and this will also work via wifi telnet console when ready). I’ve now got to get the automatic SD CARD mount on boot code working, and can then implement a quick check to see if a firmware image file is on SD card, then automatically flash that and reboot into OTA. Once that is done, all the user will have to do is copy a file to SD card, plug it in, and switch on. Regards, Mark.

1 0

Fwd: OVMS with Tesla Roadster 3.0
by Mark Webb-Johnson 03 Sep '17

03 Sep '17

> Begin forwarded message: > > From: Ulrich Hopp <uh1000(a)t-online.de> > Subject: Fwd: [Ovmsdev] OVMS with Tesla Roadster 3.0 > Date: 2 September 2017 at 1:22:08 AM HKT > To: Mark Webb-Johnson <mark(a)webb-johnson.net> > > ------------------------------------------------------------- > From: Ulrich Hopp <hopp(a)terminal-beach.de> > Subject: [Ovmsdev] OVMS with Tesla Roadster 3.0 > Date: 1 September 2017 at 2:35:32 PM HKT > To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> > > > Hi, > only want to confirm that my OVMS V 2.0 works fine after Tesla Roadster upgrade (big battery) > Cu Uli aka @talktedius329 > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. >

1 0