Skip to content

Rover Tri-Band Radio: 1.3 GHz video + 900 MHz HaLow mesh + LoRa

Deep-research report. Generated 2026-08-19. Sources: 12. Confidence: High on the core architecture and the WM1302 mismatch; Medium on exact coexistence numbers (mostly simulation/lab data).

The question

Tyler likes the OpenMANET "Hammond" enclosure build but it only covers the 900 MHz leg. He wants to run three links on one rover at once: - 1.3 GHz analog FPV video now, going digital later via a custom transceiver link (not yet researched) - 900 MHz Wi-Fi HaLow carrying the batman-adv mesh (controls + telemetry + degraded video) - LoRa as a long-range low-bandwidth link

He asked whether stacking 3x Seeed WM1302 Pi Hats gets him there, or if there's something better.

Headline finding: the WM1302 is the wrong radio for two of the three legs

The central confusion is that "900 MHz" in the OpenMANET build and "900 MHz" on the WM1302 are two completely different technologies that happen to share a band.

  • OpenMANET's 900 MHz leg is Wi-Fi HaLow (IEEE 802.11ah), run on a Morse Micro MM6108/MM8108 radio (e.g. Seeed Wio-WM6108), doing 802.11s mesh + batman-adv. That is a real IP mesh radio that carries any traffic. (OpenMANET docs, hardware page)
  • The WM1302 is a LoRaWAN gateway concentrator built on the Semtech SX1302 baseband chip, mini-PCIe form factor, connected over SPI (or USB). It speaks LoRa / LoRaWAN only. It is not Wi-Fi, not 802.11ah, and cannot join a batman-adv mesh or carry general IP traffic. (Seeed wiki, WM1302 module wiki)

So 3x WM1302 does NOT give you the HaLow mesh. It gives you three LoRa concentrators and nothing else. The mesh still needs a separate HaLow radio.

Do NOT stack three WM1302 hats. It's physically and electrically impossible on one Pi.

  • A Raspberry Pi has one 40-pin header, and the legacy HAT spec allows exactly one HAT because the HAT ID EEPROM lives at a fixed I2C address; two HATs collide on that EEPROM and on the shared GPIO pins. Stacking identical HATs drives the same GPIO to conflicting states (effectively a short). (RPi HAT+ spec, raspberrypi/hats issue #16)
  • The WM1302 Pi Hat uses the main SPI0 bus + I2C + specific GPIOs (reset, GPS UART, etc.). Three of them would all fight for SPI0, CE0, and the same reset/GPS pins. (WM1302 pinout)
  • The HAT+ spec does allow up to three boards only if they are different classes (one Standard HAT + one Stackable + one Power). Three of the same Standard-class radio HAT is not one of those combinations. (RPi HAT+ spec)

You also don't need more than one. A single SX1302 concentrator already listens on 8 LoRa channels simultaneously. Three would be pure redundancy with no functional gain for a single rover.

The WM1302 is overkill for a rover anyway (gateway vs node)

The WM1302 is a LoRaWAN gateway/concentrator, the infrastructure side, meant to sit at a base station and aggregate many end-devices, forwarding to a network server (TTN, ChirpStack). (Seeed wiki) A rover is an endpoint, not a gateway. For a rover you want a single LoRa node radio (Semtech SX1262 class), which is far smaller, cheaper, and lower power.

What you actually want on the LoRa leg depends on the job (RAKwireless, layered guide): - LoRa P2P: raw point-to-point rover-to-base link, you own the framing/retries. Best if you just want a simple long-range backup command/telemetry channel. - Meshtastic / MeshCore: off-grid LoRa mesh with routing, encryption, GPS, ready-made apps. Good if you want a resilient low-rate fallback that self-heals. Note it is best-effort, low throughput, high/variable latency, not for guaranteed real-time control. (Meshtastic overview, openelab comparison) - LoRaWAN (the WM1302 world): only if you want the full gateway + network-server telemetry model. Overkill here.

The real problem: 900 MHz HaLow and 900 MHz LoRa share the same band

This is the coexistence trap. In the US, both Wi-Fi HaLow and LoRa live in the 902-928 MHz ISM band. Running both on the rover, inches apart, means cross-technology interference.

  • Simulation study (NS-3, 2025): as LoRa load rises, 802.11ah throughput drops up to 31% and packet loss rises up to 79% in dense deployments. LoRa's very long on-air time (packets up to hundreds of ms to seconds) can wipe out an entire 802.11ah PPDU. (MDPI Sensors 2025)
  • The two protocols have no shared coexistence mechanism: 802.11ah uses CSMA/CA energy-detect (ED-CCA at ~-75 dBm/MHz), LoRa is a "just transmit" chirp with only spreading-factor robustness. HaLow's higher ED threshold can talk right over a low-power LoRa frame. (IEEE 802.19.3 / MERL TR2022-106)
  • LoRa's own weak receive levels (down to -139 dBm on the WM1302) make it very vulnerable to a nearby HaLow transmitter swamping it. (Seeed wiki, PSR / arXiv 2109.03488)

Mitigations, in order of effectiveness: 1. Don't overlap sub-bands. Pin HaLow to one part of 902-928 and constrain LoRa channels to the opposite end, with as much guard as you can. Helps but does not fully solve it in-device. 2. Physical antenna separation + isolation. Put the HaLow and LoRa antennas as far apart as the chassis allows, ideally orthogonal polarization, with ground planes / shielding between the radios. In-device coexistence rule of thumb is at least a quarter wavelength separation, more is better. (embedded.com, Promwad) 3. Time-division / duty limiting. Keep LoRa low-duty (it's meant to be), so it rarely steps on the mesh. 4. Cleanest option: move LoRa off 900 entirely. If your region/license allows, running LoRa at 433 MHz (or the mesh on a different band) sidesteps the co-band fight. Worth checking against your legal constraints.

