deskthority

YALE70 wrote: 23 Oct 2024, 19:10

pilcher wrote: 23 Oct 2024, 17:22

del20nd wrote: 23 Oct 2024, 16:50Again, I'm happy with what was delivered overall. I understand the reasons for not delivering a fully assembled board, but do wish that, at the very least, the stabilizers came tested and preinstalled, especially if there's undocumented variation in the orientation which they have to be installed. Getting them wrong can be a costly and annoying time sink. There's always a chance that you'll have to disassemble the keyboard either way, springs can come dislodged in shipping, etc, but I feel that just taking this one step would greatly reduce the risk.

My biggest "complaint" about shipping is that several of my springs were actually damaged by being mashed against the barrels. I had to remove those springs and straighten them out as much as I could, which inevitably isn't perfect (although I did ultimately get all of the keys working). I'm hesitant to suggest that the keyboards should be shipped with the springs not installed, because it would make setup quite a bit more work, but it would prevent the springs from being damaged in this way.

Mine did as well. I had a few damaged keycaps too because UPS decided to play package football with the delivery (all eight pounds of it). These were all quickly replaced, but I do have some ideas on additional measures that could be taken to hopefully mitigate stuff like this from occurring on future shipments.

The loose component bags should be secured: I think them shifting around inside the box during transit is a big reason why springs are getting bent and whatnot. I would tie down, rubber band, or tape the bags to the keyboard so they can't move. I'd also try protecting the exposed barrels/springs with a thin sheet of cardboard or packing foam, so that the bags aren't resting directly on the springs.

Finally, I would also tape over the side gaps on the top of the box. Only the long bottom gap was taped over and in my case, I think something caught in one of those side gaps and completely ripped the end of the package open. The carrier had taped over the opening before I received the package.

Otherwise, I think the foam endcaps are fine - I don't think the box needs any additional padding, but given the limited interior space of the box, hopefully those ideas at least make it less likely that reckless carrier handling ends up causing actual damage to the keyboard or the components.

pilcher wrote: 23 Oct 2024, 17:15

del20nd wrote: 23 Oct 2024, 16:50While the setup process was mostly straightforward to anyone that's dealt with rehabbing original Model F's, I did run into one frustrating issue with the black vertical key stabilizers. In the instructions it's explicitly stated that the stabilizer for the ISO enter should be keyed such that the large ear is pointing towards the left, 180 degrees rotated from the images in the guide. When I keyed it this way, it didn't work. It turned out that it worked perfectly when it was keyed the same way as the '+' key, with the large ear pointing toward the right. That was frustrating because the instruction didn't mention the variation, and getting that wrong can easily mean a complete teardown of the keyboard. I did have to pause the setup for a night to stop myself from doing something stupid to try to brute force the stabilizer. It was very frustrating in the moment.

Interesting. I didn't have to reverse the orientation of the vertical key stabilizers, but it did take a lot of force to get them in. (I found that the end of a normal sized Sharpie is the perfect size to push them in without permanently denting one's thumb.) Now I'm wondering if mine are in backwards.

YALE70 wrote: 23 Oct 2024, 05:47

