SkookumPete
Well-Known Member
That's not going to work. You have to open the .csv files as "raw", then copy and paste into your own .csv which is then loaded onto Torque. If the info in this thread is not enough, see the following:
.
Torque Pro on the Kona - overview and setup for interested owners
- Thread starter KiwiME
- Start date
- Replies 237
- Views 80K
That's not going to work. You have to open the .csv files as "raw", then copy and paste into your own .csv which is then loaded onto Torque. If the info in this thread is not enough, see the following:
.
hobbit
Well-Known Member
Since I'm not actually using TP at the moment, I don't feel sure about
trying to generate data in the exact form it wants. Every different system
is going to have minor differences -- the order of items, extra fields,
whether the bytes and math/equation is case-sensitive or not ... it's clear
that the OBDlink / scantool.net people have leeched a lot of ideas from
Torque and other interested communities, but they put their own twist on it.
They can read .csv files, for example, but not save them out ... they're
in a different order than Torque csvs. Parsing fields in the multi-packet
answers is similar; it feels like that's a de facto "industry standard"
since the early ELM327 days.
I'd be happier talking about parameters in generic terms, i.e. which ID
you send with, the mode and PID [whose total length varies], and where
in the answer the bytes of interest are. I've had to adapt all of tne Jeju
stuff from Torque format to the other format ... not hard if you understand
what the fields are. And NONE of this gets anywhere close to the passive
listening on an active bus that my old Scangauge does in the Prius -- if
we could do that, it would be *much* faster. But in the Kona we don't
get a live bus to listen to anyway, so everything here has to be query-based.
Smarter people than I have probably already tapped the power-control bus,
where all the interesting stuff happens, and are likely reverse-engineering
the crap out of what's flying by. Probably with an eye toward creatively
modifying some of it. The real asskicker here is that Hyundai and the rest
offer NO help in understanding it. Because "right to repair" hasn't grown
big enough teeth yet.
_H*
trying to generate data in the exact form it wants. Every different system
is going to have minor differences -- the order of items, extra fields,
whether the bytes and math/equation is case-sensitive or not ... it's clear
that the OBDlink / scantool.net people have leeched a lot of ideas from
Torque and other interested communities, but they put their own twist on it.
They can read .csv files, for example, but not save them out ... they're
in a different order than Torque csvs. Parsing fields in the multi-packet
answers is similar; it feels like that's a de facto "industry standard"
since the early ELM327 days.
I'd be happier talking about parameters in generic terms, i.e. which ID
you send with, the mode and PID [whose total length varies], and where
in the answer the bytes of interest are. I've had to adapt all of tne Jeju
stuff from Torque format to the other format ... not hard if you understand
what the fields are. And NONE of this gets anywhere close to the passive
listening on an active bus that my old Scangauge does in the Prius -- if
we could do that, it would be *much* faster. But in the Kona we don't
get a live bus to listen to anyway, so everything here has to be query-based.
Smarter people than I have probably already tapped the power-control bus,
where all the interesting stuff happens, and are likely reverse-engineering
the crap out of what's flying by. Probably with an eye toward creatively
modifying some of it. The real asskicker here is that Hyundai and the rest
offer NO help in understanding it. Because "right to repair" hasn't grown
big enough teeth yet.
_H*
Toolworker
Well-Known Member
Domenick has moved the 12V battery discussion to its own thread: Tracking the 12v Battery with OBD2.KiwiME said:
KiwiME
Well-Known Member
Here's a rundown on my take on CEC and CED. These are effectively odometers for energy going into and out of the traction battery as a whole, all 98 series packs of three cells in parallel. Passing current is measured precisely inside the battery using shunts. Current times the voltage, integrated over time, is energy and CEC and CED are incremented separately depending on the direction of the current. The usefulness of these numbers is first due to the fact that they are separately tabulated, second because they are cumulative over the life of the battery.
Over time, the values graphed would look like two diverging lines starting at zero when the registers were initialized at the factory. The first graph below is a mockup with straight lines to help us understand the theory; the lines are actually going to be wiggly in detail. Also recognise that when these registers were zeroed the battery would have some initial non-zero charge, let's call it SoCo.
The first outcome to note from this is that whenever the current SoC is the same as the initial SoCo, the battery's cumulative overall efficiency is simply the ratio of the current values of CED over CEC. (If the current SoC is not the same as the factory SoC, the CEC is higher or lower by that difference).
The important takeaway at this stage is that we have four numbers on hand so far. CEC and CED, the initial SoCo, plus the average battery efficiency to-date calculated from those first three values.
The actual logged values on the next graph below have been offset by a fixed number for each curve to allow a detailed view of the changes while alternately driving and charging over a period of about an hour. You can see that while driving there is more discharging going on to move the car than there is charging due to regen. When charging there is no movement of the CED value because the car is not moving. Note, while charging, power used to keep the systems running is drawn from the charger before it enters the battery. You can see clearly where the charge rate changes due to charging tiers, battery heater heater activity and/or other uses of incoming power while waiting.
You'll note that over a trip, from the change in these values you could calculate how much regen energy is recovered v.s. how much energy is spent.
Now onto the last item. The main purpose of these registers as best as I can determine is to calculate a stable current SoC, not affected by pack voltage that may vary under load. Apparently this technique is called "coulomb counting" and there are numerous studies on the subject if you care to google it.
As I mentioned above, when the current SoC is the same as SoCo, the cumulative battery efficiency is just CED over CEC. But, since battery efficiency could be assumed stable over the few last charge cycles, you can assume an efficiency based on past data and work back to get the current SoC even if it's not the same as the starting SoCo. For that you also need to know the battery capacity because both SoC values are a percent of that, resulting in kWh. CEC and CED are also expressed in kWh.
Battery losses occur for several reasons during charging and discharging. The SoC represents the stored energy in the middle of that process. If you add energy during charging you lose a tiny bit going in, the result increasing SoC representing slightly less than what you put in. However, you don't yet know what you lose discharging because you haven't done that yet and therefore the SoC cannot reflect that further loss.
For simplicity I've assumed that those losses are equally spread between charging and discharging. On my Kona I've worked that out to be 96% total, where the charging and discharging efficiencies will be each the square root of that total value.
The following formula and graph are a simplistic use of these numbers to determine current SoC. I say 'simplistic' because I'm sure the technology is much more complicated mathematically, but this gets close. So, CEC and CED are each modified by the square root of the total efficiency and the resulting difference is offset by the factory SoCo to get the current SoC. The constants assumed are noted below, SoCo, total battery capacity and overall efficiency.
Over the same driving/charging data as the graph above you can see that my estimated charge in green (SoC EST) emulates the displayed charge in red (SoC DIS) very well.
Please ignore the blue SoC (BMS) on the graph, that's outside the scope of what I'm covering in this post.
Over time, the values graphed would look like two diverging lines starting at zero when the registers were initialized at the factory. The first graph below is a mockup with straight lines to help us understand the theory; the lines are actually going to be wiggly in detail. Also recognise that when these registers were zeroed the battery would have some initial non-zero charge, let's call it SoCo.
The first outcome to note from this is that whenever the current SoC is the same as the initial SoCo, the battery's cumulative overall efficiency is simply the ratio of the current values of CED over CEC. (If the current SoC is not the same as the factory SoC, the CEC is higher or lower by that difference).
The important takeaway at this stage is that we have four numbers on hand so far. CEC and CED, the initial SoCo, plus the average battery efficiency to-date calculated from those first three values.
The actual logged values on the next graph below have been offset by a fixed number for each curve to allow a detailed view of the changes while alternately driving and charging over a period of about an hour. You can see that while driving there is more discharging going on to move the car than there is charging due to regen. When charging there is no movement of the CED value because the car is not moving. Note, while charging, power used to keep the systems running is drawn from the charger before it enters the battery. You can see clearly where the charge rate changes due to charging tiers, battery heater heater activity and/or other uses of incoming power while waiting.
You'll note that over a trip, from the change in these values you could calculate how much regen energy is recovered v.s. how much energy is spent.
Now onto the last item. The main purpose of these registers as best as I can determine is to calculate a stable current SoC, not affected by pack voltage that may vary under load. Apparently this technique is called "coulomb counting" and there are numerous studies on the subject if you care to google it.
As I mentioned above, when the current SoC is the same as SoCo, the cumulative battery efficiency is just CED over CEC. But, since battery efficiency could be assumed stable over the few last charge cycles, you can assume an efficiency based on past data and work back to get the current SoC even if it's not the same as the starting SoCo. For that you also need to know the battery capacity because both SoC values are a percent of that, resulting in kWh. CEC and CED are also expressed in kWh.
Battery losses occur for several reasons during charging and discharging. The SoC represents the stored energy in the middle of that process. If you add energy during charging you lose a tiny bit going in, the result increasing SoC representing slightly less than what you put in. However, you don't yet know what you lose discharging because you haven't done that yet and therefore the SoC cannot reflect that further loss.
For simplicity I've assumed that those losses are equally spread between charging and discharging. On my Kona I've worked that out to be 96% total, where the charging and discharging efficiencies will be each the square root of that total value.
The following formula and graph are a simplistic use of these numbers to determine current SoC. I say 'simplistic' because I'm sure the technology is much more complicated mathematically, but this gets close. So, CEC and CED are each modified by the square root of the total efficiency and the resulting difference is offset by the factory SoCo to get the current SoC. The constants assumed are noted below, SoCo, total battery capacity and overall efficiency.
Over the same driving/charging data as the graph above you can see that my estimated charge in green (SoC EST) emulates the displayed charge in red (SoC DIS) very well.
Please ignore the blue SoC (BMS) on the graph, that's outside the scope of what I'm covering in this post.
FloridaSun
Well-Known Member
When I go to github, I can find the files but I can't find the download button?? How do I download from there?
FloridaSun
Well-Known Member
figured it out. Got all the displays now.. now I need to understand what the values mean, especially those battery related..
FloridaSun
Well-Known Member
All my cells except for #31 have 3.88 volt and 31 has 3.86 volt. Is that a problem?
ericy
Well-Known Member
I wouldn't think so.
apu
Well-Known Member
Give it a full charge, they should all equalize, plus it will give you an opportunity to look at your top end buffer size. BMS should report 95-96% when your display reports 100%.
FloridaSun
Well-Known Member
Thx.. will try that.
I will charge to 100% on Thursday night as I'm leaving on a small road trip on Friday.. 210 miles to the closest level 3 charger at my destination. I could take a 15 mile longer route that has several Level 3 along the route, but I prefer the shortest route.
Right now, SOC (display is 74.5 and SOC/BMS shows 72.5).
Based on my calculation, the total buffer on the Kona should be 4.62% when new. So, 95.38% when the car is new..
Battery size is 67.1 kwh, available to owner, 64kw..
Last edited:
apu
Well-Known Member
That's about right, I get 1.5% difference at similar SOC.
apu
Well-Known Member
Yeah , I have seen that 67.1 kwh gross battery capacity number thrown around a couple of web sites, not sure if its an official number. I just know when my battery was brand spanking new torque pro reported the BMS reading as 95% when the display indicated 100%. I believe Kiwime indicated his is 96%, so there is probably a little variation. I hope that helps.
FloridaSun
Well-Known Member
I wonder if the 000_Battery_power value is the charge the car is receiving?
The display shows charging at 7.4kwh and battery power shows about -6.9kw
Would be a 7% loss. Not too much..
The display shows charging at 7.4kwh and battery power shows about -6.9kw
Would be a 7% loss. Not too much..
apu
Well-Known Member
Seems like a reasonable assumption.
FloridaSun
Well-Known Member
20 mv differential is not an issue,as a matter of fact that is pretty good; just keep your eye on it to ensure the equalization process is working as it should.
I believe the Kona pack has 3 parallel cells per unit of measurement so a defect in one will be hard to recognize until it drags down the voltage of the other two.
I wonder if the cells in question are in the "stacked" module below the rear seat where coolant circulation might be slightly less.
apu
Well-Known Member
I think you will likely have it all. I suspect you will have not much if any degradation at 22,000 miles. The Bolt has very similar LG packs to ours. This Bolt owner calculates a 5-8% degradation over 105,000 miles. https://www.torquenews.com/8861/chevy-bolt-ev-battery-health-after-100000-miles
FloridaSun
Well-Known Member
Last night, I charged to 80% and all cells ended up with 3.92 Volt, so the discrepancy on #31 was gone.
FloridaSun
Well-Known Member
apu
Well-Known Member
It seems your top end buffer is intact, and it will be a good baseline reading to compare to as your battery ages.