- OvmsDev - Open Vehicles

v1.3.3
by Mark Webb-Johnson 12 Sep '12

12 Sep '12

Hot on the heels of v1.3.1 comes v1.3.3. Here is the change log: 2012-09-12 1.3.3 Firmware 1.3.3 #77 Option for GSM Network selection #74 Car: SETUP (DIAG) mode for firmware #76 SMS HELP command #75 Car: Basic (stub only) Renault Twizy Support #71 Car: Send line voltage level back to server #70 Car: Send hardware version along with firmware version ### Make QC config use TMC server Really, no urgent need to update, as this firmware is primarily intended for the China factory to give them a way to QC modules. Towards the end of this month it will be the firmware shipped with all new modules. At the moment, they are shipping with v1.3.1. The new v1.3.3 firmware, as a side-effect, gives us a way to configure a module without a SMS plan on the SIM (so long as you have a way of getting a PC as a RS232 terminal - not so trivial nowadays). It also gives us a useful diagnostic tool for developers. When a module running v1.3.3 (or later) is switched on, it will go through the normal startup sequence of RED led on, GREEN led flashing out firmware version. Once that is done, both leds will turn off and the module will wait 10 seconds for you to enter SETUP mode. If nothing is done, it will start normally. If, using a terminal emulator connected to the RS232 port you type SETUP (enter) during this 10 second window, then the firmware will enter SETUP (DIAG) mode. # OVMS DIAGNOSTICS MODE (both red and green leds will be flashing 10 at this time) From there, you can type HELP for help, and issue commands. There is a built-in Tesla simulator (CANTXSTART and CANTXSTOP), allowing two modules to be connected back-to-back and the CAN bus to be exercised, and a few diagnostic screens. The QC configuration for v2 modules has been removed, as this new facility makes it obsolete. You can also type "S " followed by a SMS command to run SMS commands locally (e.g.; "S STAT", "S MODULE?", "S FEATURES?", etc). The output of the command will be sent back to the terminal. In this way, you can setup the module without requiring a SMS account. Note that the SETUP (DIAG) mode is kludgy. It relies on the DIAG port as a tap on the uart communications between the modem and the PIC, and on the modem echoing characters typed back. When you type "SETUP", what happens is the "S" goes to the modem which echos it back and the PIC sees it, then "E", "T", "U", "P" and the final ENTER. This string is not recognised by the modem (no "AT" prefix), but is recognised by the PIC in that magic 10 second startup window. Similar for the commands within SETUP mode itself. There is one nasty side-effect of this (which is why I call it kludgy) - if a command/response has an "AT" somewhere in it, then it will be interpreted as a Hayes AT command by the modem. This causes problems with commands like 'stAT', 'feATure", etc. You might see "OK" and "ERROR" responses in the output. It is not perfect, but it works - and is pretty powerful to setup a module. I've also added a new parameter (#13) to this firmware, which can hold a 'locked' GSM network identifier, and associated GSMLOCK and GSMLOCK? SMS commands. If you set this, the usual AT+COPS=0 command will be changed to one to lock GSM carrier to only the carrier you specify (turning off roaming). This is useful for two reasons: (1) the GSM lock is faster and more reliable, (2) roaming SIMs often have multiple carriers at different rates and this allows you to choose the carrier. However, take care. If you are configuring by SMS, setting GSM lock incorrectly will cause the module to be unable to connect to GSM and you'll have to use the RS232 DIAG port to recover. If you want to see a list of discovered GSM networks, in SETUP mode type "AT+COPS=?". Finally, a stub implementation of a Renault Twizy module has been added, to serve as a starting point for the developers working on this. The state of this is similar to Volt/Ampera support - just stub at the moment, with no real functionality yet. Progress is being made... Regards, Mark. P.S. Here are the instructions, with more information, on the QC steps during SETUP. Attached are some pictures and firmware, that has SETUP mode that can be used for diagnostics and QC. Instructions: You need to make a cable to connect two modules together. The cable should be 1 foot long, 4 core, and have 2 DB9 female ends. Soldering is like attached pictures. +12V, GND, CAN-H and CAN-L cables are just connected 1-to-1. Then, you need to put a 120Ohm (approximate - 100Ohm is also ok) resistor between CAN-H and CAN-L on one end of the cable. You also need to arrange a plug for +12V DC power supply and connect to the +12V and GND pins of the other end. This cable provides power to both modules, and a can bus the modules can talk on. With a serial console connected to one module, power up the module (make sure blue LED is on). RED led should be on, and GREEN led will blink 1 then 3 then 2. On the serial console, type SETUP and you should see the module switch to setup mode: # OVMS DIAGNOSTICS MODE For this first module, put the module into CANTXSTART mode. This will start it transmitting messages on the CAN bus. # OVMS DIAGNOSTICS MODE CANTXSTART # Starting CAN sim Leave the first module powered on. You can use this now to QC test many other modules. The module is transmitting CAN bus messages. Move the serial console to a second module to be tested, power up the module (make sure blue LED is on). RED led should be on, and GREEN led will blink 1 then 3 then 2. On the serial console, type SETUP and you should see the module switch to setup mode: # OVMS DIAGNOSTICS MODE For this module, turn on feature #15 with a special command: # OVMS DIAGNOSTICS MODE S FEATURE 15 1 ERROR # Feature has been set. (do not worry about the ERROR - it is ok). Then, type the DIAG command: # OVMS DIAGNOSTICS MODE DIAG # DIAG # Firmware: 1.3.2/V2 # SWITCH: 1 # 12V Line: 14.7 V # Signal: 0 # VIN: ----------------- (TR) # SOC: 0% (0 ideal, 0 est miles) You can see it shows you the firmware version, status of the switch (0 or 1), 12V line voltage, and GSM signal level. It also shows you messages received on the CAN bus from the first module (in CANTXSTART mode). If all is ok, you should see VIN with some numbers (not ------), and SOC, ideal and est miles also showing numbers. If you get this, then the CAN BUS is working. Try to change the switch, and DIAG to see it changes ok. Make sure the blue LED is blinking, and both red and green leds are also blinking together. This tests all the LEDs work. When finished testing, "S FEATURE 15 0" to disable the can bus active mode and then turn off module under test. Regards, Mark.

