u/Ishant1519

Dead TWS earbuds still have a working Bluetooth receiver + amp — only the battery, buttons, or mic usually fail. So I tapped the analog speaker output and built a 3-tone FSK modem to send data over it.

Signal path:

Phone/PC → Bluetooth A2DP → TWS earbud → analog speaker out → MCU ADC → Goertzel FSK demod → packet + CRC

Key details: TWS output is BTL/differential — do NOT ground the second speaker terminal, it'll short the amp (as did) .

ADC sample rate assumption (8kHz) was wrong. Measured actual rate was 5.8kHz. 3 sparse tones (700/1100/1700 Hz) survive the earbud's bad frequency response better than GGWave's multi-tone scheme, which failed to decode payloads reliably on this path. Built a small packet protocol: preamble, length, payload, CRC-8, end marker. Keeping the A2DP stream open, instead of closing/reopening it, fixed intermittent decode failures.

Results: 95%+ packet success in integration testing. 4/4 packets decoded clean with valid CRC in controlled tests.

~3.2–4.5 bit/s effective payload rate. Not competitive with SPP or a real wireless modem — that's not the point. The point is turning e-waste into a $0 Bluetooth-to-MCU bridge.

Next: testing this with a Bluetooth-less MCU (CH32V003) as the actual receiver. Source: https://github.com/Ishu1519/TWS-A2DP-Mode

Curious if anyone's got a better modulation scheme that survives A2DP codec distortion at a higher bitrate.

I wanted a cheap way to program the CH32V003 without buying a dedicated programmer, so I tried building one around an ESP32-S3. The existing implementations I tried didn't work reliably for my setup, so I ended up reverse-engineering the single-wire SWIO protocol.

I found issues around bit ordering and timing in the implementations I was working from, then reproduced the protocol on the ESP32-S3 and got the CH32V003 programming flow working.

I wrote up the full reverse-engineering process, timing measurements, and implementation details here:

GitHub: https://github.com/Ishu1519/esp32s3-ch32-programmer

Hackster: https://www.hackster.io/ishantj1519/esp32-s3-ch32v003-swio-programmer-d6d3c7

I'd be interested in feedback from people who have worked with the CH32V003 SWIO/SDI interface or have tried other low-cost programmers.

I built an ESP32-S3 based programmer for the WCH CH32V003.

The ESP32-S3 is doing the SWIO communication itself through GPIO10, then using the CH32 debug/DMI interface to detect the target, access memory and program the flash.

Architecture:

PC

↓ USB/UART

ESP32-S3

↓ GPIO10 / SWIO

CH32V003

↓

Flash / application

What is working on real hardware:

- SWIO synchronization

- DMI communication

- CH32V003 detection

- target memory read

- flash unlock

- 64-byte page erase

- flash programming

- read-back verification

- arbitrary binary programming

- reset/run

- Python host flashing tool

One of the useful debugging failures was getting:

DMCFGR = 0xFFFFFFFF

before I had the SWIO startup/timing and physical setup working correctly.

Later I had the opposite kind of problem: programming and verification were working, and the CH32 was actually running, but my motor application did not move. The CP6208 had its second input HIGH instead of LOW. Grounding it fixed the motor.

The final end-to-end test is:

python tools/flash_tool.py --port COM10 --bin firmware/ch32_blink/blink.bin --addr 0x08000000 --reset

Result:

Target detect: OK

Programming: OK

Verification: OK

Reset/run: OK

The programmed CH32V003 then drives a CP6208 and the motor runs.

I used existing open-source CH32/SWIO implementations as references, including CNLohr/ch32v003fun and BlueSyncLine's SWIO implementation. The repository contains the source, hardware documentation and Python host tool:

https://github.com/Ishu1519/esp32s3-ch32-programmer

I'm interested in how portable the approach is to other ESP32 variants and other SWIO-based CH32V00x parts.