F104+SSK+122+62+77+50+Ergo orders now open! New Kishsaver+Industrial Model F Keyboards

[NathanA]

seriously looks like your RP3 and RP4 are 10-pin while PCB is made for 8-pin ones.

I would never have spotted that with my eyes in those pics. I think you've nailed it.

[...] or they thought they could get away with using the 5 array and they might have been able to if they'd have gotten the spacing right.

I suspect your former theory of honest mix-up / wrong component on pick-and-place is more likely. If it were a 10-pin part, would it not be more likely to be a bussed resistor pack instead of the isolated type (a bunch of resistors "concatenated" together) that is spec'd for RP3 and RP4? If so, then there's no way this would've worked even if they had managed to line up 8 out of 10 pins every time...right?

Are there any plans to upstream this work to the QMK project?

Sure. Once the code has been refactored to meet the QMK project's standards so that they'll accept it. You volunteering?

If you want to use a different QMK base version, you can "graft" the keyboards/xwhatsit directory into your own build tree & then just browbeat it until it builds without errors (there's really only 1 or 2 minor adjustments you have to make to get it to compile with current QMK 'master' branch...details are provided earlier in this thread).

As an alternative, I use NathanA's Vial build, and I'm very happy with it. He provided all the details to build it yourself a few pages ago.

Do note that my very primitive build script assumes you already have a working QMK build environment (incl. avr-gcc cross-compiler) set up. It also does git clones of both the pandrew repository as well as the QMK (well, Vial one in my case...) repository up on Github, performs the merge, and then throws a couple of extra patches in to help smooth out the build process as well as adjust the settings "to taste". Since it pulls directly from pandrew's repository, I'd discourage people from directly running the script too many times...it's more of a guide or "reference" as to how to do a successful build that will produce a known-working firmware. It also means that pandrew's repository is a dependency, and that if you are already having problems cloning it due to internet bandwidth/distance/server speed/whatever issues, this won't solve that problem for you.

I tried the configurator site at http://35.164.28.200:5000 but when I try to load the ANSI-HHKB-split_shift_split_backspace layout, none of the keys are mapped. I hand-edited the json and uploaded it until it looks correct but when I try to use the website to compile, I get an error.

I don't know why (haven't spent enough time with it, and have no desire to, really) but, yeah: the web QMK Configurator only has predefined key bindings for the LAYOUT_all definition. That said, no need to hand edit any JSON: just download the official firmware archive, extract it, and the JSONs for all of the various layouts are included in there. Upload the JSON corresponding with the layout of your choice to the web configurator, then edit to suit your needs.

[ghostbuster]

Thanks for the detailed replies everyone. Somehow when I ordered this keyboard I was under the mistaken assumption that it would be a complete, working product out of the box. Of course I don't expect volunteers to fix it for me; I was just hoping it was going to be working when I received it.

I'll probably take the grafting and brow-beating path. I haven't read all 7k+ posts in this thread but the sense I'm getting is that QMK, warts and all, is more stable than vial. I doubt I'd have time to do much refactoring to upstream the code but out of curiosity is there anywhere online that the QMK maintainers have discussed their reservations?

[flowchartsman]

For the LED overlay suggestions, I like the new ones but please let's stay to the original IBM LED hole locations for the designs. I'm open to moving the overlay but there would be a tooling charge of $100 to $200.

The IBM version is actually the first version I did. I have a few variants.


Without locks and a variant symbol for scroll lock:


Yet another symbol for scroll lock:

[flowchartsman]

I do think that the caps lock with the LED in the center of the padlock is the most awkward of the 3...looks a bit visually crowded, maybe? As I said, it's a hard problem to solve, and IBM did this to themselves...

Still, this is my favorite effort to-date that I've seen.

Might be a bit of an academic discussion for the ones Ellipse is thinking of making, but here's a unicomp version. They really make it hard by having the lights in weird positions like that.

[NathanA]

Somehow when I ordered this keyboard I was under the mistaken assumption that it would be a complete, working product out of the box.

