Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Open Vehicle Monitor System (OVMS) - Technical Discussion

This site may earn commission on affiliate links.
I just got a text from h2o saying that the 2G network goes down at the end of the year. Any had luck with T-Mobile yet?

I also just received this text... I would love to move to a permanent solution instead of another 2g carrier that is going to sunset 2g soon anyhow...

Do we have any idea on when 3G will be available?
 
I also received the message from H2O, stating that the 2G network will go down at the end of the year. I believe that is because they use AT&T hardware, which will be shut down at the end of the year. For what it's worth, I did a quick search of the net and found several references to Verizon and T-Mobile retiring their 2G networks in 2020. For those with T-Mobile access, that may provide a temporary solution.
 
I do not think it has anything to do with the tele network, SMS communication seem to work well, but i start getting some alerts from the OVMS web interface. Recently I have received twice the following: Vehicle Alert #981: Bad State Transition fault.
Anyone know what this is about? I Charge with the small mobile charger (EU specs.)
 
The Forum wiki for the Roadster has a pretty good list of fault cods. Unfortunately, the info for #981 isn't very helpful. Scroll down through the wiki and look for the thread titled Roadster. If you learn anything about this error you can help others by editing the wiki with what you learn.
 
The following design outline for OVMS v3 was posted to the OVMS developer's mailing list. Comments welcome, but best to feedback directly to that list as that is where the discussion is happening.

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 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. 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). 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 around the end of November. The v1.0 of ESP32 development environment will be released at around that time.
 
The Forum wiki for the Roadster has a pretty good list of fault cods. Unfortunately, the info for #981 isn't very helpful. Scroll down through the wiki and look for the thread titled Roadster. If you learn anything about this error you can help others by editing the wiki with what you learn.
Thanks for your help - it was very useful. Yes it seem to be related to the the spare connector which were delivered with the car. My garage where the Roaster is parked is in a community area, where my plug has a so-called "distribution meter" for reading my Roaster's consumption. I know that there is a lot of disturbance on the supply side and several power cuts. Hope that the matter settle - Thanks for having the OVMS, always able to know what is going on. Btw. for the v3, personally I think it would be great to have a WiFi option. My Roaster is often parked on -3 where the is no mobile signal. I know that one cannot get all:)
 
Btw. for the v3, personally I think it would be great to have a WiFi option. My Roaster is often parked on -3 where the is no mobile signal. I know that one cannot get all:)
It will have WiFi by default. Cellular is optional (sort of...).

Many thanks to Mark for putting so much time and effort into this. Mark, I'm going to nominate you for MVP for all of the EV community.
 
  • Like
Reactions: markwj and wiztecy
Btw. for the v3, personally I think it would be great to have a WiFi option. My Roaster is often parked on -3 where the is no mobile signal. I know that one cannot get all:)

v3 will have wifi and bluetooth by default (it comes with the MCU we have chosen). Cellular will be an option (and that will come with hologram.io sim as default). This will allow us to change cellular modem in future, should the need arise, as well as offer different modems in different markets.

The event system we are coming up with allows us to do all sorts of really cool stuff. Kind of like ACC on steroids. Every time something happens (SOC change, charge starts, charge stops, plugin, enter a location area, leave a location area, etc) an event fires and you will be able to configure something to happen based on that event (plus other attributes). For example, when I get to my home location, turn on wifi and turn off cellular (to save power and data charges).

Many thanks to Mark for putting so much time and effort into this. Mark, I'm going to nominate you for MVP for all of the EV community.

Aw, shucks. You've done quite a bit as well yourself, Henry. A lot of Roadster owners rely on your CANs every day.
 
I might as well keep replying to myself. :)

FYI. There is one catch. A 24 month contract is required.

There is a plan that is $1.50 / month for 1 MB of data. or $5 / month for 50 MB of data. Text messages are 0.01 each. Seems pretty good, but I'm not sure about committing to 24 months.