Oct 292016

So, I drag the cluster, battery and 20A charger out to the deck to do a full load test. This is the first time I’ve fired this newly built controller on a full load. Uncharted territory so far.

Here’s the set up.

The charge controller that I built earlier is in a nice shiny re-purposed case that I had laying around. Just the right size too. These were USB extender devices that my father’s workplace had used in a project: they wanted the innards, so we got the empty boxes. I just mounted the PCB on a small piece of plastic to insulate it from the case, and routed my DC leads out through a hole in the case originally intended for an RJ-45 jack.

At this point, everything is humming along fine. Our battery charger is on stand-by.

The meter is showing a sedate 12.4V and the controller is happy with this. That said, I’ll have to work on the visibility of those LEDs. The two on the power MOSFET control lines are off at this stage.

So I give the system a bit of curry. I transfer a copy of a Linux kernel git repository to each, tell them to update their working copies from that, and build a version of kernel v4.8.5. This made the current jump up to about 10A. So far so good, the battery is holding.

Then, about 30 seconds in, the controller decides it’s a bit too low, so it kicks the charger on. There’s a few false starts, as the charger delays its start-up a bit. Eventually though they get into sync and start charging. At this point, the charger is taking the load of the battery and the cluster.

Great. So it continues for a minute, then decides it wants to shut down, which it does, followed by a moment of oscillation. It seems the controller is too impatient for the charger, waiting for the power to come on…but then… what’s that smell???

Oops, guess that MOSFET got just a little too hot. I was hoping to avoid the need for heatsinks by over-dimensioning the MOSFETs. These are supposedly able to take 70A, I realise that’s with a heatsink, but I thought that at 20A, they would be able to handle it.

One somewhat roasted MOSFET says otherwise. Interestingly, only one has visible marks, its mate looks okay, but likely isn’t.

The MOSFETs don’t have to be mounted directly on the PCB, we can re-locate them to where we can squeeze a heatsink in if I can’t get one in between the two already. The thought was each pair have a heatsink in between them. More pondering to do it seems.

Oct 232016

So, late yesterday afternoon, I devised a light test of the controller to see how it would perform.

For this I disconnected all but one of the nodes, and hooked up one of my old 10Ah LiFePO₄ packs and my 3A charger hooked to mains. The LM2576-based charger is just able to hold this load and provide 1A charging current.

The first thing I noticed is that the fan seemed to turn on and off a lot… this could be a difference in the temperature sensors between the DIP version of the ATTiny24A that the prototype used and the SOIC version which the new controller used.

The test ran overnight. The node basically was idling, as were the two Ethernet switches. But, it served the purpose. I now know the logic is sound, although I might want to adjust my set-points a little.

That’s the output data from a small digital power meter that was hooked up in circuit. This device is unable to display negative current, so the points at which the battery was charging is shown as 0A. Left axis is voltage, right is current. You can see that the charger gets brought in when the battery dips below 12V and clicks off just before 13.2V.

I can probably go a little higher than that, maybe about 13.6V. I may also need to re-visit the fixed resistor settings on the linear regs inside the nodes to knock them down a few more pegs to prevent the BMCs whining about the high voltage.

Next weekend, I might consider hooking up the 20A mains charger and giving it a full load test.

Oct 222016

So, I ordered the parts last weekend and over the course of the last week, they arrived, in three dispatches.

Might’ve been cheaper for RS to wait for the lot to arrive, I’d have been happy for them to do that had they asked, but never mind, they all turned up. So today, in clouds of solder smoke out on the back deck, I set to work soldering up the first of these boards.

At first, I just put all the SMD parts on, the programming header, the 5V reg, and the DC input lead. This proved a little fun. When I ordered the parts, I had initially put a lot of resistors, all 0805 size, to fill some of my stock. Then I took some off the list because I was over budget a little. Murphy dictates the ones that you take off are the ones you need.

I had thought I had spares anyway… turns out those were 1206s. And, in a pinch, one can use 1206 size resistors on an 0805 size footprint, or at least the “hand-soldering” variants that Kicad produces. The 10k pull-up resistors used on the MOSFETs and the 47k pull-up on the reset line are all 1206s, and they fit okay.

Had I remembered I had 1206s not 0805s, I’d have used 1206s. They’re a little friendlier to work with.


  • always check the list before hitting the order button!
  • In a pinch, you might be able to squeeze a 1206 onto an 0805 footprint, but don’t bet on it!