I assume by "working" you mean that because you ordered the Mac keys, your preferred key bindings/layout would already be preprogrammed for you? (You didn't hint that anything was "broken" in your original post, thus why I ask.)

There's a long history to why things are the way that they are when it comes to the software side of things. The most well-known and widely-adopted third-party-developed capacitive sensing controller for IBM Model F keyboards was (and arguably remains) the Xwhatsit, which is an open design. The designer even wrote his own firmware for the controller. The New Model F project uses an Xwhatsit-derived controller design internally, and it was no secret that this was always going to be the case. So for anyone who knew what that was, they already knew roughly what to expect going into this, though admittedly this project clearly attracted a wide range of people, not all of whom could be expected to be intimately familiar with all of the different components or have had prior experience with installing or using an Xwhatsit controller with true-blue IBM hardware. Porting QMK to the Xwhatsit hardware was not part of the original plan at all, and the effort to do so did not get underway until Ellipse had already been shipping keyboards for a few months with the original Xwhatsit firmware preloaded on it. He eventually made the switch to factory-flashing the (still in beta) QMK port because it became fairly clear even early on that pandrew's rewritten-from-the-ground-up capsense implementation was superior. Other than Ellipse's hardware manufacturing efforts, much of the rest of this "ecosystem" is rather decentralized and has grown up organically around it over time as there has been need.

I haven't read all 7k+ posts in this thread but the sense I'm getting is that QMK, warts and all, is more stable than vial.

I would disagree. Most people here who use straight-up QMK rather than one with VIA or Vial sugar sprinkled on top seem to choose to do so because that's just what they are familiar with & prefer. It's also the firmware option that essentially has "first-party support" (such as it is) from Ellipse/modelfkeyboards.com

The beauty of course is that trying any firmware -- original Xwhatsit, various QMK builds, VIA, or Vial -- is just a controller reflash away, and these controllers are virtually impossible to permanently brick. So you've got nothing to lose by giving a few different firmwares a fair shake...

My own take is that if we want to get these keyboards to a place where they are -- as you put it -- a "working product out of the box", a firmware option that gives people a way to reconfigure it without having to break out a C compiler and re-flashing the whole thing every time is a prerequisite. Not everyone who bought or might be interested in buying one of these keyboards is going to want to do that (or is even familiar with C development at any level). This is why I'm as passionate about encouraging Vial adoption as I am. And I advocate for Vial vs. VIA because it's clearly superior in so many ways with (as far as I've been able to tell) zero downside: client-side is WAY less bloated (PyQT vs. Electron), client-side is also open-source where VIA is not, you can configure many QMK features with Vial that would otherwise require writing C code while VIA basically only lets you remap key bindings and write simple macros, etc.

[pandrew]

Are there any plans to upstream this work to the QMK project?

Yes. It will take time. I have zero time right now, but nothing is abandoned, I just don't have time to work on it due to life circumstances. No, it's not trivial. If it was only 8 hours of work, it would have been done a long time ago. It's more than that.

QMK maintainers have discussed their reservations?

I want to clarify, cause some of the discussions on this thread start sounding like QMK maintainers might have some unreasonable requirements. That is NOT the case. It is absolutely normal for there to be back-and-forth between someone wishing to contribute to an open source project and its maintainers. I haven't even officially started that process. I only asked around on the QMK discord, and the main two things I learned from those conversations was that they would prefer common capsense code as core feature (rather than in the keyboards/xwhatsit sub-tree), and that they don't want auto-bootloader-entry as a feature, because it's technically a security flaw. Even beyond these things I listed, there is a mountain of work that has to be done to make it ready, so there was no point in even trying to open a pull request, until the codebase is in a state that I'm comfortable trying to present as a PR. Again please let it be clear, it's not that QMK maintainers are blocking upstreaming, it's that I don't have the time right now to work on it. I will get to it when I will have time.

I'm assuming pandrew = purdea.ro? Trying to clone that getting less than 1 kbit/sec.

I just tried cloning on a machine from the US (from my romanian server).
The whole repository got cloned in 2 minutes and 45 seconds. The .git subdirectory is about 145 MiB, so the average bandwidth was around 900KiB/s

It is possible there was a transitory problem with the network connection at the time you tried it, please try again.

This is why I'm as passionate about encouraging Vial adoption as I am.

I agree, and I also want to eventually officially support VIAL. Main issues I will need to solve are: 1) To make the debugging features in util.exe work with it 2) To have it support all the keyboard variants I support. All of these are doable, I just don't have time right now. And waiting might actually solve some problems for me, since XAP is in development upstream (well it was in active development a couple months ago, I did not have time to keep up-to-date with the latest news). Currently I can't support VIAL-specific problems, but I appreciate all the people who have posted their VIAL firmwares.

