Projects

DC-DC Converter: Connectors

So, a thing that will make or break this project, will be the connectors that feed power in and out.

My existing system uses the larger 50A Anderson connectors.  These are big and chunky, not really appropriate for a PCB.  The 30A version would be okay size-wise, and I use these on the bike, but 30A isn’t sufficient.  That’s about my cluster’s peak current draw, and I want a 50% safety margin.

Thinking about it last night… 20V at 50A… that’s a kilowatt!  Pales into insignificance when you compare it to the 48V 400A electric harvester I worked on years ago (and blew many a MOSFET on, not to mention boiling electrolytics with ripple current), but it’s still a decent amount of power.

There’s the XT60 and Deans connectors, however the problem with these is they aren’t all made equal, there’s some slight variances in the tolerances, thus you can buy two “XT60″s or two “Deans” connectors and find they won’t mate.

I see no problem in a short flying lead that connects to screw terminals.  Take the flying lead, wire it up, then connect it to the connector of your choice.  That’s how the solar controller I was using connected up, and I don’t think its problems were with its connectors.

The conductors I’m using are 6-8AWG.  Whatever I use, must be able to handle that.  There isn’t a lot out there for off-board connectors, and even the XT60s are a wee bit small.  I did find these terminal blocks .  Supposedly good for 76A, that’s enough safety margin for me, and Phoenix Contact aren’t known for producing crap.

The spade lugs used on the HEP-600C I’m using for charging my batteries would be smaller than this, and so far I’ve not seen any fires.

I might be able to put a few different footprints down on the PCB, we’ll see.  I plan to design the PCB so there’s nice wide areas so you can drill your own hole and solder whatever you like there.  Likewise for the inductor and capacitors, this will be a board that aims for flexibility.

DC-DC Converter: Researching designs

So, I’ve been pondering doing a more capable power controller for the purpose of enhancing or even outright replacing the solar controllers I have now on the Solar-powered cloud computing cluster.

The idea started as a straight DC power meter with a Modbus interface, as there’s pretty much nothing on the market.  Lots of proprietary jobbies, or display-only toys, but nothing that will talk an open protocol.  I started designing a circuit.  I thought: it’d be handy to have digital inputs and outputs.

Lots of mains energy meters have them, and they’re handy for switching loads.  My remote reset facility when porting the mainline kernel to the TS-7670 was a digital output on the CET PMC-519.  If I crashed the TS-7670, I basically fired up ipython, loaded pymodbus, connected to a Modbus/TCP gateway, then issued a few write-coil commands to power-cycle the TS-7670.

Often the digital inputs are hooked to water or gas pulse meters to meter usage: you get a pulse every N litres of water or every N cubic metres of gas.

A meter with digital I/O that’s programmable would be just perfect for the job my little power controller is doing.

I could make the channels PWMable, thus be able to step down the voltage.  Put an INA219 on there, and I’d have current measurement and power control.  The idea evolved to putting the INA219 and a MOSFET on a board, so it was a separate module: just to make board layout easier and to reduce the size of the boards.

For a buck converter, you just add an inductor and a few smoothing capacitors.  Better yet, two INA219s and a MCU would let me measure power in, out, and have localised brains.  Thus the idea of a separate, smart module, was born.  For kicks, I’m also adding the ability to boost as well by tacking a boost converter to the end.

The principle is really quite simple.  A buck converter has this topology (source, Wikipedia):

If you swap out that diode for another MOSFET, you get a synchronous buck converter, which looks like this (same Wikipedia article):

It’s worth noting that a MOSFET switch has a body diode that might be exploitable, I’ll have to check.  You drive the two switches with complimentary outputs.  Both these circuits will step down a voltage, which is what I want to do 99% of the time, but it’s also useful to go up .  A boost converter looks like this (source: Wikipedia):

Again, that diode can be replaced with another MOSFET.  This will step up a voltage, but not down.