1 0

What Cellular Provider, and how much are you paying (US$)
by Mark Webb-Johnson 12 Sep '12

12 Sep '12

I've been told by many people, that one of the biggest problems with OVMS is the cellular providers. It is a hassle to maintain a pre-paid card, and the providers keep changing the rules. Particularly in the USA. Could you let me know (with figures in US$, approximately ok, please): What country are you in? What cellular provider and service do you use? How much do you pay, up-front for the SIM card? How much do you pay, monthly for the service (SMS + Data)? How much do you pay, per-MB for data? Long-term viability - do you think this is still going to be possible in a year or two? Anything else relevant? Just reply to this email, on the mailing list. I only need 1 report for each provider, so if you see someone else reply to the list for your provider you can ignore this. Thanks, Mark.

9 9

My OVMS Cellular Plan
by Bennett Leeds 11 Sep '12

11 Sep '12

1. US 2. ATT 3. $0 for SIM card since left over from a phone I don't use. 4. $20/month is my delta. $10 for the number on a "Family Plan" and $10 for unlimited data "non-smartphone". I also get texts free since my family is already on unlimited shared text messages (I have a teenager on the plan). 5. $0/MB - see #4 6. ATT is switching from Family Plans to "Shared Data" plans. I don't know the difference, but if the Shared Data plan makes sense for you anyway, then it could be even better. Basically, the way this works is to be on the Family/Shared Data/Shared Text plan anyway. Then simply add a phone line for $10/month and get a free cheap-o phone, which you don't use. For Family Plan pay $10 for unlimited data. For Shared Data, I don't know what the increment is. Put the SIM in your OVMS. Note that the GoPhone plans were better, but for $20/month I have no hassles and should be grandfathered in for at least another year. - Bennett

1 0

Re: [Ovmsdev] Cool down
by Bennett Leeds 11 Sep '12

11 Sep '12

I've been doing 220volt 15 amp charging to cool the battery. Like Tom, I manually stop it when the battery temp reaches 80F. Like Mark, I found that low amp charges didn't cool the battery as much - I'll speculate that Tesla probably sees the low amperage and figures that it can't waste as much juice cooling the battery, and that a slow charge won't really heat it up much. Have you thought about parameters for the CoolDown function? - Desired End Temperature - Amperage to Use - Maximum length of time to run Also, have you considered an "Auto" feature, where when OVMS sees the car is plugged-in but not charging and that the battery temp is high, automatically kicks on to cool it? The max run time parameter is kind of a safety feature to avoid running too long at high prices. - Bennett

2 1

Model S
by Kenneth Adelman 08 Sep '12

08 Sep '12

I have my Model S if anyone in the SF Bay area wants to come take a look from the point-of-view of supporting ovms on it. Ken

1 0

OVMS v2 Base Vehicle Module Availability
by Mark Webb-Johnson 06 Sep '12

06 Sep '12

Dear OVMS Developers 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: You send an eMail to info(a)openvehicles.com letting us know your openvehicles.com user id, and how many modules you would like to order. We will be putting those order requests into a first-come-first-served list. Some users have already pre-ordered, and we'll honor their positions in the list (but they still need to eMail us to let us know they still want them). Early next week we will send out invitation codes and instructions. The first modules will ship out mid next week. In about a month'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

1 0

OVMS v2 Base Hardware
by Mark Webb-Johnson 05 Sep '12

05 Sep '12

The first batch of v2 base hardware is in my hands, and in my car :-) We QCed the first 20 modules last night, and all seems ok. Remaining tasks are just to confirm no issues in real cars, and double-check the advanced functions (GPS, switch, 12V ADC). 24 hours and we should be good to go. Attached are some images. Tom: Is this enough for you firmware guide? Bennett: I'll eMail you separately about the manual. Regards, Mark

