EV Battery Tester

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).


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.

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

3 thoughts on “EV Battery Tester”

  1. 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:
    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. Hi Michael,

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

    – David

  3. This is a great example of a Do It Yourself application that any engineering-savvy EV battery end user could set up to satisfy their curiosity. As a comparison point, several similar, but more involved, levels of testing need to performed by EV and HEV battery developers. Of course, testing done in these development and manufacturing environments is performed with more advanced automated equipment than that outlined here, but this is still a great home battery test application!
    For HEV/EV battery development, the first level of testing needed is to evaluate the performance of the individual Lithium Ion (or other chemistry) cells themselves to evaluate charge/discharge characteristics, energy density, and thermal behavior of a particular cell chemistry.
    The second level of testing is evaluating the BMS, that is, the Battery Management System circuitry that monitors the state (voltages, temperatures, etc) of individual battery cell modules and of the full battery pack as a whole, and handles functions like cell balancing. Correctly performing this these tests involves simulating and controlling all inputs the BMS encounters in normal vehicle operation, subjecting it to any possible conditions it would encounter in the real world, and making sure it responds correctly in all cases.
    An example of this approach can be found here:
    The third level of testing is to validate all functional and performance characteristics of the battery pack as a whole (ie once the cells have been fully assembled into the completed pack that will go in a vehicle). This includes testing the diagnostic (CAN) communications between the pack itself (from the BMS) to the vehicle’s Engine Control Unit (ECU) or On Board Diagnostics (OBD) system, testing all internal electrical components and wiring (expected isolation voltages, path resistances, capacitances, etc), and other pack functions like contactor operation, safety interlocks, etc. It also involves performing high power cycling of the pack to simulate actual real world drive profiles to determine qualities like the battery’s energy capacity, which in turn is directly related to the vehicle’s range it can travel on a single charge. An example of an automated test system for this level of testing can be found here:


Comments are closed.