- OvmsDev - Open Vehicles

OVMS v3 Release Candidate
by Mark Webb-Johnson 31 Aug '17

31 Aug '17

Here’s the final issue-list we had to be addressed with the OVMS v3 release candidate board: Board layout to match enclosure (including mounting holes) To be able to have a board + enclosure product. CP2102 power from USB (with no connection to 3.3v on ESP side) To fix sleep-mode power consumption issue with CP2102. 100nF for C21 To resolve auto-flash issue. 10K between pin 25 of the CP2102 and pin 35 of the ESP32 To protect against fake CP2102. Change to resistor values for voltage divider on ESP32 ADC To fix power consumption issue with that voltage divider network. Tri-state buffer on MAX7317 MISO using 74AHC1G125 To fix MAX7317 MISO not co-existing with MCP2515 MISOs. EGPIO P2 (MAX7317) 10K pull-up to 3.3v and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of SN65. MCP2515 #1 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65. MCP2515 #2 10K pull-up on RX0BF and connection to Rs of matching SN65 To fix sleep-mode power consumption issue of MCP2515 and SN65. #3 was the worst. That has been plaguing us for months, and got worse when we changed #2 to power the CP2102 from USB. We thought it might be a ‘fake’ component issue, but that turned out to be not so. In the end, it turned out to be a silicon issue on the ESP32. Frustrating in that Espressif knew about it all along, but it was not documented or discussed much. Anyway, a change from 1nF to 100nF capacitor works around the issue and will continue to work with newer silicon (when Espressif release it). Apart from #3 and #6, these fixes are primarily to address power consumption. We want to get that as low as possible (particularly in sleep mode). Without the modem, and with the above fixes, it seems that we can get down to around 23mA in normal operation, 19mA with CAN asleep, and 4.5mA with everything sleeping (all these @12v supply). By comparison, with modem, OVMS v2 is around 80mA @12v (and can’t sleep). We might be able to get the sleep figure a bit lower in software, but we think we are about as low as it is going to get. At such low currents, our switched mode power supply is not very efficient, and further work on this is really now hitting diminishing returns. The modem should be able to be completely powered off, under control of the ESP32. It also has various low-power sleep modes. So, that will add to the consumption (as does wifi/bluetooth, if enabled), but only in use. Anyway, it is a separate board so any required fixes can be made directly without affecting the main board. New layout is done, and release candidate board is being made now. It should be in my hands any day. Assuming that is ok, we’ll pull the trigger and make the first production run of developer boards. Firmware is coming on, but we need more people working on it. Particularly for porting over vehicle support. So, #1 priority is getting those developer boards available. Regards, Mark.

3 4

Nissan Leaf Updates
by Tom Parker 29 Aug '17

29 Aug '17

Hi, I've made a few changes to the Nissan Leaf support. Configurable battery sizes to support 30kWh batteries. Parameter 21 is now initialized to 281 gids if it doesn't contain a string that parses to an integer. Change this parameter to change how many gids represents 100%. If you have a 30kWh battery you probably want to set it to 363. I discussed options to change the SOC calculation when I first started working on OVMS and Tom Saxton made a convincing argument that OVMS should display the amount of energy remaining in the battery, not how full it is. I'm not planning to push the other options I discussed back then as it turns out he's right, you want to know that when it tells you 60% you have 60% of some fixed amount of energy, not 60% of whatever the car thinks it can do today. You'll have to restart the OVMS after changing this parameter for it to take effect. Ambient temperature. The value I'm getting isn't quite right, but it's close to the eyebrow dashboard display. Leaf Spy mentions something about a correction in it's change log but I haven't tried to track it down. Battery temperature. The BMS sends the battery temperature in a multiplexed field on a regular basis, so no polling is required. I've had battery temperature via polling in my development branch for a while but, on my car at least, this causes a relay to click during charging so I didn't merged it upstream. I did some reverse engineering with a CAN bus man in the middle and discovered how the battery temperature on the dashboard works. Remote Climate Control switch off. It turns out at least some Gen 2 cars don't turn off their climate control after you remote start it. They even continue remote climate control after driving the car and then turning it off. Now I send the off command after 15 minutes on battery power and 30 minutes on grid power, or if the car turns on. I've discovered that on Gen 2 and later cars the plugged in detection doesn't work. This isn't hugely surprising because they changed the battery charger between Gen 1 and 2. This last change hasn't been merged yet because I only just now sent the pull request. I've also found that remote climate control doesn't work at all on 2016 models -- Nissan moved the TCU to the Car CAN bus (it was on the EV CAN bus) and changed the messages. Expect an update for 2016 remote climate control and Gen 2 plugged in detection soonish.

