RGB power consumption
Obviously you should always build you Lotus the way you want it, and if you want more RGB, that's the way you should build it. But it's a good thing to know why it's not the recommended way, and why I will not build a Lotus to a customer with both soldered in place and active at the same time if ordered through my build service.
This is why the newest versions of the PCB selects either Glow or Per-Key RGB with a switch.
Most DIY builds like the Lotus, split or otherwise, use a Pro Micro controller footprint. The classic Pro Micro uses an Atmel Atmega32u4 MCU, that has an USB 2.0 interface.
Upgrading it to a rp2040 based pin compatible controller like the Frood, Adafruits KB2040, or any other similar, it in-fact has an USB 1.1 interface instead, so a slight 'downgrade' in max supported speed, or actually bandwidth, which is the relevant change.
As for actually used data transfer speeds, this is completely irrelevant, as no keyboard will ever need all the bandwidth USB 1.1 offers, and in no way will a keyboard ever need or be able to use a USB 3.0 or faster connection, even if some keyboards commercial do use that standard today (They still use a slower/lower bandwidth connection, even if they use the newer protocol).
The USB Specification (applied to power limits) in its simplest form means a USB device can negotiate it's required of power from the host in 100 mAh steps, and at handshake the host will never deliver more than 100 mAh. The port is then physically protected by a resettable fuse, that protects the PC from damage from a faulty device drawing too much power because of a short or other physical damage.
That fuse is tripped if too much power is drawn, and the computer needs to be rebooted to reset it.
- Max 500 mAh
- Fused at nominally 500 mAh (500 + 10%, meaning 550 mAh) in reality somewhere 550-750 mAh
- Easily accessible for DIY
- Max 900 mAh
- Fused at nominally 900 mAh (990 mAh) in reality most commonly 1000 mAh
- Expensive and complicated to implement for DIY
This means that regardless of what the specification says, that specific port can deliver as much power as the fuse is rated for. Meaning that it is entirely possible to draw more than 500 mAh from a USB 2.0 port, possibly up to 750 mAh without any issue. But it also mean you should not expect to be able to do so, as the spec limits power at 500 mAh. Laptops are commonly known for following the spec more strictly and having a fuse at 550-600 mAh or so, while larger desktops with lots of ports commonly share a (larger) fuse over more than one port, and can be a bit more forgiving.
The initial 100 mAh is literally supposed to be enough to start up the MCU and negotiate the actual needed power and the speeds for the communication etc. And in the example of the Lotus 58, using two classic Pro Micro, each Atmega32u4 uses roughly 15-20mAh of power, and any additional OLED's and such keep it well within that range, usually at less than 50 mAh at all times. That leaves 450 mAh of those 500 mAh to power the RGB.
So what happens if you solder on enough RGB LED's to consume more than those 450 mAh? Well, the fuse trips. Meaning you need to restart your computer. And once you do, and plug the keyboard in again, the cycle repeats. Indefinitely.
Each RGB LED is 'smart' containing a small ship that communicates over the single data line. That means that even if totally switched of and black, it draws some power. The SK6812 mini/mini-e used on Lotus 58 has a typical power consumption of ~1-2 mA at idle, and at max brightness, they are specified to consume 12 mA, but in reality at full white, they usually consume closer to 14 mA per RGB. (This seems to roughly equate to 2 mA + 12 mA / % of brightness).
An since they cannot be 'switched' off, needing that power to be able to listen to the command to be turned on or lit up, they simply consume that power by being soldered onto the PCB. And they try to consume that power the instant you plug that USB cable in.
- Power consumption at idle: 24 mA
- Theoretical max consumption: 148 mA
- Power consumption at 25% brightness: 60 mA
- Power consumption at 50% brightness: 96 mA
- Power consumption at 75% brightness: 132 mA
- Power consumption at 100% brightness: 168 mA
- Power consumption at idle: 116 mA
- Theoretical max consumption: 696 mA
- Power consumption at 25% brightness: 290 mA
- Power consumption at 50% brightness: 464 mA
- Power consumption at 75% brightness: 680 mA
- Power consumption at 100% brightness: 812 mA
- Actual 'safe' brightness value in QMK: 120
- Power consumption at idle: 140 mA
- Theoretical max consumption: 840 mA
- Power consumption at 25% brightness: 350 mA
- Power consumption at 50% brightness: 560 mA
- Power consumption at 75% brightness: 770 mA
- Power consumption at 100% brightness: 980 mA
- Actual 'safe' brightness value in QMK: 90
Notice how almost all the numbers for combined Glow and Per-Key RGB are above that 450 mAh threshold, and is very likely to overpower the fuse, and making the keyboard unusable? Even just at 25% it's getting close to the limit, and the actual usable value in QMK is quite low.
And while the expected 'safe' value for just Per-Key is also low, it's at least real world usable.
The potential max for all scenarios are however ridiculous. Not only would you likely damage your retinas trying to look at your keyboard, and possibly melt the PCB traces to supply that power.
Sure, it's entirely possible to put a line of code in there to limit the max brightness, keeping that 'safe' value lower. But QMK can't do anything about the power needed to simply light the RGB's up at a dim glow.
And limiting the max brightness in software also changes the dynamic brightness, making the adjustment you have a lot less effective, meaning you are stuck with dim and dimmer, not really useful brightness's.
Or simply using a version that can select one at the time.