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.Augusto.Berg wrote: ↑Tue Nov 06, 2018 11:05 amI bought one that is on the way and now I'm really worried about this "bug"
Waiting for news...
Keyboard debouncing
-
- Posts: 137
- Joined: Wed Jun 14, 2017 9:27 pm
Re: Keyboard debouncing
Re: Keyboard debouncing
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.
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
Re: Keyboard debouncing
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:
- 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.
- 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.
- 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.
So keep it warm...
Re: Keyboard debouncing
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.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
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.
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.
Re: Keyboard debouncing
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.Jaymos wrote: ↑Tue Feb 05, 2019 1:11 pmNo, 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.
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
41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot
Casio, Rockwell 18R
Re: Keyboard debouncing
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.
-
- Posts: 1107
- Joined: Tue May 02, 2017 5:48 pm
- Location: Netherlands
- Contact:
Re: Keyboard debouncing
X<>Y does not affect LASTX
Re: Keyboard debouncing
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
41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot
Casio, Rockwell 18R
Re: Keyboard debouncing
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.cdmackay wrote: ↑Wed Feb 06, 2019 12:49 amI 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]
--bob p
DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Re: Keyboard debouncing
Correct, and that's the main reason why we should avoid this and show them the light.
Greetings,
Massimo
ajcaton
-+×÷ left is right and right is wrong Casted in gold
Massimo
ajcaton
-+×÷ left is right and right is wrong Casted in gold