Dual-radio bridge assembly guide for connecting backhaul and local mesh layers
A bridge node is two MeshCore radios connected via a serial (UART) cable. One radio talks to the backhaul network on 911.45 MHz using a directional antenna. The other serves the local mesh on 910.525 MHz using an omni. MeshCore's RS232 bridge feature handles all the routing.
Both radios run MeshCore repeater firmware built with the RS232 bridge option enabled. The official MeshCore builds do not include bridge support, so you'll need to use our custom firmware builds. The bridge delay makes the serial hop behave like a normal RF relay to the rest of the mesh. Companions and local repeaters are completely unaware the bridge exists.
| Component | Qty | Notes | Est. Price |
|---|---|---|---|
|
RAK4631 WisBlock Core Module (US915)
Rokland — SKU 116000
|
2 | nRF52840 + SX1262. Ultra-low power. This is the brain + radio of each side. | $39.94 |
|
RAK19003 WisBlock Mini Base Board
Rokland — PID 110035
|
2 | Compact base board. Has UART/GPIO breakout, battery connector, and solar input. The smaller form factor keeps the enclosure compact. | $27.94 |
|
IPEX/u.FL to N-Female Bulkhead Pigtail
Amazon — IPEX to N-Female pigtails
|
2 | Short pigtail (~6–12") from the RAK4631's u.FL LoRa port to an N-female bulkhead on the enclosure. Mounts through the enclosure wall so the cable run connects from outside. | ~$10 |
|
Proxicast 10 ft N-Male to N-Male CFD-400 Low-Loss Cable
Amazon — Proxicast ANT-180-401-10
|
1–2 | Premium 400-series low-loss coax, N-male on both ends. Gold-plated pins, solid copper-clad aluminum core. Rated for outdoor use. Connects from the IPEX-to-N bulkhead on the enclosure to the antenna's N-female port. Available in multiple lengths — get the shortest run that reaches. | ~$25–35 |
|
915 MHz Omni Antenna (local mesh)
Rokland — LoRa / 915 MHz antennas
|
1 | For the local mesh radio. A 3–6 dBi omni is fine for most sites. N-female connector. Choose based on your local coverage needs. | ~$10–30 |
|
900 MHz 9 dBi Directional Panel Antenna (backhaul)
eBay — Antenna World COM-9028PN
|
1 | 902–928 MHz panel antenna with ~9 dBi gain, N-female connector. Solid ground plane provides good front-to-back ratio for co-site isolation. Made in USA. Compact form factor, mounts easily on a mast or wall bracket. | ~$46 |
|
Dupont Jumper Wires (Female-Female)
Amazon — various
|
3 | For the UART bridge wiring (TX→RX, RX→TX, GND→GND). Short lengths — 10–15 cm is plenty. | ~$5 |
|
3.7V LiPo Battery (JST 2-pin connector)
|
1–2 | One per base board, or share power. Check JST connector polarity — RAK uses a specific pinout. Rokland batteries are verified compatible. | ~$8–15 |
|
5V Solar Panel (JST connector)
|
1 | Optional but recommended for remote deployments. 5V panel connects to the RAK19003's solar input. 1–2W panel is adequate for dual nRF52 nodes. | ~$10–15 |
|
Weatherproof Enclosure (IP65+)
Amazon — IP67 enclosures
|
1 | Needs to fit two RAK19003 boards plus wiring. ~150×100×75mm minimum. Drill holes for N-type bulkhead connectors (one per antenna) or use cable glands for the pigtail feedthroughs. | ~$10–15 |
The two RAK19003 base boards are connected via three wires using the UART/GPIO header pins. This is a cross-wired serial connection — one radio's TX goes to the other's RX, and vice versa. Both boards share a common ground.
| Radio 1 (Backhaul) | Wire | Radio 2 (Local Mesh) |
|---|---|---|
| TX (Pin TX1) | → wire → | RX (Pin RX1) |
| RX (Pin RX1) | ← wire ← | TX (Pin TX1) |
| GND | — wire — | GND |
Both RAK4631 modules run at 3.3V logic, so the UART connection is direct — no level shifter needed. Do not connect to a true RS-232 voltage level device (±12V) without a level converter. The "RS232" name in MeshCore refers to the serial protocol, not the voltage standard.
On the RAK19003 mini base board, the UART pins are available on the IO header. Refer to the RAK19003 datasheet for the exact header pinout. The TX1 and RX1 pins correspond to the nRF52840's hardware UART1. Ensure you're using the correct UART — MeshCore's bridge uses the serial port specified at compile time via the WITH_RS232_BRIDGE flag.
Both radios need MeshCore repeater firmware with the RS232 bridge option compiled in. The official MeshCore builds do not include bridge support, so you'll need to use our custom builds. Download the correct firmware for your board from the Firmware Builds page, then flash it using the MeshCore Flasher's Custom Firmware option.
Do not use the standard firmware options in the MeshCore Flasher — they do not include bridge support. You must download the bridge-enabled firmware from our Firmware Builds page and flash it using the Custom Firmware option in the flasher.
RAK_4631_repeater_bridge_rs232_serial1 for a RAK4631 using UART1).This radio connects to the backhaul network. Assume you've already configured the radio parameters (frequency, bandwidth, SF, TX power) per your community's backhaul settings. The commands below are only the bridge-specific configuration.
# Connect via serial console at 115200 baud # Radio params assumed already set: # set radio 911.45,62.5,7,5 # set name BRIDGE-WEST-BH # Enable the RS232 bridge set bridge.enabled on # Bridge received packets (from RF) out to serial set bridge.source rx # Set baud rate — must match Radio 2 set bridge.baud 115200 # Add delay (ms) so the bridge behaves like an RF hop set bridge.delay 500 # Verify settings get bridge.enabled get bridge.source get bridge.baud get bridge.delay
This radio serves the local mesh pocket. Same bridge commands, just on the radio that's already configured for the local mesh frequency.
# Connect via serial console at 115200 baud # Radio params assumed already set: # set radio 910.525,62.5,7,5 # set name BRIDGE-WEST-LM # Enable the RS232 bridge set bridge.enabled on # Bridge received packets (from RF) out to serial set bridge.source rx # Set baud rate — must match Radio 1 set bridge.baud 115200 # Add delay (ms) so the bridge behaves like an RF hop set bridge.delay 500 # Verify settings get bridge.enabled get bridge.source get bridge.baud get bridge.delay
The bridge.delay value introduces artificial latency so the mesh treats the bridge as a normal RF hop for timing purposes. 500ms is a reasonable starting point. If you experience retransmission issues, increase it. If responsiveness matters more than timing accuracy, you can decrease it — but going below ~200ms may cause the mesh to not count it as a hop.
With both radios operating within ~1 MHz of each other (910.525 and 911.45), co-site interference is a real consideration. The two antennas need physical separation to prevent the backhaul radio from desensing the local mesh radio (and vice versa). Here's what helps:
Vertical separation is your primary isolation tool. Mount the directional (backhaul) antenna below the omni (local mesh), with as much vertical distance as the site allows. Even 2–3 meters makes a significant difference. The omni's radiation pattern has a null along its vertical axis, so getting the directional into that null zone minimizes coupling.
Channel separation works in your favor. At 62.5 kHz bandwidth with ~1 MHz of offset, the LoRa radio's channel filter provides meaningful adjacent-channel rejection — roughly 30+ dB at that spacing. This is usually sufficient when combined with modest physical separation.
Antenna front-to-back ratio is handled well by the recommended panel antenna. The COM-9028PN has a solid ground plane behind the radiating element, which naturally blocks energy from radiating backward toward the omni. This is one of the main advantages of a panel over a yagi or grid for co-site deployments — the flat metal backplane acts as a shield.
If the community moves to 500 kHz bandwidth, the backhaul frequency shifts to 911.6 MHz. Channel separation drops to ~2× the channel width. You'll need to be more aggressive with physical separation — plan for 3+ meters between antennas, or consider mounting them on separate mast points. At 62.5 kHz, most sites will work fine with minimal separation.
show config or equivalent.Bridge not forwarding packets? Confirm both radios have bridge.enabled on and matching baud rates. Check that the UART wiring is crossed (TX→RX) and not straight-through. A logic analyzer or USB-serial adapter on the bridge wires can confirm data is flowing.
Packets arriving but not being rebroadcast? Make sure both radios are running repeater firmware (not companion firmware). The bridge forwards raw packets to the serial port, but the receiving radio needs to be in repeater mode to rebroadcast them over RF.
Seeing duplicate messages or loops? MeshCore's mesh routing is designed to handle duplicate suppression, but if you're seeing obvious loops, check that the bridge delay is set appropriately. A delay that's too short may cause the mesh to not treat the bridge as a distinct hop.
One direction works but not the other? Bidirectional bridging requires both radios to have the bridge enabled. If only one side is enabled, traffic will only flow in one direction (mesh→serial on the enabled side). Ensure bridge.enabled on is set on both radios.