Explained by OnStar: kWh data spike when battery enhancement is done

[gieso]

I have been escalating an OnStar/MyVolt.com issue where a large kWh data spike was reported to OnStar coincident with when I had my battery enhancement done. Others have reported the same issue.

Today, I received a phone call from the OnStar R&D Project Manager responsible for this software explaining what happened and what they are doing to address the situation. Here is what I was told.

Typical Operation:

• There is a hardware sensor/counter in the Volt that tracks the total kWh drawn since the car was built.
• The most recent value of this counter is kept separately for use in later calculations.
• When a charging event completes, the most recent value is subtracted from the counter to determine the number of kWh drawn during that charge event.
• The value of the counter is then saved off as the new most recent value.

Problem description:

• The SW update required to add support for the new battery coolant level sensor also resets the sensor/counter in the Volt that tracks the kWh drawn by the car to zero.
• At the completion of the next charging event, the previous value (a large number representing the total kWh drawn since car was built) is subtracted from the counter value (zero since it has been reset).
• The value reported for this specific charge event is a large negative number.
• The MyVolt.com site does not expect a negative number for this value and simply discards the minus sign leaving a very large reading for this specific charge event.
• This large value is shown in efficiency graphs and is also included in the total kWh which is used to calculate kWh/100 mile figures and other efficiency figures.
• This issue will happen for everyone that has the battery enhancement and related SW update.

Proposed Solution:

• Back office software changes on the MyVolt.com site will be made to address the issue where negative values for kWh drawn are reported.
• If a negative value is seen for kWh drawn during a charge event, that event will be disregarded and the data not reported on MyVolt.com and not used in calculating kWh/100 miles and other efficiency figures.
• When this new back office update is rolled out, the large data spike will no longer be reported and incorrect values listed for kWh/100 miles and other efficiency figures will be calculated correctly.

Proposed Timeline:

• The proposed solution is being reviewed now to insure the proposed fix is robust.
• The Project Manager believes that the fix will be implemented by the end of July and rolled out on the MyVolt.com website a couple of weeks after that.

I am encouraged that they believe that they have located the root cause of the issue and that there appears to be a reasonable explaination for the behavior seen. While it seems like a long time to implement the fix, I am glad that they are taking their time to insure that this problem is addressed properly and completely.

It seems like it would make sense to correct the Software Update to support the battery coolant sensor to not reset the kWh counter, but I have no information on if this will happen or not.

We shall see how this plays out when the new MyVolt.com software rolls out in August.

[ghostgs1]

Thanks for the update, all they told me was they knew there was a problem and were working on the fix. I feel a lot better with your information.

[Selling Volts At Sundance]

gieso- Very complete and to the point as always- Thank you for your very complete post-

Tom-

[DonC]

Great information. Thanks for passing this along.

[RScott]

Good work getting that information! As a programmer, I can tell you that definitely sounds plausible.

[tboult]

Thanks for the post. The fix needs to be to MyVolt.com.. not the car.. since any battery replacement (e.g. failed unit) will cause a reset.
n
Replacing negative by positive is just silly bad programing.

Hopefully they get they cannot just ignore the negative.. they need to update their base to be the new level that made it negative. (Imaging replacing it with a partially used battery.. not zero but still negative).

Hopefully the get the should also be testing for any crazy values.. if out of range ignore. I had days with moderately arge spikes (50kw) and I've never had my battery in. My lifetime has been -- for months.

Its reported no data in the past 3 weeks (since 6/10) even though voltstats show data.


Sigh.. guess we wait to see if they fix things by August..

[jbfalaska]

Volts were relatively trouble free until this disastrous recall agreement. If given the choice, I'd opt out of tearing my whole car apart to slide in a few metal plates. The car was safer before the recall fixes.

[AySz88]

That explanation jives well with my guess that the "spike" magnitude is the number of kWh hours that have went into the battery to that point. Not too surprising.

Hopefully they still have the original data (with the sign included), or else they'll have to use some sort of heuristic (though I guess such a heuristic would be fairly easy in this case).

[RScott]

The fix needs to be to MyVolt.com.. not the car.. since any battery replacement (e.g. failed unit) will cause a reset.

I'd call it a bug with the software update on the car. If Chevrolet was the only one with access to the numbers in the car, they can do whatever they want. But where Chevrolet has given OnStar (and therefore the world, really) access to the data in the car, they need to make sure they do not change data incorrectly. If OnStar was told "This variable is the number of kWh downloaded since the car was built", with no mention of resets, it is a bug on the Chevrolet side. FWIW, the Volt has a variable "the number of minutes that have passed since the car was built"; I'll have to check to see if that gets reset after the update.

Of course, regardless of how it is documented, OnStar needs to fix their code!

Replacing negative by positive is just silly bad programing.

Close. Bad programming, yes. But silly implies that they meant to do that, something like this which would force the variable to be positive:

int x;
x=GetValue();
x=abs(x);

I'm guessing that they do not intentionally "discard the minus sign". That means that someone considered the possibility of getting a negative number, and decided in that case the best thing to do would be to discard the minus sign (which indeed would be silly!). I'm guessing that it happens more like this:

unsigned int x;
x=GetValue();

With 'x' an unsigned integer, if GetValue() tries to return a "negative" number, it will be have been converted to an unsigned integer, which would be positive.

Not that it really matter much, if they can simply change it to a signed integer, and discard any values below zero.

[tboult]

I'd call it a bug with the software update on the car. If Chevrolet was the only one with access to the numbers in the car, they can do whatever they want. But where Chevrolet has given OnStar (and therefore the world, really) access to the data in the car, they need to make sure they do not change data incorrectly. If OnStar was told "This variable is the number of kWh downloaded since the car was built", with no mention of resets, it is a bug on the Chevrolet side. FWIW, the Volt has a variable "the number of minutes that have passed since the car was built"; I'll have to check to see if that gets reset after the update.

It does not make sense for the variable to be KW since he car was built. I would expect this lives in the battery, and is KW since the battery was built. That is what I would want to know, since I do expect to change batteries sometime in my car's life.

Close. Bad programming, yes. But silly implies that they meant to do that, something like this which would force the variable to be positive:

int x;
x=GetValue();
x=abs(x);

I'm guessing that they do not intentionally "discard the minus sign". That means that someone considered the possibility of getting a negative number, and decided in that case the best thing to do would be to discard the minus sign (which indeed would be silly!). I'm guessing that it happens more like this:

unsigned int x;
x=GetValue();

With 'x' an unsigned integer, if GetValue() tries to return a "negative" number, it will be have been converted to an unsigned integer, which would be positive.

Not that it really matter much, if they can simply change it to a signed integer, and discard any values below zero.

True they could have just said unsigned int x.. then the battery would have been really crazy since it the cast would make a small negative number a really really big positive number. .. How big where the spikes?

and I still think its silly.. its not just "getGal" the the code would have been something like
unsigned int Oldval = GetVal(); // get kw val from storage
unsigned int newval = ReadVal(); // get kw from car
unsigned int used = newval - oldval; // compute how much was used...

when you subtract two variables and store the result in an unsigned it produces a warning (at least in my compilers).