I'm also toying with the idea of backporting my training algorithm into original xwhatsit firmware. If that comes to pass, there will be two reliable choices for firmware variants that can have their keymaps changed without having to re-flash the firmware.

The issue is that pandrew's QMK capsense driver will "pass over" setting a threshold for any keys where the default layer 0 key value is set to "KC_NO" (nothing), and just set that pad to threshold of 0. Which in turn causes that key to not be sensed, period. And it just so happens that literally every key layout in the default firmware distribution other than the JIS and scumyc ones have that extra key to the right of Spacebar set to KC_NO.

Well that's a stoater of a bug if so!

In plain QMK this is a feature, not a bug. Let me explain:
Key positions that don't have a flippers over them will have a lower signal value than key positions that have a flipper over them, but are unpressed. That means that with high likelyhood keys without flippers will make the range of signal levels bigger, and as such will likely affect the binning of these signal levels. For this reason I explicitly recommend not assigning keys to key positions that don't have flippers over them. This is in order to maximize the chance that the training algorithm will come up with a closer to optimal solution. This is why key positions that are assigned N/A or KC_NO on layer 0, in plain QMK, are skipped over.

Layer 0 in plain QMK is stored only in flash memory. My code only looks in this flash memory area.

VIAL adds the possibility of EEPROM-stored keymaps, but my training code is not aware of this.
One potential way to handle this, is for my code to also look in the eeprom, (if running in VIAL), and to make the decision to skip or not to skip a key based on the configuration it finds in the EEPROM. Also there could be some pitfalls with live reconfiguration. Vial may need to re-trigger training on keymap updates, if keys are changed from N/A to having a function on layer 0.

A second option is to have different pre-built vial firmware alternatives for different flipper-placement configurations.

A third option would be to try to quantify the effect of key positions without flippers. I guess it's possible that the effect I'm talking about is small enough that it's not worth fussing about. After all people have been using their keyboard just fine without following this recommendation of mine. I haven't done the work to try and quantify this effect, so I don't know how much it matters.

seriously looks like your RP3 and RP4 are 10-pin while PCB is made for 8-pin ones.

Nice catch!

[Ellipse]

Nice setup example: A Snazzy Labs subscriber on YouTube recently let me know about Quinn's latest video - I like the combination of the 0-9 style number pad and the Industrial SSK custom set on Quinn's Brand New Model F F77 keyboard shown briefly in the first few seconds. I have not seen too many of the various configurations with the Mopar key set and the number pad together (personally I prefer the number pad on these keyboards to the Ins/Del/etc. type right side block).

[NathanA]

pandrew, thanks for piping in and setting the record straight. ...unfortunately, this won't guarantee that anybody will actually read your post when we flip over to page 251 & people just start asking all of the same questions all over again...

1) To make the debugging features in util.exe work with it

