Keyboard debouncing

If you're having problems with the hardware of a DM41X or DM42, post about them here.
Dave Britten
Posts: 137
Joined: Wed Jun 14, 2017 9:27 pm

Re: Keyboard debouncing

Post by Dave Britten »

Augusto.Berg wrote:
Tue Nov 06, 2018 11:05 am
I bought one that is on the way and now I'm really worried about this "bug" :shock:

Waiting for news... :|
I wouldn't lose too much sleep over it. It's a very minor thing, and I think it was more common with some of the early production models like mine. I've cleaned the keys out, and it's pretty rare now, usually only affecting Shift or the arrow keys. It's just a bit annoying when it happens, because it seems like something that could be very easily fixed in software with only about 5-10 ms of debounce lockout.
tycho
Posts: 35
Joined: Sun Nov 05, 2017 4:09 pm
Location: Norway

Re: Keyboard debouncing

Post by tycho »

I think we should still keep this topic warm, because the problem remains for me on some number keys, although rarely. I have sample SN: 356.

I recently updated the FW straight from 3.5 to 3.12, and I noticed it more often - although I also did the "key softening" routine and use the calculator more. The "Slow auto repeat" seems to have no effect, i.e. not slower auto repeat, and not shorter delay before repeat, which is too short (and sometimes causes unwanted debouncing itself).

Maybe a coincident, but lately I have seen the debouncing problem ONLY with "Slow auto repeat" ON!
Please make the "Slow auto repeat" actually have an effect, and increase the delay before repeat.

Related: Why is the auto repeat so slow in menus? Here it would be nice to have more speed.
"The Answer to the Great Question... Of Life, the Universe and Everything... Is... DM42" ― Adam Douglas
boessu
Posts: 22
Joined: Mon Jan 28, 2019 10:40 pm

Re: Keyboard debouncing

Post by boessu »

tycho wrote:
Mon Feb 04, 2019 12:01 pm
I think we should still keep this topic warm, because the problem remains for me on some number keys, although rarely. I have sample SN: 356.
I think the topic is still warm.
I have SN:03279. I got it last week and I noted also this kind of problems after using it a bit. First I had the problem that sometimes a key won't be registered. But that's maybe also a "stiffy"-problem. The key domes have some hub and if you feel a "click", you feel the small spring dome and not the contact you expect. If the keys are a bit stiffer, a "click" doesn't mean it results in a contact if you press with a comfortable force (sounds a bit silly, but that's possible).

But on the beginning, the "-" was simply unusable as it flippered the number in sign. I also have the problems on some numbers like you. Sometimes I have it more, sometimes I have it less. That really points on debouncing.

There are basically three possibilities for me:
  1. The software has a debouncing problem. Software can be easily fixed... however I didn't saw any debouncing code on github. Maybe I just didn't found it... Hopefully it is in the part of the firmware you can easily update.
  2. There is a hardware problem. I hope that's not the case here, but... I noted the PCB isn't fixed like the HP's are (or other keyboard in phones I'm personally know of from the past...). The HP's pressed the board on the keys and melted the tips of the plastic to fix them. This is not really an elegant way and I wouldn't do that, but that worked. The DM42 is just fixed with the flat screws below the display and with hooks on the bottom. I would expect a few more screws or something in-between (The more "high quality" way I know is to fix it with a few screws, of course). Maybe that's not a issue as the PCB seems rather high quality and thick. But as it seems the problem happens often somewhere around the numbers, it could be a stability problem of the PCB. The keys in the middle area would get a bigger debouncing problem then. I didn't noted the problem on the topper level where the screws are... Even if this is the case: it's possible that this results in heavier debouncing which can be fixed with software. At least there is a chance.
  3. I got the lucky punch and they sent me a device which was returned from another customer without reason. I noted some older customers here in this forum have a bigger S/N than I. That would be a bit of a bummer... But anyhow the effect is only noticeable if you really use the calculator. So a 5-minute-function-test wouldn't fail and if that would be the case, it's easily understandable why SwissMicros didn't found a problem in the device.
Beside of some notes here, I really don't think this is a problem of a small batch. The switches make a high quality impression on me. I simply don't believe the switches (that much of them, all somewhere in the number areas) are really the problem. Since you've also noticed that in the number area like I, it is far more feasible that is somewhere on 2.). But this also means there is the chance that it can be fixed by software.

So keep it warm...
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: Keyboard debouncing

Post by Jaymos »

StreakyCobra wrote:
Tue Oct 16, 2018 3:59 pm

