Trip energy rate display seems to be too low

[KiwiME]

Yesterday I took a 290 km day trip, ... partly to try out my new gear reducer oil and double overhead magnetic drain plugs. As usual I made the effort to log OBD data. Everything looks normal except that I noticed the trip energy rate display read 1.02 kWh/100 km less than what I actually measured using the BMS energy odometers CED and CEC. Those BMS registers are incremented by integrating the product of current and voltage over time, both exiting and entering the pack. They need to be accurate to determine what SoC to display on the fly.

My trip total net energy usage from the battery was 44.43 kWh.
The Accumulated info display read 14.3 kWh/100 km, or 14.3 x 290/100 = 41.47 kWh total.

Missing from the displayed info is 44.43 - 41.47 = 2.96 kWh. The drive time was indicated as 4:13 hr:min or 4.22 hours. So, on average a load of 2960 Wh / 4.22 h = 701 watts was not accounted for while the car was in Run mode.

If I consider worst-case error margins the display could mean 14.39 x 290/100 = 41.73 and my logs 44.33, a difference of 2.6 kWh or 616 watts. So, that's not the problem.

The power use display on the media centre (which is mislabeled as Energy Use) told me that the Electronics (the 12V system) was using about 200 watts and the Climate (AC) was using using roughly 250 watts, numbers we probably all see. (As an aside, I'd be impressed if the car can run all it's essential systems on a mere 200 watts.) So, it could be that the Accumulated info ignores those overheads, and perhaps additionally fixed power draws may be underreported.

I'm wondering if the trip display does not account for anything other than the inverter and the motor? Or, is it simply not very accurate?

This is not the first time I've noticed this but it is the first time I've paid attention to it.

 

[herode10]

Yesterday I took a 290 km day trip, ... partly to try out my new gear reducer oil and double overhead magnetic drain plugs. As usual I made the effort to log OBD data. Everything looks normal except that I noticed the trip energy rate display read 1.02 kWh/100 km less than what I actually measured using the BMS energy odometers CED and CEC. Those BMS registers are incremented by integrating the product of current and voltage over time, both exiting and entering the pack. They need to be accurate to determine what SoC to display on the fly.

My trip total net energy usage from the battery was 44.43 kWh.
The Accumulated info display read 14.3 kWh/100 km, or 14.3 x 290/100 = 41.47 kWh total.

Missing from the displayed info is 44.43 - 41.47 = 2.96 kWh. The drive time was indicated as 4:13 hr:min or 4.22 hours. So, on average a load of 2960 Wh / 4.22 h = 701 watts was not accounted for while the car was in Run mode.

If I consider worst-case error margins the display could mean 14.39 x 290/100 = 41.73 and my logs 44.33, a difference of 2.6 kWh or 616 watts. So, that's not the problem.

The power use display on the media centre (which is mislabeled as Energy Use) told me that the Electronics (the 12V system) was using about 200 watts and the Climate (AC) was using using roughly 250 watts, numbers we probably all see. (As an aside, I'd be impressed if the car can run all it's essential systems on a mere 200 watts.) So, it could be that the Accumulated info ignores those overheads, and perhaps additionally fixed power draws may be underreported.

I'm wondering if the trip display does not account for anything other than the inverter and the motor? Or, is it simply not very accurate?

This is not the first time I've noticed this but it is the first time I've paid attention to it.

View attachment 14509

I observed the same thing. I use a micro-controller to read the net energy used for a trip. Based on that, I calculate an estimated remaining range. But same as you, my calculated kWh are always higher than the instrument cluster display. My recording are for smaller trips to work. Still results are quite consistent. This morning the 45km to work, gave a display of 18.3 kWh/100km while the calculated value was 19.33 kWh/100km. CED= 9.3, CEC= 0.6 so net= 8.7 kWh. Displayed energy used gave me 8.23 kWh. So it is 0.47 kWh not accounted for, or 620 watts. I don't have numbers for longer trips but the values derived from CED and CEC are always greater then the cluster values.

 

[herode10]

If I look at the instantaneous kWh bar graph display in the instrumentation cluster, the energy rate level seems to be calculated based on the instantaneous power and speed. To verify this, I maintained a constant speed of 100 km/h and the observed power reading from my obd2 was about 20 kW. The bar graph indication was around 20 kWh/100km. Same test at 60 km/h gave me 9 kW and about 15 kWh/100km on the bar graph: By extrapolating the energy used for 100 km if speed was maintained and the power stayed constant as well, I get 15 kWh/100km. It is likely the kWh/100km in the accumulated info display is an average of these values. This could explain the difference between the accumulated info value and the value based on CED and CEC.

 

