I seem to be in the ballpark though - I calculated the IR of the King Kong cell at ~4 milliohms, which Sucre confirmed. The actual readings I was getting were ~4.2 milliohms.
Like you, I'm generally happy with consistency rather than absolute accuracy, and will accept the fact that the numbers are likely going to be different from method to method, especially with such a picky measurement.
It all seems to be in the range for the values we've calculated at the pack level. A brand new pack is ~0.24 ohms, a good stock pack is ~0.30 ohms and a dead stock pack is ~0.45+ ohms.
That would be 2, 2.5 and ~3.7 milliohms per cell, average.. and is in the ballpark for what I'm seeing. Bad stock cells are reading 4 - 4.5milliohms, good cells are reading 2.8 - 3 milliohms. New cells are reading 1.9 - 2 milliohms. My numbers seem a little high, and it's probably due to the waiting too long thing.
I'll try to code it so it actually waits for the voltage to settle, rather than a set period of time.
__________________
Bumblebee Batteries, LLC - Helping your hybrid get from point A to point Bee!
The bank1 cycles are the 02 benched battery w/ original variables settings, I will run another round here in a week or two with the newer settings. The bank0 cycles are the 05, my daily driver, which I had to shut down in last charge to fly out for Christmas.
The O5 is stronger all the time it seems, the battery on the bench I need to figure out a maintenance routine for. I feel the 02 was the stronger when I pulled it from the rollover.
__________________
New Formula Red 05 MT 164978m
Monte Carlo Blue 02 MT 158536m
ScangaugeII w/lean burn x-gauge
Fumoto oil drain valve, 60# in OEMs
Wet Okoles & ArmrestKing armrest
MIMA#136,GC1#47,Lewis sub
Bank 0 Cycle 1 132.5
Bank 0 Cycle 2 140.8
Bank 0 Cycle 3 139.9
Bank1 Cycle 1 148.9
Bank1 Cycle 2 149.1
Bank1 Cycle 3 149.6
all stopped discharging for R6
DischR = 6: End of discharge determined by the difference between the Long-term and Short-term Voltage Averages exceeding the SlopeDifMax* set value. (Battery Voltage graph dropping rapidly signals a cell drop-out or overall pack nearing end of safe Discharge)
Will be interesting to see how things change on the next series with the new variables.
Eli, the voltage will not settle, it will continue to drop due to the cells discharging, so we want to sample the second point the same length of time from the start on each test, and that time should be the minimum that gives repeatable readings.
I meant the delta of the voltage drop.. when it levels off. But yeah, I realized that after I said that - to get consistency, it just needs to be sampled at the same time. Which is why my readings are consistent, at least. Almost surprised I seem to be so close while waiting so long if it takes less than 150ms. Let's see what I come up with after tweaking things.
__________________
Bumblebee Batteries, LLC - Helping your hybrid get from point A to point Bee!
The settling time of the electronics can make a big difference in how long you need to wait for the change to be stable.
If you have an OPamp in the system, that can add a lot of time to the required settling time, which is why a storage scope is such a good tool for seeing the details of a single pulse.
I am trying to understand why I can't get a deeper discharge with a Code 3 end rather than a Code 6 end. The comparison graphs below show a "good" discharge to 135V with Code 3 (top), and a discharge to I think 137.8V with a Code 6 (bottom). Both of these are after a soaking charge. It seems the good discharge has a greater negative slope than the bad discharge. And I don't see any sudden drops that would indicate cells dropping out. The "Bad" discharge was actually done with the SlopeDifMax at the newly recommended 30, and the "Good" was with it at 20. I also have an Excel sheet that shows both of these within 2 volts of the end of discharge, but it basically would show the same slopes and steps, just with exact numbers attached.
Question is how to set SlopeDifMax to improve the situation, and what to look for to avoid nasty results besides hitting the MinDischrgV...?? And does this show that something might be amiss in the program?
B
Oh...PS...I guess the time scales will not be exactly the same, so evaluation of slope by the graphs may be complicated. If the spreadsheet is better for that, I can send/upload it.
And my charger is S/N 0166
Last edited by bluesight; 01-07-2013 at 11:37 PM.
Reason: Observation
The discharge end detection has several things it is looking at.
It looks like your stopping based on one of these test, which looks for if the voltage drops .2V in one 5 second sample, and does it again on the next, the pack is considered to be in the final discharge slope and it stops. The fact that your in that condition at the 140V means that you have a stick/cell that is dropping out, and you will not improve things until you replace that stick. It also could be several sticks running out of juice at the same time, so your pack will require a bench test with the sticks exposed so you can:
1) determine which stick/sticks are dropping out.
2) if the whole pack is ready to drop out, or that there are many sticks that are still well into the good zone, and replacing the bad ones will fix the pack.
The first pass at documenting this procedure is this video:
The detection algorithm seems too subtle for me to catch. I don't see the .2V drops in 2 subsequent 5 second intervals on the lower (bad) graph any more than on the upper (good) graph. And these graphs don't look nearly as revealing as those on the video where there appeared to be some major changes in slope when cells were dropping out. On the video (and in the data logger), the bottom box with graphs (blue lines) appears to show more sensitive data, looks like some derivatives of the change rates for the voltage drops along with a smoothed version. But I don't know how to recover those in the "Compare" window. Those seem to hold more of a key to detection of dropping cells. Though in earlier screen images that I captured, those lower graphs looked pretty well behaved in the "macro" sense. I couldn't zoom in on them after the fact.
I was thinking that maybe multiple .2V drops in 2, 5 second intervals could be detected within the typical step drops shown in the graphs. That would appear to be a potential sampling error. But I don't see that effect at the end of the lower "bad" graph above, unless there is some delay between detection and throwing the code. And I would expect it would happen on the "good" graph as well, and many times overall since there are steps in discharge voltage throughout the cycle.
Sorry to persist in my confusion...
B
PS...the sharp drop at the end of the curves is the complete discharge shutoff, not continuation of the discharge process that might be confused with dropping of cells....
PPSS...I see from the data that the steps in voltage samples are "instantaneous", probably due to A/D converter resolution and can't be detected across multiple 5 second intervals. The slopes shown on the graphs are anomalies of the line graph method...won't show step changes. End data for "good" looks like:
OK, after looking at the data it does not look like the bit/sample is stopping you,
There is another tech editable variable the DischSmpFac* that is at play. The variable is adjustable without the password from the datalogger.
We look for the discharge slope to level off during the flattest part of the curve, and figure out how many 5 second samples it took to drop a bit, (slope)and then use the DiscSmpFact* to set a target samples per bit as a low end limit.
All of the detection of slope code depends on the discharge starting after a charge so we have a known point of reference, and can do the slop min detect to find the flattest part of the discharge curve.
We explain this in the mode 6 operator manual section i believe it starts on page 17.
Since new packs and old packs will have drastically different samples / bit change this was intended to compute a minimum samples / bit that was scaled differently depending on the pack capacity.
Since you using the datalogger,and can watch the drop out so well, try turning off the discharge stop as described in the video, and see what the graph looks like after the detection code would have stopped it. The charger will beep when it would have stopped the discharge, and you can stop it manually with the stop key once you have see the real drop off, or wait for the still active MinDischrgV* to stop it
In the normal operation,you could also change the DiscSmpFact*, so the target bits / sample is lower.
Send me an e-mail, or give me a phone call, and I can share the password with you.
With password entered, during the discharge, you hit test, which will turn off all discharge detection code except for the "MinDischrgV* hard limit.
The graph will show us what is happening.
Will be watching for your results, and possibly your suggestions as to how we could impruve the detect algorithm.
My math skills regarding this type of statistical detection is weak, so suggestions are welcome. We do not have the option of storing a lot of datapoints for analysis within the microcontroller, so we have to do it on the fly, and need to cover all the possibilities from a really weak pack to a really strong one.
On the other hand, the detection could be passed to labview, where the whole history and all the datapoints are stored in the graph buffer, Labfiew has some very advanced statistical analysis functions and labview could stop the discharge?
The AutoGuide.com network consists of the largest network of enthusiast-owned enthusiast-operated automotive communities.
AutoGuide.com provides the latest car reviews, auto show coverage, new car prices, and automotive news. The AutoGuide network operates more than 100 automotive forums where our users consult peers for shopping information and advice, and share opinions as a community.