This already works. I don't know why it isn't working for the original darkcruix or original & current Ellipse builds of VIA firmware; if I had to take a stab in the dark, perhaps they both had RAW_ENABLE = no set in their rules.mk? (EDIT: duh, no, that can't be it, because I believe VIA itself depends on the raw HID endpoint, which is why the raw_hid_receive function in util_comm.c needs to be renamed in the first place...hmm.)

In the case of my Vial builds, I chose to use different USB VID & PID than either your original QMK port uses or the different PIDs that darkcruix elected to use with his VIA builds...didn't sit right with me to camp on Zenith's old VID even if they are dead now. So I modified your util's USB device scan/enumeration routine to look for more than one known-compatible USB device ID; patch attached. That's literally all I had to do, and then this version of your util was talking just fine to your raw_hid_receive routines on my builds of Vial... (If I add the darkcruix VIA PIDs to the pidlist array, it still doesn't pick up a keyboard running darkcruix- or Ellipse-built VIA firmwares, which is why I conclude they must've also changed something else to break it...)

Currently I can't support VIAL-specific problems, but I appreciate all the people who have posted their VIAL firmwares.

*raises hand* so far that would consist of...(counts fingers)...me.

At this time, your code seems to run perfectly fine alongside Vial, as long as I keep the version level of my Vial build tree to approximately 0.4.1 (summer 2021). As soon as I go beyond that is when instabilities set in; thus, I have just been sticking with older Vial sources for the time being.

From what I can gather, I believe newer versions of Vial firmware are somehow overwriting & scrambling the parts of memory where you are storing the auto-cal threshold values. I say this because if I can manage to launch your utility and bring up the keypress monitor in time before the firmware on the keyboard eventually crashes/stalls and needs to be rebooted, the keypress monitor loads up but shows absolutely bonkers values for the computed thresholds for various keys. (I'll try to get a screenshot posted soon.) The instability seems to have cropped up right around the time that Vial did a large refactoring of their Tap Dance and Combos code, and if I omit those features from my builds of Vial 'master' for Xwhatsit controllers, that also stabilizes things. It is absolutely not a general Vial problem, though, and is somehow specific to your capsense code, because if I build a copy of Vial with all of the same features for a different ATmega32U2-controlled keyboard with regular contact-based switches that just relies on the default QMK matrix scanning implementation, there is zero instability.

[...] A second option is to have different pre-built vial firmware alternatives for different flipper-placement configurations.

Having a bajillion-and-one .hex files to build and distribute for every conceivable layout under the sun -- especially since the layout is reprogrammable dynamically after flashing -- is something I'd like to see us try to get away from, not further encourage. So though this is clearly the easy way out, I personally vote against it.

A third option would be to try to quantify the effect of key positions without flippers. I guess it's possible that the effect I'm talking about is small enough that it's not worth fussing about. After all people have been using their keyboard just fine without following this recommendation of mine.

I'm just one data point, but I have been using a build of Vial with all flippers having default assignments other than KC_NO but with 4 unpopulated barrels, and have not had any problems.

[elira]

I'm having issues with the spacebar, it registers but it seems like it has a delay or something. Has anyone had this issue? Should I replace the spring?

[BuGless]

I'm having issues with the spacebar, it registers but it seems like it has a delay or something. Has anyone had this issue? Should I replace the spring?

Yes, had it. Both with an 'f' key and with the space bar.
In both cases, I removed the spring, then reseated the spring, pushed it down properly using a pair of tweezers, and put the keycap back on.
The results were good, both keys register fast again, just like the other keys.

[flowchartsman]

I have not seen too many of the various configurations with the Mopar key set and the number pad together (personally I prefer the number pad on these keyboards to the Ins/Del/etc. type right side block).

This is the number pad layout I'm currently using with Vial.


I don't usually end up using the number keys for numbers, so I have a pseudo numlock key setup for that. For normal (layer 0) use, I've got that block setup to do navigation and media. I used to have the keys above the left and right arrows for song skip, but kept hitting them accidentally, so I switched them to the macos back-one-word and forward-one-word, and I really really love it. I use a couple of handy tap-dances to have one key that does pause/play, forward song AND backward song on one single key, and then the most upper-right key is a tapdance to either toggle DnD or just lock the screen if double-tapped, which is also super handy. I like that VIAL lets me edit tap dance visually, though my initial attempt to use the tapdance key to toggle numlock or layer two didn't seem to work right with it putting the layers in a weird, inconsistent state where it would mostly be layer 0 but with some keys mysteriously disabled. Not a huge deal, honestly, and I'm sure it will probably get hammered out eventually.

Tapdance has been a real game changer for me, and just these two keys alone are supremely useful for me.

Also, having the momentary layer (2) for mouse movement is great for those occasional times when I need to do work on something that has a GUI in my homelab, but don't want to lug a mouse around. Super handy. Really wish I had just one more layer to offload the meta stuff like haptic and reset to, but I gather there are memory limits to the number of layouts that can be stored. Might switch those to tapdance double-tap to keep them from being accidentally triggered.

[bmk]

If I ordered back in December 2021, think my keyboard was in the recent container? I'm wondering in case I move come December.

[Daniel_CH]

So, I've been having a weird issue with my ISO Enter key.

It has stopped working out of nowhere for the past 2 days, and I've had to reseat the spring to get a semblance of response again. Playing with the spring without the keycap shows normal response. Controller screws are tight and the flipper is in perfect condition. I changed the spring, just in case.

But even then, it stopped working for the third time tonight. What is weird is that the best way I have now found to quickly fix it was to reinstall the key, while NOT holding the keyboard vertically, but flat.

Any idea what could be causing this? Could a bad keycap be the problem (nothing is broken on it, but maybe an issue during molding)?

[elira]

I'm having issues with the solenoid, I installed according to the video but it doesn't work. I just hear a fain buzz when enabled but it doesn't work. Does anyone know how to fix it?

[elira]

I'm having issues with the solenoid, I installed according to the video but it doesn't work. I just hear a fain buzz when enabled but it doesn't work. Does anyone know how to fix it?

Ok, solving my own issue. I took the solenoid and controller out given that I saw it has a small LED that tells you if the solenoid is enabled or not. Once I did that I saw that the controller's LED was flashing properly. Upon further inspection I saw that the header solder joints looked bad (on the solenoid controller), so I reflowed them and now it works fine. It's my first keyboard with solenoid. I think I have fixed all the keys that were funky, so far it seems like an interesting keyboard, but it seems to need a lot of tweaking to get it to work. So far I have had to replace 3 springs, and re-seat a couple more.

[yaun]

I was just about to fill out the form for the ISO Enter key, when I saw, that there is only one option for 99$, which is for an entire key set, if I am not mistaken.

I ordered a certain serial number, but as I understand your latest blog post, my order will go out rather late anyway, because I ordered several extras. So, I am somewhat reluctant to throw in additional orders, but I think I would go for one ISO Enter key and one Code key, both matching the color of the keys I ordered so far, if it was significantly less than 99$. Can we modify existing, unshipped orders of keysets to include the ISO Enter key and the Code key?

[flowchartsman]

I'm going to do a custom dye sublimation for my keycaps, are there any dimensions for the faces of the various keycaps available anywhere?

[Guppy]

That said, if somebody were to come up with a better-looking design and have it produced, I suspect a lot of people would rise up and call them blessed.

What, like this?



I was able to find a schematic reference for the cutouts on the original Model M, but these unicomp ones are derived from tracing, so I could use some better measurements if anyone has them.

I have no input on the QMK Firmware discussion but I just wanted to say: that looks really good, I think I remember something really similar on other 80's-90's era keyboards.

[Ellipse]

yaun the ISO Enter mold would take months so unfortunately you'd have to pay for separate shipping since all the orders will be out before the mold is ready (everyone feel free to email me for a quotation for any order with only small items - for international shipping). US shipping for small items is a flat $9.99 rate. I'd imagine the key would be $49 alone just like the other keys given how low volume it's expected to be based on current responses. If the mold is $5000 for example (have not quoted anything just yet) then we'd need about 50+ key sets' worth of interest at $99 each.

[Ellipse]

Project milestone: this week the 3000th Brand New Model F Keyboard shipped! I am still going through the backlog and expect to finish up over this month and next month as noted earlier.

Also the first red and green text dye sublimation keys arrived from the factory and look nice. Some folks wanted red text esc or green font for the alt key like on the Model M keyboards.

2022-06-07_13-35-16 - Copy.jpg (868.96 KiB) Viewed 35434 times

[DMA]

seriously looks like your RP3 and RP4 are 10-pin while PCB is made for 8-pin ones.

I would never have spotted that with my eyes in those pics. I think you've nailed it.

LOL try to hand-solder a QFN with 0.6mm pin pitch and by the time you get it done you'll be able to notice much smaller details, guaranteed.

[...] or they thought they could get away with using the 5 array and they might have been able to if they'd have gotten the spacing right.

If it were a 10-pin part, would it not be more likely to be a bussed resistor pack instead of the isolated type (a bunch of resistors "concatenated" together) that is spec'd for RP3 and RP4? If so, then there's no way this would've worked even if they had managed to line up 8 out of 10 pins every time...right?

I don't think it will have a common lead - it's not often one needs 9 pullup resistors, honestly.
However, one would never ever do this on purpose - capillary forces of the molten solder work miracles when they work for you, but are a disaster when they work against you I.e. when you have a pads matching component pins, the component will self-align almost magically. And in this case (because component placement location is actually it's center - PnP machine doesn't really know much about component position, it's all open-loop (I tried asking around at this year's APEX if anybody actually has closed-loop placement control and nobody admitted )) - component's pins were placed exactly between pads and you essentially have a "which pad reaches liquidus first pulls the pins towards itself" lottery.

[Ellipse]

Thanks to the help from a few folks I have put together a description of the Icon Keys on the Extra Keys page, in order from left to right - please let me know if there are any errors or if you have the Unicode codes for the missing items:

Icons Row 1 (Unicode in parentheses):
1. ← Backspace
2. ← Backspace
3. ⇥ Tab
4. ⭾Back and Front Tab / Horizontal Tab (U+2B7E)
5. Caps Lock (U+1F512)
6. Caps Lock (U+1F512)
7. ↵ Return / Enter
8. ↵ Return / Enter
9. ⇪ Caps Lock
10. ⇧ Shift
11. ⇧ Shift
12. ⇧ Shift
13. ⇧ Shift
14. ⌘ Command (Apple/Mac)
15. ⌃ Control (Apple/Mac)

Icons Row 2:
1. <X| Backspace / Erase to the Left (U+232B)
2. <X| Backspace / Erase to the Left (U+232B)
3. <X| Backspace / Erase to the Left (U+232B)
4. ⎋ Escape (Apple Escape) [unicode U+238B]
5. O-->[ ] IBM print screen
6. Padlock with the Up and Down arrow: Scroll lock
7. ⎉Pause / Circled Horizontal Bar with Notch [U+2389]
8. a^ Insert IBM-style
9. a with curved line: Delete
10. ⌦Delete / Erase to the Right (U+2326)
11. ↖ Home / North West Arrow [U+2196]
12. ↘ End [unicode U+2198]
13. ⇞ Page up / Upwards Arrow with Double Stroke [U+21DE]
14. ⇟ Page down / downwards arrow with double stroke [U+21DF]
15. Padlock with the number “1” Num lock
16. ⎇Alt key with arrow (U+2387)
17. ◇Meta / UNIX-style super key / Diamond [U+25C7]
18. ⌃ Control 1.5U
19. ⌥ Option (alt) 1U [unicode U+2325]
20. ⌘ Command 1.5U
21. ⇮ Upwards Double Arrow (U+21EE)
22. List icon
23. ƒ Function / F with a hook [unicode U+0192]
24. ↵ Return / Enter

[Guppy]

I appreciate the descriptions, I hadn't seen a number of those symbols before (I'm a whippersnapper, I know) and now it's a little bit more clear where each comes from or what their intended function might be.

