Questions regarding underglow on a Rev2 Zeal60 PCB

[FailureToLoad]

Hey Geekhack,

I recently built my first keyboard using a Rev2 Zeal60 RGB LED PCB I got from the recent MassDrop offering. Everything went well and the process from start to finish has gotten me pretty hooked on this hobby.

I started running into some issues when I attempted to add underglow via an led strip. I eventually got it working but made the mistake of changing two different things between two troubleshooting attempts, so now I have questions. Below is the guide I originally referenced as well as the components I used.

• Tusing's Zeal60 underglow guide
  
• ALITOVE WS2812B 60/m LED strip
  
• Elenco Solid Hook-Up Wire
  

I should note at this point, I did all my firmware through QMK's master branch using the Zeal60 keyboard folder from Wilba6582's fork. I wanted to learn QMK as part of this, but still wanted to at least stay in the spirit of using the software Zeal recommended.

Tusing's original wiring setup suggested connecting the strip's 5v pad to the F1 thermistor. Baethus' plank underglow guide, which is referenced in the QMK documentation, recommends going off the VCC pinout.
Considering Tusing recommends increasing the maximum power consumption to 900, is their approach trying to access a more stable power source for that level of power or will the VCC pinout still be able to service the LED strip without issue?

That question is part of why I connected to the VCC pinout instead of the thermistor. When I followed Tusing's guide to the letter, I found that QMK threw a wraparound errror when I tried to make the hex file. Digging into the source code, it looks like this is due to the consumer of USB_MAX_POWER_CONSUMPTION, MaxPowerConsumption, being a uint_8 variable. I mainly work with OO languages, but if I remember right that's basically an unsigned char which should only have values between 0-255. I haven't debugged deep enough to see if there's any magic happening to defeat that limitation. If this were purely software, I'd have no qualms changing from an 8 to 16 bit value to see what happens. Considering there's hardware I've put time, care, and money into connected to this, I'm very hesitant to make this change without being better informed. All things considered, I haven't even really added the two other strips I intend to use on the current configuration to see if a deeper dive is even needed or if the brightness is fine as is. Can anyone more experienced than myself weigh in?

My intention is to do an updated write up that details, start to finish, everything involved in this mod. I want to spell out everything so anyone new to the hobby, like myself, can not only have a guide to follow but also be presented with factors to consider before taking on a mod like this.

edit - Still haven't found any answers yet. I've posted to the google group for the LUFA usb drivers to get more info around the safety of changing the variable. Beyond that, I'm also rewiring my LEDs tonight to see if there's a noticeable change in brightness by using the F1 thermistor over the VCC pinout.

[FailureToLoad]

Hey there folks!

I know not many people were interested in this topic, but I got a reply from the author of the LUFA drivers about power tolerances.

Much of this might have been my own misunderstanding as to how the values were being treated within the drivers, but in the event anyone else comes looking for this information I wanted to post a clear record of what I've found.

The USB device descriptors are binary tables which are serialised from the device to the host, so that the host can interrogate the device and determine the functionality that it supports. Because of that, the descriptor field structures are all fixed and can't be changed -- you can only change the values listed inside the fields, rather than the fields themselves (or the host PC won't be able to read them correctly).

The USB 2.0 specification lists that the max power consumption field is given in multiples of 2mA, so a value of 10 means 20mA maximum power consumption. The largest legal value for that field is 250 (500mA) for USB 2.0, which is why the USB-IF decided that it should be an 8-bit value.

For USB 3.0, they decided that the field would be specified in 8mA units, with a maximum value of 112, or perhaps 113 (actual limit is 900mA, not sure if they round up or down) which again still fits into 8-bit fields for backwards compatibility. Note that this enhanced power draw is *only* available when in SuperSpeed mode, and not the Low, Full and High speed modes of USB 2.0. The 8-bit USB AVRs can only achieve Full Speed at best, but either way I don't believe you can get access to USB 3.0's enhanced power supply draw without swapping to a different architecture with the multi-gigabit USB speeds.

Cheers!

- Dean