Stalled Iris 16 - RGB Vandal Button

[iFreilicht]

This project has been stalled, I will not continue working on it!

Basic concept:
The idea is to have a 16mm vandal button like this:

But with 12 RGB LEDs inside that can be controlled via USB. The button would be connected to a USB2.0 header on the mainboard. Secondary features are that it doesn't need soldering and that the cables exit towards the side. It will also have an input for the HDD LED and you could use it as a reset switch as well.

Try out the online Visualizer 0.2 here!


Uses:

Possible uses for these LEDs would be customisable ring colour, a ring loading animation whenever there's HDD activity, multiple segments lighting up the more controllers are connected (like the Xbox 360 did), a simple clock, a breathing LED animation when the PC is sleeping, rainbow colour gradient animations, you name it.

Ideas:

What would extend the possible uses is if one could also read the button via USB, so if you installed multiple switches they could open a program, disable WiFi or whatever. Another idea is to allow the HDD-LED input to be used as an output for other LEDs, so if you installed the switch alongside an existing front-panel, you could control one of its LEDs as well.

 

[iFreilicht]

Current status:

2017-06-16: First and most important Prototype parts arrived!



2017-03-24: "Bleeding Edge Edition" Sign-Up!

Well, here it is: https://******/forms/Jdq6ZzC8VFhPTaoJ3

Details inside. Quantity limited to 16. The winners will be picked manually at my discretion, not randomly. If you've got any more questions, ask away!

2017-03-16: Please vote for the product name!

I've narrowed it down to three final candidates. One Latin word followed by the number 16 to denominate the hole diameter. The meaning of the word is written in parenthesis. The initial list was almost 70 words long.

Vote here!

If you have any additional thoughts, please let me know!

2016-12-13: First pictures of the model!

Alright, here is what I've got so far:


Now, you can see multiple things here, some are a bit more hidden. You can see the general shape, which is is very reminiscent of a normal vandal switch, apart from a few changes. I'll walk you through those features and my reasoning behind them. If you missed any prior discussion in the thread, you can catch up here.

Why not something other than a vandal switch?
While some are getting tired of seeing vandal switches used so commonly or dislike that they can't be flush with the front of a case, they have a very nice and minimal front and many still like that aesthetic. Additionally, that makes installation a breeze. Modding a case to take this switch is as simple as drilling a 16mm hole.

Why the two flat spots?
These have both an aesthetic and a functional reason. The functional reason is that they make it easier to hold the button in the same orientation while installing it. The aesthetic reason is that it ties the micro HDMI connector in much nicer than if the whole body was round. They also work much better with the set screws in my opinion.

What do the two slots do?
They each serve a different purpose. The one at the front grants access to a DIP switch that allows the user to free up one GPIO pin as explained in the previous post. This allows extending the functionality of the switch without opening the switch. The one at the back is an unfortunate necessity. When disassembling the switch, one has to insert a small slot screwdriver or other stiff flat object there before pulling out the internal assembly.

What are the set screws for?
Holding the whole thing together. To disassemble the button, only those two screws have to be removed. Then the whole internal assembly can be pulled out the bottom of the button. This allows access to the two resistors which are in series with two of the GPIO pins. These resistors can then be swapped out to accommodate different external LEDs or to use the EUSART bus on P4 and P5. (To use the I2C bus on P1 and P2 one only has to flick the DIP switch, no modding required) You can see that one screw is showing on the bottom. I'll see whether I can fix that, but right now the screw is too close to the bottom for that to work.

Why use a micro HDMI connector?
This connector (also called HDMI Type-D) is the only one for external use that has enough pins and is small enough to fit the button. It is also small enough to potentially fit a smaller 12mm version of this button. It carries a USB2.0 signal and five GPIO signals, which requires at least nine pins. There are a few pins left over, which could be used in a future version with a better Microcontroller for even more GPIOs.
Using a connector like this over directly connected wiring has multiple advantages for modding. It makes it easier, cheaper and safer. If the stock cable isn't the right length, right colour or you need different terminating connectors on the other end, you can just get a micro HDMI cable for 5 bucks and modify that to your hearts content. There's no risk of damaging the button by soldering and you don't even have to open it.

What are the 12 slots on the top for?
Those direct the light from the twelve independent RGB LEDs to the top. They are very visible in these pictures, but the actual cover ring will be frosted and I will do some testing beforehand to make sure that the slots don't show when the button is turned off and the separate LEDs lights don't bleed into each other inside the ring when turned on.

What is the purpose of those weird shapes at the bottom?
They serve alignment purposes. Some animations on the switch might be dependent on orientation, so the switch needs to know where "up" is. Usually it will consider the triangle to be "up", but if that is not desired (for example if that orientation would block the connector), one can set in the software which of the lines is the top one. Unfortunately, there's no space for an accelerometer inside the switch with the current manufacturing techniques I'm using, so this is has to be done manually.

