In a couple of threads on the TTN forum, some questions on the power consumption of a LoraWAN/TTN gateway have been raised, and whether it could be powered independently, e.g. through a solar panel. I decided to revisit this topic while working on a guide on lightning protection for gateways. Completely isolating your gateway from the building it is on is an effective way to provide lightning protection. It also opens up some possibilities for ‘guerilla gateways’ which you can place anywhere without being tied to the availability of power.
Below I calculate the required components needed to build a fully self-sufficient TTN gateway.
I have access to detailed AC and DC yield data from a 4.8kW solar array oriented perfectly south under a 40° vertical angle, providing very valuable reference data. I used the worst case DC yield data, namely the dark months November, December and January. We had the ‘luck’ to have some extremely clouded weeks these months, so a setup that can bridge these periods will certainly survive the rest of the year.
Having access to PV yield is one thing, but an accurate prediction of the power consumption is another. I decided to hook up my Raspberry Pi powered ic880 gateway to our venerable Voltech PM3000 power analyser and let the integrator run for a couple of days. I measured the power consumption the Raspberry drew through its USB port. The gateway was operating normally, that is mostly receiving data from nodes. Except for the occasional transmission from other users, I did not specifically perform transmissions. The gateway was connected to the internet through Ethernet.
On average, the gateway drew 3.2 Watts of power on the 5V DC USB line (figure 1).
This was confirmed by the integrator, e.g. after 25.66h it had consumed 82.76Wh of energy averaging 3.23 Watts of instantaneous power (figure 2).
With these figures in hand, it was time to build a (simplified) system model. I defined a classic DC-coupled off-grid model as depicted in figure 3. It consists of a solar panel, a solar charger/controller, a lead acid battery, a DC/DC power supply and, of course, the gateway.
I’ll talk some more about each component, you can scroll down to the results if it doesn’t interest you.
The solar charger/controller has some specific parameters to take into account, namely the quiescent current Iq (self-consumption) and the power conversion efficiency η.
As you can see in figure 3 I went for a MPPT solar charger/controller instead of the cheaper and more ubiquitous PWM controllers. PWM controllers are a great choice if the voltage of your solar panel more or less matches the voltage of your storage medium and if you principally expect sunny (hot) operating conditions. The required size of our solar panel was however (spoiler alert!) too large to be practical with 12V panels matched to our lead acid battery, and we are especially concerned with performance during the cold winter months. I therefore went for the more efficient MPPT controller. These controllers frequently offer more advanced battery charging strategies, e.g. desulfation, and a dedicated load connection optimising battery capacity and battery life.
MPPT controllers do cost a bit more and have somewhat higher quiescent current than MPPT controllers, but have overall higher efficiency. I based the controller in my model on the Steca Solarix MPPT with an average efficiency of 95% and a quiescent current of 10mA. I’ve had good experiences with Steca in the past so it’s kinda my go to brand when looking for solar chargers. MPPT will generally be around 80-85% efficiency.
Energy storage medium
As in most off-grid applications the selected energy storage medium is a lead-acid (LA) battery. LA offers superior cost/capacity ratios compared to other battery types at the cost of size and weight. This is however a stationary application and the size of the battery will be much smaller than that of the PV panel, so we don’t have to worry about these parameters.
Not all LA batteries are born equal though. I selected the Vision Akkus 6FM75T AGM type storage battery. In this type of battery the electrolyte is Absorbed in a Glassfiber Mat (hence AGM). These batteries are maintenance free, can be mounted in non-horizontal positions and can cope better with cold temperatures. Most importantly however, they last many charge/discharge cycles (up to 1.600 and more), can handle partial discharge and have limited self-discharge (around 3% per month). They are built to supply a steady current flow to the load. We assumed an overall 85% charge/discharge efficiency, taken into account (spoilers again) the very high average SoC of around 83%.
Don’t use a flooded LA battery, commonly known as a car battery. Car batteries are built to supply a short burst of incredibly high current and expect to be fully recharged regularly, and make for very poor long term energy storage mediums.
The Raspberry Pi powered gateway operates on 5V, so I used a DC/DC converter to step down the 12V battery voltage to 5V. The gateway draws on average 670mA, so a power supply rated 1.2A or more should be sufficient. Best to buy a premium brand to ensure a stable output. We went for an overall 85% conversion efficiency, loosely based on the XP Power DTE40.
The calculation model is a simplified model based on the assumptions above. Solar energy from the PV panels is first converted to a steady 12V power taking the solar charger efficiency into account.
The gateway draws a steady 3.2W at 5V. I’ve raised this figure by 20% to 3.8W to be sure. On the 12V side the DC/DC converter efficiency is likewise taken into account resulting in around 4.4W power draw. The quiescent power draw of 0.12W from the MPPT controller is added resulting in a total power draw of around 4.6W.
If the energy output of the solar charge controller exceeds the total power draw, the excess power is stored in the battery at an efficiency of 85%. If the total energy draw exceeds the solar charger output, power is drawn from the battery. This is a further simplification because the real charge/discharge efficiency is dependent on the SoC. However the model resulted in a very high average SoC, making the average of 85% acceptable.
The model has two variable inputs: solar panel size and battery storage capacity. The goal is to incur zero downtime and to never reach a battery State of Charge (SoC) lower than 30%, which is the under-voltage cutoff for a LA battery.
I varied both inputs and plotted the combinations resulting in a minimal SoC of 30% or more. This resulted in figure 4.
As one can see, the extreme values are a minimal solar panel size of 100W and a minimal battery storage size of 40Ah. Everything below that results in an insane value of the other parameter.
In figure 5 the battery SoC (blue) and solar energy yield (red) are plotted for a solar panel size of 150Wp and a battery capacity of 75Ah. As one can see, this setup is able to bridge around 6 clouded days without dropping below a 30% SoC, resulting in zero downtime. In general I would recommend a somewhat bigger solar panel size, say 180Wp to 200Wp.
Is it worth it?
A setup as described above would cost something like this
|200Wp solar panel||€120|
|Steca Solarix MPPT 2010||€210|
|Vision Akkus 6FM75TX 75Ah battery||€199|
|DC/DC converter 12V-5V||€30|
Take some €40-ish into account for mounting and cabling and you end up around €600 for this self-sufficient gateway. That is without the cost for the gateway and the antenna, mind you.
So is a completely off-grid, self-sufficient gateway doable? Totally. Is it worth the price? That’s for you to decide.