The Radio Links Compared — ESP-NOW, Bluetooth LE, LLPM and Enhanced ShockBurst

Every practical light-gun radio lives in the same 83.5 MHz of spectrum at 2.4 GHz, so the choice is not between frequencies but between protocols: how a report is framed, when it is allowed onto the air, who acknowledges it, and what the PC sees at the other end. This volume compares the candidates with numbers. The hardware that runs each is Volume 3; the end-to-end latency is Volume 4.

2.1 What the Link Has to Do

From Volume 1, 1.4, five requirements, in order of how hard they are to meet:

1. Present the same USB devices as a cabled gun: the absolute mouse, keyboard and gamepad reports, and the serial port for force feedback. MiSTer finds an OpenFIRE gun by vendor ID 0xF143, the name prefix “OpenFIRE ” and its serial device, to which it writes M0x9 (Open-Source Firmware Vol 6, 6.5). A link that delivers only HID loses MiSTer’s light-gun mode and every game-driven recoil effect.
2. Add little latency, and little variation. A cabled gun waits 0 to 1 ms for the USB poll (Fully Wired Vol 5, 5.7). The gun’s whole share, camera frame to USB report, is 2.7 to 8.8 ms (Aiming Maths and Calibration Vol 7, 7.5). A link that adds a few hundred microseconds is invisible against that; one that adds a camera frame or more is not.
3. Send fresh position, deliver commands reliably (Volume 1, 1.4).
4. Work with four guns in one room. OpenFIRE supports four player identities; multiplayer light-gun games are the point of many cabinets.
5. Use a radio that can legally be put in a hand-held product someone else buys (Volume 6), if kits are ever sold (D11).

2.2 One Band, Everyone in It

In a house the band already carries the home’s Wi-Fi access point and its clients, every phone’s and laptop’s Bluetooth, wireless mice and keyboards, Zigbee or Thread devices, and, while it runs, a microwave oven. The protocols below differ mainly in how they share it:

• Wi-Fi and ESP-NOW sit on one 20 MHz channel and contend for it by listening before talking (carrier sense with random back-off). They share airtime with whatever else is on that channel and its neighbours.
• Bluetooth LE hops: a connection moves to a new 2 MHz data channel at every connection event, and the controller can drop channels it finds bad (adaptive frequency hopping). Interference costs it occasional retransmissions rather than a whole channel.
• Nordic’s proprietary modes run on a channel the firmware chooses, in 1 MHz steps; frequency agility is whatever the application adds.

Volume 4 turns this into packet-loss behaviour; here it is enough that none of these links owns its spectrum. The ESP32 port’s dongle copes by scanning before it settles (2.3).

2.3 ESP-NOW

ESP-NOW is Espressif’s connectionless protocol on top of the Wi-Fi radio: no access point, no association, just addressed frames between two radios on the same channel. Espressif’s documentation (ESP-IDF, ESP32-S3, read 19 October 2026) gives the frame as a Wi-Fi vendor-specific action frame:

Table 1 — ESP-NOW is Espressif's connectionless protocol on top of the Wi-Fi radio: no access point, no association, just addressed frames between two radios on the same channel. Espressif's documentation (ESP-IDF, ESP32-S3, read 19 October 2026) gives the frame as a Wi-Fi vendor-specific action frame

Field	Bytes
MAC header	24
Category code (127, vendor specific)	1
Organization identifier (0x18FE34)	3
Random values	4
Vendor-specific content header	7
Payload	up to 250 (1,470 in ESP-NOW v2.0)
FCS	4

A unicast frame is acknowledged at the MAC layer, and the send callback reports success when the data was “received successfully on the MAC layer”; the documentation adds that “it is not guaranteed that application layer can receive the data” and recommends application-level acknowledgements and sequence numbers where that matters. The default bit rate is 1 Mbps.

What the OpenFIRE port does with it (from shared_lib/OpenFIRE_Wireless/ESP32/OpenFIRE_Wireless.cpp, read 19 October 2026):

