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

[RainehDaze]

Not really sure what to do exactly with one of my extra ` keys.

Following up on my super-informal poll from several weeks back, regardless of what you choose to change it to, which of those two keys do you expect you would change: the far-left one, or the far-right one?

I'd probably change the left one at this point out of habit, but at the same time I could easily go back to having ` familiarly there because the pause key is now much further away than it was on my F77 layout, and that's annoying since I want the compose key surprisingly often.

[webwit]

Following up on my super-informal poll from several weeks back, regardless of what you choose to change it to, which of those two keys do you expect you would change: the far-left one, or the far-right one?

Those HHKB "fans" who use a FSSK or F104 should be excommunicated from the Church!

[resonator]

Those HHKB "fans" who use a FSSK or F104 should be excommunicated from the Church!

Nah. The Happy Hackers appear to be modeled on a Sun Type 3 which have a ton of keys. I'd recommend using that to decide what the default layout should be for a HHKB style on a larger keyboard.

[NathanA]

Those HHKB "fans" who use a FSSK or F104 should be excommunicated from the Church!

The Happy Hackers appear to be modeled on a Sun Type 3 which have a ton of keys. I'd recommend using that to decide what the default layout should be for a HHKB style on a larger keyboard.

Unfortunately, this doesn't help. Sun Type 3 appears to have a function row (immediately above the number row, no gap), but naturally the left-most key on that row is F1. The whole question about what to do with F104 and FSSK in this regard is which other already-existing key should be duplicated by default on the left-most key of the number row: `/~ (also exists on the right-most key of the same row) or Esc (already exists as top-left-most key of the entire keyboard, to the left of F1). The Sun Type 3 isn't a useful as a reference point for this.

The later Sun keyboards (types 5/6/7), however, when the so-called "Unix layout" versions of them are considered, might be. The ANSI and ISO versions both have `/~ as leftmost number row key, have Esc to the left of F1, and have a 2U Backspace on the right side of the number row, as expected. The "Unix" ones, though, mimic the Type 3 by changing leftmost number row key to Esc, moving Backspace down to the next row on the 1.5U key above Enter, and splitting the 2U key above it into two 1Us, with rightmost being `/~. So, as you say, HHKB-style. So if Esc got moved down to be in the number row, what does it do with the key to the left of F1 that's formerly known as Esc? ...good question, 'cause that key has a blank label on every picture I've found!! Anybody know what that key does (assuming it does anything)?

(By the way, my idea of a "perfect compromise" here on the HHKB keymaps for F104 and FSSK was to keep original Esc as Esc, move `/~ to the rightmost key, and set the leftmost to be the QMK-specific Esc/~. My logic was that ~ almost certainly gets used more often by more people than ` does, and Esc/~ sends Esc when unshifted, and ~ when shifted. So non-HHKB devotees with muscle memory who expect Shift+that key to send a ~ will not be caught off-guard, and HHKB fans with muscle memory who expect pressing that key alone to send Esc will also not be caught off-guard. This is in fact what I did for the default HHKB layouts for these models, but I'm considering whether or not to bother with changing that to something else in the next firmware release. If, however, most purchasers of these "large" HHKB models are going to remap the leftmost key anyway rather than the rightmost one, then there's a "who cares what that key is set to by default...it's going to get changed by the user anyway" argument to be made.)

[Ellipse]

NathanA would you be able to post a guide to making the various flashable keymaps including the hex and vil files? I remember you noting that it was not straightforward, but it would help in case folks wanted to share fully-customized, flashable keymaps of their own.

[NathanA]

NathanA would you be able to post a guide to making the various flashable keymaps including the hex and vil files?

Hmm didn't I send you instructions on how to do it in PMs once upon a time? I'll have to re-look at past messaging history but I feel like I did...

The .vil files have always been easy:

1. Create your layout in Vial.
2. Go to File > Save.

Simple.

It's the .hex files that aren't so easy. I used to build special versions of firmware which included a custom QMK macro I wrote that would actually cause the keyboard firmware to "type" the contents of the hex file out onto the screen. So I'd open up Notepad, press the key on the keyboard that ran that routine, and wait for it to finish. But I left that routine out of the shipping firmware, in part because it took up valuable flash space that was best used for other, more useful features.

