Case study · Automation

Solar CommHub: communication when the grid is unavailable

A CMU-Africa proposal for a portable, solar-powered communication unit for disaster response, with a costed bill of materials and a five-year financial model as well as the simulation plan that was never run.

Role

Systems design, energy modelling and financial analysis

Timeline

April 2025, six weeks

Method

HOMER Pro · TRNSYS · Python link budget

Output

A design proposal and a costed financial model

When Typhoon Haiyan crossed Tacloban City in 2013, the cell towers went with the power. Families could not call for help, rescue teams could not coordinate and the silence held for weeks. Solar CommHub is a proposal for the gap that silence leaves: a portable, solar-powered communication unit two people can carry, set up in under thirty minutes as well as run for three days without sun.

◈

What this is. A design proposal and feasibility study written at Carnegie Mellon University Africa in April 2025, supervised by Prof. Jesse Thornburg. No unit was built. The energy, thermal and radio models described below were specified but never run. What was finished is the design itself and a costed financial model, so this page is about what those two documents actually settle.

∑

Source of the numbers. Every money figure here is recomputed from the eight-line bill of materials in the April 2025 financial report rather than quoted from its summary. The bill sums to $1,468 at 56.6 PHP to the dollar, break-even follows from $640 of net annual cash flow and the five-year return is 1,732 over 1,468. Two figures the report states, an IRR of 28 to 30% and an NPV above $820, do not reproduce and are left off this page. Ledger: backups/solar-commhub-numbers-ledger.2026-08-28.md.

When the towers go down

Tacloban sits on the eastern coast of Leyte, in the path of the storms that cross the Philippines at a rate of roughly twenty tropical cyclones a year. Haiyan is the one people remember. It took the grid and the cell network together, and the proposal is blunt about what followed: communities isolated, aid delayed as well as rescue coordinated by whatever radios happened to survive.

The pattern repeats. After Typhoon Rai in 2021 more than two million people lost electricity and phone service for weeks, and some villages burned tyres at night so helicopters could find them. The standing answer is a diesel generator, which costs PHP 80 to 150 a kilowatt-hour and runs out of fuel exactly when the roads it would arrive by are impassable.

Four gaps, named

Fragile infrastructure

Grids and towers fail together, and repair runs to weeks

Diesel dependency

PHP 80 to 150 per kWh, plus fuel that cannot reach a flooded road

Access inequality

A satellite terminal starts at PHP 50,000, so recovery tracks income

Solar that does not fit

Fixed arrays need days and skilled labour; lanterns cannot carry a village

Each gap points at a different failure, so anything worth building has to answer all four at once. That is what set the cost target, and the cost target is where this project's most interesting result comes from.

Bar comparison of energy cost per kilowatt-hour. Diesel is drawn as a range band from PHP 80 to PHP 150; Solar CommHub is a single bar at PHP 30, between 2.7 and 5 times cheaper. — Fig. 05: The rate the design has to beat. Diesel is a band because the proposal gives a range, and fuel price is the thing that moves.

Five constraints that shaped everything

Deployable

Under thirty minutes, two untrained people, no tools

Autonomous

72 hours with no sun, at a 25 W continuous load

Reaching

5 km line of sight on LoRaWAN, toward 10 km meshed

Affordable

At or below PHP 25,000 a unit

Survivable

IP67, 50 m/s wind, minus 10 to 50 C

Every one of these is a number a test could fail, which is the point. The proposal's own framing is that the system has to be simple enough for villagers to deploy, tough enough to survive a typhoon as well as cheap enough to scale.

Simulate first, then spend

The method is the part of this project worth showing. A student with a six-week deadline and a small budget has one expensive failure mode, which is buying the wrong hardware and finding out on the bench. The answer here is to put three simulations in front of every purchase, each aimed at a specific decision that would otherwise be made by guessing.

SIM 01

Size the energy system

HOMER Pro, with Tacloban irradiance from NASA POWER at 4.5 kWh/m2/day, a load profile of 25 W continuous with 50 W peaks and LiFePO4 round-trip efficiency at 95%. It minimises levelised cost of energy subject to surviving a 72 hour outage, sweeping four to seven days of typhoon cloud cover. It settles panel and battery sizing, which is most of the bill of materials.

SIM 02

Test the box before printing it

TRNSYS, on a 60 by 40 by 30 cm PETG enclosure with 2 mm walls, under 700 W/m2 of solar gain on a black surface and one metre of immersion for an hour. The outputs are internal temperature against the 50 C electronics ceiling as well as condensation risk during the fast cooling that follows a typhoon. It settles wall thickness and venting before a printer runs for a day.

SIM 03

Check the link budget

Custom Python, using Okumura-Hata path loss at 868 MHz for urban and rural terrain to give packet delivery ratio against distance, plus a rain attenuation model at 1.6 GHz for the Iridium fallback. It settles whether the 5 km claim survives contact with trees and buildings, as well as how often the expensive satellite path has to carry traffic.

Read together those three retire the three ways this design could be quietly wrong: an undersized battery, an enclosure that cooks its own electronics as well as a radio range that only exists on a datasheet. None of them was run. The models were specified down to their inputs and boundary conditions and the six weeks went elsewhere, so what the project demonstrates is the sequencing, not the results.