1.3 GHz video brings its own coexistence baggage

The 23cm band (1240-1300 MHz amateur allocation; 1280 MHz is effectively the one clean legal channel in the US) has two well-documented problems that matter a lot when you're also running 900 MHz and GPS (Oscar Liang, unmanned.tech 2026):

  1. 1.3 GHz VTX desensitizes GPS. GPS L1 is 1.575 GHz and L2 is 1.227 GHz; a 1.28 GHz transmitter leaks into the L2 carrier and a bad front end can clamp GPS entirely. Measured demos show spurious energy at 1.227 GHz with the VTX antenna within 6-18 inches of the receiver. Fix: keep VTX antenna far from GPS, use a low-pass/notch filter on the VTX. (HeliFreak demo, webx.dk measurements)
  2. 900 MHz control/data interferes with 1.3 GHz video. Even though the frequencies aren't adjacent, 1.3 GHz analog receivers are sensitive to 900 MHz links (ELRS 900, Crossfire). A filter on the video RX antenna path is described as basically mandatory when a 900 MHz link is present, or you get visible noise in the analog picture. (unmanned.tech)

So the very stack Tyler wants (900 MHz mesh + 1.3 GHz video) is a known-noisy pairing that needs filtering and antenna discipline, not just plugging boards together.

Think of it as three independent radio chains that share a Pi, not three HATs stacked.

  • Leg 1, mesh (900 MHz HaLow): the one Pi HAT slot. Use the OpenMANET-supported Seeed Wio-WM6108 (SPI) or an SDIO Morse Micro board, running the OpenMANET image (802.11s + batman-adv, ~27 dBm with the custom BCF). This is your primary controls/telemetry/degraded-video link. (OpenMANET firmware, hardware)
  • Leg 2, LoRa fallback: a single USB LoRa node (SX1262-based, Meshtastic or LoRa P2P), NOT a WM1302 and NOT a second HAT. Going USB keeps the HAT header free for the HaLow board and avoids the SPI/EEPROM conflict. Keep it low-duty and on non-overlapping channels vs HaLow.
  • Leg 3, 1.3 GHz video: today this is a standalone analog VTX + camera that isn't wired into the Pi at all; it just needs its own 1280 MHz antenna, a low-pass filter, and physical separation from GPS and the 900 MHz antennas. When you go digital later, that "custom transceiver link" is its own separate radio (likely an SDR or a dedicated digital video module), still a fourth antenna chain, not something the WM1302 touches.

Practical Pi note: SDIO HaLow builds usually disable the Pi's onboard Wi-Fi (bus conflict); SPI HaLow builds keep onboard Wi-Fi usable as an AP. A Pi 4 / CM4 has a second SPI bus if you ever do want a second SPI radio, but USB is the least painful path for the LoRa leg. (OpenMANET hardware, RPi SPI)

Key takeaways

  1. Buy one HaLow radio + one LoRa node, not 3x WM1302. WM1302 is a LoRaWAN gateway concentrator; it can't do the mesh and you can't stack three on one Pi.
  2. Your worst coexistence problem is 900 (HaLow) vs 900 (LoRa) in the same ISM band. Separate the sub-bands, separate the antennas, keep LoRa low-duty, or move LoRa to 433 MHz.
  3. 1.3 GHz video needs filtering + antenna separation to avoid killing GPS and to survive 900 MHz interference. Plan for a low-pass/notch filter from day one.
  4. The Hammond enclosure only houses the HaLow radio. Running all three means multiple enclosures/antennas and a real antenna-placement plan, not one box.
  5. Decide the LoRa job first: simple P2P backup link vs Meshtastic self-healing mesh. That picks the radio.