The other thing I could have done better would be to nudge the footprint for the 7805 along a little so that the switch-mode alternative part (ROHM BP5293-50) would fit. Better yet would be to not be so darn lazy and actually make a footprint for it. It’s a little cosy, but it snuggles up nicely against the capacitor.

Similarly, slightly bigger holes for the power connectors would help too, although the pins on the MOSFETs aren’t exactly big and they’re supposed to handle 70A. The lead length is short though, so not much resistance, I’ll probably get away with it.

The LEDs also proved a challenge, namely figuring out which way around they went. Most were all Osram CHIPLED parts, had a milky-white lens, and no markings visible on the top (one nondescript marking on the bottom), so it was difficult to tell anode from cathode. I wound up using my electronics kit to supply 4.5V through a 1k resistor out to two wires (a twisted pair from some CAT5e) which I could touch to each side to know which was which.

The one exception was the batch of yellow LEDs I bought, Osram didn’t seem to do the yellow ones so wound up buying Kingbright ones, which featured two green dots showing the cathode (the “bar” end of the schematic symbol). When I run out of the existing stock of red, orange and green LEDs, I’ll get more like these I think as it makes life much easier.

This was shortly after programming, the code running on the board for the first time.

Seeing the LEDs blinking, I disconnected the board and proceeded to fit the remaining through-hole components. The resulting board seems to be making the right noises, turning the fan on and off in response to the internal temperature sensor, and running from a 9V source.

Now I guess I’ll wire up the remaining leads, hook it to DC power and see what happens.

Oct 132016

Well, today’s mail had a surprise.  Back about 6 years ago, I was sub-contracted to Jacques Electronics to help them develop some device drivers for their video intercom system.  At the time, they were using TI’s TLV320AIC3204 and system-on-modules based on the Freescale i.MX27 SoC.

No driver existed in the ALSA tree for this particular audio CODEC, and while TI did have one available under NDA, the driver was only licensed for use with a TI OMAP SoC.  I did what just about any developer would do, grabbed the closest-looking existing ALSA SoC driver, ripped it apart and started hacking.  Thus I wound up getting to grips with the I²S infrastructure within the i.MX27 and taming the little beast that is the TLV320AIC3204, producing this patch.

As the code was a derivative work, the code was automatically going to be under the GPLv2 and thus was posted on the ALSA SoC mailing list for others to use.  This would help protect Jacques from any possible GPL infringement regarding the use of that driver.  I was able to do this as it was a clean-room implementation using only material in TI’s data sheet, thus did not contain any intellectual property of my then-employer.

About that time I recall one company using the driver in their IP camera product, the driver itself never made it into the mainline kernel.  About 6 months later, another driver for the TLV320AIC3204 and 3254 did get accepted there, I suspect this too was a clean-room implementation.

Fast forward to late August, I receive an email from Jeremy McDermond on behalf of the Northwest Digital Radio.  They had developed the Universal Digital Radio Controller board for the Raspberry Pi series of computers based around this same CODEC chip.  Interestingly, it was the ‘AIC3204 driver that I developed all that time before that proved to be the code they needed to get the chip working.  The chip in question can be seen up the top-right corner of the board.

Universal Digital Radio Controller

Timely, as there’s a push at the moment within Brisbane Area WICEN Group to investigate possible alternatives to our aging packet radio system and software stack.  These boards, essentially being radio-optimised sound cards, have been used successfully for implementing various digital modes including AX.25 packet, D-Star and could potentially do FreeDV and other digital modes.

So, looks like I’ll be chasing up a supplier for a newer Raspberry Pi board, and seeing what I can do about getting this device talking to the world.

Many thanks to the Northwest Digital Radio company for their generous donation! 🙂

Oct 122016

So, after a couple of email enquiries, the truth is unveiled. As it turns out, Swiss Post send parcels via one or more transit countries which due to a quirk in their tracking UI, may appear as the destination.

Asendia were in touch last night informing me that: “Please kindly note that sometimes tracking website will show the wrong destination. Canada is only the transit country.” Ahh okay, no problem then. Confusing, but that’s fine. 🙂

I know now for later not to panic if it says Canada.

This morning, there was a surprise parcel arrived at work, containing 6 PCBs. Bonus! Guess I had better get the other parts on order. I won’t have them ready for this week end, but I predict much solder smoke in my future next weekend.