Four-column architecture diagram: harvest, a 300 W flexible array and MPPT charge control; store, a 48 V 2.4 kWh LiFePO4 pack at 38.8 percent of the bill of materials and a 72 hour autonomy target; link, LoRaWAN at 868 MHz with an Iridium short burst data fallback at 20.4 percent; sense, flood, wind and air-quality sensors with a low-power microcontroller. — Fig. 03: The proposed unit. The two blocks outlined in terracotta are the two that dominate its cost.

The architecture that falls out of those constraints is deliberately lopsided. Generation and sensing are cheap and replaceable. Storage and the satellite link are neither, and they carry the whole promise of a hub that still works when there is no sun and no network left to join.

So the radio plan is LoRa first with Iridium in reserve. LoRaWAN at 868 MHz costs $30 and covers five kilometres line of sight, meshing toward ten across linked hubs. Iridium short burst data costs $300 up front and $240 a year, which is more than half the annual operating budget for a link that should sit idle most of the time.

What the money said

The financial report is the one deliverable that was finished, and it is why this page exists. It prices every component against a named vendor listing in April 2025, then runs one unit out over five years.

Horizontal bar chart of the eight-line bill of materials totalling 1,468 US dollars. The 48 V 2.4 kWh LiFePO4 battery is 570 dollars or 38.8 percent and the Iridium satellite modem is 300 dollars or 20.4 percent; the remaining six items fall from 260 dollars to 30 dollars. — Fig. 01: Where the $1,468 goes. The two highlighted rows are 59.2% of the unit between them.

Two lines dominate. The 48 V 2.4 kWh LiFePO4 pack is $570, or 38.8% of the unit, and the Iridium modem is $300, another 20.4%. Together that is 59.2% of what it costs to put one hub on the ground. Everything else is small: the printed enclosure at $88, the microcontroller at $70, licensing at $50 as well as the LoRa radio at $30.

That split is not a curiosity, it is the design argument. The parts that let the system survive a blackout are the parts that cost money, so any real cost reduction has to come out of storage or the satellite path, and those are exactly what cannot be cut without losing the thing the hub is for.

Cumulative cash flow for one unit over five years, starting at minus 1,468 dollars and rising 640 dollars a year, crossing zero at 2.3 years and ending at plus 1,732 dollars. — Fig. 02: One unit against its own capital cost. Break-even at 2.3 years assumes the lease lands.

USD to build one unit

Years to break even

Return on capital, five years

Hours of autonomy by design

On the model's own assumptions one unit clears its capital cost in 2.29 years and returns 118% over five. All of that rests on a single line of income, the PHP 300,000 five-year lease to a local government unit, because the report rules out the voucher revenue the proposal had hoped for. Take the lease away and there is no payback to discuss.

The target the model refused to meet

The proposal set a unit cost target of PHP 25,000, about $442, and its executive summary repeated the figure as though it were settled. The costed bill of materials came in at PHP 83,089. That is 3.32 times the target.

The proposal also put break-even at fourteen months. The financial report, working from real prices, puts it at 2.3 years. Both numbers cannot stand, and the later one is the one with a bill of materials behind it. This is the most useful thing the project produced: an analysis with enough teeth to contradict the brief it was written to support.

A model that only ever confirms the number you started with is not doing any work.

Six weeks, two tracks

The schedule was honest about its own limits. Simulation was the graded deliverable so it took four days a week, hardware took three and the prototype count was cut from three to one to fit.

Six-week schedule with two swimlanes. The simulation track runs model building, optimisation, reconciliation and submission; the hardware track runs procurement and printing, assembly, stress testing and handover. Milestones sit at weeks two, four and six. — Fig. 04: Two tracks against one deadline, with simulation carrying the assessed work.

The risk register is the revealing part. Its stated fallback for a damaged prototype is to write the report from simulation data, which means the simulations were load-bearing from the start. In the event neither track produced a published result, and the repository meant to hold them stayed empty.

◈

What this project did not produce. No unit was built. No HOMER, TRNSYS or link-budget run was executed, so there are no simulation results to report and none are claimed here. There was no field deployment, and the proposal's deployment sentence still carries its template placeholders. Its bibliography is untouched boilerplate, so every contextual claim above is attributed to the proposal rather than asserted. Component pricing is April 2025 single-unit retail, with no volume discount, shipping, duty or assembly labour.

What I would do next

The gap between this proposal and something worth deploying is narrower than it looks, because the expensive thinking is done. The three models are specified down to their inputs and boundary conditions, and running them is about a week of work that would settle the two open questions: whether 300 W and 2.4 kWh really carry a 72 hour outage under Tacloban cloud cover, and whether 5 km survives real terrain.

The cost result points somewhere specific too. If storage and satellite are 59% of the unit, the next version does not shave the enclosure. It asks whether a smaller pack with a tighter load budget still clears 72 hours, as well as whether one satellite uplink shared across meshed hubs can serve several units instead of one each. Both are questions the existing HOMER model would answer without buying anything.

The proposal is finished thinking. What is missing is the week of compute that would tell me which parts of it are wrong.

Next project

EduBridge Analytica: a research instrument educators can run

View→