# batman-adv Deep Dive: SC Robotics Rover Comms Redesign
Research date: 2026-08-17. Scope: replacing the rover's single 2.4GHz Ubiquiti point-to-point bridge with a dual-radio batman-adv mesh — a 900MHz Wi-Fi HaLow (802.11ah) leg for control via the OpenMANET project (Raspberry Pi + Morse Micro HaLow HAT), and a 2.4GHz leg for video — kept as two **unbonded** mesh instances so control and video traffic can be pinned to specific radios via interface/socket binding rather than left to batman-adv's own link-quality-driven interface selection.
---
## 1. Architecture: how batman-adv actually works
batman-adv ("Better Approach To Mobile Ad-hoc Networking, Advanced") is a **layer-2** mesh routing protocol implemented as a Linux kernel module. Unlike the original BATMAN daemon (which worked over UDP/IP at layer 3), batman-adv operates directly on Ethernet frames: it creates a virtual network device (`bat0`) that behaves like a big transparent switch, so every node on the mesh appears link-local to anything running above it (IPv4, IPv6, DHCP, ARP, etc.) regardless of how many physical hops separate them.
- Linux kernel docs: https://docs.kernel.org/networking/batman-adv.html
- LWN overview: https://lwn.net/Articles/426947/
- Wikipedia summary: https://en.wikipedia.org/wiki/B.A.T.M.A.N.
**Core mechanism — Originator Messages (OGMs):** every node periodically broadcasts an OGM to announce its own existence. Neighbors that hear it rebroadcast it (subject to protocol rules), flooding the OGM outward hop by hop until the whole mesh has seen it, possibly via multiple paths. Each node tracks, per known "originator" (i.e., per other node), which of its own direct neighbors is currently the best next hop toward that originator — it does **not** compute or store a full end-to-end path, only "who do I hand this frame to next." This is classic distance-vector-style behavior adapted for wireless: no central coordinator, self-healing on topology change, but growing table/overhead cost as the mesh scales (author estimate: fine to ~1,000 nodes, not designed for much beyond that).
- OGM field reference: https://www.open-mesh.org/doc/batman-adv/OGM.html
- Original protocol internet-draft (detailed OGM semantics, bidirectional-link checks, sequence numbers): https://www.ietf.org/archive/id/draft-wunderlich-openmesh-manet-routing-00.txt
- Academic writeup of OGM structure and the neighbor-ranking "sliding window": https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2024-09-1/NET-2024-09-1_02.pdf
Because batman-adv is transport-agnostic at layer 2, it can route across heterogeneous "hard interfaces" simultaneously attached to the same `bat0` — Wi-Fi, Ethernet, VPN tunnels, etc. — and picks whichever hard interface currently looks best per originator. This multi-interface capability (bonding/alternating, discussed in §3) is the mechanism the team is deliberately opting **out** of for the control/video split.
**Practical setup primitive** (same across all uses):
```
ip link add name bat0 type batadv
ip link set dev wlan0 master bat0
ip link set up dev bat0
ip addr add 192.168.0.1/24 dev bat0
```
Diagnostics run through `batctl` (ping, traceroute, tcpdump, neighbor/originator tables) since normal L3 tools don't see through the L2 abstraction cleanly.
---
## 2. BATMAN_V vs legacy BATMAN_IV
batman-adv ships two selectable routing algorithms, set per mesh interface via `routing_algo` (`BATMAN_IV` or `BATMAN_V`); they are **not** interoperable with each other on the same mesh.
| | BATMAN_IV | BATMAN_V |
|---|---|---|
| Link metric | **Transmit Quality (TQ)**: derived by counting OGMs successfully echoed/received, essentially a packet-loss-based estimate | **Throughput-based**: queries the wireless driver via cfg80211 for expected throughput (accounts for modulation/rate, retransmissions) |
| Discovery vs. path-quality | Combined in one OGM | **Split**: ELP (Echo Location Protocol) handles neighbor discovery/link-quality probing at high frequency (~500ms) without being flooded mesh-wide; OGMv2 propagates path quality mesh-wide, so it can run at a slower interval, reducing overhead |
| Maturity / default | Default in most distros (OpenWrt, LibreMesh) as of 2018–2025; considered the mature, "boring but works" option | Newer design, theoretically more accurate under real-world radio conditions (avoids TQ's tendency to overestimate link quality because OGM broadcasts often go out at low, robust modulation rates that don't reflect actual unicast throughput) |
| Known field issues | None broadly reported | Multiple independent reports of instability: OpenWrt wiki author explicitly recommends staying on BATMAN_IV "until BATMAN_V is ready for actual use," citing an OpenWrt forum thread of on-prem connectivity loss (https://forum.openwrt.org/t/batman-v-routing-on-prem-connectivity-loss-seen/20432); a LibreMesh GitHub issue reports BATMAN_V "not correctly detecting throughput of the wifi interfaces, indicating all of them as zero throughput" during a Wireless Battle Mesh field test (https://github.com/libremesh/lime-packages/issues/1009); a 2024 EWSN poster documents ongoing throughput-detection bugs when wireless interfaces sit behind more than one virtual layer (e.g., macsec bridges) and slow EWMA convergence causing ~10s lag before BATMAN_V reacts to a real throughput drop (https://ewsn.org/file-repository/ewsn2024/ewsn2024posters-final14.pdf) |
Sources: https://en.wikipedia.org/wiki/B.A.T.M.A.N. · https://openwrt.org/docs/guide-user/network/wifi/mesh/batman · https://libremesh.org/reference/network/protocols-options.html · https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_V (page itself blocked by an anti-scraper challenge at fetch time, but corroborated via the above three independent sources) · FreiFunk conference slides on interface alternating/ELP/OGMv2 split: https://media.hamburg.freifunk.net/geekend/2014.ffnordcon/batman-adv-assessment%2Blookout-ffnordcon2014.pdf
**Recommendation for this project:** default to **BATMAN_IV** for both legs, especially the control leg. TQ/packet-loss metrics are a known quantity, the code path is more battle-tested, and the specific failure mode reported for BATMAN_V (misdetecting throughput as zero, or an all-around 10-second lag reacting to a real degraded link) is exactly the kind of silent-failure risk you don't want on a control channel. BATMAN_V's theoretical advantage (better differentiation between similar-looking links) matters more for the video leg where you have more bandwidth headroom and more tolerance for the algorithm being slow to react — even there, given the reported instability, BATMAN_IV is the safer starting point; only benchmark BATMAN_V once IV is a known-working baseline. Note also: OpenMANET's own roadmap explicitly plans BATMAN_V for **bonding HaLow + 2.4GHz uplinks together** (https://openmanet.github.io/docs/hardware/raspberry-pi) — which is precisely the bonded-mesh behavior your team has decided to avoid, so that roadmap item isn't directly relevant to your unbonded design, but it does suggest BATMAN_V is the algorithm the project maintainers consider "future" rather than "default."
---
## 3. The exact unbonded dual-radio config
### Why bonding/alternating can't be trusted for traffic-type separation
batman-adv's native multi-interface handling has two built-in modes, both metric-driven and both blind to what kind of traffic is in the frame:
- **Bonding**: when a `bat0` mesh interface has multiple hard interfaces of similar quality attached, it can round-robin frames across all of them simultaneously for higher aggregate throughput. Toggled via `batctl bonding 1` / netlink `BATADV_ATTR_BONDING` (kernel patch reference: https://lists.openwall.net/netdev/2018/11/23/89).
- **Interface alternating** (the *default* multi-interface behavior when bonding is off): at each hop, batman-adv prefers **not** to forward back out the interface a frame arrived on, and network-wide interface alternating (introduced with BATMAN_V's path-diversity work) tries to route different flows over different interfaces network-wide based on the path metric — e.g., alternating 5GHz → 2.4GHz → 5GHz hop by hop purely to avoid half-duplex self-interference (https://media.hamburg.freifunk.net/geekend/2014.ffnordcon/batman-adv-assessment%2Blookout-ffnordcon2014.pdf).
Neither mechanism has any concept of "this flow is safety-critical control, keep it on radio A no matter what." Both operate purely on measured link quality/throughput per hop. A styrene.io technical writeup independently confirms this framing: "N+1 routing tables: per-interface tracking of best next-hop... Interface alternating (default): switches interfaces at each hop... Bonding mode: all interfaces used simultaneously" (https://mesh.styrene.io/docs/research/batman-adv/) — i.e. exactly the behavior the team wants to avoid for the control path. `hop_penalty` (per-hard-interface, tunable 0–255% degradation applied to TQ/throughput per hop) exists to bias which interface batman-adv *prefers*, but it's a soft bias on a shared metric, not a hard traffic-class pin (kernel patch: https://github.com/MotorolaMobilityLLC/kernel-msm/commit/3bda14d09dc5789a895ab02b7dcfcec19b0a65b3). This validates the team's decision to not rely on any single-bat0 bonded/alternating configuration.
### The pattern: two independent, unbonded batX instances
This is a real, documented pattern — not a hack unique to this project. Two corroborating sources:
1. **A production ground-station reference implementation** (AltNautica's FPV/UGV ground-agent docs) runs exactly this architecture: two separate USB Wi-Fi radios of the *same chipset*, each doing an entirely separate job — one runs WFB-ng (video/telemetry link to the drone) in monitor mode, the other runs `batman-adv` as `bat0` purely for ground-station-to-ground-station mesh relay. They are never bridged or bonded together; each stays on its own dedicated adapter and channel. Direct source: https://docs.altnautica.com/ground-agent/batman-adv (see the two-adapter table: "Primary RTL8812EU: WFB-ng... Mesh carrier RTL8812EU: batman-adv mesh"). This is architecturally the closest real-world analog to your design — same "keep the safety/control-relevant radio separate from the payload radio" principle.
2. **A batman-adv kernel commit message** documenting a historical community workaround: "Some creative solutions are currently in use: Such people are configuring multiple batman-adv mesh/soft interfaces, wire them together with some veth pairs and then tune the hop penalty to achieve an effect similar to a tunable per interface hop penalty" (https://github.com/MotorolaMobilityLLC/kernel-msm/commit/3bda14d09dc5789a895ab02b7dcfcec19b0a65b3). This confirms multiple independent `batX` mesh interfaces on one host is a known, if non-default, configuration — the kernel devs even added the per-hard-interface `hop_penalty` knob specifically because people were already doing this.
### Concrete Linux implementation steps
Each physical radio gets its own independent batman-adv soft interface — no shared `bat0`, no veth bridging between them (unlike the historical workaround above, you don't need to bridge them since you want them to stay logically separate, not just quality-biased):
```bash
# --- Control leg: 900MHz HaLow interface (e.g. wlan_halow) ---
modprobe batman-adv
ip link add name bat0 type batadv
batctl meshif bat0 interface create routing_algo BATMAN_IV # explicit, don't rely on default
ip link set dev wlan_halow master bat0
ip link set up dev wlan_halow
ip link set up dev bat0
ip addr add 10.42.0.X/24 dev bat0 # control subnet
# --- Video leg: 2.4GHz interface (e.g. wlan_24) ---
ip link add name bat1 type batadv
batctl meshif bat1 interface create routing_algo BATMAN_IV
ip link set dev wlan_24 master bat1
ip link set up dev wlan_24
ip link set up dev bat1
ip addr add 10.43.0.X/24 dev bat1 # video subnet, separate /24
```
Named `.netdev`/`.network` units under systemd-networkd are a cleaner way to make this persistent (a full worked example, including the MTU bump required for batman-adv's L2 overhead, is documented here: https://gist.github.com/requinix/4167ac09242684ac23f484543ac8bbcd — note its caveat that Netplan itself cannot configure batadv interfaces and you must drop to raw systemd-networkd `.netdev`/`.network` files, or use `batctl`/`ip` directly in a boot script if not using systemd-networkd).
### Steering traffic per-interface: SO_BINDTODEVICE + ip rule
Two complementary mechanisms, matching the two subnets above:
- **Application-level (preferred for your own control/video processes):** `setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, "bat0", ...)` forces that socket's traffic onto the `bat0` (control) or `bat1` (video) path specifically. Per `curl --interface` semantics (verified against strace output): binding to a device still performs a route lookup restricted to routes through that device; if no explicit route exists, Linux falls back to an on-link route with no gateway. Reference: https://superuser.com/questions/1877085/curl-interface-so-bindtodevice-and-tunnel-interfaces
- **System/policy-level (for anything that doesn't call SO_BINDTODEVICE itself, or to enforce the split even if an app misbehaves):** `ip rule` + per-interface routing tables. Since each leg has its own subnet (10.42.0.0/24 vs 10.43.0.0/24 above), default routing will already mostly separate them by destination, but to be robust against apps binding to a *source IP* rather than an interface, add explicit rules:
```bash
ip rule add from 10.42.0.X lookup control_table
ip rule add oif bat0 lookup control_table
ip route add default dev bat0 table control_table # or via specific gateway if applicable
ip rule add from 10.43.0.X lookup video_table
ip rule add oif bat1 lookup video_table
ip route add default dev bat1 table video_table
```
`ip rule` man page (RPDB semantics, `oif`/`iif`/`from` selectors): https://man7.org/linux/man-pages/man8/ip-rule.8.html. A worked two-interface example with exactly this from/oif/table pattern: https://unix.stackexchange.com/questions/177398/connect-through-different-interfaces-to-the-same-server-so-bindtodevice-desti
### Known gotchas
- **MTU**: batman-adv adds its own header overhead. The systemd-networkd example and OpenWrt docs both call out bumping the hard interface's MTU to 1560+ (Ethernet) or up to 2304 (802.11s) to avoid batman-adv silently fragmenting every packet at L2, which costs throughput. Watch dmesg for `batman_adv: bat0: The MTU of interface X is too small` warnings.
- **rp_filter / reverse-path filtering**: `net.ipv4.conf.*.rp_filter` set to strict (1) or even loose (2) mode can silently drop return traffic on a bound socket if the corresponding `ip rule`/route isn't symmetric — the unix.stackexchange thread above documents exactly this failure mode and its fix (disable rp_filter on the relevant interfaces, or ensure routes exist for both directions).
- **No native batman-adv encryption/auth** — OpenWrt docs explicitly note this ("batman-adv does not provide encryption or authentication. If required, it should be implemented either or both in the underlying transport... or protocols"), so any competition rules around RF security need to be satisfied at the 802.11 (WPA3/SAE on the 802.11s mesh layer, see §5 below) or application layer, not by batman-adv itself.
- **Netplan cannot configure batadv interfaces at all** (confirmed 2023, still true) — plan on either raw systemd-networkd unit files or a boot-time shell script using `ip`/`batctl` directly.
- **BATMAN_V zero-throughput bug** through more than one virtual-interface layer (§2) — if you ever bridge/macsec either leg, re-verify BATMAN_V's throughput detection isn't silently reporting 0.
---
## 4. Jetson kernel module support
**Short answer: batman-adv is not shipped/enabled in NVIDIA's stock JetPack/L4T kernel config for Orin Nano. Getting it requires a full custom kernel rebuild, and at least one team hit a boot-breaking failure doing exactly that on JetPack 6.2.**
Cross-verification across independent sources:
1. **Direct incident report (primary evidence):** an NVIDIA Developer Forums thread from July 2025, Jetson Orin Nano DevKit, JetPack 6.2 (L4T R36.4.3), kernel 5.15.148-tegra. The poster used the community OE4T `jetson-orin-nano-builder` workflow to rebuild the kernel with `CONFIG_MAC80211=y`, `CONFIG_MAC80211_MESH=y`, `CONFIG_CFG80211=y`, `CONFIG_BATMAN_ADV=m` added on top of the stock config, built `Image` + modules, deployed, and the device **failed to boot from NVMe** (boot loop / black screen) — only reverting to the stock kernel restored boot. This confirms two things: (a) batman-adv/mesh support is **not** present in the config NVIDIA ships by default (the poster had to explicitly add these symbols), and (b) enabling it via a full custom kernel build is not risk-free on this platform — a support engineer in the thread pointed toward OOT-module/initrd mismatches as the likely cause (the deployed modules must also be present in the initrd, not just `/lib/modules`, if any early-boot driver depends on them). Thread (unresolved at last reply): https://forums.developer.nvidia.com/t/jetson-orin-nano-fails-to-boot-from-nvme-after-enabling-mac80211-mesh-batman-adv-built-using-oe4t-builder/338031
2. **Corroborating: no batman-adv in Jetson defconfigs.** The historical OE4T defconfig for older Jetson kernels (`tegra_defconfig`, L4T r32.4 / kernel 4.9 era) enables `CONFIG_CFG80211=m` and `CONFIG_MAC80211=m` (general Wi-Fi stack) but has **no `CONFIG_BATMAN_ADV` entry at all** — https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.4/arch/arm64/configs/tegra_defconfig. Searches for a Jetson-specific defconfig with `BATMAN_ADV` already enabled turned up nothing across NVIDIA's own kernel-customization docs or the OE4T project pages, and multiple independent NVIDIA forum threads about enabling other non-default networking kernel options (e.g. `CONFIG_NETFILTER_XT_MATCH_RPFILTER`, `CONFIG_IP_SET` for Calico/K8s: https://forums.developer.nvidia.com/t/kernel-option-setting-failed/333168) confirm the general pattern: any networking feature outside NVIDIA's curated default set is not present and must be manually enabled via a from-source kernel rebuild — there is no lighter-weight "just modprobe it" path on Jetson the way there often is on generic desktop/server kernels that ship batman-adv as a stock module.
3. **The custom-kernel-build process itself has a track record of pain independent of batman-adv specifically** — multiple 2024–2025 forum threads document Orin Nano JetPack 6.x custom kernel builds hitting `nvidia-oot` module redefinition errors, sign-file/openssl build failures, and cross-compile vs. native-compile inconsistencies before even reaching the point of testing a new driver (https://forums.developer.nvidia.com/t/issues-building-custom-kernel-36-4-new-jetson-orin-nano-dev-kit/309215). This is general Jetson kernel-rebuild friction, not batman-adv-specific, but it raises the effective cost/risk of the "just recompile the kernel" path for a competition team on a deadline.
**No evidence found of anyone successfully running batman-adv on a Jetson Orin Nano/NX in production.** I could not find a single forum post, blog, or repo confirming a working batman-adv build on Jetson Orin hardware — only the one failed attempt above. This should be treated as an open risk, not a solved problem (see §6).
**Practical implication for your architecture:** OpenMANET's own reference implementation runs entirely on Raspberry Pi + OpenWrt (kernel 6.6.104, mainline mac80211 backports — https://openmanet.github.io/docs/firmware), *not* Jetson. If the Jetson (running your autonomy/vision stack) needs to be a **mesh participant itself** (i.e., run its own `bat0`/`bat1` and attach a radio directly), you're in the unverified, custom-kernel-build territory documented above. If instead the Jetson sits **behind** the Raspberry Pi HaLow node as a plain Ethernet client (RPi does the meshing, Jetson just gets an IP on the mesh subnet via the RPi's LAN/bridge), you avoid the Jetson kernel problem entirely — batman-adv never needs to run on the Jetson. This distinction is significant enough that it should be an explicit architecture decision, not an assumption (flagged again in §6).
---
## 5. Real-world robotics/UGV use cases
- **DARPA Subterranean (SubT) Challenge Final Event** (multi-robot ground+air exploration, 3rd place finish) — the most substantive published field evaluation of batman-adv for robotics found in this research. The team explicitly evaluated batman-adv as a layer-2 meshing option and **partnered with Meshmerize GmbH to build on/replace it** for their final competition stack, because in their preliminary evaluation batman-adv took ~10s to re-establish connectivity after a topology change vs. ~1s for Meshmerize (which prioritizes fast reconnect over optimal routing). Their final system carried 125.2MB of telemetry/mapping data over one hour with robots relaying through each other; batman-adv was the baseline they measured against, not what they shipped. Paper (open access): https://ar5iv.labs.arxiv.org/html/2203.12832. This is a directly relevant caution: if your mesh needs sub-second reconnect after a robot repositions or a link drops, vanilla batman-adv's ~10s reconvergence (per this independent field measurement) may be too slow for a fast-moving competition rover, and is worth load-testing early rather than assuming.
- **TIERS (University of Turku) scalable MAV swarm project** — ROS2 + Wi-Fi mesh (batman-adv) + UWB positioning on Raspberry Pi Zero W nodes, with a documented `batman-adv-setup` guide as part of their swarm bring-up process. Confirms batman-adv is a live, current choice in academic multi-robot networking, specifically on Raspberry Pi-class hardware (same platform class as your HaLow leg). Repo: https://github.com/TIERS/scalable-mav-swarm-with-ros2-batman-uwb
- **AltNautica ground-agent architecture** (already cited in §3) — a production dual-radio design nearly identical in spirit to yours: one radio for the primary control/video link, a second independent radio running batman-adv purely for ground-station mesh relay, deliberately kept unbonded and on separate hardware. https://docs.altnautica.com/ground-agent/batman-adv
- **Competition rovers generally favor commercial bonded-cellular solutions over batman-adv.** The West Virginia University Mountaineer Mars Rover (NASA RASC-AL Robo-Ops, 2nd place 2016) used Peplink/Pepwave SpeedFusion cellular bonding rather than a Wi-Fi mesh protocol — relevant mainly as a contrast: that's a cellular-bonding approach (multiple WAN links bonded for redundancy over infrastructure networks), a different problem than your line-of-sight RF mesh in an unlicensed band. https://www.peplink.com/case-studies/west-virginia-robotics-team-rover-networking/
- **BYU's 2025 University Rover Challenge telemetry paper** used ROS1/ROS2 over a long-range point-to-point antenna link, not a mesh — no batman-adv or mesh networking mentioned. Included here for completeness/contrast: most URC/Robo-Ops-style competition teams are still on single point-to-point links, not mesh. https://repository.arizona.edu/handle/10150/679589
- General academic backdrop on multi-robot mesh networking choices: a 2024–2025 study comparing ROS2 middleware (FastRTPS/CycloneDDS/Zenoh) over a dynamic mesh topology for planetary-exploration-style multi-robot systems recommends Zenoh for reachability/CPU/overhead reasons in mesh scenarios — worth keeping in mind for whatever pub/sub layer runs over your batman-adv control link, independent of the L2 mesh choice itself. https://orbilu.uni.lu/bitstream/10993/64125/1/_Cleared__Springer___Mesh_Network.pdf
---
## Open questions / unresolved
1. **No confirmed working batman-adv build exists on Jetson Orin hardware** (Orin Nano/NX) as of this research. The only concrete data point found is a failed attempt (boot loop on NVMe). If the Jetson itself must run batman-adv (rather than sitting behind the RPi as a plain client), budget real time for kernel-build risk and have a fallback plan (e.g., route the Jetson's traffic to the RPi mesh node over a simple Ethernet link and let the RPi do all the meshing) before committing to this on a competition timeline.
2. **batman-adv's real-world reconvergence time (~10s per the DARPA SubT team's measurement) may be too slow** for a rover that can lose/regain line-of-sight quickly during a run. This wasn't tested for your specific HaLow/2.4GHz combination and should be benchmarked directly (deliberately break and restore a link, time reconnect) rather than assumed acceptable.
3. **BATMAN_V's field-reported bugs (zero-throughput misdetection, slow EWMA convergence) were not tested against Morse Micro HaLow hardware specifically** — all the negative reports found are from generic 802.11 (ath9k/ath5k-class) hardware. It's unconfirmed whether these issues reproduce on HaLow; recommend starting on BATMAN_IV regardless (see §2) and treating BATMAN_V as an experiment, not a default.
4. **Whether the Morse Micro/Seeed WM1302 HaLow driver plays well with `mac80211_mesh` (802.11s) the same way OpenMANET's OpenWrt image does was confirmed for OpenWrt, but not verified for a stock Raspberry Pi OS / non-OpenMANET-firmware setup**, if the team intends to build on top of raw Raspberry Pi OS instead of flashing the OpenMANET firmware image directly. Given OpenMANET already ships a maintained image with 802.11s + batman-adv wired together, using their image as-is (rather than reinventing that integration) is the lower-risk path unless there's a specific reason not to.
5. **No published data was found on batman-adv reconvergence or throughput specifically over Wi-Fi HaLow** (all HaLow performance papers found measure raw 802.11ah throughput/latency/range, not batman-adv running on top of it). The throughput and latency numbers in §5 (e.g., ~1–2 Mbps at a few hundred meters LoS, single-digit-ms to low-tens-of-ms latency in short range) are for raw HaLow links; batman-adv's OGM/ELP overhead and multi-hop forwarding will add some additional latency/overhead on top, magnitude untested here.
6. **Competition RF rules** (if any apply to your event, e.g. max EIRP, band restrictions on 900MHz ISM or 2.4GHz) weren't in scope for this research pass and should be checked separately before finalizing radio selection.