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

Open Vehicle Monitoring System

This site may earn commission on affiliate links.
OVMS Status Update

Some updates:

  1. New v2 base hardware. It is coming. First production batch will arrive in the next few days (probably available for shipping out late next week), with large quantities arriving mid September. After then, things will be stable. We have arranged a China distributor to handle the payments, logistics and shipping of these, so things should be much smoother and quicker going forward (and a lot less of a load on Sonny and I). Price should end up approximately the same as before (+/-).
  2. New v1.3.1 firmware is under testing now. It should be released early next week.
  3. I am aware of the issues with the Android App under some new hi-res phones. The problem is that the code has some logic to detect tablets, and it is mis-detecting some new phones as tablets, based on screen resolution, and that leads to layout issues. Sonny (who is responsible for the Android App) has been hung up at work with an important project that is just coming to fruition. He'll be free in a few weeks to resume work on the Android App, and has the motivation to get it right with his new Android phone. We've got a couple of other developers lined up to help him, but we really need him to lead this. He says that he should be able to finish the new version (fixing the layout issues, and also bringing it up to par with the iOS App for some of the newer features) before the end of October. Sorry it has taken so long, but this has been really tricky to solve.
  4. We have a few small changes to the iOS App, and an update will go to Apple for approval in the next few days.

It has been quite over the summer holidays, and we have some exciting announcements to come over the next few months.

Regards, Mark.
 
I forgot to say that if anyone needs a hardware module, please create an account on Open Vehicle Systems. As soon as we get the new modules in stock, we'll be sending out an eMail to users there with instructions. The accounts created there since the old modules went out of stock will get priority (as presumably everyone up until that point has got a unit anyway).
 
OVMS v2 Base Vehicle Module Availability

We're pleased to announce that the new OVMS v2 base vehicle module is about to become available.

For existing users, there is no requirement to upgrade to this new version - there is no difference in functionality for Tesla Roadster users between the v1 and v2 modules. The new hardware is primarily intended for new users, and to support vehicles other than the Tesla Roadster. You can, however, of course upgrade if you want to.

To speed-up and smooth the delivery process, we've appointed a new distributor in China, who will be able to fulfill your orders online, starting deliveries next week. This distributor is just starting up their online business in China, their website is currently under beta-test invitation-only, but they have agreed to provide early access invitation codes to OVMS users.

If you would like to order this new hardware now, the arrangement will be:

  1. You send an eMail to [email protected] letting us know your openvehicles.com user id, and how many modules you would like to order.
  2. We will be putting those order requests into a first-come-first-served list. We have a rather large list of pre-orders, and we'll honor their positions in the list (but they still need to eMail us to let us know they still want them).
  3. Early next week we will send out invitation codes and instructions.
  4. The first modules will ship out mid next week.

In about three week's time, we expect to receive a much larger shipment of modules and the China distributor's website will go public. At that point, we'll just direct people to go to that site directly to order whatever they need.

Thanks for all your support in this project. It is truly exciting to see it move forward in this way.

Regards,
Mark Webb-Johnson
openvehicles.com

ovmsv2-3.jpg
ovmsv2-2.jpg
ovmsv2-1.jpg
 
Mark, you mentioned that there was going to be a new firmware for the existing 1.x hardware. Is this available yet?

EDIT - I found the 1.3.1 on the website and downloaded it to my OVMS module. There is no way to view the version from the Andriod App, but I send the "version" text message and I am now on 1.3.1. Since there are no release notes yet, is there anything different I should notice with the new firmware?
 
Last edited:
Are there plans to add a cool-down feature similar to the Tattler where when you get home it will charge for 45 min or so at 16A then restart the full charge at scheduled time in evening?

I've tried to do this, but can't see any affect. What I've tried is 220V 10A, but the battery temperature doesn't change much. Maybe this needs 110V?

Some discussion on this on the OVMS developers mailing list, and best to raise it there. If someone can give us the (repeatable) logic for this, we can do it.

- - - Updated - - -

Mark, you mentioned that there was going to be a new firmware for the existing 1.x hardware. Is this available yet?

EDIT - I found the 1.3.1 on the website and downloaded it to my OVMS module. There is no way to view the version from the Andriod App, but I send the "version" text message and I am now on 1.3.1. Since there are no release notes yet, is there anything different I should notice with the new firmware?

Change log at:

http://www.teslamotorsclub.com/showthread.php/7716-OVMS-Installation/page17?p=182321&viewfull=1#post182321

Repeating here for clarity:

Tom Saxton has put up a great firmware update guide at:

OVMS Firmware Update Guide

and is also hosting copies of the binary firmware there.

Another option is to contact one of the developers listed at the top of this thread, who have offered to help users in their area upgrade.

We do recommend that all current users of OVMS upgrade to this version. It includes lots of bug-fixes, some new features, and better modem control.

Regards, Mark.

Code:
2012-09-02 1.3.1       Firmware 1.3.1
                       The following issues have been addressed (since 1.2.9):

                       Tidy-up for charge notifications
                       #57 Car: Motor temperature overflow
                       #58 Car: Strange range when low on power
                       #69 Wakeup temperature subsystem when car is woken up

