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.<\/p>\n\n\n\n
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<\/a>:<\/p>\n\n\n\n To save time I used a web calculator<\/a> to convert from period to frequency. Seeing a falling edge before every packet and bit periods of 28\u00b5s -> 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):<\/p>\n\n\n\n RXD, however, is another story. The shortest bit period on RXD is 101\u00b5s, with others being 202\u00b5s and packetized with a ~5ms preamble of zeroes. Assigning an Async analyzer at 101\u00b5s -> 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n I entered enough text to cover 3 full frames, so I expect to see (192*3) = 576 bytes go by, ignoring protocol overhead.<\/p>\n\n\n\n TO BE CONTINUED… Feel free to drop any insight into the comments!<\/p>\n\n\n\nGallery<\/h2>\n\n\n\n