Ellipse wrote: 23 Oct 2024, 04:41 Are you referring to the post on the top case for the solenoid (the other post on the top case is for the USB cable's p clip strain relief)? That hole should be 6-32 thread and there should have been a 6-32 bolt provided. I suggest testing the hole with another 6-32 bolt. I have installed a number of solenoids and drivers for these boards and have not noticed any issues. The solenoid driver should not be mounted to any points on the bottom of the case.

It is the post for the solenoid driver, yes. I used the larger of the screws provided - the two smaller screws being used to secure the the solenoid to the bottom plate. I should have some more 6-32 machine screws kicking around so I'll verify this once I have another opportunity to open the keyboard up.

pilcher wrote: 25 Oct 2024, 01:28 I am getting inconsistent registrations of my "F" key (oh the irony!). Most of the time it works just fine, but it occasionally doesn't register, or it registers twice. I've already tried twisting the spring around and even swapping it with the spring from another key. The signal level also looks OK.

What else can I try?

pilcher wrote: 25 Oct 2024, 16:57 Also, has anyone been able to get the pandrew utility to work on Linux? I've managed to build it (tried both hidapi variants), and it doesn't detect my keyboard, even when run as root.

EDIT: FWIW, Vial detects my keyboard just fine (even as a non-root user).

YALE70 wrote: 23 Oct 2024, 00:51 Lastly, the "LShift + RShift + N" command for enabling NKRO that was specified in the manual did not appear to work for me. I ended up just mapping it in Vial to Layer 2 as "Fn + Space + N".

Ellipse wrote: 23 Oct 2024, 04:41 I believe NKRO is enabled by default for NathanA firmware and not enabled for the previous pandrew firmware

YALE70 wrote: 23 Oct 2024, 05:47 Yeah, my NKRO didn't appear to be enabled by default when I initially tested it so that's when I ran into trouble trying to enable it.

pilcher wrote: 25 Oct 2024, 16:57 Also, has anyone been able to get the pandrew utility to work on Linux? I've managed to build it (tried both hidapi variants), and it doesn't detect my keyboard, even when run as root.

Ordinary Witch wrote: 26 Oct 2024, 05:35 just to make sure; there are two variants of the utility. the one meant for the new firmware is here. I don't remember where the older one meant for pandrew's original firmware is anymore, but you'll need the right one for your firmware

del20nd wrote: 23 Oct 2024, 19:42

Ellipse wrote: 23 Oct 2024, 19:22 Great photos del20nd! Thanks for posting your review.

The manual mentions that the vertical stabilizers should have the larger ear on the right side for all keys except the ISO enter key, which has the larger ear on the left side. There is a photo that shows the normal orientation (larger ear on the right side) below the following text in the manual:

"The vertical stabilizer inserts are installed also as pictured for the number pad 2U Vertical keys, but must be installed differently for ISO Enter! The product photo shows each photo in the “right side up” orientation so for ISO Enter you’d just install the vertical (black) insert 180 degrees rotated from the photo, so that the larger “ear” of the insert is on the left." I added some more details to the manual to reiterate this point.

Can you show a photo of what you meant with the flat silicone gasket? That seems like a good idea to consider to remove an insert without the Wilde tool linked to previously.

pilcher please do share photos of the mod when it is completed! You'd have to cut through the aluminum case somehow. I explained on a recent page on this thread why the key sets cannot be installed, so the downside is that the springs may move out of place while the keyboard is bounced around in shipping.

YALE70 based on one or two issues of damaged boxes I have started taping the sides as well. So far no reports of box destruction with the additional tape. Also I am now putting as much as possible below the keyboard including the dot matrix page and green booklet to minimize the small bags moving around too much since they are lightweight. But we must always continue to expect shipping damage to be a possibility since the keycaps cannot be installed, and more of these results will be reported when hundreds of packages are going out in such a short time span.

Thanks for the feedback.

That I'm saying is that I had to install the ISO enter key with the ear to the right side, counter to instructions, for it to work. When the ear was installed facing towards the left as instructed, the enter key bound badly. It works perfectly with the ear pointing towards the right.

The flat silicone gasket is something I had left over from another project. It's something I made by taking black silicone gasket maker from Harbor Freight, flattening between two pieces of waxed paper to about the thickness of a credit card, and letting dry overnight. I've used these flat sheets to cut out washers and silicone feet for other projects, so here I just tore off a piece of scrap.

Ellipse wrote: 26 Oct 2024, 09:09 pilcher my guess is you are not reinstalling the spring correctly, in the correct 12 o'clock position as well as with the spring about 1mm away from the 12 o'clock position of the barrel when the keyboard is held vertically, space bar end up. If the spring is too high up (too close to the 6 o'clock barrel position), buckling errors will occur as you mentioned. I also recommend swapping the keycap with another keycap to see if the F keycap itself was somehow deformed or damaged.

As reported to me through another GH/DT forum member's great research back when the project was just getting started 8 or 9 years ago:

It is important for the spring to be close to the 12 o'clock position of the barrel (as shown below) when the keyboard is held vertically, space bar end up, because the click is not strong otherwise and click errors are more likely to occur.

It is also important for the spring to be close to the 6 o'clock position of the barrel when the keyboard is held vertically, number/function row end up, because the key press will cause the spring to buzz if not in this position. This means that the spring cannot touch the 12 o'clock position because then the spring will be too far away from the 6 o'clock position when the keyboard is flipped to the right side up position.

And finally, springs that are installed too much left or too much right compared to the vertical center will cause errors with installation such as keys not working reliably.

• I don't know that it's really possible to determine if the spring and keycap are installed correctly just from the sound & feel. Personally, I would recommend that folks use the signal monitor when doing the initial keycap installation.

• Installing the springs onto the flippers is really, really difficult, and that's even more true when the springs have been damaged in shipping.

NathanA wrote: 26 Oct 2024, 13:28 And where did you obtain the sources to build it?

If you pulled from pandrew's repo, that version is not going to detect a keyboard running Vial firmware, since the USB Vendor ID and Product ID doesn't match what it is expecting. If you download the New Model F Vial firmware bundle, it includes unified diff patches that will result in a working version. But for your convenience, I've gone ahead and split the util-specific patches out of the main diff file & am attaching them to this response.

http://purdea.ro/qmk_firmware/

pilcher wrote: 26 Oct 2024, 21:18 Assuming that NathanA's post is correct, [...]

pilcher wrote: 27 Oct 2024, 00:31 I pulled it from

Code: Select all

http://purdea.ro/qmk_firmware/

. AFAICT, this is where the manual says to get it, but I can't get your patch to apply to that tree.

NathanA wrote: 27 Oct 2024, 11:07 Within the download package is included a (extremely primitive) shell script which checks the source code needed out of the pandrew and Vial repos, applies my diffs, and then builds all of the keyboard firmware binaries. (Given the complexity and the number of target host platforms, it does not attempt a build of the util; that's still left to you.) So frankly, what you should do is download that package from the website, and the follow the instructions for building in the README in order to set up your build environment. This will leave you with a source build tree that is in the exact state that you need & with the exact version of the files that you need in order to build a copy of the utility that includes support for these keyboards.

Unknown keyboard (you may need to update the util version)!

python2 generate_layout.py > kbd_defs.cpp

pilcher wrote: 27 Oct 2024, 23:59 OK, I've made some progress. The utility now sees the keyboard, but when I try to start the signal level monitor, I get an error pop-up that says:

Unknown keyboard (you may need to update the util version)!

I tried to run the command to add a new keyboard:

python2 generate_layout.py > kbd_defs.cpp

pilcher wrote: 27 Oct 2024, 23:59I was able to work around a couple of errors (failing to locate avr/io.h and util/delay.h) by creating a couple of symlinks in my /usr/include directory, but now it's failing to find sequencer.h, which seems to be within the firmware tree, so I have no idea how to fix that.

patch -p1 < /YOUR/PATH/TO/THE/newfxx-vial-package/src/pandrew-util-new_kbd_defs_r5.diff

Rotti wrote: 27 Oct 2024, 16:34 Hey guys. I am using a Rev 2 Xwhatsit controller with an original Kishy that I have had working for many years now. I did have the original buzzer board and am trying to get the solenoid working. It does technically function but is very weak. With the default firmware from the "beta" side of QMK, the keys that I found that are supposed to adjust the dwell time for the solenoid do not seem to be working.

[...]

Well, I flashed the firmware listed above a couple posts, and now the keymap is WAY off, and can't get back into bootloader mode.

NathanA wrote: 28 Oct 2024, 01:52 EDIT: Okay, I see what's going on. The generate_layout.py script apparently traverses through all of the header files, I guess to resolve certain constants. So something wrong with avr-gcc installation can in fact break this.

I actually did include a pre-generated version of the kbd_defs.cpp file in diff form which includes all of the definitions for the new keyboard models; it just doesn't get applied automatically since the build script doesn't attempt a build of the utility (and since typically, if you have a properly functioning build environment, the generate_layout.py script works just fine anyway). To utilize it, re-run build.sh to get yourself a fresh build tree, then from your 'qmk_firmware' directory, run:

Code: Select all

patch -p1 < /YOUR/PATH/TO/THE/newfxx-vial-package/src/pandrew-util-new_kbd_defs_r5.diff

Then try your util build again.

pilcher wrote: 28 Oct 2024, 16:14 I wrote up steps I took to build the utility here. Hopefully they will be useful for others.

$ git clone http://purdea.ro/qmk_firmware
$ cd qmk_firmware
$ git checkout 6ebae72
$ git checkout 758febb -- keyboards/xwhatsit/util/util/kbd_defs.cpp

$ patch -p1 < ../newfxx-vial-package/src/newfxx-vial-0p4p1-patches_r5.diff
$ patch -p1 < ../newfxx-vial-package/src/pandrew-util-new_kbd_defs_r5.diff

grep "^+++\s" file.diff

NathanA wrote: 28 Oct 2024, 11:19

Rotti wrote: 27 Oct 2024, 16:34 Hey guys. I am using a Rev 2 Xwhatsit controller with an original Kishy that I have had working for many years now. I did have the original buzzer board and am trying to get the solenoid working. It does technically function but is very weak. With the default firmware from the "beta" side of QMK, the keys that I found that are supposed to adjust the dwell time for the solenoid do not seem to be working.

[...]

Well, I flashed the firmware listed above a couple posts, and now the keymap is WAY off, and can't get back into bootloader mode.

I see that you finally got back to bootloader mode, so that's good. Yes, the PROG pad shorting can be finicky.

There are a number of things to address here...

First and foremost, the Vial firmwares that have been posted so far and which are being discussed in this thread are ONLY compatible with the Ellipse recreation keyboards. NOT with the original IBM-manufactured ones that have undergone an xwhatsit brain transplant. The web page explicitly says that these are for the "New Model F" keyboard series from "Model F Labs". The reason for the incompatibility (and for why your keymap looked and worked all screwy after you flashed the wrong firmware to your 'board) is because the recreation 'boards are NOT an exact clone of the originals, and the matrix arrangement is completely different on the Ellipse ones (not to mention that the pin header on the wcass "remix" of the xwhatsit controller is ordered differently than an original xwhatsit, such as what you have, while the Ellipse 'boards all shipped with wcass controllers). In fact, this DT thread is by-and-large dedicated to the recreation/clone boards.

The solenoid stuff is another entirely separate can of worms, and one that I am at a slight disadvantage of at addressing comprehensively since 1) I do not own a solenoid, 2) I do not desire to own a solenoid (at least, not for personal use...if someone wants to send one to me for testing/dev purposes, that's another thing entirely, but since I have no other use for it, I'm not going to sink my own $$ on one), and as a consequence, 3) I have never personally done any firmware testing with solenoids. And back when QMK first got ported to the xwhatsit family of controllers, there was a bunch of discussion in this thread surrounding issues getting it to fire satisfactorily. It seems like eventually most of the problems got worked out, and those updates were incorporated into the QMK firmwares that Ellipse himself was making and shipping pre-flashed to his boards. What I do NOT know for certain is whether these changes ever managed to spread beyond that. They were certainly available for anyone else to take and incorporate into their own builds/projects/forks, but that doesn't mean they did, and I haven't really checked or paid much attention to what others have done. I don't know where you are sourcing your QMK firmwares from that work with your board but which have solenoid performance problems, but if for example you're using pandrew's "beta" QMK Configurator instance to do so, I have no idea what solenoid driver code is being used there behind-the-scenes. (It looks like there is a "full source" download link, but I haven't taken the time to download and comb through it...)

On top of that, there is also the issue of any physical differences between the original IBM solenoids vs. the new solenoids that Ellipse sells (scroll down to the header that says "Custom made solenoid specifications:" for details). Since I have experience with neither, I have no idea if firmware that has been optimized for these new solenoids will perform as expected if you are using an original one. (I also have no idea which solenoid you have.)

All of that having been said, though I have no way to test it, I made sure to integrate the same, "known-good" solenoid code into the firmware builds I have been making for these keyboards, so that at least in theory the solenoid should perform exactly the same with Vial as it did with QMK...it should be no better, nor worse. And I haven't heard any complaints about solenoid performance from people running Vial on their New Model F keyboards in a looong time, which I take as a good sign (no news is good news...).

Anyway, if you wish to try it, I have gone ahead and ported Vial firmware to your original Kish + xwhatsit. The usual disclaimer of course is that I have no original Kish hardware to test it on; however, I'm still pretty confident that it will at least mostly work. You can download it here. Once downloaded, expand the ZIP archive, double-click the "link-flash-scripts" script, then go to the flash-scripts > ibm_f62_xwhatsit folder & double-click the singular "flash-..." script that's in there. Kick the keyboard controller into bootloader mode when instructed, and then wait for it to finish. After it's done, you can download Vial to configure your keyboard. Haptic/solenoid on/off toggle is mapped to Fn + Space + T by default, and "dwell time" can be decreased or increased with Fn + Space + "minus" / "plus" respectively.

mbarszcz wrote: 26 Oct 2024, 20:03 Just wanted to thank you Ellipse for all your effort you put into making these new Model F keyboards a reality. I've been following this project for many years now and had an original F122 that started with the original xwhatsit firmware which never quite worked right for me despite constantly fiddling with it. Several years ago I switched to the beta QMK firmware which has been great, but it was quite fussy to configure at the time.

While I know there are a lot of people that like the crazy small and unusual layouts, since before the project even began I just wanted a Model M layout with the Model F key mechanisms. All the keys, normal size. I was thrilled when the project got to the point where you started producing them. I finally got mine in the mail and spent the afternoon carefully putting the little pieces of floss in it just like my F122, putting it all together and very carefully putting the stickers on. Since this was a "special" model M for me, I decided to make it look like the Industrial M, complete with the requisite square black IBM badge in the corner.

The keys and firmware all worked perfectly right out of the box. No fiddly keys, no fiddly springs, no endless tweaking of sensitivities and thresholds, no bending and reseating the backplates, barrels and foam, no grounding issues, it all just worked as reliably as any other keyboard. Given how sensitive the capacitive sensing on the Model F is to imperfections, I think what you've managed to reliably manufacturer at this level of quality is truly commendable. Couple that with the Vial firmware and its amazing how far things have come over the past few years with all the manual firmware flashing that I used to have to do on my F122. It makes for a very polished experience.

Now I just need to get the icon set to finish it off.

The quality, the look, and the feel of this keyboard is exactly what I was looking for, great job.

photo_2024-10-26_12-42-34.jpg

Ellipse wrote: 29 Oct 2024, 21:11 I suggest erasing the eeprom and starting over in terms of flashing the firmware again.

Rotti wrote: 29 Oct 2024, 15:25 But it still doesn't seem to be working like advertised. It still doesn't actuate hard enough to come close to depressing the return spring and is not audible. I am wondering if the driver board was somehow damaged during shipping. The driver and solenoid were both shipped together in the same bag without any separation. There is an LED on the driver that I believe is supposed to flash with the solenoid firing. However, it is not.

Ellipse wrote: 31 Oct 2024, 03:02 "if I keep pressing a key over and over, it stops working for roughly five seconds. I THINK this is “One Shot Keys”."

Ellipse wrote: 31 Oct 2024, 03:02"There doesn’t appear to be a setting that I can find (in Vial) to TURN THIS OFF."

Ellipse wrote: 31 Oct 2024, 03:02"I can set it to 50 presses and that makes it *less likely* to be a problem, but that STILL will be a problem in video games."