# Research: Homemade 1.3 GHz (23cm) SDR Link vs. Off-the-Shelf 900 MHz+3.4 GHz Commercial Radios for SC Robotics Rover Comms
**Prepared for:** SC Robotics (Saddleback College) rover comms redesign
**Context:** Team has already committed to a batman-adv mesh with a 900 MHz Wi-Fi HaLow leg (OpenMANET: Raspberry Pi + Morse Micro HaLow HAT) for control, plus a 2.4 GHz leg for video. Question: add or substitute a 1.3 GHz (23cm amateur band) SDR link for longer range, vs. buying an off-the-shelf 900 MHz + 3.4 GHz commercial radio (e.g., Doodle Labs Mesh Rider–class hardware).
**Venue:** University Rover Challenge (URC) at Mars Desert Research Station (MDRS), Hanksville, UT — desert terrain that is *not* pure flat open desert: MDRS has canyons, escarpments, and documented NLOS "radio blackout" pockets that required the Mars Society to deploy hilltop relays for reliable multi-km coverage ([Crew 228 EVA report](https://reports.marssociety.org/2021/10/04/crew-228-eva-5-report-october-4th/); [EVA-Link transcript, Mars Society Conference 2024](https://macroinvent.com/wp-content/uploads/2024/08/EVA-Link-Transcript-2024.pdf)).
---
## 1. SDR options for a 1.3 GHz link
### PlutoSDR (ADALM-PLUTO)
- Built around the Analog Devices **AD9363** RF Agile Transceiver. Factory-qualified tuning range is **325 MHz – 3.8 GHz**, natively covering 1.3 GHz with **no upconverter/downconverter needed**. Tunable channel bandwidth 200 kHz–20 MHz, 1 TX / 1 RX channel (not MIMO), separate TX/RX tuning for full duplex. ([Analog Devices Wiki – detailed specs](https://wiki.analog.com/university/tools/pluto/devs/specs); [MathWorks hardware support page](https://www.mathworks.com/hardware-support/adalm-pluto-radio.html))
- ADI also sells firmware that reconfigures the same silicon as an **AD9364**, extending the *advertised* range to 70 MHz–6 GHz, but ADI explicitly notes this is **outside the qualified/warranted tuning range** — it works but isn't a guaranteed spec ([MathWorks `configurePlutoRadio` docs](https://www.mathworks.com/help/comm/plutoradio/ref/configureplutoradio.html)). Since 1.3 GHz is inside the *native* 325 MHz–3.8 GHz range, this caveat doesn't matter for this application — Pluto is solidly in-spec at 1.3 GHz.
- **TX power: ~7 dBm (5 mW) max**, confirmed by ADI's own datasheet and independently by rtl-sdr.com and GitHub issue threads about power-level bugs in early SDR software stacks ([Mouser/ADI product highlight PDF](https://www.mouser.com/datasheet/2/609/ADALM-PLUTO-Product-Highlight-1633770.pdf); [rtl-sdr.com unboxing](https://www.rtl-sdr.com/adalm-pluto-sdr-unboxing-and-initial-testing/)).
- No RF shielding on the stock board; stock antenna/balun is tuned for 2.4 GHz, but the SMA connectors let you swap in an external 23cm antenna.
- Cost: ~$150–250.
- **A directly relevant prior-art project exists**: [Charon](https://github.com/tvelliott/charon) turns 2+ PlutoSDRs into a standalone OFDM transceiver running **batman-adv mesh networking** — i.e., someone has already built almost exactly what SC Robotics is contemplating, on this exact hardware. It reports 64-subcarrier OFDM, 16-QAM, ~272 kbps PHY rate (after FEC) in a 140 kHz occupied bandwidth, and measured **TCP throughput of ~117 kbps single-hop / ~80 kbps at one repeater hop, holding down to about −100 dBm RSSI**. This is strong direct evidence that PlutoSDR + batman-adv is buildable, but also a concrete data point on how modest the throughput is at narrowband, low-TX-power settings.
### LimeSDR (USB and Mini variants)
- Built around the Lime Microsystems **LMS7002M** FPRF transceiver IC, which has **continuous coverage of 100 kHz – 3.8 GHz** at the chip level — again natively covering 1.3 GHz with no upconverter ([LMS7002M datasheet](https://storage.sea.com.ua/tech_info/Lime%20microsystems/LMS7002M-Data-Sheet-v3.1r00.pdf); [Lime Microsystems product page](https://limemicro.com/silicon/lms7002m/)).
- Board-level RF ports have matching networks *optimized* for sub-ranges (this doesn't limit the chip, just tunes performance). On the original **LimeSDR USB**, port `TX1_2` is optimized for **30 MHz – 1.9 GHz**, which cleanly covers 1.3 GHz; `TX1_1` is optimized higher (2–2.6 GHz or up to 3.3–3.8 GHz depending on board revision) ([MyriadRF LimeSDR Hardware Installation](https://wiki.myriadrf.org/LimeSDR_Hardware_Installation); [MyriadRF Discourse clarification thread](https://discourse.myriadrf.org/t/operating-frequency/8741)). MyriadRF engineers confirm you *can* use any port at any frequency — the "optimized range" only affects performance, not a hard cutoff ([same Discourse thread](https://discourse.myriadrf.org/t/operating-frequency/8741)).
- **TX power: up to 10 dBm CW**, frequency-dependent, per Lime Microsystems' own spec page and the MyriadRF docs ([limemicro.com LimeSDR USB page](https://limemicro.com/sdr/limesdr-usb/); [MyriadRF LimeSDR USB docs](https://myriadrf.org/projects/limesdr-usb)). Real-world measurements on the MyriadRF forum show output well above the nominal 10 dBm spec is achievable with careful matching-network tuning, but that's not a stock, out-of-the-box guarantee ([MyriadRF Discourse: max TX power clarification](https://discourse.myriadrf.org/t/limesdr-maximum-transmit-power-clarification/2233)).
- 2x2 MIMO, up to 61.44 MHz instantaneous bandwidth (LimeSDR USB) — chip-level modulation bandwidth up to 120 MHz on some designs.
- Cost: ~$300–330 (USB), cheaper for Mini variants.
### Other candidate boards
- **bladeRF 2.0 micro** (Nuand): 47 MHz–6 GHz RF tuning range (covers 1.3 GHz natively), 2x2 MIMO, up to 56 MHz filtered bandwidth, **+8 dBm CW max TX power** per the underlying AD9361 datasheet — comparable to Pluto, i.e. also too low for multi-km links without a PA. Nuand sells an official bias-tee TX power amplifier add-on (BT-100) as an acknowledgment of this ([nuand.com bladeRF 2.0 micro](https://www.nuand.com/bladerf-2-0-micro/); [Nuand GitHub issue on max TX power](https://github.com/Nuand/bladeRF/issues/644)).
- **HackRF One** (Great Scott Gadgets): 1 MHz–6 GHz, but **half-duplex only** (can't TX and RX simultaneously) and 8-bit ADC/DAC — a real handicap for a full-duplex control+telemetry link. TX power in the relevant range (1.3 GHz falls in the "10 MHz–2170 MHz" bucket) is **5–15 dBm**, comparable to the others ([HackRF One docs](https://hackrf.readthedocs.io/en/stable/hackrf_one.html)). Cheap (~$300) and useful for RX/spectrum work, but the half-duplex limitation makes it a poor primary choice for a bidirectional link.
**Bottom line on hardware:** all of these SDRs cover 1.3 GHz natively — RF frontend frequency range is a non-issue. The real constraint across every board is **TX power: 5–10 dBm (3–10 mW) stock**. None of them can drive a multi-km link on their own; an external power amplifier (and likely a low-noise preamp on RX) is mandatory in every case, which is real added engineering scope (PA selection, thermal management, spectral-purity/filtering to stay compliant with Part 97 emission rules, TX/RX switching).
---
## 2. Is a real broadband link buildable at 1.3 GHz with this hardware?
### Link budget, several-km desert link
Free-space path loss (FSPL) at 1296 MHz:
- FSPL(dB) = 20·log₁₀(d_km) + 20·log₁₀(f_MHz) + 32.44
- At 3 km: FSPL ≈ 9.5 + 62.3 + 32.4 ≈ **104 dB**
- At 5 km: FSPL ≈ 14.0 + 62.3 + 32.4 ≈ **109 dB**
This is pure free-space, line-of-sight math — MDRS terrain is documented as NOT reliably LOS at multi-km ranges (viewshed studies, escarpments, and the Mars Society's own deployment of hilltop repeater relays confirm this: [EVA-Link transcript](https://macroinvent.com/wp-content/uploads/2024/08/EVA-Link-Transcript-2024.pdf)). Real-world link margins should assume some multipath/diffraction loss beyond FSPL, especially at 1.3 GHz where wavelength (23 cm) diffracts around terrain far less forgivingly than 900 MHz (33 cm) or the P900-class commercial radios teams often use for exactly this reason.
**Two very different power regimes to consider:**
1. **Stock SDR TX power (7–10 dBm) + high-gain antennas, no PA.** With, say, 15 dBi antennas at both ends (a modest yagi or small dish — very buildable): 10 dBm + 30 dBi − 104 dB ≈ **−64 dBm received** at 3 km. That's a workable margin for a *narrowband, low-data-rate control link* (SDR RX sensitivity for narrowband digital modes is commonly −90 to −100 dBm), but nowhere near enough SNR for a wideband video channel, where the noise floor rises with bandwidth (~6 dB per doubling of BW) and you need much higher instantaneous SNR for real-time compressed video.
2. **With a power amplifier**, taking advantage of the Part 97 headroom (see §3): even a modest 5–10 W amp (37–40 dBm) with the same antennas gives **>30 dB more margin**, comfortably supporting a higher-bandwidth link, or the same control link with large fade margin for non-ideal terrain.
### What this hardware realistically supports
- **Control-only** (few-hundred-kbps to low-Mbps, narrowband/moderate BW): realistic and demonstrated. The Charon project (§1) is direct proof PlutoSDR + batman-adv can carry mesh traffic at 1.3 GHz-class frequencies, albeit at ~100 kbps-class TCP throughput in its published narrowband configuration. Wider channels (Pluto supports up to 20 MHz BW, LimeSDR up to 61+ MHz) could push this into the Mbps range, but every doubling of bandwidth raises the noise floor and shortens usable range for a given TX power, and nobody has published a battle-tested "high-bandwidth batman-adv over 1.3 GHz SDR" reference design — this would be genuinely novel systems-integration work, not a known-good recipe.
- **Video**: possible in principle with a PA and adequate directional antennas, but this is a much harder engineering problem than the control link — full-duplex operation, higher SNR requirements, and Part 97's ban on "obscuring" codes (see §3) constrain what modulation/compression choices are legally clean. Realistically, video over this link would need its own dedicated engineering effort (codec selection, adaptive bitrate, wider channel bandwidth, careful antenna pointing) on top of getting the control mesh working — treat "control + video on the same homemade 1.3 GHz link" as a stretch goal, not a baseline assumption.
**Verdict on buildability**: Yes, a real link is buildable — the RF hardware supports it and there's working prior art for the control case. But "buildable" here means "a competent RF/software integration project," not "off-the-shelf." Expect antenna design/fabrication, PA integration and thermal/spectral-purity work, GNU Radio or similar SDR software-stack development (Pluto/Lime don't come with a "batman-adv over 1.3 GHz" driver out of the box — Charon is a hobbyist project, not a production stack), and non-trivial RF debugging time that a small student team will be competing against a competition deadline for.
---
## 3. Part 97 (US amateur radio) legality
### Band and license class
- **1240–1300 MHz (23 cm) is a real amateur allocation**, confirmed directly from the FCC's own regulation text at 47 CFR §97.301(a): the wavelength table lists "23 cm | 1240-1300 [MHz]" available to **Technician, General, Advanced, or Amateur Extra Class** control operators — i.e., the **entry-level Technician license already grants full privileges on this band** ([47 CFR §97.301, Cornell LII](https://www.law.cornell.edu/cfr/text/47/97.301); confirmed independently by [ARRL's Technician privileges chart](https://www.arrl.org/files/file/Tech%20Band%20Chart/US%20Amateur%20Radio%20Technician%20Privileges.pdf) and [ARRL band plan](https://www.arrl.org/band-plan)). There's a separate, narrower 1270–1295 MHz sub-band reserved for Amateur Extra only under §97.301(b), but that's irrelevant since Technician already covers the whole 1240–1300 MHz range under §97.301(a).
- Getting a Technician license is a single ~35-question multiple-choice exam, commonly described by URC itself as achievable "in just a few weeks" for anyone with an electronics/physics background ([URC 2022 Q&A, item 9](https://urc.marssociety.org/home/about-urc/history/urc2022/urc2022-qa)) — this is a low barrier, not a real blocker.
- Emission types (MCW, phone, image, RTTY, data, spread spectrum, test) are broadly authorized on 23cm under §97.305 ([Cornell LII §97.305](https://www.law.cornell.edu/cfr/text/47/97.305)) — a batman-adv/802.11-style digital data link is a legitimate emission type here.
### Encryption is explicitly prohibited — confirmed from the regulation text
**47 CFR §97.113(a)(4)** (direct FCC regulation text, via Cornell LII, which mirrors the official CFR): amateur stations may not transmit
> "...messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein..." ([47 CFR §97.113](https://www.law.cornell.edu/cfr/text/47/97.113))
The FCC's own plain-language FAQ confirms and enumerates the *only* exceptions: space telecommand (§97.211(b)), telecommand of model craft (§97.215(b)), and RTTY/data emission codes (§97.309(b)) — none of which permit general-purpose encryption ([FCC Amateur Communications & Operations FAQ](https://www.fcc.gov/wireless/bureau-divisions/mobility-division/amateur-radio-service/amateur-communications-operations)). The FCC has twice rejected petitions to carve out encryption exceptions — once for general emergency-services use ([FCC Order dismissing Don Rolph petition, DA-13-1918A1](https://docs.fcc.gov/public/attachments/DA-13-1918A1.pdf)) and once specifically addressing whether *compression* that has the practical effect of obscuring meaning counts (an open NYU petition the Wireless Bureau sought comment on in 2019, underscoring how strictly the FCC construes this rule: [DA-19-1130A1](https://docs.fcc.gov/public/attachments/DA-19-1130A1.pdf)).
**Practical implication for the design**: whatever runs over the 1.3 GHz leg — batman-adv headers, MAVLink-style telemetry, video codec bitstream — **must not be encrypted**. Standard compression (which doesn't intend to *obscure meaning*, just reduce size) is generally accepted ham practice (e.g., digital voice codecs like D-STAR/DMR are used on ham bands), but AES/TLS/VPN-style encryption of the payload is not legally usable on this band. If the team wants a uniformly encrypted comms architecture across all three legs (900 MHz HaLow, 2.4 GHz video, 1.3 GHz long-range), the ham leg breaks that model — the 900 MHz and 2.4 GHz legs run under FCC **Part 15** (unlicensed ISM), which has no such restriction, so this constraint is unique to the proposed 1.3 GHz leg.
### The "model craft" exception — a real find, with a real catch
**47 CFR §97.215** creates a specific carve-out for amateur stations transmitting control signals to a model craft:
- (a) waives the station-ID requirement for transmissions directed only at the model craft (if the transmitter itself is labeled with the licensee's call sign, name, and address);
- (b) explicitly states the *control signals themselves* "are not considered codes or ciphers intended to obscure the meaning of the communication" — i.e., a documented, non-encrypted control/telemetry binary protocol is fine and doesn't need to be "readable" the way voice or text traffic would;
- **(c) caps transmitter power at 1 W** ([47 CFR §97.215, Cornell LII](https://www.law.cornell.edu/cfr/text/47/97.215)).
This is directly relevant to a competition rover, but there's an important nuance: **the team likely doesn't need to invoke §97.215 at all.** If the control/telemetry protocol is documented and not intended to hide meaning (which describes basically any normal binary telemetry protocol — MAVLink, batman-adv, etc.), it isn't a "code or cipher intended to obscure meaning" in the first place, and the general Part 97 power limits for the 23cm band apply instead of the 1 W model-craft cap (Technician/General/Advanced/Extra can run **up to 1500 W PEP** on UHF/microwave bands, in practice limited by whatever PA hardware you actually build — see §2 amplifier options up to hundreds of watts, e.g. commercial 23cm PAs rated 120–600 W: [DEMI 23120PA](http://01895fa.netsolhost.com/PDF/Manuals/23120PA.PDF), [W6PQL 600W LDMOS amp](https://www.w6pql.com/600w_23cm_LDMOS_amplifier.htm)). §97.215 is a convenience carve-out (skip station ID, get explicit legal cover that your binary protocol isn't a "cipher"), not a mandatory 1 W ceiling on rover control links in general — but it's worth having on file as a clean legal argument if a competition RF judge/official questions the link.
### Control operator / remote operation
- §97.109(c): "When a station is being remotely controlled, the control operator must be at the control point. Any station may be remotely controlled." ([47 CFR §97.109, quoted via govinfo.gov CFR PDF](https://www.govinfo.gov/content/pkg/CFR-2025-title47-vol5/pdf/CFR-2025-title47-vol5-part97.pdf)) — i.e., the *licensed control operator* must be physically present at wherever the rover's ground-station transmitter control point is (the URC base station / team laptop), not at the rover itself. This is normal and easy to satisfy — someone on the team just needs to hold at least a Technician license and be at the control station during any 1.3 GHz operation.
- §97.213 (telecommand of an amateur station under automatic/remote control, if the setup needs that flexibility) requires: a sufficient control link, a fail-safe that limits transmission to ≤3 minutes on control-link malfunction, protection against unauthorized transmissions, and a posted license/contact placard at the station ([47 CFR §97.213](https://www.law.cornell.edu/cfr/text/47/97.213)). None of this is onerous for a competition setup, but it is a real design requirement (e.g., a watchdog timeout on the RF link, not just on the rover's autonomy stack).
### Interference risk: secondary allocation
The 23cm band is allocated to amateurs on a **secondary basis**. Per 47 CFR §97.303, amateur 23cm stations "must not cause harmful interference to, and must accept interference from" US government radiolocation, aeronautical radionavigation, and GPS/GNSS-adjacent services that are primary in this band ([47 CFR §97.303, Cornell LII](https://www.law.cornell.edu/cfr/text/47/97.303)). This is not hypothetical: ARRL has published warnings about new FAA CARSR air-traffic radars sharing this exact band and documented at least one real interference case in Southern California ([ARRL: "Amateurs Must Protect New Radars in 23 cm Band"](https://www.arrl.org/news/amateurs-must-protect-new-radars-in-23-cm-band)), and international regulatory bodies are actively studying constraints on the band due to GNSS (Galileo/GLONASS/QZSS) receiver interference ([IARU WRC-23 AI 9.1b page](https://www.iaru.org/spectrum/iaru-and-itu/wrc-23/agenda-item-9-1-topic-b/); [RSGB WRC-23 briefing PDF](https://rsgb.org/main/files/2022/10/23cm-Band-and-RNSS_Oct2022final.pdf)). Practically: at a remote site like MDRS this is unlikely to be a real-world problem (no nearby CARSR radar, no dense GNSS receiver population), but it means the team has zero interference protection if something does clash, and must yield/retune if it does.
### URC's own rules context
URC's Q&A explicitly encourages teams to get amateur licenses to access bands *outside* the crowded, competition-managed 900 MHz RC and 2.4 GHz Wi-Fi channels, and confirms URC does not manage or restrict ham-band use the way it manages 900 MHz/2.4 GHz channel assignments ([URC 2022 Q&A, items 6–9](https://urc.marssociety.org/home/about-urc/history/urc2022/urc2022-qa); [URC current Q&A](https://urc.marssociety.org/home/requirements-guidelines/qa)). Teams remain fully responsible for their own FCC Part 97 compliance — URC does not provide any regulatory cover.
---
## 4. Honest go/no-go verdict
**Recommendation: No-go on building the 1.3 GHz SDR link for this competition cycle. Go with off-the-shelf 900 MHz + 3.4 GHz commercial radio hardware instead.**
Reasoning:
- **Legality is fine, but not free.** The Technician license barrier is genuinely low (URC itself calls it "a few weeks," single easy exam), and 1.3 GHz is legitimately available with a clean legal path via either the general Part 97 power limits or the model-craft carve-out. This is not the blocking issue.
- **The real cost is engineering effort and risk, not law.** Every SDR option here ships with only 5–10 dBm of TX power — a PA is mandatory, which means RF amplifier design/sourcing, thermal management, filtering for spectral purity, and TX/RX switching, on top of building a working SDR software stack for batman-adv-over-1.3GHz that has, at best, one hobbyist proof-of-concept (Charon) at very modest (~100 kbps) throughput. This is a multi-month RF systems project for a team that already has two other comms legs (900 MHz HaLow, 2.4 GHz video) to build, integrate, and debug before competition. Adding a third, novel, homebrew RF band multiplies integration surface area and failure modes at exactly the time the team needs the mesh to be reliable.
- **No encryption is a real, if manageable, constraint.** It forces an architectural seam — the 1.3 GHz leg can't share the same security model as the Part 15 legs — and needs explicit design discipline (documented protocol, no accidental encryption via a library default) to stay compliant.
- **Commercial 900 MHz/3.4 GHz radios solve the actual problem directly.** Products like Doodle Labs' Mesh Rider series are already Linux/OpenWrt-based, mesh-capable (compatible with the same batman-adv-style routing concepts the team is already using), field-tested past 20 km LOS and demonstrated beyond 100 km in ideal conditions, support simultaneous telemetry + 4K-class video over one broadband RF channel, and include AES encryption in hardware if wanted ([Doodle Labs RM-915 datasheet](https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/6458/PdfFile_124608.pdf)). This is a known-good, purchasable, supported solution instead of a from-scratch RF engineering project. It costs real money (commercial-grade mesh radios run from several hundred to several thousand dollars per unit depending on power/model), but that's a budget line item, not an open engineering risk.
- **Where a 1.3 GHz SDR link *would* make sense**: as a multi-year side project, a "stretch" backup channel, or specifically as a learning exercise for team members interested in RF (the Part 97 licensing process and SDR development are genuinely valuable skills). It is not a good bet as a primary or even secondary competition-critical comms path on the current design timeline, given the team hasn't yet finished the 900 MHz/2.4 GHz legs.
**If the team still wants to pursue 1.3 GHz anyway**, the lowest-risk path is: get 2–3 team members Technician-licensed early (cheap, fast), prototype the SDR link as a pure narrowband control backup (not video) using the Charon precedent as a starting point rather than building from scratch, and treat it as parallel R&D that doesn't block the primary comms architecture.
---
## Open questions
1. **Exact PA and antenna budget.** No specific 23cm PA + antenna combination has been priced/selected here; a real go/no-go on cost needs quotes for a PA (5–150 W class, per §2/§3) and directional antennas (yagi or dish) for both rover and base station.
2. **Does the team have (or can it get) Technician-licensed operators before the competition?** This determines whether the 1.3 GHz path is even a live option on the current timeline.
3. **What specific commercial radio model/budget is the team actually comparing against?** This report used Doodle Labs Mesh Rider as an illustrative example; a real decision needs a firm SKU, price, and confirmation it's importable/exportable without ITAR/EAR issues if buying from certain vendors (some Microhard/Doodle Labs SKUs with AES encryption require export permits per the Microhard PicoPRO-900 datasheet referenced above).
4. **Has anyone actually benchmarked batman-adv (not just Charon's custom OFDM waveform) directly over Pluto/LimeSDR at a wider bandwidth (multi-MHz) to see whether Mbps-class throughput is realistic**, or is this genuinely unexplored territory the team would be pioneering?
5. **MDRS-specific propagation data**: does URC or the Mars Society publish any actual measured RF path-loss/coverage data for the competition course (beyond the qualitative "radio blackout pockets" reports found here) that could sharpen the link budget beyond free-space assumptions?
6. **Would URC officials/RF safety judges have any concerns about a team running a licensed high-power (multi-watt to multi-tens-of-watts) 23cm transmitter in proximity to other teams' 2.4 GHz/900 MHz gear?** Worth a direct question to URC organizers, per their own Q&A pattern of encouraging exactly this kind of pre-competition clarification.