Final thoughts
Of course, all of this is in flux and subject to change, but apart from a few small internal things that need to be changed I'm quite happy with the current status of the button. The next step would of course be a prototype, but I doubt that I'll make it to that stage this year. I'm also dreaming of replacing part of the internal structure with a flex-rigid assembly, which would free up a lot of space that is used by board-to-board interconnects at the moment, but prototyping that can be extremely expensive compared to a regular multi-PCB assembly.

2016-12-11: GPIO pin layout!

If pairs of the already broken-out GPIO pins could be used for I2C, these could be used to daisy-chain buttons without any extra hardware (and allow for easier synchronisation of multi-button effects than through a shared USB hub). That's a pretty rare use-case though.

Boy do I have news for you.

One more GPIO pin!

So, I was thinking a little. There was one GPIO left on my MCU, and it bugged me that I didn't utilise it. Today I found a way to do exactly that. Behold, the new GPIO layout:

It's not final, but I confirmed that this fits onto the PCBs and into the casing. So, we gained one more pin and I found a DIP switch that allows to decouple P1 from the button.

So, what does this mean?

Well, when flipping the DIP switch (for which the casing needs to be opened), the button is connected to GND on one side, so it can still be used normally when connected to the PWR_SW_P pin of the mainboard. Now P1 and P2 are a completely independent pair of IO pins, which are connected to the internal I2C signal processor. (Incidentally, you can also use P3 and P4 for EUSART, but that would still require replacing the 330R resistor with a 0R jumper.)

But that's not all.

That video was the reason why I thought about the button controlling LEDs in the first place. Unfortunately this particular setup would require more GPIOs than I have available.

The video I posted shows a fading effect for the HDD LED. With now 5 pins, you can either flip the DIP switch, use P1 and P2 for reading the HDD signal out and P3 and P4 for driving an external LED, or you could leave everything as it is, and just set P2 and P4 to read the HDD signal and P3 to drive an external LED on some external ground.

Can't you provide a header for "reset " output that can be connected to the motherboard, which is activated by one the GPIOs configured as open collector output ?

Well and of course you can also drive an external switch input if you want to.

Pretty good increase in features for a single additional component if you ask me.

 

[iFreilicht]

I can just barely fit a 32TQFP inside and I still have to put the support components somewhere.

Is that a microcontroller?

No, a package, but I have moved to 20SSOP. It makes everything fit a little easier, and 20 pins already more than enough.

That would be a good idea. It will help with further optimizing the project.

Done!

 

[Phuncz]

Awesome project ! How would you deal with the programability and usability, would you piggy-back off of an existing RGB implementation (Asus, Corsair, NZXT) or develop your own completely ?

Would it come in black ?

 

[K888D]

Great idea!

 

[iFreilicht]

How would you deal with the programability and usability, would you piggy-back off of an existing RGB implementation (Asus, Corsair, NZXT) or develop your own completely ?

Making my own would be fairly easy, so at least for testing I'll be doing that. I'd like to offer compatibility with that sort of software, but I don't know how much work it'll be and whether one of those companies will cooperate, so I can't say for sure.

I'd love to just have the code be open source and everyone being able to program it with Arduino IDE or something like that, but right now I don't know whether there's space for that kind of circuitry or whether I can fit a µC with that capability.

Would it come in black ?

Black and silver I'm thinking, maybe white as well. The casing will be turned from steel, so I have quite a few options with surface finish. I want to mimic normal vandal buttons as well as possible, so black needs to be made for sure. My prototypes will probably be done in just bare metal to save a bit of cost, though.

 

[CC Ricers]

Buy a couple of Chinese Arduino mini or Micro clones. They're just about as good as the genuine Arduinos and much cheaper. Easy to prototype with, especially since they have hardware serial communication support built in. That alone saves a lot of headaches of trying to write your own serial-over-USB firmware.

Arduino Micros have 32Kb of programmable flash memory which is more than enough to program in the functions you want for the LEDs.

 

[PNP]

The smallest RGB LED I've ever seen came in a 1206 package. Do you plan on doing the internals yourself? I don't envy trying to solder even one 1206 without a P&P machine (heh) or re-flow oven let alone 12. Each one of those will need its own driver/controller, and I've never seen a discrete one outside a complete (RGB LED + driver + SPI or 1-wire controller) 5050 package.

Honestly, you're skirting along custom IC territory. This has similar capabilities and besides the controller itself, the 5050 is the biggest thing on there. I don't mean to rain on your parade but you may want to either reduce it to something like 9 or 6 LEDs or find an IC that just has loads and loads of constant current LED drivers in it.

 

