deskthority

Hello DeskThority,

Preamble: First Post, Woot!
Have been reading through your forums for a little while now and decided to jump in as you seem to be a well versed community.
I'm hoping you could help me get back into the maker space, I last built an arduino hat back in 2015 so I'm a little rusty and there is so much content on this topic, most I've read is a little dated, looking for latest advice.

Question: I'm looking to construct a custom Ergodox (handwired) with individually controllable RGB LED backlights. YES, I do appreciate how much wiring and soldering is involved, not stepping back!
I need to find out:
1) Can I control all of this off of one board per half? i.e. all switches and all RGB LED's off of one Teensy 3.6 for eg?
2) Which board do people recommend for something like this?
3) Is there firmware that supports this already?

Hey, nice de-lurk. Welcome in! My knowledge is a little dated (had a couple of years off soldering, myself) but as I understand it:

No, not enough pins. You need two independent matrices don’t you? One matrix for all the switches and a second for the individually addressable LED. Indeed, as far as I grasp it, you may well need whole matrices for *each* colour channel of those LEDs! Four matrices? (More on that in a bit.)

A matrix is a 2D grid driven by pins for rows and columns. Just like a spreadsheet. The Teensy 3.6 (new to me!) has a lot of pins, but they’re still very much a finite resource:



I forget how many keys an ergodox has. Let’s say it’s a 6x16 matrix for the sake of argument. That means the switch sensing alone takes 6+16 pins. Then there’s the two body problem: the wiring that must go between halves. For those simplified numbers, all 6 rows and half of the 16 columns would have to cross the bridge to the other hand. 6+8 lines of connection. Before you even get to LEDs. And before you get to RGB! See how much work we’re talking about?

Now, about RGB lighting. On second thoughts, I think you could get away with less than 3 independent matrices. Instead, you could maybe (so goes my hunch) combine one axis of those three addresses as a ground, and use the other axis to access the individual R, G and B layers. Think of it as colour multiplexing, but it could all be strobed at the same time, hopefully.

Still needs an enormous amount of resources, mind. For the 6+16 matrix example, reusing the 16 axis and multiplying the 6, you would need 16 + (6*3) = 34 pins to drive those RGB LEDs. Add the 14 switch pins and the total is 48 pins. Plus an enormous amount of routing between bodies.

Doesn’t sound as bad as I expected, to be honest. And could even be less with a real ergodox layout instead of my guesswork. But here’s the kicker: you’d need software to drive it. TMK is where I’d point you, but I’ve no idea if Hasu is driving LEDs. How are you at code yourself?

https://github.com/tmk/tmk_keyboard

Good luck!

@Muirium, thanks for your reply. The intention is to have one teensy (or equivalent) in each half to help mitigate the issue you've mentioned of having to connect each matrix column and row to the other half.
I don't know if you can connect the boards together directly otherwise i'll just have to have them operate as two separate keyboards, the main concern was being able to only need one controller board per half.
I code just enough to get by so customising the firmware doesn't scare me, I want to know if something already exists that I can use that will run off of one controller that controls both the switches and rgb?

I will continue to research, open to any other comments.

My electronics knowledge is severely lacking, but I think one can always use the so-called "IO expanders" to trade speed (Hz) for more pins. For example, how Wez does it here (see the right half of the picture):



2 pins -> 16 columns

(if you read the linked article, you'll also find the code on Github, based on the QMK firmware IIRC).

The ErgoDox design contains a I/O expander in the left half but only for scanning the matrix in that half. The right matrix is scanned by the MCU. Each matrix is 7×6.
BTW, Here is a guide on matrix scanning, including various ways of replacing pins using extra chips. Similar techniques could be used for LED matrices as well.
Just don't use Charlieplexing for input scanning: you would lose rollover.

Almost all RGB LEDs used in keyboards are surface-mounted, so you might want to use a PCB anyway. The exception is some Kailh/Razer switches that can fit 4-pin RGB LEDs with through-hole pins in a row. Through-hole LEDs with four pins in a square don't fit in any switch. The "RGB switches" tend to now have a small gap for the LED to fit and then a transparent "lens" above: so that a SMD LED can fit, but a 4-pin RGB LED does not. Earlier "RGB switches" did not have a gap and they fit only very shallow LEDs or LEDs on a separate board underneath.
These days, custom PCBs are not always that expensive: there are companies out there that cater to electronics enthusiasts although most of them are best for smaller sizes than keyboards.
The original ErgoDox PCB is reversible, using the same design for left and right halves with only the components being different — and doing that could help you save money.

I believe commercial keyboards with RGB backlighting tend to use dedicated LED driver chips for the LEDs, controlled by the microcontroller over I²C or SPI.
There is a schema for a RGB-backlit ErgoDox that does so but I don't know if it is actually finished and if anyone has actually got that design printed and built.
Enthusiast-made/DIY keyboards with RGB "sideglow" (near the bottom edge) use addressable RGB LEDs controlled with only two pins on the MCU.
Recently, I read about the new APA-102-2020 LED, which is such a RGB LED small enough to fit under a "RGB switch".

If you do want to drive the matrix with the MCU's pins anyway or just want to learn more, there are many Arduino-based LED matrix projects on the web that you can get read about. I also don't think that you would need three separate matrices: only to triple the rows.

Be also mindful of the power consumption of the LEDs. The USB standard supports only up to 500 mA over the wire and when you have 101+ keys and three LEDs per key, it adds up. This is why LEDs are almost never connected with direct wiring but controlled using PWM and/or LED matrices in the first place.
And BTW, when the USB bus in standby mode, the keyboard should lower its power usage to a minimum.

Safe to say Fin knows more about the ergodox than me! Sounds like you could be onto something. Won’t be effortless, but may well be possible.

Due to my design, it will be curved (inspired somewhat by the dactyl) so I don't see a way to realistically make a PCB for it, hence the hand wiring. I already have some Gateron Switches from ages ago that I never used which I'm going to use for this project. Fortunately they already have the holes for inline through hole RGB LEDs.
Thank you for your info, I'll do some more research based on what you've said.

If you wan to drive the leds using a matrix then STP08CP05 is a good option. it is an 8 bit shift register for LED panel displays. You can use it for columns on one side (both LED driving and matrix scanning). Controlling the shift register will take 3 or 4 pins plus pins for:

• matrix scanning (6 pins directly or 2 pins with shift register)
• RGB led driving (3*6 pins); it may be useful to use 3 shift registers maybe driven by SPI hardware here (3*2 + 1 pins)

If you use shift registers then you probably will be able to share CLK lines (i.e. minus 3 pins).
That is from 9 to 28 pins for both matrix scanning and led driving on one side depending on the option you select.