2 1

Mini-OVMS by Stephan Eipl
by Michael Balzer 27 Aug '17

27 Aug '17

Hi everyone, Stephan Eipl <stephan.eipl(a)gmx.de> has created a V2 hardware fork without GSM modem, just serial port. He uses a 433 MHz module to access the module, a Bluetooth module (i.e. HC-05 / HC-06) should do as well. If you'd like to create a firmware for this hardware, just copy your build profile and enable the OVMS_FIXED_DIAGMODE compile switch. If you've got questions about building the hardware or want to order a PCB, please contact Stephan directly. Commit: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/0f4ee… Files: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/tree/master/… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

Hologram Deal
by Mark Webb-Johnson 24 Aug '17

24 Aug '17

FYI: Hologram are currently offering a ‘developer special’ deal for a "free" Developer SIM card. https://hologram.io/store/developer-global-iot-sim-card/ <https://hologram.io/store/developer-global-iot-sim-card/> (normally US$5 value) Limit is one per developer, and overall numbers are limited. The SIM is free, but you will need to pay for shipping. Regards, Mark.

1 0

V3 take 2
by Mark Webb-Johnson 20 Aug '17

20 Aug '17

Some pictures of old vs new v3 arrangement. I just got the new board today, and it 'feels' so much better. We re-layed out the expansion pins, to make routing easier, and that makes the layout much cleaner. Very happy with physical layout now. Circuit hasn't changed much - just layout. We've also built a prototype 3G/4G modem board. So far, all seems ok. I'm moving the nasty hacky test code for each peripheral over to a nicely layed out library in the ovms v3 project, one peripheral at a time. The SDCARD library came over great and is working well. Next is the SPI stuff (GPIO expansion, MCP2515 and on-board CAN). We are having an issue with power consumption in deep sleep. The ESP32 itself, 16MB flash chip, and our power supply, seem fine. They power down to <1mA. But, some other peripherals stay consuming power even in deep sleep. One cause seems to be simply missing the library code to sleep each peripheral - that is not hard, just a bit of work. The bigger issue seems to be the CP2102 USB UART chip - that is using about 5mA even in deep sleep. The SUSPEND mode doesn't seem to happen even when USB is disconnected. So, we may have to re-wire it to be powered by USB (rather than our 3.3V supply) - which will mean it powers off completely when disconnected from USB. Still testing that. The BTS chip also seems to be using more than we intend. We're talking about 20mA here (vs 80mA for OVMS v2), but I reckon we can get it down to below 1mA. Anyway, I don't want to confirm the hardware layout until we are 100% certain we can power down correctly. Getting close now... Regards, Mark.

6 7

Request For Comment: Protection of Sensitive Information on the Vehicle Module
by Mark Webb-Johnson 06 Aug '17

06 Aug '17

