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.

markwj

Asia Pacific
Moderator
Apr 10, 2011
4,681
1,380
Hong Kong
Opening this thread for technical discussions and progress on the technical side of the OVMS used in Tesla Roadster.

The general discussion of OVMS is at Open Vehicle Monitoring System

We've now published the github code repository for this project. The master branch is at:

markwj/Open-Vehicle-Monitoring-System - GitHub

So far, today, we've uploaded the vehicle code (in vehicle/OVMS.X - a PIC MP Lab X project), hardware module wiring schematics (in vehicle/Car Module), and common artwork for the Apps (in apps/artwork).

There was a last-minute change in protocol from UDP/IP to TCP/IP (due to restrictions we found that some cellphone carriers source NAT GPRS traffic, and that was causing problems with the source port of the UDP/IP connection changing unless we issued keepalive packets every 20 seconds - which would eat into cellular data plans). The SIM900 modem we use supports TCP/IP as well as UDP/IP, and switching to TCP/IP will allow us to maintain a permanent connection to the server and then bi-directionally communicate over that. This is something like the approach Apple does with their APNS (Apple Push Notification System) - the car maintains a connection back to the server, then either the car or the server can send messages over that established connection. These TCP/IP connections, while still source NATted, don't suffer from the same keepalive issue as UDP/IP and can be maintained for hours/days at a time (with very little network traffic). This change has set us back, but we are confident that the new approach will yield better results in the long term.

The framework for the in-vehicle firmware is working well. SMS works, and status can be reported to the server over TCP/IP now. The main areas of the vehicle firmware we want to work on are:
  1. Encryption (RC4+Base64) for network protocol
  2. Interrupt-driven CAN bus
  3. Extension to the event model to allow waiting for modem responses without requiring a new state to be created
  4. Pending status updates (if the network is down, queue the status update for when the network comes back)
  5. Better alerting (via network status updates or SMS)

With the switch to TCP/IP, we are now handling the necessary changes to the server code. Once that is done, we'll publish the server code as well as APIs for car-server and server-app, so that the Apps can be worked on.

Several people have already let me know that they want to help out with development, and that is most appreciated. I really hope we can build a community around this. The steps to help out are (a) create a free github account (if you don't have one already), (b) pull the code, (c) github 'watch' the project, (d) fork the project if you want to work on a branch, or let me know your github username if you want to be a collaborator and need write access to the master repository, or just send me patches/fixes/extensions for merging into mainline. It would also be helpful if you could PM me your TMC forum username and eMail address so we can keep in touch.

A final note: the hardware is coming ;-) We've in final sample stage at the moment, and the factory should start production of the first batch of hardware modules real soon. We're just working through the logistics of how you can actually purchase it and get it shipped safely.

Thanks, Mark.
 
What we have on the VDS can bus messages, so far.
Most (if not all) of the work has been done by Scott451.

Scott451 said:
Status messages to the VDS are sent on CAN ID # 0x100. The first byte (B1) is a sub_message index.
The bitrate is 1Mbps. A simplification of the messages you need and their interpretation is as follows:

Bytes are numbered B1 to B8 not B0-B7
bits are numbered bit0 to bit7
Byte pairs are in little endian order (e.g B4*256+B3)

Charger V1.5
B1=0x95
B2=State (1=charging, 2=top off, 4=done, 13=preparing to charge, 21-25=stopped charging)
B3=Sub State (2=scheduled start, 3=by request, 7=connect power cable, 9=xxMinutes-yyKWHrs,)
B5=Mode (0=standard, 1=storage,3=range,4=performance)
B8=Charging KWhrs (see sub state 9)

Charger settings
B1=0x88
B7=Charge limit
B2=Charging current
B3 & B4 Charge duration in minutes (see charger V1.5 sub state 9)

Charger interface
B1=0x89
B3&B4= Vline
B6=Iavailable(from pilot PWM)

Doors
B1=0x96
bit2 of B2 = Charge port (open=1/closed=0)
bit3 of B2 = Pilot present (true=1/false=0)
bit4 of B2 = Charging (true=1/false=0)

Range
B1=0x80
B2= Adjusted state of charge
B3&B4= Ideal range
B7&B8= Estimated range

messages from the VDS are sent on CAN ID # 0x102.

Set Charge mode
B1=0x5
B2=0x19
B5=Mode (0=standard, 1=storage,3=range,4=performance)

Start/Stop charge
B1=0x05
B2=0x03
B3=0x00
B4=0x00
B5=(Stop=0x00, Start=0x01)
B6=0x00
B7=0x00
B8=0x00

Scott451's Disclaimer: My CAN bus interpretation could be wrong. I don't work for Tesla nor have any friends that do. I'm just passionate about Tesla's products and understanding how they work. The data is the result of my own analysis of my 2008 roadster. CAN bus messages on the 2010 are slightly different (e.g V2.0 charge mode is on B6 bits 7-4 not B5 and the UTC start time offset is in minutes).

The OVMS implementation of this is at:

vehicle/OVMS.X/can.c at master from markwj/Open-Vehicle-Monitoring-System - GitHub
 
