Custom open-source hardware, a native MeshCore software port, and a new platform for standalone nodes and EmergencyHam Network gateways.
At EmergencyHam Network (EHN), we’ve been exploring how different communications technologies can work together to provide practical, resilient messaging when conventional infrastructure is unavailable or unreliable.
One of those technologies is MeshCore, a LoRa-based mesh communications system that allows messages to travel between radio nodes without relying on cellular networks or the Internet.
For fixed MeshCore installations, we wanted something that combined three important characteristics: high RF output power, affordable hardware and the flexibility of a Raspberry Pi.
We wanted sufficient transmitter power to accommodate antenna cables and cavity filters while still allowing the installation to operate at the maximum permitted radiated power, where appropriate. We also wanted the flexibility of a Linux computer without having to connect a separate microcontroller-based MeshCore radio.
The result is a custom Raspberry Pi HAT built around the Ebyte E22-900M33S LoRa module, together with a native port of MeshCore that runs directly under Raspberry Pi Linux.
The hardware has now demonstrated approximately +32 dBm peak RF output (1.5 watts), and our first five fully assembled boards cost just $220, excluding the E22 radio modules.
Including the radio modules at an indicative price of $13.12 each, that works out to approximately $57 per assembled HAT, excluding the Raspberry Pi, shipping and accessories.
All five boards are operational, and the native MeshCore software has successfully exchanged messages with other MeshCore devices.
We are now preparing to release the hardware design as open source, complementing the software already available on GitHub.
Why This Matters to EmergencyHam Network
EmergencyHam Network is developing a messaging system that allows people using different communications technologies to exchange messages through a common network.
Our current working-alpha basestation supports MeshCore, Meshtastic and SMS/RCS messaging, with additional amateur radio gateways such as APRS and JS8Call under development or consideration.
The objective is to make personal and group messaging possible across these different networks, while retaining the ability to operate locally when Internet connectivity is unavailable.
An EHN basestation provides local messaging, user directory, routing and store-and-forward functions. Gateways connect the basestation to the available communications networks.
MeshCore is particularly attractive for this application because it provides independent radio messaging using inexpensive, low-power LoRa devices.
For fixed EHN installations, we wanted a MeshCore gateway that could be placed at a suitable antenna location, operate continuously, be managed remotely and provide good RF performance.
A Raspberry Pi running MeshCore directly offers an interesting solution.
However, we deliberately designed this project to be useful beyond EHN.
Two Ways to Use the Raspberry Pi MeshCore Node
The native MeshCore port supports two principal applications.
1. A Standalone MeshCore Node
The Raspberry Pi can operate as an independent MeshCore node, communicating with other compatible MeshCore devices over LoRa.
The native software handles radio operation, MeshCore messaging, node identity and persistent configuration directly on the Pi.
A local browser interface provides access to node settings, contacts, channels, messages and diagnostic information.
The software also supports the published MeshCore companion protocol, allowing compatible companion clients to communicate with the node.
This makes the platform suitable for fixed mesh installations, experimentation, Linux application development and integration with local monitoring systems.
Unlike a conventional microcontroller-based MeshCore device, the Pi provides a complete Linux environment with networking, storage, additional interfaces and the ability to run other applications.
No EHN basestation is required. The Pi can function as a standalone MeshCore node.
2. An EmergencyHam Network Gateway
The second application connects the Raspberry Pi MeshCore node to an EHN basestation.
In this configuration, the Pi runs the same native MeshCore radio software but also provides a separate IP interface through which the basestation can exchange messages with the MeshCore network.
The basestation remains responsible for EHN-specific functions such as user addressing, group messaging, routing and message queues.
The MeshCore port remains responsible for its native radio and messaging operations.
This separation is deliberate. We want to preserve compatibility with upstream MeshCore rather than create a proprietary implementation that works only with EHN.
The arrangement also allows the radio node to be installed away from the basestation, connected through a local IP network.
For example, the Pi and HAT could be located near an antenna installation while the basestation runs on another computer elsewhere in the building.
A Browser Interface for Local and Remote Management
One advantage of running MeshCore on a Raspberry Pi is the ability to provide a browser-based management interface.
We’ve developed a Pi-hosted interface that can be accessed from another computer on the local network, without requiring a keyboard, mouse or display connected to the Pi.
The interface provides access to node configuration and operational information, including:
- Node identity and radio configuration
- Contacts and channels
- Sending and reviewing messages
- Radio advertisements
- Node status and diagnostics
The browser interface is currently served on port 8099.
The native software also provides a MeshCore companion interface on port 5040, allowing compatible companion clients to interact with the node.
In the current alpha, the companion bridge supports one client session at a time. The browser service occupies that session while running, so it must be stopped before connecting a separate companion client directly.
This is a known limitation of the current implementation and an area for future improvement.
For fixed installations, the browser interface provides a convenient way to configure and monitor a headless node over the local network.
Environmental and Power Telemetry
The custom HAT includes more than the LoRa radio.
We incorporated several monitoring functions intended to be useful for fixed, unattended and battery-powered installations.
These include an SHT40 temperature and humidity sensor, an LPS22HH barometric pressure sensor, and an ADS1015 analog-to-digital converter for monitoring supply and battery voltages.
The board provides voltage-monitoring inputs for battery voltage, supply input, output and an auxiliary source.
An optional software service reads the onboard sensors and supplies timestamped measurements to the native MeshCore runtime.
Importantly, the telemetry uses MeshCore’s existing request-and-reply mechanism and permissions. Enabling the sensor service does not automatically enable telemetry broadcasts.
During testing, another MeshCore device successfully requested and received battery voltage, temperature, humidity and pressure readings originating from the HAT.
These are currently engineering and operational measurements rather than calibrated instrumentation. In particular, the onboard temperature sensor measures the environment around the Pi and HAT, which can be noticeably warmer than the surrounding air.
Nevertheless, these facilities provide useful possibilities for monitoring the operating conditions of a remote mesh node.
Designing the Custom Raspberry Pi HAT
The hardware was developed in KiCad and uses the Ebyte E22-900M33S LoRa module, based on the Semtech SX1262 radio family.
The module communicates with the Raspberry Pi through SPI, with additional GPIO connections for radio reset, interrupts, status and transmit/receive switching.
Rather than simply connecting a LoRa module to the Pi’s GPIO header, we designed a complete HAT for fixed-node experimentation and potential unattended operation.
The board includes protected 5 V power distribution, onboard environmental sensors, voltage-monitoring inputs, provision for a hardware watchdog, fan and auxiliary switched-output connectors, and an expansion interface providing I2C and GPIO connections.
The design targets Raspberry Pi 3B and Pi 4 installations.
A dedicated 5 V power input allows the board and Pi to be powered from an appropriately rated external supply, subject to the documented power-path requirements.
The hardware also provides for a watchdog circuit intended to support recovery from system failures, although automatic watchdog operation is not yet implemented in the current software.
Similarly, the fan and auxiliary outputs provide options for future development but are not currently controlled by the native runtime.
The intention was to create a flexible hardware platform rather than a board dedicated to one narrowly defined application.
From KiCad to Working Hardware
The complete HAT was designed in KiCad and manufactured by PCBWay.
We ordered an initial batch of five fully assembled boards. All five are operational.
The first batch cost approximately $220 for the five boards, excluding the E22-900M33S radio modules, which were supplied separately.
That works out to $44 per assembled board before the radio module.
Using an indicative E22 module price of $13.12, the estimated cost becomes:
| Item | Cost per HAT |
| Manufactured and assembled PCB | $44.00 |
| E22-900M33S radio module | $13.12 |
| Total | $57.12 |
The total for five complete HATs at that module price would be approximately $285.60, excluding the Raspberry Pis, shipping, taxes, antennas and other accessories.
These figures reflect our prototype manufacturing cost and an indicative module price, not a guaranteed future selling price.
For a custom board providing a high-power LoRa radio, onboard monitoring and additional hardware interfaces, we consider this a very encouraging result.
We intend to publish the KiCad project files, schematic, PCB layout, manufacturing outputs, component information and connector documentation.
We also plan to make the PCBWay manufacturing project publicly available so other developers can potentially order boards without having to arrange manufacturing from scratch.
RF Performance: Approximately 1.5 Watts Measured
Suggested image: Photograph of the RF test setup or a measured power-versus-drive chart.
One of the original objectives was to obtain high RF output power at a reasonable cost.
The E22-900M33S includes an external RF power amplifier rated for up to +33 dBm, approximately 2 watts.
During early hardware testing, we demonstrated high-power operation. However, after a series of software changes, we found it necessary to revisit the amplifier configuration and transmit-power controls.
With the latest alpha software, we have now repeated the measurements using a calibrated spectrum analyzer connected at the E22 antenna port, with the hardware powered from a 5 V supply.
The analyzer was configured to capture the peak of a transmitted MeshCore advertisement.
The results were:
| MeshCore UI setting | Measured RF output |
| −9 dBm | +21.40 dBm |
| 0 dBm | +28.23 dBm |
| +3 dBm | +28.81 dBm |
| +6 dBm | +31.20 dBm |
| +9 dBm | +31.82 dBm |
| +12 dBm | +31.82 dBm |
The maximum observed output was approximately +32 dBm, equivalent to 1.5 watts.
An important detail is that the MeshCore UI transmit-power setting controls the SX1262 drive level feeding the external amplifier, rather than directly representing the final RF output.
In our tests, the amplifier reached its measured output plateau at a +9 dBm drive setting, with no additional output observed at +12 dBm.
We estimate approximately 1 dB of measurement uncertainty due to the test connections and measurement method. These are engineering measurements rather than formal RF compliance measurements.
This output capability provides useful flexibility when configuring fixed installations, particularly where a cavity filter may be desirable to reduce interference or improve operation at shared radio sites.
The final transmitter setting must account for antenna gain, feedline and filter losses, and the applicable regulatory limits.
The result is close to our original design objective: a reasonably priced, high-power MeshCore radio platform that can be configured for demanding fixed installations.
Porting MeshCore to Raspberry Pi Linux
The software development has been as important as the hardware design.
MeshCore was developed primarily for embedded microcontroller platforms. Running its native functionality directly on Raspberry Pi Linux required implementing the platform-specific interfaces normally provided by those environments.
Our port uses RadioLib to communicate with the SX1262 radio, together with Linux SPI and GPIO facilities.
The objective has been to preserve existing MeshCore functionality and behavior while replacing the hardware-dependent portions needed to operate on the Pi.
This is not a Python gateway communicating with a separate MeshCore radio. The Raspberry Pi itself runs the native MeshCore radio and messaging software.
There is no separate ESP32 or other microcontroller running MeshCore firmware.
We have also established development rules intended to keep EHN-specific functionality separate from the native MeshCore implementation wherever possible.
This should help maintain compatibility with upstream MeshCore development and preserve the ability to use the Pi as an independent MeshCore node.
Testing the Working Alpha
Our latest documented standalone hardware validation was completed on October 30, 2026, using a Raspberry Pi 3B running 64-bit Raspberry Pi OS Lite.
The software was built from a fresh source checkout and successfully initialized the E22-900M33S radio.
We verified that node identity and settings survived restarts and that the browser interface could configure the radio and perform messaging operations.
For RF testing, we used a LilyGo T-Beam running MeshCore as a second node.
The Pi successfully transmitted an advertisement received by the T-Beam, received and decrypted an incoming direct message, and sent a reply that was confirmed at the receiving device.
We also verified live environmental and voltage telemetry requests and replies over the radio.
Together with the subsequent RF power measurements, these tests establish that the custom HAT and native software port are functioning together as a practical MeshCore node.
There is still work ahead. The software remains alpha, and further testing is required across different hardware configurations, operating conditions and EHN gateway arrangements.
The project is experimental and should not yet be relied upon for critical emergency communications.
Open Source and What’s Next
The native Raspberry Pi MeshCore software and hardware is already available on GitHub:
https://github.com/emergencyhamnet/meshcore-pi-port
The repository includes the native Pi implementation, build scripts, system services, browser interface and installation documentation.
https://github.com/emergencyhamnet/meshcore-pi-hat
Our immediate priorities are continued software testing, improving installation and operation, validating the EHN gateway integration and making the hardware easy for others to reproduce.
Leave a Reply