EEVblog #774 - Low Battery Discharge Testing Part 1

[tszaboo]

Dave, everything you did is fundamentally wrong, because the BK Precision load is not a monkey's ass.
But jokes aside, I agree with you that if a product is draining constant power, there isn't too much energy in it. But there are stuff, where the load is usually low, and it has peaks, where the undervoltage would trigger. A good example is the Canon Powershot IS5. Every time you zoom with it, there is a chance that it will shut down, with dead battery flashing on the screen, while otherwise it could take several photos, because there isnt any motors and moving parts.
We all know what the result will be with constant load. What I'm suggesting is to give the marketing guys a fair chance, set up a pulsed load test. For example, every 5 minutes load the battery with 200mA for a second and only 5mA otherwise. The results will be much more interesting, than the "Told you so" that you are doing. Not going to be 800%, but I expect it to be better than the 0.1-10% increase that we are looking at.

Extraordinary claims require extraordinary evidence

[EEVblog]

@EEVBlog: You should do a 250mW test to make sure your setup replicates the results of the datasheet (as a baseline for the Duracell). It would be a good control for your test setup.

Not a bad point. In that case I'll have to use the remote sense inputs on the 8500 load, otherwise too much drop in the leads at low voltages.

[EEVblog]

Dave, everything you did is fundamentally wrong, because the BK Precision load is not a monkey's ass.
But jokes aside, I agree with you that if a product is draining constant power, there isn't too much energy in it. But there are stuff, where the load is usually low, and it has peaks, where the undervoltage would trigger. A good example is the Canon Powershot IS5. Every time you zoom with it, there is a chance that it will shut down, with dead battery flashing on the screen, while otherwise it could take several photos, because there isnt any motors and moving parts.
We all know what the result will be with constant load. What I'm suggesting is to give the marketing guys a fair chance, set up a pulsed load test. For example, every 5 minutes load the battery with 200mA for a second and only 5mA otherwise. The results will be much more interesting, than the "Told you so" that you are doing. Not going to be 800%, but I expect it to be better than the 0.1-10% increase that we are looking at.

Extraordinary claims require extraordinary evidence

This has nothing to do with the Batteriser at all!

[DanioIO]

This video made me think about making a analog constant power load, the BK load isnt very good at 0V and it will be good to see whats happening there. The analog constant power is not very popular with equipment manufacturers they just stick to the easier digital power calculation and that causes some problems with the near zero power measurement.

[Fungus]

the BK load isnt very good at 0V and it will be good to see whats happening there.

Probably a mismatch between the BK's sampling rate and whatever the battery is doing.

A decoupling capacitor would probably fix it.

[rs20]

Probably a mismatch between the BK's sampling rate and whatever the battery is doing.

A decoupling capacitor would probably fix it.

I've already addressed that suggestion earlier in this thread. In short, it's most likely a deliberate design decision, and a capacitor won't do anything.

[open loop]

As I don't own one so can't tell.... Is it possible to change the voltage logging on the 34470a to only log on a change in voltage say 0.01 V rather than every second. You would then have a more efficient way of logging the data.

Just my 2c

[Dr. Frank]

As I don't own one so can't tell.... Is it possible to change the voltage logging on the 34470a to only log on a change in voltage say 0.01 V rather than every second. You would then have a more efficient way of logging the data.

Just my 2c

I own a 34465A, which is behaving exactly the same, as these share the same firmware.
No, it's not possible to do so, by its own.
You have to write an external program.

Frank

[boffin]

anyone else want to see the discharge curve @ 1.21GW?

[Don Hills]

Testing under load isn't a new thing - one manufacturer used to include an under-load tester in each blister pack, and (I think Eveready) actually built one into each cell. I use an old analog ammeter to test cells - the more current they can deliver into a near short circuit, the fresher they are. But I don't know what the relationship is between the short-circuit current and the remaining capacity. Does it follow a somewhat s-shaped curve like the under-load terminal voltage, or is it more linear? I suspect the former but I guess I'll have to try it and see.

[artag]

Can't agree with Dave's criticism of the binary protocol on the BK load.

It's true that a straightforward ASCII protocol like SCPI is easy to understand and code for the simple case. But the problem is, it has no error checking. The only checks you can do if it's on RS232 are framing, gross corruption, maybe overrun (if your PC's OS tells you)  and maybe parity (if the instrument supports it and the OS reports it). This matters less on HPIB where you have handshaking, carefully controlled data lines and good cables. It's fine on USB and TCP/IP where there's lower level transport layer to detect and correct losses. But RS232 isn't that good.

ASCII protocols are fine for simple test automation (like this example) where the results aren't critical and the worst they can do is give you a spike in the graph or a missing sample - easily detected by eye. But what if you're building an ATE system ? Where an error can hang the test (what happens if a CR/LF gets corrupted), invalidate the results or kill a part by overloading it. Where the cables are long. Where the electrical interference is heavy and intermittent. Try and write a reliable transport layer for an unchecked ASCII protocol and you'll be tearing your hair out and wishing for a packetised binary protocol, because your ATE is rejecting good parts every time the fork lift drives past. 

I think BK did it right, and all too few manufacturers do - they give you an RS232 interface because PCs can do it cheaply (in the days before USB) but they just run the same protocol as they do over an error-checked, reliable link.

[artag]

But I don't know what the relationship is between the short-circuit current and the remaining capacity. Does it follow a somewhat s-shaped curve like the under-load terminal voltage, or is it more linear?

it would be interesting to calculate or measure the internal resistance of the cell as it discharges. Then, you could determine how long you could put your ammeter across the cell and still have, say, more than 50% of its capacity remaining.

[Don Hills]

it would be interesting to calculate or measure the internal resistance of the cell as it discharges. Then, you could determine how long you could put your ammeter across the cell and still have, say, more than 50% of its capacity remaining.

But does the cell chemistry behave differently at high discharge rates versus low rates? If you're testing the behaviour at the exhausted end, as Dave is, will it affect the results to apply a high discharge rate first until the cell capacity approaches the area of interest? "Don't know..."

The internal resistance does rise as the cell discharges, but it's not the only mechanism at play - the open circuit voltage also decreases. What's a valid way of measuring the internal resistance anyway? Current into a short circuit? Voltage change when the load current is changed slightly? (Edit:) It's going to vary depending on the current drawn while measuring anyway, it's determined partly by how hard the depolariser is working.

Another thing I think is unknown is the impedance at higher frequencies. For example, it's pretty well understood in car audio circles that amplifiers that draw fluctuating current can cause the car lights to fluctuate in brightness, and adding a multi-Farad capacitor across the load can reduce or prevent it. Does a cell take time to increase its output when suddenly presented with a higher load? It should be easy enough to test with a scope and a switchable load, but I've never seen anyone try it.

So many questions, so little time... and it's easy to say, "who cares anyway?"

[EEVblog]

Can't agree with Dave's criticism of the binary protocol on the BK load.
It's true that a straightforward ASCII protocol like SCPI is easy to understand and code for the simple case. But the problem is, it has no error checking.

ASCII protocols are fine for simple test automation (like this example) where the results aren't critical and the worst they can do is give you a spike in the graph or a missing sample - easily detected by eye. But what if you're building an ATE system ? Where an error can hang the test (what happens if a CR/LF gets corrupted), invalidate the results or kill a part by overloading it. Where the cables are long. Where the electrical interference is heavy and intermittent. Try and write a reliable transport layer for an unchecked ASCII protocol and you'll be tearing your hair out and wishing for a packetised binary protocol, because your ATE is rejecting good parts every time the fork lift drives past. 

Lack of error checking has worked fine for the entire GPIB automated test industry for 40 years.

[rs20]

I found the reaction to the binary protocol a bit odd as well -- I mean, David2 was saying something about C unions (why not this?) -- there's a single page of trivially translatable Python provided in the manual! Now to be clear, that's a function or two that you wouldn't have to write/translate if it was ASCII, and they should have probably just used ASCII. I agree with that. But this terrified fear of binary!? It's like you've never used an SPI chip! That's an extra couple of functions to write, a minute or two, not a spit-the-dummy, completely-give-up-and-use-a-completely-different-device point! At least, that's not how I would have reacted.

Having said all that, I might be a bit weird in this respect. I really enjoy coding SPI protocol stuff on uCs, so maybe I'm the weird one.

It's also noteworthy that the manual links to a python library you can download which gives you functions like SetMaxCurrent; you don't even need to think about protocol at all. A nice touch, and awesome for anyone who's willing to touch Python (normally not me, but I would for this particular project).

It's true that a straightforward ASCII protocol like SCPI is easy to understand and code for the simple case. But the problem is, it has no error checking.

Aren't ASCII-vs-binary and checksummed-vs-not completely orthogonal questions? For instance, the standard GPS protocol (NMEA 0183) is ASCII, but has a checksum. Why not just tack a checksum on the end of each ASCII line?

[thewyliestcoyote]

Lack of error checking has worked fine for the entire GPIB automated test industry for 40 years.

While true, (Data pin number 8 was sometimes used as a  parity http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm)
and there is nothing stopping you from doing checksums over GPIB.
I think what they where trying to do is implement for some odd reason the data checking. Maybe they where trying to be forward thinking and have this handled by some driver layer? and just never got around to it.

Now that the world has moved on form GPIB and has USB and Ethernet. Checksums are build in and are handled by the driver layer. YEA FOR ABSTRACTION!

This may also be because they think that they could be handling data that is not just ASCII lines terminated with a line feed.  Imagine asking a instrument for a big long binary array while you are used to handling ASCII. There is some chance(small chance) that in that binary data that it also could form a ASCII string. Now imagine (small change) that the found ASCII string could mean something else. Lets say something like "Incoming ICBM!". That is not the ideal problem to have in you system. I know that is stretching it but I hope I have made my point. Another example is the differentiation of preamble structure with the data can form to reduce false detections.

There is a ok python library for the BK loads from BK,
Maybe you should give that a try.
I have and I was not over flowing with excitement,

[artag]

Lack of error checking has worked fine for the entire GPIB automated test industry for 40 years.

But GPIB is not RS232, although many instruments with both used the same ASCII protocol. GPIB has per-byte flow control (so no overruns), heavy duty line drivers, short cable lengths and can have per-byte parity. It's far less likely to be corrupted than RS232 and far more likely that an error would be detected and notified to the application (RS232 drivers in the OS tend to just ditch any characters with errors). The vast majority of ATE installations use GPIB with RS232 only when necessary.

[artag]

Aren't ASCII-vs-binary and checksummed-vs-not completely orthogonal questions? For instance, the standard GPS protocol (NMEA 0183) is ASCII, but has a checksum. Why not just tack a checksum on the end of each ASCII line?

Yes, they're orthogonal. ASCII on RS232 is a lot better if it has a checksum. Better still if it has a unique framing character (though CR may qualify). But in this case the choice is between checksummed packetised binary and a typical SCPI style ASCII only - because the serial ASCII protocol is typically there for direct human interaction from a terminal.  if there's a need to put a checksum on the end then that's hard to do, because you have to calculate it for every line you type. Or use a utility to send the string, in which case it might just as well be in binary.

[artag]

I found the reaction to the binary protocol a bit odd as well -- I mean, David2 was saying something about C unions (why not this?) -- there's a single page of trivially translatable Python provided in the manual! Now to be clear, that's a function or two that you wouldn't have to write/translate if it was ASCII, and they should have probably just used ASCII. I agree with that.

C unions (and structures) aren't a great way to handle binary protocols either.  They have issues with packing, alignment and byte-ordering that have to be circumvented with non-portable #pragmas. The safe approach is what's used in library calls like htonl() - it seems clumsy but it works regardless of the platform. Old farts like me know this as the 'all the worlds a vax' error, now being re-learnt by people upgradiing from x86-32 to x86-64 to ARM.

I note that the C# library you linked to admits 'The output may differ depending on the endianess of your computer's architecture.'

[rs20]

Yes, they're orthogonal. ASCII on RS232 is a lot better if it has a checksum. Better still if it has a unique framing character (though CR may qualify). But in this case the choice is between checksummed packetised binary and a typical SCPI style ASCII only - because the serial ASCII protocol is typically there for direct human interaction from a terminal.  if there's a need to put a checksum on the end then that's hard to do, because you have to calculate it for every line you type. Or use a utility to send the string, in which case it might just as well be in binary.

Or, you implement a get-out-of-jail-free checksum (e.g. two hyphens always passes as a checksum ), or make checksums an opt-in thing that the host requests, or an opt-out thing that the human can use (e.g. error message = "Checksum failed. To turn off checksums, type 'CS OFF$e4'". Many many options other than the dichotomy you present.

I note that the C# library you linked to admits 'The output may differ depending on the endianess of your computer's architecture.'

My goodness, that's horrific! "Common Language Runtime", common except for endianess? 

[artag]

Or, you implement a get-out-of-jail-free checksum (e.g. two hyphens always passes as a checksum ), or make checksums an opt-in thing that the host requests, or an opt-out thing that the human can use (e.g. error message = "Checksum failed. To turn off checksums, type 'CS OFF$e4'". Many many options other than the dichotomy you present.

Good call.

[LabSpokane]

I'm with Dave. If you're going to give me an instrument interface, make it a standard and make it simple. When one has to interface to a gazillion different things, 232 is just simple to deal with.

[sakujo7]

But this terrified fear of binary!?

I'd argue that it's easier in some cases. Some ASCII protocol devices will unexpectedly switch between plain decimal and scientific notation, among other 'quirks'. At least with a binary protocol you ^hopefully know exactly what to expect.

Still, a device could be made to support multiple protocols at the same time such as by always starting ASCII commands with one character and binary with another. Then you can keep everyone happy.

[Kleinstein]

A constant power load gets unstable when the source resistance gets to high.
In addition here the load is likely using constant current load, updated a few times a second to get a pseudo constant power. At the end it's just not possible to get the 100 mW out out of the batterie.

It's somewhat obvious to find somt kind of brickwall end in a Alkaline cell: there is just no more zink left, or at least it's not connetcted to the contact anymore. The zink is normally just a pin in the center. The tricky part is to explain, why the no load voltage on alkaline cells goes down so much.

Its fun to look at the old "dry" cells in comparison: here the open circuit voltage is rather constant, but the internal resistance increases. There should not be such an brickwall empty point: if much of the zink is used up, the cells start to leak, but you hardly use all the zink.

At really low current, old cells can still run for quite a while: I have a battery backuped CMOS RAM as a CMOS emulator. It ran on a practically empty (to weak to drive a wrist watch) 3 V Li coin cell for more than 2 years. 

[manu]

Hello,

I made a simple arduino interface to BK Precision e-load. I own a 8510, hopefully it will work for the complete 85xx serie (8500, 8502, 8510, 8512, 8514, 8518, 8520, 8522, 8524 & 8526)
It simply outputs the display values (voltage in mV, current in 0.1mA, power in mW) in plain ascii. (cf. Arduino source in bk85xx.zip)
You can log data on a PC with a Hyperterminal-like software (e.g. https://sites.google.com/site/terminalbpp/) and save the data to a .csv file.
cf. the Terminalbpp and excel attached screen captures).
I just made it in a couple of hours, it hasn't been very well tested, so take it as-is.

The default sample time is about 1000ms. You might want to change the delay() value in the loop function but below about 200ms it think it will be too fast for the 9600 baud uart interface (see logic analyzer screen captures to have an idea of time response).
The time is displayed in ms with a 32 bit interger, so you cannot log more than 49 days... but I don't think a software will run this long on a PC without a problem...
To interface the BK e-load, I use a software uart on pins D7(Rx) and D8 (Tx), it can be moved on any available pins on the Arduino board (except D0 an D1 used for the uart-to-USB interface).

I didn't bother verify the checksum in each received frame, but if somebody minds to do it, I would be happy to have the code.
Also, it would be nice to have a command interpreter to set the e-load parameters, but, hey, it is easier to do it on the instrument itself.

Please tell me if this has been useful.

Manu