Table 2 — What the OpenFIRE port does with it (from sharedlib/OpenFIREWireless/ESP32/OpenFIREWireless.cpp, read 19 October 2026)

Setting	Value in the port	Effect
PHY and rate	802.11g, fixed 12 Mbps, 20 MHz	”Ensures link stability at the expense of unnecessary bandwidth”: a robust OFDM rate, eight times faster on air than the 1 Mbps default
Transmit power	WIFI_POWER_17dBm (“maximum power without distortion”; 15 dBm left as a commented alternative)	Range, at the cost of current
Power saving	esp_wifi_set_ps(WIFI_PS_NONE), “Disable power saving for maximum responsiveness”	The receiver is always on (Volume 5)
Default channel	11	The dongle overrides it by scanning
Channel scan (dongle only)	Channels 1 to 13; 150 ms per channel listening for access points, then a packet count per channel; strongest-signal weight 0.40; penalties for neighbours ±1 to ±4 of 50, 35, 20 and 10 %; an 8 % preference for 1, 6 and 11	About 15 seconds at plug-in, then fixed
Country	The gun sets country “IT”, channels 1 to 13, so that 12 and 13 work	See Volume 6: outside US module grants
Encryption	Off (peerInfo.encrypt = false)	Anyone can read the reports; nobody can usefully inject them without pairing (Volume 4)
Pedal	Keep-alive every 69 ms, link dropped after 200 ms	Tolerates one lost keep-alive

Airtime. At 12 Mbps an OFDM symbol carries 48 data bits in 4 µs. Assuming a 32-byte payload (a HID report plus the port’s own header; the exact framing was not counted), the frame is 75 bytes and occupies about 78 µs including its 20 µs preamble and 6 µs signal extension. Add the 10 µs gap, a 38 µs acknowledgement and the 28 µs listen-before-talk interval, and one clean exchange takes about 154 µs, plus a random back-off averaging about 68 µs. At 209 reports a second that is about 4.6 % of the channel per gun, and about 18 % for four guns on one channel. At the 1 Mbps default the same frame would take about 0.8 ms on its own, which is why the port’s fixed 12 Mbps matters. (Arithmetic in 04-templates/wireless_calcs.py; standard 802.11g timing.)

What ESP-NOW does not do is guarantee anything about channel access. In a channel shared with a busy access point the gun waits for silence like any Wi-Fi station, and a frame that collides is retried with a longer back-off. Volume 4 puts numbers on that.

2.4 Bluetooth LE HID Straight to the PC

The attraction is obvious: every laptop has Bluetooth, so no dongle. A Bluetooth LE mouse, keyboard or gamepad uses the HID-over-GATT profile; the PC’s operating system turns it into the same HID devices a USB gun produces.

The connection interval is the whole story. After connection, a Bluetooth LE link exchanges packets only at connection events, one every connection interval. A report written by the gun waits for the next event. The baseline specification allows intervals from 7.5 ms in steps of 1.25 ms (Bluetooth SIG, Core 6.2 feature overview; Microsoft’s Windows API documents the same units, “1.25ms increments, ranging from 0x0006”, which is 7.5 ms). Several packets can be sent in one event, so throughput is not the problem; waiting is.

• The central decides. The PC is the central; the gun can request parameters, and the host accepts, adjusts or ignores them. Windows 11 exposes three presets to applications, Balanced, PowerOptimized and ThroughputOptimized, without publishing their values; which interval a given PC grants a HID device has to be measured. Apple’s accessory guidelines, as quoted by Silicon Labs and Nordic’s forum, ask for a minimum of 15 ms and may accept 11.25 ms when a HID service is present (secondary sources; the Apple document itself was not read).
• At 7.5 ms, a report waits 0 to 7.5 ms (3.75 ms on average) for the air, before the PC’s own Bluetooth stack and HID layer add their part, which no source quantifies. At 15 ms the wait doubles. Against a gun that produces a fresh position every 4.8 ms, a 7.5 ms interval delivers 133 events a second: positions arrive in pairs, and the newest is up to a camera frame staler than on a cable.
• There is no serial channel. HID-over-GATT carries HID reports. A force-feedback channel would be a custom GATT service, which no emulator, MiSTer or MAMEHooker speaks; a host-side bridge program would be needed. OpenFIRE’s force-feedback model, and MiSTer’s detection, both assume a serial port (Open-Source Firmware Vol 6).
• The radio is the PC’s. Range, antenna placement (often behind a metal case or inside a laptop lid) and coexistence with the PC’s own Wi-Fi are whatever that machine has.