2012-08-28 1.2.9       Preliminary firmware 1.2.9
                       1.2.9 - a (almost feature complete) release candidate for 1.3.1

                       This version is an (almost feature complete) release candidate
                       for 1.3.1. It addresses a few known bugs, but primarily works
                       on (a) adding support for v2 hardware, (b) improving recovery
                       from loss of GSM signal in poor cellular coverage areas, and
                       (c) changes to the alert notification mechanisms to try to catch
                       more 'charge stopped' type events.

                       The following issues have NOT been addressed, but should be
                       fixed in the final 1.3.1 firmware:
                         #57 Car: Motor temperature overflow
                         #58 Car: Strange range when low on power

                       The following issues have been specifically addressed:
                         #60 Car: Still getting some GSM unrecoverable issues
                         #61 Car: Acknowledge settings with detailed parameters
                         #64 Support for v2 base hardware
                         #65 Increase timeout in NET_STATE_NETINITP
                         #66 Increase modem reset timer to 2 secs
                         #67 Car: Raise charge interrupted alerts based on charge state (stopped vs done
                         #68 Give COPS a chance

2012-05-27 1.2.7       Preliminary firmware 1.2.7
                       Bug fix for off-by-one-can-byte bug in roadster id from VIN
                       Add homelink and charge timer support, plus misc fixes
                       Only send non-empty params to PARAMS? sms command
                       Remove need to RESET after can write change
                       Only NETINIT (not SOFTRESET) after a parameter change
                       Re-label parameters internally to match new user-friendly names
                       Re-work of sms command handlers to be table driven - saving 6% of flash
                       Use the 6% of flash we saved to implement a bunch of SMS commands
                         REGISTER?                                  Report on registered phone
                         REGISTER <modulepass>                      Register caller phone
                         PASS?                                      Report on module password
                         PASS     <modulepass>                      Set new module password
                         GPS?/GPS [<modulepass>]                    Report GPS location
                         STAT?/STAT [<modulepass>]                  Report status
                         PARAMS? [<modulepass>]                     Report on parameters
                         PARAMS <param2> <param3> .. <paramN>       Set parameters
                         MODULE? [<modulepass>]                     Report on module parameters
                         MODULE <vehicleid> <units> <notifies>      Set module parameters
                         GPRS? [<modulepass>]                       Report on GPRS parameters and status
                         GPRS <gprsapn> <gprsuser> <gprspass>       Set GPRS parameters
                         SERVER? [<modulepass>]                     Report on server parameters
                         SERVER <serverip> <serverpass> <paranoid>  Set server parameters
                         DIAG?/DIAG [<modulepass>]                  Technical diagnostics
                         FEATURES? [<modulepass>]                   Report on features configured
                         FEATURE <feature> <value>                  Set specified feature value
                         HOMELINK <button>                          Activate homelink 0, 1 or 2
                         LOCK <pin>                                 Lock car (with specified pin)
                         UNLOCK <pin>                               Unlock car (with specified pin)
                         VALET <pin>                                Activate valet mode (with specified pin)
                         UNVALET <pin>                              Deactivate valet mode (with specified pin)
                         CHARGEMODE <mode> <current>                Set charge mode (sta, sto, ran, per) and current limit (in Amps)
                         CHARGESTART [<modulepass>]                 Start charge immediately
                         CHARGESTOP [<modulepass>]                  Stop charge immediately
                         VERSION [<modulepass>]                     Report module firmware version
                         RESET [<modulepass>]                       Reset module

2012-05-11 1.2.5       Preliminary firmware 1.2.5
                       LED re-work
                       Support multiple vehicle configurations - TeslaRoadster and VoltAmpera
                       NET driver tidy-ups
                       Auto-support Tesla Roadster v1.5 cars
                       Issue #38 - Prevent user from locking car if car is ON
                       Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
 
I've tried to do this, but can't see any affect. What I've tried is 220V 10A, but the battery temperature doesn't change much. Maybe this needs 110V?

Some discussion on this on the OVMS developers mailing list, and best to raise it there. If someone can give us the (repeatable) logic for this, we can do it.

The Tattler does cool-down by doing a sequence of short range mode charges at 12 amps 240 volts. I am not sure if the length of the charge is just a limited amount of time or if the state of the AC compressor operating is detectable and the charge is stopped and restarted based on this. The sequence of charges is repeated until a set temp threshold is reached or a set time limit is reached. The reason for using range mode charge is in this mode the car cools the battery more aggressively then in standard mode charge.

I have found that my 1.5 roadster will not do active cooling with less 12 amps at 240 volt or 20+ amps at 120 volts.
 
I'm using PicKit 3 under Ubuntu Linux and that is working just fine.

If markwj suggest Pickit 2, take that one, but I can confirm that Pickit 3 works just fine.

Thanks. I'm only buying this for the OVMS and the Pickit 2 is $20 so went with that. I still have a really, really old PC with XP I keep around just for things like this.
 
What parameters do you guys have set for cooldown?

Current mentioned is: 12+ amps at 240 volt or 20+ amps at 120 volts.

But, what about target temperature?

The Tattler uses 12 amp Range mode charge cycles. I have only been using 240 volt charging, the 120 volt reference was based on some testing I did in the past relating to the fact that the 1.5 Roadster did not appear to do active cooling when charging from 120 volts.

My Tattler settings were 40 minute duration with a target of 24C. In very warm conditions it would usually time out prior to reaching target temp. It was normal for me to see a 39 to 41C starting temp with an ending temp of 28 to 34C after 40 minutes with 3 or 4 charge cycles reported.
 
Last edited: