Don't forget about nimh cycling for us hybrid car guys!

[lewey marcucci]

Many of us prius guys are anxiously awaiting your super sweet software to be usable!  Our cars still use nimh and we use the imax B6's to cycle the batteries. Thanks for all you do!

[ArtC]

Since this thread is quite old, I can't imagine that you're still waiting, but others may be interested.

It's tough to keep track of what's going on when you're trying to balance 28 cells - hence my interest in Bluetooth.

This is the first "production" run with 7-chargers/cells over Bluetooth to the Android tablet.  I'm not going to disturb it until it completes, but so far so good - the values are being displayed in real-time and so hopefully are also being stored.

The graph shows a bad cell I've been using for testing.  I'm hoping to get similar data from the whole pack and compare the cells to find any that really don't match.

[Paweł Si]

Impressive!

are you also using 7 power supplies, one for each charger?

I'm assuming each charger is connected to 4x NiMh batteries,

if you want you can monitor voltages on each cell separately,

and probably a temperature sensor would be a good idea (7x).

Best Regards,
Paweł

[ArtC]

Seven chargers, seven power supplies.  I considered using an old PC power supply or two, but the charger deal with the power supplies was good and having each plugged in just makes it easier.  (I actually have an 8th one that won't flash - maybe more later).

Each Prius cell is 6 NiMH's (7.2V and about 6.5Ah) and there are 28 of them.  As far as I know there's no way to balance each NiMH separately - the cells are pretty well sealed.

You need to cycle the cells 3 or 4 (or 5) times which takes about 2-3 days per cell, so 7 chargers means that you can complete the project in a reasonable time - 4 cells sequentially per charger - and it's still a saving over the $1200+ refurb pack or the $2800 new pack.  (The paper and pencil description of the operation is here: http://priuschat.com/threads/gen-ii-prius-individual-battery-module-replacement.125588/page-2 ))

I don't think that you can do Serial/BlueTooth and temperature at the same time - I'm going for data collection.  Ideally you want to match the pack fairly closely.  I'm doing one last cycle with the tablet connected. The data will hopefully show me if there are any weak cells in the pack so that I can replace them now and not have to repeat this process in a few thousand miles.

[ArtC]

All 7 of the chargers missed the deltaV and quit on capacity limits.

It's not uncommon for these chargers to miss this, but usually on one or two.  I've never seen this happen across the whole set before. It makes me wonder if the serial output in some way is affecting the A/D readings.  I had taken a quick look at the serial code and, from memory, it all seems to be interrupt driven, I think including the transmit, so even a slow baudrate (these are running at 9600) shouldn't make a difference.

There really doesn't seem to be a drop in the curves.

17 is looking suspect - steeper charge curve.  It also started at a lower voltage so it could have a higher self-discharge (or it may not have been fully charged).

[Paweł Si]

2015-07-22 3:54 GMT+02:00 ArtC <ergot...@gmail.com>:

Seven chargers, seven power supplies.  I 

considered using an old PC power supply or two,

If your batteries are no connected it's  ok to use one power supply,

but if they are somehow connected (probably in series) you have to use separate power supplies.

 

but the charger deal with the power supplies was good and having each plugged in just makes it easier.  (I actually have an 8th one that won't flash - maybe more later).

Each Prius cell is 6 NiMH's (7.2V and about 6.5Ah) and there are 28 of them.  

As far as I know there's no way to balance each NiMH separately - the cells are pretty well sealed.

to my knowledge balancing NiMh batteries doesn't make much sens,

 

You need to cycle the cells 3 or 4 (or 5) times which takes about 2-3 days per cell, so 7 chargers means that you can complete the project in a reasonable time - 4 cells sequentially per charger - and it's still a saving over the $1200+ refurb pack or the $2800 new pack.  (The paper and pencil description of the operation is here: http://priuschat.com/threads/gen-ii-prius-individual-battery-module-replacement.125588/page-2 ))

I don't think that you can do Serial/BlueTooth and temperature at the same time

if you charger has a M0517 CPU you can do both, but you have to do some mods.

 

- I'm going for data collection.  Ideally you want to match the pack fairly closely.  I'm doing one last cycle with the tablet connected. The data will hopefully show me if there are any weak cells in the pack so that I can replace them now and not have to repeat this process in a few thousand miles.

 

2015-07-22 7:54 GMT+02:00 ArtC <ergot...@gmail.com>:

All 7 of the chargers missed the deltaV and quit on capacity limits.

It's not uncommon for these chargers to miss this, but usually on one or two.  I've never seen this happen across the whole set before. It makes me wonder if the serial output in some way is affecting the A/D readings.  I had taken a quick look at the serial code and, from memory, it all seems to be interrupt driven, I think including the transmit, so even a slow baudrate (these are running at 9600) shouldn't make a difference. 

There really doesn't seem to be a drop in the curves.

even if something would interfere with the ADC (it is likely)

you would get the opposite, the charger would  peek up a random deltaV change and the charge process would stopped earlier,

but in your case it's probably a too small charging current,
from your picture I can tell it's 650mA = 0.1C
For the deltaV method to work you need at least a ~0.5C charging current (depends on battery)

The deltaV method works as follows:

battery is charged until it's full, after that the battery heats up (energy is not longer stored, but transformed into heat)

this heat causes a voltage drop on the battery
(since the voltage drop is only a site effect of the heat it is better to determine end of charge based on temperature change)
If the charging current is too low, you don't put enough energy into the system and no delta change occurs (or it's very small)

But since you are regenerating the battery It's  probably better to use a small charging current,

and rely on the capacity limit.

[ArtC]

On Wednesday, July 22, 2015 at 10:27:50 AM UTC-6, cheali-charger wrote:

2015-07-22 3:54 GMT+02:00 ArtC <ergot...@gmail.com>:

Seven chargers, seven power supplies.  I 

considered using an old PC power supply or two,

If your batteries are no connected it's  ok to use one power supply,

but if they are somehow connected (probably in series) you have to use separate power supplies.

I could take the bus-bars off.  The circuit is broken (in several places), but you're right, this consideration is one more reason to power them separately.

 

but the charger deal with the power supplies was good and having each plugged in just makes it easier.  (I actually have an 8th one that won't flash - maybe more later).

Each Prius cell is 6 NiMH's (7.2V and about 6.5Ah) and there are 28 of them.  

As far as I know there's no way to balance each NiMH separately - the cells are pretty well sealed.

to my knowledge balancing NiMh batteries doesn't make much sens,

Mostly in this case, it's getting them all to the same charge level.  Over time while driving the cells will drift and, if you add an unknown cell (from eBay of course) then that may have a different charge level.

 

You need to cycle the cells 3 or 4 (or 5) times which takes about 2-3 days per cell, so 7 chargers means that you can complete the project in a reasonable time - 4 cells sequentially per charger - and it's still a saving over the $1200+ refurb pack or the $2800 new pack.  (The paper and pencil description of the operation is here: http://priuschat.com/threads/gen-ii-prius-individual-battery-module-replacement.125588/page-2 ))

I don't think that you can do Serial/BlueTooth and temperature at the same time

if you charger has a M0517 CPU you can do both, but you have to do some mods.

Sadly the cheap-and-cheerful Atmel version.

 

- I'm going for data collection.  Ideally you want to match the pack fairly closely.  I'm doing one last cycle with the tablet connected. The data will hopefully show me if there are any weak cells in the pack so that I can replace them now and not have to repeat this process in a few thousand miles.

 

2015-07-22 7:54 GMT+02:00 ArtC <ergot...@gmail.com>:

All 7 of the chargers missed the deltaV and quit on capacity limits.

It's not uncommon for these chargers to miss this, but usually on one or two.  I've never seen this happen across the whole set before. It makes me wonder if the serial output in some way is affecting the A/D readings.  I had taken a quick look at the serial code and, from memory, it all seems to be interrupt driven, I think including the transmit, so even a slow baudrate (these are running at 9600) shouldn't make a difference. 

There really doesn't seem to be a drop in the curves.

even if something would interfere with the ADC (it is likely)

you would get the opposite, the charger would  peek up a random deltaV change and the charge process would stopped earlier,

That happened on one of the chargers (attached).

but in your case it's probably a too small charging current,
from your picture I can tell it's 650mA = 0.1C
For the deltaV method to work you need at least a ~0.5C charging current (depends on battery)

You assume that I'm much more patient then I am.  The charge rate is 5A - see the attached.  Discharge is  700ma.

The deltaV method works as follows:

battery is charged until it's full, after that the battery heats up (energy is not longer stored, but transformed into heat)

this heat causes a voltage drop on the battery
(since the voltage drop is only a site effect of the heat it is better to determine end of charge based on temperature change)
If the charging current is too low, you don't put enough energy into the system and no delta change occurs (or it's very small)

But since you are regenerating the battery It's  probably better to use a small charging current,

and rely on the capacity limit.

I'm not sure how sensitive NiMH is to overcharge. Pb will take it (more or less) forever. LiFe has the potential for significant damage.  I think that NiMH and NiCd are somewhere in the middle.

Which reminds me.  What does the "balance" do for LiFe?  What I really need is to drop some amount of charge (say to 3.2V or so) and then charge back to 3.65 so that all the cell start out at the same SOC.  100Ah cells, so any significant discharge would take quite a while at 500ma.

[Paweł Si]

2015-07-22 19:35 GMT+02:00 ArtC <ergot...@gmail.com>:

I don't think that you can do Serial/BlueTooth and temperature at the same time

if you charger has a M0517 CPU you can do both, but you have to do some mods.

Sadly the cheap-and-cheerful Atmel version.

after a second thought, it is also possible to do both also on Atmel CPUs, you only have to 
separate the UARTs TX signal from the temperature.

but in your case it's probably a too small charging current,
from your picture I can tell it's 650mA = 0.1C
For the deltaV method to work you need at least a ~0.5C charging current (depends on battery)

You assume that I'm much more patient then I am.  The charge rate is 5A - see the attached.  Discharge is  700ma.

ok, so I take everything back :)

we have two options:

1. ADC don't catches the deltaV change, in this case see:

    https://github.com/stawel/cheali-charger/blob/master/docs/nimh_nicd_charging.md

    especially the "add noise: yes" option

2. battery is not fully charged 

    - you could check if the battery is worm at the end of charge.

    - or even do a overcharge test on a broken battery 

But to be honest I suppose it's the 2. case,
we have to catch a 5mV * 6cells = 30mV change, that shouldn't be a problem.

I'm not sure how sensitive NiMH is to overcharge.

it's not sensitive only if you are charging it with small current ~0.1C
but 1C is to much for them.

 

Pb will take it (more or less) forever. LiFe has the potential for significant damage.  I think that NiMH and NiCd are somewhere in the middle.

Which reminds me.  What does the "balance" do for LiFe?  What I really need is to drop some amount of charge (say to 3.2V or so) and then charge back to 3.65 so that all the cell start out at the same SOC.  100Ah cells, so any significant discharge would take quite a while at 500ma.

 

balancing (on this type of chargers) means to discharge cells with higher voltage to the level of the lowest one,
we balance (discharge) only with 200mA current so it will take quite a while ;)

[ArtC]

On Thursday, July 23, 2015 at 8:59:18 AM UTC-6, cheali-charger wrote:

ok, so I take everything back :)

