Porting Logitech Unifying to nRF Connect SDK — why esb_write_payload gets no ACK, and 4 other walls

arsenapple — Fri, 17 Jul 2026 12:32:22 +0000

TL;DR for the person searching at 3 a.m.
If you are sending a raw Logitech Unifying (or LOGITacker-derived) frame from the NCS/Zephyr standard ESB library (subsys/esb) and the receiver never ACKs — ESB_EVENT_TX_SUCCESS never fires, only ESB_EVENT_TX_FAILED — even though the bytes on air are provably correct and the receiver responds fine to LOGITacker sending the identical payload:

The likely cause is the least-significant bit of the S1 field in the DPL (Dynamic Payload Length) PDU header. NCS standard ESB computes it as pdu->type.dpl_pdu.ack = !noack, which puts a 1 on an ACK-requesting transmit. LOGITacker's Unifying-compatible path puts a 0 there. The two stacks encode "I want an ACK" with opposite bit values. Match LOGITacker's raw S1 value and the receiver starts ACKing immediately.

Jump to section 3 for the full trace.

What this project was
I built firmware that makes a Raytac MDBT50Q-CX (nRF52840, USB-C dongle) pair with an off-the-shelf Logitech Unifying receiver as a new Unifying device, so that keyboard/mouse input captured on a Mac can be transmitted to a Windows PC as encrypted Unifying frames — with only the single Unifying receiver on the Windows side (no admin rights, no extra software installed on Windows).

The protocol implementation is derived from LOGITacker (a Unifying/BLE security-research firmware built on the old nRF5 SDK) and ported onto the modern NCS standard ESB library (subsys/esb).

This writeup is for anyone working with the same stack (nRF52840 + NCS + subsys/esb + Logitech Unifying protocol), or debugging a similar class of bug: a bit-level discrepancy between a documented standard stack and a reverse-engineered protocol implementation.

Keywords: nRF52840, Raytac MDBT50Q-CX, nRF Connect SDK, NCS, Zephyr, subsys/esb, Enhanced ShockBurst, ESB, Logitech Unifying, LOGITacker, nrf_esb_illegalmod, DPL Dynamic Payload Length, S1 field, ACK payload, pairing protocol reverse engineering, esb_write_payload noack.

Environment:

