Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

OVMS Charge done eta experiences?

This site may earn commission on affiliate links.
Hi all,

I seem to be having inconsistent OVMS charge done prediction figures...
Currently, here's the reply to a STAT message:
Code:
21:54:25
Standard - Charging
228V/16A
Full: 265 mins
SOC: 33%
Ideal Range: 89 km
Est. Range: 64 km
ODO: 79,470.7 km
CAC: 137.81

and 10 minutes later:
Code:
22:05:44
Standard - Charging
229V/16A
Full: 262 mins
SOC: 34%
Ideal Range: 90 km
Est. Range: 66 km
ODO: 79,470.7 km
CAC: 137.81

10 minutes later, but full prediction has only decreased by 3 minutes. Did I misconfigure something, or is it the charge prediction algorithm in OVMS that might need some tinkering? Any ideas?
 
The algorithm continually adjusts its estimate, depending on what the car reports. I find it accurate to +/- 15 minutes or so, but the behaviour right at the end of the charge cycle can be very hard to predict. In your case, it seems that the car was charging slower than the algorithm predicted (hence the adjustment). Also note that the estimate is based on miles, which is not very granular (your car went from 89km to 90km, which is just 1 increment).

How long did that charge actually take? Was it close to 260 minutes?

P.S. Remember that Tesla themselves never released any such algorithm / predication feature for the Tesla Roadster, which indicates how hard it is.
 
For iOS, it might take a while as we need some other changes to that done first.

Just another 2 cents - less reliance on SMS via iOS would be greatly appreciated. It's a limitation of my data plan in the U.S. with AT&T, but it's a little annoying that it costs 5 cents to change an ACC setting via SMS. I don't mind paying for the data to change an ACC parameter, but the 5 cents/SMS messages can add up when I'm tweaking some settings or starting COOLDOWN modes.
 
While we're here - any volunteers willing to help with the iOS App would be most appreciated. It is all open source. Michael B is helping and doing some great work on the Android side of things, but I'm all alone on the iOS side of things :frown:
 
In some locations, mine is showing only 1/3 of the charge time it will really need. It's consistent for those locations. I use the standard 2.6.5 build for now, pickit is in the mail so I'll check if the Roadster build will solve this (minor) issue.
 
The algorithm continually adjusts its estimate, depending on what the car reports. I find it accurate to +/- 15 minutes or so, but the behaviour right at the end of the charge cycle can be very hard to predict. In your case, it seems that the car was charging slower than the algorithm predicted (hence the adjustment). Also note that the estimate is based on miles, which is not very granular (your car went from 89km to 90km, which is just 1 increment).

How long did that charge actually take? Was it close to 260 minutes?

P.S. Remember that Tesla themselves never released any such algorithm / predication feature for the Tesla Roadster, which indicates how hard it is.


The prediction is always about 33% of the real charge time. Maybe it helps if I log my charge progress by polling every 10 minutes with the web API and see what trend I can find there. Currently, I'm charging at 13A, while the car is at 57%, but it predicts to be done in 1.36 hours. It would be awesome if it were like that in reality, but when I look at this graph, it would take at least another 3 hours before I hit the 70%:
View attachment 75595
 
Last edited:
All right, to be more specific.

OVMS currently gives me:
220V/13A
Full: 1 hours, 18 minutes

http://www.idleloop.com/tesla/ctp.php Gives me:
Charging: from 183 to 309 ideal km at 220V/13A in 8° C weather in a Roadster with a standard mode capacity of 309 ideal km.
Estimated time: 8:31 (give or take 30 minutes or 10%)

So that's a significant difference. Could it be that the algorithm is different for the lower amperages?
 
All right, to be more specific.

OVMS currently gives me:
220V/13A
Full: 1 hours, 18 minutes

http://www.idleloop.com/tesla/ctp.php Gives me:
Charging: from 183 to 309 ideal km at 220V/13A in 8° C weather in a Roadster with a standard mode capacity of 309 ideal km.
Estimated time: 8:31 (give or take 30 minutes or 10%)

So that's a significant difference. Could it be that the algorithm is different for the lower amperages?

Chillout: If your car is connected to the tmc.openvehicles.com server, could you send me the date/time you got this estimate (in GMT, if possible) and your vehicle ID? I'll have a look in the logs.

One thing to check: what is the current limit you have set? Please make sure it is 13A, and not much higher.
 