There are a few options that allow going both ways:

  • Flyback : which uses a transformer and provides galvanic isolation.  The downside is the secondary must take all the output current, and finding a transformer that can do 50A is EXPENSIVE!  So scratch that.  (And no I am not winding my own transformers… tried that back at uni when a lecturer asked us to build a flyback converter.  Bugger that!)
  • SEPIC is basically a boost plus a buck-boost.  Efficiency is not their strong suite apparently, although there are ways to improve it.  I’m not sure the added complexity of two boost converters sandwiching a buck converter is worth it.
  • Ćuk is no good here because it inverts its output, unless you want an isolated one, which is going to be $$$$ because of the transformer needed.  Yes, I’m chickening out!
  • Split-Pi looks real interesting, in that it’s bi-directional.  In the event I ever decide to buy a front-wheel motor for my bicycle, I could use one of these to do regenerative braking and save some wear on my brake pads.  I haven’t seen many schematics for this though, just generalised ones like the one above.
  • Zeta also looks interesting, but it’s pretty unknown, and has a higher parts requirement.  It could be worth looking at.  It’s a close relative of the SEPIC and Ćuk.

The route I’m looking to try first is the 4-switch buck-boost, which looks like this:

The goal will be to have a simple microcontroller-based switch-mode power supply module with the following characteristics:

  • Up to 50A current switching capability
  • 9-30V input voltage range
  • 12-15V output voltage range
  • 250kHz switching frequency

99% of the time, conditions will be:

  • input voltage: 18~20V
  • output voltage: 13.8~14.6V

So I’m thinking we design for a buck converter, then the boost just comes along for the ride.  There’s a handy primer here for designing a buck converter.  For a 20V input and 14.6V output, their formulas suggest a 33µH inductor should cut the mustard. One of these which can handle >50A is not a big or expensive component.

In the above system, we need to be able to drive up two pairs of complementary outputs at high speed.  We can forget the hacker darling ATTiny85, as with 5 pins, it barely has enough to do the SPI interface, let alone talk I²C and drive four MOSFETs.

A good candidate though is the chip I used for the #Toy Synthesizer — the ATTiny861 .

This chip has the same high-speed PWM, and I already know how to drive it.  It doesn’t have a lot of brains, but I think it’ll do.  The challenge will be in-circuit programming.  There are just 3 PWM outputs that don’t clash with ICSP.

Don’t be fooled by the presence of two DI/DO/USCK pins, it’s the one UCI interface, just you can switch which pins it uses.  That’ll be handy for talking I²C, so I’ve earmarked those pins in purple.  The nRESET pin is marked in green, the PWM pins in blue.  When nRESET is pulled low, PB[012] switch to the functions marked in red.

This doesn’t matter for the toy synthesizer as I only need two PWM channels, and so I chose OC1B and OC1D.  Here, I need nOCID (no problem) and nOC1B (uhh oh).

During run-time, I could put my SPI interface on PA[012] and bit-bang the I²C, but I don’t want MOSFETs chattering when flashing new firmware.  Thus, when in reset, I need to inhibit nOC1B somehow.

The other way of doing this is to just forget about nOC1B altogether.  Consider this:

  • When stepping up: SW1 will be held on , SW2 will be held off , and the PWM will drive SW3/SW4.
  • When stepping down: SW3 will be held off , SW4 will be held on , and the PWM will drive SW1/SW2.

We’re only PWMing two MOSFETs at a time, so could get away with just one complementary pair, OC1D/nOC1D.  We ignore OC1B and can now use it for something else.  We just need a means of “selecting” which pair of MOSFETs we’re driving.  A PWM output with 8-bits resolution and 250kHz cycle frequency has a minimum pulse width of about 15ns (1/64MHz).

A SN74AHC244 tri-state buffer will do nicely.  We can use two GPIOs to control the two enable pins to switch the OC1D/nOC1D and a pair of other pins for manual control.  Perhaps PA[01] to select where the PWM signals get routed, and PA[23] to control the non-PWMed MOSFETs.

Due to switching speed requirements, we will need to run the ATTiny861 at 5V.  So maybe make some room for some level shifting of the SPI interface to support 3V master interfaces as this is much lower speed than the PWM output.

