- OvmsDev - Open Vehicles

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

Remote Climate Control on 2016 model Leaf
by Tom Parker 30 May '17

30 May '17

Hi, Philip came over and we had a look at why the OVMS remote climate control does not work on his Japanese Domestic Market (JDM) 2016 30kWh Leaf. It turns out that the wake up message used on "Gen 2" cars (CAN ID 0x68c with length 1 and payload 0x00) does not wake this car up. Does anyone have a late model Leaf with working Nissan Connect who can sniff the bus and tell us how the remote wakeup works on these newer cars? Have Nissan gone back to using a wire between the TCU and the rest of the car to wake it up, like they had in the Gen 1? I believe the OVMS can be used as a CAN bus monitor with an alternative firmware, so possibly anyone with an OVMS and a PIC programmer can do the sniffing. Thanks.

1 0

The last OVMS v2
by Mark Webb-Johnson 23 May '17

23 May '17

One last OVMS v2 is up on fasttech. First come first served ;-) https://www.fasttech.com/products/0/10000001/1000300-ovms-car-module-v2 <https://www.fasttech.com/products/0/10000001/1000300-ovms-car-module-v2> Regards, Mark

4 3

Monday Modems
by Mark Webb-Johnson 22 May '17

22 May '17

For your Monday morning - some modems. This should give you an idea of how the expansion can work. Each expansion module is self-contained and entirely optional. These modules extend what the base product can do. First two are 3G and 4G. They have their own power supplies (to provide the needed 4V for modem operation). Regards, Mark.

1 1

It's alive!!!
by Mark Webb-Johnson 20 May '17

20 May '17

After a day in front of an oscilloscope, with a little help from a soldering station, on board CAN bus working on OVMS v3. Now for buses 2 and 3...

1 0

OVMS v3
by Mastro Gippo 20 May '17

20 May '17

Hi all, I'd like to resurrect an old conversation. As we know, the current PIC is quickly running out of resources and maybe it's time to switch to a better platform. Two CAN buses are now desirable too. A microSD slot and direct USB connectivity wouldn't hurt either. I will probably have to design a similar hardware for myself, so I'd like to contribute to the OVMS by sharing the HW platform if you want; no strings attached of course, if you decide that there's no need for the upgrade, I'll keep on working on my project by myself! :) That said, I'd like to throw a few ideas to the table. - MCU: I'd like to use an STM32 micro. They seem to be emerging as the standard choice for diy ARM projects, and this offers a few interesting opportunities: -Programming it in c/c++ with the manufacturer CMSIS standard libraries (boring) -Programming it with the mbed.org SDK. Unfortunately no dev boards are available with dual CAN bus, but it will be easy to move to the correct micro of the same series once most of the software is ironed out on a dev board like the https://mbed.org/platforms/ST-Nucleo-F302R8/ -Programming it with an RTOS. NuttX would be my choice, as it's the one used in the Ardupilot Pixhawk platform, and I'd like to learn it. This would mean a steeper starting curve, but a lot of flexibility later as a lot of stuff is handled on the OS level (network stacks, SD card & filesystems, multitasking...). FreeRTOS is a nice option too. I'd like to use the STM32F405RG as it's the most similar to the one found on the Pixhawk, but of course I'm biased because of that, and that micro is quite overkill for the task. We can of course use a lower specced part and lose some RTOS fuctionality as long as it has 2 CAN buses. - MODEM: I have no experience in this field; is the SIM908 still a good choice or does anyone think that we should try new platforms? I like this, but I don't know if the price puts it out of budget: http://www.telit.com/telit/Pulsar/en_US.Store.display.1001./ge864-gps On the bright side, it can be programmed in python, so we can offload some of the work to the modem. This *could* allow us to free some space on the PIC, and keep that platform without changing MCU.. - Enclosure: I think that, even with the new MCU, we can still fit the old enclosure. Is that ok, or should we think about a more automotive-friendly one? Maybe waterproof for the twizy? And that's it. I think that the core SW developers should voice their opinion, as there is a lot of work to be done on that front. A huge problem will be keeping backwards compatibility to add features for the v2 users, so we should discuss about this too. Regards MG

18 70