LoRa gave your community a mesh. Now give it speed. WiFi HaLow at 902–928 MHz delivers megabit throughput at LoRa-class range — no cell towers, no ISP, no internet required. This guide builds a private, encrypted, city-scale mesh network using Heltec HaLow hardware, 802.11s mesh topology, and Reticulum smart routing with Sideband messaging on Android.
If you've deployed a LoRa or Meshtastic network, you already know the magic of sub-GHz radio: signals that punch through walls, trees, and urban clutter; kilometer-range links that 2.4 GHz WiFi can't dream of; resilient mesh topologies that route around failure. You also know the limitation — LoRa's usable data rate tops out around 5 kbps under ideal conditions. That's enough for a text message. It is not enough for a photo, a voice note, a file, or anything richer than a line of text.
WiFi HaLow (802.11ah) is what happens when you apply WiFi engineering discipline to sub-GHz radio. It operates in the 902–928 MHz ISM band — the same spectrum LoRa uses — and inherits all of LoRa's physical-layer advantages: long range, superior building and foliage penetration, and drastically lower path loss compared to 2.4 GHz. But because it's based on a modified WiFi PHY and MAC layer, it achieves data rates that are three to four orders of magnitude higher than LoRa. That gap is the difference between a text mesh and a media mesh.
This guide shows you how to build that media mesh using a hardware stack that's available today, costs less than a used laptop per node, and integrates with the Reticulum and Sideband tools you may already use.
This guide describes frontier territory. HaLow hardware (specifically the Heltec HD01 and H7608) is real, available, and works well as a point-to-point bridge — that part is proven by many hobbyists. Running Reticulum over a HaLow bridge is also proven at the experimenter level: there's an active Reticulum GitHub discussion thread where people have successfully run iperf3 and Reticulum Shell over HaLow bridges with good results.
What does not yet exist is a documented community-operated city-wide HaLow mesh running Reticulum and Sideband at scale. The architecture described here is technically sound and the components are individually proven — but the full combination is a design proposal, not a report from an established network. Think of this as a well-researched build guide for something you'd be among the first to deploy. The RF physics, the Reticulum configuration, and the hardware specs have all been verified — the social and operational questions of running a community mesh are yours to discover.
This guide builds on the earlier Node Star field guides covering Reticulum RNodes, multi-interface node setups, and the Sovereign Stack. You don't need to have read them all to follow this guide — it's written to stand alone. But if you're already running Reticulum and Sideband on a LoRa mesh, you're about 80% of the way to understanding what we're building here.
It's easy to misread HaLow as a replacement for LoRa. It isn't — or at least, not entirely. It's a different tool with different trade-offs. The table below shows how they compare across the dimensions that matter most for community mesh deployments.
| Property | LoRa / Meshtastic | WiFi HaLow (802.11ah) |
|---|---|---|
| Frequency | 915 MHz (US) | 902–928 MHz (US ISM) |
| Max data rate (raw) | ~5 kbps (SF7) · 0.3 kbps (SF12) | 150+ Mbps (peak) · 1–10 Mbps (practical) |
| Range (1 hop, outdoor) | 2–15 km (low BW, low rate) | 0.5–3 km (1–4 MHz BW setting) |
| Building penetration | Excellent | Excellent (same RF physics) |
| Foliage penetration | Excellent | Excellent |
| File / photo transfer | Very slow / impractical | Fast and practical |
| Power draw | Very low (mW) | Moderate (~1–3 W active) |
| Node cost | $30–80 | $80–140 per pair |
| Routing layer | Meshtastic flooding / MeshCore | 802.11s HWMP + Reticulum |
| Encryption | AES-128 (Meshtastic) | WPA3 (mesh) + Reticulum LXMF |
| Max hops practical | 3–5 (flooding penalty) | 5+ (HWMP path selection) |
| Phone connection | BLE or WiFi AP | 2.4 GHz WiFi AP on the same device |
| License required | None (FCC Part 15) | None (FCC Part 15) |
The right framing: LoRa is your ultra-long-range, ultra-low-power ping network — ideal for GPS beacons, emergency alerts, and minimal-bandwidth coordination. HaLow is your neighborhood data link — sufficient range for a city mesh, fast enough to carry Sideband messages with photos and voice attachments. They're complementary, not competing. And as we'll show in Phase 3, Reticulum can run both simultaneously and route intelligently between them.
HaLow's performance claims are backed by independent testing, not just manufacturer spec sheets. In early 2024, Morse Micro conducted a live 802.11ah video call demonstration on a San Francisco beach — a high-interference urban environment — achieving 11 Mbps at 500 meters and a stable 1 Mbps link at 1.8 miles (3 km). Later that year at Joshua Tree National Park, they extended this to a record 10 miles (16 km) at 2 Mbps, using a standard Raspberry Pi 4 evaluation kit at 21 dBm with a 1 dBi antenna. A peer-reviewed measurement study using Newracom NRC-7292 hardware confirmed approximately 6 Mbps throughput at 1 km using 2 MHz bandwidth at 23 dBm — which closely matches the Heltec hardware used in this guide.
For the Reticulum integration specifically: a discussion thread on the official Reticulum GitHub documents experimenters successfully running iperf3 speed tests and the Reticulum Shell protocol over HaLow bridges. The combination works. The Reticulum AutoInterface mechanism sees a HaLow bridge as an ordinary local network — which is exactly what it is — so no special driver support is needed.
What hasn't been documented yet is a full community deployment: multiple operators, distributed nodes, shared Mesh IDs, Sideband running across the whole thing at neighborhood scale. That's what this guide is architecting toward. The components are proven. The city mesh is the experiment.
If you already have Heltec v4 LoRa RNodes deployed — or any Meshtastic-compatible hardware — you don't have to retire them. Reticulum's multi-interface design lets a single installation connect to both your HaLow bridge and your LoRa RNode simultaneously. Messages route over whichever path is available and fastest. LoRa becomes your always-on fallback for critical short messages; HaLow becomes your high-speed lane for rich content. This guide shows you exactly how to wire that up.
WiFi HaLow is the marketing name for the IEEE 802.11ah amendment, ratified in 2017 and gaining serious traction in hardware since 2022. Understanding a few of its core design decisions will help you make better choices about antennas, channel settings, and placement.
All of HaLow's range advantages come directly from operating at frequencies below 1 GHz. The physics are simple: at lower frequencies, radio waves have longer wavelengths, experience less free-space path loss per unit distance, diffract more readily around obstacles, and penetrate materials (concrete, wood, foliage) more effectively.
The difference between 915 MHz and 2.4 GHz in a real urban environment is dramatic. A 2.4 GHz WiFi signal attenuates roughly 3–6 dB more per doubling of distance than a 915 MHz signal in equivalent conditions. Over a mile, that difference compounds to tens of dB — the difference between a usable link and no link at all. This is why your LoRa RNodes can reach across a city and your WiFi router can't reach to the end of your street.
Channel bandwidth is the single most important tuning parameter in a HaLow deployment. It controls both your maximum data rate and your effective range. Understanding this trade-off lets you configure your network intelligently for your terrain and use case.
Rates are practical usable throughput at 1 hop. Range scales inversely — narrower bandwidth enables longer links at lower speed. Start with 2–4 MHz for city mesh deployments.
In any 802.11 network operating in half-duplex mode (which HaLow does), each relay hop roughly halves your effective throughput because the relay node must receive and re-transmit on the same channel. A 4 Mbps single-hop link becomes approximately 2 Mbps at two hops and 1 Mbps at three hops. Reticulum's multi-interface routing helps by finding the most direct path, and proper node placement minimizes unnecessary hops.
Heltec HaLow hardware supports two distinct operating modes. You'll start with the first and grow into the second:
One unit acts as Access Point (AP), the other as Station (STA/Client). The pair forms a single wireless bridge — a transparent point-to-point Ethernet link. This is the simplest possible configuration. Two nodes, one link, both ends connect to normal IP networks. Ideal for first-time setup, testing, and simple two-location links.
Multiple nodes form a self-organizing multi-hop mesh. One unit is designated as the Mesh Gate (it provides the backbone IP address space and announces the mesh). All others join as Mesh Points. Nodes that can hear each other auto-form links; HWMP routing discovers the best path between any two endpoints. This is the city mesh mode.
Before you spend a dollar on hardware, understand the regulatory environment. The good news is short: HaLow at 902–928 MHz for hobbyist use is fully legal in the United States with no license required. The ISM band (Industrial, Scientific, and Medical) has been intentionally reserved for exactly this kind of unlicensed low-power experimentation.
FCC Part 15 unlicensed operation in the 902–928 MHz ISM band. No amateur radio license required. No special permits. Stay within the module's certified power limits (typically 21–27 dBm EIRP depending on antenna gain). This is the same regulatory category as your WiFi router, Bluetooth headphones, and LoRa RNodes.
FCC Part 15 devices must accept interference from other devices and may not cause harmful interference to licensed services. In the 902–928 MHz ISM band, the FCC permits up to 30 dBm (1 watt) EIRP for frequency-hopping spread spectrum systems.
Know your hardware version before calculating EIRP. The Heltec HD01 has two distinct power levels: V1 and V1.1 transmit at 21±1 dBm, while V2 (the current shipping version as of 2025) transmits at 27±1 dBm. The difference matters significantly for antenna selection. With a V2 unit at 27 dBm, adding even a 3 dBi antenna puts you at 30 dBm EIRP — right at the legal limit. A 5 dBi antenna on a V2 exceeds it. The fix is simple: reduce transmit power in the web UI. But you need to know which version you have. Check the silk print on the PCB or the product listing before choosing antennas.
EIRP (Effective Isotropic Radiated Power) = transmit power (dBm) + antenna gain (dBi) − cable losses. The 30 dBm limit is the ceiling for your total system EIRP, not just the radio output power.
| Parameter | FCC Part 15 Limit (902–928 MHz) | Heltec Hardware |
|---|---|---|
| Max EIRP (spread spectrum) | 30 dBm (1 W) | 21 dBm (V1/V1.1) · 27 dBm (V2) |
| License required | None | None |
| Amateur radio license needed | No | No |
| Commercial use restrictions | None for Part 15 | Check module FCC cert |
| Public infrastructure mounting | Requires property permission | Same as any antenna |
A few common-sense rules that keep you on good terms with neighbors, property owners, and the regulatory environment:
If you have a V2 HD01 (27 dBm output), you're starting very close to the 30 dBm legal limit before you've added any antenna gain at all. A 5 dBi omnidirectional antenna on a V2 puts you at ~32 dBm EIRP — over the limit. The solution is to reduce transmit power in the web UI (drop to 23–24 dBm, which gives you a comfortable 3–4 dBi of antenna headroom). The V2's higher power output is genuinely useful for longer links — just account for it. If you're using the older V1/V1.1 (21 dBm), a 7–8 dBi antenna keeps you within limits and is the sweet spot for city mesh deployment.
The Heltec WiFi HaLow product line is the most accessible entry point into 802.11ah hardware as of 2026. Their devices are FCC-certified, ship with a clean web UI for configuration, support both bridge and 802.11s mesh modes, and are priced for hobbyist experimentation rather than enterprise deployment. Two models matter for this guide.
192.168.100.1 or 10.42.0.1 — full configuration without CLI| Deployment Size | Hardware | Approx. Total |
|---|---|---|
| Minimum (2 nodes) Point-to-point link test |
1× HD01 pair + 2× upgraded antennas | ~$120–180 |
| Starter Mesh (3–4 nodes) Small neighborhood coverage |
1× HT-H7608 (Mesh Gate) + 2× HD01 pairs + antennas + power | ~$350–550 |
| City Mesh (6–8 nodes) Multi-neighborhood coverage |
2× HT-H7608 + 4× HD01 units + antennas + enclosures + solar | ~$800–1,400 |
| Hybrid add-on Per existing LoRa node |
Reuse existing LoRa RNodes as Reticulum interfaces alongside HaLow | $0 (existing hardware) |
Before building a mesh, build a bridge. One AP unit, one STA unit, a clear line of sight or near-line-of-sight between two points a mile apart. Verify the link, measure throughput, and prove to yourself that the hardware performs before scaling up. This is always the right starting point — it isolates configuration problems and gives you baseline performance numbers.
Expected outcome: Stable link at 1 mile with 1–10 Mbps throughput depending on bandwidth setting and antenna quality. Sideband on Android visible on both ends.
Power both HD01 units via USB-C. Use a quality 5V 2A adapter — thin phone charger cables can cause voltage drop and flaky behavior. The units take 30–60 seconds to boot. Each unit broadcasts a default 2.4 GHz WiFi network (SSID usually HT-HD01-xxxx) and the default password is heltec.org.
Connect a laptop or phone to the unit's 2.4 GHz WiFi network (SSID: HT-HD01-xxxx, password: heltec.org). Open a browser and try 192.168.100.1 first — that's the current default for recent firmware. If that doesn't respond, try 10.42.0.1. Legacy firmware may use 192.168.1.1. Log in with username root and password heltec.org.
In the web UI, navigate to Wizards → Standard WiFi HaLow and select AP (Access Point) mode. Set your HaLow configuration:
[HaLow Configuration — AP Unit]
Mode: AP (Access Point)
SSID: YourMeshName2026 # your group's shared mesh name
Password: YourStrongPassphrase # memorable, not guessable
Bandwidth: 4 MHz # start here — balances range and speed
Channel: US 902–928 MHz default
TX Power: see note # V1/V1.1: 21 dBm · V2: reduce to 23–24 dBm if using 5+ dBi antenna
CONFIGConnect to the second unit's 2.4 GHz WiFi and repeat. This time select STA (Station/Client) mode and enter the identical SSID and password you set on the AP unit. Same bandwidth, same channel.
[HaLow Configuration — STA Unit]
Mode: STA (Station / Client)
SSID: YourMeshName2026 # must match AP exactly
Password: YourStrongPassphrase # must match AP exactly
Bandwidth: 4 MHz # must match AP exactly
CONFIGSwap in your 900 MHz external antennas on both units. Position each unit with some elevation if possible — even a meter of height above surrounding clutter improves link reliability significantly. Save and reboot both units. The HaLow link should form within 30–90 seconds. The web UI on the STA unit will show signal strength and link status once associated.
Before deploying at distance, verify locally. Connect a device to each unit's 2.4 GHz AP. Ping across the bridge — you should see latency under 10 ms for a direct local test. Then run iperf to measure throughput:
# On one machine (server side):
$ iperf3 -s
# On the other machine (client side, replace IP with server's IP):
$ iperf3 -c 192.168.1.100 -t 30 -i 5
# Expected local output (units adjacent, 4 MHz BW):
[ ID] Interval Transfer Bitrate
[ 5] 0–5 sec 25.0 MB 40.0 Mbits/sec
[ 5] 5–10 sec 24.8 MB 39.6 Mbits/sec
BASHLocal throughput will be much higher than deployed range — this test confirms the bridge is working, not that it has the range you'll need. The deployed-range test comes next.
Place the units at your target deployment locations — ideally 1 mile apart with some elevation. Re-run ping and iperf. With 4 MHz bandwidth and decent 5–7 dBi antennas, expect 1–5 Mbps at 1 mile. If throughput is lower than expected, first check RSSI in the web UI status page. An RSSI below -80 dBm indicates antenna or siting problems more likely than hardware failure.
# Expected deployed output (1 mile, 4 MHz BW, 5 dBi antennas):
[ ID] Interval Transfer Bitrate
[ 5] 0–5 sec 1.25 MB 2.0 Mbits/sec
[ 5] 5–10 sec 1.6 MB 2.6 Mbits/sec
# Check link quality — target RSSI above -75 dBm for reliable multi-Mbps
# Web UI → Status → HaLow Interface → Signal Strength
BASHEach Android phone should connect to its nearest node's 2.4 GHz WiFi AP — the same AP it would use to access any WiFi hotspot. Once connected, open Sideband and navigate to Menu → Connectivity → Enable WiFi/AutoInterface. Announce your LXMF identity. If Reticulum is running on a machine connected to the bridge (even a laptop), the phone will discover other LXMF peers on the network almost immediately.
You have a working Phase 1 when: (1) iperf shows at least 1 Mbps end-to-end at your deployment distance, (2) ping across the bridge is stable with no loss, and (3) Sideband on both phones can exchange messages via the bridge. Any of these failing points to a specific problem the troubleshooting section can help diagnose.
Once you have a working point-to-point link, the next step is to grow it into a true multi-hop mesh. 802.11s mesh mode transforms your collection of independent bridge links into a single self-organizing network — add a node with the right credentials and it joins automatically. This is the model that makes a city mesh scalable: community members buy compatible nodes, program the same Mesh ID and passphrase, and contribute coverage just like agreeing on a Meshtastic channel setting.
Expected outcome: Any phone on any node's 2.4 GHz AP can reach any other phone on any other node's AP, automatically, via HWMP mesh routing.
Every 802.11s mesh needs at least one Mesh Gate — the node that anchors the IP address space and announces the mesh to joining Mesh Points. The H7608 is the purpose-built choice for this role and is the most reliable option for Mesh Gate. If you're starting with only HD01 units, you can designate one as Mesh Gate — but be aware that 802.11s mesh support on the HD01 was only added in firmware version 2.8.5. Make sure all HD01 units are updated to current firmware before attempting mesh configuration.
# Heltec Web UI → Wizards → 802.11s Mesh Wizard
[Mesh Gate Configuration]
Role: Mesh Gate
Mesh ID: EugeneMesh2026 # your group's shared club name
Passphrase: YourStrongMeshSecret # strong shared secret
Bandwidth: 4 MHz # 2 MHz for max range, 4 for balance
Channel: US 902–928 MHz defaults
Bridge Mode: Enabled # recommended for traffic forwarding
CONFIGEach additional node — including both units from your Phase 1 HD01 pair — gets configured as a Mesh Point. The settings must be identical to the Mesh Gate on every node: same Mesh ID, same passphrase, same bandwidth, same channel band. Save and reboot each node.
[Mesh Point Configuration — All Other Nodes]
Role: Mesh Point
Mesh ID: EugeneMesh2026 # identical to Mesh Gate
Passphrase: YourStrongMeshSecret # identical to Mesh Gate
Bandwidth: 4 MHz # identical to Mesh Gate
Channel: US 902–928 MHz defaults
CONFIGAfter all nodes reboot, check the Mesh Gate's web UI under Status. You should see all active Mesh Points listed as connected peers with RSSI and link speed data. Nodes that can hear each other directly will show as 1-hop peers; nodes only reachable through an intermediate will show as 2-hop, and so on.
# From any device connected to a node's 2.4 GHz AP,
# ping across to a device on another node:
$ ping 192.168.1.105 # IP of device on a different node
# Expected: stable pings, <20ms within 2 hops
64 bytes from 192.168.1.105: icmp_seq=1 ttl=64 time=8.4 ms
64 bytes from 192.168.1.105: icmp_seq=2 ttl=64 time=9.1 ms
BASHOnce your Mesh ID and passphrase are established, sharing the network is simple. Tell a trusted community member your Mesh ID and passphrase. They buy a compatible Heltec HaLow unit, configure it as a Mesh Point with those credentials, and deploy it somewhere with good antenna placement. The new node announces itself, the Mesh Gate sees it, HWMP builds paths through it. No further configuration required — it's exactly the Meshtastic "buy a node and join the channel" experience, but with megabit throughput.
The HD01's 802.11s Mesh Point capability was added in firmware v2.8.5 and is new enough that community testing at scale is limited. For a reliable first mesh deployment, use at least one HT-H7608 as your Mesh Gate — its mesh support is more mature and better documented. HD01 units work well as Mesh Points once firmware is current, but if your mesh fails to form, the H7608-as-Gate path is the proven fallback. To update firmware: web UI → System → OTA Upgrade.
Share your Mesh ID and passphrase only with trusted community members, at least initially. The WPA3 mesh passphrase controls who can inject traffic into your mesh fabric. An untrusted node with your passphrase can observe all unencrypted mesh traffic. Reticulum/LXMF encryption protects message content end-to-end even from other mesh participants, but the mesh transport layer itself is open to all participants who know the passphrase.
The 802.11s mesh gives you a functioning Layer 2 network. Reticulum transforms it into an intelligent, cryptographically-routed messaging network with automatic peer discovery, end-to-end encryption, and optional hybrid LoRa fallback. Sideband makes the whole thing accessible from Android phones without any additional configuration beyond joining the 2.4 GHz WiFi AP.
Reticulum treats the HaLow mesh exactly like a normal IP/WiFi network. It doesn't need to know about 802.11s internals, bandwidth settings, or radio parameters. From Reticulum's perspective, it has a network interface with some latency and throughput characteristics — that's enough. This is the elegance of the layered architecture: each layer does its job, and the layers above don't need to care about the details below.
The simplest way to get Reticulum running on your HaLow mesh is to run it on a laptop or desktop that's connected to one of the node's 2.4 GHz WiFi APs. This is ideal for testing and for members who keep a machine running.
# Install Reticulum (Python 3.8+ required)
$ pip install rns --upgrade
# Start Reticulum once to generate default config
$ rnsd --daemon
# Config file location
$ cat ~/.reticulum/config
BASH# ~/.reticulum/config — minimal config for HaLow WiFi mesh
[reticulum]
enable_transport = True # relay for other nodes if this machine stays on
share_instance = Yes
[interfaces]
[[AutoInterface]]
type = AutoInterface
enabled = Yes
# Reticulum will discover peers on the local network automatically
# via UDP multicast — works immediately on the HaLow AP's subnet
CONFIGWith AutoInterface enabled, Reticulum automatically discovers other Reticulum instances on the same subnet via UDP multicast. Any phone running Sideband on the same node's 2.4 GHz AP will immediately see announced LXMF peers — no further configuration required.
For a robust, always-on mesh node, connect a Raspberry Pi to the HaLow bridge's Ethernet port (or 2.4 GHz AP) and run Reticulum with enable_transport = True. This Pi becomes a persistent Reticulum router — it caches peer announcements, relays messages across hops, and bridges your HaLow mesh to any other Reticulum interfaces you attach (including LoRa RNodes).
# On Raspberry Pi — install Reticulum in a virtual environment
$ python3 -m venv ~/.rns-env
$ source ~/.rns-env/bin/activate
$ pip install rns
# Enable as systemd service so it starts at boot
$ sudo nano /etc/systemd/system/reticulum.service
BASH# /etc/systemd/system/reticulum.service
[Unit]
Description=Reticulum Network Stack
After=network.target
[Service]
Type=simple
User=pi
ExecStart=/home/pi/.rns-env/bin/rnsd --daemon
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
SYSTEMD$ sudo systemctl enable reticulum
$ sudo systemctl start reticulum
$ sudo systemctl status reticulum
# Verify interfaces are up
$ rnstatus
Reticulum 2.x.x running Transport on
AutoInterface Up RX: 1.2 KB TX: 0.4 KB
BASHIf you have existing Heltec v4 LoRa RNodes, you can attach them to the same Raspberry Pi via USB and run them alongside the HaLow interface in a single Reticulum instance. Reticulum manages both interfaces simultaneously and routes automatically — it prefers the faster HaLow path when available and falls back to LoRa when HaLow peers aren't reachable. This hybrid mode costs nothing extra if you already have the LoRa hardware.
# ~/.reticulum/config — Hybrid HaLow + LoRa transport node
[reticulum]
enable_transport = True
[interfaces]
[[HaLow WiFi]]
type = AutoInterface
enabled = Yes
# Discovers HaLow peers via multicast on the local subnet
[[LoRa RNode]]
type = RNodeInterface
enabled = Yes
port = /dev/ttyUSB0 # adjust to your RNode's USB port
frequency = 915000000
bandwidth = 125000
txpower = 17
spreadingfactor = 8
codingrate = 5
CONFIGReticulum builds a destination-addressed routing table from peer announcements. When a destination is reachable over both HaLow (2+ Mbps) and LoRa (5 kbps), Reticulum will route traffic toward whichever interface has the freshest, most recently-heard announcement from that destination — which will typically be the faster HaLow path. If the HaLow link fails and the only remaining announcements arrive via LoRa, traffic automatically shifts to LoRa. No configuration needed — this is built into the protocol.
Once Reticulum is running on the mesh, Android phone integration is nearly automatic:
In Android WiFi settings, join the node's 2.4 GHz network (the same HT-HD01-xxxx AP, or whatever you've renamed it). This connects the phone to the HaLow bridge's local subnet, where Reticulum is listening.
Open Sideband → Menu → Connectivity. Enable WiFi/AutoInterface. Sideband will discover the Reticulum instance on the same subnet within seconds via UDP multicast and begin announcing your LXMF identity to the network.
Tap Announce in Sideband. Within seconds, other online LXMF users anywhere on the mesh — regardless of which node they're connected to — will appear in your contacts as they announce back. Message delivery of photos and voice notes happens over the HaLow bridge at multi-Mbps speeds, compared to the minutes-per-file experience over LoRa.
HaLow's sub-GHz physics make site selection more forgiving than 2.4 or 5 GHz WiFi, but it's not magic. A few well-placed nodes will dramatically outperform many poorly-placed ones. This section covers the principles that translate directly into better coverage, longer links, and more reliable performance in real-world mid-sized city terrain.
At 900 MHz, signals diffract around obstructions reasonably well — but obstructions still attenuate the signal. Even a few meters of elevation can dramatically extend coverage by lifting the antenna above the immediate clutter (fence lines, vehicles, low buildings, dense shrubbery). For a city mesh, the goal is to get Mesh Gate nodes to elevated positions where they can see across multiple neighborhoods.
Practical elevation targets: a tall building rooftop, a hillside with line-of-sight across the valley, a rooftop mount 3–4 meters above the roofline, or even a tall pole in a backyard. You don't need 30-meter towers — even 5 meters of clear elevation above surrounding houses makes a material difference at 900 MHz.
Think of your mesh in two tiers, mirroring how cellular networks and enterprise WiFi are designed:
1–2 nodes at the highest available elevation in your deployment area. These are your HT-H7608 units, always-on, solar-powered or plugged in at a location with reliable electricity. They anchor the mesh, provide long-range backbone links (1–2+ km), and give street-level Mesh Points something to route through. Think of these as the cell towers of your mesh.
3–6+ nodes distributed across neighborhoods. These are your HD01 units, typically on second-story window ledges, rooftop edges, or attic-mounted with cable to an outdoor antenna. They connect local phones to the backbone and extend coverage into areas the backbone can't directly reach. Think of these as the distributed access points.
| Scenario | Antenna Type | Gain | Notes |
|---|---|---|---|
| General neighborhood node | Omnidirectional vertical | 5–7 dBi | Mount vertically, outdoors, elevated above roofline |
| Backbone/hilltop node | Omnidirectional vertical | 7–9 dBi | Higher gain for extended range; verify EIRP stays legal |
| Long-distance directional link | Yagi or panel antenna | 10–14 dBi | Reduce TX power to maintain legal EIRP; requires careful alignment |
| Dense urban short link (<500m) | Rubber duck / stock antenna | 2–3 dBi | Shorter links don't need high gain; avoid overdriving neighbors |
| Indoor node (testing only) | Stock or short stub | 2 dBi | Acceptable for indoor tests; real performance requires outdoor placement |
HaLow nodes are not as power-hungry as 2.4/5 GHz WiFi access points, but they're not LoRa either. An active node draws roughly 1–3 watts depending on traffic load and transmit power setting. For always-on deployments, plan accordingly:
Terrain directly affects which bandwidth setting works best. The relationship is simple: narrower bandwidth provides better sensitivity and longer range at the cost of lower throughput. Match your settings to your deployment distances:
| Terrain Type | Recommended BW | Rationale |
|---|---|---|
| Dense trees, no elevation (<800m links) | 2 MHz | Maximum sensitivity for obstructed paths |
| Suburban valley floor, typical city mesh | 2–4 MHz | Balance of range and throughput |
| Hilltop backbone to hilltop backbone | 4–8 MHz | Good line-of-sight — speed up |
| Adjacent nodes within 500m | 8 MHz | Short link, maximize throughput for media relay |
| Across a flat valley floor | 4 MHz | Good propagation — balanced setting |
The biggest barrier to a community mesh isn't technical — it's social. The best way to grow adoption is to give prospective node operators a simple, written setup card: your Mesh ID, passphrase, recommended bandwidth setting, and a QR code linking to this guide. Make it as easy as "buy this hardware, plug it in, enter these two things." Meshtastic thrived because onboarding was simple. Your HaLow mesh can work the same way.
Real-world HaLow performance depends on distance, terrain, antenna quality, bandwidth setting, and hop count. The numbers below are derived from independent testing: Morse Micro's official range demonstrations, a peer-reviewed academic measurement study (Newracom NRC-7292 hardware, similar chipset generation to Heltec), and hobbyist reports from the Hackaday and Reticulum communities. They represent realistic expectations — not marketing maximums, not worst-case pessimism. Your specific results will vary with siting and conditions.
| Scenario | Bandwidth | Antennas | Expected Throughput |
|---|---|---|---|
| Local test (units adjacent) | 4 MHz | Stock | 20–50 Mbps |
| 1 mile, clear suburban | 4 MHz | 7 dBi omni | 2–8 Mbps |
| 1 mile, moderate trees | 4 MHz | 7 dBi omni | 1–3 Mbps |
| 1 mile, dense foliage | 2 MHz | 7 dBi omni | 0.5–1.5 Mbps |
| 2 hops, 1 mile each | 4 MHz | 7 dBi omni | 1–4 Mbps |
| 3 hops (approaching limit) | 4 MHz | 7 dBi omni | 0.5–2 Mbps |
| Directional 2-mile link | 2 MHz | 12 dBi panel | 1–3 Mbps |
Even the worst-case scenario in the table above — ~500 kbps at 3 hops through moderate foliage — is still 100× faster than LoRa at equivalent range. For Sideband, 500 kbps means a 1 MB photo transfers in about 16 seconds, a 1-minute voice note in 30–60 seconds. For practical community messaging, this is a transformative improvement.
Morse Micro — San Francisco beach (high-interference urban): 11 Mbps at 500m, 1 Mbps at 1.8 miles (3 km). A live video call maintained throughout. This is arguably the most relevant real-world benchmark for city mesh use, as an urban beach is genuinely high-RF-noise territory.
Academic measurement study (NRC-7292, 23 dBm, outdoor): Nearly 6 Mbps at 1 km using 2 MHz bandwidth. This hardware is a generation similar to the Heltec devices used here. The study also confirmed sub-10ms latency at 1 km and stable links without the interference floor of an urban environment.
Hackaday hobbyist test: Solid link at 300m through a quarry with trees; the tester noted that foliage added meaningful attenuation. This is the most conservative real-world data point and a useful lower bound for obstructed suburban links.
Each node's web UI (192.168.100.1, 10.42.0.1, or the node's assigned LAN IP) provides real-time status: connected mesh peers, RSSI per peer, current link rate, traffic counters, and uptime. Check this first whenever you suspect a link issue. RSSI values to watch:
# Check Reticulum interface status
$ rnstatus
# Show known destinations (how many peers Reticulum knows about)
$ rnpath --list
# Check path to a specific destination hash
$ rnpath <destination_hash>
BASH# Run a 60-second throughput test across the mesh
# iperf3 server on one end of the mesh:
$ iperf3 -s
# iperf3 client on the other end — bidirectional test:
$ iperf3 -c <server-ip> -t 60 --bidir
# For UDP (closer to real Reticulum traffic patterns):
$ iperf3 -c <server-ip> -u -b 3M -t 60
BASHenable_transport = True on your always-on Pi node; intermittent presence causes stale routing tablesenable_transport = True is connected per network segment. Without a transport node, Reticulum's multicast doesn't cross IP subnets.ip addr to verify the interface is up. For AutoInterface, ensure the machine is actually on the HaLow bridge's subnet. Restart the rnsd service.ls /dev/ttyUSB* to confirm the RNode is visible. Verify frequency and bandwidth match the LoRa mesh settings exactly. Check rnstatus for interface error messages.The vast majority of HaLow mesh problems are configuration mismatches — one node with a different bandwidth setting, a one-character typo in the Mesh ID, or a passphrase with an invisible trailing space. Before suspecting hardware failure, factory-reset both units in a problematic link and reconfigure them side-by-side on a bench. If the link works locally, it's a siting problem. If it doesn't work locally, it's a config problem.
The city mesh you've built with 3–4 nodes is a real, functional network. It serves its immediate members, it carries Sideband messages with rich media, and it's privately encrypted. But the same architecture scales — more nodes, more neighborhoods, more capabilities — without requiring you to redesign anything. This section maps out the natural growth path.
Don't try to cover the whole city at once. Start with a reliable 2-node link, verify it thoroughly, add a third node in a new neighborhood, verify again, repeat. Each new node is a test of your mesh configuration's openness — if it auto-joins cleanly, your configuration is correct. If it doesn't, you want to find out with 3 nodes rather than 8.
A second hilltop Mesh Gate dramatically expands the coverage area and provides resilience — if one backbone node goes offline, the other keeps the mesh alive. Place your second HT-H7608 at a different elevated location with as much geographic separation from the first as practical. The two backbone nodes should ideally have line-of-sight between them for a reliable high-quality backbone link.
A Raspberry Pi at each backbone node running Reticulum with enable_transport = True makes the mesh dramatically more reliable for messaging. Transport nodes cache peer announcements, relay messages for peers that are offline, and bridge your HaLow mesh to other Reticulum networks (including LoRa meshes in other parts of the city or region).
With a multi-Mbps mesh operational, you can layer on additional capabilities from the Node Star Sovereign Stack guide: IPFS for mesh-hosted files and community documentation; offline maps pinned to IPFS for download by any mesh node; Lightning Network payments for compensating node operators; and OrbitDB for shared application state like community bulletin boards. The HaLow mesh's bandwidth makes these genuinely usable in a way that LoRa's throughput never could.
The technical infrastructure is only as good as its human infrastructure. Write a simple onboarding guide for your Mesh ID and passphrase. Create a Signal group or Element room for node operators. Document where nodes are deployed (privately, for the operator group). Establish informal norms about bandwidth etiquette, node reliability expectations, and who to contact if a link goes down. The mesh that survives and grows is the one with a community behind it.
The HaLow ecosystem is maturing rapidly. As of 2026, Heltec's line provides the best combination of price, availability, and documentation for hobbyist deployment. As the ecosystem grows, watch for:
What you're building here has real precedent at the component level but is genuinely new at the system level. HaLow bridges work. Reticulum over WiFi works. Sideband over Reticulum works. Nobody has yet published a field report of a community-operated HaLow city mesh doing all three together at neighborhood scale — which means you'd be among the first.
The Meshtastic network grew from zero to thousands of nodes because the model worked: low barrier to entry, common channel settings, instant interoperability. The HaLow city mesh can grow the same way, at the next level of capability. Start with a single verified 1-mile link. Grow one neighborhood at a time. Document what works. The people who build it first write the guide that comes after this one.
| Item | Model / Spec | Role | Approx. Cost |
|---|---|---|---|
| HaLow Bridge Pair | Heltec HT-HD01 AP+STA Kit | Mesh Point / bridge link | ~$80–140 / pair |
| HaLow Mesh Gate | Heltec HT-H7608 | Mesh Gate / backbone node | ~$70–110 each |
| 900 MHz Antenna (omni) | 5–7 dBi SMA outdoor vertical | General city mesh | ~$15–30 each |
| 900 MHz Antenna (directional) | 10–14 dBi Yagi or panel | Long-distance backbone link | ~$25–50 each |
| Weatherproof enclosure | IP65 NEMA 4X project box | Outdoor node protection | ~$10–25 each |
| USB-C power supply | 5V 3A wall adapter | Indoor node power | ~$8–15 each |
| Solar panel | 10–20W 12V panel | Outdoor node power | ~$20–45 each |
| Battery pack | 15,000–30,000 mAh LiPo | Solar buffer / overnight power | ~$20–50 each |
| Raspberry Pi (optional) | Pi 4 or Pi 5, 4GB+ | Reticulum Transport node | ~$50–80 each |
| MicroSD card | 32GB+ Class 10 / A1 | Pi operating system | ~$8–15 each |
| LoRa RNode (optional) | Heltec v4 / WisBlock RAK4631 | Hybrid LoRa fallback interface | ~$30–55 each |
| 3-node starter total | 1× HT-H7608 + 2× HD01 + antennas + power | Working city mesh | ~$350–550 |
| Component | Software | Source |
|---|---|---|
| Mesh networking overlay | Reticulum Network Stack | reticulum.network |
| Android messaging client | Sideband | github.com/markqvist/Sideband |
| Reticulum Python library | RNS (pip install rns) | github.com/markqvist/Reticulum |
| HaLow node firmware | Heltec Web UI (built-in) | heltec.org |
| Throughput testing | iperf3 | Package manager / apt install iperf3 |
| Network diagnostics | Reticulum rnstatus, rnpath | Included with RNS package |
| LoRa RNode flasher | RNode Flasher (web-based) | liamcottle.github.io/rnode-flasher |
| 802.11ah specification | IEEE 802.11ah-2016 | standards.ieee.org |
These are the primary sources that informed and validated this guide. If you want to go deeper than the guide, these are the right starting points — they're where the most active experimentation is happening.
| Resource | Why It Matters | URL |
|---|---|---|
| Reticulum Discussion #453 github.com · markqvist/Reticulum |
The primary community thread on HaLow + Reticulum. Reticulum's author Mark Qvist confirms that HaLow devices pass normal Ethernet frames and that AutoInterface works with them. Active discussion with hardware owners. | discussions/453 |
| Reticulum Discussion #421 github.com · markqvist/Reticulum |
The best live evidence thread. Someone ran iperf3 speed tests and the Reticulum Shell protocol over a HaLow bridge and posted results. The source for the "it actually works" claim in this guide. Includes hardware-specific notes on cheap AliExpress TaiXin-chipset devices. | discussions/421 |
| RNode_Halow_Firmware github.com · I-AM-ENGINEER |
A Russian developer's open-source project that flashes cheap Chinese HaLow bridge devices with custom RNode-compatible firmware, making them first-class Reticulum radio interfaces (not just WiFi bridges). Explicitly confirmed working with Sideband and Meshchat. More advanced than this guide's approach — worth knowing about. | RNode_Halow_Firmware |
| Haven — IP Mesh Radio Guide buildwithparallel.com · Parallel |
The closest commercial analog to this guide ($97, paid). Covers a tested build: Raspberry Pi + 802.11s + BATMAN-adv + optional HaLow + Reticulum, aimed at tactical/preparedness use. Uses OpenWRT hardware rather than Heltec. Worth buying if you want a complementary perspective on the same architecture, especially for multi-radio bridging and BATMAN-adv routing. | buildwithparallel.com/haven |
| Reticulum-haven-manet-ip-mesh-radio github.com · no1likesahero |
An open-source MANET mesh toolkit combining HaLow, 5 GHz WiFi, and Reticulum in a Gate/Point topology that closely mirrors the architecture in this guide. Good reference for seeing how others have structured the same network layers. | haven-manet-ip-mesh-radio |
| Hackaday — "802.11ah Wi-Fi HaLOW: The 1 Kilometer WiFi Standard" hackaday.com · January 2024 |
Popular overview article covering the HaLow hardware ecosystem, chipset vendors (TaiXin, Morse Micro, Newracom), and real-world range tests including foliage attenuation results. Good primer on the state of the hardware landscape and links to the Reticulum community discussion. | hackaday.com |
| Resource | URL |
|---|---|
| Reticulum Manual (full) | reticulum.network/manual |
| Heltec HD01 Documentation | docs.heltec.org — HD01 |
| Heltec H7608 Documentation | docs.heltec.org — H7608 |
| Node Star — Vol. 1: Build Your First RNode | nodestar.net/reticulum-rnode-guide.html |
| Node Star — Vol. 4: The Sovereign Stack | nodestar.net/sovereign-stack-guide.html |
| Node Star — Vol. 6: Mesh + AI at the Edge | nodestar.net/mesh-ai-edge-guide.html |
| Comparing Reticulum and Meshtastic | blog.erethon.com |
| FCC Part 15 Rules (ISM Band) | ecfr.gov — 47 CFR Part 15 |
| 802.11s Overview (Wikipedia) | en.wikipedia.org/wiki/IEEE_802.11s |
| Morse Micro range test coverage (Tom's Hardware) | tomshardware.com — HaLow range record |
| Meshtastic Project | meshtastic.org |
You have a guide built on real hardware, verified RF physics, and tested software components. The HaLow bridge works. Reticulum over WiFi works. Sideband over Reticulum works. What you're doing by combining them into a community mesh is new — and that's worth being clear-eyed about. Start with the 2-node bridge. Verify it thoroughly. Then add one node at a time, each deployment teaching you something the guide couldn't. When your mesh is working, tell the community. The next guide gets written by the people who build it first.