No! If you take back the firmware I'd have seven absolutely useless chargers!
 

2. battery is not fully charged 

    - you could check if the battery is worm at the end of charge.

    - or even do a overcharge test on a broken battery 

The trashed cell did hit ∆V (see attached).  The trashed cell also goes to 9.6V before hitting ∆V. (9.559V)

The good cells often seem to flat-line at 9.0V (or just above).  I think flat-line rather than plateau.

From the sample in your documentation, and the bad cell chart, I think that we should be expecting a voltage of around 9.6V.

Any idea why we're not hitting it?  The resistance of the bad cell (averaged over the whole curve ignoring values <20 or > 1000) is 312mΩ some of the other good cells are higher (~450mΩ).  The suspect 17, which seriously flatlined at 9V is 304mΩ.

5A charge is about 0.7C.  I could cut that to say 0.5C (3500mA) which might also help with the voltage. 

[ArtC]

On Thursday, July 23, 2015 at 11:03:26 AM UTC-6, ArtC wrote:

The trashed cell did hit ∆V (see attached).  The trashed cell also goes to 9.6V before hitting ∆V. (9.559V)

The good cells often seem to flat-line at 9.0V (or just above).  I think flat-line rather than plateau.

5A charge is about 0.7C.  I could cut that to say 0.5C (3500mA) which might also help with the voltage. 

Something strange here.  The cells are topping out at ~9V in both cases.  If you apply 9V to a cell you cannot get both a 5A and a 3.5A charge current - yet that's what the charger is reporting.  For information, at the end of charging the resistance of the cells was about 650mΩ.

