Every node is legal. Each entry names the spec behavior it exercises, the worst-case parameters the conductor may dial in, the hardware it runs on, and what it does to victims. Nodes are grouped by band because the interference regime is completely different per band:

• 2.4 GHz — the war zone. Bluetooth BR/EDR, BLE, 802.15.4, Wi-Fi, microwave ovens, and proprietary 2.4 GHz all share ~83 MHz. Only three non-overlapping 20 MHz Wi-Fi channels. This band gets the harshest grading.
• 5 GHz — Wi-Fi only. More spectrum, wider channels, DFS radar events. The fight here is Wi-Fi-on-Wi-Fi: co-channel contention and OBSS overlap.
• 6 GHz — Wi-Fi 6E/7 only. No legacy clients, 1200 MHz of clean spectrum (US). Worst case is many overlapping wide (80/160 MHz) BSSes.

The conductor composes scenarios from this catalog and never invents a node. rf-observer instances are passive measurement, not interferers.

2.4 GHz

inquiry-looper — BR/EDR

• Spec basis: Inquiry trains, 3200 hops/s, no AFH (Core Spec, Vol 2, Part B). The most disruptive legal behavior in Bluetooth.
• Worst case: back-to-back 10.24 s inquiry trains, zero gap, indefinite.
• Hardware: Raspberry Pi 5 + BT 5.x USB dongle, BlueZ hcitool inq loop. Stock behavior, no special firmware.
• Victim impact: broadband 2.4 GHz noise; nearby piconets lose slots, Wi-Fi on ch 1/6/11 takes collateral damage.
• Models: phones doing discovery, car kits that never stop inquiring.

page-stormer — BR/EDR

• Spec basis: Page trains, 3200 hops/s, no AFH.
• Worst case: continuous paging of a device that will never answer (R0 train repetition).
• Hardware: Pi 5 + BT dongle.
• Victim impact: same class as inquiry, narrower but persistent.
• Models: a master aggressively re-paging a dead link.

discoverable-responder — BR/EDR

• Spec basis: Inquiry scan + Extended Inquiry Response (up to 240 bytes).
• Worst case: permanently discoverable, answers every inquiry with full EIR.
• Hardware: Pi 5 + BT dongle.
• Victim impact: TX load proportional to inquirer density; EIR packets are long.
• Models: devices left in pairing mode forever.

a2dp-hog — BR/EDR

• Spec basis: A2DP streaming with DH5 packets, no sniff mode.
• Worst case: continuous max-bitrate stream, sniff disabled, full 79-channel AFH map (no Wi-Fi avoidance).
• Hardware: Pi 5 + BT dongle. Requires controller test/engineering mode to force the AFH map; scenario DSL marks it requires: test_mode.
• Victim impact: near-constant slot occupancy across the whole band.
• Models: worst-case music-streaming neighbor.

ble-adv-spammer — BLE (x3 instances)

• Spec basis: Advertising interval floor 20 ms, all 3 primary channels.
• Worst case: 20 ms interval, +8 dBm TX, 31-byte non-connectable payloads, all three primaries, indefinite.
• Hardware: ESP32-S3-DevKitC-1, ESP-IDF, ~50 lines.
• Victim impact: collides with every other advertiser; forces every nearby scanner to wake and process.
• Models: dense beacon deployments, conference-hall hell.

ble-active-scanner — BLE

• Spec basis: 100% duty-cycle active scanning.
• Worst case: scan window = scan interval, active (scan requests to every advertiser), indefinite.
• Hardware: ESP32-S3.
• Victim impact: constant scan-request traffic; raises the noise floor for other scanners.
• Models: asset-tracking gateways, the parked car waiting for phone-key.

ble-conn-saturator — BLE

• Spec basis: multi-connection central, minimum 7.5 ms connection interval.
• Worst case: max simultaneous connections, 7.5 ms intervals, continuous GATT traffic.
• Hardware: Nordic nRF52840 DK, nRF Connect SDK central example.
• Victim impact: eats connection-event airtime neighbors must work around.
• Models: a hub with too many peripherals.