[KiwiME]

Fortunately I had logged battery amps and pack voltage along with the battery registers on my last trip and so attempted to integrate that over time so I could compare it to the net cumulative energy. Unfortunately I don't have the data off the "battery power" PID.

My data is logged at 5 second intervals and so I've assumed that each of the voltage and current values prevails as power over a 5 second interval.
I've multiplied amps x volts x 5/(3600 x 1000) to get kWh and then added that result to the result immediately prior so that it accumulates.

On the X-axis, the net cumulative energy from CEC and CED is worked out as CED - (0.978 x CEC) as I normally do to account for battery cycle losses from regen. All values are shifted to zero off the first recorded datapoint.

So, now I can plot integrated battery power accumulated on the Y-axis against net cumulative energy which removes any time dependency. I'm of course hoping that I have sufficient data (2630 data points) to average out the granularity 5-second error. I've added a linear trendline so I can get an idea of the slope. I'm not really sure why the line wriggles around in some places but overall there is a good linearity to this relationship.

I was really expecting the slope to be 1.00 but clearly it isn't. I have to wonder first if the volts and amps data are scaled correctly in the PIDs and what the current PID actually represents in the car. I had assumed that amps was taken from the same pack current shunt and volts from the same voltage measurement that counters use. I'd like to hear your thoughts on this and if it relates to what you've found? And of course if I've made any mistakes, let me know!

 

[herode10]

Very interesting. Your graph seems to corrolate with the values in your original post. Close to 40 kWh accumulated (41.73 displayed) compared to the 44 kWh from the register. I would say that a data point every 5 secs may account for the difference with the value from the Accumulated Info. For sure, it is likely that current and voltage must fluctuate a bit in the 5 secs interval, integrated result could be slightly different with more data points. As you suggested, current pid value may not be the total current coming out of the battery. Your method is more detailed than my simplistic description but I think corroborates where the Accumulated kWh/100km comes from.

 

[herode10]

I performed the same exercice you did using data from last week-end 100km trip. I obtained a lower slope than yours, wander if it is because outside temperature was around -20C and climate control must have been using a good 3kW during the trip. I'm surprise how linear is the curve eventhough my power values were fluctuating from negative to positive numbers as I was not very steady on the accelerator pedal. I'm puzzled if more data points per minute would have changed the slope. I will find data from last summer where outside temperature was close to 20C to see the difference.

 

[herode10]

Here's a graph from a 270km trip that I've done last summer with ambiant temp around 25C. Slope is much closer to 1 this time.

 

[herode10]

Since I'm using a micro-controller to read and record obd2 data, I will add a calculation to integrate all power data point received. I think I get new value at least once per second. This should give a more accurate energy accumulation than based on 5 secs data.

 

[KiwiME]

I also did another plot from a mid-winter trip where heat was on and the slope was 0.92 compared to the previous 0.90 summer trip where AC was on. But in both cases the average climate power draw was only around 0.4 kW due to our mild climate.

I did notice that the Battery Power PID is simply calculated from the product of the pack voltage and "battery" current PIDs so there's no need for me to add the power PID and collect more data.

While parked and in Run mode the Battery Power seems to indicate about 0.2-0.7 below the Electronics readout on the dash. Something's amiss but I'm not too concerned because in the end I can trust the coulomb and energy counters.

I think the 5-second sampling error won't be significant if the data numbers are in the thousands. Statistically the error should average to zero.

 

[herode10]

This morning, I checked the power usage in the media window compared with the obd2 power reading. They pretty much agree with each other, max deviation about 0.2. I think my low slope numbers are not related to climate/electronics power not being accounted for.

 

[KiwiME]

I've finally found a working PID for the Kona's odometer so that makes plotting vehicle efficiency data possible as a trip progresses.
So now I can plot cumulative Wh used by cumulative kms (the odometer). Here's one from a 34 km round trip today at 17°C.

To recap from above, there are two sources of net energy data drawn from the pack. The Coulomb Counters are well-understood via the schematic to be covering all energy entering and exiting the pack. These are certainly used by the BMS to determine displayed SoC on the fly.

The other source of data is to integrate data from the pack volts and "amps", but not only is the definition of the amps PIDs unknown but there may be some error due to assuming the resulting watts remains fixed over each 5 second logging (binning) interval, plus there is no easy way to allow for battery cycle efficiency in the regen component (when amps are negative).

