F62+F77 orders now open! New Kishsaver+Industrial Model F Keyboards

pandrew

29 Aug 2020, 15:00

warty wrote:
29 Aug 2020, 07:33
My F77 came today! Yea! Some of the keys don't work... bummer.

The keys that don't respond... it's not the springs, and I don't think it's the hammers, as I can see that they move up/down with the springs.

I tried to run ibm_capsense_usb_util.app v0.9.0 (latest on the xwhatsit site). I'm familiar with this program because it's what I use in my beam spring. But it just freezes if I select either of the 2 devices (that aren't the beam spring). Disconnecting the beam spring didn't help either.

I PM'ed for an invite to the QMK beta. There's probably nothing I can do in the meantime?

dead keys: z, (but not x), c, v, b, n, m, ",", . , right shift , keypad '.' (for me; so row 4, col 3); every key on the bottom row, including spacebar.
Yeah, that definitely sounds like a physical problem somewhere. It is most likely the wires that are soldered between the controller PCB and sense PCB, like darkcruix said, however it could also be on the controller itself.

Looks like two of the rows are dead, I have highlighted all of the traces on the controller PCB related to those two rows. Since they are next to eachother I think it's most likely that they are shorted together somewhere.

Please see the attachments, and inspect those areas, and the attached wires visually. (If you have a multimeter, you might even try to beep it out to see if they are shorted)

There's a chance though, especially if it's the wires, that once you open up the keyboard the short goes away, just because you moved the wires a little.

Andrei
Attachments
bottom.png
bottom.png (66.67 KiB) Viewed 1554 times
top.png
top.png (141.7 KiB) Viewed 1554 times

warty

29 Aug 2020, 16:35

I didn't see any obvious shorts on visual inspection, for the 2 wires you highlighted. I checked between them with the multimeter at various points in the circuit, and they didn't show a short. the far 2 on the left, and the far 2 on the right do show shorts (don't know the circuit, assume that's ok). I can upload pics of front and back of board if that would be helpful. I did check that those 2 wires have continuity between the xwhatsit and the main board (at least to the pads on the main board).

But... after I put it back together and plugged it in... the keys that work and don't work changed. Current situation:

not working:
  • esc, 1,
    tab,
    capslock/ctrl,
    left shift, right shift,
    left control (bottom row, far left), spacebar, right ctrl (far right)
not working on numpad:
  • top row,
    cols 2 and 3 of 2nd row
    col 2 of 3rd row
    col 1-2 of 4th row
    all of 5th row, but col 3 is kind of intermittent (looks like sense threshold issue to me)

pandrew

29 Aug 2020, 16:55

warty wrote:
29 Aug 2020, 16:35
the far 2 on the left, and the far 2 on the right do show shorts (don't know the circuit, assume that's ok).
Yes, that's expected, those are all ground pins
warty wrote:
29 Aug 2020, 16:35
But... after I put it back together and plugged it in... the keys that work and don't work changed. Current situation:
Hmm, strange, the list of keys you gave now make it look like you have maybe 3 columns going wrong. Except there are a few keys that you haven't listed that are on those columns, (like left windows key), and a few that are not on those columns (like space, and the bottom right keys that you said was intermittent).

Have you tried reducing the threshold?
How does qmk behave?

Andrei

clickclack

29 Aug 2020, 18:02

My compact F62 had a similar problem when delivered. It turned out to be the soldered contacts of the ribbon cable on the PCB piercing the tape over them and shorting on the inside of the case.

warty

29 Aug 2020, 18:09

oooh. That was it. If I take the back cover off, all the keys work as expected.

Andrei: I'm still working on getting QMK setup. qmk setup is returning some kind of error about not being able to run bin/qmk, which is odd. I can run that if I use a full path. Dinking around with export now to see why what I'm doing doesn't work.

warty

29 Aug 2020, 18:24

I put a strip of electrical tape over the yellow tape, it seems to be enough for now. I can imagine one of those pins is going to make it's way through the electrical tape and short again though.

Ok, now I'm typing with the F77. Sound and feel are quite nice. I haven't used my Model F AT in a year or so, since the soarer kind of went south. But this is a great feel. Somehow, I didn't really grok how heavy this thing was going to be. I have a Model F 122, it's not light. And a DisplayWriter, which is even heavier. But this is ridiculous! Are you sure these cases aren't made of Uranium?

Need to change the key layout to make it more mac/me-friendly, so back to the QMK salt mines...

User avatar
darkcruix

29 Aug 2020, 18:30

warty wrote:
29 Aug 2020, 18:24
I put a strip of electrical tape over the yellow tape, it seems to be enough for now. I can imagine one of those pins is going to make it's way through the electrical tape and short again though.

Ok, now I'm typing with the F77. Sound and feel are quite nice. I haven't used my Model F AT in a year or so, since the soarer kind of went south. But this is a great feel. Somehow, I didn't really grok how heavy this thing was going to be. I have a Model F 122, it's not light. And a DisplayWriter, which is even heavier. But this is ridiculous! Are you sure these cases aren't made of Uranium?

Need to change the key layout to make it more mac/me-friendly, so back to the QMK salt mines...
Glad to hear this. This is great news! QMK takes some moments to get used to, but I can tell you - the options you have to configure things are ... crazy. When your Enter key can act as such plus GUI when held or double tab on ESC and you get a tilde ... you know it is amazing.

warty

29 Aug 2020, 19:11

I'll have to take your word for it, as I can't get the QMK environment even set up. Hmm. maybe I can see if my win7 computer still runs...

User avatar
darkcruix

29 Aug 2020, 21:31

warty wrote:
29 Aug 2020, 19:11
I'll have to take your word for it, as I can't get the QMK environment even set up. Hmm. maybe I can see if my win7 computer still runs...
I have quickly installed Linux in a VM (Ubuntu) and prepared everything in there. Makes everything so much more easy. I just copy the compiled hex file over and flash it on my system where the keyboard is connected to.

pandrew

30 Aug 2020, 00:33

@ clickclack -- cool, thanks for solving this! I wouldn't have thought of this, since I don't have my keyboard yet, and wasn't aware something like this was a possibility.

@ warty -- sorry I can't help you set up a QMK build environment on a mac, I will have to refer you to official QMK documentation, and beyond that there is a QMK discord channel with lots of activity, you might be able to get some help there. Anyway do PM me for any questions specific to qmk firmware for xwhatsit.
* qmk environment setup docs, including mac: https://beta.docs.qmk.fm/tutorial/newbs_getting_started
* qmk discord: https://discord.com/invite/Uq7gcHh
As darkcruix is suggesting, a VM could be a workaround.
Also please feel free to start by building on my configurator instance. You really only need a local environment if you start using some advanced features like macros, or anything that requires you to write C code. Even some tapping functionality is available from it. (although for full tapdance you need to write C code)

Once you get to the point where configurator is not enough, you can convert your json keymap to a .c keymap, so you don't get locked into configurator.

Andrei

warty

30 Aug 2020, 02:46

Thanks Andrei, I'm going to take darkcruix's idea, that should work great. I love the fact I have 20+ years of my computing history on this mac, thanks to apple's setup / transition thingie, but I've accumulated so much crud in /opt/local, usr/bin/ etc that I'm never very surprised when even a brew install fails.

Thanks @darkcruix! Much better than trying to revive the win7 box.

troglotype

30 Aug 2020, 17:55

@warty I have set it up the QMK build environment on macOS and flashed both a F62 and an F77 successfully. Happy to help.

User avatar
darkcruix

30 Aug 2020, 20:13

troglotype wrote:
30 Aug 2020, 17:55
@warty I have set it up the QMK build environment on macOS and flashed both a F62 and an F77 successfully. Happy to help.
Can you post a quick guide here? I‘d like to add it to the technical reference I am working on.

warty

30 Aug 2020, 20:50

Mixed results so far. I made a keyboard config hex with Andrei's online configurator. I shorted the prog pads to get into boot loader mode, and uploaded the firmware with QMK Toolbox. That wiped the cap sense logic of course, and also reduced the keyboard to less than useful state. I did that a few times to make sure it wasn't just a quirk of uploading.

I was able to build the util app on the mac, which makes it easier to update the firmware. The keypress monitor and signal level monitor are interesting. Just about every key on my keyboard is getting detected all the time. which is probably why it's not useful as a keyboard in current state.
signal_level.png
signal_level.png (133.16 KiB) Viewed 1183 times
It's not obvious to me how to change the capsense levels. I see this going on in matrix.c:
#if CAPSENSE_CAL_ENABLED
calibration();
#else
dac_write_threshold(CAPSENSE_HARDCODED_THRESHOLD);
dac_write_threshold(CAPSENSE_HARDCODED_THRESHOLD);
dac_write_threshold(CAPSENSE_HARDCODED_THRESHOLD);
#endif

and I can see the hardcoded threshold is defined to 142. I can see the design allows for finer grain setting, but I haven't looked deep enough yet to see how that happens, and how that gets stored in the config file(s).

So to get somewhere, should I just start that hardcoded threshold at 250, compile, and see what happens? (mine seem to be hovering around 240 with keys unpressed).

warty

30 Aug 2020, 21:18

Happiness: I had the case off and the xwhatsit board rotated up so I could get to the reset pads. That was fine, but I forgot that the capacitance is very much affected by whether the board is grounded to the metal plate or not. screwed the board back down, unplugged and replugged, and it's working like A CHARM!

FWIW, qmk compile works just fine on my mac, despite the errors that qmk setup was returning. <scratches head>.

Thanks for help everyone.

pandrew

30 Aug 2020, 21:36

warty wrote:
30 Aug 2020, 21:18
FWIW, qmk compile works just fine on my mac, despite the errors that qmk setup was returning. <scratches head>.
.
QMK setup probably also tries to fetch some dependencies for arm-based keyboards, so it's possible that something failed
that only affects you if you want to build for some other keyboard
warty wrote:
30 Aug 2020, 20:50
and I can see the hardcoded threshold is defined to 142. I can see the design allows for finer grain setting, but I haven't looked deep enough yet to see how that happens, and how that gets stored in the config file(s).
Please ignore that hardcoded threshold. I don't think anyone has used it so far, and I only implemented it as a convenience just in case. I may even remove it in the future. Auto-calibration is enabled by default. And what it does is it measures the un-pressed state of the key when you plug the keyboard in (for this reason you must not press keys while plugging it in). It adds a "Threshold Offset" to the measured value, and uses that as a threshold. It also bins the keys into threshold bins in order to not slow down the scanning too much.

So ideally what I would like is for threshold adjustment to be completely unnecessary.

The threshold offset itself is not something I can measure automatically though. ( I can't use the calibration pads for that purpose, because they have a much higher signal level than real pressed keys.). So the threshold offset is something that matters, and if you are having problems, you might want to tweak it. In fact there were a very few people who reported that the threshold offset was not large enough for them, so I am planning to change the default value to increase it. I expect keyboards that are already stable to remain stable with that change, and the very few keyboards that weren't completely stable to get stable.

Once that change is made, I expect the value will be good enough that nobody will have to go tweaking any threshold-related settings.

If anyone has to adjust threshold settings, I want to know about it, to figure out why.

I will make an announcement when I make the change, for people to know about it and test it.

Andrei

troglotype

30 Aug 2020, 23:03

darkcruix wrote:
30 Aug 2020, 20:13
troglotype wrote:
30 Aug 2020, 17:55
@warty I have set it up the QMK build environment on macOS and flashed both a F62 and an F77 successfully. Happy to help.
Can you post a quick guide here? I‘d like to add it to the technical reference I am working on.
Pandrew is working on a guide (I wanted to contribute to it but didn't have the time because of medical issues in the family) and I'm sure you can include the relevant passages in your reference for the keyboard. If I have time in the coming days, I will try to go through these passages again.

The only reason the process is a teeny tiny bit cumbersome right now is that you need to recreate the testing setup Pandrew has been using.

I think the guide should reflect a state in which the keyboards have become part of the official QMK online configurator. Then the only thing that needs explaining is how to use the utility to enter the bootloader to flash the firmware. Perhaps we can ask Ellipse to host pre-compiled binaries on his website, if he isn't doing so already.

I must admit that I didn't even look at the temporary online configurator pandrew has setup. I found it easiest to directly modify the keymap.c files. The official QMK guide explains the key codes so clearly that even a noob like me was able to make the necessary changes.

P.S. I encourage every F62 user to consider setting up the three right modifies and the shift key to act as arrow keys when they are pressed alone. I find this an extremely elegant solution.

warty

30 Aug 2020, 23:16

Are the keyboards going to be part of the official QMK online configurator? If so, I agree we should write to that. If not, I think maybe we could have "Easy Configuration" and "Expert Configuration" chapters. Easy something like:
- Downloading the QMK util utility (we'd definitely want to host binaries for Windows and Mac if possible; linux we'd have to put in the build steps)
- Downloading the QMK toolbox (links to official sites)
- Configuring your keyboard with the online configurator
- Putting the keyboard into boot loader mode with Util app
- Flashing the keyboard with the Toolbox app

Keeping it as simple as that will make it a lot easier for folks just starting out.

Expert Config chapter could include:
- getting the GitHub code
- getting QMK system installed
- understanding the config flies
- building a configuration
- all the ways to get to boot loader mode, including physical/electrical
- all the ways to flash the board
- Other options: how to acquire and use the old cap sense firmware?

daphnis

31 Aug 2020, 12:14

Wish I had a wooden logoless palmrest for my F62.

troglotype

31 Aug 2020, 13:11

@warty I think that's a great idea! Pandrew is already working on something like that. Perhaps get in touch with him so he can give you access to the work in progress and you can make comments / expand the doc?

User avatar
Snazzy

01 Sep 2020, 00:07

Hi everyone.

I've had my F77 for about a month and I love it save for one very frustrating issue: my 'o' key. It exhibits two undesired behaviors: (1) it will often duplicate characters resulting in far too many 'o', and (b) it will often appear delayed by not registering until after I've already typed a characters. For example, "block" will become "blcok."

I have opened up the case, cleaned the contacts and the flipper, reseated the spring, and everything seems to be in order. I have even downloaded the xwhatsit software in an attempt to adjust the threshold, but no setting seems to fix the issue and it's only present on one key on the whole board. Any ideas or suggestions of what I could possibly try to mitigate the issue? Thanks.

User avatar
darkcruix

01 Sep 2020, 00:16

Snazzy wrote:
01 Sep 2020, 00:07
Hi everyone.

I've had my F77 for about a month and I love it save for one very frustrating issue: my 'o' key. It exhibits two undesired behaviors: (1) it will often duplicate characters resulting in far too many 'o', and (b) it will often appear delayed by not registering until after I've already typed a characters. For example, "block" will become "blcok."

I have opened up the case, cleaned the contacts and the flipper, reseated the spring, and everything seems to be in order. I have even downloaded the xwhatsit software in an attempt to adjust the threshold, but no setting seems to fix the issue and it's only present on one key on the whole board. Any ideas or suggestions of what I could possibly try to mitigate the issue? Thanks.
I can only give you the advice to ask getting included in the QMK firmware beta. I am pretty certain the issue will vanish, when you change to the QMK firmware.

User avatar
Snazzy

01 Sep 2020, 00:30

darkcruix wrote:
01 Sep 2020, 00:16
I can only give you the advice to ask getting included in the QMK firmware beta. I am pretty certain the issue will vanish, when you change to the QMK firmware.
Thanks man. Just DMed pandrew. Hopefully I can get this figured out.

Ellipse

01 Sep 2020, 02:12

Forgot to mention this earlier but last week I posted the August update on the blog, which summarizes all the progress and postings since the prior update:
https://www.modelfkeyboards.com/blog/

Today I provided the factory with detailed tolerance specifications for the dye sublimation alignment and they are planning on making the first trial of a new jig design. For those who did not see my recent dye sub updates, I was very impressed that the quality of the sublimation itself met or exceeded the quality of the highest percentile of IBM's Model F sublimation work, even comparing them under my stereo microscope.

Hi Snazzy, that sounds like a bug with the xwhatsit firmware; I'd recommend upgrading to QMK beta firmware to be 100% sure. In the past I have recommended switching to the 0.9.2 alternative debounce 11 firmware, from the 0.9.2 original debounce 6 firmware that I installed on the keyboard. https://www.modelfkeyboards.com/wp-cont ... rmware.zip

In the past month or so I switched to QMK for all the new Model F's that are shipping. I continue to be surprised with the xwhatsit issues that have come up in recent months based on xwhatsit's otherwise solid history in my experience dating back to 2014. I do hope that these xwhatsit firmware-specific issues can be resolved so that there will always be multiple firmware options for these keyboards.

Ellipse

01 Sep 2020, 05:07

I thought I'd share instructions someone sent me on using the xwhatsit utility and compiling the xwhatsit hex firmware files - someone was asking me about this recently. As always, this would be done at your own risk.

Compiling/running the xwhatsit capsense utility on Linux:

For Ubuntu:
1. Open the Software & Updates program and select Community-maintained free and open-source software (universe)
2. Extract the precompiled file into a directory
3. Open a terminal and cd into that directory
4. In a terminal run: sudo apt update && sudo apt install gcc gcc-avr avrdude
5. sudo apt install build-essential
6. sudo apt install qtcreator
7. Run sudo ./ibm_capsense_usb_util


How to compile the firmware hex file on Linux (easier to do than on Windows):

For Ubuntu:
Open the Software & Updates program and select Community-maintained free and open-source software (universe)
In a terminal, run: sudo apt update && sudo apt install make gcc gcc-avr avrdude avr-libc build-essential
To get patch files from GitHub, click on the commit and in the URL, append .patch and then save that as a .patch file. pandrew's work to create 0.9.2 firmware can be found here: https://github.com/purdeaandrei/ibm_cap ... its/master
Move the patch files into the src directory
In the terminal cd into the src directory
To change the files based on a patch file, run patch < filename.patch
Run patch files in order from oldest to newest (start with debounce patch, then patch 1, then patch 2, then patch 3 (the latter three patches from pandrew).
Run make and copy the ibm_capsense_usb.hex file that was created
The default debounce is 11. To create the debounce 6 version, edit the scan.h file and change the line with #define SCAN_DB_THRESH_TOP 11 - change to a 6 (I used to use the debounce 6 version when sending out the Brand New Model F keyboards)
Run make and copy the ibm_capsense_usb.hex file that was created

consensual-penis

02 Sep 2020, 01:11

Any word on the dyesub caps?

User avatar
Scarpia

02 Sep 2020, 13:00

darkcruix wrote:
27 Aug 2020, 15:01
Scarpia wrote:
27 Aug 2020, 07:28
After a few weeks of use, the space bar on my F77 has developed a ‘squeak’ on the upstroke if I hit it on the far left.

I figure the squeaky sound can be fixed with some kind of lubricant- but what kind and where? Any ideas would be most appreciated.
I used Silicone Grease for my F122 (I rpelaced the space bar with a Model M one) and this did the trick. This is also available in Sweden (or a similar brand):
https://dentamidshop.dreve.de/dentamide ... -3974.html
In case anyone else has this problem, silicone grease lightly applied (to the outsides of the barrels and the friction points for the stab wire) worked perfectly for me. Thanks darkcruix!

The brand you linked was only available to buy from Germany or the UK and it would have cost eur 23 shipped for 35g, so I went to my local hardware store and got 70g of automotive silicone grease for less than eur 7 :-) and it worked brilliantly.

Ellipse

02 Sep 2020, 22:17

Dye sub update: Attached is a high res scan of the latest sublimated keys of excellent quality (same as what was posted a few weeks ago with my phone camera) vs. the exact originals they were based off of.

The new ones as sublimated by the factory's equipment appear to be a touch wider and thicker, so the finalized artwork will be updated to counteract those changes. (I did not account for the higher than expected amount of dye migration/bleed during the sublimation process, as the finalized artwork was an exact match to the originals)

As noted earlier the sublimation quality is excellent, as shown in these scans, looking at the keys in person, and examining them with my stereo microscope. The factory is working on the alignment and the jigs.

It is interesting to note the amount of uneven wear on older, well-used IBM keys compared to brand new ones.
Scanned Keys - new sublimation vs. original 6110344 Jun 1984.jpg
Scanned Keys - new sublimation vs. original 6110344 Jun 1984.jpg (2.69 MiB) Viewed 389 times

User avatar
Snazzy

03 Sep 2020, 04:01

Snazzy wrote:
01 Sep 2020, 00:30
darkcruix wrote:
01 Sep 2020, 00:16
I can only give you the advice to ask getting included in the QMK firmware beta. I am pretty certain the issue will vanish, when you change to the QMK firmware.
Thanks man. Just DMed pandrew. Hopefully I can get this figured out.
Just an update: talked to pandrew and the QMK beta fixed the issue I was having. Worked great and it went a lot better than trying to use the ibm_capsense app. Nice! Thanks for the recommendation.

User avatar
darkcruix

03 Sep 2020, 08:55

Snazzy wrote:
03 Sep 2020, 04:01
Snazzy wrote:
01 Sep 2020, 00:30
darkcruix wrote:
01 Sep 2020, 00:16
I can only give you the advice to ask getting included in the QMK firmware beta. I am pretty certain the issue will vanish, when you change to the QMK firmware.
Thanks man. Just DMed pandrew. Hopefully I can get this figured out.
Just an update: talked to pandrew and the QMK beta fixed the issue I was having. Worked great and it went a lot better than trying to use the ibm_capsense app. Nice! Thanks for the recommendation.
Glad to hear - hope we will see a video about the best keyboard ever built!

Post Reply

Return to “Group buys”