[barelyanything]

I'm using VIA firmware with the VIA configurator.
VIA configurator doesn't allow me to use these QMK Keycodes to program the keyboard.
These QMK Keycodes show up as HEX on VIA configurator
Does anyone know where can I find the definition to the HEX code for these QMK Keycode.

Code: Select all

| Name | Description |
|———–|——————————————————-|
|`HPT_ON` | Turn haptic feedback on |
|`HPT_OFF` | Turn haptic feedback on |
|`HPT_TOG` | Toggle haptic feedback on/off |
|`HPT_RST` | Reset haptic feedback config to default |
|`HPT_FBK` | Toggle feedback to occur on keypress, release or both |
|`HPT_BUZ` | Toggle solenoid buzz on/off |
|`HPT_MODI` | Go to next DRV2605L waveform |
|`HPT_MODD` | Go to previous DRV2605L waveform |
|`HPT_CONT` | Toggle continuous haptic mode on/off |
|`HPT_CONI` | Increase DRV2605L continous haptic strength |
|`HPT_COND` | Decrease DRV2605L continous haptic strength |
|`HPT_DWLI` | Increase Solenoid dwell time |
|`HPT_DWLD` | Decrease Solenoid dwell time |

These QMK codes are being shown as HEX on the VIA firmware.

I know
0x5ce8 is HPT_TOG
0x5cf2 is HPT_DWLI
0x5cf1 is HPT_DWLD





