November 2016 - OvmsDev - Open Vehicles

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

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

Nissan Leaf Climate Control
by Tom Parker 25 Dec '16

25 Dec '16

I sent a pull request with Nissan Leaf remote climate control support. I also wrote up a quick blog post with a photo of my gen 1 wakeup circuit: https://carrott.org/blog/archives/158-OVMS-Nissan-Leaf-Remote-Climate-Contr… I'll post a schematic of the circuit. Gen 2 doesn't require any hardware modifications. I added #define CMD_ClimateControl 43 // (ON or OFF) with argument 'on' and 'off'. I'm using temporary hack to enable climate control via the homelink buttons. If CMD_ClimateControl is suitable, could we add support in the Apps for a better button to toggle it on and off? I see there is a car_doors5bits.HVAC to signal that climate control is on, but I don't think that is exposed in the android interface. This would be a good candidate to provide feedback that the climate control is on.

3 5

OVMS v2 Memory/Settings Corruption
by Julien Banchet 12 Dec '16

12 Dec '16

Hi all, Thanks to Michaels last message to remind me to ask a question here: Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip ! It seems it happens only upon reconnection of the ovms module the the OBD plug (Twizy) as, well, the 12V battery, though brand new, can't last a weekend (car parked underground, I suppose the GSM needs to force a bit too much) So question: Has any one suffered from such an issue ? And, otherwise, Michael might be able to tell: Would having the feature on SMS only (without IP) consume less energy ? If so, would it possible to imagine a Hybrid mode, IP active only if vehicle on charge or keyon ? Thanks, JaXX, PS: Despite winter, thinking of building a solar panel + thin plexi sandwich for the rooftop, just because of the 12V battery :-) Only recent twizys can charge the 12V from the traction battery when resting.

5 21

Twizy firmware 3.8.1
by Michael Balzer 25 Nov '16

25 Nov '16

https://dexters-web.de/downloads/en https://dexters-web.de/ovms-twizy-3.8.1-text_78.en.htm Framework V2.9.1: - DIAG mode automatically started when booting without SIM, shown by constant green LED and no longer terminated by inactivity - DIAG mode SMS and MSG command output now prefixes all message lines with "# " and terminates with "#." on a single line (easier to process from tools like the perl client) - Added "CARON" alert for vehicle stopped turned on (first after 15 minutes, followups every 60 minutes) Twizy 3.8.1: - Trip report energy usage now based on odometer and also showing SOC gains - Charge power & energy, battery voltage & current now also in framework (for App display and tools) - Alert on SimpleConsole key presses when vehicle parked (i.e. for external alarm sensors) - Charge power limiter Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

OVMS v3 Design Outline
by Mark Webb-Johnson 05 Nov '16

05 Nov '16

