November 2010

Gentoo/MIPS Progress update and LCA news

32-bit Gentoo/MIPS stages for both big and little endian systems are now available for MIPS-I, MIPS-III and MIPS-IV.  For now I’ve got these on my devspace, but I hope to get some of them out to mirrors as soon as possible.  I’d appreciate any feedback on this release.

The little-endian stages should work on Loongson systems.  All stages include a patched binutils binary (see bug #338405) which adds some fixes for errata in the Loongson 2F CPUs and the little-endian stages for MIPS-I and MIPS-III have this fix enabled in the CFLAGS, enabling their use on Loongson hardware.  They will also work on non-Loongson systems.

I’ve been doing quite a bit of testing with the little-endian stages in particular, and have had few problems with getting many software packages to work.

binutils-2.21 already includes the fixes needed, along with lots of other MIPS-related fixes… and so when that is released (they’ve already done a branch freeze for 2.21) I plan to build new stages based on this newer toolchain, and with the newer Perl release.  Current stages use Perl 5.8.8 since I found I hit a few snags at the time which I thought were better dealt with later (some package complained there was “something funny about this Perl version” and bombed out) as the primary concern for the Gentoo/MIPS port at the time revolved around gcc.

I downloaded and installed binutils last night, based on that day’s CVS snapshot.  I’m now trying to see if I can get qt-webkit to build (the biggest sticking point so far) using that, with the view of having a workable KDE-based desktop going on the Yeeloong and the Fulongs here before LCA 2011.  (For now I’ve got FVWM.)  In the meantime I’ll be keeping an eye on the binutils mailing list.

On the LCA front… I got formal confirmation of my payment on the weekend… so I’m definitely a go-er… I’m still trying to find out if I’ll be helping out with any stalls…

There’s a social meeting of the Brisbane Amateur Radio Club this Friday, wherein our involvement in LCA will probably be discussed — club president was supportive of the idea when we discussed it on our 2m net last Wednesday evening… we just need to figure out what we can do, who can do it, and what needs to be done.

I’ve managed to get fldigi going on Gentoo/MIPS, and so maybe interfacing one of the computers I have (either one of the Fulongs or the O2) to a radio transceiver… (perhaps one of the ships’ radios on the HMAS Diamantina… nice mix of old+new-er) decoding some RTTY or PSK31, is an option.  We’ll have to decide this formally.

Those who wanted to drop in… we meet at the Queensland Maritime museum this Friday (and every second and fourth Friday except fourth in December and second in January) at 7:30PM — entrance is via “Service Gate 2” off Lower River Terrace.  We meet in the lunch room under the bridge.  If anything is decided, we will likely make our final decision at the following business meeting, which happens a fortnight later.

BARC Meeting entry point

BARC Meeting entry point... via Service Gate 2 off Lower River Terrace

If Gentoo has a stall, it’d definitely be worth setting up one of the Fulongs there… and for that I’d want a reasonable desktop going (KDE, or maybe XFCE… I know people have done some stunning work with FVWM, but I’m not that good).  I look forward to LCA regardless… if neither Gentoo nor BARC are running a stall in the open day, then I’ll just have a look around and see what it’s all about.  I look forward to the event anyway. 🙂

Battery management system musings

One thing I do enjoy is bicycle mobile operation… that is, operating the radio whilst traveling on the bicycle. One significant barrier to this is battery life however.

So far I’ve stuck with 13.8V 9Ah gel cell batteries. These are far from ideal, but are pretty good for the price. They are lighter and cheaper than an equivalent capacity NiMH or NiCd pack, however one downside is that they do not take too kindly to deep cycling.

When I first started my work at Jacques Electronics, I found one battery would get me there and home again, with capacity to spare. I’d have one at home charging, and the other on the bike.

This was with plenty of activity on the 2m band, transmitting full power on the FT-290R II. Given this radio has a 25W linear amplifier, this represents an approximate 4A load when I went to transmit.

Towards the end of my time there, I noticed the capacity had been significantly reduced. A combination of road vibration and deep cycling had reduced the capacity to the point that I now need to take two batteries with me.

So once again, I’m looking around. They seem to go for about 6 months before they start to fail… and we’ve already got a big collection of dead gel cell batteries ready for recycling… something has to change.

Lithium Iron Phosphate (LiFePO4) is what I’m looking at. Now, there’s a choice… do I go for pre-made packs? Or do I homebrew my own out of cells?

For the latter to be an option, I must consider how I’ll balance them properly. These cells are expensive and not very forgiving (although they’re better than Lithium-Cobalt or Lithium-Ion Polymer cells). What follows is some thoughts on how to construct such a battery management system… which could be completely wrong… so don’t take this as gospel.

The mission

To construct a battery pack to replace the 13.8V 9Ah gel cell packs, using Lithium Iron Phosphate technology. The battery may develop a maximum voltage potential of 15V DC, and must provide at least 9Ah effective storage capacity.

Cell count dimensioning

Looking around, the literature I can find suggests the typical LiFePO4 cells have an operating voltage between 3.2 and 3.6V. Therefore, to obtain 13.8V, I’d need four of them in series… producing 12.8V to 14.4V.

The cells themselves come in various capacities… some I can get easily are K2 Energy 26650EV cells. These pack about 3.2Ah per cell… EVWorks sell them for under AU$8 when you buy 10 or more. If I’m to use those, I’d need 3 cells in parallel to give me approximately 9.6Ah.

Total number of cells: 12, at $7.15 a cell: AU$85.80 for a 4S3P pack.

“Ideal” cell balancing

Now, the best way I can think of to balance these things, is to do it on the individual cell level. To maintain maximum life of an individual cell, one must ensure that when charging, the cell voltage does not exceed 4.2V. When discharging, the cell voltage must not fall below 3V.

There are also factors such as current flow, cell temperature and age. However, for simplicity’s sake, we’ll consider only the voltage for now.

Given these restrictions, it would seem wise to break apart these two actions, and consider them separately.

Charging

The desirable feature when charging an individual cell, is that the cell voltage itself is prevented from exceeding 4.2V. This is of great importance with some Lithium type batteries, as the cells can explode.

My first instinct is to look at zener avalanche breakdown in diodes. A zener diode in reverse bias will continue to reject current flowing through it until such time as the avalanche voltage is exceeded. Then it begins to conduct, and the voltage drop across it will always be equal to the avalanche voltage… given sufficient series resistance.

This sounds like the sort of behaviour we’re after. So the input circuit becomes something like this:

Therefore we look for a zener that has the avalanche voltage close to (but below) the 4.2V needed. Bad news is, there isn’t a 4.2V zener, we can go 3.9V… a little too low, or 4.3V, a little too high.

By adding an otherwise gratuitous 1N4004 diode between zener and battery, we can utilise a 5.1V 1N4733. Due to the forward voltage drop of the 1N4004, the battery will only see voltages up to 4.0V despite the higher zener voltage.  When the battery is below this voltage, it will charge with a current decided by Rlim.

This circuit certainly won’t fast-charge a big pack… but in my case, an overnight charge is quite acceptable. The individual Vcharge+ and Vcharge- are wired in series to charge all the cells from a higher voltage supply, and the strings themselves may be wired in parallel.

Discharging

All good and well, but what’s the point of stuffing a battery with charge if you’re not going to take the charge out at some point? The other side of the equation is discharging.

The magic number to beware of, is 3.0V… drop below that, and the cells will be irreversibly damaged. The same tool, the zener, can be used to detect when the battery is low. One trick we can do is to swap the zener with the resistor normally placed in series with it. The zener will still have its avalanche voltage across it, the resistor’s voltage now indicates the state of the battery.

V_{Low} =  \begin{cases}  >0 & V_{cell} > V_z \\  0 & V_{cell} \le V_z  \end{cases}

If we pass this through a NPN transistor, we wind up with negated output that can directly drive two MOSFETs. One MOSFET will permit the current to flow only when the cell voltage is above the zener avalanche voltage. The other, will shunt current past the cell when the voltage of the cell is too low.

All good… but the MOSFETs would want to be capable of delivering about 20A continuous for my needs. An IRF9540N could do it with a heatsink. That’s not so much a problem, but the cost is. Each MOSFET costs about $5 locally… so there’s $10 per cell, 12 cells… $120 just in MOSFETs… the BMS will cost more than the cells!

Reducing costs

The charging side is fine, however the discharging aspect of this system is going to be too pricey for my liking. So a re-think is needed.

The same current that would turn the NPN on, could instead turn on the LED in an optical isolator. An optical isolator incorporating a NPN transistor would then pull down on a resistor when the cell voltage is above the zener avalanche voltage.

In this circuit, when the battery voltage is high enough, the optical isolator is active, pulling the NPN’s base low and leaving VnLow floating.  All modules’ VnLow signals would be wired together, forming a wired OR with the open collectors.  When a cell gets below voltage, the LED turns off, causing the isolator to turn off and the NPN’s base to rise.  It then turns on, and pulls VnLow down.

This signal with a suitable pull-up resistor can drive a NPN transistor for driving a P-channel MOSFET, so that when VnLow gets pulled low, the load is disconnected and an alarm raised.

This BMS, while undoubtedly not as good as the previous option, would provide the low-voltage protection, and can be made for under $50. I’m curious to know how others’ have tackled the problem though. This is how I’m thinking of approaching it… I may just buy a premade pack instead.