I often find myself typing numbers at the same time that I'm thinking of a problem...

Maybe I'm doing something wrong and I'm the only one to have this problem with "enter", but for this use at least "exit" is changing my life right know :-)
No, you are not alone. Since discovery in this thread of EXIT entering a number into x only, this is becoming a pleasant habit. I think you described the thought process well for my mind too. Maybe I used the 28C too much long time ago, and this method positively gets the number into x only and allows my focus on the problem instead of on the stack duplication.

More proof that you are not alone, is that the iOS ‘42s’ Free42 implementation by Byron Foster of a few years back has a ‘no ENTER stack lift’ option, which I set years ago already. This is my goto Free42 implementation on iOS. On the hardware 42S and DM42 this is now done with EXIT.
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
cdmackay
Posts: 281
Joined: Fri Oct 05, 2018 8:33 pm
Location: Cambridge, UK
Contact:

Re: Keyboard debouncing

Post by cdmackay »

Jaymos wrote:
Tue Feb 05, 2019 1:11 pm
No, you are not alone. Since discovery in this thread of EXIT entering a number into x only, this is becoming a pleasant habit. I think you described the thought process well for my mind too. Maybe I used the 28C too much long time ago, and this method positively gets the number into x only and allows my focus on the problem instead of on the stack duplication.
I may be missing the point, but an alternative might be to get out of the habit of pressing ENTER immediately after typing a number, and instead only use it before typing a second number.

And if you don't need to input any more numbers, you then immediately press the operator etc key you need without pressing ENTER for the last number input.
Cambridge, UK
41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot
Casio, Rockwell 18R
User avatar
ijabbott
Posts: 253
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

Re: Keyboard debouncing

Post by ijabbott »

There are definitely places where the habit of using EXIT to enter a number can bite you as it has side effects. A safer habit is to press X<>Y twice, as that won't have the side effect of exiting menus, although it does have the side effect of setting LASTx to the number you just entered. Another option is SHIFT SHOW, but that is harder to type.
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Keyboard debouncing

Post by Thomas Okken »

X<>Y does not affect LASTX
cdmackay
Posts: 281
Joined: Fri Oct 05, 2018 8:33 pm
Location: Cambridge, UK
Contact:

Re: Keyboard debouncing

Post by cdmackay »

ijabbott wrote:
Tue Feb 05, 2019 6:59 pm
There are definitely places where the habit of using EXIT to enter a number can bite you as it has side effects. A safer habit is to press X<>Y twice
I don't quite get what people are trying to achieve here, would you please explain?

i.e. what state is different after pressing X<>Y twice, compared to not pressing it at all?

I can see that we're no longer editing the line, the trailing edit cursor goes, but what else does that affect? What else is different? How is it useful?

[not trying to be clever, just trying to understand the point]
Cambridge, UK
41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot
Casio, Rockwell 18R
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Keyboard debouncing

Post by rprosperi »

cdmackay wrote:
Wed Feb 06, 2019 12:49 am
ijabbott wrote:
Tue Feb 05, 2019 6:59 pm
There are definitely places where the habit of using EXIT to enter a number can bite you as it has side effects. A safer habit is to press X<>Y twice
I don't quite get what people are trying to achieve here, would you please explain?

i.e. what state is different after pressing X<>Y twice, compared to not pressing it at all?

I can see that we're no longer editing the line, the trailing edit cursor goes, but what else does that affect? What else is different? How is it useful?

[not trying to be clever, just trying to understand the point]
I'm not 100% why folks are advocating these alternates (there seem to be multiple points being made) but the main difference is that [Enter] disables stack-lift, so the next thing entered replaces X without pushing the stack up, while the other methods terminate entry with stack lift enabled. To me, there are corner cases where this can make a difference, but typically it's not important. The usual reason folks pursue this is if they learned RPL before RPN, where all terminated entries always enable stack lift. These tricks better simulate the behavior of RPL.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
User avatar
akaTB
Posts: 794
Joined: Tue May 02, 2017 1:56 pm
Location: Milan, Italy

Re: Keyboard debouncing

Post by akaTB »

rprosperi wrote:
Wed Feb 06, 2019 3:47 am

The usual reason folks pursue this is if they learned RPL before RPN, where all terminated entries always enable stack lift. These tricks better simulate the behavior of RPL.
Correct, and that's the main reason why we should avoid this and show them the light. :lol:
Greetings,
    Massimo
ajcaton
-+×÷ left is right and right is wrong :twisted: Casted in gold
Post Reply