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

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