Bluetooth LE also offers the 2M PHY (Bluetooth 5), which halves time on air but not the interval; it helps power, not latency.

2.5 Bluetooth 6.2: Shorter Connection Intervals

The Bluetooth SIG’s Core 6.2 adds Shorter Connection Intervals (SCI): where “the minimum interval was 7.5 ms with a 1.25 ms resolution”, it “reduces the minimum interval to 375 µs, with 125 µs resolution”, explicitly for “high-performance HID devices, real-time HMI systems, and sensors”. The catch is in the same document: both ends must support it; otherwise “the connection remains limited to Baseline Connection Interval Values”.

The practical minimums are set by the controllers. A December 2025 hands-on guide by Novel Bits (Mohammad Afaneh, sponsored by Nordic) gives Nordic’s supported minimums as 750 µs for the nRF54L Series and 875 µs for the nRF52, nRF53 and nRF54H Series, and says smartphone support is “still emerging”, recommending “dedicated Central hardware such as gaming dongles”. Nordic’s own shorter_conn_intervals sample in the nRF Connect SDK lists the nRF5340, nRF54L15 (and its L10/L05 emulations), nRF54H20, nRF54LM20, nRF54LV10 and nRF54LC10 kits; the nRF52840 is not on its list (sdk-nrf main branch, read 19 October 2026).

For a light gun this means: SCI is a standards-based way to get sub-millisecond intervals, but only between two radios that both support it. For the foreseeable future that means a dongle built for the gun, not the PC’s own Bluetooth. It is a way to build route B (Volume 3), not a way to drop the dongle.

2.6 Nordic’s LLPM

Before SCI, Nordic offered the same thing as a proprietary extension: Low Latency Packet Mode. Nordic’s LLPM sample describes it as “designed for applications in which the interface response time is critical for the user. For example, for virtual reality headsets or gaming mouse and keyboard”, with “the lowest supported connection interval … 1 ms for one link”, on the LE 2M PHY only. Both ends must be Nordic controllers that support it. The sample builds for the nRF52840 Dongle and the nRF54L15 DK, among others, which matters because those are the boards most likely to be on hand already (D38).

Nordic’s reference HID application, nRF Desktop, uses LLPM in exactly the light-gun shape: a gaming mouse and a USB dongle, with LLPM “sending data with high report rate (up to 1000 reports per second), which is not supported by the standard Bluetooth LE”, and a dongle configuration that “supports up to four simultaneous Bluetooth LE connections in Low Latency Packet Mode”. In the current SDK the dongle configurations are for the nRF5340 DK, nRF54LM20 DK and nRF54H20 DK; the nRF52840 Dongle configuration that existed at release v2.9.0 is not on the main branch (read 19 October 2026). The application also shows the detail that makes LLPM work: the mouse keeps two reports in flight, because “submitting the hid_report_sent_event is delayed by one Bluetooth connection interval”, so that every connection event carries data.

LLPM is still Bluetooth LE underneath: connection-oriented, frequency-hopping, acknowledged, with bonding. At a 1 ms interval a report waits 0 to 1 ms for the air, then the dongle’s USB poll adds 0 to 1 ms more.

2.7 Enhanced ShockBurst

Enhanced ShockBurst (ESB) is Nordic’s oldest proprietary protocol, the one behind countless wireless mice and keyboards from the nRF24L era. The nRF Connect SDK’s ESB library (read 19 October 2026) describes:

• One receiver (PRX) and up to eight transmitters (PTX), each on its own pipe with an address of a 2 to 4 byte base plus a 1-byte prefix.
• Payloads of 1 to 32 bytes with dynamic length in legacy mode, up to 252 bytes static between nRF5 devices.
• Automatic acknowledgement, with an optional payload in the acknowledgement. The receiver can queue data that rides back to the transmitter inside the ACK.
• Automatic retransmission, count and delay configurable.
• Fast ramp-up: radio start-up falls from 130 µs (nRF51 and nRF24L) to 40 µs on nRF52 and nRF53; an experimental option keeps the transmitter ready and brings “transmission delay below 100 µs for a 4-byte payload”.
• Bit rates of 1 and 2 Mbps on nRF52; the nRF54L15 supports proprietary 2.4 GHz modes “up to 4 Mbps” (Nordic product page).

Why ESB fits a light gun unusually well. It is transmit-on-demand: there is no connection interval, so a report goes the moment it exists. And the ACK payload is a natural return channel: the dongle queues any serial force-feedback bytes from the PC, and they reach the gun in the acknowledgement of its very next report, at most 4.8 ms later, with no extra transmissions. A 32-byte report at 2 Mbps is about 164 µs on air; with ramp-up and the acknowledgement about 0.28 ms per exchange, close to ESP-NOW’s figure.

Its costs: no standard, so both ends are custom firmware; no built-in frequency hopping, so the application must pick and change channels itself; and no pairing beyond agreeing an address, so pairing is also the application’s (Volume 4). The ESB sample in the SDK builds for the nRF52840 DK and nRF54L15 DK.

2.8 Plain Wi-Fi, and Bluetooth Classic

Wi-Fi through the house’s access point (UDP from the gun to a program on the PC) needs software on every host, puts the access point and its power-save behaviour in the path, and gives MiSTer nothing it can use. It is rejected without further numbers.

Bluetooth Classic HID is what the Wii Remote uses. It has the same “PC’s radio” problem as Bluetooth LE HID and its own polling behaviour, and it would bring back the serial port only through the Serial Port Profile, which the hook programs do not speak either. The arduino-pico core offers Classic HID and SerialBT on the Pico W, but OpenFIRE ships its Pico W builds with Bluetooth disabled (-noBT) because of a known TinyUSB conflict (Reference Electronics Vol 2).

2.9 The Links Side by Side

Table 3 — 2.9 The Links Side by Side

	ESP-NOW (ESP32 port)	BLE HID to the PC	BLE + SCI to a dongle	LLPM to a Nordic dongle	ESB to a Nordic dongle
Standard	Espressif proprietary on Wi-Fi frames	Bluetooth SIG, HID over GATT	Bluetooth Core 6.2	Nordic proprietary BLE extension	Nordic proprietary
Receiver	ESP32-S3 dongle	The PC’s Bluetooth	Custom dongle (SCI both ends)	Nordic dongle	Nordic dongle
When a report may go	When the channel is free	Next connection event	Next event	Next event	Immediately
Interval	none	7.5 ms minimum, host decides	375 µs in the spec; 750 µs on nRF54L	1 ms	none
On-air time, 32-byte report	~78 µs at 12 Mbps (+ ACK)	~0.1 to 0.3 ms	similar	~0.1 ms at 2M	~0.16 ms at 2 Mbps (+ ACK)
Return channel for force feedback	Yes (the port’s serial bridge)	No (custom GATT only)	Custom	Custom	Yes, in the ACK payload
Frequency agility	One channel chosen at plug-in	Adaptive hopping	Adaptive hopping	Adaptive hopping	Application’s job
MiSTer / hook programs	Yes, as released	No serial path found	If the dongle presents serial	If the dongle presents serial	If the dongle presents serial
Firmware today	Released (7.0.0 rc5)	Pico W libraries; no OpenFIRE build	Nordic sample	Nordic sample, nRF Desktop	Nordic sample

2.10 Why This, and Why Not the Others

The criteria, in the order of Section 2.1: the same USB devices including serial; latency added well under one camera frame; correct handling of stale and lost data; four guns; and parts that could go in a kit.

