EV Battery Tester

June 30th, 2009

I am interested in testing my my EV batteries - for example to measure the effects of various charging strategies. So I dreamed up a system using a WRT54G router and my little $2 PIC based voltage and current sensor WISPCAR board from last year. The WISPCAR board senses voltage and current and sends them out a RS232 port at 4800 baud. It also has a watchdog timer, and costs about $2 to make.

With our recent Mesh Potato work I have routers and serial ports on my mind. I have also been in touch with Bart from the Flukso Project who are using routers to monitor home power consumption - another area I am very interested in.

Routers are cool data collection devices. They are essentially mini-Linux systems so you can so all sorts of clever things like use shell script and connect them to the Internet. They usually have unused serial ports (WRT54GL’s have two) and often a few GPIOs. Best of all they are wireless - so you can start a test running then monitor it from your laptop some where else in the house. It’s “a good thing” to monitor battery tests like these as the power levels involved are substantial and there is the possibility of expensive battery damage.

I connected the WISPCAR board to my PC via a RS232 cable and it worked first time, even though it had been a year since I last used it. Despite surviving in my junk box for that long I promptly managed to blow it up in about two hours, I think I put 12V into one of the PIC A/D ports. Oops. The prototype was built on veroboard which was painful to flip over all of the time. So I rebuilt in “Manhatten” style so all the parts were on the top. Pretty, isn’t it!

Finding an 40A Load

To test my EV deep cycle batteries I wanted a load of around 40A, as that is the 60 km/hr “cruise” current of my EV. Finding a way to discharge batteries at these sorts of currents is not as easy, for example you would need at 0.3 ohm 480W resistor. It’s also nice if the current stays constant for the duration of the test, despite heating of the load and the battery voltage changing from 12.5V to 11.5V as it discharges.

I used a suggestion from the EVDL - a couple of 300W 12V to 240V inverters. I scurried around the house for a few hours, trying to find some 240V devices that were in the several hundred Watt range. Hairdryers, curling wands, and bedside lamps mysteriously disappeared from the house, only to re-appear on my bench in the shed! Finally I settled on a couple of bedside lamps with 60W bulbs, and an oil filled electric column heater connected to a Variac. The Variac allowed me to finely adjust the current to get exactly 40A. I measured the current using a 100A shunt connected to the battery (1mV/A).

Software

I modified the PIC assembler code just slightly. To avoid over discharging the battery I wanted the watchdog timer to stop the test if the router should fail to poll the PIC every 20 seconds. Normally the watchdog drops the power for a few seconds, then restores it, to reset the device it is monitoring. The watchdog controls a 12V/40A automotive relay that can stop and start the test under control from the router.

It’s possible to connect WISPCAR directly to a PC using a RS232 adaptor, this is how I did most of my development. So the router is not really required, I just felt like doing it that way to explore the idea.

Getting the WRT54GL router serial port to work correctly was tricky. I couldn’t get the first serial port to change from 115000 to 4800 baud using the stty command. Every time I set it some other piece of software set it back! This port is configured as the serial console, however the second RS232 port on the router was free and I had better luck changing it’s baud rate to 4800.

To make WISPCAR work I needed to send commands and log data from the WRT54GL serial port, preferably under the control of shell script so I didn’t have to write and cross compile any C code. A few hours of head scratching and Googling led to this solution. To write a character to the serial port:

echo -n 'w' > /dev/tts/1

This command resets the watchdog timer and prompts WISPCAR to send a line of data. This data is read like to a file called “w” like this:

dd if=/dev/tts/1 bs=1 count=36 1>w 2>/dev/null

Good old dd to the rescue. I initially tried:

cat w < /dev/tts/1

but it wouldn’t send me the line until the sending device sent a Ctrl-D (end of file). In practice you start the read line first then send the command to wispcar:

dd if=/dev/tts/1 bs=1 count=36 1>w 2>/dev/null&
echo -n 'w' > /dev/tts/1

Each line is exactly 36 bytes long and contains some status information plus the voltage and current A/D samples. From then on it’s easy for shell script to extract the voltage and current samples and save them to a text file with a time-stamp. The shell script also monitors the voltage sample and stops the test at a certain threshold.

The text file output is easy to grok and plot using Unix tools like cut and Octave. Or the text file could be imported into a spreadsheet if that’s your thing. As the discharge current from the inverters is very stable, the AH capacity of the batteries can be calculated from the time the test ends. Here is a sample output plot.

Note the rough shape of the graph. Part of this is sampling glitches - electrical noise (perhaps from the inverters) upsetting WISPCAR as it samples. The chunky step size is due to the 8 bit resolution of the PIC A/D, that works out to about 1 bit/100mV which is a little coarse for this application. However even with this noise the system is effective in measuring the AH capacity of the batteries - the main goal of this work.

WISPCAR Hardware Mods

To reduce the sampling noise I made a few hardware changes. Here is the latest schematic. To the current sensor I added a capacitor to roll off the bandwidth at 10Hz and effectively reduce the gain for any high frequency noise signals. I lowered the resistor values in the Voltage sensor divider to lower the impedance and reduce the impact of any induced noise. I also added some filtering capacitors to lower the frequency response to about 10Hz. This removed most of the glitches for the next few tests:

Note this test starts at 13V - the battery had just come off charge. This discharge time (and hence capacity) is the same as the first test plotted above with the same battery.

A further improvement would be a higher resolution A/D or a way to just sample the 13-10V range, at the moment much of the A/D range (for example 0-10V) is never used and hence wasted.

The current sensor wasn’t really needed as the load current stayed constant. However I would like to work on that some more one day - it seems to have some problems I don’t quite understand like offset error (I am weak on op-amps). The ideal circuit would amplify a mV level differential DC signal (e.g. 40mV from the shunt at 40A) up the the 0-5V range of the A/D in the PIC. It has to be differential as we are sensing the current on the “high side”. Note the + current sense wire must be separate to the 12V power lead to avoid power to WISPCAR flowing thru the current sensor wires and inducing an additional voltage offset.

Going Further

There are many applications for the combination of a $2 PIC circuit and a router. So far I have used the combination for monitoring a solar power Wifi station and testing EV batteries.

This system could be simplified a lot to make it friendlier for the non-Linux geek. For example the router could present the battery discharge data as a web page on it’s internal server or even generate graphs. The test cut off threshold could be set using a web-based GUI.

Links
Original WISPCAR post
WISPCAR SVN containing schematics and source code files
David’s EV Page
Flukso Project

2 Responses to “EV Battery Tester”

  1. Michael "Amberwolf" Elliott Says:

    I found this page via the EVDL posts on DIYElectricCar forum. I like this idea. If I can find the PIC you used in something I have around here that I can recycle, I will probably try this out–I’d love to know what the batteries I get will do before I go test them out on the bike and get stuck somewhere due to a miscalculation. ;)

    This is a good PDF I found via google of many basic op-amp circuits:
    http://ecow.engr.wisc.edu/cgi-bin/get/ece/340/schowalter/opampckts.pdf
    All of the ones I’ve ever used are in there in one form or another. :)

    Now, as for getting that usable range on the ADC to just use the 10-13V area, you need to offset the voltage downward first, then scale it up (amplify it) so it fits in the full range of the ADC.

    There should be enough extra op-amps on that LM324 you’re not using to do it.

  2. david Says:

    Hi Michael,

    Yes one idea to offset the voltage in a stable, repeatable fashion is with a voltage regulator.

    - David

Leave a Reply