ble-extadv-spammer — BLE

• Spec basis: Extended advertising with chained AUX packets on secondary (data) channels.
• Worst case: max-length advertising chains, minimum interval.
• Hardware: nRF52840 DK.
• Victim impact: unlike legacy adv, this eats data-channel airtime.
• Models: AoA/AoD RTLS tags, electronic shelf labels at scale.

auracast-tx — LE Audio

• Spec basis: Broadcast Isochronous Streams (BIS), one-to-many by design.
• Worst case: continuous broadcast, max retransmissions.
• Hardware: Nordic nRF5340 Audio DK, stock broadcast-source example.
• Victim impact: permanent reserved periodic airtime on shared channels.
• Models: airport/gym Auracast that never turns off.

phonekey-sim — BLE pair

• Spec basis: aggressive peripheral advertising + 100% duty-cycle central scanning (the phone-as-key pattern).
• Worst case: phone side advertises at minimum interval at high TX power; car side scans continuously. Both sides at once.
• Hardware: Android phone + ESP32 acting as the car.
• Victim impact: the full-duplex version of adv-spammer + active-scanner.
• Models: first-gen phone-as-key implementations that chose brute-force duty cycle over smart discovery.

wifi-ap-farm-2g — Wi-Fi (x4 instances)

• Spec basis: beacons at lowest basic rate; 40 MHz operation in 2.4 GHz.
• Worst case: 100 ms beacons at 1 Mbps basic rate, max TX power; one AP on 40 MHz straddling channels; iperf load on top.
• Hardware: 4x OpenWrt-capable dual-band APs. All stock UCI knobs.
• Victim impact: beacons alone consume a large fraction of airtime at 1 Mbps; the 40 MHz AP stomps two of the three clean channels; every BT radio in the room pays.
• Models: the apartment building.

wifi-slow-client-2g — Wi-Fi

• Spec basis: low-MCS bulk upload (legal, just far away).
• Worst case: MCS0 uploads saturating the medium.
• Hardware: laptop/Pi at the chamber edge behind extra attenuation.
• Victim impact: one slow client hogs airtime, starves everyone without airtime fairness — including BT coexistence on the DUT's combo chip.
• Models: the neighbor's security camera uploading to the cloud.

probe-stormer-2g — Wi-Fi

• Spec basis: active scanning with probe requests.
• Worst case: rotating-MAC wildcard probes across all 2.4 GHz channels, continuous.
• Hardware: Pi + Wi-Fi dongle.
• Victim impact: every AP in earshot answers every probe; discovery traffic becomes the dominant traffic. The Wi-Fi analog of inquiry.
• Models: crowds of phones hunting for known networks.

zigbee-chatter — 802.15.4

• Spec basis: Zigbee reporting, minimum report intervals.
• Worst case: coordinator + 6 end devices on 802.15.4 ch 11–14 (overlapping Wi-Fi ch 1), reporting at minimum intervals.
• Hardware: TI CC2652 USB stick + cheap Zigbee sensors.
• Victim impact: persistent narrowband chatter inside the Wi-Fi/BT band.
• Models: the smart home next door.

microwave-oven — real-world tier, 2.4 GHz

• Spec basis: none (not a spec device) — magnetron broadband noise ~2.45 GHz.
• Worst case: running empty-ish on high, door closed, on a timer cycle.
• Hardware: any 1000 W consumer microwave.
• Victim impact: ~50% duty-cycle broadband blast; the classic.
• Models: the office kitchen. Opt-in only; excluded from default scenarios.

5 GHz — Wi-Fi only

No Bluetooth lives here. The fight is Wi-Fi-on-Wi-Fi plus DFS.

wifi-ap-farm-5g — Wi-Fi (x3 instances)

