In our previous post, we explained why we chose Wi-SUN for Okra’s mesh communications. In short, we needed a radio technology with low module cost, reliable range in the hundreds of meters, and enough bandwidth for both energy data and Pod firmware updates of around 600 KB.
Finding a border router: Beacon V1
The central device in a Wi-SUN network is the border router, which is responsible for forwarding all the data from the closest devices to and from the cloud, either by cellular or satellite connection. The first version of our Wi-SUN border router, called Beacon, consisted of three main parts:
- BeaglePlay, a single-board ARM computer with a Texas Instruments CC1352P7 wireless MCU supporting Sub-1 GHz and the TI Wi-SUN stack
- GL-X300B, a 4G LTE industrial gateway from GL.iNet
- An IP67 outdoor enclosure from Takachi
Beacon v1 was ideal for an MVP and for validating Wi-SUN in the field. During testing, however, two issues stood out. First, the TI Wi-SUN border-router stack was not stable enough for our needs. Because BeaglePlay integrates the Sub-1 GHz chip, we could not swap only the radio. Second, using a full industrial 4G Wi-Fi router with its own cloud added cost we did not need.
Since Beacon is not a high-volume product or a major revenue line, our first thought was to adopt an off-the-shelf Wi-SUN gateway. Most available gateways, however, target the European market with heavy compliance requirements and price points often above €1,000. That was not viable.
Deciding to build our own: Beacon V2
We considered customizing an existing IoT gateway or even using an industrial mini-PC, but we wanted tighter control over the hardware platform. We chose to design a custom PCB around the NanoPi Neo Core, a compact Linux SBC from FriendlyElec. A Zigbee-gateway design based on the same NanoPi was made available to us as a reference, which helped initially, though we still changed a lot to meet Beacon’s requirements.
The big advantage of this NanoPi variant is that all key interfaces are exposed on pin headers, which makes clean integration into a custom carrier PCB practical.
Key components of Beacon
- Wi-SUN radio. After testing, we found Silicon Labs best fit our needs and selected the EFR32FG28. It supports higher TX power, which helps with range and link robustness.
- Cellular modem. We started with the MCUZone 4G module designed specifically for NanoPi boards.
- Enclosure. We reused an outdoor enclosure originally intended for an outdoor 4G router, which is functionally close to Beacon.
- Quality-of-life extras. We added a temperature sensor, a Wi-Fi module for local AP access during troubleshooting, and downward-facing LEDs that indicate power and connection status.
Prototyping
We manufacture in China, but we needed quick prototype turnarounds. We ordered two prototype PCBs from PCBWay, and our lead hardware engineer, Marco, hand-assembled them in our office.
Lab and field validation
Earlier, we had deployed Beacon v1 in the Abababubu village in Nigeria. The TI Wi-SUN stack struggled to reliably support 90 clients, so we stabilized the site by splitting the load across two Beacons.
To verify that the new Beacon with the Silicon Labs radio could handle our target scale, we built a Wi-SUN staging setup in our Porto office. It currently runs 200+ Cicadas with custom firmware. Cicada is a communications module that can be added to Okra Pod V3 units that lack Wi-SUN; for the lab we flashed a special firmware so each Cicada acts as a standalone Wi-SUN client and generates adjustable random traffic to simulate network load. With some firmware adjustments, the new Beacon handled this network of 200+ Cicadas plus around 10 Leafs and Pods.
We then returned to the field. The first new Beacon went to Abababubu. It runs on VSAT and now supports the same 90-device network that previously required two old Beacons to remain stable.
Next, we upgraded Burum. Unlike Abababubu, Burum has cellular coverage, so the Beacon runs on 4G. The MCUZone modem that behaved in Porto and Abuja dropped offline frequently in Burum. Limited Linux driver quality made troubleshooting difficult. Because Beacon uses a standard mini-PCIe slot, we quickly tested a Quectel EG21-G module in the office and deployed it in the field. That swap resolved the 4G stability issues.
From ad-hoc checks to a proper cloud dashboard
To monitor Beacon performance - uptime, client count, link quality, and other Wi-SUN metrics, we started with the simplest thing: SSH’ing into each Beacon and running commands. That gave us snapshots, but not trends. Next, we logged locally and parsed the files with a quick Python script; useful, yet still short of what we needed.
The turning point was a lightweight service that reports Beacon telemetry over MQTT. After a few iterations, that data now powers our Grafana “OkraNet” dashboard, which surfaces:
- Uptime since last reboot, last backhaul connection time, and connection type (4G, Ethernet, or Wi-Fi)
- Number of connected nodes and per-node connectivity bars
- Signal-strength charts for nodes linked directly to the Beacon
- CPU temperature and full Beacon logs
- A visual network graph for topology insight
We also receive Slack alerts whenever a Beacon has been offline for more than six hours. With this dashboard, we can both watch live fleet health in the field and run controlled experiments on our Porto staging setup. Next up, we plan to expand these dashboards and expose most of this information to customers deploying Beacons.
Conclusion
With the design proven in both the lab and the field, we have been moving to mass production. The new Beacon architecture gives us the control we need over the radio, compute, and cellular components, while keeping costs in check and allowing fast substitutions when conditions demand it.
In the future, we plan to begin work on Beacon V3, which aims to increase reliability while reducing cost of the unit.
Learn more about Beacon: visit the OkraNet page.
