While looking at some LED facemask projects online, I came across a neat new flexible RGB LED matrix with BLE connectivity. It has 32×16 RGB pixels but the mobile app it uses will only send full-on primary color combinations, i.e. it’s not full color. Cost is ~$40.
- Markings: [HC89F0541 | 2011 | A7616511]. Qty: 1. Holychip 8051 MCU, Link.
- Markings: [SM16206S | BZBCNNAC17]. Qty: 6. Sunmoon 16 channel constant-current LED sink driver, Link.
- Markings: [D7258 | 2009CF]. Qty: 2. Double Microelectronics 8 channel LED source driver, Link.
- 2mm x 2mm RGB LED. Qty: 512.
4 wires go from the BLE/battery pack labeled VCC, TXD1, RXD1 and GND. I used my Saleae Logic16 to see what the TXD/RXD waveforms looked like, focusing on length of data bit periods. You can view the below logic traces in Logic2:
To save time I used a web calculator to convert from period to frequency. Seeing a falling edge before every packet and bit periods of 28µs -> 35714Hz I figured we had a UART at ~38400 baud. Setting an Async serial analyzer in Logic2 showed what looks to be meaningful data. I exported the incoming data (in hex):
RXD, however, is another story. The shortest bit period on RXD is 101µs, with others being 202µs and packetized with a ~5ms preamble of zeroes. Assigning an Async analyzer at 101µs -> 9900Hz -> ~9600 baud yielded garbage (framing errors everywhere). 10K baud also yielded nothing. Given this is a product in the LED space, I assigned a WS2812B analyzer in Logic2 but that also produced nothing useful. Weird, I’ll have to look closer.
There are (32 x 16 x 3) = 1536 LED die on the display. Since this display only drives each die fully ON or OFF, we should be able to represent each die with a single bit. I expect the display data for a single frame will then be (1536/8) = 192 bytes.
I entered enough text to cover 3 full frames, so I expect to see (192*3) = 576 bytes go by, ignoring protocol overhead.
TO BE CONTINUED… Feel free to drop any insight into the comments!