Last edited:
A document on what we know of the Roadster CAN bus messages has been posted at:

vehicle/Car Module/canbus_notes.txt at master from markwj/Open-Vehicle-Monitoring-System - GitHub

and a perl script that parses a CSV log from a CAN-USB adaptor to decode and show what is known is at:

others/roadster_can.pl at master from markwj/Open-Vehicle-Monitoring-System - GitHub

Both are being updated fairly regularly.

This is the result of original work done by Scott451, extended by markwj and fuzzylogic. New discoveries of messages for trip counter, odometer, speed, doors, TPMS sensors and lock/unlock are very exciting and should open up a lot of functionality.
 
Yesterday I got a notification on my iPhone from OVMS but it only said:
SMS from: -MSG:
and nothing else. There is no sms on my phone. Did the module receive and SMS?

Yes, that is the SMS forward feature. Your SIM in the OVMS module must have received an SMS messages and tried to forward it to you. Both the caller phone number and message were blank.
 
From oktober 2012 I am using the OVMS module with a SIM card of GeoSIM inside. The first 5 weeks all went well but from that moment on I have to do a hardware reset about every week by removing the CAN cable, wait for 1 minute and connect again. Sometimes it works for 5 days, sometimes I am already out of connection after 3 days. When this happens SMS is also out which is logical because the module is continously trying to connect to the server.
On the module the green light is blinking, so the connection with internet is OK.
My conclusion is that the server sometimes close the connection to my car. After the hardware reset everything immediately goes well for as stated above a few days.
On the app on my phone I read the whole time "updated x hr ago", which means that live is not possible as the car is not communicating with the OVMS server.
What needs to be altered Mark?

Marius
 
Mark,

i noticed that the OVMS stopped working on my Roadster. I have been experiencing the 12v issue and a Ranger is coming out on Monday to fix it. My question is does the OVMS run off of power from the 12v battery? If it does, can it contribute to it loosing power?

Thanks
Bob
 
Mark,

i noticed that the OVMS stopped working on my Roadster. I have been experiencing the 12v issue and a Ranger is coming out on Monday to fix it. My question is does the OVMS run off of power from the 12v battery? If it does, can it contribute to it loosing power?

Thanks
Bob

Not that I am aware of. In the 2.x roadsters, OVMS is powered from the main battery. The 12v battery is only used to power emergency systems.

If you are using v2 hardware, please eMail me (support (at) openvehicles (dot) com) your vehicle ID and I will check the server logs. For v2 modules, we have good diagnostics on 12V power levels.
 
From oktober 2012 I am using the OVMS module with a SIM card of GeoSIM inside. The first 5 weeks all went well but from that moment on I have to do a hardware reset about every week by removing the CAN cable, wait for 1 minute and connect again. Sometimes it works for 5 days, sometimes I am already out of connection after 3 days. When this happens SMS is also out which is logical because the module is continously trying to connect to the server.

Marius,

What is your vehicleid, and version of firmware in the module? Output of MODULE?, SERVER?, GPRS?, DIAG, and VERSION SMS commands would be useful to see.

In older firmware versions, we have seen problems recovering from poor cellular connectivity areas, but that is GPRS only and should not affect SMS. New firmware resolves this.
 
  • Like
Reactions: AtAge19
Has work begun to decipher Model S's systems?

Nope. There has been some interest, but I suspect people are waiting to see what Tesla will release when their Apps come any-day-now. With all the 12V system problems with Model S at the moment, it is probably safest to stay away until the car firmware stabilizes.

The work on Volt/Ampera has produced some OBDII support technology. For that car, we connect to the OBDII port and poll for OBDII parameters, rather than just listening on the bus. Seems to work well, and is very extensible. We even have a standard OVMS-OBDII cable now, which is used for Volts, Amperas, Twizys, and others in development.

That has also produced generic OBDII vehicle support, that will even work in modern ICE vehicles (showing gas tank level in place of battery SOC) - including vehicle status, GPS tracking, etc. Like the Volt/Ampera, this is under development and hopefully we should have something for end users in the next month or so.
 
Mark,
I use this forum as I expect more users to have the same issue. As it seems that is not the case I will contact you via (email)
Marius

Marius,

No problem with people using this forum to ask for help. It is one of its purposes.

The reason I suggest users contact support@ directly is privacy. To help, we often need private information like vehicle ID, status messages, etc - and can't really exchange that here.

Regards, Mark
 
Mark,
Would it be possible for the OVMS app to report secondary system activities like battery balancing/heating/cooling or warnings that might otherwise show up on the display (Tesla Roadster). I don't know if any of these things come across that buss the module is connected to.

thanks
michael
 
Mark,
Would it be possible for the OVMS app to report secondary system activities like battery balancing/heating/cooling or warnings that might otherwise show up on the display (Tesla Roadster). I don't know if any of these things come across that buss the module is connected to.

thanks
michael

Michael,

We already report heating (including percentage). I don't think there is a -specific- pre-charge cooling cycle (like there is for heating).

The error codes and balancing information haven't been discovered yet - although charge interruption alerts are found and reported.