SOC different between car and OBDII scanner report

[emmrecs]

Having finally resolved exactly why I could not see any results using Car Scanner Pro and OBDII dongle (I had selected the wrong profile in the app!!) I now see a strange anomalous difference between the car's own display and the data in the app.

Specifically, the car shows my State of Charge as 100% (it's just finished charging) but the app shows it as 95% or less. Anybody any idea why this difference?

I should perhaps add that battery state of health is shown as 98.4%, which it has been since its first service more than 12 months ago.

TIA.

 

[Rookery]

I don't really know but my guess is that the car shows the usable SOC 100% whilst the OBD shows the usable as 95% and the other 5% is the non usable buffer.

 

[MickeySw]

Specifically, the car shows my State of Charge as 100% (it's just finished charging) but the app shows it as 95% or less. Anybody any idea why this difference?

I’d say the app shows the SoC in relation to max usable capacity while the car compares it to current capacity (max * SoH)

The reason it doesn’t show as 98.4% is probably due to the trick most manufacturers use to hide initial degradation (in your case it probably started off around 104%)

 

[CanyonReveller]

If you have the long range, the maths would be 57.4/61.1= 94%
So with 100% on the car dash, the app should show roughly 94% as SoC. The app percentage will have no idea about the usable capacity/buffer set by the car. Instead, it will be based on the measured cell voltages.

 

[Coulomb]

This is common; the Battery Management Unit usually maintains two SoC values, the "real" one and the "display" one. The display one has 0-100% as the usable range (excluding buffers). The "real" one is needed for important calculations, including State of Health (SoH).

 

[MickeySw]

. The app percentage will have no idea about the usable capacity/buffer set by the car. Instead, it will be based on the measured cell voltages.

App developers usually just display the value of a certain CAN ID available on the OBD bus and don’t calculate it. As @Coulomb mentioned the car uses several different values.

The display for example cannot show more than a 100% but in reality the battery’s initial capacity is higher than. The car can only work with useful capacity. The buffer is due to a ‘no go zone’ at the top/bottom of the cell voltage to avoid fast degradation.

 

[CanyonReveller]

App developers usually just display the value of a certain CAN ID available on the OBD bus and don’t calculate it. As @Coulomb mentioned the car uses several different values.

Of course the car will be doing the calculations. However, it will be reporting the real world data that is not adjusted for a buffer, otherwise key diagnostic information would be lost. The point is that the app will not be able to adjust to factor in the buffer set by the car, as that data is not reported in the OBD data on the MG5.

 

[Alb]

The two figures align for me notwithstanding the fact there is rounding of the figure displayed on the car.

 

[MickeySw]

The two figures align for me notwithstanding the fact there is rounding of the figure displayed on the car.

What is your reported SoH?

 

[Alb]

100% at almost 3 years old

 

[Rookery]

97% at 2yrs 8 months.
Done by MG dealership.

 

[m4rmite]

100% at almost 3 years old

2 yrs and 10 months and mine is 100% according to car scanner
23500 miles.

 

[MickeySw]

Looks like if one’s SoH is 100%, SoC reported by the app matches the display on the dash, therefore the “57.4/61.1 theory” couldn’t be right.

@emmrecs does the app always show 5% lower or does it depend on SoC?

 

[MickeySw]

Of course the car will be doing the calculations. However, it will be reporting the real world data that is not adjusted for a buffer, otherwise key diagnostic information would be lost. The point is that the app will not be able to adjust to factor in the buffer set by the car, as that data is not reported in the OBD data on the MG5.

Not sure what you mean by “buffer” can you elaborate pls?

 

[Rookery]

The buffer is part of the battery that you can't use, this is to protect the battery so you can't overcharge it or run down to complete zero.

 

[MickeySw]

The buffer is part of the battery that you can't use, this is to protect the battery so you can't overcharge it or run down to complete zero

Of course the car will be doing the calculations. However, it will be reporting the real world data that is not adjusted for a buffer, otherwise key diagnostic information would be lost. The point is that the app will not be able to adjust to factor in the buffer set by the car, as that data is not reported in the OBD data on the MG5.

If this buffer is meant to protect the battery, won’t the car be prevented from using it in the first place? Then why would the real world data need to be adjusted and what key diagnostic information is lost otherwise?
The app gets its info via OBD from the car, what data is not reported?

Sorry, all very confusing…

 

[Coulomb]

If this buffer is meant to protect the battery, won’t the car be prevented from using it in the first place?

Yes.

Then why would the real world data need to be adjusted and what key diagnostic information is lost otherwise?

All the data on cell behaviour is based on using all of the battery, including the buffers. All that means is that the BMS maintains two SoC values, one to calculate what's really going on, and one to display to the driver. No diagnostic information is really missing.

The app gets its info via OBD from the car, what data is not reported?

I can't recall, but I'm 98% sure that both SoC values are available from the CAN bus, and therefore via OBD. Some apps might report the actual SoC as the "headline" value, and report the display SoC elsewhere in a smaller font. That's what typically triggers the confusion.

 

[lbaron]

Anyone know how to fix the output value in Torque to send to ABRP so it matches the dashboard figure? I want to send it to ABRP for route planning. Thanks

 

[MickeySw]

Anyone know how to fix the output value in Torque to send to ABRP so it matches the dashboard figure? I want to send it to ABRP for route planning. Thanks

Someone else had the same 5-7% difference in SoC reading, seems to be a setup issue:

A Better RoutePlanner (ABRP) and Torque Pro Step-by-Step

www.chevybolt.org

 

[lbaron]

Someone else had the same 5-7% difference in SoC reading, seems to be a setup issue:

A Better RoutePlanner (ABRP) and Torque Pro Step-by-Step

www.chevybolt.org

After considerable digging I think the reduced reading is a %age of the total battery (not the reduced amount of charge as indicated by 0-100% on the dashboard.

This image shows the output of SoC from Torque. I think embedded in there is possibly the dashboard SoC, or it needs further calculation based on the real battery availability. Will have to play.

Don't know how it hasn't come up earlier, ABRP with OBD just won't work as it is.