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

[Rico]

Thank you very much, I'll have a look !

[riverstyx]

I recently received my F77 and am trying to swap around the key layout a bit. I've followed the instructions (in the YouTube video "Dead simple Model F Keyboard Layout Customization in 16 minutes: QMK and Via") to the letter; however, when I get to the Atmel Flip bit where I'm supposed to open the USB connection, I'm presented with the following message:

Could not open USB device.

I've looked through the thread here in an effort to see if anyone else has encountered (and resolved) this issue but have not found anything yet. I'm running Atmel 3.4.7 Build 112 on Windows 7. (When I downloaded Flip, I downloaded the version that installed JRE 5.0 Update 11, and that's the JRE that seems to be running.)

I'd be very grateful for any pointers anybody wouldn't mind sharing--especially if it's merely a pointer to documentation so that I can sort it out, myself! Thank you!

[Edited to address grammatical and typographical errors.]

[Arkku]

What would be great for me to have:

• Source code of the current QMK firmware, for informative purposes mostly

• Information on matrix/switches topology with always on and off switches(could still find that reading qmk source code)

• Have access to Pandrew utility software: I feel that I could connect the firmware with this tool and why always reinvent the wheel ?

Hi, since I recently wrote a new firmware that supports these keyboards, maybe I can share some experiences (wall of text ensues):

I had already written a USB HID keyboard implementation and "engine" (i.e., layers, macros, combo keys, etc.) from scratch (no library used so the code might be smaller and more specific to keyboards, and it has in some ways more optimised non-NKRO descriptors than in QMK). I suspect you may also have to do something like this unless QMK supports some keyboard that uses the same kind of chip as you (maybe the chibios used by arm-based QMK keyboards would support it). If you end up having to do it on top of QMK, there's quite a bit of boring USB HID descriptor and request/response plumbing that needs to be done in order to support all of QMK's features like mouse keys, media keys, etc... It's not particularly difficult, but not having to support all of QMK is one reason why I prefer my own firmware.

I originally wrote the firmware for a DIY PS/2 to USB converter (to install inside my model M keyboard), but as proof of concept I decided to make a wrapper to support semi-easily porting keyboards from QMK (at least as long as they use the same microcontroller family, since my USB implementation is only for AVR), i.e., taking the low-level keyboard driver from QMK but using my keyboard engine instead of QMK's. This was fairly easy: a dozen or so files from QMK copied as is, and the "main" file of under 400 lines that duplicates the execution flow of the QMK but passes the matrix scan results to my engine instead.

Porting a new keyboard using this approach is theoretically a simple matter of taking the keyboard-specific files from the corresponding "keyboards" directory in QMK and setting up a Makefile to include them in the build. The two things that need customisation are the QMK config.h (this is mostly mechanical changes of changing the files it refers to) and the file which contains the base keymap, i.e., matrix configuration.

So, the things to look in QMK is to find the keyboard directory, e.g., `keyboards/xwhatsit/brand_new_model_f/f77/wcass` and then backtrack any files it refers to in the parent directories. For these keyboards, the keymap/matrix configuration is in this innermost directory, in the .c and .h files with the same name as the directory (here wcass.h and wcass.c). The .h file contains macros that map the actually existing physical key positions to the matrix row and column, and the .c file calls one of these macros with the physical key layout. (The layout is often even written in the text file to look like the actual keyboard, so following this is easy. I recommend copying these pretty much as is, since manually defining each matrix is time-consuming and error-prone. The changes I do is just to make sure all the populated keys are unique, since my engine is based on specifying the differences between this "natural" keymap and what you wish to use.)

Now, the tricky part is the capsense scanning and calibration. In the QMK firmware, this is defined in `keyboards/xwhatsit/matrix.c`. I originally used this file as is, just to get my firmware working with a proven solution, but I have rewritten probably over 80% of that file since, to optimise the speed (the scanning is typically 2-4 times faster, although the worst case is only maybe 20% faster, and calibration is maybe 2–3 times faster – it could be over 6 times faster but I have chosen improved accuracy instead, since the absolute calibration time is already short enough to be negligible in the USB proceedings).

The matrix scanning is done by setting a DAC threshold, then pulsing each column and reading the results from the rows, each giving either high or low (one or zero) depending on whether the key is above or below that threshold. The goal of the calibration is to find some set of thresholds that is small enough to be scanned for every key fast enough to be responsive, while having the thresholds such that the values correspond reliably to the actual state of the the key.

For the calibration premise is that we know the mapped keys (by looking at the non-zero values in the aforementioned keymap) and can assume that those keys "should" be all unpressed on power-up. (I have some code to handle keys pressed on power-up, but we can get back to that later.) The difficulty here is that without user interaction during calibration, we can only presume to find the thresholds for the always unpressed state at that moment in time. We could simply assign the thresholds to the highest value that makes each key read as not pressed, but that will result in phantom presses when the values drift slightly over time, and when pressing adjacent keys causes a slight change in unpressed keys.

The start of calibration in pandrew's firmware is to first do two binary searches across all mapped keys to find out the range of thresholds where the (presumably unpressed) keys give inconsistent values (i.e., the highest threshold below which they will all start to read as pressed, and the lowest threshold above which they all start to read as unpressed). The 5 (or whatever number is configured) calibration bins are then distributed evenly across this range. This is largely the same in my firmware.

Next, pandrew's firmware does a binary search for each individual mapped key, trying to find the "tipping point" of uncertainty, where the result of 16 scans at the same threshold would result in 8 pressed and 8 not pressed values, i.e. half and half. The key is then assigned to the calibration bin closest to this threshold. In the end, each bin is assigned a final threshold as the average of the minimum and maximum threshold of the keys in that bin, and then that threshold is adjusted upwards by a magic number (from the configuration file) to hopefully push it so far up that it will not give phantom presses, and at the same time hopefully still low enough that actual presses register reliably.

This works pretty well in practice, as long as the magic number is configured well. I have a couple of mostly theoretical issues with it (i.e., please do not interpret this as criticism of the firmware; it works great and without it there probably wouldn't be my firmware for these keyboards!):

• First, this approach tends to always use all the bins. Scanning each bin takes almost a constant amount of time, i.e., scanning 5 bins takes almost 5 times longer than scanning 1 bin. In my experience, 2 bins can still be scanned under 1 millisecond (the maximum USB HID poll rate), and maybe 3 with some other optimisations and some luck in how the keys are distributed across columns in each bin. Often the range of values is also very small, and the bins end up very close together.
• Second, searching for the tipping point where 16 scans reads 8/8 seems theoretically unreliable: if we assume that we are testing at exactly the "correct" threshold where the probabilities are 50/50, the probability of getting that 8/8 result is the same as flipping a coin 16 times and getting exactly 8 heads and 8 tails (in any order), which is under 20%. Likewise, scanning a wrong threshold where the probabilities are unbalanced can still, with bad luck, end up giving the 8/8 result and the search is terminated. Thus, I feel that in theory the threshold found for each key can be any value from the "unreliable range" of thresholds. (This is mitigated a lot by averaging the bins.)

So, what I do instead is I do a slightly more dynamic bin assignment where the thresholds change as keys are assigned to them, and I also use some min/max values for the bin spacing to perhaps better support both small ranges and large ranges resulting from calibrating with some keys pressed (or incorrectly mapping an unpopulated key position, for example). Then, I scan an entire column in parallel (so 8 keys at a time; it takes the same time as scanning one key), and I do the binary searches in parallel for all of those keys, adjusting the thresholds of all of them until all 8 searches have terminated. And, instead of looking for the tipping point where the results of 16 scans are 8/8, I look for the lowest threshold where the results are 0/16 pressed/unpressed. (There are 65536 combinations for the results of 16 scans, and the 0/16 is only one of them, whereas there are 12870 ways it can be 8/8. So, even though it is still possible to have bad luck and end up with a false probabilistic result, it is a lot less likely, especially since the search does not terminate until all 8 keys have been resolved.)

Then, optionally, in the end I also merge nearby bins, to further reduce the number of bins. On my F62 and two F77 keyboards, it actually works fine to just reduce the number of bins to 1, but I recently changed it to be a bit less aggressive and instead it now ends up with 2 bins. As further post-processing, if the highest bin is "suspiciously far" (magic number) from the other bins and contains only a small number of keys (magic number), it is assumed that those keys were actually pressed during calibration and they are merged into the next highest bin. (Both the nearby bin merging and this outlier detection can be de disabled.)

My approach is not nearly as proven in practice as pandrew's, and I am still considering some ways to enhance it, but I believe it to be theoretically more robust, and it is definitely faster. However, due to the different calibration levels, the magic offset applied at the end (to avoid phantom presses) needs to be re-discovered for each keyboard type. With the F62 and F77 keyboards it seems to very forgiving (at least at the present age of the keyboards), but we had to reduce it somewhat for Muirium's AT keyboard to register keys reliably. (In retrospect, I should have anticipated that since I am looking for the edge, instead of the middle, of the range of uncertainty, and the aggressive bin merging results in larger bins).

I have done numerous other tweaks as well like saving calibration to EEPROM and using it to detect keys pressed on power up, in which case calibration can be skipped and the keys can start registering immediately. (Without this firmware keys pressed on power up tend to calibrate such that they will never be seen as pressed, since the assumption is that no key is pressed during calibration. I do manage to detect that fairly well, but then those keys will still have "random" calibration since the true idle threshold can't be measured.)

Anyway, having a more powerful controller is exciting, and I am also interested in porting my firmware to support it (although it means I have to largely reimplement the USB stack to work cross-platform). Everything is GPL licensed so you may also take the matrix calibration code from either my or pandrew's firmware as you wish; both have some lines of inline assembler related to the actual scanning, but the calibration parts are portable C.

Also, in case anyone actually read all the technical stuff above, I'm definitely interested in hearing ideas about how to improve the calibration. In particular, I would love to get rid of the magic threshold offset, but looking at the values available by calibration, it seems like that info might not be available. (I have two preliminary ideas pending implementation: one would be to do one round of interactive calibration to find and save the offset by having the user press and release two keys with an unpressed key in the middle, and then see the effect on that middle key. The other would be to see if an always-pressed pad has this effect on its adjacent keys, but I doubt it since there isn't a flipper.)

Links:

• My AAKBD firmware: https://github.com/arkku/aakbd
• Latest QMK with my matrix scanning (but the threshold offsets are not correct for all variants): https://github.com/arkku/qmk_firmware
• pandrew's QMK firmware: http://purdea.ro/qmk_firmware

edit: Re. utility, it is using a generic USB HID endpoint. The source file is util_comm.c, and it is somewhat specific to the LUFA library used by QMK for AVR microcontrollers. I have theoretically made a compatibility layer in my firmware, but TBH I have not been able to test it in practice (I had some issues getting it to work with Windows, and other issues building the utility for Mac). Also, the utility has a hardcoded USB vendor and product id and does not recognise the keyboard with any other ids. The utility's source codes are in both QMK firmwares linked above, in the directory keyboards/xwhatsit/util. My QMK version is using the newly-registered 0x4704 product id, pandrew's is using some repurposed id that seems to be common in unofficial firmwares, so even though the protocol is technically compatible, you need to build the utility for the specific id.

[Rico]

Thank you Arkku for this very detailed answer !

That's funny because I had already found your QMK repository and already started to dive in the source code
Thank you for confirming the util directory contains the Pandrew utility I was looking for.

I see that you and Pandrew went to great lengths for the calibration algorithm.
I have yet to see what will be really needed for the Leyden Jar PCB as it is a bit different than original Xwhatsit PCB:
- New MCU (RP02040)
- Hardware matrix scanning using PIO.
- On board regulated 3.3V reference for everything, including columns activation.
It may improve a few things ... or not
I have more testing to do to to confirm.

If it works well on my own F77, I have little clue it would work well on other boards.
Did you experienced significant differences in detected voltage levels across different boards with the official wcass controller ?

Again thank you very much for your help !

[Arkku]

- New MCU (RP02040)
- Hardware matrix scanning using PIO.
- On board regulated 3.3V reference for everything, including columns activation.
It may improve a few things ... or not

Much of the scanning time is due to writing the DAC thresholds, so if you can speed that up, it will improve things. If you have enough pins, you could theoretically start scanning rows instead of columns, i.e., currently the 8 rows in a single column are scanned at once, but if you had more pins you could instead scan the 16 columns in a single row at once. (I have not checked the specifics closely enough to know if either of these is the case.)

If it works well on my own F77, I have little clue it would work well on other boards.
Did you experienced significant differences in detected voltage levels across different boards with the official wcass controller ?

I have an F62 in zinc case, and two F77s, one zinc and one aluminium case. The range of uncertainty (the min and max) in non-pressed keys is about 20 units (out of 1024 DAC range and about 200 non-pressed to pressed full range) on all of them. The two zinc-cased keyboards calibrate to within 3 units of each other, and the aluminium-cased one calibrates to within about 5 of those two. So, rather consistent, at least when they are new.

[Rico]

The PCB does have 16 columns and 8 rows and I am pulsing the columns, i'll see how it works as is for the moment.
And I have yet to see if changing the DAC value during the scanning is needed in my case.

Glad to hear that you have consistent results with the different boards you have, this is a good thing

[Arkku]

The PCB does have 16 columns and 8 rows and I am pulsing the columns, i'll see how it works as is for the moment.

Yeah, that's how the current controllers work as well, and it is particularly nice to get the 8 rows as one 8-bit value on the 8-bit microcontrollers. But if you have the capability to pulse rows and read columns as a 16-bit value instead, it should double the speed.

edit: Of course that's excluding the DAC threshold changes. I have optimised those in a couple of ways: reducing the number of bins used, checking whether the threshold is already the one that is about to be written, and alternating the bin scan direction between asceding and descending (this eliminates one DAC write per scan beyond the first since the previous scan wrote that threshold already, e.g., with two bins it would be A B, (B) A, (A) B, etc.)

[Rico]

I'd need 4 comparator chips to do that instead of 2, but yes in theory it could be faster.
For now I have 640us taken to scan the matrix (can probably be faster later on), but I don't change the DAC value in between.

[allyoop]

Just got my F62 this week. Almost got lost by my local courier because they decided to leave it in a different apartment without me signing off on it.

Got Colemak keymap set via QMK on Linux, which required me to use LSHIFT+RSHIFT+B to enter bootloader as the compiled pandrew utility didn't detect the keyboard, and dfu-programmer to erase and flash the new firmware.

One of my shift keys kept getting stuck even after squeezing and adjusting the keycap stems, but good thing I bought extra keycaps to replace it with.

Question for those who bought the HHKB front print key set, are your F and J keys missing the tactile bump as well, or did I just get a bad batch or something?

IMG_2846.jpg (308.82 KiB) Viewed 9995 times

IMG_2845.jpg (337.13 KiB) Viewed 9995 times

[Muirium]

Ouch!

I’m not in this group buy—it just rumbles on, a perennial storm in Deskthority—so I’ve no idea if those homeless home keys are a defect or design. But I’d use whichever variant feels best to your fingers in use. If the HHKB-less ones, then I’d also substitute out the now overhanging front legended H, N and M keys, if you have regular ones to spare.

Spoiler:

I’m assuming Ellipse copied the HHKB’s front legends, down to those numpad operators all the way down there. I never used them for numerics, myself, and wound up taking their Fn+spots for layer keys. But for sure, the nub-less F and J are a mistake.

[Ellipse]

riverstyx did you follow the instructions in the firmware section regarding installing the drivers? You have to scroll down a bit in that section. Usually this affects those flashing firmware for the first time on a particular computer. That may fix your issue - please keep us posted!

The HHKB Front Print keys did not have nubs by design, though I recently ordered some nubbed HHKB Front Print keys if anyone is interested - there would be no charge to replace the key (or substitute the key, if it has not yet shipped), outside of shipping costs, if you ordered this key before and prefer the nubbed variation (please PM or email me for details). For many layouts it might be preferable to be nubbed (probably most of them), though for some layouts Colemak, Dvorak, etc. these keys are not nubbed.

Also one more free replacement offer (besides the cost of shipping): please note that the ". Del" key should technically be a ", Del" key for the following sets, to be more authentic to these layouts: Brazil, Swedish-Finnish, Dutch, Dutch Modern

[taraskremen]

Interesting re. the rubber rings, I'd not considered that. I used to use red o-rings on my cherry blues so I've just tried one and it gives a nice soft finish to the keypress, also the key still works fine with the original springs. Right.... this may take some time. (just checked - 1.5mm thick)


For wrist wrest I have an old thick double gel thing (although I can't find it online anymore "CaseLogic GL-1") which is the perfect height for the ModelF for me (~35mm), being a really soft gel I find it moulds around my wrist and I tend to have it slid slightly back:


(having trouble getting a picture of the height! but about this:)

Thanks for the information and images! I am the person on whose behalf Ellipse posted the o-ring mod and questions. I started a thread on reddit about a custom palm rest for the Model F. I linked it in the original e-mail, but it looks like the link didn't make its way to the forum. It can be found here.

The red o-rings, if you are using the same ones I have, are quite a bit thinner than the blue ones, so it is a lot easier to use the stock springs with them. Most keys just work, and for those that don't, the springs have to be stretched just a bit to move the actuation point higher than the o-ring contact. My blue o-rings measure 1.7mm in thickness, but some of that is lost when they are stretched to fit around the keycap post. There are probably better o-rings, with a larger diameter, to use for this, but I just had many of these around already. The red o-rings I have measure 1.36mm in thickness and have a slightly larger diameter, so they don't stretch as much around the keycap post. I am not sure where the "0.2mm" and "0.4mm" measurements come from that are printed on the package (maybe the nominal radius?).

I write software for a living and, before this mod, I could really only use the F62 about one day a week before I felt significant pain in my finger tendons. With the reduced travel, that interval is now about 2-3 days. I do wonder if there are lighter springs I could use, at least for the outer keys. Topre had the right idea with varying the switch force based on which finger is used to press the key on the Realforce -- I am now doing the same with all of my MX boards (e.g. MX Blue for alphas, MX Brown for modifiers). Currently, it's the thumb and little finger that are giving me the most trouble. The thumb issues are mostly due to not having a decent wrist/palm rest that is the correct height for the board and the distance between the top of the space bar and the nearest resting surface (the case), and the pinkie pain is mostly felt in the tendon running along the edge of my forearm after prolonged use. I attribute the latter to the high spring force, and I never had this problem with any other board: it's usually just my thumbs that give me trouble.

The gel rest in the pictures looks interesting. It is rather difficult to find one tall enough for this board, but it's good to know that they are out there. From the images, it looks like your F77 if flat on your desk. Is this the case? In any event, thanks for sharing!

[thefarside]

Sorry to change topic, but regarding the NYC meet and presentation, I can’t host or participate sadly, but was curious if ellipse would be interested in a Zoom type of presentation. I think that would reach the largest audience given the geographic spread of everyone.

I’m a latecomer to this project and would be interested in learning the trials and tribulations that lead to a keyboard in my hands. I’d also be interested in seeing a live demo of the beamspring keyboard. If you’ve been secretly working on a blue alps recreation I’d also be interested in seeing that too

[darkcruix]

Sorry to change topic, but regarding the NYC meet and presentation, I can’t host or participate sadly, but was curious if ellipse would be interested in a Zoom type of presentation. I think that would reach the largest audience given the geographic spread of everyone.

I’m a latecomer to this project and would be interested in learning the trials and tribulations that lead to a keyboard in my hands. I’d also be interested in seeing a live demo of the beamspring keyboard. If you’ve been secretly working on a blue alps recreation I’d also be interested in seeing that too

That would be awesome!!!!

[wolfman]

I think it's been over a year since my last update. I have been working on refactoring of pandrew's QMK firmware for inclusion into the QMK official repo.

I have decided to focus only on the keyboards that I physical possess and can test. I have the Model F Labs F62 and F77.

My refactored QMK firmware for the F62 and F77 is in the keyboard/model_f_labs directory in the source.

I added documentation via ASCII graphics in the source for the layouts and most of the key-maps.

Updated key-maps from Ellipse and me.

There are VIA enabled keymaps for both the F62 and F77. Updated versions of Roland Huber's VIA design files for the VIA utility are in the via keymap directories. The VIA enabled firmware does not support the pandrew xwhatsit utility.

VIA support requires that each model of keyboard to have a different USB VID and PID pairs. My firmware uses the default QMK VID of 0xFEED. The PID for F62 is 0x0F62. The PID for the F77 is 0x0F77.

Since I changed the the USB VID and PID had to do a hack of pandrew xwhatsit utility.

The source has been updated with pandrew's changes up to Dec 4 2021.

The QMK official repo was merge into the source on June 15 2022.

The only thing that remains to be tested is the solenoid. I am waiting for the solenoid driver that forgot to include in my original order.

I think my source is close to being a candidate for inclusion into QMK.

I need to try to port in Arkku changes.

Link to my "model_f_labs_f62_f77" GitHub candidate branch for QMK:
- Sub branch of mjw_xwhatsit branch
https://github.com/matthew-wolf-n4mtt/q ... bs_f62_f77

Updated pandrew xwhatsit utility:
- Tested only on Linux
- Only sees one keyboard when multiple are present.
https://github.com/matthew-wolf-n4mtt/p ... it-utility

My dev QMK branch "mjw_xwhatsit"
- Has README with notes on refactoring.
- Includes keyboards/ibm
- Includes keyboard/sneakyrobb
https://github.com/matthew-wolf-n4mtt/q ... w_xwhatsit

[Gladstone]

Just got my F77 in this week and tried out compiling from source with Arkku's and pandrew's QMK forks. Thanks for all your hard work! To be honest, having QMK + HHKB layout on a Model F was my main reason for buying in, and I'm very satisfied. Ran into a few gotchas that other people may want to know about, though:

In Arkku's firmware, some of the `_Static_assert` calls in `matrix.c` don't have a string literal parameter (see lines 417-425), which isn't optional till C++ 17. With a default build environment from `qmk setup`, firmware won't compile. Each of these `_Static_assert`s throws a really uninformative console error:

Code: Select all

keyboards/xwhatsit/matrix.c:423:62: error: expected ',' before ')' token
     _Static_assert(CAPSENSE_KEYMAP_ROW_TO_PHYSICAL_ROW(4) < 8);

After adding dummy messages to all these calls, e.x.

Code: Select all

    
    // Existing code: 
    // _Static_assert(CAPSENSE_KEYMAP_ROW_TO_PHYSICAL_ROW(0) < 8)
    _Static_assert(CAPSENSE_KEYMAP_ROW_TO_PHYSICAL_ROW(0) < 8, "Foobar")
    

I was able to compile just fine.

Also, on both arkku's and pandrew's firmware, enabling QMK dynamic macros in a regular keymap causes the keyboard to soft-brick (in regular QMK, no Via / Vial enabled). I have no idea why this is. Maybe it's related to the memory overwriting issues that NathanA ran into with Vial Tap Dance and combos? Someone should probably draw up a list of what QMK features don't work with the capsense implementation.

[darkcruix]

I think it's been over a year since my last update. I have been working on refactoring of pandrew's QMK firmware for inclusion into the QMK official repo.

I have decided to focus only on the keyboards that I physical possess and can test. I have the Model F Labs F62 and F77.

My refactored QMK firmware for the F62 and F77 is in the keyboard/model_f_labs directory in the source.

I added documentation via ASCII graphics in the source for the layouts and most of the key-maps.

Updated key-maps from Ellipse and me.

There are VIA enabled keymaps for both the F62 and F77. Updated versions of Roland Huber's VIA design files for the VIA utility are in the via keymap directories. The VIA enabled firmware does not support the pandrew xwhatsit utility.

VIA support requires that each model of keyboard to have a different USB VID and PID pairs. My firmware uses the default QMK VID of 0xFEED. The PID for F62 is 0x0F62. The PID for the F77 is 0x0F77.

Since I changed the the USB VID and PID had to do a hack of pandrew xwhatsit utility.

The source has been updated with pandrew's changes up to Dec 4 2021.

The QMK official repo was merge into the source on June 15 2022.

The only thing that remains to be tested is the solenoid. I am waiting for the solenoid driver that forgot to include in my original order.

I think my source is close to being a candidate for inclusion into QMK.

I need to try to port in Arkku changes.

Link to my "model_f_labs_f62_f77" GitHub candidate branch for QMK:
- Sub branch of mjw_xwhatsit branch
https://github.com/matthew-wolf-n4mtt/q ... bs_f62_f77

Updated pandrew xwhatsit utility:
- Tested only on Linux
- Only sees one keyboard when multiple are present.
https://github.com/matthew-wolf-n4mtt/p ... it-utility

My dev QMK branch "mjw_xwhatsit"
- Has README with notes on refactoring.
- Includes keyboards/ibm
- Includes keyboard/sneakyrobb
https://github.com/matthew-wolf-n4mtt/q ... w_xwhatsit

These are GIGANTIC news! Thanks for the work here - this will change a lot and simplifies things.
I have a variety of the original IBM keyboards (Buckling and Beam) and I believe most of the variants of the reproductions for testing.

[Arkku]

I need to try to port in Arkku changes.

It should be easy, especially as my repository has the latest QMK changes as of today already. In theory just copying matrix.c, matrix_manipulate.h and util_comm.c should work to make it compile, but as a caveat, the CAPSENSE_CAL_THRESHOLD_OFFSET is values in the config.h files are untested for all other keyboards than the F62 and F77.

There are VIA enabled keymaps for both the F62 and F77. Updated versions of Roland Huber's VIA design files for the VIA utility are in the via keymap directories. The VIA enabled firmware does not support the pandrew xwhatsit utility.

I think in theory both could be supported but it would need making the utility handle multiple VID/PID pairs instead of one hardcoded value, and probably util_comm.c would need to be called from via.c.

BTW, may I ask why VIA, not VIAL? AFAIK the latter doesn't need the tool to specifically support the keyboard, since the keyboard reports its own configuration, which would probably also solve the need to have unique VID/PID? (One big advantage of this is that those of us who like to use IBM's USB VID on converted IBM keyboards could do so, and same for those who need the Apple Fn key and thus need to use Apple's VID.)

[Arkku]

In Arkku's firmware, some of the `_Static_assert` calls in `matrix.c` don't have a string literal parameter (see lines 417-425), which isn't optional till C++ 17.

Thanks for reporting this, I have added the string literals. (Also, the code is C, not C++, so the correct standard would be C23 which makes this mistake less excusable. However, that file is strongly GCC-specific due to inline assembler and such, so I don't have the pedantic warnings enabled for it.)

Also, on both arkku's and pandrew's firmware, enabling QMK dynamic macros in a regular keymap causes the keyboard to soft-brick (in regular QMK, no Via / Vial enabled). I have no idea why this is.

If it happens with both versions, running out of RAM is definitely a possibility. The atmega32u2 used in these keyboards only has 1K RAM… I really wish the controllers had used the atmega32u4 instead, but too late at this point, and an aftermarket replacement controller should probably be something entirely different like the project Rico is working on.

Things you can try to reduce RAM usage to verify this:

• in config.h, change CAPSENSE_CAL_BINS to a smaller number (it is now 5, try 2)
• in rules.mk, change RAW_ENABLE to no
• replace util_comm.c with an empty file (echo >util_comm.c in the command line should do it, you can later restore original with git restore util_comm.c)
• in the wcass.c file (or whichever file is in the innermost directory for that specific keyboard and controller), delete the line with KEYBOARD_FILENAME (I think this is a borderline bug in the firmware to store this in RAM instead of progmem, and I just changed it in my fork)
• also disable any other enabled things in rules.mk that you are not using

(edit: if you are using my fork, you can skip the wcass.c and possibly also util_comm.c steps, but do a "git pull" first since I just changed it)

If you do all of these and the issue disappears, then it is almost certainly RAM.

[Gladstone]

Also, on both arkku's and pandrew's firmware, enabling QMK dynamic macros in a regular keymap causes the keyboard to soft-brick (in regular QMK, no Via / Vial enabled). I have no idea why this is.

If it happens with both versions, running out of RAM is definitely a possibility. The atmega32u2 used in these keyboards only has 1K RAM… I really wish the controllers had used the atmega32u4 instead, but too late at this point, and an aftermarket replacement controller should probably be something entirely different like the project Rico is working on.

Things you can try to reduce RAM usage to verify this:

• in config.h, change CAPSENSE_CAL_BINS to a smaller number (it is now 5, try 2)
• in rules.mk, change RAW_ENABLE to no
• replace util_comm.c with an empty file (echo >util_comm.c in the command line should do it, you can later restore original with git restore util_comm.c)
• in the wcass.c file (or whichever file is in the innermost directory for that specific keyboard and controller), delete the line with KEYBOARD_FILENAME (I think this is a borderline bug in the firmware to store this in RAM instead of progmem, and I just changed it in my fork)
• also disable any other enabled things in rules.mk that you are not using

(edit: if you are using my fork, you can skip the wcass.c and possibly also util_comm.c steps, but do a "git pull" first since I just changed it)

If you do all of these and the issue disappears, then it is almost certainly RAM.

Thanks for the tips! Must be the RAM, then. Following your steps and setting DYNAMIC_MACRO_SIZE to 64, dynamic macros worked just fine. Haven't tested with the full 128, though.

[Arkku]

FWIW I finally got around to fixing the compatibility of my AAKBD firmware and pandrew's utility… They are now compatible, but only if the utility's hardcoded USB vendor and product ids match the firmware (this is the case with my QMK repository). I also changed the implementation to store the keyboard name in ROM (program space) instead of RAM, and updated util_comm.c to work for both QMK and AAKBD using the same file.

[doureios]

[…] but was curious if ellipse would be interested in a Zoom type of presentation. I think that would reach the largest audience given the geographic spread of everyone.

That would be awesome!!!!

Zoom would be awesome for all of us who are far from NYC who also want participate in real time by pushing the “Raise Hand” button to ask a question (that is, if Ellipse even wants to have a Q&A section). Unfortunately, I doubt that I will be able to attend a Zoom meeting at a certain time, nor do I have any questions to ask.

I get that the presentation is private, but I wonder if they would allow a recording to be published? May I offer an unsolicited suggestion? If the presentation is merely video recorded and and posted on YouTube, I’d certainly watch it (and probably more than once). It could reach all of the rest of us who have bought into this project whenever it is convenient for us, but best of all, it would give the rest of the world an opportunity to see it too. This would be the perfect thing to post as the introduction YouTube video. The people who newly discover this project will get a nice summary in presentation form instead of having to glean from the mountain of information on the website.

[Arkku]

Thanks for the tips! Must be the RAM, then. Following your steps and setting DYNAMIC_MACRO_SIZE to 64, dynamic macros worked just fine. Haven't tested with the full 128, though.

I updated my repository with the other changes, so only rules.mk and config.h are needed for this after git pull. And if it works, I would also suggest restoring CAPSENSE_CAL_BINS to 3, that way there is room for two real bins and one trash bin in case calibration is ever done with a key accidentally held down.

[repo_code]

quick PSA: it's possible to load firmware under Linux without Atmel Flip.

The newest version of Flip with Linux support is from 2017 and appears to lack support for the atmega32u2, so it's likely not an option.

To flash firmware:

* Build pandrew's qmk_firmware from git, as described on https://www.modelfkeyboards.com/manual/
* Use its keyboards/xwhatsit/util/util program to put the controller into bootloader mode. This works just like on Windows.
* Instead of Atmel Flip, use this process to flash:

Code: Select all

> sudo dfu-programmer atmega32u2 erase
> sudo dfu-programmer atmega32u2 flash F77_-_HHKB_2U_backspace_-_0-9.hex 
> sudo dfu-programmer atmega32u2 reset

The dfu-programmer is a common Linux package; Ubuntu has it, anyway.

I've only tested this with a stock firmware, but it should work with any.

Good luck!

[Arkku]

quick PSA: it's possible to load firmware under Linux without Atmel Flip.

The dfu-programmer is a common Linux package; Ubuntu has it, anyway.

dfu-programmer also works for macOS, it is easy to install from Homebrew. When using my firmware, you can also get the keyboard to bootloader mode with another Homebrew package: dfu-util. My command for entering bootloader and flashing the firmware is:

Code: Select all

dfu-util -e && sleep 2 && dfu-programmer atmega32u2 erase && dfu-programmer atmega32u2 flash modelf77.hex && dfu-programmer atmega32u2 launch

(The sleep is there to give the keyboard time to reset, since dfu-programmer doesn't wait.)

[Ellipse]

How long should the presentation be? I imagine it as being a brief overview of the project, plus questions, while a forthcoming book to offer more detail.

[thefarside]

How long should the presentation be? I imagine it as being a brief overview of the project, plus questions, while a forthcoming book to offer more detail.

Possibly up to an hour long. The topics would be at your discretion but my curiosity would be on:

• Project origins

• What factors made you realize this could be created

• Motivation behind closing the 4704 Model F

• Product development trials and tribulations

• Anything interesting you learned along the way

• Advice for other creators or recreators

[xji]

Hey folks, I know this must be a completely dumb question regarding the assembly, though I just can't for the life of me figure it out (new to this space). I also couldn't find an answer via a cursory search, so I have to ask it here.

I'm at the last step of assembling the keyboard (F62 model with HHKB layout), where all that's left is the bottom row of keys. However, apparently the lower end of the keys would overlap the stabilizer wire of the spacebar? Here's a photo:



The spacebar came preinstalled. Should I remove it and install it again? However, I see the below image on the manual page also seems to show the stabilizer wire sitting right against the bottom row, which made me really confused.



Or is there are special set of keys that I should install for the bottom row?

Thanks a lot for your help!

[taraskremen]

What problem(s) is the overlap between the bottom row of the keys and the space bar stabilizer wire causing? The keys should bottom out before they can hit the wire.

One issue I ran into is that the play in the space bar allows it to rotate enough that it interferes with the "./>" key on the right. On the left, there is a cylinder inside the space bar that keeps it more or less aligned with an otherwise unused barrel, but there is no cylinder on the right, allowing the extra play. I solved this by carefully shaving down the interfering edges of the "./>" key and space bar in that area with fine grade sandpaper, but I suppose putting something in the right tab to prevent the stabilizer wire from moving so far forward could be another viable solution.

[Arkku]

I'm at the last step of assembling the keyboard (F62 model with HHKB layout), where all that's left is the bottom row of keys. However, apparently the lower end of the keys would overlap the stabilizer wire of the spacebar? Here's a photo:

In the first photo it looks like the stabilizer wire has moved on top of the hooks, whereas in the second photo it is correctly installed. It should be in both hooks, then the keys will sit above it but bottom out before they hit the wire.

(To answer the question: yes, reinstall the spacebar to be like the second photo.)