So, the "+" marks are from the coulomb counters and I'd consider that to have the highest accuracy possible. The data represented by the line below that is from the integration of V x A and that usefulness is questionable as noted above. The numbers at the top of those two curves are the final outcome from each method. Contrast those numbers with what the dash trip display indicates is the trip average.

So, it seems if you want representative efficiency data for costing or range estimation you're not likely to get that off the dash reading. Once I include charging efficiency of around 75% at 230V/7A I'm looking at 200 Wh/km. My off-peak incremental billing rate is NZ$0.28/kWh so that's a running energy cost of NZ$0.056/km.


As a note, I'm going to start using Wh/km now instead of kWh/100km. Bjorn Nyland did a video on this subject recently and for once I agree with his reasoning.

On another note, before I found the odometer PID I tried integrating the GPS speed PID which uses the phone's GPS data to determine speed. It gave the trip length as 99.4% of the odometer's reading. GPS data of course is a bit sporadic one reading to the next but averages out to be very accurate. But it demonstrates that assuming each datapoint is valid over each entire 5 second logging interval is not a bad estimation given enough samples.

 

[herode10]

I updated my code in my microcontroller so battery pack current and voltage are now updated every 0.5 sec intervals. Using the same integration method you use along wth the odometer pid values, I get exactly the same kWh/100km as the one displayed in the dash.

What is the advantage of displaying w/km?

I notice that with higher power demand, the difference between the Cumulative Net Energy discharge and Cumulative Energy based on time integration increases. Last week-end, I drove 70km on the highway, very little regeneration (less than 3%), power demand remain quite stable during that trip and I finish with 24kWh/100km (cold and very windy). Energy based on time integration was 10% less than the cumulative net energy register. Similar trip in the past where power demand was much less gave less gap, around 4-5% for 17kWh/100km. An other observation I made, for trip with high regeneration % (like when I return from work with heavy traffic), the cumulative energy based on time integration wil be higher than cumulative net energy from pid registers. Not too sure why...

As you say, the value obtained from the Coulomb counter is the reliable one. I wonder which value the GOM is using. The dash kWh/100km is definitly not accurate.

 

[KiwiME]

... so battery pack current and voltage are now updated every 0.5 sec intervals. Using the same integration method you use along wth the odometer pid values, I get exactly the same kWh/100km as the one displayed in the dash.

I could always increase the sampling time in Torque Pro to test that idea.

... Another observation I made, for trip with high regeneration % (like when I return from work with heavy traffic), the cumulative energy based on time integration will be higher than cumulative net energy from pid registers. Not too sure why...

Are you adjusting negative current to allow for battery cycle efficiency? Not that it would make a lot of difference but I'd assume it's relatively easy to handle that in code.

The advantage of Wh/km is simply to avoid the decimal point, the original reason behind litres/100km assuming Bjorn was correct in saying that.

I'm wondering if I could make my own GoM by extrapolating the data collected from a start point to the remaining battery SoC or Ah. I've got a Lillygo TTGO T-display micro waiting for a project.

 

[herode10]

Are you adjusting negative current to allow for battery cycle efficiency? Not that it would make a lot of difference but I'd assume it's relatively easy to handle that in code.

I'm not applying any correction for the negative current. I know I should but I'm not doing it either with CEC. From analysing some data, I tend to believe that CED is not accounting for some lost as well due to voltage drop during high current demand. In winter where my average energy consumption is 25kWh/100km, I get 61kWh from the battery. I would have to apply at least 30% for cycle lost to bring it close to 64kWh. Same method in summer time where my average is around 14kWh, I obtain my full 64kWh.

The esp32 TTGO is the same micro-controller I am using.

 

[KiwiME]

... I notice that with higher power demand, the difference between the Cumulative Net Energy discharge and Cumulative Energy based on time integration increases....

Continuing with my quest to discover the basis of 000_Battery current and 000_Battery voltage while driving, looking closer at the data I see now what you are referring to. It's a puzzling observation, implying more power is drawn off the battery than is actually being accounted for by the coulomb counter registers. And on regen the opposite happens.


The area marked on the graph are two long grades at around 90-100 km/h, X-axis is time. The road (total length 146 km to 360m elevation) is a softer grade either side of these two hills. Regen efficiency is taken as 0.978 for CEC. Lowering that number doesn't help this lack of correlation, in fact it makes it worse.

 

[herode10]