Board: raytac_mdbt50q_cx_40_dongle/nrf52840 (present in NCS's Zephyr boards)
SDK: nRF Connect SDK v3.4.0
Radio: NCS standard ESB library, extended from nrf/samples/esb/esb_ptx
Peer: an off-the-shelf Logitech Unifying receiver (real hardware), plus a second nRF52840 dongle flashed with LOGITacker used as a sniffer / forced-pairing observation rig

Prebuilt LOGITacker firmware won't boot on the Raytac dongle Symptom Flashing the official prebuilt LOGITacker hex (pca10059 and mdk_dongle variants) to the Raytac MDBT50Q-CX over USB SDFU (via nRF Connect Programmer) succeeds, but the device never enumerates over USB and the LED never lights. The DFU bootloader itself is healthy — flashing works and re-entering DFU mode works.

Isolation
Rule out the hardware. Zephyr officially supports the same board (raytac_mdbt50q_cx_40_dongle). Building and flashing three Zephyr (main) samples — Blinky, CDC ACM, HID keyboard — all worked (Blinky: LED0 = P0.8 blinking at 1 Hz; CDC ACM: /dev/cu.usbmodem* enumerated; HID keyboard: IOHIDDevice enumerated). So the hardware and bootloader are fine.
Instrument main(). Add a diagnostic that blinks LED0 three times at the very top of LOGITacker's main() before normal init. The three blinks never appeared, and there was no USB enumeration. Since the blink code is polarity-independent and trivially early, this means the code hangs before reaching main().
The UICR hypothesis (and why it was wrong). SystemInit() in modules/nrfx/mdk/system_nrf52840.c has a path that, when CONFIG_GPIO_AS_PINRESET is defined, writes PSELRESET into UICR and resets. I suspected an earlier Zephyr flash had modified UICR and the firmware was stuck in a reset loop. A control experiment killed this hypothesis.
Control experiment (decisive). I flashed the nRF5 SDK's own minimal Blinky sample (examples/peripheral/blinky/pca10059/mbr, built without CONFIG_GPIO_AS_PINRESET). It also failed to boot (LED0 never lit → main unreached). A minimal, LOGITacker-unrelated sample from the SDK itself doesn't start either, so the UICR/PINRESET theory has no legs.
Root cause (unconfirmed, shelved)
The real issue reduces to a broader incompatibility that is not LOGITacker-specific: generic apps built with the old nRF5 SDK (assuming ~2018-era toolchain/startup) don't start in this dongle's Open bootloader environment. I never pinned down exactly where it hangs (startup asm / SystemInit / linker VMA placement). Because Zephyr (and NCS) boot the same board fine, I decided I could route around the mystery instead of solving it, and abandoned the nRF5 SDK port entirely, switching to porting the Unifying transmit logic onto NCS (Zephyr).

Lesson
When "a specific project won't run," first check whether a minimal sample on the same foundation (SDK, toolchain, bootloader assumptions) reproduces the failure. If it does, suspect the foundation before you debug the individual project — it's usually faster.

Don't let the name nrf_esb_illegalmod scare you into over-scoping LOGITacker's ESB implementation file is named nrf_esb_illegalmod.c. The name suggests Unifying communication might require undocumented, non-standard register manipulation, which would make the port a huge job.

What it actually is
A comment in nrf_esb_illegalmod.c states that the "illegal" part refers only to RX-side passive (pseudo-promiscuous) sniffing configuration using undocumented registers. The transmit (PTX) path — the part I actually needed — is completely standard ESB: NRF_ESB_PROTOCOL_ESB_DPL / NRF_ESB_BITRATE_2MBPS / NRF_ESB_CRC_16BIT / NRF_ESB_MODE_PTX / 32-byte payload. The 100+ RADIO-register hacks exist only for sniffing.

Result
The sniffing register hacks don't need to be ported. The PTX path maps 1:1 onto NCS's standard subsys/esb library (esb_init() / esb_set_base_address_0/1() / esb_set_prefixes() / esb_set_rf_channel() / esb_write_payload()). The only genuinely Unifying-specific logic that must be reimplemented is: the channel-hopping table, AES-ECB frame-key derivation + XOR, the HID++ frame construction + checksum, and the known pairing-mode fixed address. Scope shrank dramatically.

Lesson
In reverse-engineering projects, file/function names often reflect history (the research target was sniffing) rather than intent. Don't estimate scope from names — read only the path you actually use.

The main event: a DPL S1 least-significant-bit mismatch between NCS ESB and Unifying/LOGITacker Symptom Sending the Unifying Phase-1 pairing request from NCS subsys/esb, transmission continues but the receiver's ACK is never detected (ESB_EVENT_TX_SUCCESS never fires; only ESB_EVENT_TX_FAILED repeats).

Isolation — narrow to the one remaining variable
I verified packet content, transmission, and the receiver independently, to corner the problem onto the only thing left: my own receive/ACK-detection path.

Packet content. Compared the TX payload (e1 5f 01 de ad be ef 82 08 13 37 04 00 01 05 00 00 00 00 00 00 a9) byte-for-byte against the reference implementation's expected Phase-1 request → exact match. Marker / flags / phase / pseudo device address / keep-alive / WPID / protocol / type / caps / checksum all correct.
Is it actually on air? Flashed a second nRF52840 with LOGITacker and ran pair sniff run (passive sniffing) → detected the identical byte sequence. Transmission is fine.
Is the receiver healthy? Unplugged the device under test (stopping its transmission) and used LOGITacker's pair device run (forced pairing, a complete implementation) to send the exact same bytes to the same real receiver → the receiver responded with RSP1 (E1 1F 01 ...), completed Phase 2 / Phase 3, and reached Device pairing succeeded. The receiver is fine.
Content, transmission, and receiver are all correct → the fault is exclusively in my firmware's ACK/RX-detection path. Since LOGITacker uses low-level RADIO register access (nrf_esb_illegalmod) while NCS uses the abstracted subsys/esb, the TX→RX switch timing was the next suspect.

Tracing the ACK-receive flow on hardware
Compared the ACK-wait sequence in NCS's esb.c and LOGITacker's nrf_esb_illegalmod.c. Both use the base sequence END → DISABLE → DISABLED_RXEN short → RX READY, but NCS routes TX start and the ACK timer through an EGU/PPI/MPSL-FEM compatibility layer.
Added a PPI + TIMER1 diagnostic on the NCS side and observed RADIO->STATE at TX END / TX DISABLED / RX READY / timeout on real hardware (3,824 samples). TX DISABLED state was always RXRU (1); post-RX-READY state was always RX (3). So a missing RXEN or a stalled RX ramp-up is not the cause.
Changed ACK-wait timeout 160 µs → 500 µs, TX power 0 dBm → +8 dBm, and 2 Mbps preamble 16-bit → 8-bit, testing each on hardware. EVENTS_ADDRESS still never asserted in any case — none of these was the root cause (preamble reverted to standard 16-bit).
Root cause
The decisive difference is the least-significant bit of the S1 field in the DPL PDU header.

Implementation S1 LSB on an ACK-requesting transmit
LOGITacker (nrf_esb_illegalmod, Unifying-compatible raw value) 0
NCS standard ESB (subsys/esb, computed as pdu->type.dpl_pdu.ack = !noack) 1
With identical ESB settings (protocol/mode/bitrate/CRC), the S1 LSB corresponding to "request an ACK" (noack=false) was inverted between the two stacks. Temporarily changing NCS's pdu->type.dpl_pdu.ack from !noack to noack (matching LOGITacker's raw S1) produced, for the first time, 187 consecutive ADDRESS / END / CRC radio events, and RSP1 began parsing correctly.

The S1 bit signals whether an ACK is requested in both Enhanced ShockBurst and Unifying — but the polarity of that bit (is 1 "ACK requested" or is 0?) was interpreted differently by NCS standard ESB and the Unifying (LOGITacker-derived) side. This mismatch never surfaces at the API level (the noack argument to esb_write_payload()); it is only visible in the raw bit representation of the generated physical frame.