I’m seeking comments/feedback/suggestions for the protection of sensitive information on the vehicle module for OVMS v3. Firstly, here is the background document from Espressif regarding native ESP-32 flash encryption facilities, along with a short summary: http://esp-idf.readthedocs.io/en/latest/security/flash-encryption.html <http://esp-idf.readthedocs.io/en/latest/security/flash-encryption.html> Flash encryption keys are normally randomly generated and stored in efuses that are write-only and protected so they cannot be read via normal means. The chip transparently encrypts everything on flash when the facility is first enabled. The chip transparently decrypts everything coming from flash, to the program running on the system. There is a limitation that serial flashing (factory/developer image) can only happen three times with this system. However, OTA updates are unaffected by this limit. Once the flash is encrypted, it is secure from tampering. But, you can always just upload another program to it (via OTA, or serial flash) and run that. Then, that program has full access to the decrypted flash. To get around that vulnerability, Secure Boot should always be used in combination with flash encryption: http://esp-idf.readthedocs.io/en/latest/security/secure-boot.html <http://esp-idf.readthedocs.io/en/latest/security/secure-boot.html> A public key is stored in a write-once eFuse. A matching private key is used to sign programs to be downloaded to the system. The bootloader verifies the keys and current signature of program in flash, and will only execute correctly signed code. Bottom line is that if an attacker has physical access to the device, then only a combination of flash encryption and secure boot can protect the contents of the flash. At that point, a microscope and chip etching is needed. However, that is completely incompatible with open source development. Only the manufacturer (us, Open Vehicles, in this case) can sign programs to be loaded onto the device. It is also a PITA for developers (due to the limit of 3 flashes for factory/developer serially flashed images). Our requirement is to protect sensitive information on the device. Things like wifi passwords, etc. The ESP32 provides us the flash encryption + secure boot option, as well as various storage areas we can take advantage of (RAM, NVM key-value store in flash, SPIFFS file system, eFuses). Assuming we aren’t going to use flash encryption + secure boot, and assuming we can compromise to limited protection from those with physical access to the device, what can we do? I have created a stub config API: void RegisterParam(std::string name, std::string title, bool writable=true, bool readable=true); void DeregisterParam(std::string name); void SetParamValue(std::string param, std::string instance, std::string value); std::string GetParamValue(std::string param, std::string instance); The config store is based on Param+Instance=Value. So, for example, we can have a parameter for wifi parameters, an instance of the wifi SSID, and the value being the password, etc. Each param can also be tagged as writable and/or readable by the end-user (the system itself must of course have full read/write access). The question is how to implement that store in as secure a way as possible? OVMS v2 provided no protection - a serial console directly connected had access to everything. One compromise suggestion I have is: On boot, check NVM for an encryption key. If it doesn’t exist, randomly create it and store in NVM. That key is now per-device. (Note that I am trying to find out if we can store that key in eFuse rather than NVM, and protect the eFuse from external serial reading, but still have access to it from running program - that would be slightly more elegant and a make things a little harder for an attacker, but I don’t know if it is possible) Store the config values in flash SPIFFS filesystem, and encrypt them with the encryption key. Both the above can be done within the config system, with no external access. Have the commands to read/write config honour the readable/writeable flags and enforce the protection at the command level. If we did that, someone with physical access to the device could either (a) upload their own code to read and print the configs, or (b) extract the flash contents, find the NVM key, and decrypt stuff themselves. Pretty much no protection for an educated smart hacker with time. We’re open source so this is trivial. Protection against remote access to these protected configs would be better. So long as our command processor is not exploitable, or there is some other unknown remote exploit affecting us, we’re pretty secure. Note that a suggested variant of this would be to store the key externally to the device and to have to enter it manually whenever the device is powered on (but before network access). Storing the key in ram would make it slightly more secure to external access, but would be more troublesome for the end-user to have to get a laptop out to plug it in and enter the key. One other comment is that even if WE don’t enable flash encryption and secure boot, there is nothing stopping an educated end-user doing that. He would need to arrange to sign his own updates (and not use ours). Thoughts? Suggestions? Regards, Mark.

3 4

Fwd: OVMS v3?
by Michael Balzer 03 Aug '17

