[Ovmsdev] Charge Control

[Tim Putnam]

Hi,

In response to your points:

1. Setting it based on finish time is what I'd be after, and couldn't you always build in a healthy safety margin so accuracy of only +/- 1 hour might be relatively easy, keeping it simple and getting the function out there, and then building accuracy in later releases.

2. For this to be any use it would have to be very good, but the only place I regularly charge is at home, and location doesn't necessarily mean you have the same charge requirements. Perhaps just a set of saved setups on the app end to choose from would be more useful, and a lot simpler?

3/4/5. It would be great to be able to pull all this data and compare to other cars without fiddling with files and usb sticks.

7. I agree that sounds the best way.

8. Personally I'm not interested in settings based on day of week. It would be nice to be able to specify ideal miles to charge to, and an option to say if it gets to a particular time and you're not fully charged whether to stop or carry on.

regards,
Tim


On 5 Apr 2012, at 12:45, 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 at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120405/9c3e0fe6/attachment.htm>