The area marked on the graph are two long grades at around 90-100 km/h, X-axis is time. The road (total length 146 km to 360m elevation) is a softer grade either side of these two hills. Regen efficiency is taken as 0.978 for CEC. Lowering that number doesn't help this lack of correlation, in fact it makes it worse.

Could you show the CED, CEC and calculated power?

 

[KiwiME]

Here's a graph of those three items over half the 290 km trip. I omitted the second half because there is a discontinuity where I stopped for a few hours and have no real time data to fill in the gap.

If I adjust the fixed regen efficiency factor it only bring the curves somewhat closer when I reach about 1.1, an implausible value so it's not as simple as that.

If I add a small differential term to the CED - η*CEC values I can make the curves match closer on the uphill runs. It does look to me like an algorithm is applied that adds a term related to real-time power rate of change, a bit like the "D" term in a PID servo control loop.



Here's just coulombs CDC - CCC v.s integrated 000_Battery current for the entire 290 km.



Here's the same graph but focused only on the two hills on the first half of the trip. Red is integrated current.



Here's pack voltage for only those two hills. The blue line is 000_Battery voltage v.s. that calculated from Min and Max cell voltages times 98, represented as small bars. This comparison is more difficult to discern because the cells with the minimum voltage are far fewer (in my case) than ones with a higher voltage, so the actual pack voltage will be higher than the average of the two extremes. But it indicates to me that the 000_Battery voltage is not as obviously biased, if at all as is 000_Battery current.



So, I'm leaning towards 000_Battery current being processed through an algorithm or look-up table in preparation for subsequent digestion by the GOM and driving efficiency dash readouts. I have no idea why that's needed because the coulomb counter registers should accurately meter battery usage.

Perhaps it puts a conservative bias in the dash numbers in case the driver is "hammering it" to quote Bjorn Nyland? While driving up these hills the power is around 80 kW.

Certainly I would not be surprised if Hyundai did this to avoid unhappy customers and the bias needs to be inserted at a point in the real time data to be pertinent.

The other consideration is that I've found 000_Battery current appears to quite accurately represent DC charging current at 47 kW. So, even though the current value is relatively high it may not be affected because it's continuous rather than dynamic, or just that it's in charging mode.

 

[herode10]

Thanks for these graphes. Very interesting your Cumulative Coulomb and Integrated Current curves. I was expecting that the 2 curves would have been on top of each other. It demonstrates that the bias between the CED-CED curve and Energy from power integration curve comes from the 000_Battery current measurement.

I am puzzled how to trust the kWh/100km displayed in the dash as the value is clearly derived from the energy based on power integration over time and not CED-CEC. On a long trip, I would like to calculate my own GOM and using the power measurement will definitely not give an accurate estimate. I modify the code in my ESP32 for distance measurement to get an even more accurate kWh/100km calculation. Since the odometer PID has a resolution of only 1km, I used your idea to integrate speed to get distance. I use this value to interpolate between odometer increaments. With power integrated every 0.5 sec intervals and the high resolution odometer, my kWh/100km calculation matches exactly the readout in the dash. I observed difference upto 2 kWh/100km (mainly in winter) when I compare kWh/100km based on CED-CEC and the value displayed in the dash. In the winter, my range on highway is around 250km, this correspond to 5kWh gap. The CED-CED value clearly making more sense as it follows the SoC used.

I am doing a 1200km trip next week (Montreal to Virginia). I will used both kWh/100km calculation and see which one I can trust.

 

[KiwiME]

BTW, I've only just noticed that the integrated current data crosses back and forth over the CED-CEC data, depending apparently on the magnitude of the current.

But aside from that lapse of attention to detail from myself, a patent search very quickly uncovered much about this subject.

The basic real-time current measurement is modified (as we're observing) to more accurately reflect the real effect on SoC when integrated. It's hard to work through the lengthy legal descriptions but there seem to be numerous factors applied to correct the basic current measurement. It seems that calculating SoC on-the-fly is not nearly as simple as I had thought.

This one came up first and seems most pertinent, if not very readable.
https://patents.google.com/patent/US8589096B2

This one was listed as a reference in the above patent (among dozens of choices) and might offer a few more clues.
https://patents.google.com/patent/KR20210137763A

In summary, when I simplistically factor CEC to account for assumed battery cycle efficiency (0.978) the real-time current value is already doing that for us using their algorithms. So, when you mentioned that you're not correcting the negative real-time current values for losses, well, no need to, it's already done.