That might be it... the limit is higher than the current amperage. Never thought of that! Although using the set limit might not be the best way to base the prediction on, might be better to use the current Amps instead.

My ID is NL0447, and that estimation was made at 11:12:08 GMT on 23/3/2015.
 
Last edited:
That might be it... the limit is higher than the current amperage. Never thought of that! Although using the set limit might not be the best way to base the prediction on, might be better to use the current Amps instead.

My ID is NL0447, and that estimation was made at 11:12:08 GMT on 23/3/2015.

Yep, seems your car is advertising a charge limit of 70A at that location, but is only currently (sic) drawing 13A.

Can you try to set it to 13A as a charge limit, and see what happens? What is the actual EVSE you have at that location?

The algorithm uses 'wAvail' - watts available from the wall - I guess as the actual current coming in varies over time.

I'll ask Tom to have a look at this, and comment.
 
The algorithm programmed into the OVMS firmware is the same as what's on my CTP web page, but the tricky bit is setting the parameters that go into the calculation.

Setting the parameters that go into the charge time predictor is complicated. For the amperage, there are four numbers to consider: the current charge current, the amp limit transmitted by the charging station, the charge limit set for the location by the Roadster, and the charge limit set by ACC for the location. Any combination, including all of them, may be invalid. The voltage is even worse; we only know the voltage when the car is actively charging. I did some experimenting when developing the algorithm, but had a difficult time knowing when I could trust a value.

What's in there now is pretty simple and isn't right as often as it could be. I'll work with Mark to see if we can make it better, hopefully in a way that's not horribly Roadster-specific so other vehicles can leverage it.

In the mean time, I recommend using the CTP command if STAT isn't giving you reliable results. If you send CTP to the device, it will take its best guess at the parameters, like STAT does. You can also manually specify the parameters, e.g., CTP 238V 32A
 
The algorithm programmed into the OVMS firmware is the same as what's on my CTP web page, but the tricky bit is setting the parameters that go into the calculation.

Setting the parameters that go into the charge time predictor is complicated. For the amperage, there are four numbers to consider: the current charge current, the amp limit transmitted by the charging station, the charge limit set for the location by the Roadster, and the charge limit set by ACC for the location. Any combination, including all of them, may be invalid. The voltage is even worse; we only know the voltage when the car is actively charging. I did some experimenting when developing the algorithm, but had a difficult time knowing when I could trust a value.

What's in there now is pretty simple and isn't right as often as it could be. I'll work with Mark to see if we can make it better, hopefully in a way that's not horribly Roadster-specific so other vehicles can leverage it.

In the mean time, I recommend using the CTP command if STAT isn't giving you reliable results. If you send CTP to the device, it will take its best guess at the parameters, like STAT does. You can also manually specify the parameters, e.g., CTP 238V 32A

Thanks for this explanation.
Just some ideas, from my statistics-study background:
- I see the voltage flucuates between 210 and about 240 most of the time. Using an average value for voltage, e.g. take the voltage for the last 10/60/whatever minutes, and you will know the min, max and avg values. Then you can predict something like: Estimated time done: in 10 hours (+12 minutes/ - 40 minutes).
- Predict using the current values, and not the set limits. Then the prediction would be right with the disclaimer: "given the current known charge variables, charging will be done in 10 hours". It would lead to a raw estimate under the present charging circumstances, and the prediction would change over time. Since the latest bèta version of the Android OVMS app now shows the charge prediction, the prediction will be updated every now and then. At least we could plot the estimated times done in a graph like this, and show a rough estimate. The blue values at the top are all predictions from the current session. The grey lines mark the boundaries: the car will be done somewhere in this area

graph.jpg



Just some ideas ;)
 
We're totally in agreement that when the car is charging, the CTP should use the actual voltage and current. That will get fixed.

I'm surprised to hear that your voltage varies so much. I think that's pretty unusual, but it's still just a 15% variation. Computing a trailing average would require more memory than the OVMS has to spare. Perhaps more sophistication will be possible in the next major revision of the hardware.

Even without that voltage fluctuation, there's a tremendous amount of variance in the charge rate for vehicles charging under what appear to be similar circumstances. I explain some of the complexity in my blog about the algorithm.
 
Keep in mind that the car my slow down charging to cool the battery, and it will sometimes decrease the amperage based on temperature and other factors. I don't think that can be anticipated in the algorithm to calculate the completion time. It does seem to be accurate within +/- 15 minutes, which is good enough for me.