- OvmsDev - Open Vehicles

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

28 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

Estimating charge duration (complete charge by … time)
by Mark Webb-Johnson 23 Aug '12

23 Aug '12

In order to provide a feature 'complete charge by time', we need to be able to estimate how long the charge will take. Looking at anonymised historical logs from ovms, we have records for a few hundred completed charges, over a range of temperatures and current/voltage conditions. The ovms logs are not perfect, but they do cover a large variety of conditions. Paranoid mode cars are excluded from the results (or, perhaps better written as can't be included because we can't see the data). I have cleaned them to remove overtly wrong data (-1Amp charges, aborted charges, etc). What remains are the records for 360 charges. For privacy reasons, we've been dumping these logs after a couple of days, so I only have the last few days from TMC and then a several month batch from a few cars early on in the days of OVMS (from the www.openvehicles.com development server). I am going to make arrangements to keep an anonymised form of this (basically the charges.csv format) in future, even from TMC, in order to get as much historical data as possible. I'm guessing that the more data, the better and more accurate model we can build. I've attached to this eMail a csv containing the data, and a simple perl program I knocked up to display it in various ways. It would probably be better to do this in excel, but I haven't had time to do that yet. The fields in the charges.csv are: $key - A unique key for the charge record (assuming no-one starts a charge in the same microsecond :-) $mode - The charge mode $wmax - The maximum Watts (current x voltage) seen as used during the charge $s_tambient - The ambient temperature (celcius) at the start of the charge $s_tbattery - The battery (ESS) temperature (celcius) at the start of the charge $e_tambient - The ambient temperature (celcius) at the end of the charge $e_tbattery - The battery (ESS) temperature (celcius) at the end of the charge $s_soc - The SOC% (varies by mode) at the start of the charge $e_soc - The SOC% (varies by mode) at the end of the charge $soc = $e_soc-$s_soc - The increase in SOC% $s_kmi - The ideal kilometers at the start of the charge $e_kmi - The ideal kilometers at the end of the charge $kmi = $e_kmi - $s_kmi - The increase in ideal kilometers as a result of the charge $duration - The duration (in minutes) of the charge, as indicated by the car $kwh - The kWh put into the battery (ESS), for the charge, as indicated by the car eg; 20120220062307.716156,standard,5980,4,32,10,21,6,97,91,18,301,283,529,52 5.9kW charge, 4C ambient at start of charge, SOC 6% -> 97% (= +91% SOC), 18kmi -> 301kmi (= +283kmi), 529 minutes, 52kWh My chargetables.pl code tries to crunch this data in a few ways. Here is the output from the small set we have: NUMBER OF SAMPLES: kWh,Temp 0 1 2 3 4 5 6 7 8 9 10 11 13 14 16 17 TOTAL 0 0 0 5 0 0 0 0 2 0 1 0 0 0 0 0 0 8 10 0 0 12 5 0 5 0 2 0 1 0 0 0 0 0 0 25 15 2 0 24 7 6 14 1 6 0 0 0 1 0 0 0 0 61 20 4 4 23 12 4 12 2 7 2 1 3 3 1 0 0 0 78 25 3 5 27 6 1 16 5 7 0 3 12 2 1 0 0 0 88 30 2 2 6 4 2 5 1 4 1 6 1 0 1 1 0 0 36 35 0 2 1 1 0 5 1 3 0 21 7 0 2 0 5 0 48 40 0 0 1 1 0 1 0 1 2 4 1 0 0 0 4 1 16 KM(IDEAL)/MINUTE: kWh,Temp 0 1 2 3 4 5 6 7 8 9 10 11 13 14 16 17 0 ----- ----- 0.19 ----- ----- ----- ----- 0.71 ----- 0.45 ----- ----- ----- ----- ----- ----- 10 ----- ----- 0.20 0.32 ----- 0.49 ----- 0.63 ----- 0.78 ----- ----- ----- ----- ----- ----- 15 0.33 ----- 0.18 0.26 0.40 0.60 0.67 0.54 ----- ----- ----- 0.39 ----- ----- ----- ----- 20 0.18 0.11 0.20 0.25 0.44 0.48 0.37 0.63 0.51 0.91 0.78 0.55 0.86 ----- ----- ----- 25 0.12 0.06 0.18 0.29 0.67 0.46 0.52 0.51 ----- 0.68 0.82 0.82 0.99 ----- ----- ----- 30 2.84 0.04 0.20 0.23 0.42 0.51 0.57 0.60 0.56 0.75 0.88 ----- 1.06 1.01 ----- ----- 35 ----- 0.08 0.20 0.19 ----- 0.45 0.28 0.41 ----- 0.78 0.79 ----- 1.11 ----- 0.69 ----- 40 ----- ----- 0.19 0.27 ----- 0.39 ----- 0.59 0.58 0.83 0.62 ----- ----- ----- 1.07 0.37 EFFICIENCY: kWh,Temp 0 1 2 3 4 5 6 7 8 9 10 11 13 14 16 17 0 ----- ----- 74.6 ----- ----- ----- ----- 103.9 ----- 91.5 ----- ----- ----- ----- ----- ----- 10 ----- ----- 78.1 81.9 ----- 90.4 ----- 80.8 ----- 97.2 ----- ----- ----- ----- ----- ----- 15 ----- ----- 70.3 78.7 81.5 95.4 ----- 90.0 ----- ----- ----- 66.2 ----- ----- ----- ----- 20 106.0 79.5 76.7 84.5 ----- 93.1 68.9 91.1 79.5 98.4 95.0 87.3 98.4 ----- ----- ----- 25 0.0 37.5 71.1 86.2 ----- 87.2 72.9 90.4 ----- 80.3 89.2 74.5 90.4 ----- ----- ----- 30 340.7 26.5 79.3 85.3 87.7 87.0 74.0 87.4 79.5 81.7 94.6 ----- 96.4 89.3 ----- ----- 35 ----- 50.4 68.6 69.6 ----- 87.2 71.5 84.1 ----- 89.5 85.0 ----- 94.6 ----- 90.4 ----- 40 ----- ----- 68.4 79.5 ----- 74.8 ----- 89.5 88.3 91.1 53.0 ----- ----- ----- 96.0 86.7 It produces three tables. The axes on all are the same - kW along the top, and battery temperature down the side. The idea is to extract the charge records and put them in the matching bucket based on the rounded-down kW for maximum charge wattage seen, and rounded-down 5Celcius for battery temperature at the start of the charge. The first table (NUMBER OF SAMPLES) just shows the number of charge records seen for each bucket. The second table (KM(IDEAL)/MINUTE) shows how many ideal kilometers were added, an average, for each bucket. The third table (EFFICIENCY) tries to calculate an efficiency by assuming a 53kWh battery (ESS) would be 100% SOC, and then looking at the change in SOC% over the charge to calculate how much was put into the battery (ESS), and comparing that to what the car says was taken from the wall (to the nearest kWh). The numbers are all over the place in some areas (e.g.; 30C, 0..1kW, where there are only 2 samples). The hypothesis is that charging efficiency depends primarily on battery/ambient temperature and kW available at the wall. If we can store such a small table in the OVMS module in the car, when OVMS needs to complete a charge by say 5am, it can plug in the current temperature and available current/voltage and get out a charging efficiency (perhaps how many minutes for each extra 1% of SOC). Then, knowing that it needs 100-currentSOC% to charge, it can work out how many minutes that would be, add on say 1/2 hour for safety, and start the charge at the appropriate time. Neat, and no server connection required. Thoughts? Anyone good at number crunching to play with this? Regards, Mark.