1 0

OVMS v2 basic hardware finalized
by Mark Webb-Johnson 01 Sep '12

01 Sep '12

It has been an incredible amount of work, but I'm really pleased with the final result. First batch is on the truck. After a quick QC, I'll stick them in some cars here for a couple of days, to ensure no problems, then good to go out. Regards, Mark

1 0

Apps
by Mark Webb-Johnson 29 Aug '12

29 Aug '12

We've decided to make some changes to the github repository for the Apps. To try to get more people involved, and to make it easier to get involved, we're splitting the main OVMS repository into three. The main repository will now handle just the car firmware and documentation. A new Open-Vehicle-Android repository will be made, and the apps/Android tree moved to there. A new Open-Vehicle-iOS repository will be made, and the apps/iOS tree moved to there. We'll then be trying to build up a group of developers with commit-access to the Android and iOS repositories, to try to take these apps forward. The car firmware group is already working well, so not much needs to be done there. In particular, the Android App has been stagnant for a while. I'm glad to report that Sonny has told me his big project is coming to fruition and he will have some time, starting in about a month, to help out with the Android project and get it back on track. Thanks, Sonny - most appreciated. We've had a few offers from Android developers as well, and hopefully a group can be formed there to take this forward. Sonny estimates that the Android App can be brought up to date and working on modern Android hardware within the October timeframe. For the iOS side, I'll continue to lead that, and try to build up a group to help out. In particular, we have some work to do on complete-charge-by-time functionality, that I'm hoping to get some help on. It would also be nice to have a settings system as nice as the Android one. I'm also hoping that the Android and iOS groups can work together on a more unified approach to the logic behind the apps. While there are differences between the platforms, the core logic and way things are done should be able to be unified more. The car firmware itself is pretty stable and feature complete now. The major work being done is on support for vehicles other than the Tesla Roadster. I'm hoping the upcoming v2 hardware will reinvigorate that. The repository split should happen either today or tomorrow, and I'll send out a short note when it is done. Regards, Mark.

1 1

1.2.9 going on 1.3.1
by Mark Webb-Johnson 29 Aug '12

29 Aug '12

I've just built the firmware labelled 1.2.9, as a pre-release candidate for 1.3.1. It contains all the major structural changes, as well as those that could impact reliability or have a big affect on the functionality of the system. I build all versions of the firmware to .hex files, for those who don't/can't build from source, and everything is in github already. Here is the changelog since 1.2.7: 2012-08-28 1.2.9 Preliminary firmware 1.2.9 1.2.9 - an (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 As you can see, we've still got two bugs outstanding. These are both minor edge cases that shouldn't affect the core operation and most importantly shouldn't affect the normal operation of the system - unlike the changes 1.2.7->1.2.9 which are major in places and might impact the system. The reason for this build is to get it in some cars to make sure everything still operates ok. The major changes that might impact things are: Changes to the modem control logic, to introduce longer delays, retries and some new 'settle' states to try to improve the recoverability when the module/car is in areas of poor cellular connectivity. This will take a long time to tets in real cars. What we're hoping to fix here is the situation where a car loses GSM lock in poor connectivity areas, but can't recover lock when it moves back into a good cellular coverage area. Introduction of a linear backoff algorithm to server connections. This is to address a reported issue where the server is down/unreachable and the module repeatedly tries to connect, driving up cellular costs. The number of bytes for each connection is minimal (80 bytes or so), but in cases where the mobile provider either charges for these bytes (most don't seem to), or horribly rounds them up (we've seen evidence of mobile providers rounding connections up to 100KB or 1MB!), the new algorithm should minimise the impact. This also helps in cases where the vehicle ID or server password doesn't agree with the config at the server, or the incorrect server IP address has been entered. This has been quite thoroughly tested on the bench. Change to the notification system, to be more expandable to new notification types, include SMS notifications for trunk opening in valet mode, and most importantly change from using charge sub-state to the main charge state when deciding whether to SMS/Push notify when charging is stopped. The new logic is that SMS/Push notification should occur whenever a charge is stopped (either inside the car or outside), except for two cases: (a) the car itself stops the charge because it determines the charge completed normally (charge done state), and (b) within 30 seconds after an authorised App/SMS requests the charge be stopped. This has been minimally tested, and I need the most help with testing this. Support for v2 hardware. I'll handle the testing for this, as I'm the only one with v2 hardware in hand at the moment ;-) It has been tested on the bench and seems fine. I don't expect any issues in real cars, but we'll know within the next week or so. The final 1.3.1 should be released around the upcoming weekend. The v2 hardware is arriving this week, and we need the firmware locked down ready for that. I would really appreciate it if some of you have time and can test this out in your cars, to give us some confidence that these major changes don't impact the reliability or functionality of the upcoming 1.3.1. Let me know here of any problems you find. Regards, Mark.

1 0