Showing 1 of 1633 conversations about:
YanboWu
8010
Collaborations
Aug 6, 2019
bookmark_border
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!
(Edited)
Aug 6, 2019
Mattington
51
Aug 8, 2019
bookmark_border
Would this issue and fix also apply to high profile ctrl's?
Aug 8, 2019
PandaSPUR
232
Aug 8, 2019
bookmark_border
Seems to be working so far... finally a fix. thanks!
Aug 8, 2019
YanboWu
8010
Collaborations
Aug 8, 2019
bookmark_border
Yep! They all run off the same PCB / firmware.
Aug 8, 2019
saintsummoner
0
Aug 11, 2019
bookmark_border
Would this fix be automatically applied to the boards being shipped out ETA August 12?
Aug 11, 2019
stepsten
38
Aug 12, 2019
bookmark_border
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?
Aug 12, 2019
YanboWu
8010
Collaborations
Aug 13, 2019
bookmark_border
@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.
Aug 13, 2019
saintsummoner
0
Aug 13, 2019
bookmark_border
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.
Aug 13, 2019
Haulien
384
Aug 13, 2019
bookmark_border
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.
Aug 13, 2019
stepsten
38
Aug 13, 2019
bookmark_border
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.
Aug 13, 2019
PigmonkeY
1056
Aug 14, 2019
bookmark_border
I flashed today. No change. Tons of keychatter. Problem unsolved.
(Edited)
Aug 14, 2019
bilsch
6
Aug 14, 2019
bookmark_border
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.
Aug 14, 2019
YanboWu
8010
Collaborations
Aug 14, 2019
bookmark_border
@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?
Aug 14, 2019
PigmonkeY
1056
Aug 14, 2019
bookmark_border
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.
(Edited)
Aug 14, 2019
skytz
45
Aug 14, 2019
bookmark_border
If people are still having keychatter issues, have your developers increase the "DEBOUNCE" value in config.h. https://github.com/Massdrop/qmk_firmware/blob/8b5e4959a01441c9c2cf718b725b18ecbf4d046f/keyboards/massdrop/ctrl/config.h#L95 Good luck! :)
(Edited)
Aug 14, 2019
skytz
45
Aug 14, 2019
bookmark_border
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.
Aug 14, 2019
bilsch
6
Aug 14, 2019
bookmark_border
Awesome thanks! I figured it would be something along these lines
Aug 14, 2019
YanboWu
8010
Collaborations
Aug 14, 2019
bookmark_border
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.
Aug 14, 2019
jxliu
985
Engineer
Aug 14, 2019
bookmark_border
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.
Aug 14, 2019
PigmonkeY
1056
Aug 14, 2019
bookmark_border
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?
(Edited)
Aug 14, 2019
skytz
45
Aug 15, 2019
bookmark_border
Yeah, it would require some trial and error, but it's an option to look into if users are still experiencing issues. You'd need to find a value large enough that keychatter does not occur, but small enough such that inputs are not dropped. One other suggestion I'd make is to change a line here: https://github.com/Massdrop/qmk_firmware/blob/8b5e4959a01441c9c2cf718b725b18ecbf4d046f/keyboards/massdrop/ctrl/matrix.c#L101 Currently a delay of 1 microsecond is set, but I think changing it to 20 may actually do the trick. The Preonic firmware is using a delay of 20 as well. https://github.com/qmk/qmk_firmware/blob/master/keyboards/preonic/rev3/matrix.c#L118
(Edited)
Aug 15, 2019
jxliu
985
Engineer
Aug 15, 2019
bookmark_border
Yeah, when you flash the keyboard, the firmware is saved to non-volatile memory. Just to be clear, the configurator you went to is https://drop.com/mechanical-keyboards/configurator , right?
Aug 15, 2019
PigmonkeY
1056
Aug 15, 2019
bookmark_border
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.)
Aug 15, 2019
Haulien
384
Aug 15, 2019
bookmark_border
Few days update for me since re-flashing, the update seems to have fixed it for me.
Aug 15, 2019
YanboWu
8010
Collaborations
Aug 16, 2019
bookmark_border
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.
Aug 16, 2019
timesscar
5
Aug 17, 2019
bookmark_border
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?
Aug 17, 2019
bilsch
6
Aug 18, 2019
bookmark_border
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 ;)
Aug 18, 2019
Dondragmer
12
Aug 19, 2019
bookmark_border
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.
Aug 19, 2019
Sh4kki
0
Aug 19, 2019
bookmark_border
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. any suggestions?
Aug 19, 2019
jxliu
985
Engineer
Aug 19, 2019
bookmark_border
Sounds like you did not download samd51j18a.bin or did not put that in the same directory as mdloader. See instructions: https://github.com/Massdrop/mdloader/releases/tag/1.0.3
Aug 19, 2019
skytz
45
Aug 19, 2019
bookmark_border
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.
(Edited)
Aug 19, 2019
Dondragmer
12
Aug 20, 2019
bookmark_border
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.
Aug 20, 2019
skytz
45
Aug 20, 2019
bookmark_border
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.
Aug 20, 2019
Dondragmer
12
Aug 20, 2019
bookmark_border
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.
Aug 20, 2019
Dondragmer
12
Aug 20, 2019
bookmark_border
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?
Aug 20, 2019
skytz
45
Aug 20, 2019
bookmark_border
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. :/
Aug 20, 2019
Dondragmer
12
Aug 20, 2019
bookmark_border
  1. OK. Maybe I'll concentrate on wait_us for now.
  2. 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).
  3. 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. :-)
