Current limiting for 120 LEDs via USB?

[Skaytacium]

So me and one of my friends are currently building our own keyboard. You can find it on https://github.com/Skaytacium/Skayboard.

Currently, we are on revision 3 and we recently ran into a problem which we just cannot seem to find the solution to. We need to power 76 per-key RGB SK6812 LEDs and 44 underglow SK6812 LEDs. USB 2.0 only supports 500mA at high power mode and sometimes devices can even switch to low power mode (100mA) if they need to.

Our original plan was to multiplex these LEDs, so we only power one column at a time (~6-7 LEDs per column), but then my friend suggested that we just turn off the LEDs rather than use an external multiplexing IC and add complexity.

This seemed like a good idea at first but after some calculations, I soon realized that we cannot do that as it would effectively make all of the LEDs work at ~12-13Hz.

Then I had an epiphany and thought why not just separate the 120 LEDs into groups of 30, and concurrently send data to that, but well sadly, theoretically if I could do that I would get exponentially good performance per pins, but practically, not many microcontrollers can parallelly output to 4 data pins.

What I really want to know is what companies like Ducky/Razer/Corsair do. Their keyboards might not be the best, but their PCB design has to be pretty good if they are retailing at such a high volume.

Any responses, suggestions, or answers, will be welcomed and appreciated.

[Findecanor]

Mainstream keyboards use LED controller chips that drive RGB LEDs in a matrix. To limit the current, only one logical column is enabled at once. In combination with control of the duration that each logical row is enabled, each LED's intensity can also be controlled individually.

I'd suggest looking at the LED controller chips from ISSI such as the IS31FL3733 IS31FL3743.. The "Input.Club K-Type"/"Drop CTRL" has two IS31FL3733 driving both the backlight and the under/side-glow. They are controlled over I²C. There is support for this and a few other ISSI LED controllers in QMK.

Edit: Useful info from another thread:

IS31FL3733 seems to be going out of production and I believe the IS31FL3743 is the recommended replacement for new designs. Other than that, key differences would be it's using a higher scanning frequency which probably is only significant for the largest of these drivers, it allows for configurable matrix size and promises reduced EMI which is nice I guess.

[Skaytacium]

Hey, thanks for the reply.

So there were some misunderstood concepts in my mind, especially about the persistence of vision, which led me to think that if I am able to multiplex LEDs, then the brightness would remain the same, but alas, I was wrong.

After a lot of calculations, https://www.desmos.com/calculator/0ll3s4aer2 , I was finally tired of thinking about how I would implement a fast and responsive system, but then something clicked into my mind.

I headed on over to this website https://testufo.com/persistence and then finally, something clicked into my mind. When I would change the line thickness option, the brightness of the image would reduce, and the way that these addressable LED ICs control their individual components is by PWM.

After doing some revision on my basic engineering concepts, I finally realized that I am stupid that even if I multiplex it, I won't get the max brightness.

TL;DR: I need to use more power-efficient LEDs!

Edit #1: Updated formulas and worst case refresh rate (f) at https://www.desmos.com/calculator/tn6ieguse1

[typo]

My Great Grand Dad built this board completely custom. It must have an older IC. The LED's I gather are drawing too much current. When the laser printer powers on. It kills the entire controller in the machine! Must reboot! The print job is done. Since it spooled to the printers memory. That is a bummer because this board is my grail.

[Skaytacium]

What?