TimeHorse / pycarwings

Python library for interacting with the Nissan CARWINGS telematics service.
4 stars 0 forks source link

Find a way to get the true SOC number #3

Open TimeHorse opened 12 years ago

TimeHorse commented 12 years ago

Currently the RESTful response does not appear to provide the current percent SOC only the current bar count. Need to investigate how to get the true SOC. It could be better estimated from the Time to Charge (not L2) but this would be a kludge and the web interface can do it so surely the RESTful interface should.

haykinson commented 12 years ago

This one isn't easy, alas. I considered using the miles-to-empty estimate, which is a larger number and thus theoretically is more precise. However its accuracy is only as good as the value shown on the dashboard in the car, which we all know depends on far too many factors to be truly useful, especially when the battery is more than half full.

I think the time to charge is slightly more accurate than the number of bars, but it's still not down to the minute and changes in 30- (or 60-?) minute increments.

TimeHorse commented 12 years ago

I agree. I'm thinking like my post in the MNL forum CARWINGS API thread that the best approach is to use the 21-segment (AFAICT) Trickle Charge number. Then at least we get units of 5% or so each. But even better, I'm considering a fuzzy evaluation that judges the Trickle time as a region from (x-1)/42 to (x+1)/42 and the bars the fuzzy region (y-1)/24 to (y+1)/24. Add the Normal time's fraction and we probably could tweak accuracy even higher and by using all 3 we avoid the plugged in situation where trickle may not be reported.

TimeHorse commented 12 years ago

Ilya,

I've got some preliminary data for my commute this morning. Unfortunately my script konked out after about 10 minutes (I was pinging the car about every 90 seconds) so I only have a few samples and I was set to charge to 80% (weekend rate for me) and came from 100% (daily) so no values for time to complete. But the thing about the time scenarios being in seconds has an interesting implication: 1) we know these numbers take ECO mode into account since I'm sure within minutes of me leaving I switched over to that and my power went down about 40W. The thing is, when 100% capacity we know the battery is 24kWh and the time is given for both AC and No AC. So we can compute the power the car is estimated we use by simply dividing the energy (24kWh * 3600s/h) by the time estimate. Here I get about 545 W for no AC and 634 W for with AC. In fact, these are both rational values, with specific values of 6/11 kW for no AC and 27/44 kW for with AC with a 3/44 kW difference between them. Now, since I'm guessing it doesn't take actual cabin or external temperature into account it probably assumes a fixed energy of 3/44 kW or about 68 W for the AC but we know the AC can get up to 5kW so this assumption may be off since it differs by a factor of 10 from max.

Now, that's for the top of the commute, at 100%. When I start driving of course my minutes range goes down and the seconds of range jumps too. Clearly this is mainly due to the ECO mode and also there is a smaller difference between AC and no AC which is typical of ECO. But it's hard to get this right once the battery starts draining since the "fixed Energy" of the battery is no longer fixed. To compensate, I should take those power estimates and the difference between samples (in seconds) and multiple to get the amount of battery used. If I do that, maybe the numbers will more closely match and we may be on to a very viable SOC. Still no way to turn the charger off other than walking up to the car but it's something. I'll keep you posted. Let me know if you'd like an invite to my GSpread.

TimeHorse commented 12 years ago

D'oh! Meters, not seconds. Had my whole concept of how Range was calculated wrong. So if it's meters the physics gets a bit more complicated but interesting...

TimeHorse commented 12 years ago

Put another way, range is generally a based on velocity by the relation P/v = E/R where P is the Power output, E is the Energy available, v is the Velocity (speed) and R is the estimated Range. But in truth this is more like P(v)/v where P(v) is a third-order (cubic) equation. In other words, P(v)/v = k1_v__2 + k2_v + k3 + k4/v, where k1 is basically determined by Drag, k2 is really just 1/2m(v22-v22)/v, essentially the change in Kenetic Energy with momentum (speed), k2 is based on the rolling resistance of the tires and any climbing or descending of a slope and k4 is essentially the accessories like headlights, radio, etc. that don't actually depend on speed.

Of course, all that is (hopefully) beyond the calculation the LEAF is using. I guess it's based on the reading of mi/kWh actually though I don't yet see exactly how except in so far as I average 4.4mi/kWh at the moment...