[Colinreay]

I'd definitely be interested in one! How small do you think you could feasibly make the vandal switch package?

 

[CC Ricers]

The closest thing I've seen to having a LED ring in a built-in array with driver is the NeoPixel, but the 12 LED array is 37mm in diameter, larger than a vandal-proof switch. As you can see they're already tightly packed so you'll need to reduce the number of LEDs without going with a custom PCB design.

They're made with SK6812 IC packages to control each LED. WS2812 is another one with similar qualities. Mini versions of both exist, but I haven't seen any sold in a pre-made ring array.

 

[PNP]

NeoPixel style 1-wire communication may not jibe well with USB polling rates. And since the precise timings required make interrupts impossible, you'll need to juggle polling the HDD activity signal too.

 

[iFreilicht]

Buy a couple of Chinese Arduino mini or Micro clones. They're just about as good as the genuine Arduinos and much cheaper. Easy to prototype with, especially since they have hardware serial communication support built in. That alone saves a lot of headaches of trying to write your own serial-over-USB firmware.

Arduino Micros have 32Kb of programmable flash memory which is more than enough to program in the functions you want for the LEDs.

Thanks for trying to help, but I've already decided on the microcontroller. I'll be using one with built-in USB support, there's no space for a serial-to-USB converter in this thing. I already have a genuine arduino, but I won't test with that, because the timing required for this to work is very specific and I want to make sure it works on the micro that'll be in the actual product, not something vastly more powerful.

The smallest RGB LED I've ever seen came in a 1206 package. Do you plan on doing the internals yourself? I don't envy trying to solder even one 1206 without a P&P machine (heh) or re-flow oven let alone 12. Each one of those will need its own driver/controller, and I've never seen a discrete one outside a complete (RGB LED + driver + SPI or 1-wire controller) 5050 package.

Honestly, you're skirting along custom IC territory. This has similar capabilities and besides the controller itself, the 5050 is the biggest thing on there. I don't mean to rain on your parade but you may want to either reduce it to something like 9 or 6 LEDs or find an IC that just has loads and loads of constant current LED drivers in it.

Mine is 1510 metric. Maybe I can find some through-hole LEDs with similar characteristics for testing on a breadboard, but no, I'll probably not be soldering the LEDs myself. They are very low current, so I can actually drive them just from the I/O pins of the micro that I selected, my main problem will be the reduced luminosity that is caused by charlieplexing all the LEDs. This is not a lighting circuit, though. All I want is that the LEDs can be seen in daylight, they don't have to be particularly bright.

On the main LED PCB, I have one button, 12 RGB LEDs and six resistors, all on a double-sided board and adhering to the design capabilities of a manufacturer I already found, so I'm not concerned about not being able to fit them inside.

I do need to switch the LEDs at quite a high frequency to fool the human eye, though. 50 Hz per LED and I can drive two at the same time, so just 900 cycles a second for a single brightness level per LED, and about 225kHz for 255 brightness levels. The MC is running at 48MHz, so I should be able to make it work. If not, I'll reduce the levels of brightness per LED.

12 LEDs are absolutely necessary because they are divisible by 2, 3, 4, and 6, so they allow for a lot of different options in terms of patterns.

I'd definitely be interested in one! How small do you think you could feasibly make the vandal switch package?

Great to hear! It will fit 16mm holes which seems to be a very popular size for vandal buttons. The current length I'll have to check when I'm home, but I'll try to make it as short as possible.

The closest thing I've seen to having a LED ring in a built-in array with driver is the NeoPixel, but the 12 LED array is 37mm in diameter, larger than a vandal-proof switch. As you can see they're already tightly packed so you'll need to reduce the number of LEDs without going with a custom PCB design.

They're made with SK6812 IC packages to control each LED. WS2812 is another one with similar qualities. Mini versions of both exist, but I haven't seen any sold in a pre-made ring array.

Yeah those LEDs are huge af and yes I'll have custom PCBs in this, no way around it. As I wrote above my LEDs are 1510 metric and the PCB containing them is already completely layed out and ready for manufacturing.

NeoPixel style 1-wire communication may not jibe well with USB polling rates. And since the precise timings required make interrupts impossible, you'll need to juggle polling the HDD activity signal too.

It'll already be hard enough with 36 LEDs on 7 pins, I don't want to imagine having all of that on a single one. Fortunately, the HDD activity polling will take much less cycles than the LED driving.

 

[jeshikat]

So is the plan for a custom-machined body or try to retrofit an existing vandal switch?

 

[PNP]

I do need to switch the LEDs at quite a high frequency to fool the human eye, though. 50 Hz per LED and I can drive two at the same time, so just 900 cycles a second for a single brightness level per LED, and about 225kHz for 255 brightness levels.