Thanks

[Ellipse]

As an update the latest email newsletter update is going out this afternoon. Here's a link to see it right away, or if you are not subscribed (to subscribe feel free to head over to the project web site and click the box on the right hand side of the window):

https://mailchi.mp/106dffa1b161/brand-n ... te-9074837

Also check out this great project to create an RP2040-based controller for capacitive buckling spring keyboards:
https://www.keebtalk.com/t/the-leyden-j ... ards/17489

[RaoulRod]

I got my solenoid in and installed it, got it working!

In the manual it shows you where to install the solenoid in the classic case. But nothing deals with where to put the driver board. Other than using some double stick tape, does anyone have a good suggestion?

There is a spot for a screw on the driver board, but I didn't find any good spots to mount it in the case

C8410A54-00F6-4D14-A3AA-FBAEDAE115E7.jpeg (3.6 MiB) Viewed 34826 times

[Ellipse]

A helpful person emailed me the answer to setting up the toggle keys - the secret to getting the right side blocks 4 and 5 working.

In summary you set one key (for example the key between Right Alt and Right Ctrl) to be the toggle key: on the QMK configurator site, go to the Quantum tab and drag the TG key in the Layer and Tap Functions section to the keyboard and then enter in the number 3 in the text box inside this key (to indicate "layer" 3). Then click layer 3 on the left side of the keyboard and drag the Insert/Del/etc. keys to the positions as indicated however you installed the keys (example "Del" on the 6 num pad key).

