How Long a Battery Hive Lasts: Solar, LiFePO4, Deep Sleep

There’s a question that always comes last with a connected hive, after the ones about sensors and charts, but that actually comes before all the others: what about power? A hive sits in a field, often far from a house, almost always without an outlet for kilometers around. All the intelligence you put inside it, the scale, the climate sensor, the microphone, the radio, is worth nothing if the node dies in November and you don’t find out until the following spring. Energy autonomy isn’t a detail to sort out at the end: it’s the design problem everything else is built around.

In this piece I walk through how the bjtOS node’s power chain is built, why I chose certain components, and above all what really decides how long it lasts: not the battery, but how much time the node spends asleep.

The chain, link by link

The power supply of an off-grid node is a tiny power plant in miniature. In order: a solar panel, an MPPT charge controller, a battery, a regulator that brings the voltage down to the electronics’ 3.3 volts, and finally the actual load, meaning the microcontroller with its sensors and the LoRa radio.

The solar panel is the source. It doesn’t need to be large, but it has to be sized for the worst month, not the best one (more on this later, because it’s the counterintuitive part).

The MPPT controller sits between the panel and the battery and does two things: it tracks the panel’s point of maximum output as light changes (a passing cloud, the low January sun) and it manages the correct charging profile for the battery chemistry. It’s a component that pays for itself, because in low light the difference between charging well and charging poorly is exactly the difference between making it to the end of winter or not.

The battery is the lung: it stores energy during the day to keep the node alive at night and on bad-weather days. Then a 3.3-volt regulator stabilizes the voltage for the electronics, and here there’s a detail that sounds like nitpicking but is actually decisive: it has to be a regulator with extremely low quiescent current. When the node is asleep it draws almost nothing, and if the regulator itself drinks more current than the sleeping microcontroller, you’ve already lost. In deep sleep, the regulator’s own consumption can become the dominant line item in the whole power budget.

Why LiFePO4 and not the battery in your phone

For energy storage I chose LiFePO4 (lithium iron phosphate) chemistry, not the classic lithium you have in your phone. There are three reasons, and they’re worth the choice.

The first is lifespan: a LiFePO4 cell handles thousands of charge and discharge cycles against the few hundred of classic lithium. In a device that has to sit in a field for years, cycling every day, that’s the difference between replacing the battery every season or forgetting about it entirely.

The second is safety: it’s a chemistry that’s far more thermally stable, which is exactly what you want in a closed wooden box, exposed to summer sun, that you can’t keep an eye on.

The third is the flat voltage curve: a LiFePO4 cell sits around 3.2 nominal volts for almost the entire discharge, rises to about 3.65 volts at full charge, and needs to be cut off around 2.5 volts to avoid damaging it. That flatness is a virtue for the electronics, which see a stable voltage, but it’s also a small curse: since the voltage barely changes as charge drops, reading the state of charge from voltage alone is difficult. A number that barely moves between 70% and 30% tells you very little. It’s a solvable problem, but you need to know about it in advance, and further down I explain how I’m tackling it.

An honest note on the prototype: on the bench, to get moving quickly, I’m using a convenience pack (classic lithium 18650 cells with a small ready-made charging circuit). The field chemistry, though, remains LiFePO4: the prototype is there to validate the chain and the firmware, not to capture the final autonomy figure.

The real lever: deep sleep

Here comes the part that flips the intuition. You’d think autonomy depends on the battery: bigger battery, more days. That’s partly true, but the far more powerful lever is something else: how much time the node spends switched off.

A hive node doesn’t need to be awake. Weight and climate are extremely slow signals: they change over hours, not seconds. There’s no point measuring them continuously. So the microcontroller spends the vast majority of its time in deep sleep, a state where it draws a tiny fraction of what it does when working. It wakes up at regular intervals, say every few minutes, does its round (reads the sensors, processes, transmits over LoRa), and immediately goes back to sleep.

The math is unforgiving, and it’s in our favor: if the node is awake for a few seconds every five or ten minutes, for 99% of the time it consumes almost nothing. It’s the ratio between time on and time off, the duty cycle, that governs autonomy far more than battery capacity does.

A couple of precautions revolve around this idea. The first is cutting power to everything that isn’t needed while the node sleeps: a dedicated power line turns sensors on only during wake-up, and the debug display, handy on the bench, has to be switched off entirely in the field, because a display left on by itself can draw more than everything else combined.

The second is knowing which items are the heavy hitters of the active phase. There are two: LoRa transmission, which draws current for those few instants, and above all audio analysis, meaning microphone sampling and the frequency transform (FFT) used to read the colony’s “song.” Audio is the most demanding part of the wake cycle, and for that reason it can run on its own rhythm, less frequent than the other measurements or concentrated in certain hours, instead of running on every wake-up.

The autonomy math (and why winter calls the shots)

Sizing this chain properly isn’t guesswork, it’s arithmetic. The method is always the same:

Measure current draw in two states: asleep and awake-and-working, with the duration of each phase.
From that, derive the average daily consumption in milliamp-hours.
Size the battery to cover a certain number of sunless days, the bad-weather days when the panel isn’t recharging.
Size the panel so that, on good days, it puts back at least what the node consumes, with some margin.

The tricky part is step 4, and it’s counterintuitive: the panel isn’t sized for summer, it’s sized for winter. In northern Italy, December and January irradiance is a fraction of June’s, days are short and often overcast. That’s the condition that dictates panel and battery size. A system that holds up in January in Lombardy will coast through summer; the reverse leaves you stranded exactly when the beekeeper isn’t out checking hives.

And there’s one more constraint that winter brings with it: LiFePO4 must not be charged below freezing, or the cells get damaged. So in the field you need a charger that blocks charging when it’s too cold, or you accept reduced winter operation. It’s one of those details you don’t see until it bites you, and it needs to be in the budget from day one.

Where things stand now: the first discharge test

To keep all this from staying theoretical, it needs to be measured. In the past few days I started the first discharge test on a real node: a bench hive was unplugged from power and left running on battery alone, starting at full charge, transmitting its own voltage to the cloud at regular intervals. The battery acts as a stopwatch: when the voltage drops to the cutoff threshold, I’ll know how long it lasted.

This first test deliberately runs in the most power-hungry regime possible, with the node always active, without yet the power-saving strategy it will use in the field. The autonomy figure that comes out of it, then, isn’t the final number but a pessimistic floor: in the field, with the node asleep almost all the time, it will last much longer. What this test does already deliver, and this is the truly valuable part, is the shape of the discharge curve: how voltage drops over time.

That’s exactly what’s needed to solve the flat-voltage problem I mentioned earlier. With the real curve in hand I can build the volts-to-charge-percentage conversion, the non-linear table that translates a nearly motionless voltage into a readable “you’re at 60%.” And I decided to put that server-side, not inside the node: that way the percentage shown to the beekeeper can be calibrated and corrected against real data without having to touch nodes already installed. It’s one of those choices that seem like a minor detail at the time and that, a year down the line, save you a trip to every apiary.

Energy is the invisible foundation

What people look at on a smart hive are the charts, but underneath those charts there’s a small power plant that has to survive winter on its own, in a field, for years. The panel, the right chemistry, a regulator that doesn’t waste, and above all a node designed to sleep almost all the time: that’s the part you don’t see, and it’s what decides whether everything else actually exists.

It’s also why a natively digital hive is designed starting from constraints, not from sensors. If you’re curious about the bigger picture, I covered how a smart hive works as a whole, and there are dedicated pages on what we’re building: the technology and the product. Autonomy is the quietest promise of all: nobody notices it, until the day the data doesn’t arrive. And our job is to make sure it always does.