Showing 1 of 1633 conversations about:
View Full Discussion Hey everyone,
Appreciate all your patience while we worked through the double input issue (i.e. chattering).
The good news is that we've found a promising solution that can be applied via a firmware update. I also wanted to give a shoutout to @skytz for putting us on the right path to getting this addressed.
We've updated the Drop Keyboard Configurator such that any newly generated firmware will have the fix built-in. For those that need help with flashing a new firmware, @Elbert created a more indepth guide with screenshots.
We are still doing additional root causes analysis on other parts of the keyboard that could be contributing to the issue. If anyone runs into issues after applying the update, do let us know!
Would this issue and fix also apply to high profile ctrl's?
Seems to be working so far... finally a fix. thanks!
Yep! They all run off the same PCB / firmware.
Would this fix be automatically applied to the boards being shipped out ETA August 12?
Tried the fix, but get "Error: Could not find a valid device port" when running the exe. Have tried different USB ports on the pc, tried both usb c ports on the CTRL, and different usb c cables...Any thoughts?
@stepsten Did you get the reset button on the back of the keyboard after running the command on your command prompt?
@saintsummoner no, this fix is still new and those units were manufactured and shipped to our warehouse before the fix was found. In addition, we will need to run validation and qualification on this new firmware before deploying it in production. This will take some time to complete but we wanted to share the fix right away with everyone.
I see. Thanks. Do you know when the board are supposed to go out? Previously it said that it should be shipped by august 12 but now it's august 14. It also seems like some people have been waiting since august 1st.
Flashed the updated fw a few hours ago and it seems to be fixed. Will update in a day or 2 and let ya know.
my bad..i thought i had to wait for the port to be found before hitting the reset button. i tried again and was able to flash successfully. hopefully it's fixed.
I flashed today. No change. Tons of keychatter.
Can you guys provide a link to the source changes / whatever?
I changed the keyswitches because I figured out I *do* like the tactile / clicky more than I expected ( had linears ). That change was not related to this issue. I've noticed the duplication but have not seen a discernible pattern. My suspicion here is that a firmware setting related to key-press timing which implies a config change in the firmware may address this issue.
So far none of the key repeating feels related to the hardware. It could be resistors per key or something. Over-all the keyboard works just fine and I'm happy with it. I never have issues with key-presses being detected / working so pretty confident its not a hardware issue.
@PigmonkeY That's odd to hear. If you feel up for it we can get your unit in the office to evaluate and get a working one out to you / fix up yours?
At this point, I'm already on my THIRD replacement board. I'm just going to take it as a lesson learned about anything with a "massdrop made" logo on it, and make sure to spread that message to anyone who may be considering a product from you guys.
Furthermore, I already got rid of the halo switches that came with the board, in hopes of solving the keychatter issue. Lesson learned.
Sourcecode changes they've done so far are here: https://github.com/Massdrop/qmk_firmware/commit/3cb242b47d50571c599ee9fa0a1cde15632fcdd8
If you're interested, look into switch debouncing. In the recent fix, they changed the firmware sourcecode to use a different debouncing algorithm. There are hardware implementations of switch debouncing that use a capacitor, but usually not in keyboards. It's cheaper (and sufficient) to handle it in firmware.
Awesome thanks! I figured it would be something along these lines
That does work to some extent. However, you run into a problem when the debounce value is set to a high MS where inputs are no longer recognized when a user is typing fast. So instead of double input, you are now dropping inputs.
Did you recompile your firmware with either our web configurator or the latest version of our QMK fork? It's not enough to just flash your keyboard with the same firmware as before.
There should be a noticeable improvement.
I went to the configurator, compiled the default layout, and flashed it over.
Edit: To be clear, this is flashed to non volatile memory, so it would not have reset my new flash when I unplugged the board to clean it, would it?
It is indeed. I flashed a second time, and went ahead and played about an hour and a half of typing of the dead. It looks like the problem has reduced since I reflashed, however i'm still regularly doubling certain letters (namely S and L for some reason.)
Few days update for me since re-flashing, the update seems to have fixed it for me.
We would still love to take a look at your keyboard since the behavior really does deviate from our test results. If you are worried about having a keyboard to use in the meantime, we can get a replacement sent out to you first.
It seems to have fixed it for me in general, however I think I have one bad switch (the chatter stopped for every key except this one). I want to try replacing the switch but I can't find cherry MX brown RGB switches for sale anywhere. Any ideas where I can get replacement switches?
So I have updated the firmware based on the drop keyboard configurator published above. So far I have not really seen a change in behavioor - I still get the occasional repeated keypress. I'm intentionally not fixing this update so you can see juust what frequency this occurs with. I do feel it is occurring less frequently however it still does happen..
only spelling / corrections I've made are when I did actually misspell a word ;)
It worked considerably better than "to some extent" for my CTRL. I only needed to #define DEBOUNCE to 10 to deal with the remaining issues after fixing most of them by changing wait_us as skitz suggested. So far I have seen no problems at all, so presumably I don't type fast enough for 10 to be a problem. I don't know how high it can go without causing missed keypresses, but I wouldn't discourage people from trying it.
Opening port 'COM3'... Success!
Found MCU: SAMD51J18A
Bootloader version: v2.20 Mar 27 2019 10:04:47 [ctrl]
Applet file: applet-flash-samd51j18a.bin
Error: Could not open applet file: applet-flash-samd51j18a.bin
Closing port... Success!
i did it exactly like in the manual and named the new firmware default.bin however i always get errors.
Keeping DEBOUNCE at 5 and setting the wait_us delay to 20 works great for me.
Also important to everyone tweaking these values... DEBOUNCE is measured in milliseconds, while wait_us is measured in microseconds.
The Cherry MX keyswitch spec sheets also recommend a debounce delay of 5 milliseconds.
wait_us of 20 was a huge improvement, but still got occasional doubles. I probably wouldn't have used it all day for serious work. DEBOUNCE of 10 reduced it still futher, to the point that I used it all day today and it took a while before I could tell that there are still bounces, just very rare (like a few per day). It is something like the rate going down by an order of magnitude each time. I guess I should tweak one or the other further, but I'm not sure which.
Ah I see. I suppose it also depends on which keyswitch you have too. I'm using box whites, which doesn't seem to be as susceptible as the other switches.
I have Halo Clears, which seem to be a lot more susceptible. Still, the three mods combined (using the current massdrop repo, setting wait_us to 20, and DEBOUNCE to 10) is so close that It shouldn't take much to get to zero (or below the threshold where I can tell, I guess). Not sure if I should take wait_us to 25 or 30, or DEBOUNCE to 15, but I guess experimenting is easy.
I bumped wait_us to 25, no bad effects I can see in a few minutes typing. We'll see what happens tomorrow. Given the high rate of convergence of the patches, it seems like I'm a couple of steps from getting below the noise floor. :-)
I'm on the master branch of the massdrop repo--is there by chance a bugfix branch I should be on instead? I didn't see anything obvious. If I'm wrong it would be useful to have the latest upstream--the configurator version probably reduced the bouncing by half, still significant.
Part of the reason I bought this board is for playing with switches as well as firmware. Are there any other brands known to be an issue?
I think you should be able to increase the wait_us delay pretty large without any noticeable negative effects. But I've also seen firmwares use 40-50 microseconds.
I haven't checked out the other branches, so I can't say for sure if there's a bugfix branch. (I'm not part of the development team, just contributing in my spare time :D )
Funnily enough, my repo is actually forked from the upstream qmk repo.
And I don't know any other keyboard with debouncing issues, so I can't help you there. :/
- OK. Maybe I'll concentrate on wait_us for now.
- Well, maybe someone from Drop will wander by and let us know if there is. If there is not, it might not be a bad idea for them to create one, or a few, so we can help them try out fixes (and also show that they're working on it as a cheap & easy bit of customer care).
- I didn't mean other keyboards, I meant other switches that have issues in this one. I'm planning to play with switches, you see, and wouldn't mind knowing in advance. :-)
I'm also screwing with firmware like other people in this thread, and so far have found wait_us 20 as some have tried seems to have helped the problem significantly.
Do you think you could share the default compiled bin with your fix? 😬 pretty new to qmk and a lot of this is over my head.
Firmware report: after a day of hacking with wait_us(25), I can report that I did not once think it had doubled on me. It felt perfect, so logically I'd leave it as is, but I'm tempted to see if I can drop DEBOUNCE back down to the default now that wait_us is up. On the other hand I really enjoyed the keyboard today, so I might want to to install the code and toolchain on my work computer before I mess with perfection.
Playing with different switches is next, but I'm warming up to it more and more just as it is with these halo clears. Probably just warming up to mechanical keyboards in general after not using one for a long time. Today the feeling was more "crisp" and less "loose", so I'm regaining my touch. I think the heavy aluminum plate helps, most of the mechanical keyboards I used back in the day were built more lightly (yeah, they were probably nearly all the cheap end, though I'm pretty sure I let a Model M slip away without ever knowing what I had). Really happy with the keyboard now that the firmware seems to be behaving itself.
I think i speak for everyone here and everyone else that’ll stumble on this thread looking for a fix. Thank you!!
I’ve been researching and playing around more and more with qmk and just to be clear you set the DEBOUNCE at 5 and the wait_us delay to 20?
Wouldn't you know it, after posting this I got the first doubling of the day. Odd. The rainbow stays just ahead of me...upped wait_us to 30 microseconds.
DEBOUNCE is 5 by default. Mine is currently at 10, but once I get wait_us perfect I may try lowering it again. wait_us is 1 by default, I started by changing it to 20. Both of those were skitz's recommendations. Keep in mind I forked massdrop's fork, not the base qmk repo.
I'd say the repeats were cut by half with the code from the massdrop configurator, and by about a factor of 10 each by changing DEBOUNCE from 5 to 10 and wait_us from 1 to 20. At that point I only saw a few repeats per day. Now I'm at wait_us==30 pursuing no repeats at all.
hmm.. and you're not noticing any missed keys?
debounce sounds pretty self explanatory, but what does "wait_us" control?
No missed keys at all, as far as I can tell. It seems that people were more worried about dropped keys if DEBOUNCE were increased than wait_us, which makes some kind of sense given that DEBOUNCE is in milliseconds and wait_us in microseconds. That's why, once I am satisfied that wait_us is dialed in, I may try reducing DEBOUNCE again.
wait_us seems to just be a pause, it's where it is called that determines what it does. From criminally cursory glances over the code, wait_us seems to be used for a per-column pause during the scan over the key columns, while DEBOUNCE probably controls how long some sort of debounce algorithm averages (or something) over. I don't really know, I'm cargo-culting skitz's suggestions.
Totally! i feel so dumb. Thanks for the reminder!
I've been testing this firmware all morning and I haven't had any keychatter at all yet. Only issue seems to be that the fn+x hotkey to turn off all LEDs is missing :D
Thanks for the article, it was def a interesting read
Hm, interesting. The only change I made was to the delay and it should have all the latest updates. I think the online configurator might be adding those hotkeys by default. I guess just use Fn+Z in the meantime until the configurator gets updated.
I figured that was the issue. Anyways, thanks for hunting down the issue and fixing it.
That the ctrl configurator is adding in some extra hotkeys on its own.
Good to hear that 5/40 seems to be working for people. At wait_us == 30ms I couldn't detect any chatter, so I dropped DEBOUNCE back to default and am trying 5/30. It will be a while before I know because I'm on jury duty instead of spending hours a day at the keyboard, but if I see any I'll try raising wait_us further rather than fiddling with DEBOUNCE for a while. I really never saw the slightest issue with DEBOUNCE at 10, though.
I will probably also try the stock firmware just for comparison, because, well, if I didn't want to experiment I wouldn't have intentionally bought a qmk-based keyboard. :D
As an update, I took wait_us as high as 40 and I still got bounces with DEBOUNCE at 5. Not a lot of them, but noticeable. It's interesting that this worked for others but not for me--the easy guess is it's the halo switches. Has skytz' DEBOUNCE 5, wait_us 40 version completely worked for anyone with halo switches, or conversely has it not worked for anyone with non-halo switches?
I just bumped DEBOUNCE back to 10 and wait_us down to 35, which judging by past performance should completely eliminate the bounces. We'll see.
I can confirm that Skytz' solution has eliminated the bounce for me, but I'm running KBDFANS T1's (holy panda clones)
so it finally hit me after about 2 weekssss i somehow get random more s keypressssses than it should... and my keyboard ssstopped working completely until i resseated the cable.
@Dondragmer any chance you could make your 10/35 firmware available? I'd like to give it a go. I've gotten a few instances of keychatter today for the first time since flashing...
Sure, I guess I could stick it on a free download site somewhere. Give me a couple of days, though. I was on Jury duty for nearly two weeks and now I'm back to my long commute, trying to catch up at work.
thanks...i would also appreciate this. i've tried the firmwares above, but with varying degrees of success, and am still not there yet.
Applied the update and the chatter rate reduced to a single key. I swapped the switch with a lesser used key and everything seemed resolved until yesterday. Now my `w` key is chattering. Could there be a firmware issue AND bad switches?
Some of the switches are definitely exacerbating the issue. If you reach out via your transactions our support team can get you a few replacement switches as well.
Hello, I have a few switches still misbehaving too. I assume contacting support in the same manner is the correct approach?
Not sure about that. I've replaced all the switches on my keyboard (twice, now) and even after trying a few firmwares, I still have the same keys that commonly misbehave. L and the spacebar key. My next area to investigate is if the sip sockets are okay.
Our offer still stands. We'd love to get your keyboard into the office so we can do root cause analysis on it. We can get you a replacement keyboard which should be problem free.
I'd be interested, but only if another keyboard could be sent ahead of me sending the one in I have now. It's currently my only keyboard after moving some other machines out of the house.
You'd also be getting it with no switches in it...
Has anyone in this thread had any success with simply replacing the switches on the problem keys to get rid of the chatter?
Just as a heads up, I contacted support and they will not ship a replacement keyboard until they see movement on the return tracking. They will also not expedite any shipping of a replacement. They did offer to refund $20 on the keyboard if I opted not to sendd the keyboard back.
I figured as much. This is clearly not a problem they really want to fix.
And yet, they're still selling them...knowingly defective. I actually would love to see a drop admin comment on that. Massdrop why do you continue to sell products that come with known defects in them?
The smart money would be on freezing sales until you work out the problems your keyboard has had since it was launched OVER A YEAR AGO. I suspect this comment will go unanswered though, because admitting they know the items are defective sets them up for all kinds of action. Maybe freezing sales would actually motivate them to DO somthing. Funny how a bunch of regular users can release firmwares in a day after this is discovered, but massdrop is still dragging their heels "trying to identify the problem" (read, not actually doing anything except paying lip service).
This isn't some third party drop, either, this is a first party drop designed by massdrop. None of the regular massdrop excuses work here. They still can't even fix their OWN mistakes. There's a reason this was the last massdrop product I ever bought.
Massdrop = Garbage Merchants
What did you end up getting? Did it fix the keychatter issue?
Nope. Some of the firmwares above will help with the problem, but nothing completely fixes it.
Do you have any new updates on a possible fix? I'm already looking into a different keyboard if some solution isn't coming soon.
My replacement ctrl just arrived so I will be putting it through its paces the next few days to see if the key chatter issues persist in the replacement keyboard.
yah, got my replacement ctrl a week or so ago and seems fine. thing is, it took 6 months for the chattering to appear on my original ctrl...will it take that long to verify if the replacement ctrl has the same issue?
@YanboWu so, we're THREE months in from this post now, how about that "promising solution" you guys were (not actually) working on? Find it real strange that all these people have the same issue, but massdrop's "engineers" just can't seem to spot it!
Yeah it took quite a while for my chatter issues to crop up as well. If these issues reappear on the new keyboard, idk what I’ll do. Demand a refund I suppose. I don’t want to have to go through an endless cycle of returns and replacement keyboards.
Even better, looks like they've removed the conversations heading from the drop page to cover up all the negative press.
Hmmm not a good look for Drop.
I have the same issue @stepsten was having, but I AM hitting the reset button, and still get the same error of "Error: Could not find a valid device port".
I have also tried Fn + B, multiple ports, multiple cables, as well as both usb c ports on the ALT
Muffin did you ever find an answer to this? I'm having the same issue. tried different cables, different ports even different computers.
I am getting this problem and nothing has helped. Not different USB ports on my pc or the keyboard. Fn+B doesnt work, hard reset button on the back doesn't work. Just the same error over and over no matter what. All I'm trying to do is change the LED colors.
i figured it out. and by "I" i mean the guys in the qmk discord figured it out. its an issue with mdloader. The new CTRL i got apparently has a different chip and therefore the chip id had to be updated in the code. info here: https://github.com/Massdrop/mdloader/issues/24 sorry i tried to go back and update everywhere i looked for help but forgot this post
FYI, this fix was not applied to boards that were shipped June 2020 either. I had the double typing issue as well on my Drop Alt keyboard and I applied this fix and so far it has been working (I just applied the fix 30 mins ago) so I will keep you posted.
FYI my key chatter has returned on the new keyboard. The "t" and "0" keys are almost to the point of being unusable. The "0" key has even registered as many as 5 times with a single key press and as little as zero times on 6 key presses. Will try cleaning the switches to see if that helps as the keyboard was sitting unused at work for the past 6 months due to quarantine. It was working flawlessly prior to Covid. @PigmonkeY
I just realized that the QMK repo code is not up to date with the massdrop forked code, and I think the qmk base essentially does no debouncing. Increasing the `wait_us` probably helps to do a sort of debouncing, and I wonder if if makes the upper rows chatter more because they are waiting less in that loop. I'm putting this here in case anyone is making edits to the master QMK firmware to fix their debouncing issues, you should use the massdrop firmware instead. (To be clear, YanboWu has always indicated to use the massdrop fork and their released versions).
Two other things I'm wondering:
- Is there any thought to getting the QMK repo updated with the latest massdrop code (or update the massdrop fork with the latest QMK?) I'm pretty new, so I don't know if there's anything that's updated that's better in the QMK repo, but would be nice to know it's up to date.
- The debounce algorithm used looks essentially the same as the default one provided in the QMK firmware, the sym_defer_g: https://beta.docs.qmk.fm/using-qmk/software-features/feature_debounce_type#selecting-an-included-debouncing-method. Is there any reason not to use that one?