With this setup, I was told that you can press the toggle key to act as a quasi-num lock key - when it is pressed, pressing the 6 num pad key in the above example will send the Del signal, and when the toggle key between Right Alt and Ctrl is pressed again, it will go back to num pad. I think this is the solution we are looking for to getting the additional right side block keys working but please let me know if this is accurate.

RaoulRod the solenoid driver can be loose but I recommend taping the bottom side with polyimide or electrical tape so that it does not accidentally come in contact with any exposed metal surface such as the bottom inner assembly plate.

[RaoulRod]

Ellipse, thanks for the reply. I think mentioning the solenoid driver location/electrical isolation is something that should be added to the manual/video. Also, I did experience the same electrical gremlin that AgentOrange96 experienced. Initially I screwed the solenoid in too tightly, and it didn't work when the case was closed. I replaced the outer washer that I ripped trying to secure the solenoid and it is working now.

I do need to raise the board more than the standard cork feet to account for the extra height of that screw.

Again, something to probably add to the manual

[Ellipse]

Confirmed I have added the solenoid notes to the manual as well as on the solenoid product page.

I just received some interesting additional details on the Code key that I am sharing below:
"The Code key was found on IBM terminals as well as IBM Wheelwriter
typewriters. In both cases, though, its functionality was basically
exactly the same as the Alt key (the left-hand one, not the right-hand
one when it is used as an AltGr key) on the PC, to enable special
word-processing functions or other special functions of the program in
use.
There was also a Code key on the Displaywriter."

[NathanA]

A helpful person emailed me the answer to setting up the toggle keys - the secret to getting the right side blocks 4 and 5 working.

<snip> ... the TG key ... </snip>

Maybe we just didn't describe it well in our posts to this thread, but this is literally, 100% the exact same thing that those of us here who have been talking about our "pseudo-NumLock" set-ups have been doing this whole time.

Right side blocks 4 and 5 have already been implemented this way, and 3 re-implemented this way as well (3 doesn't need to be done this way, but the advantage to doing so is that then you can actually switch back and forth between numbers and nav commands with block 3 on a Mac, which doesn't have the concept of "Num Lock").

The important disclaimers are as follows:

1. This of course does not rely on actual NumLock, so the host computer will be unaware whether your pseudo/quasi NumLock is on or off. You also can't change NumLock on the host and have that trickle down to the keyboard, either.
2. You still cannot fully implement block 4 using QMK Configurator, because double-zero can only be accomplished with a macro, and you cannot script macros with QMK Configurator.

Most of us have made our peace with #1, though it would be cool if QMK were modified to allow one to treat NumLock status as a method for selecting a particular layer.