How to use Codex to replace a headset dongle
Codex helped replace a failed headset receiver with two ESP32-S3 boards. Packet captures, human soldering and listening checks shaped the experimental firmware.
Original prompt
Shared by the source author. See source notes for context.
could we make our own dongle?
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Rbanh15
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- The author reports PC audio and a microphone through the replacement receiver. The experimental two-board design needs original pairing data and was tested only with the author's headset.
- Human involvement
- The author supplied hardware, captured original receiver data, soldered and flashed boards and listened to distinguish useful audio from noise.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- The author captured packets, firmware and pairing data from the still-usable receiver.
- Codex analyzed the protocol and iterated firmware while the human flashed and listened.
- The design split radio/USB and codec work across two ESP32-S3 boards.
Rbanh15 used Codex to replace a failing receiver for a Razer Blackshark V2 headset. The original headset still worked, but its proprietary wireless connection depended on a dongle the manufacturer would not replace or sell separately.
The project began while that receiver remained usable. The author captured packets and obtained its firmware and pairing data. Codex handled most protocol analysis and firmware development, while the human supplied hardware, soldered connections, flashed boards and listened to each revision for audio or noise.
A single ESP32-S3 could not fit codec processing, USB work and radio scheduling into its timing budget. The final stack split responsibilities across two boards: one handled USB and radio, while the other encoded playback and decoded microphone audio over SPI. The Linux computer saw ordinary stereo output, a mono microphone and headset controls.
The author reports hearing a test melody and then actual PC audio through the replacement, using the headset's original wireless protocol rather than Bluetooth hands-free mode. Build instructions were published, but the project remained experimental, required the user's existing pairing data and had only been tested with this headset. Physical assembly and listening checks were essential parts of the result.
Prompt
Original prompt
Source: Reddit · Rbanh15
Frequently asked questions
Why did the design need two boards?
Codec work, USB and radio scheduling exceeded one board's timing budget.
What did the human verify?
The author listened to revisions to distinguish audio from noise.
Will it work with every headset?
No. It needs existing pairing data and was tested only with the author's model.
More details
About this account
The author captured packets, firmware and pairing data from the still-usable receiver. Codex analyzed the protocol and iterated firmware while the human flashed and listened.
Primary author post opened. Source/build instructions linked. Experimental receiver requires existing pairing data and was tested only with the author's headset; compatibility with other models is not established. Original prompt excerpt.
Credit: Rbanh15 — Reddit
Source published
Added to Agents In Use
Source checked
Tools and topics
Codex · ESP32-S3 · SPI · Linux
Hardware repair · Protocol analysis
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.