2 1

Charging Stopped vs Done
by Mark Webb-Johnson 16 Aug '12

16 Aug '12

https://github.com/markwj/Open-Vehicle-Monitoring-System/issues/67 The car has two charging complete states (charging stopped and charging done) and a bunch of sub-states. So far, we've been trying to use the sub-states to differentiate between the charging completing normally or being stopped by the user in the car (or from the apps) vs the charging being aborted early from a source external to the car. The idea is that if you pop the breaker, you get an alert, but if you stop the charge from within the car or from the App, you don't. The problem is, as Bennett points out, that there are some reasons internal to the car that should really be alerted (but aren't). A good example is 'extension cord detected'. The car reports that on the bus as state charging stopped sub-state that it was stopped from inside the car (which is true - the car detected the charging cord and stopped the charge) - which is not what we want. The suggestion is to change to a simpler logic. If the car reports charge state 'charging done' (ie; charge went to completion and finished) then do nothing, but if charge state is 'charging stopped' (ie; something, whatever, stopped the charge before it reached completion) then alert (via SMS/IP PUSH). The difference will be that we would then alert if you stopped the charge from within the car of from the iPhone App, but would also catch more wierd events like 'extension cord detected'. Personally, I think this is a safer solution to the issue. We're going to catch more events this way, the logic is much simpler. The downside is that if you stop the charge from the App/Car you also get an alert. Thoughts? Mark.

3 3

1.3.1
by Mark Webb-Johnson 15 Aug '12

15 Aug '12

