Open Vehicle Monitoring System

[ecarfan]

Thanks Tom. And until just now I had completely missed the "Control" function at the upper right corner of the App's information screen! When you said the time zone offset could be set in the App I started looking for how to do that and for the first time noticed the "Control" function. Cool.

 

[samcarney]

The documentation is wrong, the time zone offset is parameter #23 not #24. (See the definition of PARAM_TIMEZONE in params.h.) Note also that it's a Parameter, not a Feature.

The format of the time zone offset is hour:minutes, with negative hours for time zones east of GMT.

For PDT, you want to set parameter #23 to -7:00.

As far as I know, there's isn't a convenient way to set parameters by SMS. Notice there is no documented PARAMS command. There is an undocumented PARAMS command, but it requires you to send a list of all of the parameter values starting with the miles/km (so parameters 2 through 23, 22 strings including the crazy ACC configuration strings).

The best way to set the time zone offset is through the iPhone or Android app.

View attachment 75615

For people who aren't using an iOS or Android device, it would be nice to have a PARAM command that works like the FEATURE command, or a dedicated command for setting the timezone offset.

Thank you Tom, for the info. Is there somewhere to get a list of all the "parameter" functions? I would also like to know if there is a listing of the "Vehicle Alert Codes". Thank you in advance for your expertise.

 

[tomsax]

Thank you Tom, for the info. Is there somewhere to get a list of all the "parameter" functions? I would also like to know if there is a listing of the "Vehicle Alert Codes". Thank you in advance for your expertise.

AFAIK, there's only one PARAM-related SMS command: send all of the parameters in order, separated by commas, starting with the Miles/Km setting (you have to set the first two, registered phone and module password, with the REGISTER and PASS command, and I'll bet setting the server password doesn't work, so you'll probably have to stop there). You can see what the param values are by looking at the Params page on the iOS app, and presumably the Android app as well. (Launch the iOS app, wait for the connection to go live, tap on the Settings tab, tap on the (i) on the far right of your vehicle entry, tap Control, tap Parameters.)

Here's a partial list of the Roadster error codes.

 

[samcarney]

Thanks Tom. I know how to get to the parameters page. But what do they do? Example parameter #23 will set the time, #14 sets the vehicle type. What about the others?

About error messages. I get for example "Vehicle Alert Code: TR1N/1163 (00000009)". I know that TR1N is a Roadster 1.5, TR2N is a 2.0. What about the other numbers?

- - - Updated - - -

Thanks Tom. I know how to get to the parameters page. But what do they do? Example parameter #23 will set the time, #14 sets the vehicle type. What about the others?

About error messages. I get for example "Vehicle Alert Code: TR1N/1163 (00000009)". I know that TR1N is a Roadster 1.5, TR2N is a 2.0. What about the other numbers?

OKAY! Got the this part figured out "TR1N/1163", etc. What about the numbers in Parenthesis?

Thanks again!!

 

[markwj]

OKAY! Got the this part figured out "TR1N/1163", etc. What about the numbers in Parenthesis?

You can pretty much ignore them. Nobody outside Tesla knows what they mean. They are shown as 'data' on the Tesla VDS when the alert comes up.

 

[samcarney]

You can pretty much ignore them. Nobody outside Tesla knows what they mean. They are shown as 'data' on the Tesla VDS when the alert comes up.

Thanks Mark.
One other question I have regarding the "Features" #0-Digital speedo, #8-GPS Stream, #9-Minimum SOC, #14-Car bits, #15-CAN Write. What is the function of the ones that I have not listed?
Okay one more question? On the "Parameters" page. What is the function of #13 and #15 - #22.?

 

[tomsax]

The parameter values are documented in the OVMS Roadster user manual, which you can always find by going to openvehicles.com.

Note that the time zone parameter is in slot 23, not 24. Parameters 20-22 are currently unused.

 

[samcarney]

The parameter values are documented in the OVMS Roadster user manual, which you can always find by going to openvehicles.com.

Note that the time zone parameter is in slot 23, not 24. Parameters 20-22 are currently unused.

Thank you.
Sam

 

[Stuart]

OVMS and IPv6

I’m in Japan, on a network that has only IPv6 (with a NAT64 translator for accessing IPv4 services like tmc.openvehicles.com). The iOS OVMS app (version 1.6.6) just seems to hang, unable to connect to the server.

According to my Mac, the tmc.openvehicles.com server is accessible (via the DNS64/NAT64 translator) at IPv6 address 64:ff9b::36c5:ff7f:

% host tmc.openvehicles.com
tmc.openvehicles.com has address 54.197.255.127
tmc.openvehicles.com has IPv6 address 64:ff9b::36c5:ff7f

And I am able to connect to port 6867 over IPv6:

% telnet tmc.openvehicles.com 6867
Trying 64:ff9b::36c5:ff7f...
Connected to tmc.openvehicles.com.
Escape character is '^]’.

but the iOS OVMS app doesn’t connect.

I checked out the source code from GitHub, and it looks like it’s supposed to support IPv6, so I don’t know why it’s not working.

If someone more familiar with the code cares to take a look, you can make your own DNS64/NAT64 network for testing by option-clicking the “Internet Sharing” checkbox in System Preferences in OS X El Capitan. (Instructions are given in the first part of this Apple Developer Conference presentation.)

 

[widodh]

Well, couldn't somebody add native IPv6 to the OVMS server?

 

[markwj]

OVMS Future