03 Aug '17

Mark, here's a potential buyer of ~50 v3 modules. Do we have a production schedule yet? Thanks & regards, Michael -------- Weitergeleitete Nachricht -------- Betreff: OVMS v3? Datum: Wed, 2 Aug 2017 16:15:40 +0200 (CEST) Von: fabian(a)legoutdulibre.com An: dexter(a)dexters-web.de Hi, I am the IT manager for a small transport company in Canada, evaluating different devices to track our vehicles and store other data. I read with interest your post 3 months ago about work on OVMS v3 boards/devices. Could you post an brief update on your site about these? It would help in my research, our timeframe is Nov/Dev 2017 (~50 vehicles, possibly more). Many thanks, Fabian Rodriguez https://legoutdulibre.com

3 5

Re: [Ovmsdev] OVMS module for Opel Ampera/Chevrolet Volt
by Michael Jochum 20 Jul '17

20 Jul '17

Hi, yes i will sell them. The V1 and the V2. The V1 has the TR Connector. The V2 has the OBD-II Connector. Bye Michael > Am 19.07.2017 um 15:33 schrieb Pierre-Yves Gilton <py.gilton(a)gmail.com>: > > Hi, > > Ok, so what about the availability of the v3 for Ampera ? What are the additional functionalities of V3 vs V2 for ampera ? > @Michael J, do you sell your V2 module if you can't use it ? > > Thank you. > Regards, > PY > > 2017-07-19 14:42 GMT+02:00 Michael Jochum <mikeljo(a)me.com <mailto:mikeljo@me.com>>: > Hi, > > thank you :) > > But: "Unfortunately" I no longer have the Volt ;). Now i drive Tesla. :-)) > But still have the Tools, Sources etc. for the Volt Part, so i think i can help (a little bit). > > BTW: i still have an OVMS V1 and V2 Module that i can't use in the Model S. > > Bye > Michael > > > > Am 19.07.2017 um 12:07 schrieb Michael Balzer <dexter(a)dexters-web.de <mailto:dexter@dexters-web.de>>: > > > > Hi PY, > > > > yes, V3 will be compatible with all vehicles > > currently supported, so also the Volt/Ampera. > > > > Thanks for your beta test offering, the > > Volt/Ampera developer Michael Jochum has been > > informed :) > > > > Regards, > > Michael > > > > > > Am 17.07.2017 um 14:12 schrieb py.gilton(a)gmail.com <mailto:py.gilton@gmail.com>: > >> Hello, > >> I'm looking for an OVMS module compatible with my 2012 Opel Ampera. I understood that ovms v3 is on the point of being available ; so I plan to wait the 3rd version. But will it be compatible with opel ampera ? If you need tester on this car don't hesitate ! > >> Thank you. > >> PY Gilton > > > > > > -- > > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > > > > > >

1 0

Re: OVMS module for Opel Ampera/Chevrolet Volt
by Michael Jochum 19 Jul '17

19 Jul '17

Hi, thank you :) But: "Unfortunately" I no longer have the Volt ;). Now i drive Tesla. :-)) But still have the Tools, Sources etc. for the Volt Part, so i think i can help (a little bit). BTW: i still have an OVMS V1 and V2 Module that i can't use in the Model S. Bye Michael > Am 19.07.2017 um 12:07 schrieb Michael Balzer <dexter(a)dexters-web.de>: > > Hi PY, > > yes, V3 will be compatible with all vehicles > currently supported, so also the Volt/Ampera. > > Thanks for your beta test offering, the > Volt/Ampera developer Michael Jochum has been > informed :) > > Regards, > Michael > > > Am 17.07.2017 um 14:12 schrieb py.gilton(a)gmail.com: >> Hello, >> I'm looking for an OVMS module compatible with my 2012 Opel Ampera. I understood that ovms v3 is on the point of being available ; so I plan to wait the 3rd version. But will it be compatible with opel ampera ? If you need tester on this car don't hesitate ! >> Thank you. >> PY Gilton > > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > >

