So does those double action switches close both terminals when fully pressed in?
-
Save 15% on ALL SFF Network merch, until Dec 31st! Use code SFF2024 at checkout. Click here!
Yes it will be clicky, but not the way keyboard keys can be clicky. Think of clicking like on the lock-button on an iPhone.
Yes, all the ones I know do.
So, I do think this is an interesting idea. Thank you for linking two possible candidates, that's quite helpful. I'll first confirm or correct any statements I can, then go on to discuss this.
That is correct. It does read out the state of the button, this allows to start an animation when shutting the PC down, but the switch is directly connected to the mainboards PWR_SW header. The user doesn't necessarily have to connect it that way, as some mainboards do support Standby power supply on the internal USB ports and GPIOs can simulate a switch being pressed, but it needs to be the standard configuration.
I don't know that this is true. For the reset button you're right, but I've not seen a setting like this in the BIOS of my mainboard (GA-B85N Phoenix) for the power button.
This is a very good point. Including a two-stage switch is not going to hurt anybody.
The only thing that would add expense is the different switch. Anything else that needs to be changed would be in PCB layout, which does not change the cost in this case. Suggestions and Ideas are why I post projects so early instead of developing them in secret, so thank you for bringing this up!
Come on... its like saying "how are you going to avoid stabing your eye by using a fork to eat?"
Eh I'm not in line with that. That question is actually quite legitimate when talking about small children when they first learn to eat. You'd never give them a fork, they'll learn with a spoon first because then they can't hurt themselves as easily.
Additionally:
They are designed for cameras where a half-press will only trigger the auto-focus to adjust. The force curves on those switches, especially the first stage, are not very high, so it is quite easy to accidentally press it in too far. With a camera, this doesn't matter too much, you just take a second picture.
But with a PC, where pressing the button in too far could cause all your work to be lost, we need to think a little more about the possible applications.
Is it really, though? Resetting a PC can be achieved by holding the power button in, so I don't see this as a valid argument for including a two-stage switch.
This seems extremely complicated as compared to just holding the button in for two to four seconds. How often do you have to do that anyway?
Discussion:
So, I haven't checked yet whether there's a two-stage switch that would actually fit into the Iris 16, let's suppose there is.
In terms of adding a way to read out both stages of this switch, the additional required development is close to zero. It requires a single GPIO pin on the microcontroller, currently three are unused. So really, if it can be done and doesn't increase cost, there's no argument against doing it. It will increase the value and it will not hurt anyone who doesn't want to use it.
Potential use cases for the mid-press would be turning an animation on or off, switching LED lighting or fans in your case on or off (though that would require a bit of tinkering) or to lock the PC. So pressing the button in a little would lock it, pressing it in all the way would send it to sleep mode. Really, if the button implements another USB endpoint (for a keyboard for example), you could just use AutoHotKey to make the mid-press do anything you want.
As I said above, the full-press circuit needs to be connected to the PWR_SW header by default, so the switch is guaranteed to turn on the PC correctly in every scenario. You can work around this by connecting the Iris 16 to an internal USB port that supplies power in standby and configuring one of the GPIOs to "fake" a switch. In that case, you can use the two stages for anything you want and can modify the firmware using the Arduino IDE to do exactly what you want. Freedom is endless in that case.
One decision I can make right now is that the mid-stage would not be directly connected to the outside. So if the button isn't powered, there's no way to know whether the button has been depressed by half. This will not hurt functionality in any way in my eyes, and is important as it keeps all the external pins free of fixed functionality.
On a general-purpose button it'd be fine, but on a power button it seems like it'd cause headaches with accidental presses.
OEM machines (Dell, HP, etc.) never have reset switches and I have absolutely no problems working on them. If the OS is stuck just jam the power button down for a few seconds and force it off, otherwise yank the power cord.
OEM machines (Dell, HP, etc.) never have reset switches and I have absolutely no problems working on them. If the OS is stuck just jam the power button down for a few seconds and force it off, otherwise yank the power cord.
I'd also be wary of actually using a function where a few extra newtons of force can accidentally power off the machine.
Well, there's nothing stopping anyone from using this as a general purpose button, so maybe catering to that crowd might be beneficial?
Jup, seems way too risky.
Well you could set the power button to not do anything in the OS settings and then use software to turn the PC off (USB HID has a scancode for lock, sleep and power down), so it's certainly solvable, but nothing I'd implement as a stock option.
Actually, I forgot something:
Two-stage buttons might actually feel less clicky than regular ones, that would have to be tested.
Agree with the others, too risky.
I mean, two stage buttons can be useful if the usage follow familiar patterns. Example: camera auto focus + shoot.
But not for a PC, where most people are used to having separate power & reset buttons.
My 2 c
Usually the setting is something to the tune of: tap sends sleep command, hold for 3-4 seconds sends shutdown command.
There may or may not be an option to disable the sleep function on the quick press action, and just have the hold for power function.
For Windows, everything other than the hold-power-to-power-off (a motherboard function) is determined in software. You can choose what function a short press of the button does without touching the BIOS/UEFI. The user-exposed option are "Do Nothing", "Sleep", "Hibernate", and "Shut down", but I suspect there are registry keys that you could modify to trigger arbitrary events.
Jup, that's the way I know it. So you could just tell windows not to "Do Nothing" and then use the HID endpoint on the button to trigger shutdown/sleep if desired.
In any case, all of this would be non-standard behaviour to be added by the user, and there is no use-case I could think of that would require the mid-stage of the button to be externally connected, so in any case this would be a very small change in terms of design.
I havent looked through the forum throughly so this may have been asked already but would it be possible to do a 12mm even if you have to sacrifice some leds? also if this is successful would you consider a 12mm version?
Yeah a 12mm with fewer LEDs should be doable. For now I'll concentrate all my efforts on the 16mm version and I do have some doubts about the actual demand for a 12mm variant, but I'll certainly make a poll when the time comes
Heck I'd love a 22mm version
Absolutely something to consider as well. 22mm version would probably have a few more features/LEDs as well. Maybe it'd already be big enough for two rings.
To keep you in the loop:
For anyone wondering, the package with the breakout PCBs is still at customs. I did have to do quite a bit of paperwork because I'm doing this gig as a company now, but I got my EORI number a few days ago and DHL should've sent the package on by now. Going to phone in tomorrow to see what's up.
Last edited:
22mm bezel or cutout diameter? Some vendors aren't consistent about whether the labeled size is the panel cutout diameter (ie the body diameter) or the bezel diameter. I ordered the wrong one by accident because of that and a proper 22mm switch is huge
Cutout diameter22mm bezel or cutout diameter? Some vendors aren't consistent about whether the labeled size is the panel cutout diameter (ie the body diameter) or the bezel diameter. I ordered the wrong one by accident because of that and a proper 22mm switch is huge
I tend to find the bezel and actuator to be just perfectly sized for my fingers.
Technical Update:
I finished a prototype implementation of BAM/BCM (Binary Code Modulation) and Charlieplexing on the Arduino Micro, and results are very promising!
To reiterate, with Charlieplexing I am able to control all 36 LEDs individually using just 7 I/O pins. Because Charlieplexing requires tri-state logic to work properly, I can not use the built-in PWM facilities of the microcontroller, so I'm using BCM to minimize the processor overhead caused by a implementing the modulation in software.
There are two main concerns when doing this, flickering and brightness. Because of the high number of LEDs, for 24-bit colour it is required to switch the state of the output pins 56 times for just a single frame of animation. Even worse, because some of them need to take much longer than others, more than 114000 steps are required for one animation frame. Additionally, each LED can maximally be on for 1/7th of the time. If the microcontroller isn't able to switch between states fast enough, the LEDs would seem to flicker and potentially be much darker than desired.
But after finishing my implementation on 6 LEDs using 3 pins, it is fairly safe to say that at least flickering won't be an issue. The Arduino Micro has a 16MHz crystal, and I am able to render at a little over 320 FPS. Switching over to 7 pins would only decrease that to about 138 FPS, which is still pretty great. Additionally, Iris 16 will run at 48MHz, so thrice as fast. There's also no noticeable flickering of any sort, so that's pretty great.
The only unknown now is the brightness. We'll see how that works out, but I'm pretty positive that it will be bright enough.
There's actually some pretty neat stuff like manual loop unrolling and adaptive delay correction built in to my implementation that allows for these fast speeds and also makes the whole thing more accurate. Reading this back those two sound like awesome marketing buzzwords.
I'll make the source code available in due time, but please understand that it'll stay confidential for now.
Hope to give you some hardware updates soon, thanks for reading!
I finished a prototype implementation of BAM/BCM (Binary Code Modulation) and Charlieplexing on the Arduino Micro, and results are very promising!
To reiterate, with Charlieplexing I am able to control all 36 LEDs individually using just 7 I/O pins. Because Charlieplexing requires tri-state logic to work properly, I can not use the built-in PWM facilities of the microcontroller, so I'm using BCM to minimize the processor overhead caused by a implementing the modulation in software.
There are two main concerns when doing this, flickering and brightness. Because of the high number of LEDs, for 24-bit colour it is required to switch the state of the output pins 56 times for just a single frame of animation. Even worse, because some of them need to take much longer than others, more than 114000 steps are required for one animation frame. Additionally, each LED can maximally be on for 1/7th of the time. If the microcontroller isn't able to switch between states fast enough, the LEDs would seem to flicker and potentially be much darker than desired.
But after finishing my implementation on 6 LEDs using 3 pins, it is fairly safe to say that at least flickering won't be an issue. The Arduino Micro has a 16MHz crystal, and I am able to render at a little over 320 FPS. Switching over to 7 pins would only decrease that to about 138 FPS, which is still pretty great. Additionally, Iris 16 will run at 48MHz, so thrice as fast. There's also no noticeable flickering of any sort, so that's pretty great.
The only unknown now is the brightness. We'll see how that works out, but I'm pretty positive that it will be bright enough.
There's actually some pretty neat stuff like manual loop unrolling and adaptive delay correction built in to my implementation that allows for these fast speeds and also makes the whole thing more accurate. Reading this back those two sound like awesome marketing buzzwords.
I'll make the source code available in due time, but please understand that it'll stay confidential for now.
Hope to give you some hardware updates soon, thanks for reading!
Technical Update:
I finished a prototype implementation of BAM/BCM (Binary Code Modulation) and Charlieplexing on the Arduino Micro, and results are very promising!
To reiterate, with Charlieplexing I am able to control all 36 LEDs individually using just 7 I/O pins. Because Charlieplexing requires tri-state logic to work properly, I can not use the built-in PWM facilities of the microcontroller, so I'm using BCM to minimize the processor overhead caused by a implementing the modulation in software.
There are two main concerns when doing this, flickering and brightness. Because of the high number of LEDs, for 24-bit colour it is required to switch the state of the output pins 56 times for just a single frame of animation. Even worse, because some of them need to take much longer than others, more than 114000 steps are required for one animation frame. Additionally, each LED can maximally be on for 1/7th of the time. If the microcontroller isn't able to switch between states fast enough, the LEDs would seem to flicker and potentially be much darker than desired.
But after finishing my implementation on 6 LEDs using 3 pins, it is fairly safe to say that at least flickering won't be an issue. The Arduino Micro has a 16MHz crystal, and I am able to render at a little over 320 FPS. Switching over to 7 pins would only decrease that to about 138 FPS, which is still pretty great. Additionally, Iris 16 will run at 48MHz, so thrice as fast. There's also no noticeable flickering of any sort, so that's pretty great.
The only unknown now is the brightness. We'll see how that works out, but I'm pretty positive that it will be bright enough.
There's actually some pretty neat stuff like manual loop unrolling and adaptive delay correction built in to my implementation that allows for these fast speeds and also makes the whole thing more accurate. Reading this back those two sound like awesome marketing buzzwords.
I'll make the source code available in due time, but please understand that it'll stay confidential for now.
Hope to give you some hardware updates soon, thanks for reading!
I need to see picturessss I need hype to see if I'll be able to drill a 16mm hole in my modmini instead of the 12 that's there for this >.>
I'm impressed!Technical Update:
I finished a prototype implementation of BAM/BCM (Binary Code Modulation) and Charlieplexing on the Arduino Micro, and results are very promising!
To reiterate, with Charlieplexing I am able to control all 36 LEDs individually using just 7 I/O pins. Because Charlieplexing requires tri-state logic to work properly, I can not use the built-in PWM facilities of the microcontroller, so I'm using BCM to minimize the processor overhead caused by a implementing the modulation in software.
There are two main concerns when doing this, flickering and brightness. Because of the high number of LEDs, for 24-bit colour it is required to switch the state of the output pins 56 times for just a single frame of animation. Even worse, because some of them need to take much longer than others, more than 114000 steps are required for one animation frame. Additionally, each LED can maximally be on for 1/7th of the time. If the microcontroller isn't able to switch between states fast enough, the LEDs would seem to flicker and potentially be much darker than desired.
But after finishing my implementation on 6 LEDs using 3 pins, it is fairly safe to say that at least flickering won't be an issue. The Arduino Micro has a 16MHz crystal, and I am able to render at a little over 320 FPS. Switching over to 7 pins would only decrease that to about 138 FPS, which is still pretty great. Additionally, Iris 16 will run at 48MHz, so thrice as fast. There's also no noticeable flickering of any sort, so that's pretty great.
The only unknown now is the brightness. We'll see how that works out, but I'm pretty positive that it will be bright enough.
There's actually some pretty neat stuff like manual loop unrolling and adaptive delay correction built in to my implementation that allows for these fast speeds and also makes the whole thing more accurate. Reading this back those two sound like awesome marketing buzzwords.
I'll make the source code available in due time, but please understand that it'll stay confidential for now.
Hope to give you some hardware updates soon, thanks for reading!
-Edit-
Have you done any research into which Open Source license you'd use?
Last edited:
More good news! DHL just informed me that my breakout PCBs have cleared customs yesterday, so they'll (surely) be here by the end of the week.
Thanks!
A little, but damn that shit is complicated. I think for the software I'm leaning towards something like GNU GPLv3 because it requires derivative works to also be free and licensed the same way and explicitly forbids using patents to make the software non-free, which would doubly protect me from reverse patenting frauds like @Josh | NFC suffered from in the past. That also serves as a guarantee to the customers that they can do with the software whatever they want indefinitely, I won't be registering a patent and go after them.
In theory, this license would also require anybody copying my product on the basis of my own published code to make it open source as well, allowing me to profit from their improvements (if they implement any). In reality a company like TT couldn't give a shit and a half about that, they'd just copy it and be done with it, but it's a nice thought and someone's got to take a step into that direction.
One problem with GPLv3 is that inherently closed source applications like government projects are then not allowed to use any of my work, limiting its usefulness. It's a bit of a moral conundrum.
For now, my code doesn't have a license at all, so it is protected under copyright.
The hardware is a different thing, not sure about that yet.
I wanted to make a short video of the charlieplexing in action, but didn't manage to hardcode a nice enough animation. So I'll implement the frame calculations first, and at that point I can hopefully show the full LED ring in action.
But if you just want a picture of the breadboard with the six LEDs and the Arduino in it, I can give you that later this day
I'm impressed!
Have you done any research into which Open Source license you'd use?
Thanks!
A little, but damn that shit is complicated. I think for the software I'm leaning towards something like GNU GPLv3 because it requires derivative works to also be free and licensed the same way and explicitly forbids using patents to make the software non-free, which would doubly protect me from reverse patenting frauds like @Josh | NFC suffered from in the past. That also serves as a guarantee to the customers that they can do with the software whatever they want indefinitely, I won't be registering a patent and go after them.
In theory, this license would also require anybody copying my product on the basis of my own published code to make it open source as well, allowing me to profit from their improvements (if they implement any). In reality a company like TT couldn't give a shit and a half about that, they'd just copy it and be done with it, but it's a nice thought and someone's got to take a step into that direction.
One problem with GPLv3 is that inherently closed source applications like government projects are then not allowed to use any of my work, limiting its usefulness. It's a bit of a moral conundrum.
For now, my code doesn't have a license at all, so it is protected under copyright.
The hardware is a different thing, not sure about that yet.
I wanted to make a short video of the charlieplexing in action, but didn't manage to hardcode a nice enough animation. So I'll implement the frame calculations first, and at that point I can hopefully show the full LED ring in action.
But if you just want a picture of the breadboard with the six LEDs and the Arduino in it, I can give you that later this day
Similar threads