• Spec basis: dense OBSS deployments; 80 MHz channels legal.
• Worst case: 3 APs on overlapping 80 MHz channels (e.g. all on ch 42), max TX power, 6 Mbps beacons, iperf load; one AP on a DFS channel.
• Hardware: OpenWrt-capable dual-band/6E APs (5 GHz radio).
• Victim impact: co-channel contention collapses per-BSS throughput; OBSS preamble-detection forces deferral across the whole 80 MHz.
• Models: the office floor, the apartment block's 5 GHz spillover.

wifi-slow-client-5g — Wi-Fi

• Spec basis: low-MCS bulk upload on 5 GHz.
• Worst case: VHT MCS0 upload saturating an 80 MHz BSS.
• Hardware: laptop/Pi behind attenuation.
• Victim impact: airtime hogging on the wide channel; without airtime fairness one client halves everyone's throughput.
• Models: the far-bedroom laptop on a video call.

probe-stormer-5g — Wi-Fi

• Spec basis: active scanning across UNII bands.
• Worst case: rotating-MAC wildcard probes across all 5 GHz channels, continuous.
• Hardware: Pi + Wi-Fi dongle.
• Victim impact: probe-response storms from every 5 GHz AP in earshot.
• Models: conference crowds with aggressive roaming.

dfs-event-sim — Wi-Fi, TEST MODE

• Spec basis: DFS radar detection forces channel vacate (regulatory).
• Worst case: radar pulse patterns triggering repeated channel switches on the DFS AP, with clients forced to follow via CSA.
• Hardware: RF signal generator with radar pulse profiles, OR chamber APs in test mode with injected radar-detect events. Requires human approval per run; never radiate radar-like pulses outside the chamber.
• Victim impact: repeated channel-switch announcements, client disassociations, throughput cliffs during vacate.
• Models: living near an airport/weather radar.

6 GHz — Wi-Fi 6E/7 only

1200 MHz of clean spectrum (US), no legacy clients, LPI/AFC rules. Worst case is overlapping wide BSSes, not legacy overhead.

wifi-ap-farm-6g — Wi-Fi (x2 instances)

• Spec basis: 80/160 MHz BSSes in 6 GHz; LPI indoor operation.
• Worst case: 2 APs on overlapping 160 MHz channels (e.g. both on ch 15), max LPI TX power, iperf load.
• Hardware: Wi-Fi 6E APs (OpenWrt where supported, else stock with max legal settings).
• Victim impact: 160 MHz OBSS contention; preamble puncturing behavior under overlap.
• Models: the early-adopter neighbor with everything on 6 GHz.

wifi-slow-client-6g — Wi-Fi

• Spec basis: low-MCS upload on a 160 MHz BSS.
• Worst case: HE MCS0 upload holding the wide channel.
• Hardware: laptop/Pi behind attenuation.
• Victim impact: airtime hogging at 160 MHz scale.
• Models: the 6 GHz client at the edge of range.

Passive observers (NOT interferers)

rf-observer-2g

• nRF52840 DK with sniffer firmware + Wireshark (BLE), monitor-mode Wi-Fi adapter (Wi-Fi/probes), btmon on a dedicated Pi (BR/EDR). Captures DUT advertising intervals, TX behavior, inquiry/page events, probe requests, per-radio duty cycle. Feeds citizenship scoring.

rf-observer-5g6g

• Monitor-mode Wi-Fi 6E adapter capturing 5/6 GHz management traffic: DUT probe behavior, channel-width choices, DFS CSA handling, TXOP/airtime share. Feeds citizenship scoring for the companion phone/laptop side.

Out of scope (noted for completeness)

• Sub-1 GHz (Zigbee/Thread 868/915, LoRa): no overlap with wearable links; relevant only if the companion phone acts as a Thread border router. Noted, not built.
• 5 GHz DFS radar outside dfs-event-sim: real radar is not ours to transmit.