August 2012 - OvmsDev - Open Vehicles

Android code for OVMS
by Mark Webb-Johnson 13 Dec '12

13 Dec '12

It appears that we're in a mess with the Android code base. The Android project Sonny had worked on containing updates to the OVMS Android App has been accidentally deleted, and the latest updates to the code lost. The NAS backup arrangement that Sonny had in place has also failed, and there is no backup. Sonny apologizes, and has tried hard to recover the files, but cannot. He is also still tied up with work commitments, and can't help much for the next month or two. We still have the code base in github, but that is quite old as it has not been updated with the improvements made in recent months. Primarily the settings screen, partial support for groups, and support for tablets. It is the tablet support that is causing problems with new high-res phones (as it is incorrectly identifying these as tablets) - I suspect that the settings code is the main thing we want to retain. I have tried to reverse-compile the Android code from the APK in the marketplace, and while the resulting code looks pretty good, the resources are not reverse-compilable, and look like they would take a significant amount of work to repair. My approach has been to take the github version, compile it, decompile it, and compare that with the decompiled version of the latest android market APK - applying patch duffs where necessary. The code looks good, and seems to only need minor tidy-ups. But, the resources are a mess. It seems the decompile process retains code symbols, but not resource symbols. The resource IDs and tags end up as numbers. I'm really not familiar with Android development, so am not sure how feasible that approach would be. It looked very easy and successful to start with. So, we are faced with a decision: 1. Someone more experienced with Android development comes up with a brilliant solution to finish off the reverse compilation of the APK to get back the latest version. I don't mind stepping in with the 'donkey work', but I really don't know where to start. What are those "R" class files - they look like they may be the key? 2. We start again with the code as it was a few months ago, and try to take it forward from there. 3. We investigate cross-platform development environments that could perhaps give us a more unified appearance across the the different platforms, as well as support for Windows Phone and others. What do people think? Mark

3 7

Alarm messages
by Jack West 16 Sep '12

16 Sep '12

Developers, Has anyone decoded the alarm message on the can bus of the Roadster? Any ideas where it might be hiding? Thanks, Jack

2 7

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

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

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

24 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 17 Aug '12

17 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