Firstly, an apology for the continued delays with this. The IOT environment is changing so fast, and there are so many amazingly capable choices appearing in the market, that it is hard to select one and live with it for the coming years. That said, we now (finally) have a solution that I think will provide a fantastic platform for OVMS in the future, and meet most of our goals. So, here’s the design outline. MCU Platform I’ve obtained samples for, and tested, over a dozen MCU platforms over the past 9 months. None have been perfect, but one has come very very close. As many of you guessed, I feel that the ESP32 platform <https://espressif.com/en/products/hardware/esp32/overview> has pretty much everything we need and is the clear winner. a) Cost effective (MCU, bluetooth, wifi, plenty of RAM and FLASH; all in a single module the size of a postage stamp). b) Free-RTOS based operating system c) Over-the-air update support d) Open GNU based toolchain e) Great community support The main negative is that it only has a single on-board CAN bus, and that has zero documentation at the moment. But it has SPI and can interface to something like the MCP25625 to give us up to 3 CAN buses. The other issue is that this is so new that documentation is limited; although the manufacturers are working hard on this, and helping us where they can. So, from a platform point of view, that is what I am working on. A motherboard of our own containing buck converter style DC-DC conversion (high efficiency) from both 12V (vehicle) and 5V (usb), a WROOM-32 ESP32 FCC/CE certified module, SD-Card, USB port, OVMS ports, CAN circuitry, and two expansion slots. Expect 16MB RAM, giving us about 4-6MB maximum code size (based on the OTA scheme of one factory firmware image, one running firmware image, and one downloading firmware image). That base module will support bluetooth and wifi connectivity. Cellular will be provided by a plug-in module in an expansion slot, leaving one spare expansion slot free. Low power modes will be built in to the design, from the bottom up. I’m trying to get the cost of this right down. Base module cheaper than OVMS v2. With the cellular option, around the same price. A base OVMS v3 module could be used for CAN bus reverse engineering work, data logging, etc, at a very very competitive price. We’ve got prototypes for this running on breadboards already, and we are about to start the board and casing layout. I’ve also got a handful of ESP32 development boards available if anybody wants to help out with base platform code. Cellular Connectivity The base module will have an expansion connector for optional cellular connectivity. The idea is to make this modular, so we can swap out modems if necessary. The issue with OVMS v1 and v2 has been cellular connectivity plans. Everyone using a mix of prepaid SIMs, on a huge number of different networks, and all of us having to deal with topping-up and other hassles; the AT&T sunset of 2G being a good example. We tried GeoSIM, but it is just too expensive. A few years ago, I backed a kickstarter project called ‘konekt’. They were building a small cellular module, and IOT cloud, very early on. What they have produced has turned into two offerings: a) their cellular module with support for their cloud, and b) a MVNO (mobile virtual network operator) with very competitive data rates and worldwide coverage. You can find them now at www.hologram.io <http://www.hologram.io/>. I’ve been watching them grow, and testing their SIMs, and have been very impressed. It seems to be an amazing match for what OVMS needs. Specifically: a) Simple SIM that we can add to every OVMS module going out the door. b) Global activation (they use two zones, with most of the world where OVMS is in the cheapest zone 1). c) Zone 1 pricing of about US$0.40/month basic upkeep, plus US$0.60 - US$1.00 per MB of data. Zone 2 perhaps 20%+ more expensive. A 3MB zone 1 plan is around US$2/month all in (US$3/month in zone 2). d) Free inbound SMS. We can offer an option to put the cellular modem to low-power sleep, and be woken up by an SMS (from OVMS server) when an App connects. Free. Perfect for vehicles like the Twizy. e) Simple API based console so we automate the accounting side of things. f) Bi-directional SMS is available for normal SMS style rates (free inbound, with outbound at about US$0.19/message, plus US$1/month in USA if you want a fixed number). Hologram has partnerships with multiple carriers for each country. For example, in Hong Kong my car OVMS uses a family-plan style multi-sim approach. I get four SIMs and they all share the same data, call and sms plan. The one I use is from a carrier called CSL. It works well, except in front of my house or in my garage - where there is no coverage. I pulled out that SIM and put in a hologram sim (remembering to change the APN to “HOLOGRAM” before I did it, of course). The Hologram sim immediately connected to CSL and everything worked smoothly. Then I moved the car to the front of the garage. I saw the network disconnect from "Hong Kong CSL Limited” (carrier lost) and reconnect to "SmarTone Mobile Com Ltd”. Then I reversed into the garage, and saw the connection switch to "Hutchison Hong Kong”. On my drive to work I took a northerly route near china and got a switch to "China Mobile HongKong Comp Ltd”. The point is that I’m paying one data plan, but able to take advantage of 4 different networks. The plan is to put these SIMs in every OVMS module from the factory, and to offer a quick and simple provisioning system. Other SIMs could of course still be used, but this would be the default approach. Hologram SIMs are also available today to OVMS v2 users in USA (particularly those about to be stranded by AT&T). Hologram supports the T-mobile network in USA. This should give us some breathing room to give us time to get OVMS v3 out, without rushing things but getting things right as a base platform going forward. Protocol When OVMS v1 was designed, we rolled our own protocol out. This was far from ideal, but it was so early in the IOT world that there wasn’t anything else out there lightweight and mature enough to be used. Today, things have changed and there is a huge selection to choose from. That said, there is one clear winner of all these choices. The IOT world is varied, but the one clear solution that has appeared is MPPT (Message Queuing Telemetry Transport <https://en.wikipedia.org/wiki/MQTT>). The decision as to which hardware platform to choose has been incredibly hard. By comparison, the choice of protocol is a ‘no brainer’ - OVMS v3 will use MQTT. Specifically, MQTT v3.1.1 over SSL over TCP/IP. The protocol itself is very lightweight, very flexible, and offers a simple but powerful publish/subscribe model. The big advantage of this is that it is an open protocol with many clients and applications supporting it. Your house can subscribe to vehicle events just as easily as your cellphone app. Relatively easy to do “Hey siri set my car temperature to 20 celcius” style actions, as well as hook into home automation, etc. Server I really like the Amazon approach to MQTT, but consider that too proprietary and hard to integrate to others. We’ll probably end up just running our own Mosquitto MQTT server on the same machine as OVMS v2 currently runs on, but the protocol is open and easy to choose from the dozens of implementations out there. Apps Existing Apps should continue to work via a bridged OVMS v2 server. Longer-term, it will not be hard to change the Apps to switch to MQTT protocol (presumably over websockets). So, that is the plan. I hate to give timelines (especially when it depends so much on the ESP32 Expressif guys getting their documentation out, and WROOM-32 modules available in large quantities), so all I can say is it is happening ‘now’. I have the development environment in place, and am building the framework support for OVMS using the development boards I have. Also working with the guys in China to get the OVMS v3 hardware design finalised. I hope to be able to release what I have so far to github before the end of November. Regards, Mark.

4 6

Hologram.IO announcement on TMC
by Mark Webb-Johnson 03 Nov '16

03 Nov '16

https://teslamotorsclub.com/tmc/posts/1813075/ <https://teslamotorsclub.com/tmc/posts/1813075/> We've been talking to a MVNO (mobile virtual network operator) called Hologram, and have had some very good initial test results in Hong Kong. You can find them at: http://www.hologram.io/ <http://www.hologram.io/> It is most likely that OVMS v3 will come with Hologram.IO SIMs and we will use these as our default cellular provider, worldwide. Zone 1 pricing (including USA) for a 3MB plan is U$1.99/month, and the 5MB plan is US$2.99/month - that amount of data should be fine for normal OVMS usage. Overage is US$1/MB. Alternatively, you can pay-as-you go at US$0.40/month for the SIM connection, then US$0.60/MB. This is really designed for data usage, but SMS is available at a price. Incoming SMS is free, and outgoing is US$0.19/message. If you want a fixed USA number, it is another US$1/month. To migrate an existing OVMS module to this, you SMS "GPRS hologram" to the module while it is still connected to the network using your old SIM. When the acknowledgement comes back, turn off the module, switch in the Hologram SIM, turn on and enjoy. The SIM will seamlessly switch to whatever cellular network it supports. It can even roam (although Canada and Mexico are zone 2 so you would need to pay the higher rates). If your existing OVMS is offline, you can provision it using the Hologram web console. There is a facility there to send an SMS message to the module, and view the reply messages online. If anybody wants to try this out, please let me know and I'll make the necessary arrangements.

1 0