June 2017 - OvmsDev - Open Vehicles

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

21 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

Preparing for v3 development
by Stephen Casner 30 Jun '17

30 Jun '17

Mark, what version of ESP-IDF are you using for the framework preparation? We need to install the same in order to be ready to take in code and add to it. -- Steve

2 1

OBD2 poller / CAN TX handling
by Michael Balzer 21 Jun '17

21 Jun '17

Hi everyone, Wolfgang (Zoe) and I just stumbled upon an ancient bug in the CAN TX buffer handling of the OBD2 polling framework. After checking other modules, I found the same code quite often, so vehicles not using the poller might be affected as well. Waiting for some TX to get finished is almost everywhere done with this snippet: while (TXB0CONbits.TXREQ) {} // Loop until TX is done Problem: this loop does not end if the PIC runs into a TX error, because TXREQ won't get cleared then. So a TX problem with the CAN bus triggers the watchdog reset. Solution: while ((TXB0CON & 0b00111000) == 0b00001000) {} // wait for TX done / error This loop ends on both TX error conditions and after successful transmits. The fix for vehicle.c is here: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/13c68… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

V3 size and arrangement
by Mark Webb-Johnson 19 Jun '17

19 Jun '17

I've got the first OVMS v3 development board in my hands now. The components seem fine, and I'm finalizing the QC program that checks everything to make sure all is ok. 16MB flash with OTA capability, Wifi, Bluetooth, 3xCAN bus, lots of GPIO, switched 12V, power by USB/12V, SD card reader/writer, optional 2G/3G/4G modem (with GPS), two expansion slots, USB, and an external expansion connector - all look good. Both 3G and 4G development expansion boards are also being made now, and I should have those next week. But, having seen it and held it, I'm now having second thoughts about the layout. As you can see from the attached pictures, the expansion slots are each about 60mm x 45mm. Putting two of those on the board makes it about 9.5cm x 9.5cm square. Height will be similar (a little bit taller) than the current OVMS v2. This is a first draft run only, just to confirm the components, but as you can see there is quite a lot of blank space and traces for the two expansion slots. That, and the sheer number of connectors we have, dominate the board. Let's call this arrangement (A). There was an alternative arrangement that I considered a while back. That would be to have just one expansion slot, but use stackable connectors (so multiple boards could be piggybacked on each other). In that arrangement, the expansion slot could be either vertical or horizontal, with a vertical arrangement being close in size to the existing OVMS v2 (but the height would need to be much taller to accommodate the piggybacked expansion boards). Let's call this arrangement (B). It doesn't change the wiring. Just the size and arrangement of components on the board, as well as the box housing this all. (A) ends up with a 1" wider+taller box of about the same thickness, while (B) ends up with a box about the same width and height, but significantly thicker. To me, it seems that (A) is more automotive, and (B) more hobbyist. What do people think? In the meantime, on with development (now that at last I have a target in my hands). Mark

10 27

OBD-II dongle message mapping for EVs
by Greg D. 07 Jun '17

07 Jun '17

Hi folks, Apologies in advance for the long email. I am looking for feedback on a potential feature-addition for the OVMSv3 software. As I've mentioned earlier, I have a side project to get an OBD-II dongle running in my Tesla Roadster. The overall project was to put a few applications on a Raspberry Pi for in-car use (but not regarding the car itself), some of which need an Internet connection. A too-good-to-pass-up deal from T-Mobile last fall netted me a "free" SyncUp Drive dongle, which offers a Wi-Fi hotspot in addition to a number of vehicle monitoring functions. Much better than tethering my cell phone. The dongle, however, is not supported in my Roadster (or any EV), and it goes into standby about 5 minutes after turning on. So, the side project was to create an "OBD-II simulator" to keep the dongle happy enough to keep the Wi-Fi on and not go to sleep. Using that Raspberry Pi and a CAN Hat, I have succeeded in creating a small program that provides enough simulated stimulus that the dongle stays running (yea!), but of course the simulated data is of no use in vehicle monitoring. I don't currently care about that, but from earlier discussions on this forum, it seems like creating a properly translated OBD-II port with the OVMSv3 would be of some interest for use with similar or other OBD-II dongles. The idea would be to use two of the CAN interfaces in the OVMSv3 hardware for connecting to the vehicle, and the third interface would provide the EV-translated OBD-II port for the dongle. The question then is, what information is of interest to be provided, and what OBD-II messages should be used for that purpose? I have attached a first draft spread sheet of the CAN messages, based on what my SyncUp Drive dongle reads, and what values might realistically be returned for them by the simulator. Please let me know if you have any suggested additions or corrections to what I have proposed. I have connected a regular OBD-II diagnostic dongle (OBDLink SX) to the simulator, and can view the various (though currently dummy) parameters returned. This is probably the best use for the feature, where you can monitor, log and graph things that the OVMS App doesn't provide access to. In the specific case of the SyncUp Drive dongle, most of these parameters are not directly visible by their smartphone application. They digest the data and attempt to provide a higher level "service" to warn you of issues with the car, give nanny-level alerts (e.g. speeding, geo-fence violations, aggressive driving), etc., none of which I have any use for, and several of which may have privacy implications. My guess is that they also monetize and/or share the data stream (they apparently have a deal with Allstate Motor Club for roadside assistance, for example), so I intend to have the sharing of the VIN configurable... :) Your thoughts? Thanks, Greg

2 3

OVMS logo
by Mark Webb-Johnson 06 Jun '17

06 Jun '17

We need to change the OVMS logo, to better reflect the vehicle independence. The existing logo is too much Tesla. Felix has kindly prepared a couple of options for us, attached below. My preference is for the one with the car outline (even though it retains a hint of Tesla), as it emphasizes the vehicle comms aspect. This is quite urgent, as the Teslive people are pushing for artwork. What do you guys/gals think? Regards, Mark

8 14