It looks from the code as though the current and voltage is just a read from analog inputs.  I tend to trust the voltage since we've seen a curve that goes to 9.6V and then ∆V's.  If I get a chance I'll add an ammeter to one of the cells.

Any ideas?    What's the hardware is that generates the current input?

Batteries are weird. If this was a just a resistor, it would almost look like a boost failure - the low resistance cells might reach 9.6V without a boost (~12.5V input) whereas the higher resistance cell won't.  With batteries I'm never really sure what the behavior will be.

[Paweł Si]

2015-07-24 17:46 GMT+02:00 ArtC <ergot...@gmail.com>:

On Thursday, July 23, 2015 at 11:03:26 AM UTC-6, ArtC wrote:

The trashed cell did hit ∆V (see attached).  The trashed cell also goes to 9.6V before hitting ∆V. (9.559V)

The good cells often seem to flat-line at 9.0V (or just above).  I think flat-line rather than plateau.

5A charge is about 0.7C.  I could cut that to say 0.5C (3500mA) which might also help with the voltage. 

Something strange here.  The cells are topping out at ~9V in both cases.  If you apply 9V to a cell you cannot get both a 5A and a 3.5A charge current - yet that's what the charger is reporting.  For information, at the end of charging the resistance of the cells was about 650mΩ.