1 0

OVMS v3 framework on GITHUB
by Mark Webb-Johnson 03 Jul '17

03 Jul '17

I’ve released what I have so far at: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3> From now on, I’ll push directly to there, and accept pull requests. DEVKIT-C To get it up and running on a DEVKIT-C style device, you will have to ‘make menuconfig’, and change (a) flash size to 1MB, (b) partition table to just a single factory image (no OTA). That will break when we bring the config system and SPIFS filesystem in flash online, but is workable for the moment. Our OTA and config flash will just rely on the partition table contents, so should continue to work with this (although you will need a custom partition table to work in 4MB). A better solution is to use an external 16MB flash chip, on a breadboard with the DEVKIT-C. Not hard to do. Physical wiring (for W25R128 and DEVKIT-C): #1 -> IO22 (FL_CS2) #2 -> SD0 (FL_SD0) #3 -> SD3 (FL_WP) #4 -> GND #5 -> SD1 (FL_SD1) #6 -> CLK (FL_CLK) #7 -> SD2 (FL_HOLD) #8 -> 3.3v Fuse blowing (take great care - this is a one-time operation): espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_REG 1 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_TIEH 1 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_FORCE 1 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CLK 6 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_Q 7 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_D 8 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_HD 9 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CS0 22 If you do it right, it will look like this: Config fuses: XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 1 R/W (0x1) XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 1 R/W (0x1) XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 1 R/W (0x1) SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 6 R/W (0x6) SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 7 R/W (0x7) SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 8 R/W (0x8) SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 9 R/W (0x9) SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 22 R/W (0x16) DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0) FIRST TIME BOOT You should see something like this: rst:0x1 (POWERON_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) I (85) boot: SPI Speed : 40MHz I (85) boot: SPI Mode : DIO I (94) boot: SPI Flash Size : 16MB I (106) boot: Partition Table: I (118) boot: ## Label Usage Type ST Offset Length I (140) boot: 0 nvs WiFi data 01 02 00009000 00004000 I (164) boot: 1 otadata OTA data 01 00 0000d000 00002000 I (187) boot: 2 phy_init RF data 01 01 0000f000 00001000 I (210) boot: 3 factory factory app 00 00 00010000 00400000 I (233) boot: 4 ota_0 OTA app 00 10 00410000 00400000 I (257) boot: 5 ota_1 OTA app 00 11 00810000 00400000 I (280) boot: 6 store Unknown data 01 82 00c10000 00100000 Initialising COMMAND Framework Initialising METRICS Framework Initialising OVMS Peripherals... SPI bus... MAX7317 I/O Expander... ESP32 CAN... ESP32 ADC... MCP2515 CAN 1/2... MCP2515 CAN 2/2... SD CARD... Initialising TEST Framework Initialising SD CARD Framework Initialising MAX7317 EGPIO Framework Initialising VFS Framework Registering Vehicle: Tesla Roadster Initialising HOUSEKEEPING Framework... I (1657) cpu_start: Starting scheduler on PRO CPU. I (509) cpu_start: Starting scheduler on APP CPU. Welcome to the Open Vehicle Monitoring System (OVMS) - async console OVMS > CONSOLE First thing you’ll see if we’ve unified everything into a command console. This console can be accessed over USB, and in future we’ll support WIFI, BLUETOOTH, SMS, GPRS, etc. The point is that all console commands work the same, no matter where they are called from. All core functionality will be exposed via console commands. Here is an example session (live from my test system): Welcome to the Open Vehicle Monitoring System (OVMS) - async console 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 > vfs ls /sdcard SPOTLI~1 VFS.CPP COMMAND.CPP COMMAND.H COMPON~1.MK CONSOL~1.CPP CONSOL~1.H METRICS.CPP METRICS.H OVMS.H OVMS_M~1.CPP PERIPH~1.CPP PERIPH~1.H TERMINAL.CPP TERMINAL.H TEST_F~1.CPP TEST_F~1.H OVMS > vfs rm /sdcard/OVMS.H VFS File deleted OVMS > egpio output 1 255 EGPIO port 1 set to output level 255 OVMS > sd unmount Unmounted SD CARD OVMS > metrics list m.version v.b.12v 0 v.b.cac v.b.range.e v.b.range.i v.b.soc v.b.soh v.b.temp.ambient v.b.temp.charger v.b.temp.motor v.b.temp.pem v.p.altitude v.p.direction v.p.latitude v.p.longitude v.p.odometer v.p.speed v.p.trip v.tp.fl.p v.tp.fl.t v.tp.fr.p v.tp.fr.t v.tp.rl.p v.tp.rl.t v.tp.rr.p v.tp.rr.t v.type v.vin OVMS > ? egpio EGPIO framework help Ask for help metrics METRICS framework sd SD CARD framework test Test framework vfs VFS framework Tab completion is not done yet, but you can do a “?” to see what is available. METRICS You’ll see these metrics as a new thing in OVMS v3. The idea is that rather than having hard-coded items, we have a dynamic extendable list of metrics. Some are standard (look in metrics_standard.h), but others can be added by vehicle modules (or any part of the system, really). These metrics will be used for MQTT, but also joined back together into groups for OVMS v2 protocol. LANGUAGE The code is in C++. The choice there was because (a) I wanted collections (maps, arrays, etc), (b) I wanted components to be able to self-register without having to change the framework (you just put the component in the right place and it merges itself into the system). Most of the code itself is basic C. CODE STRUCTURE The ‘main’ directory contains the framework itself. Only people playing with the framework should have to change that. The ‘components’ directory contains the extension components. This is where the system is extended. Within ‘main’, we have: command.cpp - the console command processor config.cpp - the configuration system console_async.cpp - an async console for USB port housekeeping.cpp - housekeeping tasks (e.g. measuring the 12v level every few seconds and updating the v.b.12v metric) metrics.cpp - the metrics system metrics_standard.h - the standard metrics ovms_main.cpp - the main entry point peripherals.cpp - access to all the peripherals in the system terminal.cpp - an experiment that didn’t work and will go soon test_framework.cpp - test framework for QC vfs.cpp - access to the virtual filesystem (from console) Within ‘components’, we have: can - a unified interface to CAN buses esp32can - CAN bus native to the ESP32 mcp2515 - CAN bus on the MCP2515 chips, controlled by SPI esp32adc - The ADC (for measuring 12v voltage level) max7317 - The extended GPIO (EGPIO), controlled by SPI microrl - A command line processing library pcp - Power Controlled Peripheral (a base layer for all out peripherals so we can power control them in a unified way) sdcard - SD CARD control spinodma - A SPI master driver that doesn’t use DMA (suitable for the small transfers we do) and is extendable beyond the hardware limit of 3 devices per SPI bus vehicle - The base vehicle layer vehicle_teslaroadster - An example project to add vehicle support for Tesla Roadster There are some code consistency issues at the moment. Things like lowercasevariables vs ThoseLikeThis. I’m trying to clean that up, as the code has come from lots of different places. CHANGES.TXT There is a CHANGES.TXT file. As I make changes (or incorporate other people’s changes), I’ll update it. TODO.TXT There is a list of tasks outstanding in TODO.TXT. If anything interests you, please let me know and I’ll be happy to assign it to you (as well as extremely grateful :-). I’m still trying to validate all the hardware, and ensure everything works. That means moving over the test code I have into proper libraries in this framework, and implement test_framework, or other, commands to allow them to be tested. Some are stubs, but most in the OVMS.V3 github are now live and working. See TODO.TXT for the latest status. Enjoy, Mark.

4 10