Aug 20, 2019
PigmonkeY
1056
Aug 20, 2019
bookmark_border
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.
Aug 20, 2019
FishHolic
25
Aug 20, 2019
bookmark_border
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.
Aug 20, 2019
Kinkajou
2
Aug 20, 2019
bookmark_border
plz save us
Aug 20, 2019
skytz
45
Aug 21, 2019
bookmark_border
Aug 21, 2019
Dondragmer
12
Aug 21, 2019
bookmark_border
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.
(Edited)
Aug 21, 2019
FishHolic
25
Aug 21, 2019
bookmark_border
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?
Aug 21, 2019
Dondragmer
12
Aug 21, 2019
bookmark_border
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.
Aug 21, 2019
Dondragmer
12
Aug 21, 2019
bookmark_border
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.
(Edited)
Aug 21, 2019
FishHolic
25
Aug 21, 2019
bookmark_border
hmm.. and you're not noticing any missed keys? debounce sounds pretty self explanatory, but what does "wait_us" control?
Aug 21, 2019
Dondragmer
12
Aug 21, 2019
bookmark_border
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.
(Edited)
Aug 21, 2019
Sh4kki
0
Aug 21, 2019
bookmark_border
Totally! i feel so dumb. Thanks for the reminder!
Aug 21, 2019
skytz
45
Aug 21, 2019
bookmark_border
No problem! The one I uploaded has DEBOUNCE at 5 and the wait_us delay at 40. There's a good explanation on what bouncing/debouncing is here: https://www.allaboutcircuits.com/technical-articles/switch-bounce-how-to-deal-with-it/ Also, the wait_us delay is added because it takes some time for the input/output pins of a microcontroller to switch on and off. So it ensures that the pin states are correctly being read.
(Edited)
Aug 21, 2019
PigmonkeY
1056
Aug 21, 2019
bookmark_border
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
Aug 21, 2019
FishHolic
25
Aug 21, 2019
bookmark_border
Thanks for the article, it was def a interesting read
Aug 21, 2019
skytz
45
Aug 22, 2019
bookmark_border
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.
Aug 22, 2019
PigmonkeY
1056
Aug 22, 2019
bookmark_border
I figured that was the issue. Anyways, thanks for hunting down the issue and fixing it.
Aug 22, 2019
FishHolic
25
Aug 23, 2019
bookmark_border
What was the issue?
Aug 23, 2019
PigmonkeY
1056
Aug 23, 2019
bookmark_border
That the ctrl configurator is adding in some extra hotkeys on its own.
Aug 23, 2019
Dondragmer
12
Aug 24, 2019
bookmark_border
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
Aug 24, 2019
Dondragmer
12
Aug 28, 2019
bookmark_border
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.
(Edited)
Aug 28, 2019
PigmonkeY
1056
Aug 28, 2019
bookmark_border
I can confirm that Skytz' solution has eliminated the bounce for me, but I'm running KBDFANS T1's (holy panda clones)
Aug 28, 2019
Sh4kki
0
Aug 30, 2019
bookmark_border
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.
Aug 30, 2019
PigmonkeY
1056
Aug 31, 2019
bookmark_border
@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...
(Edited)
Aug 31, 2019
Dondragmer
12
Sep 5, 2019
bookmark_border
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.
Sep 5, 2019
stepsten
38
Sep 9, 2019
bookmark_border
thanks...i would also appreciate this. i've tried the firmwares above, but with varying degrees of success, and am still not there yet.
Sep 9, 2019
RottenSushi
2
Sep 10, 2019
bookmark_border
I have applied the firmware update by reflashing the CTRL with the online configuratorr (https://drop.com/mechanical-keyboards/configurator) and still am getting some chatter. Specifically on the d and r keys.
Sep 10, 2019
delianides
17
Sep 12, 2019
bookmark_border
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?
Sep 12, 2019
YanboWu
8010
Collaborations
Sep 12, 2019
bookmark_border
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. @delianides @RottenSushi
Sep 12, 2019
timesscar
5
Sep 12, 2019
bookmark_border
Hello, I have a few switches still misbehaving too. I assume contacting support in the same manner is the correct approach?
Sep 12, 2019
PigmonkeY
1056
Sep 15, 2019
bookmark_border
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.
Sep 15, 2019
YanboWu
8010
Collaborations
Sep 16, 2019
bookmark_border
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.
Sep 16, 2019
PigmonkeY
1056
Sep 16, 2019
bookmark_border
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...
Sep 16, 2019
RottenSushi
2
Sep 17, 2019
bookmark_border
Has anyone in this thread had any success with simply replacing the switches on the problem keys to get rid of the chatter?
Sep 17, 2019
RottenSushi
2
Sep 17, 2019
bookmark_border
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.
Sep 17, 2019
PigmonkeY
1056
Sep 18, 2019
bookmark_border
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
(Edited)
Sep 18, 2019
Valarri
2
Sep 22, 2019
bookmark_border
What did you end up getting? Did it fix the keychatter issue?
Sep 22, 2019
PigmonkeY
1056
Sep 22, 2019
bookmark_border
Nope. Some of the firmwares above will help with the problem, but nothing completely fixes it.
Sep 22, 2019
delianides
17
Oct 2, 2019
bookmark_border
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.
(Edited)
Oct 2, 2019
RottenSushi
2
Oct 30, 2019
bookmark_border
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.
Oct 30, 2019
stepsten
38
Nov 1, 2019
bookmark_border
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?
Nov 1, 2019
PigmonkeY
1056
Nov 4, 2019
bookmark_border
@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!
(Edited)
Nov 4, 2019
RottenSushi
2
Nov 6, 2019
bookmark_border
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.
Nov 6, 2019
PigmonkeY
1056
Nov 6, 2019
bookmark_border
Even better, looks like they've removed the conversations heading from the drop page to cover up all the negative press.
(Edited)
Nov 6, 2019
RottenSushi
2
Nov 6, 2019
bookmark_border
Hmmm not a good look for Drop.
Nov 6, 2019
muffin860
12
Feb 14, 2020
bookmark_border
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
Feb 14, 2020
marcw
25
Jul 2, 2020
bookmark_border
Muffin did you ever find an answer to this? I'm having the same issue. tried different cables, different ports even different computers.
Jul 2, 2020
jbuckz
0
Jul 8, 2020
bookmark_border
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.
Jul 8, 2020
jbuckz
0
Jul 8, 2020
bookmark_border
also @muffin860 @marcw what happened with your boards?
Jul 8, 2020
marcw
25
Jul 9, 2020
bookmark_border
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
Jul 9, 2020
ascebba
1
Jul 16, 2020
bookmark_border
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. Thank you!
Jul 16, 2020
Ctrlfrk
1
Sep 8, 2020
bookmark_border
I compiled with the 10/35 config as mentioned previously in this thread and from what I can tell it solves the issue completely for me. I'm able to hit ~100wpm on typing tests with no chatter. Obviously more testing is needed, but if you don't feel like compiling and want to try it out I uploaded my build artifact. https://cdn.discordapp.com/attachments/673412703192350723/752993218127462770/massdrop_ctrl_10-35.bin

(Edited)
Sep 8, 2020
RottenSushi
2
Sep 11, 2020
bookmark_border
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
(Edited)
Sep 11, 2020
Ronnie76er
4
Nov 20, 2020
bookmark_border
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:
  1. 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.
  2. 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?
Nov 20, 2020
View Full Discussion