Follow-up (2026-08-19): PCIe/M.2 modules at 1.3 GHz?

Tyler asked if any PCIe modules cover 1.3 GHz. They do, but there is no turnkey "1.3 GHz radio HAT/card," because 1240-1300 MHz (23cm) is an amateur-only band with no mass-market chipset. Everything that tunes 1.3 GHz in a card form is a wideband SDR, where you implement the waveform yourself.

  • LimeSDR XTRX (mini-PCIe): LMS7002M + Artix-7 FPGA, 30 MHz-3.8 GHz, 2T2R MIMO, 120 MHz BW. Covers 1.3 GHz. But TX power is only ~10 dBm (10 mW), so it needs an external PA for any range. (Lime, Crowd Supply)
  • HamGeek M2SDR (M.2): AD9361 (B210-class), 70 MHz-6 GHz, GPSDO, ~$376, drivers tested on Raspberry Pi 5 / Orange Pi / RK3588. The cheapest card that fits the "PCIe module on a Pi" ask. Still ~10 dBm class TX, needs a PA. (hgeek)
  • Epiq Sidekiq M.2 / Mini PCIe (AD9361, 70 MHz-6 GHz, 50 MHz BW) and Vanteon vProtean M.2 (ADRV9004, UltraScale+): professional-grade, covers 1.3 GHz, but thousands of dollars. (Epiq, Vanteon)

Caveats for the SDR route: tiny TX power (external PA + filtering required), you build the digital video modem yourself (e.g. a DVB-T/COFDM or custom waveform in GNU Radio), higher latency risk, and under Part 97 it must be unencrypted.

Pragmatic alternative for digital 1.3 GHz video without writing a modem: frequency-agile COFDM OEM video modules. These are turnkey H.264/H.265 digital HD links, many are tunable across ~170-2700 MHz including 1.2/1.3 GHz, 32g and up, HDMI/SDI/CVBS in, RF out, 60-250 ms latency, some with AES. Not a PCIe card (standalone module), but this is the realistic "custom digital transceiver link" path he flagged for later. (LinkAV MANET1648, mopanvideo)

Bottom line: PCIe form at 1.3 GHz means SDR (flexible, low power, DIY modem) or you go non-PCIe with a COFDM module (turnkey video). No dedicated 1.3 GHz PCIe radio exists because the band has no consumer chipset.

Follow-up (2026-08-19): SDR primer + true-transceiver alternatives

Context from the same thread: Tyler worked through what SDR is, TX vs RX, and which boards can actually transmit. Captured here so the buying shortlist lives with the rest of the radio research.

SDR vs the alternatives (the tradeoff)

An SDR moves the radio (filtering, tuning, modulation/demod) out of fixed hardware and into software on top of a minimal RF front end (antenna + amp + fast ADC). The waveform becomes a program, not a circuit. - Fixed-function chip (LoRa SX1262, a Wi-Fi/HaLow card): no flexibility, cheap ($5-40), low power, modem already done. - Pure SDR (LimeSDR, USRP, HackRF, bladeRF): total flexibility across its tuning range, mid-to-high cost, higher power, you write the modem (GNU Radio etc.). - Dedicated modem ASIC (a COFDM video chip): purpose-built, no flexibility, low power, no coding. - Net: a fixed chip is an appliance; an SDR is a programmable platform you pay for in watts, dollars, and engineering time.

TX / RX / duplex (the fundamentals that gate every choice)

  • TX = transmit (send), RX = receive (listen). A radio that does both is a transceiver.
  • A working rover link needs both ends to TX and RX (commands up, video/telemetry down), so both ends need transceivers.
  • Half-duplex = TX or RX, one at a time. Full-duplex = both at once (receive control while transmitting video).
  • This is why the NooElec/RTL-SDR (RTL2832U + R820T2) is the wrong tool for the link: it is RX-only. Great as a ~$40 bench/diagnostic receiver (100 kHz-1.75 GHz covers 433/900/1.3 GHz for monitoring), but it can never be a rover radio. To boost weak RX on it: set manual tuner gain (AGC off, ~0-49.6 dB) → band-appropriate/directional antenna → LNA at the antenna feedpoint + band filter (often bias-tee powered) → reduce coax loss.

The shared-tuner trap (why one SDR ≠ two bands at once)

