Mark - those sound like cool features. When I log drives manually, I also record the trip meter energy use, efficiency and drive time numbers. That lets me compare energy from the wall to energy from the battery pack. For charge logging, I log the energy use reported by the car and compare that to the energy use reported by the wall meter so I can see how accurate the car is. I would be great to be able to charge to a lower SOC, since 180 miles of range is just ridiculous for my daily driving. On the other hand, doing that regularly might mess up brick balancing. There's a bunch of info on charge rate here: http://www.saxton.org/tom_saxton/2010/07/tesla-roadster-charging-rates.html I collected that data in early 2010, just before the firmware update that changed how the Roadster calculates battery capacity, which may have also changed charging profiles. All of my data was taken in moderate temperatures, so it needs to be augmented with data on how ambient temperature affects charge rate. Still, I've been using this data to calculate charge times and I do pretty well, both at setting the charge start time to get a range mode charge to end in a certain time window and also to know how long I should charge in the middle of a road trip to maximize charge rate. (For example, if you're at a 70A charging station and your next charge is a 40A outlet, it's a waste of time to keep charging past the point where current tapering is below 40A.) Tom on 4/5/12 4:45 AM, Mark Webb-Johnson wrote:
I'm now starting to think about the v1.3 firmware, which is intended to add the following:
Log charge history Log drive history Sophisticated control of charge time
We don't really have TOU metering in Hong Kong, so not much use for me, but part [3] would be fun nevertheless. Most charge control in EVs is pretty basic, and it might be interesting to see how sophisticated this can be made without complications.
I don't know if this is workable or not, so put my thoughts out into the open for discussion.
For charge time, the consensus seems to be that people want to enter the time to FINISH charge, vs the current time to START charge. To do that, we need an estimate of how long the charge will take. For that, we either need a sophisticated model or a collection of historical data we can lookup to find something approximate. Hence item [1] on my list.
Elon talked about the car learning about you. Where you park. Where you charge. etc. So, if always leave home at 7:00am to go to the office on Mondays through Fridays, perhaps the car can learn? Or, at least suggest based on what it has seen... Hence item [2] on my list.
For [1], we would store such things as temperatures, SOC start, SOC end, charge mode, charge current, charge voltage and duration. The can bus charge message seem to include this information.
For [2], we would store such things as date/time of drive, duration (time, distance, and elevation change), battery usage. We seem limited in this from what we have decoded on the can bus so far.
Regardless of the above, [1] and [2] would be useful information for any owner, anyway.
Privacy is an issue. Two problems - (a) protection of my charge/drive history, (b) the use of 'shared' charge history for [3]. My suggestion is to keep drive and charge history private. Perhaps it could just be stored as paranoid mode blobs. But, there should be an option to allow anonymised sharing of charge history for the use of [3]. My thinking is that if you share your data anonymously, then your lookup includes the pool of others anonymous charge history. if you choose not to share, then your lookup is only against your own charge history.
I did toy with the idea of using the server to control this. So, at 3am the server sends a command to the car to start the charge, etc. That would simplify the firmware in the car, but has a major problem of GPRS connectivity - if the cellular signal was lost the charge wouldn't start. Bad. So, I think it best to have the historical database in the server, the calculations in the App, and the settings downloaded to the car while it has cellular signal (after which it just follows them autonomously).
The Tesla Roadster currently offers you a choice of charge on plug-in, or start charge at a particular time. It also allows you to limit charge current and set charge mode. My thinking is to extend this by making it per day-of-the-week for a few defined locations, and to provide an override for the 'current' day/night. If the override is not set, and you are in one of the defined locations, then the system looks up the day of the week and controls charge based on what you have set. The UI for this is quite simple - presumably a screen with tabs/selector for day or the week, and then controls to set charge mode, current limit, and time to start/complete by. One developer also had the good idea that a charge SOC limit would be useful (e.g.; please stop charge when it gets to 70% / 220km ideal).
How do we handle night vs day charging? Is this only for overnight, or do we base it on when you plugin?
Is this workable? Useful?
Really interested in people's feedback on this.
Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev