Battery Performance Tester

Stuff I am working on
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Battery Performance Tester

Post by Daniel Wee »

Okay, after what seems like ages, I've finally gotten down to getting this done. You know how there are all these brands on AA's on the market with all types of far reaching performance claims - this project gives you the bottom line. It tests, logs and compares performances and will give you the low down on which battery is better. Basically it is a controllable discharger and logger.

I happen to have some dsPIC33F128MC802 lying around which I've not used so I thought that it might be a good opportunity to press this into service. The idea is very simple - have a multi-channel high-res ADC going - while controlling the discharge using PWM. I also had some really really old MTP3055E n-channel FET's lying around and those looked just about right for this situation since the Vgs is about 2.9V. The difficulty here is that the single AA puts out around 1.2V to 1.5V when new/charged depending on the battery chemistry, and can go down to well below 0.7V. I wasn't sure if the FET would bias at such a low power, and fortunately for us it does. I think a higher Vgs would get me better conduction but we're driving it with 3.3V which is all we can manage. The dsPIC33F MCU's only run at 3.3V, unlike its' dsPIC30F brethren which can run up to 5V. In any case, tests show that we can manage up to 140mA discharge through a 1ohm resistor, indicating that we are getting at least 6ohms out of the FET but possibly better as the battery (although it should be 0.1ohms when fully biased, according to the datasheet). Part of that 6ohms is also the battery's internal resistance.
IMG_0927a.JPG
IMG_0927a.JPG (262.98 KiB) Viewed 21831 times
IMG_0928a.JPG
IMG_0928a.JPG (268.6 KiB) Viewed 21831 times
IMG_0930a.JPG
IMG_0930a.JPG (220.41 KiB) Viewed 21831 times
IMG_0933a.JPG
IMG_0933a.JPG (192.51 KiB) Viewed 21831 times
IMG_0934a.JPG
IMG_0934a.JPG (180.59 KiB) Viewed 21831 times
IMG_0936a.JPG
IMG_0936a.JPG (200.05 KiB) Viewed 21831 times
I tried adding LED's to the gate driver lines but the voltage drop seemed too much and resulted in a significant drop in bias levels so I'm leaving that out for the moment. May try again with higher resistance values for the LED's - say 470ohms or 330ohms.

Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

I think, in order to get the FET to conduct harder, I will have to use an FET with a lower drive requirement so I'll be trying out a different FET. This, together with the change in the LED resistor value, should mean that I can get the channel drive LED's working without losing drive ability with the LED's. This should be interesting.

It also appears that I have enough pins (thank goodness for user assignable pin-functions) to squeeze in an I2C port - which means I can get an LCD in there if I want to. I'll have to think about the drive software though, but this will wait till I've got the rest of the software working.

Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

Component delivery FAIL

Well, I took delivery of the components this afternoon and happily swapped out the 220ohm resistors and put in the 1206 sized 330ohm resistors instead so that the LED's are now not blindingly bright. I also pulled the MTP3055E's and replaced it with the STP36NF06L logic-level MOSFET's, or what I thought was the STP36NF036L's. Upon powering up, the channels with the MTP3055E's in place had the LEDs lit and the new transistor channels had dark LED's. This was puzzling since FET's are voltage driven and have high-impedance gates which should not affect the LEDs. If anything, it should be the LEDs affecting the gate. A quick measure of the current draw shows that it seems to be working - and I am getting increased current draw - up to 450mA from 150mA so something is working. Measuring the gate voltage revealed just under 0.7V. I was thinking - huh? - that looks like the bias voltage of a bi-polar transistor, and yet the circuit seems to be working. The leakage current in the drain is pretty high though - 24mA. So I decided to take a closer look at the part - you know, with a part number like STP36NF06L, you don't really want to look at the part but I had to and could not see anything resembling this cryptic part number. Instead I saw BUL128A printed all over it and decided to Google it. As it turns out - the BUL128A is an NPN power transistor, which, by sheer coincidence, shared the correct pin-out so that it could drop into the FET position and still work as a common-emmiter driver. That explains the dark LED, the high leakage current, and why I had to pull out the BUL128A's as I wait for the correct part to be delivered (next Monday hopefully.) The lesson learnt here is that you can't always trust what it says on the packaging and delivery errors do take place so always check. I got lucky this time but maybe not so the next. Here's a photo of the casualties:-
IMG_0943a.JPG
IMG_0943a.JPG (221.66 KiB) Viewed 21824 times
With that saga behind me, I set about working on the PWM drivers for the MOSFETs. We have four output compare channels (OCx) and some PWM channels that we can use to control these channels. Fortunately, this particular MCU allows user mappable pin functions and with that, I mapped the four OCx peripherals to the appropriate pins, and had to rely on one of the PWM channels to account for the fifth driver channel. This should work in theory, and after an afternoon's worth of coding - they appear to work pretty well. This will now allow us to present PWM driven loads to the batteries. What we need to do is to linearize the duty-cycle to the resistance of the load so that we can present a constant current load to the batteries if we want to. This cannot be done without the new MOSFETs though so it will have to wait until Monday.

Meanwhile, I calibrated the ADCs against my Fluke 289 DMM so we're within 0.005V for accuracy. The I2C LCD also arrived today and I think we might be able to stuff that into the circuit. The thing here, though, is that the I2C isn't among the mappable peripherals and the default SDA and SCL lines are currently mapped to the UART1 I/O lines. This isn't much of a problem really since I can just re-map it easily. Again, we seem to be running some good fortune here in that the SDA1/SCL1 and the alternate pins, ASDA1/ASCL1 happen to be uncommited other than to the UART and the PGD/PGC. In fact, due to the nature of I2C, I could probably just tap it off the ASDA1/ADSCL1 lines without affecting the ICSP function. I may need to add some weak pull-ups on those lines though so we'll have to see how this pans out.
IMG_0945a.JPG
IMG_0945a.JPG (239.89 KiB) Viewed 21824 times
Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

Okay, after a titanic struggle and two days, I've managed to get the I2C working with the LCD (PCD2119x). Turns out that the pull-ups needed to be tied to the 5V (LCD side) supply rail rather than the 3.3V MCU rail. This wasn't clear in any of the datasheets but it solves the problems I've been having. After that I had to figure out what exactly the manuals are trying to say, and get through the mis-information in the datasheets. To cut a very long story short - I am now able to print what I want and where I want, on the LCD. In order to do this, I had to:-

1. figure out that the I2C address provided in the datasheet was wrong
2. figure out the correct I2C communications protocol which was lacking from the datasheet
3. figure out a way around the non-standard character set ("R") that was in the CGROM

There is still a bit of a mystery in that the I2C baudrate doesn't appear to be spot on but that could be due to a number of things. Instead of 400kHz, the scope is saying 354kHz or so. I'm wondering if this means that I've got the wrong primary clock selected but for now I'm just leaving this alone.

I had to hack together a driver for the LCD backlight but that was a cinch, plus I still have a line or two to spare so things are looking good for now.
IMG_0951a.JPG
IMG_0951a.JPG (222.89 KiB) Viewed 21823 times
I also wrote some higher level functions to control the PWM duty-cycle which made for some rather pretty LED effects. Adding the LED to the line drops the 3.3V logic to about 2.9V or so and this was enough to mess things up with the MTP3055E's. I'm hoping that where the STP36NF06L's are concerned, the lower Vgs requirement would allow the light-show to continue unabated. Otherwise we will have to sacrifice the lights for functionality.
IMG_0949a.JPG
IMG_0949a.JPG (273.04 KiB) Viewed 21823 times
Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

I changed the LCD backlight pin over to one of the PWM controller pins and now I have PWM on the LCD backlight, which allows me to dim the light as much as I want. Pretty nifty but involved moving the wire and a few lines of code.

I also moved the voltage reader to an ISR so that it takes place at 10Hz. The RTC routine is also running in that same ISR so we have time now.

Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

Well, the correct MOSFET finally arrived today and they went into the board without any hassle and performed as expected - which is far better than the MTP3055E, plus the LEDs all continue to work. A quick test shows that at full-conduction, it exhibits a resistance of about 0.18ohm with an Vds presented by the DMM (which is probably 3V-unloaded or less). There are several things learnt in trying to get this configuration going.

First of all, it is good to have the ADC sampler running as fast as you can get away with, relative to the PWM rate. So I lowered the PWM rate to 1.3kHz (which is as low as it can go with this timer and divider setup), and upped the ADC sampling rate to 10kHz. This seems to yield fairly accurate readings from the ADC, comparable to the DMM.

Secondly, I had to correct the reference voltage from 3.3645V which is what is measured off the AVdd and AVss pins, to a slightly higher 3.371V. This yields the most accurate readings possible from the ADC down to 0V.

Thirdly, I found that Rds doesn't seem to scale well with the PWM duty-cycle. This could be due to the DMM being unable to sample the resistance properly. The physics of it would suggest that they scale normally but this isn't what is being measured. For example - with a duty-cycle of 66.7% and the above-mentioned PWM frequency, the DMM is reading about 411ohms. With a much higher PWM frequency, it was reading 10ohms. Consequently, we may have to resort to some other means of actually measuring the Rds, or more importantly, the combined Ids.

Fourth, we also found that the load resistors (1ohm) seem to have a fair bit of error - ranging from 1.12ohms to 1.08ohms. This means we're looking at a +12% error margin - which is a whole lot for this application. The question is if I should bin the resistors for lower error or rely on PWM to make up for it.

Meanwhile, I am putting a very low PWM duty-cycle on unoccupied channels to drain of any residual charge or charge build-up. This makes for nicer looking readings and negligible impact on performance. The DMM reads over 2.7kohm at this reading so we're talking about a drain of only 0.55mA or so in the worst case scenario. Additionally, the circuit detects if there is a battery in the holder and if so, it will present a full-off condition so there is in fact no drainage at all.

Lastly, the PWM channel (5) behaves a little differently from the OC channels (1-4). There is some minor phase difference, and a slightly higher Vgs for that channel. As of now, I am not too sure of the seriousness of this variation but using channels 1 to 4 would be preferred wherever possible.

Our biggest challenge at this point would be to equalize the load and to build up a table so that we know what load is being presented to the battery being tested.

Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

We're almost there. I've managed to solve the voltage jitter with aggressive MA filtering (in addition to the LPF and 1uF smoothing cap). In any case, it is pretty smooth now, even when being fed with a noisy test voltage (from the switching power supply under load). This results in a very slow response time (about 4secs) but should be sufficient for our application. The 1uF cap is a bit disconcerting though since it holds a charge for so long that battery removal is often not detected for many seconds. I might remove this later on. For now, though, thing are working right.

The battery detection routine works, as do the loading functions and the voltage measurements, which is pretty accurate right now. The hardest part was calibrating the PWM. At the current 1kHz frequency, I am getting about 0.01% duty-cycle accuracy. The hard part, though is that I don't have a variable linear and stable source voltage to measure the effective resistance of the load. I think we're probably within 1% but I would like to see much less than that. The key here is having a stable source that can deliver at least 1A with good regulation.

The next things I have to do is to write the data-dump routines, the serial terminal interface, and to improve the LCD UI a little bit (including use of the backlight). I'll probably mount the whole thing on the base board before that though, to minimize damage to things.

Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

Okay, the serial interface code is done, for the most part. In fact, just about everything is done except for fine calibration. I also managed to mount the whole contraption onto a board - not pretty but gets the job done so I'm fine with that.
IMG_0966a.JPG
IMG_0966a.JPG (201.5 KiB) Viewed 21793 times
IMG_0973a.JPG
IMG_0973a.JPG (230.79 KiB) Viewed 21793 times
IMG_0974a.JPG
IMG_0974a.JPG (254.14 KiB) Viewed 21793 times
Serial-CLI.jpg
Serial-CLI.jpg (115.28 KiB) Viewed 21793 times
Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

Dang! Another failed capacitor. This is perhaps the third time that a capacitor came out as shorted. No wonder the batteries on CH4 kept dying so fast. In any case, this really calls for a whole new round of calibrations.

The software looks quite complete now but the first sample test produced a rather erratic discharge curve.
First-Test.jpg
First-Test.jpg (82.5 KiB) Viewed 21778 times
We can see clearly the problem with the additional load in channel-4, from the shorted capacitor. Channel-2 seems to be suffering from some issues as well and needs to be looked into. This could well be from bad contacts as there was some oxidation at the contacts that we did not see before starting the test. Bad contacts should not, however, lead to higher discharge as seen from the curve but it could be simply lower voltage. We're going to use a lower threshold to see if we can get rid of the fluctuations, and maybe add some hysteresis to the cycle.

Daniel
Daniel Wee
Site Admin
Posts: 2449
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: Battery Performance Tester

Post by Daniel Wee »

I've decided that the simple first order conversion equation just isn't accurate enough so I did another calibration matrix and applied a quadratic fit. The problem was we were going from PWM to resistance so we needed an inverse quadratic interpolation and I didn't want to use a look-up table so I resorted to a brute-force iterative method and that seems to be working fast enough. With this new conversion function, I am getting around 1% and better accuracy (probably better than 0.5%) so we're back to doing another discharge test at 2.0ohms with smaller steps to see if I am still getting the erratic voltage variations.

Daniel
Post Reply