The LimeSDR USB is "2x2 MIMO," but on the LMS7002M both RX channels share one RX tuner/PLL and both TX channels share one TX tuner. The two RX channels must sit within the same ~61 MHz window. 900 MHz and 1.3 GHz are ~400 MHz apart, so one board cannot run a 900 mesh link and a 1.3 GHz video link simultaneously. MIMO is for two antennas on the same frequency (diversity/beamforming). Only cross-band exception: TX and RX tuners are separate, so you can transmit on one band while receiving on another, but that doesn't give you two full duplex links on two bands. Simultaneous multi-band = separate RF front ends per band (which is how Doodle Labs does it too).

Does Doodle Labs use SDR? Yes, "hybrid SDR."

Mesh Rider is a software-defined waveform + multi-band front end built on Qualcomm 802.11 silicon (not a blank-canvas SDR). One software stack (OpenWrt, deep API access) spans ~100 MHz-6 GHz by swapping band modules. It's software-defined in waveform/band/networking behavior, but calibrated hardware per band, which is why it gets both performance and flexibility. Different tier (and price) from a DIY parts stack; it replaces the mesh leg with one premium box.

True (TX-capable) SDR shortlist

All of these transmit and receive, unlike the RTL-SDR. Bare-SDR TX power is tiny (~0-15 dBm, sags at high bands), so every one needs an external PA + band filter for real rover range.

Budget / learning (USB, bench): - ADALM-Pluto (PlutoSDR) - 325 MHz-3.8 GHz (community hack ~70 MHz-6 GHz), 12-bit, full-duplex, 1T/1R. ~$230 direct from Analog Devices. Best "actually learn digital comms" pick, and cheaper than the Lime Mini 2.0. - HackRF One - 1 MHz-6 GHz (widest), 8-bit, half-duplex. ~$150 (clone) to ~$320 (genuine). Huge community; TX sags above 4 GHz. HackRF Pro (2026) adds 100 kHz-6 GHz + TCXO stability.

Full-duplex / MIMO mid tier: - bladeRF 2.0 micro xA4 - 47 MHz-6 GHz, 2x2 MIMO, 12-bit, 61.44 Msps, Cyclone V FPGA. $540 (xA9 with bigger FPGA is $860). Closest true competitor to the LimeSDR USB, arguably better supported. - PLUTO+ - beefed Pluto clone, 2T/2R, 70 MHz-6 GHz, adds Gigabit Ethernet + microSD boot. ~$200-300. Best MIMO value. - LimeSDR USB - the 2x2 board above; remember the shared-tuner limit. - LimeSDR Mini 2.0 - single-channel bench transceiver, LMS7002M, 10 MHz-3.5 GHz, 40 MHz BW, full-duplex, USB 3.0. ~$600 (Crowd Supply, official, free US shipping). vs Mini 1.0 the only real change is the FPGA (Intel MAX 10 ~16k LUT → Lattice ECP5 ~44k LUT, forced by the chip shortage, brings open Yosys/nextpnr toolchain + more on-device DSP headroom); RF is identical. 1.0 is EOL.

Embeddable (rover form factor, not a dangling dongle): - LimeSDR Micro (M.2 2280, slots in like an SSD), LimeSDR XTRX (mini-PCIe, 2x2), HamGeek M2SDR (M.2, AD9361, 70 MHz-6 GHz, GPSDO, ~$376, Pi 5-tested). These solve the mounting/bus problem for a permanent rover install.

Pro / gold-standard (if someone else pays): - Ettus/NI USRP B-series (B200/B205mini/B210) - 70 MHz-6 GHz, 56 MHz BW, clean clock/PPS sync for coherent multi-radio work. ~$1,000-2,000+. Overkill unless you need lab reliability.

Attaching two SDRs to one computer

Physical part is easy (two ports: USB, or M.2/PCIe slots, or Ethernet SDRs on a switch). The real limits: - Bus bandwidth: SDRs stream raw IQ. One SDR at 20 Msps/16-bit ≈ 640 Mbps; two ≈ 1.3 Gbps before any processing. Don't hang two wideband SDRs off one shared USB controller (sample drops/overruns). Give each its own bus (one M.2 + one USB on a separate controller, or Ethernet). - Clocking: independent band-links (900 vs 1.3) need no sync. Only coherent work (MIMO/beamforming/direction-finding) needs a shared 10 MHz reference + PPS line. - CPU + power: two software modems double CPU load; FPGA SDRs (XTRX/USRP/bladeRF) offload it. Power the radios from a regulated rail / powered hub, not Pi bus power.