interesting, if the internal resistance was 650mΩ (actually it's a Tevenin resistance of your whole system, battery wires included) you should get a voltage difference of (5A-3.5A)*650mΩ = 0.975V

although this resistance is measured at the beginning of the charging  process and the batteries internal resistance  decreases during charging.

 

It looks from the code as though the current and voltage is just a read from analog inputs.  I tend to trust the voltage since we've seen a curve that goes to 9.6V and then ∆V's.  If I get a chance I'll add an ammeter to one of the cells.

yes, ammeter reading would be helpful. 

 

Any ideas?    What's the hardware is that generates the current input?

we measure current by measuring voltage on a 0.05 Ohm resistor, which is amplified through an op-amp. 

[ArtC]

On Sunday, July 26, 2015 at 6:45:38 AM UTC-6, cheali-charger wrote:

2015-07-24 17:46 GMT+02:00 ArtC <ergot...@gmail.com>:

On Thursday, July 23, 2015 at 11:03:26 AM UTC-6, ArtC wrote:

The trashed cell did hit ∆V (see attached).  The trashed cell also goes to 9.6V before hitting ∆V. (9.559V)

The good cells often seem to flat-line at 9.0V (or just above).  I think flat-line rather than plateau.

5A charge is about 0.7C.  I could cut that to say 0.5C (3500mA) which might also help with the voltage. 

Something strange here.  The cells are topping out at ~9V in both cases.  If you apply 9V to a cell you cannot get both a 5A and a 3.5A charge current - yet that's what the charger is reporting.  For information, at the end of charging the resistance of the cells was about 650mΩ.

interesting, if the internal resistance was 650mΩ (actually it's a Tevenin resistance of your whole system, battery wires included) you should get a voltage difference of (5A-3.5A)*650mΩ = 0.975V

although this resistance is measured at the beginning of the charging  process and the batteries internal resistance  decreases during charging.

 

It looks from the code as though the current and voltage is just a read from analog inputs.  I tend to trust the voltage since we've seen a curve that goes to 9.6V and then ∆V's.  If I get a chance I'll add an ammeter to one of the cells.

yes, ammeter reading would be helpful. 

Haven't had a chance to put an ammeter on there yet and have to leave town so it might be a while.

I did put the Hyperion charger on the cells.  It also seems to top out at about 9V but it  ∆V's in about 15-20 minutes.  So I'm back to the original theory that something in the serial comms is causing a problem.

I was hoping that there might be more code in:

ISR(USART_UDRE_vect)

but there's not a lot there.  It might still be worth enabling interrupts until the final line so that the code can be pre-empted by an A/D complete interrupt.  I haven't looked at the A/D filtering logic, but can't really imaging that the extra TX code is making a difference.  At 9600 baud it's also happening no more often than every millisecond.

There's a bunch of RX code in there that might be low-hanging fruit if you're looking for code space.

 

Any ideas?    What's the hardware is that generates the current input?

we measure current by measuring voltage on a 0.05 Ohm resistor, which is amplified through an op-amp. 

Significant temperature variation and no isolation - but simple, effective and hard to imagine too much error.

I can't really complain - I did choose the chargers based on low price.
 

[Paweł Si]

2015-07-27 3:43 GMT+02:00 ArtC <ergot...@gmail.com>:

Haven't had a chance to put an ammeter on there yet and have to leave town so it might be a while.

I did put the Hyperion charger on the cells.  It also seems to top out at about 9V but it  ∆V's in about 15-20 minutes.  So I'm back to the original theory that something in the serial comms is causing a problem.

hm... we do block everything when the UART's buffer is full

maybe you should set the UART's speed to a higher value,

9600 may not be enough. 

I was hoping that there might be more code in:

ISR(USART_UDRE_vect)

but there's not a lot there.  It might still be worth enabling interrupts until the final line so that the code can be pre-empted by an A/D complete interrupt.  I haven't looked at the A/D filtering logic, but can't really imaging that the extra TX code is making a difference.  At 9600 baud it's also happening no more often than every millisecond.

I don't even know whats inside  HardwareSerial.cpp, it's an arduino implementation

but enabling the interrupts shouldn't hurt.

[Paweł Si]

2015-07-27 3:43 GMT+02:00 ArtC <ergot...@gmail.com>:

I did put the Hyperion charger on the cells.  It also seems to top out at about 9V but it  ∆V's in about 15-20 minutes. 

There might be some big differences how we measure the  ∆V's,

cheali-charger:

1. each measurement you see in your logs is a averaged value of 1000x ADC measurements 

    (In the source code it's called "one full measurement", it takes about 0.7s to complete) 

2. in addition to that the ∆V is a averaged value of 42x "full measurements", so it's 42000x ADC
   measurements and it takes 30 seconds.

   (you definitely have to see the ∆V in your logs, before cheali-charger decides it's really there)

3. we measure  voltage when charging current is flowing (charge is done with constant current)

Hyperion charger (I never saw this charger, so it's only guessing):

1. they charge battery with pulsing current

2. they measure battery voltage when current is not flowing

3. they also do some tricks like averaging to enhance the ADC resolution

[Jim Redman]

On 07/27/2015 08:43 AM, Paweł Si wrote:

2015-07-27 3:43 GMT+02:00 ArtC <ergot...@gmail.com>:

Haven't had a chance to put an ammeter on there yet and have to leave town so it might be a while.

I did put the Hyperion charger on the cells.  It also seems to top out at about 9V but it  ∆V's in about 15-20 minutes.  So I'm back to the original theory that something in the serial comms is causing a problem.

hm... we do block everything when the UART's buffer is full

The transmit buffer appears to be 256 bytes (but it may be 16 which would be a problem).  The packet is much smaller than that:

$1;1;32.6;3329;0;0;0;0;64902;0;12602;0;2;13;7;9;9;0;0;0;0;0;0;408;0;54;5;60

9600 baud is about 1ms per character so that packet should transmit in 100ms or so.  Packet arrive about 1/second or just a little less, certainly more than 500ms apart so I don't think that the buffer should ever be full (unless it's only 16 bytes).

However, thinking about it, I don't know what else happens on "doIdle" but a one second cycle on that seems pretty slow, which may mean that maybe one heck of a lot of cpu cycles are being used on interrupts.  If the TX ISR is delayed by other interrupts it may take a while to get those bytes out and so the buffer may fill up. 

It's my recollection that there's a time-space between the packets, but it's been a week or so since I watched and I wasn't watching for that, so that may be my imagination.

If the buffer is filling up,then one solution would be to ensure that there's enough buffer space before starting the send.  HardwareSerial::available appears to be the number of bytes in the buffer so free would be SERIAL_BUFFER_SIZE - available()

maybe you should set the UART's speed to a higher value,

9600 may not be enough.

The bluetooth dongles default to 9600 baud (or sometimes 19200) and changing them is not simple (requires an Arduino or similar).  I can try that (except that at the minute I don't have access to an Arduino - I should have packed the AVR dragon because I currently don't have any way to program the chargers) - but it would be much easier for others if there's no need to change the dongle settings.

I was hoping that there might be more code in:

ISR(USART_UDRE_vect)

but there's not a lot there.  It might still be worth enabling interrupts until the final line so that the code can be pre-empted by an A/D complete interrupt.  I haven't looked at the A/D filtering logic, but can't really imaging that the extra TX code is making a difference.  At 9600 baud it's also happening no more often than every millisecond.

I don't even know whats inside  HardwareSerial.cpp, it's an arduino implementation

but enabling the interrupts shouldn't hurt.

It depends on which interrupt is being starved and why.  Given how little code is in the TX ISR I'm leaning towards the idea that the ADC is starving the TX.

How accurate is the clock?  If the clock is loosing time then it's probably missing interrupts which would suggest that other ISRs will have problems.

--
You received this message because you are subscribed to a topic in the Google Groups "cheali-charger" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cheali-charger/8xqFRYT0iew/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cheali-charge...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jim Redman]

On 07/27/2015 09:44 AM, Paweł Si wrote:

2015-07-27 3:43 GMT+02:00 ArtC <ergot...@gmail.com>:

I did put the Hyperion charger on the cells.  It also seems to top out at about 9V but it  ∆V's in about 15-20 minutes. 

There might be some big differences how we measure the  ∆V's,

cheali-charger:

1. each measurement you see in your logs is a averaged value of 1000x ADC measurements 

    (In the source code it's called "one full measurement", it takes about 0.7s to complete) 

2. in addition to that the ∆V is a averaged value of 42x "full measurements", so it's 42000x ADC
   measurements and it takes 30 seconds.

   (you definitely have to see the ∆V in your logs, before cheali-charger decides it's really there)

3. we measure  voltage when charging current is flowing (charge is done with constant current)

Without Serial logging this detects  ∆V most of the time.

30 seconds is a pretty long average.  The ∆V appears to occur over about a 5 minute period at the end of a ~1 hour charge, so stretching out the 30 seconds may be enough to throw the reading off.

Hyperion charger (I never saw this charger, so it's only guessing):

Some pictures here.

http://www.elektromodellflug.de/oldpage/Projekte/eos-0606i.htm

I doubt it's really that much different from the supported chargers (if at all).  It claims it added about 1Ah to the cells.  I suspect it's just refreshing the surface charge and adding some overcharge - the other chargers max out at ~7400 mAh which is significantly over the capacity of the cells..

1. they charge battery with pulsing current

2. they measure battery voltage when current is not flowing

3. they also do some tricks like averaging to enhance the ADC resolution

[Paweł Si]

2015-08-02 1:26 GMT+02:00 Jim Redman <ergot...@gmail.com>:

Without Serial logging this detects  ∆V most of the time.

cheali-charger is detecting the ∆V without serial logging?

are you sure?

 

30 seconds is a pretty long average.  The ∆V appears to occur over about a 5 minute period at the end of a ~1 hour charge, so stretching out the 30 seconds may be enough to throw the reading off.

hm... we can always decrease this interval.

[ArtC]

Some more input.

I've just cycled another couple of packs.  The goal was making one good pack from two bad ones - not as easy as I would have hoped, these were fairly trashed (we suspect too much driving after the pack failed).

The good cells all missed ∆V when logging was on at a 5A charge current (and sometimes missed it without logging).  So something strange is still going on and there's still a logging dependency.  I suspect, in general, that decreasing the averaging time may help especially since it may be extended by logging.  5A is about 0.7C so significantly above the recommended 0.5C.  At some point I dropped the current to 3.5A (see one of the ideas above) and continued to not see ∆V's.

With the suspect cells, they ∆V pretty much consistently at 3.5A and at 4.5A (I never went back to 5A) - even when logging.  A couple missed, maybe they were the best cells (I didn't have time to repeat a discharge).

The suspect cells were mostly in the 5000-6000mAh whereas good cells are closer 7000mAh.  Not much confidence in this pack, but at least Cheali Charger seems to be behaving correctly.

I'll try and get the application out on Google Play.  The quantify of data is causing memory issues on some of the devices, so my challenge is to craft a SQL statement for SQLite that will skip values and only pull ~2000 values.  Once I have that the graphs should be stable.

Moving away from Prius NiMH and gas powered vehicles for a while (unless the suspect pack fails).  I still need to top balance 40+ 100Ah LiFe for which I need to discharge them a little (say to ~3.2V) and then charge them back to 3.65V (or so) to get the ElectraVan running.

[Paweł Si]

2015-08-13 0:05 GMT+02:00 ArtC <ergot...@gmail.com>:

Some more input.

I've just cycled another couple of packs.  The goal was making one good pack from two bad ones - not as easy as I would have hoped, these were fairly trashed (we suspect too much driving after the pack failed).

The good cells all missed ∆V when logging was on at a 5A charge current (and sometimes missed it without logging).  So something strange is still going on and there's still a logging dependency.  I suspect, in general, that decreasing the averaging time may help especially since it may be extended by logging.  5A is about 0.7C so significantly above the recommended 0.5C.  At some point I dropped the current to 3.5A (see one of the ideas above) and continued to not see ∆V's.

I've added a ticket for that, unfortunately it will have to wait a while, I don't have enough free time right now :/

 

With the suspect cells, they ∆V pretty much consistently at 3.5A and at 4.5A (I never went back to 5A) - even when logging.  A couple missed, maybe they were the best cells (I didn't have time to repeat a discharge).

The suspect cells were mostly in the 5000-6000mAh whereas good cells are closer 7000mAh.  Not much confidence in this pack, but at least Cheali Charger seems to be behaving correctly.

I'll try and get the application out on Google Play.  The quantify of data is causing memory issues on some of the devices, so my challenge is to craft a SQL statement for SQLite that will skip values and only pull ~2000 values.  Once I have that the graphs should be stable.

that's great news! :-)

 

Moving away from Prius NiMH and gas powered vehicles for a while (unless the suspect pack fails).  I still need to top balance 40+ 100Ah LiFe for which I need to discharge them a little (say to ~3.2V) and then charge them back to 3.65V (or so) to get the ElectraVan running.

It would also great if you would consider to use additionally a temperature sensor,

the charging process should be more reliable with it.

I'm assuming such a package contains a build in one, maybe there is a chance to use it?

[John Seaton]

Did the app ever make it to Google Play and if so what is the name?

I'm helping a buddy re-condition his prius battery pack and this looks promising.

[Jim Redman]

I've just published it.  Some horrible graphics on the Google Play store - apologies for that.

Cheali Charger Battery Monitor

If you're going to run 7 chargers you'll need a device that supports 7 bluetooth connection.  Some support only three - I don't really have much advice except for trial and error.  The Samsung tablet (pictured) supports 7.  I _think_ that most of the Nexus devices and many phones will also provide support for enough connections.

I have a newer version that the apk in the play store - as soon as I get a chance to check it out I'll upload it (but it's been languishing for months - in part because I loaned all my chargers to another Prius owner)

Please let me know if you have any problems - that should give me some incentive to revisit the application.

[John Seaton]

Wow that was fast!

Did you ever get the -dV peak detection working for all the packs?

I have an original iMax B6AC+ that I loaned to my friend for charging his packs and I had the capacity and time limit turned off. The packs took 8-10 amps of charge before the charger detected it was full. I found a forum thread where a guy was using these same chargers to charge his packs and was setting his capacity limit to 7250. I turned the capacity limit back on and set it to that. We are doing doing 3 cycles now at 5A/.7A with the capacity limit set to 7250.

I picked up an Accucel 6-80w to help out with the work and set the settings the same but for some reason it is stopping once it hits the capacity limit and displays a "over charge capacity limit" message and won't complete the cycles. My iMax just hits the limit and starts the next cycle. The most annoying part is that you can't see what it took out and put in for the one cycle it completed. I have two watt meters so that should solve that problem.

I'll read through the thread again once I get home but I might have some questions for ya if you don't mind.

Thanks!

[Jim Redman]

On 05/03/2016 03:29 PM, John Seaton wrote:
> Wow that was fast!

I was already half way through publishing it. That does lead me to
wonder how old the APK that's there is, so if you do have problems (or
successes), please let me know.

https://play.google.com/store/apps/details?id=com.ergotech.android.ChealiBatteryMonitor&hl=en

>
> Did you ever get the -dV peak detection working for all the packs?

No. I never really go back to the project. I do have another Prius
pack that I need to cycle, so maybe, whenever I get to that (most likely
not until a pack one of the Priuses fails) I may take another look.

Now I think about it, having a bluetooth (or any serial dongle) actually
connected should make no difference - the processor is pushing the bits
out the line whether anyone's listening or not.

>
> I have an original iMax B6AC+ that I loaned to my friend for charging his packs and I had the capacity and time limit turned off. The packs took 8-10 amps of charge before the charger detected it was full. I found a forum thread where a guy was using these same chargers to charge his packs and was setting his capacity limit to 7250. I turned the capacity limit back on and set it to that. We are doing doing 3 cycles now at 5A/.7A with the capacity limit set to 7250.
>
> I picked up an Accucel 6-80w to help out with the work and set the settings the same but for some reason it is stopping once it hits the capacity limit and displays a "over charge capacity limit" message and won't complete the cycles. My iMax just hits the limit and starts the next cycle. The most annoying part is that you can't see what it took out and put in for the one cycle it completed. I have two watt meters so that should solve that problem.

The one data point (without much evidence to back it up) I would add is
that the worse the module the more likely that the charger will hit
-dV. On the one bad module (missing a whole cell) that I used for
testing it would hit -dV fairly consistently. The same is (largely)
true for the really weak pack that the borrower of my chargers is cycling.

The one other thing that I tend to do with the pack is give one final
charge with the same charger. I generally think that the most important
part of this operation is the balancing rather than the cycling.

>
> I'll read through the thread again once I get home but I might have some questions for ya if you don't mind.

No sure that I'll have answers, but I'll do my best...

[John Seaton]

While I take a break from making charge cables ...

On Tuesday, May 3, 2016 at 5:52:04 PM UTC-4, ArtC wrote:

On 05/03/2016 03:29 PM, John Seaton wrote:
> Wow that was fast!

I was already half way through publishing it.  That does lead me to
wonder how old the APK that's there is, so if you do have problems (or
successes), please let me know.

https://play.google.com/store/apps/details?id=com.ergotech.android.ChealiBatteryMonitor&hl=en


>
> Did you ever get the -dV peak detection working for all the packs?

No.  I never really go back to the project.  I do have another Prius
pack that I need to cycle, so maybe, whenever I get to that (most likely
not until a pack one of the Priuses fails) I may take another look.

No worries, I was just curious, 

My plan is to collect Prius packs both good and bad and get setup to run cycles on them at different rates and collect the data on them. I'm planning on building a test rig with temp sensor and load cell so that I can monitor temp and pack swelling. I want to get intimately familiar with these packs.  

Now I think about it, having a bluetooth (or any serial dongle) actually
connected should make no difference - the processor is pushing the bits
out the line whether anyone's listening or not.

>
>   I have an original iMax B6AC+ that I loaned to my friend for charging his packs and I had the capacity and time limit turned off. The packs took 8-10 amps of charge before the charger detected it was full. I found a forum thread where a guy was using these same chargers to charge his packs and was setting his capacity limit to 7250. I turned the capacity limit back on and set it to that. We are doing doing 3 cycles now at 5A/.7A with the capacity limit set to 7250.
>
> I picked up an Accucel 6-80w to help out with the work and set the settings the same but for some reason it is stopping once it hits the capacity limit and displays a "over charge capacity limit" message and won't complete the cycles. My iMax just hits the limit and starts the next cycle. The most annoying part is that you can't see what it took out and put in for the one cycle it completed. I have two watt meters so that should solve that problem.

The one data point (without much evidence to back it up) I would add is
that the worse the module the more likely that the charger will hit
-dV.  On the one bad module (missing a whole cell) that I used for
testing it would hit -dV fairly consistently.  The same is (largely)
true for the really weak pack that the borrower of my chargers is cycling.

Yeah I thought that was an interesting observation. The new cells not displaying any noticeable -dV falls in line with what I've read on other sites so that pretty much confirmed in my mind that we need to continue using the cap limit as the cut-off point for these chargers. 

 

The one other thing that I tend to do with the pack is give one final
charge with the same charger.  I generally think that the most important
part of this operation is the balancing rather than the cycling.

Back when I first started flying R/C airplanes on battery packs, my lipos didn't even come with balancing ports and my chargers didn't have them either. It was much later on that I understood why batteries needed to stay balanced. Even though I don't balance nimh or nicad battery packs for hobby use, I figured the prius battery packs needed to be. 

>
> I'll read through the thread again once I get home but I might have some questions for ya if you don't mind.

No sure that I'll have answers, but I'll do my best...

I've been making cables so I haven't spent the time to really soak in what you've done in this thread but I did have one quick question. Did your charges stop charging when the cap limit was hit or did it stop that charge and start the next cycle? I'm trying to determine if this is a new "feature" in these chargers since my old one doesn't abort the whole charge cycles after the first one.

Thanks

John 

[John Seaton]

Does this firmware support using the balance ports for nimh batteries? Sorry, I haven't read through the documentation yet but yeah I need to.