# What if a dead TWS earbud could become a Bluetooth data module?
I had a cheap/dead TWS earbud and started wondering whether the Bluetooth receiver inside it could be reused for something completely different.
Instead of using the TWS for normal audio, I used its analog speaker output as a data channel.
The idea is:
Phone / PC
β
Bluetooth A2DP
β
TWS Bluetooth receiver
β
Analog speaker output
β
MCU ADC
β
Goertzel frequency detection
β
Ternary FSK
β
Packet + CRC
β
Digital data
## The hardware
The first reference receiver is an ESP32.
The TWS speaker output is BTL/differential, so the second speaker terminal is not connected to MCU ground.
The tested connection is:
TWS SPK1 β ESP32 GPIO34
GPIO34 β 10kΞ© β GND
TWS GND β ESP32 GND
The receiver samples the analog waveform and detects three frequencies:
700 Hz = symbol 0
1100 Hz = symbol 1
1700 Hz = symbol 2
## The interesting part: the sampling rate was not what I expected
I initially designed the decoder around an 8 kHz sampling rate.
After measuring the actual ESP32 ADC loop, the real sampling rate was approximately 5.8 kHz.
Once the real sampling rate was taken into account, the three frequencies could be separated reliably.
## From three tones to actual data
At first, each frequency represented a command.
That was too limiting.
So I turned the three frequencies into a ternary alphabet and built a packet format containing:
- preamble/synchronization
- length
- payload
- CRC-8
- end marker
This allowed the same modem to carry messages such as:
HELLO
PING
STATUS?
RELAY=1
MOTOR=120
## GGWave experiment
I also tested GGWave through the same Bluetooth/TWS path.
GGWave could partially synchronize to some frames, but complete payload decoding was not reliable on this particular TWS/audio channel.
Rather than forcing a more complicated modulation scheme through a bad channel, I built a sparse custom 3-tone FSK modem that better matched the behavior of the TWS.
## Another surprising discovery
Repeatedly opening and closing Bluetooth audio streams caused intermittent decoding problems.
Keeping one persistent A2DP audio stream open greatly improved the reliability of the physical channel.
This ended up being as important as the DSP itself.
## Results
The current tested system achieved:
- ~99.4% steady-state detection of a continuous 1700 Hz signal after Bluetooth startup
- 4/4 successful controlled packet transfers
- >95% packet success during the larger integration test
- approximately 3.2β4.5 bit/s effective payload rate
The modem is intentionally slow. It is designed for small commands and data, not high-speed communication.
## Why build this?
The interesting part is not trying to compete with Bluetooth SPP.
The interesting part is reusing hardware that would normally be thrown away:
Bluetooth A2DP receiver
β analog audio
β MCU ADC
β custom data modem
The receiving MCU does not need to contain a Bluetooth radio.
## Next step
The next experiment is to connect the modem to a genuinely Bluetooth-less MCU such as the CH32V003 and use the TWS purely as the wireless receiver.
The full source code, protocol documentation, hardware notes and experiments are available here:












Comments