Author Topic: Issue with Spaceman Pancake rev 1 / Kailh Choc switches  (Read 1234 times)

0 Members and 1 Guest are viewing this topic.

Offline Deacon Cole

  • Thread Starter
  • Posts: 6
Issue with Spaceman Pancake rev 1 / Kailh Choc switches
« on: Wed, 03 April 2024, 12:40:53 »
So, I'm using a Spaceman Pancake rev 1 keyboard that uses the Kailh Choc white switches for a project. It's been doing what I want, but lately I've noticed it double hits the space sometimes. Triple hit sometimes. Kind of annoying since this is a distraction-free word processor and it's kind of distracting to go back an remove spaces all the time. <<< it would have done it at least four or five times in the space of the proceeding text.

Problem is, I'm not sure where the issue is so I can solve it. Could be the switch is going bad, which means getting out the soldering iron, which I'm not super looking forward to.

It could be the debounce needs to be increased by editing the config.h file in the source code, but I downloaded the source code and it doesn't have a config.h file, so I'm unsure how to proceed.

Have others been having trouble with Choc switches like this? I haven't had this keyboard very long, so it seems weird that it would wear out so fast.

Any help on how to proceed will be appreciated.

Offline Deacon Cole

  • Thread Starter
  • Posts: 6
Re: Issue with Spaceman Pancake rev 1 / Kailh Choc switches
« Reply #1 on: Thu, 11 April 2024, 12:44:46 »
So, my issue persists but I have been making attempts to correct it and have further observations.

I'm no long convinced the issue is the switches, specifically. That is, I no longer think they go bad prematurely or that this one button is going, possibly defective. The keyboard seems to work fine on my laptop but in the project which runs on a Raspberry Pi Zero (Raspberry OS Lite Bullseye) I occasionally get the issue, more later. That said, the switches may be contributing to the problem. I had found this issue before and have just re-confirmed it with my multimeter. The Kailh Choc switches connect just before engaging the "click," unlike Cherry MX switches which engage on or immediately after the click. It makes it possible to engage the switch without clicking. This is one of the trade-offs in using low profile switches, I suppose. I have V1 Chocs and do not know if V2 behave the same way, but would be surprised if they don't. So it might be that sometimes when I press a button that it engages a little bit earlier than I think and then goes into the key repeat routine a little sooner than expected, which would explain why I get double and sometimes triple hits.

Next I checked for mechanical problems. I was using the 48 key layout with a two-button space bar and thought I may be fat-fingering it. I don't know if the software would count each button as a separate button and not be effected by the debounce routine, but I suspect it would. I have replaced the two with a single button and have a stabilizer on order, but I was using it this past weekend and I started getting the issue for no discernible reason. I pressed directly down on the key and watched the space advance once when pressed and then again upon release. I have opened on of the switches and can't really see what would cause this double hit unless it's what I described in the preceding paragraph. The second mechanical issue is that I have the project is a case made of foam core, which includes a bezel around the keyboard. Since this case is for prototyping purposes, I don't care about aesthetics and the whole thing is held together with blue tape. I am constantly opening up the top, so the tape loses it's grip. This bezel has caused problems before with keys being hard to press because it's in the way, either lifting up or shifting out of position. I have it removed now and will see if I get further issues.

If I do, I will need to see about reflashing the firmware and extending the debounce delay. I've been reading through the QMK manual webpage and think I understand that I can simply add the config.h file to the appropriate folder. Would be nice if it had it so I could just edit it, as per the instructions, but such is life

Offline Rhienfo

  • Posts: 605
  • Location: Melbourne, Australia
  • Why is everything I want here so expensive :(
Re: Issue with Spaceman Pancake rev 1 / Kailh Choc switches
« Reply #2 on: Thu, 11 April 2024, 21:54:47 »
I'm not too well versed on pcb stuff, but I still think you should probably replace that swi

I think the only differences between choc v1 and v2 is is the stem can accomodate cherry caps and there is a different footprint for the bottom of the switch.

I'm more leaning to this being a software problem or a pcb issue, if all the chocs proceed the actuation before the click (which I didn't know about that's a bit interesting)

I might not be interpreting what You said that there was foam involved in the case, that might've done a electrostatic discharge if it's not foam designed to not produce those discharges and messed up that certain part of the pcb, you might want to test the pcb to see if there are not underlying issues there.

Hope you figure out what's going on and fix it.
fjell | hhkb bt

Offline JamieC1

  • Posts: 1
Re: Issue with Spaceman Pancake rev 1 / Kailh Choc switches
« Reply #3 on: Fri, 12 April 2024, 23:43:59 »
The extra spaces on your keyboard might be due to a switch issue or a setting that needs adjustment. Try changing the debounce setting or replacing the faulty switch. If problems persist, contact the manufacturer. Publix Passport
« Last Edit: Sun, 14 April 2024, 22:54:30 by JamieC1 »

Offline Deacon Cole

  • Thread Starter
  • Posts: 6
Re: Issue with Spaceman Pancake rev 1 / Kailh Choc switches
« Reply #4 on: Sat, 13 April 2024, 14:44:54 »
Hope you figure out what's going on and fix it.

Thank you. I think I may have the answer and it's not great.

The issue is definitely the switches and because the Choc switches engage just before the click, which throws the timing all off. The solution is to adjust the repeat delay settings, which is not in the QMK firmware but handled in the Raspberry Pi's OS.

The problem is this feature is poorly documented and has changed over the more recent distros of Raspberry OS. So, information tells me to edit a file that no longer exists. And if I try to make that file, is disappears on reboot. Joy!

The command to fix it is

Code: [Select]
sudo kbdrate -d 500 -r 80
Which gives me a half a second delay over zero when I first boot up. The problem is this is lost on reboot and needs to be re-entered. Making this permanent is difficult because all the documentation (forum posts) online I have found points to files that no longer exist or do not work. Even the manual for kbdrate (man kbdrate) points to a file that doesn't exist and it doesn't look in it if I create it. On top of this, most of what I have found online involves the GUI interface, which I am not using and has tools and settings that are incompatible. Changing the delay in the command line will not effect the GUI and vice-versa. Gotta love LINUX. God knows why.

Anyway, I found I can enter the command and settings in /etc/bash.bashrc... with sudo, which I'm pretty sure is a bad idea... and it works. On boot, the 500ms delay is present and it greatly reduces the possibility of getting a double or triple hit.

It's not a perfect solution, but since it's a timing thing with how the switches work, the only real solution would be to get a different keyboard with MX switches that connect when they click. But I would lose all the space under the keyboard, then. Or it would make the project much, much thicker. We'll see how I like this solution before I go dropping a couple hundred on another keyboard.