Picking for this rover

  • Just learning TX-side SDR on the bench: ADALM-Pluto (or HackRF for range) beats spending $600 on the Lime Mini 2.0.
  • Want real MIMO/two channels: bladeRF 2.0 micro xA4 ($540) or PLUTO+ for value.
  • Mounting on the rover permanently: go M.2/mPCIe (LimeSDR Micro, XTRX, or M2SDR), not a USB board.
  • Reminder: two full SDRs on the rover is heavy/power/CPU-hungry. Lighter path stays: one SDR only for the leg that truly needs a custom waveform (future 1.3 GHz digital video) + fixed-function chips for mesh and LoRa.

Follow-up (2026-08-19): ADALM-Pluto vs LimeSDR Mini 2.0 head-to-head

Both are single-channel (1T/1R), full-duplex, 12-bit transceivers, same class, but different design philosophies. Tyler is weighing buying 5 for the team.

ADALM-Pluto LimeSDR Mini 2.0
Price (official) ~$230 (Analog Devices) ~$600 (Crowd Supply)
RF chip AD9363 (same silicon as AD9364) LMS7002M
Freq range 325-3800 MHz official; ~70 MHz-6 GHz via known software hack 10 MHz-3.5 GHz (no hack)
Bus USB 2.0 (480 Mbps, caps sustained wideband) USB 3.0 (5 Gbps)
Sample/BW ~20 MHz instantaneous BW 30.72 Msps, 40 MHz BW
Onboard compute Xilinx Zynq (ARM + FPGA), runs embedded Linux, SSH-able, can run standalone ECP5 FPGA only, no CPU, always needs a host
FPGA toolchain Xilinx Vivado (proprietary, free tier) Open-source (Yosys/nextpnr)

Key tradeoffs: - Price: 2.6x gap. Across 5 units that's ~$1,850 saved going Pluto. - Pluto reaches higher (hacked to 6 GHz, covers 5.8 GHz FPV); Lime reaches lower (10 MHz for HF). Both cover the rover's 433/900/1280 MHz bands. - Lime's USB 3.0 genuinely matters for wide digital-video captures; Pluto's USB 2.0 is the real ceiling on it. - Pluto is a standalone Linux radio (Zynq); Lime Mini is a dumb USB peripheral. Niche for a rover since a Pi is already onboard. - Lime wins for custom on-radio gateware (open FPGA toolchain); Pluto needs Vivado.

Verdict for this team: Pluto is the smarter buy, especially at 5 units. Cheaper by ~$370/board, covers all rover bands, 6 GHz headroom via hack, and it's the community-standard learning board for TX-side SDR. Lime Mini's edges (10 MHz low end, USB 3 bandwidth, open FPGA toolchain) are real but none are things the current rover plan needs. Same caveats as all bare SDRs: single band at a time, ~7-10 mW TX, needs external PA + filter for range.

Open questions for Tyler

  • Which region/licensing? (Determines whether 433 MHz LoRa is on the table, and legal 23cm channels/power.)
  • Is the LoRa leg a command/telemetry backup, or a separate data mesh? (P2P vs Meshtastic.)
  • Does the rover carry GPS? If yes, the 1.3 GHz filtering plan is mandatory, not optional.

Sources

  1. Seeed WM1302 Pi HAT wiki - concentrator, SX1302, mini-PCIe over SPI.
  2. Seeed WM1302 module wiki - LoRaWAN gateway module, sensitivity, pinout, SPI/I2C usage.
  3. OpenMANET docs home - Wi-Fi HaLow MANET on Morse Micro + batman-adv.
  4. OpenMANET hardware - MM6108/MM8108, SPI vs SDIO, onboard Wi-Fi caveats.
  5. OpenMANET networking - batman-adv V, 10.41.0.0/16, bonding roadmap.
  6. MDPI Sensors 2025, LoRa-on-802.11ah interference - up to 31% throughput drop, 79% packet loss.
  7. MERL TR2022-106, IEEE 802.19.3 sub-1GHz coexistence - ED-CCA thresholds, protocol coexistence.
  8. arXiv 2109.03488, Partial Symbol Recovery - LoRa vulnerability to cross-tech interference.
  9. Oscar Liang, 1.2/1.3 GHz FPV guide - 900 MHz vs 1.3 GHz interference, GPS, filters.
  10. unmanned.tech, FPV frequency tested 2026 - 1280 MHz legal channel, GPS and 900 MHz control interference.
  11. RPi HAT+ specification - one HAT per class, EEPROM/GPIO constraints.
  12. RAKwireless LoRaWAN vs P2P vs Mesh + openelab comparison - node vs gateway, choosing the LoRa layer.
  • No related pages yet.