LogitechG Keyboard RGB Display Wall  - Page 1
Forum section: electronics / general

author: mariush
author_rank: Super Contributor
timestamp: April 26, 2016, 07:25:39 am
content: Have a look at this RGB wall made out of Logitech keyboards 10 keyboards per row, 16 rows of keyboards ... 160 keyboards in total for 18400 rgb leds.Luke (the guy speaking in the video) says Logitech had to write their own custom software and that each keyboard actually has some sort of converter in the back to show up as an unique IP .. so i guess there's some microcontroller retrieving data from some http or udp stream 30 times a second?How would you do this ?I was thinking ... 2 bytes per rgb led (5:6:5 or something like that) , 115 "pixels" per keyboard means we have 230 bytes, plus something for header (for example send the id of the keyboard for which the 230 bytes is meant for, so that the other keyboards would ignore the chunk of data) would be something like 240 bytes and 30 times a second that's 7200 bytes a second. Fairly easy to hack something up that would receive 240 bytes 30 times a second, covert those 240 bytes into the usb packets the keyboard expects to receive and flip all those leds when a sync signal or something like that is received (so that all 160 keyboards change the leds at the same time).There's <2$ microcontrollers with USB built in which takes care of the communication with the keyboard and they'd have the processing power to convert those 240 bytes into the packets needed for us in less than 33 ms, now all that's needed is some way to receive the data and synchronize all keyboards.I think it's more data than rs-485 or rs-232 / uart whatever could handle unless the panel would be split in small sections but is it really that big amount of data that each keyboard would need to resort to ethernet and having IP to retrieve their own data from a central server 30 times a second?Let's say we split the 10x16 panel into 16 tiny 10x1 panels and then we'd have about 10 x 240 bytes x 30 fps = 72,000 bytes per second or 576,000 bits per second for each section... and then you'd need to make the software on the video player server split the image into 16 chunks and send the data in parallel to 16 devices connected to computer which then further split the data to send to the 10 keyboards...

author: rstofer
author_rank: Super Contributor
timestamp: April 26, 2016, 07:49:14 pm
content: I wonder how they synchronize the keyboards. Shoveling the data around doesn't seem like much of a deal but getting the LEDs to light at the right time (synchronized) seems like a stumbling block. Maybe they use a broadcast packet to say 'change now!'. There are a lot of micros with ethernet ports. Just get a really big switch and you're good to go.Pretty neat - if you have access to a dumpster load of lighted keyboards.

author: hans
author_rank: Super Contributor
timestamp: April 26, 2016, 09:01:43 pm
content: I saw this video too today and thought; probably some very custom electronics & software, where only the mechanical 'keyboard' is the same. Doesn't matter though, it's a pretty cool thing to behold.Standard keyboard = 104 keysx 16-bit RGB = 208 bytes160 keyboards30fps-> roughly 1MB/s data rateLittle need for header for USB or ethernet protocols. You could just send new frame data and use a frame sync packet to latch the data to the display.160 devices could go over 2 separate USB hosts (which is present on most PCs anyway), but probably not deterministic enough for frame sync.A simple UDP protocol that transmits 1 multicast/broadcast packet as a frame synchronization is easier. However, UDP is not exactly high QoS, so it could even be a mix of UDP and TCP.Makes me wonder though, why it couldn't be done at 60fps. Because after all, that is what the wholePCMR reddit(and thus most PC fanatics) is all about.