I eventually figured out a much easier way:

1. Create your layout in Vial (or load the .vil file you previously created and saved).
2. Put keyboard in bootloader mode.
3. Run "dfu-programmer atmega32u2 erase --force"
4. Run "dfu-programmer atmega32u2 read --eeprom > output.hex"

(where "output.hex" is whatever you want to call the resulting .hex file)

It's simple in terms of the number of steps. The main downside with this method is that the ATmega bootloader doesn't allow you to read from the EEPROM memory unless you first wipe the flash memory. Which is totally freaking stupid, but there's nothing I can do to change that. (I assume it's some kind of misguided security-related feature.) What this means is that even if you are creating a bunch of layouts for a single keyboard model, you have to re-flash firmware in between creating each layout. Not only is that inconvenient and a huge waste of time, but it causes a lot of wear and tear on the flash memory. So when I make these, I actually use one of the spare defective wcass controllers you sent for this purpose.

It would be awesome if there was some kind of script or utility that could read a .vil and auto-generate a .hex from that, but writing such a thing would basically require that it be reading from QMK source code files in order to be able to figure out what valid keycodes & their values are. So it would be complex, as well as require that you have QMK/Vial firmware source on your computer.

One thought that I've had is to maybe patch the Vial app so that you can run it from the command-line and feed it a .vil file to load into the keyboard, and then immediately exit (the GUI would not display at all). Then instead of shipping both .vil and .hex files, I'd only have to ship the .vils, and the flash script would just run Vial to load the .vil into the keyboard EEPROM at the end of the process. Even if I got that to work, the main downside is that it would require everybody to install Vial on their computer first before they could run the firmware flash scripts, and it would have to be a custom version of Vial at that (unless I can submit my change to the author of Vial and get him to include it in a future release). It's ultimately probably better for the firmware upgrade package to be able to work stand-alone (without a dependency on Vial), which is why I haven't pursued this, either.

If anybody has a brilliant idea I haven't considered, though, I'm all-ears...

[resonator]

The "Unix" ones, though, mimic the Type 3 by changing leftmost number row key to Esc, moving Backspace down to the next row on the 1.5U key above Enter, and splitting the 2U key above it into two 1Us, with rightmost being `/~. So, as you say, HHKB-style. So if Esc got moved down to be in the number row, what does it do with the key to the left of F1 that's formerly known as Esc? ...good question, 'cause that key has a blank label on every picture I've found!! Anybody know what that key does (assuming it does anything)?

I have no idea what that blank key originally did. I can't think of a sensible default so mapping it to nothing makes sense to me. Today, it can easily be remapped, so it's no big deal if someone has a good idea for how they personally want to use it.

I noticed that there are also variants with a split right shift, the extra key being a line-feed button. That apparently sends an ASCII 10 (https://stackoverflow.com/questions/309 ... -form-feed). I'm not sure how useful that button is today with UTF-8. I'm a bit of a purist so I'd probably do that and allow it to be remapped by the user.

For a default map, I'd copy historical examples (even if you need to do a mashup) and allow people to adjust them to their own liking. But that's just me.

(By the way, my idea of a "perfect compromise" here on the HHKB keymaps for F104 and FSSK was to keep original Esc as Esc, move `/~ to the rightmost key, and set the leftmost to be the QMK-specific Esc/~.

Apart from the doubled-up Esc, that's been my setup for 10+ years now. I just use the Esc/~ combo on the number row.

[NathanA]

I have no idea what that blank key originally did.

My assumption is that it was "originally" Esc, as I have to believe it only came into being on Type 5 when they decided to make a bigger keyboard that also had "IBM Enhanced Layout" style ANSI/ISO variants. I assume this because it has no previous analogue on older Sun keyboards. When they added it to make the full-size ANSI/ISO keyboards possible, they also kept a more Sun-like variant around for the purists. Whether or not the key does anything on the Sun-like variant when it is paired with original (e.g. SPARCstation) hardware and (Solaris) software is what I'm wondering...