Table 4 — 2.10 Why This, and Why Not the Others

Link	Verdict	Why	Why not
ESP-NOW, as in the ESP32 port	The first trial (D25, D30)	The only link with released light-gun firmware on both ends; serial carried; newest-report-wins at the dongle; airtime small at 12 Mbps	Single fixed channel chosen at plug-in; channels 12 and 13 possible (Volume 6); receiver always on; a pre-release firmware
ESB, Nordic dongle	The proposed kit link, to be proven on the bench	Transmit-on-demand, so no interval; the ACK payload is a ready-made force-feedback channel; up to eight transmitters per receiver; tiny radio current	Both ends custom; no hopping or pairing unless written; no light-gun firmware exists
LLPM, Nordic dongle	The alternative to ESB for route B	Standard Bluetooth machinery (hopping, bonding) at 1 ms; nRF Desktop is a near-complete reference including a four-connection dongle	Proprietary to Nordic on both ends; one interval of wait (0 to 1 ms) that ESB does not have
BLE with SCI	Watch, not build yet	A standard route to sub-millisecond intervals	Needs SCI on both ends, so a custom dongle anyway; controller support is new
BLE HID to the PC’s radio	Rejected for the main gun	No dongle	No serial, so no MiSTer light-gun mode and no game-driven recoil; the host picks a 7.5 to 15 ms or longer interval; the PC’s antenna and coexistence are unknown
Wi-Fi to a PC program	Rejected	—	Host software everywhere; access-point latency; nothing for MiSTer
Bluetooth Classic	Rejected	The Wii Remote’s proof that it works	Same host problems as BLE HID; OpenFIRE’s Pico W builds disable Bluetooth

The two survivors are not rivals in time. The ESP32 port answers “is a radio good enough to play on?” this month with nothing written. The Nordic links answer “what should a finished, sold gun use?”, and Volume 3 explains why that answer probably differs.

Sources

1. Espressif, ESP-NOW, ESP-IDF Programming Guide (ESP32-S3, stable) — https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/network/esp_now.html (read 2026-10-19).
2. Alessandro Satanassi, OpenFIRE-Firmware-ESP32, shared_lib/OpenFIRE_Wireless/ESP32/OpenFIRE_Wireless.cpp, dongle/src/main.cpp — https://github.com/alessandro-satanassi/OpenFIRE-Firmware-ESP32 (read 2026-10-19).
3. Bluetooth SIG, Bluetooth Core 6.2 Feature Overview — https://www.bluetooth.com/bluetooth-core-6-2-feature-overview (read 2026-10-19).
4. Mohammad Afaneh, Novel Bits, Bluetooth LE Shorter Connection Intervals: A Hands-On Guide with the nRF54L15, 16 December 2025 — https://novelbits.io/ble-shorter-connection-intervals-hands-on-nrf54l15/ (read 2026-10-19).
5. Nordic Semiconductor, nRF Connect SDK (sdk-nrf, main): samples/bluetooth/llpm/README.rst and sample.yaml; samples/bluetooth/shorter_conn_intervals/; samples/esb/; applications/nrf_desktop/ (README, description, board configuration; v2.9.0 configuration list); ESB protocol documentation — https://github.com/nrfconnect/sdk-nrf and https://nrfconnectdocs.nordicsemi.com/ (read 2026-10-19).
6. Microsoft, BluetoothLEPreferredConnectionParameters Class — https://learn.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.bluetoothlepreferredconnectionparameters (read 2026-10-19).
7. Silicon Labs, Selecting Suitable Connection Parameters for Apple Devices — https://docs.silabs.com/bluetooth/8.3.0/mobile-apps-suitable-connection-parameters (search result; quoted only as secondary).
8. Nordic Semiconductor, nRF54L15 product page — https://www.nordicsemi.com/Products/nRF54L15 (read 2026-10-19).
9. Earle Philhower, arduino-pico documentation, “Bluetooth on the Pico W” — https://arduino-pico.readthedocs.io/en/latest/bluetooth.html (read 2026-10-19).