This leaves PB3, PB6, PA1 and PA3 free for GPIOs to use however we wish.  Two of these should probably be made part of the host interface, one for chip select (PB3 seems a good choice) and one for an interrupt (maybe PB6).  Add the 5V/0V power rails, and nRESET, and the same interface can be used for ICSP too.

The idea looks doable.  The challenge will be making the control algorithm work within the constraints of the ATTiny861, but given what people have done with the ’85 which has the same core, I’m sure it can be done.

Solar Cluster: Jury still out on solar controller, thinking of PSU designs

So, the last few days it’s been overcast.  Monday I had a firmware glitch that caused the mains supply to be brought in almost constantly, so I’d disregard that result.

Basically, the moment the battery dropped below ~12.8V for even a brief second, the mains got brought in.  We were just teetering on the edge of 12.8V all day.  I realised that I really did need a delay on firing off the timer, so I’ve re-worked the logic:

  • If battery drops below V_L, start a 1-hour timer
  • If battery rises above V_L, reset the 1-hour timer
  • If the battery drops below V_CL or the timer expires, turn on the mains charger

That got me better results.  It means V_CL can be quite low, without endangering the battery supply, and V_L can be at 12.8V where it basically ensures that the battery is at a good level for everything to operate.

I managed to get through most of Tuesday until about 4PM, there was a bit of a hump which I think was the solar controller trying to extract some power from the panels.  I really need a good sunny day like the previous week to test properly.

This is leading me to consider my monitoring device.  At the moment, it just monitors voltage (crudely) and controls the logic-level enable input on the mains charger.  Nothing more.  It has done that well.

A thought is that maybe I should re-build this as a Modbus-enabled energy meter with control.  This idea has evolved a bit, enough to be its own project actually.  The thought I have now is a more modular design.

If I take the INA219B and a surface-mount current shunt, I have a means to accurately measure input voltage and current.  Two of these, and I can measure the board’s output too.  Stick a small microcontroller in between, some MOSFETs and other parts, and I can have a switchmode power supply module which can report on its input and output power and vary the PWM of the power supply to achieve any desired input or output voltage or current.

The MCU could be the ATTiny24As I’m using, or a ATTiny861.  The latter is attractive as it can do high-speed PWM, but I’m not sure that’s necessary in this application, and I have loads of SOIC ATTiny24As.  (Then again, I also have loads of PDIP ATTiny861s.)

The board would expose the ICSP pins plus two more for interrupt and chip select, allowing for a simple jig for reprogramming.  I haven’t decided on a topology yet, but the split-pi is looking attractive.  I might start with a buck converter first though.

This would talk to a “master” microcontroller which would provide the UI and Modbus interface.  If the brains of the PSU MCU aren’t sufficient, this could do the more grunty calculations too.

This would allow me to swap out the PSU boards to try out different designs.

Solar Cluster: Return of the Redarc BCDC1225

Well, I’ve now had the controller working for a week or so now… the solar output has never been quite what I’d call, “great”, but it seems it’s really been on the underwhelming side.

One of the problems I had earlier before moving to this particular charger was that the Redarc wouldn’t reliably switch between boosting from 12V to MPPT from solar.  It would get “stuck” and not do anything.  Coupled with the fact that there’s no discharge protection, and well, the results were not a delight to the olfactory nerves at 2AM on a Sunday morning!

It did okay as a MPPT charger, but I needed both functions.  Since the thinking was I could put a SSR between the 12V PSU and the Redarc charger, we tried going the route of buying the Powertech MP3735 solar charge controller to handle the solar side.

When it wants to work, it can put over 14A in.  The system can run on solar exclusively.  But it’s as if the solar controller “hesitates”.

I thought maybe the other charger was confusing it, but having now set up a little controller to “turn off” the other charger, I think I can safely put that theory to bed.  This was the battery voltage yesterday, where there was pretty decent sunshine.

There’s an odd blip at about 5:40AM, I don’t know what that is, but the mains charger drops its output by a fraction for about 50 seconds.  At 6:37AM, the solar voltage rises above 14V and the little ATTiny24A decides to turn off the mains charger.