Here's the official statement - or as close to official as Open Vehicles gets ;-)

We are aware of the upcoming decommissioning of 2G GPRS systems by some regional carriers. Today, there are millions of 2G M2M (machine-to-machine) devices in the field today, and it will take some time to upgrade those devices to 3G/4G, and some may simply never be upgraded. The approach taken by most is to switch carrier to one still supporting 2G GPRS.

The SIM908 module we currently use for OVMS is already past end-of-life and remaining stocks are extremely limited and expensive. There is a replacement SIM808 radio module, with similar specification to SIM908 but that requires modifications to our board layout. We are currently out of stock of OVMS v2 modules (using SIM908), and trying to arrange a final batch (v2.5) using SIM808 modules. Hopefully this final batch will be available during March 2016 timeframe. OVMS v2 is a 2G system, without WIFI or BLUETOOTH.

Longer term, we are working hard on the OVMS v3 system. Specifications and timeline are subject to change, but the following notes on OVMS v3 may help:

• We will use 32bit ARM architecture, support multiple CAN buses, and be very extensible. We are trying to get as much RAM and FLASH memory as possible, to avoid the limitations of the OVMS v2 architecture.
• We anticipate being able to maintain the same DB9, antenna, and GPS connectors, so as to be a simple plug-in replacement.
• Apps will be backwards compatible (supporting both OVMS v2 and v3 modules).
• The design is for a base module to support at least 2 CAN buses, with SD card, USB, WIFI and BLUETOOTH connectivity as standard.
• 3G/4G connectivity will be provided by an optional plug-in module (with different modules available for different regional requirements, and making it easy to replace the module without having to replace the entire OVMS system).
• Expansion will be via plug-in modules, and expansion connectors.
• Firmware will be all new, based on a multi-threaded embedded RTOS.
• The base module will be able to perform CAN bus logging over USB, WIFI and/or BLUETOOTH.
• The base module will also be able to perform the usual OVMS functionality (but you will need a 3G/4G radio module if you want to be able to receive alerts or check vehicle status when out of WIFI/BLUETOOTH range).
• We anticipate having an extremely limited number of development boards available 2016Q2, for firmware developers.
• The OVMS v3 production modules should be available sometime during the second half of 2016.

I hope that the above helps.

Regards, Mark.

 

[Habious]

Just so I'm clear (because I can sometimes be a little slow)...this statement...

3G/4G connectivity will be provided by an optional plug-in module (with different modules available for different regional requirements, and making it easy to replace the module without having to replace the entire OVMS system).

...ONLY applies to the v3 hardware (which doesn't exist yet), correct?

i.e. Those of us with v1 and v2 hardware (which is everyone with OVMS at the moment) won't have the option to expand to get 3G/4G without buying the new v3 module...when it becomes available.

 

[markwj]

Just so I'm clear (because I can sometimes be a little slow)...this statement...

...ONLY applies to the v3 hardware (which doesn't exist yet), correct?

i.e. Those of us with v1 and v2 hardware (which is everyone with OVMS at the moment) won't have the option to expand to get 3G/4G without buying the new v3 module...when it becomes available.

Yes, those specs are for the OVMS v3 system. For v3, the radio module will be an optional pluggable component.

For OVMS v2, the radio module is more than 50% of the component cost and soldered on the board. Replacing that module is prohibitively expensive. Even if we could find one pin-compatible (we can't), solder re-working a surface mount component like that is not for the faint hearted. Overall, any return-upgrade-replace option for v2 owners would cost more than a new v3 module.

For OVMS v1, in theory we could do a replacement baseboard (which contains the modem module). But, for v1 the baseboard is more like 80% of the component cost. Again, not economical to upgrade it in place.

So, for v1 and v2 owners we're going to help offset the replacement cost by offering discounts on the v3 hardware for existing users. Add to that the new processor capabilities, wifi, bluetooth, usb, and so much flash and ram that we can add some cool new features (and implement existing features better).

 

[Nvbob]

Mark

Count us in. Let us know if you need beta testers.

 

[AEdennis]

Mark

Count us in. Let us know if you need beta testers.

I second that...

Also thanks for the clarification @MarkWJ

 

[samcarney]

Here's the official statement - or as close to official as Open Vehicles gets ;-)
/QUOTE]

Thanks for the update Mark. I'm eager to upgrade to OVMS V3 when it is released. I'm confident it will be as robust as V1 & V2, and with additional functionality. Can't wait!!

 

[dsm363]

Waiting list for V3?

 

[markwj]

Thanks guys. The first development boards will probably go to the core vehicle development people (you know who you are) so that they can work on porting their v2 vehicle support to the v3 platform. Biggest issue is likely to be 8bit -> 32bit and backing out all the optimisations that were made to work in an 8bit environment. Those will be base boards only (usb, wifi, bluetooth but no cellular). Close to final design, but a bare board only (not in a case). Once we've validated the final design, and are sure the core functionality is fine, we'll proceed to putting it in a case (which is actually trickier than v2 because of the bluetooth and wifi antenna).

For those not on the developer's mailing list, I'll post periodic updates here. Especially as we get close to building the first batch.

 

[samcarney]

Here's the official statement - or as close to official as Open Vehicles gets ;-)

Thanks for the update Mark. I'm eager to upgrade to OVMS V3 when it is released. I'm confident it will be as robust as V1 & V2, and with additional functionality. Can't wait!!

 

[markwj]

Waiting list for V3?

I'm #1 on the founders list ;-)