F77 help with Num7 not registering

tfossor

29 Sep 2021, 19:54

Dear Deskthority,

Just got a new F77. Had to reseat the springs on a few keys to get them working (Esc, spacebar, Num8), but can't for the life of me get Num7 to work.

This despite following the instructions for reseating the spring (12 o'clock spring end, replacing key in vertical spacebar up position), even changing the spring a few times.
When the spring is in place on the flipper peg, it seems to be a bit more stiffly placed in that when turning keyboard vertical spacebar up, the spring doesn't flop very well onto the barrel edge, no matter how i manipulate the spring.] Not only is the keypress not registering, but there is no audible distinctive barrel-spring click.

Manually moving the spring with the key removed to make contact with the barrel does NOT trigger a keypress.
But using the pandrew utility's Signal Level Monitor to check demonstrates a DROP from baseline Signal Level of 136 DOWN to a Lowest Signal Level of 126 with manual manipulation of the spring to touch the barrel.
Note the OTHER keys on the keypad, which are working without problems, have a baseline signal level of 134-136, but on keypress go to the 170s to 200s.

I'm not sure what to do next.

Any advice?
Attachments
postkeypress.jpg
postkeypress.jpg (139.56 KiB) Viewed 2282 times

User avatar
Muirium
µ

29 Sep 2021, 22:10

Something is physically wrong with that flipper. Sounds like one that should have failed quality check.

You’re right that moving the flipper yourself should have as much effect as triggering the other keys.

tfossor

30 Sep 2021, 16:22

So is the next step unscrewing the keyboard and replacing the plastic flipper/spring assembly? (Uncharted waters for me, but will try if necessary)

User avatar
timw4mail

30 Sep 2021, 16:42

I had one stubborn spring in my F77 that I managed to fix by removing about two coils, but that spring seemed longer that the others (as though it was stretched). I also had to fiddle with the spacebar stabilizer to get it not to stick, but I'm not ultimately sure how I fixed that.

As great as the Buckling Springs mechanism is, for better or worse it is finicky, and that really shows in shipping.

Unfortunately, it does sound like you might need to actually disassemble the keyboard.

User avatar
Muirium
µ

30 Sep 2021, 20:04

Look on the bright side: it’s an F. At least going inside doesn’t involve a one way process of snapping plastic rivets! (Gross.)

Do these come with spare flippers? IBM originals don’t!

User avatar
timw4mail

30 Sep 2021, 20:08

Muirium wrote:
30 Sep 2021, 20:04
Look on the bright side: it’s an F. At least going inside doesn’t involve a one way process of snapping plastic rivets! (Gross.)

Do these come with spare flippers? IBM originals don’t!
No, but you can get a repair kit from the same place. First I would check to make sure the flipper hasn't just fallen off the spring.

tfossor

30 Sep 2021, 23:35

I have spare flippers! And I'm 100% sure that the spring has NOT fallen off the flipper (I've gotten pretty good at securing the spring to the flipper at this point as I've tried multiple spring reseatings in vain attempts to get Num7 working).

I think this is what I'm going to have to do:
https://www.youtube.com/watch?v=xaa23N9JDBs&t=55s
Ugh. Not trusting my plierwork.

Ellipse

08 Oct 2021, 04:03

How's your progress tfossor? My guess is that the flipper got stuck in the barrel when the keyboard was bounced around by the shipping carrier - I've seen a few examples of this - yep you would have to open up the inner assembly sandwich to loosen the flipper.

Then I would physically place a different flipper on the exposed PCB as shown in one of the project videos (while the pandrew utility is open) to see if it registers. Maybe some debris got in there below the flipper.

Sometimes a keyboard with even one key improperly installed messes up with the autocalibration of a particular row or column when the keyboard is powered on. Or maybe it could use a little touch up of the soldering of that row and matrix. As a note the factory tested every key and I also retest every key to make sure it registers and turns green, but these keyboards do get bounced around in shipping which can't be avoided these days.

tfossor

20 Oct 2021, 03:34

Sorry for the late response! I was out of town and just got back.
I haven't performed surgery yet on the keyboard, and will likely give it a shot this weekend (and will post results here).

But I appreciate any advice I can get beforehand, so thank you, Ellipse!

tfossor

23 Oct 2021, 21:00

F77 Num7 repair.jpg
F77 Num7 repair.jpg (448.91 KiB) Viewed 1690 times
Finished opening the F77.

Biggest challenge was on closing back up, getting the metal tabs to properly close the keyboard. If I had to do it over, I would have bent the tabs a tiny bit away from the metal plates on the antispacebar side when resliding the metal plate under the tabs on the spacebar side. They were getting in the way, resulting in me applying too much force trying to slide the plate under, causing a slight bend in the corner of the plate (easily straightened out).

Anyhow, found that the plastic flipper was a tiny, tiny, bit skewed such that it was frozen against the black plastic collar that surrounds the flippers. It was easily removed and replaced with the keyboard open. Visibly, no obvious problems on the flipper itself. But didn't want to take the chance so simply put in a replacement. On above image, the flipper in question is at the end of the hemostat.

Now, all is good and I am happily typing, using more words than necessary to complete this post!

tfossor

31 Oct 2021, 07:07

Enjoying the F77. But one bit of strangeness remains.

Using the QMK Configurator, for some reason the BACKSLASH key will not accept reprogramming in the first layer. I haven't tried to reprogram it in the zero layer from BACKSLASH output nor on the second layer. But though the QMK Configurator>pandrew>AtmelFlip sequence works with creating a hex file, clearing the EEPROM, reloading the new hex file for any other key, the BACKSLASH won't output on layer one. Just the proper BACKSLASH output on layer ZERO. Weird.

User avatar
Muirium
µ

31 Oct 2021, 10:50

Show screenshots of the layers. Something will be amiss.

You should see most keys in Layer 1 set to "transparent", which means they simply do the same thing as down on Layer 0. I believe technically this is "KC_TRNS" and you can assign it to keys using the Quantum tab of the QMK web configurator.

Confusingly, it's actually displayed as a down pointing triangle. For instance, here on my µ3276 beamspring layout:

Screenshot 2021-10-31 at 2.22.36 pm.jpg
Screenshot 2021-10-31 at 2.22.36 pm.jpg (233.79 KiB) Viewed 1533 times
All keys on Layer 0 have values. But other layers are mostly transparent.

tfossor

01 Nov 2021, 05:31

f77crop.jpg
f77crop.jpg (4.23 MiB) Viewed 1519 times
Even with layer 1 of the backslash set to transparent, the keypress still does not register at all any acknowledgement by the QMK Configurator "TEST KEYBOARD" function. All other keys work. Backslash works fine both in the wild and under "TEST KEYBOARD" function of QMK Configurator under Layer 0.

Note my F77 is ANSI Split Right Shift with 2u Backspace but with Vertical/ISO Enter key (in fact in the pic of the faulty flipper above, you can see the vertical stabilizer for the ISO Enter). I am using the base file "zF77_-_HHKB_Split_Shift,_everything_else_ANSI_-_0-9.json" to configure, minimally modified.

Hope the image is clear enough...

User avatar
Muirium
µ

01 Nov 2021, 12:42

So, the last pic is your actual keyboard? ANSI with ISO Return?

That big ISO Return key occupies two barrels and their sensor pads, but only triggers one of them. If you pull it off, you'll find a plastic stabiliser leg under one of the positions. All larger modifier keys (>1.5u) are like that on IBM Model F and Model M: they sit above multiple "switches" but only ever activate one of those.

So which key do you mean by backslash?

The physical \ key on your keyboard is the one above Right Shift. You've got that set to ISO # on Layer 0 and nothing at all on Layer 1.

The logical \ keys you've defined on your layout are actually underneath the Return key and the Left Shift key. Those may well never be pressed at all, because that's where the stabilisers live. Pull those two caps off and you should see they have a plastic leg there.

Have you put flippers under both barrels of those two keys? That shouldn't work, surely not reliably. The cap's plastic stabiliser is meant to slide in and out of a "stabilizer insert" which you put into the barrel instead of a flipper. Those are white or black plastic cylinders you should have been supplied with (though I've never bought from Ellipse so I don't know if he expects you to order them separately).

tfossor

01 Nov 2021, 22:07

Yes, the last photo is the ACTUAL keyboard with ISO return, and hence occupies two barrels (the vertical stabilizer barrel for the bottom peg on the underside of the ISO return key is visible on my photo of the black flippers incidentally, with the position upsidedown relative to the keyboard and the hemostate on the Num7), so only the bottommost switch is activated as you described.

As per the picture, there are NOT flippers under both barrels of the two keys corresponding to the ISO Enter, just the bottom key has a flipper. The stabilizer is on the top key (black). The photo with the flippers on it is upsidedown, so the hemostat is on the Num7 for orientation's sake.

Thank you for your help though! I had assumed the QMK graphic of the backslash corresponded with my physical backslash key. And your suspicions were correct: they don't. Tested by altering the ISO# on Layer 0 key on the QMK graphic confirmed that that is what I SHOULD have been working with to program my PHYSICALLY LABELLED backslash. So I guess the QMK graphic backslash corresponds to my unused upper ISO Enter switch.

Thanks for the help!

All is working and I actually learned a thing or two.

Post Reply

Return to “Keyboards”