The spikes indicate that something is active, but it’s intermittent.  Ultimately, the voltage winds up slipping below the low voltage threshold at 11:29AM and the mains charger is brought in to give the batteries a boost.  I actually made a decision to tweak the thresholds to make things a little less fussy and to reduce the boost time to 30 minutes.

The charge controller re-booted and turned off the mains charger at that point, and left it off until sunset, but the solar controller really didn’t get off its butt to keep the voltages up.

At the moment, the single 120W panel and 20A controller on my father’s car is outperforming my 3-panel set-up by a big margin!

Today, no changes to the hardware or firmware, but still a similar story:

The battery must’ve been sitting just on the threshold, which tripped the charger for the 30 minutes I configured yesterday.  It was pretty much sunny all day, but just look at that moving average trend!  It’s barely keeping up.

A bit of searching suggests this is not a reliable piece of kit, with one thread in particular suggesting that this is not MPPT at all, and many people having problems.

Now, I could roll the dice and buy another.

I could throw another panel on the roof and see if that helps, we’re considering doing that actually, and may do so regardless of whether I fix this problem or not.

There’s several MPPT charger projects on this very site.  DIY is a real possibility.  A thought in the back of my mind is to rip the Powertech MP3735 apart and re-purpose its guts, and make it a real MPPT charger.

Perhaps one with Modbus RTU/RS-485 reporting so that I can poll it from the battery monitor computer and plot graphs up like I’m doing now for the battery voltage itself.  There’s a real empty spot for 12V DC energy meters that speak Modbus.

If I want a 240V mains energy meter, I only have to poke my head into the office of one of my colleagues (who works for the sister company selling this sort of kit) and I could pick up a little CET PMC-220 which with the addition of some terminating resistors (or just run comms at 4800 baud), work just fine.  Soon as you want DC, yeah, sure there’s some for solar set-ups that do 300V DC, but not humble 12V DC.

Mains energy meters often have extra features like digital inputs/outputs, so this could replace my little charge controller too.  This would be a separate project.

But that would leave me without a solar controller, which is not ideal, and I need to shut everything down before I can extract the existing one.  So for now, I’ve left the Powertech one in-place, disconnected its solar input so that now it just works as a glorified VSR and voltmeter/ammeter, as that bit works fine.

The Redarc is now hooked up to solar, with its output going into a spare socket going to the batteries.  This will cost me nothing to see if it’s the solar controller or not.  If it is, then I think some money on a VSR to provide the low-voltage protection, and re-instating the Redarc charger for solar duty will be the next step.  Then I can tear down the Powertech one at my leisure and figure out what they did wrong, or if it can be re-programmed.

The Meanwell charger is taking care of things as I type this, but tomorrow morning, we should hopefully see the solar set-up actually do some work…

… maybe. 🙂

Toy Synthesizer: Never forget thy series resistor!

So, I’ve gotten back to this project having spent a lot of my time on work, the Yarraman to Wulkuraka bike ride and the charging controller #Solar-powered cloud computing — just to name 3 things vying for my attention.

In the test board, I had wired up some LEDs for debugging, dead-bugged 0805s, which were hooked between the output of the octal latch and 0V.  I omitted the series resistor, as I presumed that, given the output was PWMed with a maximum duty cycle of ⅛, the LEDs shouldn’t burn out.

Turns out I had forgotten a property that all diodes exhibit, that is the desire to clamp the voltage across them.  Today I was testing the board, and wondering why some channels were dim, others didn’t work at all, but one worked so much better.  Did I accidentally put the wrong current limiting resistor in series with the drain?  No, all checked out as about 12 ohms.

I put a program on the MCU that just turned a channel on when the button was pressed.  No music, no fancy PWM stuff, just turn on a LED when the corresponding button was pressed.  Measuring the gate voltage showed about 2V.

Even with the PWM output forced low, the output was still 2V.  Moreover, I was using my new bench supply, and with nothing running, the circuit was drawing ~300mA!  Why?

Turns out, the LEDs I had dead-bugged in, were trying, and succeeding, in clamping the output voltage.  2V was just barely enough to trigger the output MOSFETs, but clearly this was borderline as some worked better than others.  I was likely in the linear region.