PWM dimming is a risky proposition, something that display manufacturers routinely catch flak for. It will be interesting to see if anyone will notice.

 

[hardcore_gamer]

PWM dimming is a risky proposition, something that display manufacturers routinely catch flak for. It will be interesting to see if anyone will notice.

PWM- LED control is patented (US 6586890). That's why I use sequenced dimming in my projects.

Edit: A few more details on sequenced dimming:

Simply generate a pseudo-random signal (For example, using linear feedback shift registers). Control the duty cycle to control the LED brightness.

 

[iFreilicht]

So is the plan for a custom-machined body or try to retrofit an existing vandal switch?

Custom machined, there's no way around that. Prototypes could be printed, though.

PWM dimming is a risky proposition, something that display manufacturers routinely catch flak for. It will be interesting to see if anyone will notice.

Fortunately I'm not making a real display here, but I can totally see why people would dislike it. But as you said yourself, there's too little space for dedicated drivers for every single LED, so I don't really have any other choice apart from making the switch much larger, and that ain't gonna happen.

Do you think letting the user choose between high refresh frequency and colour variety could help? So you could choose between 50Hz & 24-bit, 75Hz & 18-bit and 100Hz & 12-bit colour? Seems like a good compromise to me. If I can get a higher refresh rate on 24-bit colour, even better, but I read that 50Hz is the minimum.

Guess we'll just have to find out

PWM- LED control is patented (US 6586890). That's why I use sequenced dimming in my projects.

Edit: A few more details on sequenced dimming:

Simply generate a pseudo-random signal (For example, using linear feedback shift registers). Control the duty cycle to control the LED brightness.

Thanks for bringing that up, didn't actually know this was a thing!

What about using BAM to dim the LEDs? That doesn't seem to be covered by the Philips patent (which incidentally seems to be valid in Germany as well and the root of lots of controversy).

BAM seems to be a better choice anyway for colour mixing. When I had the Roccat Kova for a short while, getting a nice orange on that was pretty much impossible because the colours seemed to ramp up in intensity very quickly.

 

[PNP]

PWM- LED control is patented (US 6586890). That's why I use sequenced dimming in my projects.

Edit: A few more details on sequenced dimming:

Simply generate a pseudo-random signal (For example, using linear feedback shift registers). Control the duty cycle to control the LED brightness.

Dang ...surprisingly little legal action, given its ubiquity.

Same risks. If it isn't linear DC, it will produce discomfort for a small segment of the population. Granted, this is a niche product and the likelihood is low, but you never know.

Do you think letting the user choose between high refresh frequency and colour variety could help? So you could choose between 50Hz & 24-bit, 75Hz & 18-bit and 100Hz & 12-bit colour? Seems like a good compromise to me. If I can get a higher refresh rate on 24-bit colour, even better, but I read that 50Hz is the minimum.

Guess we'll just have to find out

50 Hz is kind of low (though I probably wouldn't notice), most backlights hover around 200-220 Hz, but it's also true that you aren't making a display and hopefully no one will spend their days staring at it.

Do you plan on giving user choice through software? Do you really need that sort of color depth on a button?

 

[iFreilicht]

Do you plan on giving user choice through software?

Oh I absolutely do. Allowing users to flash the firmware with the Arduino IDE seems like a nice option, integration into existing RGB peripheral frameworks was also mentioned. I think right now I'd prefer the Arduino approach, then I can still see whether a big company would be interested in partnering in the future. Some kind of driver will be needed on the OS side to allow users to interface with the button for more advanced stuff. At the very least, I'll make a command line program that allows sending signals to the button.

Do you really need that sort of color depth on a button?

Not really. 16.7 Million colours sounds nice, though. And for colour matching, more colours are always better. In my case, my board has orange underglow LEDs and I can't change the colour of those, but want the button to match. If someone wants this button for their LZ7, they should be able to make it match the accents as well as possible, too. You can come up with many more examples.

 

[EdZ]

50Hz should be perfectly acceptable for a 'full persistence' LED indicator. It was acceptable for pulse-illuminated CRTs all over Europe (PAL on 50Hz line frequency).
If you were sitting 1m in front of an LED indicator 10m across pumping out 100+ Lux then yes, 50Hz would probably be pushing things.
In practical terms, the only thing the refresh rate would limit you in is in moving patterns. With 12 LEDs, you can do a 'full run' around the ring in ~1/4 a second (with single LED illumination. Lighting multiple LEDs in varying brightness you could 'spread' the pulse and 'spin' faster). Upping the refresh rate would allow higher 'spin rates'.

 

[iFreilicht]

Ah yes, good point about the animation speed. I wonder what sort of limits RGB keyboards have in that regard.