I noticed that there are also variants with a split right shift, the extra key being a line-feed button. That apparently sends an ASCII 10 (https://stackoverflow.com/questions/309 ... -form-feed). I'm not sure how useful that button is today with UTF-8. I'm a bit of a purist so I'd probably do that and allow it to be remapped by the user.

For all past Ellipse boards with split right shift (HHKB-style where rightmost key is 1U), the smaller right key is mapped to Fn. So to keep things consistent, I'm pretty sure that's what I also did for F104/FSSK, and then made the right-side middle 1U button between RCtrl and RAlt either another Win key or the "right mouse click" key (can't remember which off top of my head).

For a default map, I'd copy historical examples (even if you need to do a mashup) and allow people to adjust them to their own liking. But that's just me.

That's basically what I did. Just trying to figure out if there is an argument for a more sane default that covers a greater multitude of people and gives the highest percentage of new users the best fresh-out-of-box experience, is all.

Apart from the doubled-up Esc, that's been my setup for 10+ years now. I just use the Esc/~ combo on the number row.

As a user of F77 (so no doubled-up Esc), same here. Esc/~ for the win, baby.

[Ellipse]

NathanA would you be able to post a guide to making the various flashable keymaps including the hex and vil files?

Hmm didn't I send you instructions on how to do it in PMs once upon a time? I'll have to re-look at past messaging history but I feel like I did...

The .vil files have always been easy:

1. Create your layout in Vial.
2. Go to File > Save.

Simple.

It's the .hex files that aren't so easy. I used to build special versions of firmware which included a custom QMK macro I wrote that would actually cause the keyboard firmware to "type" the contents of the hex file out onto the screen. So I'd open up Notepad, press the key on the keyboard that ran that routine, and wait for it to finish. But I left that routine out of the shipping firmware, in part because it took up valuable flash space that was best used for other, more useful features.

I eventually figured out a much easier way:

1. Create your layout in Vial (or load the .vil file you previously created and saved).
2. Put keyboard in bootloader mode.
3. Run "dfu-programmer atmega32u2 erase --force"
4. Run "dfu-programmer atmega32u2 read --eeprom > output.hex"

(where "output.hex" is whatever you want to call the resulting .hex file)

It's simple in terms of the number of steps. The main downside with this method is that the ATmega bootloader doesn't allow you to read from the EEPROM memory unless you first wipe the flash memory. Which is totally freaking stupid, but there's nothing I can do to change that. (I assume it's some kind of misguided security-related feature.) What this means is that even if you are creating a bunch of layouts for a single keyboard model, you have to re-flash firmware in between creating each layout. Not only is that inconvenient and a huge waste of time, but it causes a lot of wear and tear on the flash memory. So when I make these, I actually use one of the spare defective wcass controllers you sent for this purpose.

It would be awesome if there was some kind of script or utility that could read a .vil and auto-generate a .hex from that, but writing such a thing would basically require that it be reading from QMK source code files in order to be able to figure out what valid keycodes & their values are. So it would be complex, as well as require that you have QMK/Vial firmware source on your computer.

One thought that I've had is to maybe patch the Vial app so that you can run it from the command-line and feed it a .vil file to load into the keyboard, and then immediately exit (the GUI would not display at all). Then instead of shipping both .vil and .hex files, I'd only have to ship the .vils, and the flash script would just run Vial to load the .vil into the keyboard EEPROM at the end of the process. Even if I got that to work, the main downside is that it would require everybody to install Vial on their computer first before they could run the firmware flash scripts, and it would have to be a custom version of Vial at that (unless I can submit my change to the author of Vial and get him to include it in a future release). It's ultimately probably better for the firmware upgrade package to be able to work stand-alone (without a dependency on Vial), which is why I haven't pursued this, either.

If anybody has a brilliant idea I haven't considered, though, I'm all-ears...

Thanks! Below are my notes from the manual on the preprogrammed firmware layers - I believe the F104/FSSK standard ANSI/ISO sets Fn as the key between Right Alt and Right Ctrl.

Current preprogrammed keypress commands in Vial and QMK:

Depending on your keyboard model, the FN key is factory set to the key between Right Alt and Right Ctrl (latest F104/FSSK/etc. models), the key to the right of the shorter right shift (for all HHKB style models), or Right Ctrl (for the older models like F62/F77).

Hold down the keys Fn+Spacebar+
T–>Toggle the Solenoid On/Off Any key HPT_TOG
+= Increase Solenoid dwell time HPT_DWLI
-_ Decrease Solenoid dwell time HPT_DWLD
E–>EEPROM Reset (erases all settings like if you adjusted a dwell time for solenoid)
R–>Reset (enter bootloader)
D–>Debug

Hold down the keys Fn+

Esc–>Power
F1–>Brightness Down
F2–>Brightness Up
F6–>Media Stop
F7–>Media Prev
F8–>Media Play
F9–>Media Next
F10–>Media Mute
F11–>Vol Down
F12–>Vol Up
Print Screen–>Eject

[NathanA]

I believe the F104/FSSK standard ANSI/ISO sets Fn as the key between Right Alt and Right Ctrl.

Sorry, yes, just in case it wasn't clear to everyone based on what I wrote, that was what I was trying to communicate: on HHKB split shift boards, Fn is the extra key from splitting the shift, but otherwise it's the right extra 1U key between Ctrl and Alt.

[...] or Right Ctrl (for the older models like F62/F77).

This is actually another thing I'm sorely tempted to change in the default layouts of both of those models. Both to facilitate wider consistency, but also because it just never made sense to have the key that is usually RCtrl instead act as Fn. A 1.5U "Fn" key is not included in the standard key set, everybody puts a "Ctrl" there, so I think it was really confusing for a lot of people (and this also got a mention both in Chyros' review *and* in LGR's review). Maybe this was driven by a need to shoehorn NumLk somewhere, and that right middle key was the only place it could really work? That space for NumLk only makes sense if you're using right block options #2 and #5, though, and even then you probably don't need to hit it all that often. Maybe for those two layouts I'll make NumLk accessible on some key on the Fn layer instead...

[Ellipse]

Here's a nice and quick review and photo from a user on reddit. The photo compares the Model F to the original Model M keyboard. The case dimensions are exactly the same but the Model M looks bigger due to the camera angle with the Model M keyboard being in front of the Model F.

https://www.reddit.com/r/MechanicalKeyb ... impressed/

And a nice photo from reddit user Phil_Goodman, with the F104 in Industrial Gray and a 48 inch computer monitor!

https://www.reddit.com/media?url=https% ... e381f297d7
https://www.reddit.com/r/modelm/comment ... _pictures/

One more photo and review - this one has a red Panic button from Unicomp installed in the Esc key position:
https://www.reddit.com/r/MechanicalKeyb ... d_finally/

[nac5605]

Can't wait for my B122 to arrive! But, in the meantime, I figured I'd share some info with everyone who might have had the same problem as me when it came to finding keycaps for the board.

The F13-F24 keys and the 10-key macro cluster on the board don't officially have any keycaps in the set that Ellipse sells on their website. I searched literally everywhere online for keycaps that fit, but could only find 1 set of the macro keys in SA profile on Apos. The set I got on Apos didn't even match the mold of the keycaps that were sold on the modelfkeyboards website either.

However, recently I came across a website called yuzukeycaps.com, which allows you to make completely custom dye-sub pbt caps and order them. This is not an ad for them and I have no affiliation, btw. I made a request to add the B122 layout to their website, and they obliged: https://yuzukeycaps.com/keyboards/model-f-b122. Right now it's only cherry profile, but they should be adding KAM profile keycaps (a more sculpted and spherical profile than cherry) soon.

Just thought this would be useful for those that bought the B122 layout but couldn't find keycaps to fit it. Again, not an ad and not affiliated, just like the service.

[NathanA]

Can't wait for my B122 to arrive!

Just FYI but I think you might've posted to the wrong thread.

[Ellipse]

Chyrosran22 has just released the trailer! It is a wild video!

[RainehDaze]

Hmm, having a bit of a weird one with this, that I'm not quite sure of the cause. It sometimes seems that the H key is registering slightly behind everything else? So, I'll try to type the or that or this and it'll come out as htat. I can mitigate it by typing slower, but… it's not like the h actually has trouble registering, so I'm a bit confused.

[pilcher]

Hmm, having a bit of a weird one with this, that I'm not quite sure of the cause. It sometimes seems that the H key is registering slightly behind everything else? So, I'll try to type the or that or this and it'll come out as htat. I can mitigate it by typing slower, but… it's not like the h actually has trouble registering, so I'm a bit confused.

Have you used pandrew's utility to check the signal levels?

[RainehDaze]

Hmm, having a bit of a weird one with this, that I'm not quite sure of the cause. It sometimes seems that the H key is registering slightly behind everything else? So, I'll try to type the or that or this and it'll come out as htat. I can mitigate it by typing slower, but… it's not like the h actually has trouble registering, so I'm a bit confused.

Have you used pandrew's utility to check the signal levels?

Somewhat related problem, I can't seem to get the keyboard to show up in it. Which is strange, I seem to have all the requirements installed to run the make script.

[pilcher]

Hmm, having a bit of a weird one with this, that I'm not quite sure of the cause. It sometimes seems that the H key is registering slightly behind everything else? So, I'll try to type the or that or this and it'll come out as htat. I can mitigate it by typing slower, but… it's not like the h actually has trouble registering, so I'm a bit confused.

Have you used pandrew's utility to check the signal levels?

Somewhat related problem, I can't seem to get the keyboard to show up in it. Which is strange, I seem to have all the requirements installed to run the make script.

Since you mention make, are you on Linux?

If so, you may already be aware of this, but I wrote this doc that describes the steps I took to build the utility on Fedora 40.

https://gist.github.com/ipilcher/9a14d8 ... 71a282fa74

[Ellipse]

RainehDaze please follow the manual as the fix for your specific issue is noted there. And please be sure to build the latest version of the pandrew utility on linux, or download the latest one in the manual inside the QMK-layout-files.zip file there, as older pandrew versions will not detect the keyboards.

[RainehDaze]

Have you used pandrew's utility to check the signal levels?

Somewhat related problem, I can't seem to get the keyboard to show up in it. Which is strange, I seem to have all the requirements installed to run the make script.

Since you mention make, are you on Linux?

If so, you may already be aware of this, but I wrote this doc that describes the steps I took to build the utility on Fedora 40.

https://gist.github.com/ipilcher/9a14d8 ... 71a282fa74

Yeah, I'll give that a shot; I'm guessing there's something that hasn't set up right and it's just failing invisibly, since it still opens well enough. Just... no keyboard detection. And I can see you've got quite a few more steps than just doing the build in the utils folder.

[NathanA]

And I can see you've got quite a few more steps than just doing the build in the utils folder.

It matters what the source of your "utils" folder is.

If you just cloned the repo hosted at purdea.ro and built from that, the util will not detect your keyboard.

You need to apply some additional source code patches in order to build a version that can talk to your keyboard. Those patches are included in the firmware bundle downloadable from here.

There is a lot of recent discussion about this in this here thread. pilcher's instructions for building on Fedora are good, though of course only apply to Fedora. Furthermore, if all you want to do is build the util & not also install and host a whole QMK build environment, you can distill & simplify pilcher's instructions even further, as I explained here.

[idollar]

My F104 came in yesterday!

.......

Are these keyboards shipped with xwhatsit-like controllers ? Really ?
I thought that Ellipse was using the newer controllers.

I recognise the wonderful work done by xwhatsit, but its evolution = Leyden-Kar (Rico's controller here: https://github.com/mymakercorner/Leyden_Jar) is such a game changer that I would not consider any model f with a different controller.


Cheers

[NathanA]

Are these keyboards shipped with xwhatsit-like controllers ? Really ?
I thought that Ellipse was using the newer controllers.

He will be, on the F122, new B104, and B122.

With big productions, there's this little thing called "lead times". It takes time to get all of the ducks in order, get your bill-of-materials all lined up & bought/paid-for & inventories secured so that they're available when you need to go to manufacturing (and not suddenly backordered or discontinued), test and approve samples for mass-production, etc.

As I understand it, the newer FSSK and F104 models were already locked-in before the Leyden Jar project was actually finished and ready to go. To switch controllers at this stage would have set back / delayed production even further. After all, there are reasons why the new FSSK and F104 are shipping now, but the F122 still is not.

You know how you hear people talk about how, for example, Apple already knows what components are going to be in the iPhone models that are scheduled to come out not just next year, but 2 years out? And how it's probably already too late to change anything about them, *two years* ahead of time? Because when you're building things at that kind of scale, it really takes that long to get everything that needs to get done between now and then, and those plans need to be set in stone way ahead of time? Yeah. That.

I recognise the wonderful work done by xwhatsit, but its evolution = Leyden-Jar is such a game changer that I would not consider any model f with a different controller.

That's definitely your prerogative, and you probably aren't even the only one that feels that way. Heck, I wish my F77 that I've already had for a couple of years had come with Leyden Jar. But it freaking literally didn't exist back then, at least as a final product.

I also wish the brand-new computer that I bought right before the new chips were announced had the new chip in it instead of the old one. Such is life. There will always be a newer thing just around the corner that's better than the one you just got. But if you wait for every new thing, you'll never pull the trigger (or, if you are the one making things, you'll never ship anything).

Fortunately, the xwhatsit is a very time-tested controller at this point. And at the end of the day, my guess would be that most people buying pre-assembled keyboards rather than building their own just want to be able to sit down at their new keyboard and start using it...breaking a soldering iron out isn't their idea of a good time, nor is dorking around with writing or tweaking keyboard firmware. I would guess (and hope) that for such users (likely the vast majority of them), the stock xwhatsit will be fine.

[idollar]

With big productions, there's this little thing called "lead times". It takes time to get all of the ducks in order, get your bill-of-materials all lined up & bought/paid-for & inventories secured so that they're available when you need to go to manufacturing (and not suddenly backordered or discontinued), test and approve samples for mass-production, etc.

It does not have to do with lead times. I guess that it has to do with stock and economies of scale.

As I understand it, the newer FSSK and F104 models were already locked-in before the Leyden Jar project was actually finished and ready to go. To switch controllers at this stage would have set back / delayed production even further. After all, there are reasons why the new FSSK and F104 are shipping now, but the F122 still is not.

The Leyden-Jar was completed on May 2023.
https://github.com/mymakercorner/Leyden_Jar/tags

You know how you hear people talk about how, for example, Apple already knows what components are going to be in the iPhone models that are scheduled to come out not just next year, but 2 years out? And how it's probably already too late to change anything about them, *two years* ahead of time? Because when you're building things at that kind of scale, it really takes that long to get everything that needs to get done between now and then, and those plans need to be set in stone way ahead of time? Yeah. That.

Ellipse's bussiness and suppy chain cannot be compared to Apple

I recognise the wonderful work done by xwhatsit, but its evolution = Leyden-Jar is such a game changer that I would not consider any model f with a different controller.

That's definitely your prerogative, and you probably aren't even the only one that feels that way. Heck, I wish my F77 that I've already had for a couple of years had come with Leyden Jar. But it freaking literally didn't exist back then, at least as a final product.

I also wish the brand-new computer that I bought right before the new chips were announced had the new chip in it instead of the old one. Such is life. There will always be a newer thing just around the corner that's better than the one you just got. But if you wait for every new thing, you'll never pull the trigger (or, if you are the one making things, you'll never ship anything).

I meant "now a days, I would not consider any model f with a different controller.".
I have used xwhatsit controllers during many years. They allowed for the fssk. I was very happy about them. But one cannot compare the AVR with the RP2040. The later are simply better.

Fortunately, the xwhatsit is a very time-tested controller at this point. And at the end of the day, my guess would be that most people buying pre-assembled keyboards rather than building their own just want to be able to sit down at their new keyboard and start using it...breaking a soldering iron out isn't their idea of a good time, nor is dorking around with writing or tweaking keyboard firmware. I would guess (and hope) that for such users (likely the vast majority of them), the stock xwhatsit will be fine.

xwhatsit, in my opinion, is the past. A VERY GOOD past that we have enjoyed. The work that he did is great. Moreover, the documentation that came with the controller is simple increadible!. It is the base for many of the posts that we read. Ellipse's bussiness would not exist without him. But Rico has designed a really good evolution.
For 399$ + shipping, I would have expected to have the latest and better controller.

Summarising:

- I do not need to be explained how a supply chain works. Really, an MBA was enough
- Personally, Today, I would not purchase a model f based on a xwhatsit controller. Or better said, after testing the Rico's evolution, I would seriously consider replacing it.
BTW: this is what I am doing with all my model-f equipped with xwhatsit.

Cheers

[NathanA]

It does not have to do with lead times. I guess that it has to do with stock and economies of scale.

The Leyden-Jar was completed on May 2023.

I believe your timelines are off.

Yes, the schematic for Rev. 3 was published in May 2023.

Ellipse announced the full-size F keyboards in April 2023.

According to Keebtalk posts by Rico, he didn't receive his own first samples of actual Rev. 3 boards until August, and started doing validation testing in September.

I have not been privy to the development process but can only imagine that testing revealed additional things on either the hardware or software side that needed tweaking. He chimed back in in February (2024, to be clear) saying things are proceeding "slowly but steadily". I'm not sure but I'd guess this is not his full-time job, just something he works on for fun.

A final version of a diagnostic app similar to what pandrew wrote did not get released until May 2024. Other anticipated features like split-keyboard support or PS/2 support still are in development.

Obviously the following is guesswork on my part, so I'll let Ellipse speak for himself, but if I were him, and my choices were to wait for Leyden Jar to be finalized (which was not guaranteed), or to buy enough parts to ensure that enough xwhatsits could get made in the quantities that he needed controller boards for (remember that even by 2023 some of the worldwide chip shortages post-pandemic still were a thing!), I would have picked the latter. It only makes sense.

I'm sure he has a stockpile of fully assembled xwhatsits that he had committed to buy as a result. Likely not so easy to back out of those kinds of commitments.

F122/B104r2/B122 PCB designs have more than 8x16 rowsXcols, so the xwhatsit design cannot be used for those. And thus, the FSSK and F104 are released first.

I'd guess that after his xwhatsit stock has been depleted, and if Ellipse continues to make FSSKs and F104s, he will almost surely sub in Leyden Jars for future manufacturing runs of those.

[idollar]

I'd guess that after his xwhatsit stock has been depleted, and if Ellipse continues to make FSSKs and F104s, he will almost surely sub in Leyden Jars for future manufacturing runs of those.

You correctly spotted the reason why I said that I am surprised

I would not go for one of Ellipse's keyboards which are based on xwhatsit controllers just to empty his stock.
If I would have to do it, I would replace the controller. This cost would add to the $399+shipping.

The same applies to the unicom mini and the new controller they are designing ... I would like to see which controller will be used.

[pilcher]

I would not go for one of Ellipse's keyboards which are based on xwhatsit controllers just to empty his stock.
If I would have to do it, I would replace the controller.

Why would you need to replace the controller? Yes, the Leyden Jar is more capable, but what functionality would you actually be missing with an Xwhatsit-based F104?

You can certainly wait for the current stock to be exhausted and hope that Ellipse eventually produces Leyden Jar-based F104s, but that discounts the value of actually using an F104 until a new revision exists (which may be never).

[Ellipse]

As noted before, the main reason for the switch was because of the expected discontinuation of the mass availability of the Atmel chips, especially felt during the chip shortage several years ago. Without Rico's great controller we may not have been able to build Model F and Beam Spring controller replacements to keep these keyboards running long into the future.

The real-world functionality and performance are identical for these controllers in my testing, so please do not think you will notice anything different. The big advantage of the RP2040-based Leyden Jar is that it has more memory and the potential for advanced functionality such as PS/2 support and split keyboard communication between controllers, though the xwhatsit supports at least 3 layers which is plenty for the needs of almost all new Model F users.

NathanA is correct that only recently did the Leyden Jar controller finish prototype testing and was considered ready for production, and that we are waiting for the xwhatsit supply to be done before switching everything to Leyden Jar. Also, as of today the Leyden Jar still does not have firmware for these other keyboards, so the Leyden Jar controller is not yet ready for these other keyboards. I did test an older Rev2 Leyden Jar that worked fine with the new Model M classic style F104, so I do not foresee any issues expanding support to additional keyboards.

[idollar]

As noted before, the main reason for the switch was because of the expected discontinuation of the mass availability of the Atmel chips, especially felt during the chip shortage several years ago. Without Rico's great controller we may not have been able to build Model F and Beam Spring controller replacements to keep these keyboards running long into the future.

The real-world functionality and performance are identical for these controllers in my testing, so please do not think you will notice anything different. The big advantage of the RP2040-based Leyden Jar is that it has more memory and the potential for advanced functionality such as PS/2 support and split keyboard communication between controllers, though the xwhatsit supports at least 3 layers which is plenty for the needs of almost all new Model F users.

I disagree.

The first thing that I noticed when installing (Rico's) RP2040 Leyden Jar was its speed. It is noticeble faster.
Rico has used RP2040 PIO ... (reference to simple explanation on how PIO works here https://tutoduino.fr/en/pio-rp2040-en/) which takes the matrix scanning out from the main processor. A very beautiful solution which contributes to speeding up the controller response.

NathanA is correct that only recently did the Leyden Jar controller finish prototype testing and was considered ready for production, and that we are waiting for the xwhatsit supply to be done before switching everything to Leyden Jar.

A nice way to state that it is stock related

Also, as of today the Leyden Jar still does not have firmware for these other keyboards, so the Leyden Jar controller is not yet ready for these other keyboards. I did test an older Rev2 Leyden Jar that worked fine with the new Model M classic style F104, so I do not foresee any issues expanding support to additional keyboards.

The original FSSK was not supported by the Leyden Jar firmware. This did not stopped me to compile my own. Moreover, I had to do it twice as I have daily use two different FSSK versions: the original v0r1 prototype and the group but v1r0.
I do not see any problem in doing it for other keyboards. Actually as I said I plan to migrate my other Model Fs to the Leyden Jar.

BTW: do you ship your keyboards Firmware VIAL ? My xwhatsit ended up without memory when I tried to compile VIAL on them.

I keep thinking that the Leyden Jar is a game changer. This is why I was surprised to read that AVR-xwhatsit keyboards are sold at the end of 2024.

Well done Rico. Respect !

[idollar]

I would not go for one of Ellipse's keyboards which are based on xwhatsit controllers just to empty his stock.
If I would have to do it, I would replace the controller.

Why would you need to replace the controller? Yes, the Leyden Jar is more capable, but what functionality would you actually be missing with an Xwhatsit-based F104?

Basically one can enable all VIAL options:

• More layers (I have 10)
• More macros (I have 32)
• I could enable TapDance (I have complied it to support 32)
• I could enable Combos (I have compiled it to support 32)
• Key overwrites
• Mouse
• The new OLED display which I just installed in my original FSSK
• Any additional function that you may want to add by updating the QMK/VIA code. The limit is the sky (ok, the limit is the memory of the RP2040 )

DSCF0298-small.jpg (1.42 MiB) Viewed 672 times

I cannot remember how many of the above fitted in my xwhatsit before I discontinued them.

You can certainly wait for the current stock to be exhausted and hope that Ellipse eventually produces Leyden Jar-based F104s, but that discounts the value of actually using an F104 until a new revision exists (which may be never).

Do not get me wrong. I have never tried the Ellipse's keyboards but I am sure that any model-f like keyboard is great.
My only point is that it can get even better with a Leyden Jar