Snip out the common connection for the LEDs to 0V, and the problems disappeared.  I’ve dead-bugged a 1kOhm resistor in series with the lot, and that’s got my debug LEDs back and working again.  The MOSFET outputs now work properly.

The bigger chunkier MOSFETs I bought by mistake could have worked just fine: maybe I was just driving them wrong!

Two prospects have crossed my mind:

  • Getting the MOSFET board made professionally
  • Getting a board that combines all components onto one PCB made professionally

The version that is shown was really designed for the home PCB maker to be able to produce.  The traces are wide and the board is fundamentally single-sided: when etching, you just etch one side of the board and leave the other side unetched.  When drilling the holes, you just countersink the holes a bit on all pins not connected to 0V.

A smaller board with everything in one would be worth making now that I’ve proven the concept.  Not sure there’s a good reason to go to SMT at this stage: I still want to make assembly simple.  The thinking is the all-in-one would have some headers so you can conceivably break things out for other projects and just omit parts as required.

This could theoretically be entered into the #The 2018 Hackaday Prize as part of the musical instrument contest, as that’s what it is: it’s a musical instrument for the severely physically handicapped.  There is a video of a slightly earlier prototype in this post .

Code wise, I’ve done little.  The basic functionality is there, it makes noises, it flashes LEDs, that’s about what it needs to do for now.  I did have to increase the start-up delay so that the buttons were detected properly, as without this, if I used my bench-top supply, it would fail to see any inputs.  People aren’t going to notice 100ms boot-up delay vs 1ms, but it makes a difference if the power supply is a little slow.

Solar Cluster: Power controller installed

Well, I finally got around to installing that power controller.

Yes, the top of that rack is getting to be a pigsty. Even the controller isn’t my best work:

You can see above I’ve just tacked wires onto the points I need and brought those out to a terminal strip.  There’s provision there for some PWM-controlled fans, but right now this is unused.  I’ve omitted the parts not required for the application.  If this works out, I might consider doing another board, this time better dedicated to the task at hand.

With that controller in place, I’ve now wound the charger back up.  In fact I made a whoopsie at first: I forgot that the Vout pot on the HEF-600C-12 sets the float voltage and wound that right up to 14.4V which meant a boost voltage of 15V!

Thankfully I looked over at the volt meter on the solar controller and realised my mistake quick.  15 seconds won’t hurt anything, but it is now set at 13.6V.  You don’t even see it on the 40-sample average.  The controller should let the mains charger sit there for an hour before it reconsiders the need for mains.

I think my next step … there’s a yard that could do with a hair cut… I’ll drag the mower out and chase that around the yard for a bit.  Then we’ll see what it looks like.


Okay, back from a little mowing… and sure enough, the controller is mostly doing the right thing.  I think I’ll need to tweak some set-points, maybe set the solar threshold lower.  Thankfully the “inhibit” LED is just an indication that it considers the solar voltage low, the solar is going to be on no matter what.

Yes, that SSR is massive for the job. It’s what I had on hand at the time. I’ll probably replace it with something small, maybe a reed relay since they’re cheap.

Right at this point, I have the SSR’s inputs connected between the solar V+ and the BC-547B on the board, so when the sun *does* go down, the mains power will be turned back on no matter what the controller thinks.

A close-up look of the status LEDs shows what mode we’re in:

We’ll ignore the temperature ones. Ultimately they indicate the state of the fan controller, and in this state, it’d be running the fans, as indicated by the Fan PWM LED to the left. Temperature is measured by the sensor in the ATTiny24A on-board, so not highly accurate.

The other mystery “LED” is the shiny surface on the BC-547B to the left of the two source status LEDs.

Here, I suspect the sun ducked behind a cloud so the voltage dropped, hence both “inhibit” LEDs came on. Earlier, “Float” was lit (you can sort-of make it out in the previous photo), the charger was actually actively trying to charge the battery, but to the controller it looked to be done. It left it go for the hour as programmed, then turned off the mains charger to let the solar panel take over.

