Question about buttons?

I’m not a huge fan of the clicky buttons used on the front. I was wondering why the decision to use those rather that the rubber contact buttons that were used on the back?

1 Like

The buttons caused us alot of grief. More than anything else during the entire development. If I say the buttons set us back about 2 iterations and 4 months, it isn’t far from the truth.

Why silicon buttons were abandoned

Originally, we were using the silicon buttons on both sides. About 50% of clicks didn’t register. We improved the squiggles, we created solder mask free areas, we improved many things.

After about 2 revisions and really nightmarish debugging, we got the reliability to about 95%. But 95% in using buttons is NOT good enough. The user experience was absolutely horrible. You never knew when the button was going to misfire. I am not exaggerating when I say buttons have to be 100% reliable all the time. Even if 1 out of 100 clicks misfires, you’ll be tearing out your hair in no time. Thats how annoying it is.

It turns out, that silicon buttons, those cheap components we take for granted in our gamepads and remote controls are actually very very very fidgety about the axial pre-tension of the button dome. This means not only the distance has to be exact, but the case and button have to “pre-tension” the collapsible dome by ever so slight amout.

Now, the problem with the construction of Pokitto is, the case snaps together with Lego pegs. Lego pegs work great, but there is one thing they do not do: they do not extert any axial pressure - this is a big differentce vs screws where the whole point is the axial pressure they generate.

There was no way we could make the silicon buttons work, unless we would have changed the entire case mechanism from legos to screws. And this was february. So I decided to abandon the silicon keys. Maybe with a lot of debugging we could have gotten it working. Maybe not. Then Daniel suggested an alternative: a mechanical switch that was completely silent because it had a silicon dome inside

Part 2 - how silent silicon dome switches were abandoned

The silent mechanical switches were slightly bigger than the normal mechanical metal dome switches. Inside the button component was a silicon dome that essentially replicated how the silicon button works. Daniel found a supplier from China who was making them at a very reasonable price.

This seemed like an ideal solution: a mechanical switch without any of the bad aspects of a mechanical switch. In other words, it was silent.

So yet another case iteration, yet another PCB iteration, yet another 1,5 months.

The silent dome buttons were a total, horrible failure, and I think the Chinese supplier has a disaster in their hands.

Within a weeks almost all of the button components stopped working. There was another really bad thing: when you press on a mechanical metal dome, it goes past its buckling point, after which the spring force is a lot less. This means less force needed to hold down the button. But in the silent silicon dome buttons, the spring force (as per Hooke’s law) is directly proportional to the distance you press the button down, there is no buckling point. This means the button was pressing against your finger all the time. In games, it means your fingers get really tired, even if you are an adult man.

The mechanical clicky buttons were a compromise to the benefit of having a button that fires every time you press it, no matter what. The click is an unfortunate side-effect.

If you want to reduce the click a bit, take a piece of plastering tape (the kind you use for plasterin wounds) cut little circles and glue them to the tops of the button components. This reduces the “play” of the button and reduces sound.

4 Likes

Wow, I would never have thought that ‘simple’ things like buttons would have caused so much trouble!
Thankyou very much for the insight. I was thinking of adding tape to the bottom of the plastic on the buttons to trduce the wobble a bit and make them feel a little more like rubber ones, I’ll definitely give it a try now :slight_smile:

2 Likes

This adjustment has recently been done to the Pokitto button molds. But again this was a decision of time vs. finetuning. Try to manage, buttons that we will be producing later are “tighter”

2 Likes

I know what you mean, the keyboard on my pocket chip is clicky domes and there are times typing in terminal I want to bang my head off the floor, I actually had a replacement set sent to me by one of the NTC guys because I had several that just wouldn’t register, I have heard the buttons on Pokitto and they sound good. And solid.

personally prefer a clicking button ( cherry mx blue guy here)

are they going to be changed in any revisions?

1 Like

Probably not very soon.

The button we’re using is a very reliable component (there are not-so-small differences in the quality and lifespan of switch components) and we will keep it for the time being.

This is a nice illustration of why the “90/90” rule of product development is a thing: the first 90 percent of the product (good enough to give to your friends) development takes the first 90 percent of the time allotted. The last 10 percent of the product development (good enough to sell to strangers) takes the second 90 percent of the time allotted.

IOW, it takes at least as much work to go from “good enough to give to your friends” to “good enough to sell to strangers” as it took to get to the first stage, and anyone doing the work to get to the product stage deserves real respect.

1 Like

I have completely different question for button usage. I heard (If I’m not wrong) flash button is normal button like dpad. Can you assign volume up/down, exit program & load loader and something another functions for system button scheme to flash+another button?

I do prefer the clicky ones above the rubber domes too. I have a NeoGeo Pocket with mechanical switches and they are really comfortable to play with.

1 Like

Correct. In one of the first versions, we tried to use up button to double as flash mode select/up button.

We started getting lockups at boot so we gave up on it. Perhaps someone finds a way to use it. Its connected to a normal port (P0_3 if i remember right)

2 Likes

So I found flash button connected P0_2 instead of P0_3.
First try: No interrupt attached to flash button. Program writed for directly read button with mbed DigitalIn function. Pokitto loader wait screen passed but pokitto stuck at volume setting screen.
Second try: Attached interrupt to Flash button. Pokitto really slows down. Pokitto loader wait screen and volume setting screen passed. Program running but Pokitto not reading Flash button. Every time i read true.
I think i need SWD :confused:

1 Like

This works for reading the flash button…

long unsigned int pins = (((volatile uint32_t *) 0xA0000000)[0]);
if((pins >> 8 & 1) == 0){
    // Flash button is held
}
1 Like