After the fix
Once RSP1 reception was stable, I ported the existing reference implementation's Phase 2 / Phase 3 / final confirmation / key-derivation logic unchanged, and confirmed Unifying pairing succeeded on hardware. After pairing, the RF address, WPID, and derived AES device key are persisted to NVS and restored on boot to re-establish the link.

Lesson
When porting a proprietary protocol (Unifying) on top of a standard stack (NCS ESB), verify not that your code is semantically equivalent at the API level, but that the raw bytes handed to the radio actually match. The most reliable method was to send an identical payload from both stacks and compare the byte sequences on air (or in RAM). This is a class of bug you cannot reach by reading docs or API signatures — trust the raw output, not the intended meaning.

Test-oracle traps When radio + crypto + firmware + app all interact, mis-defining "did that succeed?" (the test oracle) makes you doubt a correct implementation endlessly. The traps I actually hit:

4-1. An RF ACK does not prove "a character appeared on screen"
Link-layer ACKs for encrypted key reports came back fine while Windows showed nothing. An ACK guarantees the packet arrived over the air; it does not guarantee the receiver's HID interpretation or OS acceptance. Sending hello one character per second displayed correctly, but a 20 ms-interval burst stopped at hel. The cause was not crypto or pairing but the time spent hopping to find the channel the receiver is currently listening on (see 4-3-adjacent tuning below).

4-2. Logi Options+ saying "device not found" does not mean pairing failed
The macOS pairing helper (Logi Options+) sometimes ended its add-device flow with "device not found," yet the firmware logs showed all phases completing and encrypted traffic working. The Options+ UI is only a coarse indicator — it keeps searching while it detects pairing-class traffic and ends when it detects nothing — and cannot be used to judge success/failure of a custom device. Use the firmware serial log (phase completion, key derivation) and actual encrypted traffic as ground truth. Also note Options+ exposed no operation to remove an existing device (don't hand out UI steps that assume one exists).

4-3. Clearing persistent data: delete vs clear
After changing the pairing-record storage format, boot failed to load (Link storage load failed: -5) and never reached radio pairing. A single-record nvs_delete() left a mix of old/new-format remnants and did not fix it; a full nvs_clear() did. Even then, the same firmware sometimes still received no ACK/RSP1 — resolved by physically unplugging/replugging the receiver and restarting the Options+ search from scratch. With byte-identical firmware and payload, the receiver's transient internal state (e.g., a previous search session not internally closed) can matter.

4-4. Don't re-present a previously-solved path as a "new root cause"
I nearly attributed the current failure to a plausible-looking code diff ("we discard the ACK payload on the initial request"), but history showed the known-good implementation did the same thing. For recurring hardware failures, before proposing a new hypothesis, A/B test the known-good binary against the current implementation under identical persistent state and identical physical topology — it avoids mistaking an unrelated diff for a new cause.

Data-driven tuning: reordering channel search cut latency by 3×+ Unifying's communication channel table has 25 entries; the transmitter doesn't know which channel the receiver is currently listening on, so it hops through candidates until an ACK returns. Initially I searched in ascending order, but aggregating real logs showed the receiver alternating between two specific channels (44 and 35).

Keeping all channels but placing those two at the front of the search order, measured on a 36-character input test:

Metric Before (ascending) After (44/35 first)
Total time (36 chars) 2,861 ms 856 ms
Avg attempts/char 15.44 1.50
Max attempts/char 38 2
Success – 72/72 reports
Reordering the search from the measured frequency distribution — not a guess — improved responsiveness by more than 3× while keeping the inter-character delay at 0 ms.

Summary table

Symptom Wrong / over-scoped hypothesis Actual cause Fix

1 Prebuilt LOGITacker won't boot Bad hardware; LOGITacker-specific bug nRF5-SDK generic apps don't start in this bootloader env (root cause unconfirmed, shelved) Switch the whole port to NCS (Zephyr)
2 The name illegalmod All Unifying comms need special register hacks Only the sniffing code does; TX is standard ESB Port the PTX path onto standard subsys/esb
3 No ACK from NCS standard ESB Channel / timing / TX-power problem DPL S1 LSB polarity inverted between NCS and Unifying Force the S1-bit computation to Unifying's convention
4 Mis-judging "success" Over-trusting RF ACK / Options+ UI / NVS ops Each signal guarantees only a narrow thing Use firmware logs and A/B tests as ground truth
5 Channel search too slow Adding delay will stabilize it Search order didn't match real receiver behavior Prioritize channels by measured frequency
References
LOGITacker (RoganDawes) — Unifying/BLE security-research firmware; the source of the protocol implementation referenced here.
nRF Connect SDK subsys/esb (Zephyr's standard Enhanced ShockBurst library).
DEF CON 24 "Unifying" / MouseJack materials (independent description of the 10-byte Unifying mouse frame layout).

DEV Community: arsenapple

Porting Logitech Unifying to nRF Connect SDK — why esb_write_payload gets no ACK, and 4 other walls

Symptom Wrong / over-scoped hypothesis Actual cause Fix