The idea is that during the day, if it gets low, give it a boost from mains, then go back to solar. We only want to rely on mains at night.

Now, it should stay in that state until tonight, when the lack of sun should bring the mains charger online (by sheer fact that the solar panels power the “coil” of the relay).


So, I saw that, and had a look… sure enough, the controller is still asserting that the mains charger should be off. I think I need to bump the battery thresholds up a bit, although that’s still safely above the danger zone, it’s lower than I’m comfortable with.

Right up until 5:58PM, it seems the MCU just held on, thinking the battery voltage was “good enough”, so no need for a charge yet. I might want to drop the solar threshold down some so it doesn’t “flap” when broken cloud passes over, then raise the minimum battery threshold a bit.

Even now, the thing that’s turning the mains charger on is the fact that the 1.5V coming off the panels is not sufficient for activating the solid-state relay I’m using. I’m thankful I wired the SSR to Vsolar and made the MCU output open-collector. This is a useful little safety feature, making it impossible for the MCU to latch-up and hold the mains charger off, as the sun will eventually set, and that will force the mains charger to turn on like it did tonight.

Solar Cluster: Thank goodness for good monitoring

A few months back now, I had the misfortune of overshooting my Internet quota, and winding up with a AU$380 bill for the month (and that was capped… in truth it was more like AU$3000).  In fact, it happened a couple of times until I finally nailed down the cause.

Part of it was NTP traffic (seems lots of cowboys write SNTP clients now and point them at pool.ntp.org), some was the #Hackaday.io Spambot Hunter Project and related activity.  In short, I invested some money into upping the quota, and some time into better monitoring.

I wanted to do the monitoring anyway to keep an eye on operations, as well as things like the solar panel voltages, etc.  Since I got it in place, I’ve been able to get much faster notifications of when things go awry.  Much sooner than the 120% quota usage alarm that Internode sends you.

I’m glad I did that now, last night I left a few tabs open on the Hackaday.io site.  I noticed this evening they were still trying to load something and got suspicious… then I saw this:

Double checking, sure enough, something on one of those pages made Chromium get its knickers into a twist, and chew through all that data.

It took me a bit of tinkering to get the right query to extract the above chart.  Essentially there was a sustained 1.5MB/sec download for over 21 hours which would account for the 113.1GB that Internode recorded.

It’s a bit co-incidental that the usage dropped the moment I re-started Chromium.  Not sure why it was continually re-loading pages, but never mind.

The above data is collected using a combination of collectd and InfluxDB, with Grafana doing the dashboarding and alarms, and a small Perl script pulling the usage data off Internode’s API.

Solar Cluster: Return of the power controller

Well, I’ve been tossing up how to control the mains charger for a while now.

When I first started the project, my thinking was to use an old Xantrex charger we had kicking around, and just electrically disconnect it from the batteries when we wanted to use the solar power.  I designed a 4-layer PCB which sported a ATTiny24A microcontroller, MOSFETs (which I messed up) and some LEDs.

This was going to be a combined fan controller and power management unit.  It had the ability (theoretically) to choose a supply based on the input voltage, and to switch if needed between supplies.

It didn’t work out, the charger got really confused by the behaviour of the controller.  I was looking to re-instate it using the Redarc solar controller, but I never got there.  In the end, it was found that the Redarc controller had problems switching sources and would do nothing whilst the batteries went flat.

We’ve now replaced both ends of the system.  The solar controller is a Powertech MP3735 and integrates over-discharge protection.  The mains charger is now a MeanWell HEP-600C-12 (which has not missed a beat since the day it was put in).

Unlike my earlier set-up, this actually has a 5V logic signal to disable it, and my earlier controller could theoretically generate that directly.

Looking at the PCB of my earlier power controller attempt, it looks like this could still work.

Above is the PCB artwork.  I’ve coloured in the sections and faded out the parts I can omit.

In green up the top-left we have the mains control/monitoring circuitry.  We no longer see the mains voltage, so no point in monitoring it, so we can drop the resistor divider that fed the ADC.  This also means we no longer need the input socket P2.