Guys, I'm back on the firmware (after a break doing v2 basic hardware and summer holidays away from my roadster - driving a horrible borrowed Honda Jazz - not fun). I've just committed a bunch of changes to github on the way towards 1.3.1 firmware. The purpose of this next firmware version is to address a couple of niggly bugs, try to improve reliability of the GPRS and GSM connections (including adding linear-backoff timers for certain states like server unreachable and vehicleid/password incorrect), add support for timed charge control, and add support for the new v2 base hardware. I hope to have the code for this done within the next few days (about 75% of it got committed tonight), aiming for a release (after testing) around the end of this month. The v2 base hardware is done and with the factory. I'm doing a first test run of 20 modules (pretty much all of which have been reserved), followed by a second run of 100. I'm really sorry this has taken so long, but there were some issues with getting the prototypes working (our end as well as the factory / board fabricator). It is looking good now, and I'm expecting to receive the first batch within the next 10 days. The modules themselves are looking really good, and the cable arrangement is very flexible and reliable. As the new v2 base hardware processor has more flash memory, and some other functions (such as A/D converter for reading +12V voltage level), I've decided to split the firmware as a compile time build environment variable. This means we can build both sets of firmware from the same sources, but take advantage of v2 hardware features where available. The v2 hardware features are really for cars other than the Tesla Roadster, so no need for Roadster users to upgrade, and we'll continue to support both versions. If there are any ideas for 'little' things to go in 1.3.1, please let me know. It would be nice to try to capture the CAN bus message for alarm sounding, but I'm not sure if I'll have time to do it. I'll try. If anyone else has time, let me know. I think all we need is to be able to pickup that message and relay it on as an SMS/IP PUSH alert. Regards, Mark.

2 2

OVMS v2 Simple Hardware
by Mark Webb-Johnson 23 Jul '12

23 Jul '12

Guys, Here are the latest pics. Very neat, and getting close. This was supposed to be the final prototype, but some problems found: 1. Diag port can't tx while pic on. This is caused by the new voltage divider arrangement, and we're trying to add a diode to get it working. 2. 12v ADC measuring circuit doesn't work. Design issue, now ok. 3. GSM/GPRS switch stuck ON. Board design fault, now ok. Other than that, it works perfectly. Can bus is fine, LEDs are the same brightness and easy to read. Transistor circuit for async comms pic->sitcom works great (thanks William). Cable arrangement is fantastic. So, I've got a final prototype board coming in the next week or so. I'll run that in my car for 1 week, and if no issues are found will then give production go ahead. Regards, Mark Color samples: I've chosen C-65, but seriously considered C-15 or C-75. DIAG port and LEDs. Car connector, gsm and gps antennas. Compare vs v1. Under 1/2 size, overall. Board slides out. Cable and size comparison.

4 4

OVMS basic v2
by Mark Webb-Johnson 08 Jul '12

08 Jul '12

We're getting there... Here's the latest sample, with SIM card carrier (about credit card size) for comparison. Pretty final, apart from (a) 'oxidisation process' to be used to give it black color, and (b) laser etched lettering. The design for PCB is also done, with revisions from last week. The two holes are the LEDs for status and error. Regards, Mark

2 1

MAX942
by Mark Webb-Johnson 06 Jul '12

06 Jul '12

For the hardware guys - Michael Stegen, Brian, William - anyone :-) On the v1 board, we have: The MAX942 chip is used for the SIMCOM TX -> PIC RX line, to convert the 3.3v SIMCOM async communication to 5v TTL for the PIC. My understanding of this is that the SIMCOM chip, while expecting 3.3v can accept 5v (TX from PIC, RX to SIMCOM) - and a diode is used on the circuit for this. But on the line from the SIMCOM to the PIC (TX from SIMCOM, RX to PIC), the SIMCOM only gives out 3.3v, but the PIC requires 5v TTL levels. One half of the MAX942 is used for that, and the other half is unused. I've seen some reference designs for such conversion, but all required both 5v and 3.3v power to handle it. In the original design (two separate boards), we had no 3.3v power on the PIC board, so could only do it the MAX942 way. Now, in the new v2 design, we have both 5v and 3.3v power lines on the same board, so perhaps we can do it a simpler way. The MAX942 chip is (relatively) expensive. The China guys are asking what we want to do with this, and suggesting using resistors to handle the 3.3v->5v conversion now. I guess some sort of voltage divider. Has anyone done anything similar? Regards, Mark.

4 11

v2 Basic Hardware
by Mark Webb-Johnson 04 Jul '12

04 Jul '12