Q2 and Q7 were the footprints of the two P-channel MOSFETs.  We don’t need the MOSFETs themselves, but the signals we need can be found on pin 1 of Q2.  This is actually the open-drain output of Q1, which we may be able to hook directly to the REMOTE+ pin on the charger.  A pull-up between there and the charger’s 5V rail, and we should be in business.

In yellow, bottom left is the solar monitoring interface.  This is still useful, but we won’t be connecting solar to the battery ourselves, so we just keep the monitoring parts.  The LED can stay as an indicator to show when solar is “good enough”.

In purple, occupying most of the board, is the controller itself.  It stays for obvious reasons.

In red, is the fan control circuitry.  No reason why this can’t stay.

In blue is the circuitry for monitoring the battery voltage.  Again, this stays.

The main advantage of doing this is I already have the boards, and a number of microcontrollers already present.  There’s a board with all except the big MOSFETs populated: with the MOSFETs replaced by 3-pin KK sockets.

How would the logic work?  Much the same as the analogue version I was pondering.

  • If battery voltage is low, OR, the sun has set, enable the mains charger.

What concerned me about an analogue solution was what would happen once the charger got to the constant-voltage stage.  We want to give it a bit of time to keep the battery topped up.  Thus it makes sense to shut down the charger after a fixed delay.

This is easy to do in a microcontroller.  Not hard with analogue electronics either, it’s fundamentally just a one-shot, but doing it with an MCU is a single-chip solution.  I can make the delay as long as I like.  So likely once the battery is “up to voltage”, I can let it float there for an hour, or until sunrise if it’s at night.

Solar Cluster: Kernel driver now up on Github

So, I’m happy enough with the driver now that I’ll collapse down the commits and throw it up onto the Github repository.  I might take another look at kernel 4.18, but for now, you’ll find them on the ts7670-4.14.67 branch.

Two things I observe about this voltage monitor:

  1. The voltage output is not what you’d call, accurate.  I think it’s only a 10-bit ADC, which is still plenty good enough for this application, but the reading I think is “high” by about 50mV.
  2. There’s significant noise on the reading, with noticeable quantisation steps.

Owing to these, and to thwart the possibility of using this data in side-channel attacks using power analysis, I’ve put a 40-sample moving-average filter on the “public” data.

Never the less, it’s a handy party trick, and not one I expected these devices to be able to do.  My workplace manages a big fleet of these single-board computers in the residential towers at Barangaroo where they spend all day polling Modbus and M-Bus meters.  In the event we’re at all suspicious about DC power supplies though, it’s a simple matter to load this kernel tree (they already run U-Boot) and configure collectd (which is also installed).

I also tried briefly switching off the mains power to see that I was indeed reading the battery voltage and not just a random number that looked like the voltage.  That yielded an interesting effect:

You can see where I switched the mains supply off, and back on again.  From about 8:19PM the battery voltage predictably fell until about 8:28PM where it was at around 12.6V.

Then it did something strange, it rose about 100mV before settling at 12.7V.  I suspect if I kept it off all night it’d steadily decrease: the sun has long set.  I’ve turned the mains charger back on now, as you can see by the step-rise shortly after 8:44PM.

The bands on the above chart are the alert zones.  I’ll get an email if the battery voltage strays outside of that safe region of 12-14.6V.  Below 12V, and I run the risk of deep-cycling the batteries.  Above 14.6V, and I’ll cook them!

The IPMI BMCs on the nodes already sent me angry emails when the battery got low, so in that sense, Grafana duplicates that, but does so with pretty charts.  The BMCs don’t see when the battery gets too high though, for the simple matter that what they see is regulated by LDOs.

Solar Cluster: Getting the battery voltage into Grafana

I’ve succeeded in getting a working battery monitor kernel module. This is basically taking the application note by Technologic Systems and spinning that into a power supply class driver that reports the voltage via sysfs.

As it happens, the battery module in collectd does not see this as a “battery”, something I’ll look at later. For now the exec plug-in works well enough. This feeds through eventually to an InfluxDB database with Grafana sitting on top.

https://netmon.longlandclan.id.au/d/IyZP-V2mk/battery-voltage?orgId=1