I thought you might be interested in seeing some early pictures of the prototypes for the vs basic hardware we've been working on with the China team. Some notes: The design uses a metal rectangular "tube" style case, customised for us and cut to the width of our board. The case ends up about 7cm x 6cm. Labelled end-plates will go on, with cut-outs for the various connectors. The original design called for this to be black in colour, and we're still deciding on that (as the silver doesn't look bad and will be mostly covered with a black sticker anyway). Opening it involves removing the 4 screws on one side and sliding it out. On one side we have the CAN (and power) DB9, GSM and GPS antennas. On the other side we have the DIAG DB9 and expansion bus connectors. Holes for the LEDs are on the bottom of the case, and the LEDs themselves are on the bottom of the board, so that they are as close to the holes as possible. There are zero internal cables, and only one circuit board containing the PIC controller and SIM908 modem - connection to the car is via the main CAN DB9, using custom cables. We have tried to follow ODBII standard pinouts for that connector. For Tesla Roadster, we can use a custom 4 wire connector (Tesla DIAG port connector on one end, DB9 female on the other). For ODBII cars, a similar arrangement can be made. The SIM908 modem chip supports GPS for those cars that don't have it. Still early days, but the design looks workable and should be much easier to assemble and QC than the v1 modules. Rock solid and (probably) bullet proof. It should also have good support for cars other than the Tesla Roadster. Regards, Mark. P.S. I'm also working on a more advanced hardware solution, as a personal project, that may end up being offered. Just experimenting at the moment. William is also working on some solutions for this based on *bone hardware and shields. These are much longer term, and we'll send out more details when we have some progress.

3 4

Fwd: OVMS at Laguna Seca on Sunday
by Mark Webb-Johnson 28 Jun '12

28 Jun '12

Saw this on TMC as well. I love the idea, and really hope you get some takers. Regards, Mark. Begin forwarded message: > From: Bennett Leeds > Subject: OVMS at Laguna Seca on Sunday > Using OVMS Social Group "REFUEL" > If you're running at Laguna Seca on Sunday and have OVMS, why not add the Social Group REFUEL? That way people can watch us race virtually, either via theOVMS app, or by going to maps.google.com and entering the following into the search box: http://tmc.openvehicles.com:6868/group?id=REFUEL > > I'll also be running under the REFUEL42 Social Group, in case you want to see how I'm doing (I'm car #42). I'll also have GPS streaming on, so you should get reasonable updates. > > - Bennett

1 0

Volt/Ampera CAN Logs
by R. Scott Perry 28 Jun '12

28 Jun '12

Hi everyone, I'm the RScott from gm-volt.com, and I wrote the page at evtools.info about the Volt and OBD2 data (which I haven't updated in quite some time). I've read the recent posts to the list about the Volt, and thought I would provide information here in response. First, if it would be helpful, I have written a program for Windows to record data from an OBD2 scanner. It is designed to work with scanners that use the ELM327 chip (or are compatible). It saves the timestamp, and saves the data in the format "11:48:45.829: 206 639600". It is run from a command prompt, and not very user friendly. For the SOC, the "206 3 69 C3 00" capture indicates CAN ID 206, with 3 bytes of data. The SOC data only uses the first two bytes, so this would be 0x69C3, or 27075d. Dividing by 4,000 gets 6.769kWh in the battery, or about 42% of the total battery capacity, which should be 4 bars on the display. http://gm-volt.com/forum/showthread.php?5328-Volt-Diagnostic-Tool&p=91868#p… correlates the SOC number here with the bars displayed. The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII. So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc. The latitude/longitude conversion is almost the same as what you have for the Tesla, with two exceptions -- changing the 2048 to 1000, as noted, and the accounting for negative numbers is different. It seems that the number the Volt supplies is a 31-bit signed integer. The easiest way to handle that, I think, would be to add "latlon = latlon << 1;" before checking for <0, and then "latlon = latlon >> 1;" afterwards. Running the code you have with those two changes seems to work fine. The bad news is that I have checked all my log files (I have been logging almost all the time I have driven for about 8 months now), and the CAN ID 32A (latitude/longitude) has never shown all zeroes. If the GPS data is unobtainable, I believe the car reports the most recent reading. The GPS data comes from the OnStar system, so I am thinking it may only provide the data if the OnStar service has been activated, which could be a problem for owners outside of U.S/Canada. For charging, all I have found so far are some numbers that appear to show electricity flow to/from the battery. If they are positive, electricity is going to the battery; if negative, electricity is leaving the battery. But this will also be positive if the gas engine is on and charging the battery, as well as if the car is going downhill and the regenerative braking is being used. -Scott

5 22