AcidFire's modular keyboard system - Axios [In Development]

[zr0h]

In fact I suspect minimalism suits only pure Latin/English users and I'm not sure that such minimalism would be even suitable for other European languages with 4 levels (or even 8 levels which I have seen in a German layout file in XKB).

German https://www.neo-layout.org has 6 levels, but only 2 of them are for German letters. The rest make it _easier_ to do certain things. Which is the entire point of layers there. More layers are a good thing. Especially for numbers. If you take a look at Neo, you’ll see that the entire right half of the 4ᵗʰ layer is dedicated to essentially a number pad. I’ve never used the regular digit keys since I started using Neo. It’s more convenient and it’s faster.

Now take a look at the ErgoDox. It’s especially well suited for multiple layers with its large thumb clusters. I have shift and both Neo layer shifts there. It works wonders. Here’s a link to my layout, if you’re interested: https://github.com/kaimi/tmk_keyboard. By the way, I even have both numbers and F-keys on the first layer; it’s not impossible.

[AcidFire]

I'm not dead yet! As others have noticed, my personal life has just be a little crazy. Between getting married, some scary medical news that thankfully turned out to be not so scary, and some other exciting news I can't quite share yet I've been a bit preoccupied. However, this keyboard is still very much a passion project for me and it would take a lot more for me to ever let it go.

A major slowdown for me has been prototyping, I've shared quite a bit that seems to work out in renders and even some base printing, but overall just doesn't quite work in the end. The best example I can give is the extra keys at the top of the board. While they've been something I've very much wanted to integrate, stability comes back to be a huge pain time and time again. I know flip flopping on key layouts does not help you guys at all with figuring out how you want to lay out your setups, and I'm terribly sorry it's been a bit of back and forth with it. I'll be posting what the final layout will look like in a second, with two notes:
1) The main cluster PCBs do have extra holes for the arrow clusters. Because of our current manufacturing plan, this is something we should be able to offer as an option right out of the gate.
2) The oft neglected external number pad will be available in two layouts, one for a standard number pad and the other for F keys/hot keys if you need direct access to such keys constantly.

A major part of the slowdown with the protyping was that it was being done on a machine that was never designed for what I was trying to do with it, namely dual extrusion. After cutting open my hands more than once trying to remove support material (and in one case needing stitches), and still having to fight to get decent prints we ended up investing in another printer. This new machine, unlike the previous was purpose built for dual extrusion and has made prototyping an absolute dream compared to the previous unit. No more cleaning up parts, they just go into the tank for an hour or two and are ready to go from there.

When I was experimenting in the different ways to produce manufacturable designs for the adjustable mount, I found that they were just getting more complicated. I took a step back, took a breather and readjusted my thinking (thankfully the 40min drive to and from work gives me a lot of time to think). I hit upon a design that would make the casings much cheaper to mold, would allow you to replace a joint if it were broken, makes the electrical connection automatically (instead of having to open the device to make the cable connections) and of course opens up the door for future designs/ideas.

So the first thing to note is a change in thickness:

1. First 3d printed design, probably the closest in terms of height
2. Midway through the design cycle, this case was taller to accommodate more jack sizes
3. The tallest design by far, this design allowed for ethernet cable sized jacks and 12mm thumbscrews to make it reasonable to tighten down. It also intergrated the folding stand and the 1/4"-20 threading

The flat design in the picture above is done using what I've been calling the travel bridge:




(the white stuff you see in some of the holes is support material that hasn't been removed yet)

When flat, from the bottom of the case (including feet) to the top of the new keycaps (more on that in a minute) it measures in at 32mm. By comparison, the last version of the case was about 24mm for just the base. Once I can get them ordered, the bars will house PCBs that make the electrical connection.

This same design can be swapped out for the adjustable arms:



You'll also notice what I lovingly call the cheese grater at the top of the case. This is the mounting point for stands/external mounts/etc. and is still a bit of a work in progress.

This also being more travel friendly, I also revisited some earlier designs:





I've been extremely happy with this setup, and barring major issues I'm done doing any major tinkering with it or the layout.

The last thing worth mentioning that I've been working on is a new keycap style. I've used it with both DCS and DSA and there were things I liked and didn't about both styles, so I've been working with a new cap style that combines what I like about both.

DSA, DCS, new style (unnamed)
This new style was the last thing I printed on the old machine and even with it's less than stellar tolerances the caps fit nicely on the Cherry & Matias stems. I haven't printed a full set yet for complete testing but that's underway, even on the new machine it'll take about 24 hrs to print them all. So far though I've been very happy with how comfortable they seem to be, I'll update more when I've had a few more days of testing.

The last few notes worth mentioning:
1) I've decided to hold off on the RGB backlighting for now. It complicates the setup and while I would love to include it, it isn't as vital to getting Axios out. I will however be leaving connection points in place so that it can be added in down the road to the existing design.
2) Dropping the RGB backlighting frees up a fair bit of power consumption, which lifts the barrier to what I think is a more important feature: Bluetooth. I'm currently working with someone local to get Bluetooth integrated into the design both for regular usage and configuration of the device.
3) Yes, those cutouts at the top are for screens. OLED screens to be more exact.

EDIT: Big shoutout to Kurplop for reminding me that while I had my head down at the grind stone I was being terribly negligent here

[kurplop]

I'm glad my threats were taken seriously.

Actually, I'm quite impressed with what you've got here and glad to see an update.

[njbair]

This is some amazing progress. So glad I passed on the Infinity Ergodox. And the OLED screens sound like a neat idea as well.

[jamadagni]

Very nice to hear an update from AcidFire.

So the top keys are now gone? Oh-kay, and while having the OLED seems cool for layer display etc, I do now have to rethink my proposed key layout...:


Hm OK so I'll push Caps and possibly something else to a higher layer to make space for the <tlde> and <lsgt> keys (which are used for lots of characters in my Indic scripts), and think about what to do about Undo...

But you don't mention anything about the central hotkey clusters pictured here:

... which I have relied on in my layout above.

That's a big important plus point for me with the Axios vs other options available right now like the ErgoDox EZ, since I really would much prefer to have the 12 F keys physically (even if not the multimedia keys which are less used and I can map to a higher layer). So I hope you're not proposing to cut that out?

[jamadagni]

Re RGB backlighting, I just read over at KeyboardIO's site that they use Neopixels, and while they use an Arduino, apparently this adapter can be used to have a Teensy drive them.

BTW the Axios is using a Teensy, isn't it? Or have I become totally confused as to the current status?

At least I remember that AcidFire was promising his own take on the RGB thingy where he mentions more than 16 million colours. Any idea what that could be useful for? IIUC the human eye is considered to not be able to differentiate more than that much (or even that much)!

And does the promise for it being able to get "added in down the road to the existing design" mean modularity advantage in that I can just later plug-in a set of LEDs or something without having to solder anything?

[hoggy]

Acidfire, amazing progress!

[Paul]

Nice to hear that everything is alright and project is moving closer to production!

I like this keyboard a lot and I wish for this project so succeed. New designs look great and possible wireless option makes it even better.
But removing row of Function keys and instead adding a oled screen looks like a 2 steps back.
Why the change?

There is no practical use for the screen. On any keyboard, and especially on the keyboard targeted for comfortable touch-typing.

Maybe it could be used to show the kb layout layer or show battery life, if wireless will be supported.
But for both of these, 3 leds will do the job. They can show 8 layers, plus blink when battery is low or for other diagnostic uses.

Screen adds to keyboard cost, complicates pcb layout, and more importantly uses space at the top, that instead should be used for a extremely useful row of F-keys.
I mean regular flat row of F-keys, although the tilted F-key module looked very nice and comfortable and fit very well with the keyboard.

I suspect that a row of switches + keycaps will probably cost more than a screen , but that adds a very useful feature.
A separate F key cluster like numpad is a good option if it is used rarely, but a row included in the main keyboard is better for frequently used actions.

Again, I like this project. There are other areas that can help with adoption of the end product. Different thumb clusters, sculpted keycaps, usb hub, audio connectors, even integrated scrollwheel or a trackpoint would have some practical usefulness, screen - has none, and takes invaluable time to integrate into the design.

[davkol]

A screen *might* be very helpful, if on-the-fly macro recording is supported.

[jamadagni]

+1 for a screen but do we need two even for macro recording? And how does it figure vs LEDs in terms of power consumption? Maybe left side screen and right side LEDs?

Also, I now re-read this part:

2) The oft neglected external number pad will be available in two layouts, one for a standard number pad and the other for F keys/hot keys if you need direct access to such keys constantly.

But it is still not clear to me whether you mean the same centrally placeable and attachable one as in prototype photo 96 ehich I lonked above, or something else?

BTW that triangular attaching modifier cluster for travel -- very insightful design. It's clear you're taking time only to make ot more and more useful but in one way I'm glad I came to this thread late else i might not have lasted this long in anticipation!

[davkol]

Because someone might want to use only one half at a time? For example, when gaming or doing some graphic work.

[jamadagni]

@davkol: Excellent answer! I didn't think of that. But really one would like to know about the relative power consumption. Of course, the OLED is much more flexible!

... but yikes! Was this list of disadvantages of OLEDs taken into consideration?

[jamadagni]

Further on the OLED topic, IIANM it is accepted procedure to give alcohol baths to keyboards in case of spilt liquids etc, and if even water can damage OLEDs, I'd assume alcohol certainly can, since it's also organic. (Correct me if I'm wrong – I'm certainly not an expert on this.)

Now in such case, if an OLED were attached to the board, then one would to be extremely careful to just submerge the board part and not the OLED part in alcohol, but given that a careless mistake would be the cause of the problem in the first place, making the solution also prone to such a mistake (I mean, if you prop it up against something holding the OLED out of the alcohol and it slips or such) doesn't seem to be good design...

Or the OLED would have to be made yet another detachable module which should be detached prior to such a bath, which is, well, at least cause for more design costs...

Better look at other options, though? How about LED-based displays? Don't they come in such small sizes? And do they also get affected likewise by alcohol/other liquids?

[Oobly]

Further on the OLED topic, IIANM it is accepted procedure to give alcohol baths to keyboards in case of spilt liquids etc, and if even water can damage OLEDs, I'd assume alcohol certainly can, since it's also organic. (Correct me if I'm wrong – I'm certainly not an expert on this.)

Now in such case, if an OLED were attached to the board, then one would to be extremely careful to just submerge the board part and not the OLED part in alcohol, but given that a careless mistake would be the cause of the problem in the first place, making the solution also prone to such a mistake (I mean, if you prop it up against something holding the OLED out of the alcohol and it slips or such) doesn't seem to be good design...

Or the OLED would have to be made yet another detachable module which should be detached prior to such a bath, which is, well, at least cause for more design costs...

Better look at other options, though? How about LED-based displays? Don't they come in such small sizes? And do they also get affected likewise by alcohol/other liquids?

TBH, I wouldn't be concerned about any of these issues. Colour balance is likely to be the only noticed issue and then only after a number of YEARS of on-time on the display. An easy solution to this is to only enable the display when it's needed. Certainly doesn't seem to be an issue with any phone of mine and the benefits over LCD far outweigh anything on that list in my opinion.

I am not aware of alcohol baths being an "accepted procedure" at all, since it will dissolve all lubricants in the switches and can affect most case materials negatively, too. I certainly would not do this to any of my own boards.

Still not sure there's any really useful reason to have a display on a keyboard, but if AcidFire thinks there's a good case for having it in there, that's okay. I worry about the increases in cost, complexity and decrease in durability / toughness / reliability (more to go wrong and more easily). Especially for a first product release.

[AcidFire]

While it's true that the underlying goal of this board is comfortable, healthy typing over all else keep in mind that there are a number of functions that the board will support that the screen(s) are ideal for:

- Layer Indication -
While many of us are very capable of memorizing LED combos for what layer we're using, I've had many others express concern over not being able (or really, willing) to. The screen(s) address this issue for them at what is actually a minimal cost increase over LEDs.

- Bluetooth/Battery -
One of the biggest reasons for the screen(s) they cover a myriad of functions:
 - Battery level + charge indicator
 - Device currently connected to. The plan right now is to implement the bluetooth with a setup that allows it to keep 3-8 pairings that you can hot swap between with a simple keypress, as well as allow one device to slave to the the other wirelessly (potentially, still requires R&D)
 - Signal Strength
 - Pairing instructions/Security code
 
- Macro Recording -
Pretty self explanatory, as davkol already pointed out would make on the fly recording of macros simple and easy to visualize.

- Options/Status -
Another major aim with this board was for it to be system-agnostic as possible, which is why it's designed to keep all the profiles & settings on the board. This should help to keep the board friendly for environments like schools where you have no ability to install any supporting software. Or if you don't have the bluetooth modules to give you access to configuration tool, the screen(s) make it easier to change settings without going into the config files, especially for those who don't quite know what they're doing or feel comfortable editing a core file.

Addressing the concerns towards the screen(s) and the choice to use OLED displays:
- Power Consumption -
The datasheet for the display says that at 100% of the screen being on it should draw about 30ma, which is about 10-15ma higher than what you would drive an average LED at. By comparison, a typical RGB LED at full brightness white will draw about 60ma, or with say 5 LEDs you're looking at a 300ma draw. The numbers provided by datasheets are almost always under the most ideal situations and thus I'll be doing extensive consumption testing when the daughterboards come in, but even at 2-3 times what the datasheet expects it still clocks in much lower than even the LEDs. Typical LCDs in this size range with an LED backlight draw about 120-200ma on a single color backlight. I'm also looking at a couple of different power profiles just like a laptop, plugged in versus battery powered where the display will only power on under certain conditions.

- Viewing Angle -
With a concern towards tenting angles, the OLED display made a much better choice over an LCD with an (ideal) viewing angle of up to about 180°. In reality, I'm sure it will be a bit lower, however by comparison the typical LCD is usually 120° or less, and even towards the end of that range the polarization in the panel tends to make it look wonky anyways.

- Size -
The OLED display I've selected is 1.5mm. By comparison, I'd be looking at about 6-7mm for an LCD + LED backlight before we even talk about the board they'd be mounted to. When space is at a premium, this is a massive difference. It's also difficult & relatively expensive to get a graphic LCD in the same size as to what I've selected for Axios.

However, just like the modular nature of everything else with Axios the screens are not mounted directly to the same board as the key switches, allowing for removal, upgrade, replacement, etc etc. I also have a simple blank plate that can be used in it's place if you don't want either the LEDs or screens.

Now, as for the extra switches/hotkeys... I have to start by saying that while it can be admittedly frustrating at times sharing everything as it's being developed, you fine folks help to keep me on track with what I'm working on. I'll freely admit that I had omitted the mounts for the extra hot keys primarily because I wasn't a fan of the asthetics of it, but also because they add instability to the tented design, particularly at the higher angles. If I become a slave to aesthetics first and let functionality suffer, then I become a hypocrite in regards to my opinion on things like Apple hardware which can end up functionally limited for the sake of pretty. So when you questioned as to whether or not they were still available, and made it known that it could be a deal breaker for a number of you it was frustrating. Thankfully my patient wife listened and provided a sounding wall that helped me get past my frustration and into a revision of the design that not only works with the existing mounts, it reduces costs and extraneous parts + molds.




While the design of the stands needs some tweaking (there are currently revised parts printing), deployed it sits at a 15° angle and folded up a 5° angle. It's also stronger and more supportive at the point where it connects to the body in comparison to previous designs. More to come when the new parts finish printing (really need to invest in more printers!).

[jamadagni]

While it's true that the underlying goal of this board is comfortable, healthy typing over all else keep in mind that there are a number of functions that the board will support that the screen(s) are ideal for:

Wow – and I didn't even imagine half of them! Cool. And as davkol said, I also agree that the full OLED isn't going to be running all the time, so it wouldn't wear down so quickly. If the OLED would also have a sleep mode or low brightness mode which it automatically goes to after a given period of time, I guess it would further lengthen the life.

Now, as for the extra switches/hotkeys... I have to start by saying that while it can be admittedly frustrating at times sharing everything as it's being developed, you fine folks help to keep me on track with what I'm working on. I'll freely admit that I had omitted the mounts for the extra hot keys primarily because I wasn't a fan of the asthetics of it, but also because they add instability to the tented design, particularly at the higher angles. If I become a slave to aesthetics first and let functionality suffer, then I become a hypocrite in regards to my opinion on things like Apple hardware which can end up functionally limited for the sake of pretty. So when you questioned as to whether or not they were still available, and made it known that it could be a deal breaker for a number of you it was frustrating. Thankfully my patient wife listened and provided a sounding wall that helped me get past my frustration and into a revision of the design that not only works with the existing mounts, it reduces costs and extraneous parts + molds.

I'm sorry if I've inadvertently given you any trouble by repeatedly asking for the F keys. You are already putting in a huge amount of work on this, and I really have no right to ask you to further complicate things for yourself. But it's only because you did say you intend for it to be modular and extensible, and are so nice about taking feedback positively [and have your wife to calm you down even if you get bothered by it – yay for the fortune of having a wonderful wife ] ... that I asked about it yet again.

As I have said in an earlier post, I already put my alpha/numeric/symbol keys to maximum use on four levels due to the complexity of the multiple (orthographic) scripts I use regularly, which is why I am loth to remap numeric keys to F keys, which also I use often as a power user. So having the F keys separately does help a lot! Others like tups and zr0h have kindly shared their ideas of how F keys can be avoided, but they don't fit my requirements of four real levels of distinct characters belonging to the same script (not just convenience levels for navigation/other script as in Neo levels 4 to 6).

But there are a couple more aspects to this. If the F-key cluster were of necessity to be a bridge between the two halves like in:

... then the possibility of orienting the two halves as per one's natural shoulder/hand orientation would be lost.

But you say in your earlier post:

2) The oft neglected external number pad will be available in two layouts, one for a standard number pad and the other for F keys/hot keys if you need direct access to such keys constantly.

If that then means that it's a separate detachable module, then that's great and fine, which gives the best of both worlds! Do you have a tentative layout for such a number/F pad you can share?

Now can you answer the question about the RGB backlighting I posed earlier:

And does the promise for it being able to get "added in down the road to the existing design" mean modularity advantage in that I can just later plug-in a set of LEDs or something without having to solder anything?

Thanks a lot, and best wishes for your every success!

[njbair]

All this talk about OLED screens has got me curious, what kind of chip are you going to use to drive this board? I'm thinking an AVR won't cut it, so probably an ARM chip of some kind?

I'm also curious about the firmware. You've mentioned the idea of an easy-to-use configurator but I kind of like getting under the hood a little bit, like with TMK. Will this be an option?

[Koren]

Hey, I check the thread four times a day without success, and as soon as I leave the internet, news arrive! Good news, too. Since I have the chance, congratulations, AcidFire!

The new prototypes are really nice. I personally prefer keys to screens (I even choosed Ergodox EZ over Infinity), but that's not a big issue at all. Is there still LEDS on the thumb clusters, or do the screen replaced them completely?

Curious about the keycaps, too...

I'm also curious about the firmware. You've mentioned the idea of an easy-to-use configurator but I kind of like getting under the hood a little bit, like with TMK. Will this be an option?

I remember AcidFire saying that the project would be opensourced once released. If that's still the objective, you can expect a lot of tweaking... I still want to customize the firmware myself, or write a complete new one.

[JackMills]

I haven't been on GH recently, but wow, these "new" posts by AcidFire made my day. I am a fan of the screens, even if I am not sure what I would do with them. Oh, but it would be cool if you could have like CPU/RAM-usage or we could have the date/clock/network/volume/battery icons on it. Ok screens will be fun...

Next, you have really improved the design, it looks sleek. Looks aren't of importance to me, but if it looks better I won't be complaining. The new printer seems to be a solid investment.

The revision of that early design, the only thing I was thinking about when I saw that...give that connecting center piece a trackball!

[Dynamo]

I am glad to see that Acidfire is ok. I have checked this thread nearly every day for updates, but have been away for a few weeks, so I was suprised and happy when I checked it today.

Regarding the keyboard. I am still a bit anxious about the number of keys. On a Swedish keyboard we use the åäö-characters in addition to A-Z. Unfortunately, many keyboard designs are developed for the English layout and then it is difficult to asign keys to åäö without using key combinations. I want keys dedicated for åäö, that are easy to reach since they are quite common in the Swedish language. I asume there are even more characters in other languages. So, in my view, it is better to have too many keys than too few...

[torwag]

Why not keeping the openings for the screens as flexible module insert. 2 module slots which can be used to clip in modules from a wide variety of choices. Design a socket,  which holds power pins,  i2c pins or uart and some GPIOs.  A OLED screen module would be one possibility which might be even the official module, others might createn a more simple LED module,  there could be sound or vibration modules,  one could think of input modules like capacity touch,  pressure sensitive buttons,  dials,  knobs, wheels whatever someone need for his very particular workflow. And if you want to keep it simple,  just create a blank cover (or one with a penholder).
That would make the keyboard the first one with a module / shield / cape / extension board -  design and brings customizable keyboards to a complete new level.

[jeep]

super exciting... love to see that there are updates happening.

[Koren]

super exciting... love to see that there are updates happening.

Yes, and I hope the campaign will be launched soon, because I'm coding more and more strange things as possible firmware parts.

The last being an Enigma mode ^_^


Not totally "for the fun and nothing more", though... I'm still looking for a system where I can type weak passwords on the keyboard and have strong passwords sent to the computer. Seems a really promising solution.

[clickclack123]

The last being an Enigma mode ^_^

Not totally "for the fun and nothing more", though... I'm still looking for a system where I can type weak passwords on the keyboard and have strong passwords sent to the computer. Seems a really promising solution.

Cool sounding idea, but wouldn't the Enigma "Wheels" or encoders or whatever they're called need to be in the correct starting point?

Wouldn't this open the possibility of getting locked out of everything if the keyboard ever failed?

[Koren]

Cool sounding idea, but wouldn't the Enigma "Wheels" or encoders or whatever they're called need to be in the correct starting point?

Wouldn't this open the possibility of getting locked out of everything if the keyboard ever failed?

Indeed... I'll try to discuss this further when everything is ready, but my idea is the following : a master (rather strong) password for the keyboard that set the wheels shift/wheels initial position/wires and everything, so that if someone take your keyboard and don't know the master password, knowing the weak passwords won't allow him to access your data.

After that, a button put the wheels back in the initial position (to enter a new password), and a button "clean" the master password after you're done. I've posted the general ideas last summer in this thread I think. It's just a new way to implement it I try.

I'm looking into the amount of data (mostly couples of weak passwords/strong password) you would need to be able to convert a weak password into a strong one. I doubt it's an issue, but that's still an interesting point from a cryptanalysis point of view.


At the end, nothing is stored in the keyboard... and I think that could be a better solution than the hashs / md5 / other kind of cryptography tricks I tried last year to do the same thing. Using a last stage can insure you get lowercase, uppercase, numbers and symbols.

[Faokryn]

What the...?  It seems GeekHack stopped emailing me when this thread updates! ]:

Very exciting news! Glad to see things rolling again!

[Morty]

hi everybody   I joined this forum so I could post on this thread, because I want this kb

If everyone is still allowed to give suggestions, I would like if there was a usb port built into the keyboard so I could connect a mouse directly to the keyboard. Or maybe a usb port on each keyboard section in case someone uses the mouse with their left hand.

Thanks to everyone who read my post

[Jette]

Interesting.

Will there be an option for the original layout, as featured here? The original looked fantastic, but the current designs look like a stripped-down copy of the Ergodox, which I already have.

Specifically, the loss of the rearranged arrow-key cluster toward the bottom is a significant reduction in design; one of the major frustrations of using the Ergodox is the absence of a nice, clean, easy-to-use cluster of arrow keys in a sensible arrangement for those archaic and poorly thought-out programs that demand the use of the arrow keys and don’t let you change them. Having them in a straight, horizontal arrangement is counterintuitive—this was one of the major things that the Truly Ergonomic Keyboard got right.¹

The reduction of the thumb key clusters could be good or bad, depending on the exact dimensions of the keyboard and the size of the given user’s thumbs. Personally, I would rather have more thumb keys than less—the current design offers fewer than the Ergodox.

In spite of the changes, this remains an excellent design, and I’ll still likely end up buying the keyboard when it comes out, if the price is reasonable and the assembly doesn’t involve another twelve hours soldering, since I can (hopefully) figure out a way to use Bépo with the extra letter keys.² All the same, I think—from an aesthetic and functional standpoint—the design on the page I linked is still the best by far, and I hope it will remain available for those interested in it.

<sub>1. I’m also aware they’re a decidedly more corporate entity than the Ergodox people, so their attorneys may have bludgeoned you into scrapping the design, for whatever outrageous reason. I haven’t read through every single post.
2. Bépo is a French layout, with extra keys for é, è, ç, à, etc. I could never get it to work with Ergodox because a) Massdrop’s so-called configurator is terrible and b) it’s an international keyboard layout, and I have no idea which keys go where, c) even if I did, I’d have to do it all in C, and programming requires way, way too much executive function for me to handle in greater than minute doses, and d) there aren’t enough keys on the Ergodox—you need eleven or twelve per row, whereas the Ergodox only has ten.</sub>

[Morty]

I didn't realize about the arrow keys until Jette's post.

I think arrow keys like these are best:
http://digitalunite.com/sites/default/files/images/LZ0023-4-arrowkeys.jpg

But I don't have any ergonomic studies or anything to back it up.

[vvp]

My guess would be that (from the ergonomic point of view) the best arrow cluster would be just 4 keys in a row possibly somewhat column staggered. Definitely not inverted T where you need to move one finger around between keys.

[Yuri Khan]

Not necessarily. On an inverted-T or a diamond cluster, you have a strong finger moving around. On a 4-in-a-row cluster, one of the two most(?) frequent movement keys falls on the weakest finger.

[Koren]

Will there be an option for the original layout, as featured here?

I can't speak for AcidFire, but he said in the past months that he wanted first to produce the current design, but variations may be available after. Besides, the project should be open-source, it's not a huge change (although maybe a costly one, because of the custom PCB order) to add a key to redo the cluster.

Maybe it's possible for AcidFire to create a PCB that allow both versions, so that getting the other layout is just a matter of redoing just a little bit of soldering (and cutting of the enclosure)? A bit like the Ergodox PCB that allow slightly different layouts in theory (but if it's working, unlike the Ergodox PCB, it's even better ^_^ ) I guess it may be tricky, though, depending on the complexity of the current PCB.


The question of the arrows cluster has been a hot debate here ^_^ I don't mind either myself, although I think the dedicated arrow clusters (like on truly ergonomic) are too far from home position to be really usable (thus the arrow cluster would either be a duplicate, or an unusual cluster of F-keys...)

Besides, I don't like having home/end/pgup/pgdown on the other hand. You'll probably never find a one-fits-everyone solution, but I understand how you feel.

I may miss a dedicated cluster when I'm not typing, but I'm starting to think I'd rather have an extended numpad on the side of the keyboard, with numbers, operators, a couple of functions, navigation keys, etc. A kind of mechanical version of this : http://www.selling.loganempire.com/var/albums/Hotlinks/Pict0002.jpg

The reduction of the thumb key clusters could be good or bad, depending on the exact dimensions of the keyboard and the size of the given user’s thumbs. Personally, I would rather have more thumb keys than less—the current design offers fewer than the Ergodox.

Isn't it also 6 keys on Ergodox? (at least, it's 6 on the Ergodox I used and on Ergo EZ I'm currently waiting for) As far as I can tell, the only difference in keys between the two are the additionnal 6 keys on top of Acidfire's keyboard (plus the possible two 9-keys additional clusters).

I’m also aware they’re a decidedly more corporate entity than the Ergodox people, so their attorneys may have bludgeoned you into scrapping the design, for whatever outrageous reason.

Nothing has been said about this, and I'm pretty sure you can't protect such a detail of a design. It has been seen elsewhere, too (like on TRON keyboards, which are for the oldest ones, 30 years old, so older than anything Truly Ergonomic produced).

Bépo is a French layout, with extra keys for é, è, ç, à, etc. I could never get it to work with Ergodox because a) Massdrop’s so-called configurator is terrible and b) it’s an international keyboard layout, and I have no idea which keys go where, c) even if I did, I’d have to do it all in C, and programming requires way, way too much executive function for me to handle in greater than minute doses, and d) there aren’t enough keys on the Ergodox—you need eleven or twelve per row, whereas the Ergodox only has ten.

This is at least something I can promise: you'll be able to get the Bépo you want without having to spend nights in firmware configuration. AcidFire should provide a configuration tool, but if it doesn"t allow you to create the keyboard you want, I'll provide one (or an alternative firmware). I want something far more exotic than Bépo (I'm french, but I don't share all the choices behind the Bépo, even its variations), so I'm more than eager to invest a lot of time in this.

(when I say more exotic, it's not just a matter of being able to put any letter on any key, but having the functionalities of a kind of cellular automata in the keyboard, there's plently of tricks that can be done in such a programmable keyboard that you simply can't do on a normal keyboard I'd like to use)

I fact, if you still need a Bépo layout for your Ergodox in a couple months (when EZ ships), I may be able to help you, although it may takes some time. Unfortunately, I can't right now because I don't have an Ergodox to do tests.

Not necessarily. On an inverted-T or a diamond cluster, you have a strong finger moving around. On a 4-in-a-row cluster, one of the two most(?) frequent movement keys falls on the weakest finger.

That's only if you use the (common, VI-style) left-up-down-right order and on the right hand. There's some people that suggest putting the keys in a different order, or better, on the left hand since if makes left, arguably the less used key the one that fall on the weakest finger.

I think arrow keys like these are best:

Probably mostly a question of preferences and habits. It's also the shape I prefer, probably because I used them A LOT. But I'll put them in the middle of the keyboard for easier access, on a layer. I already use this on linux and enjoy it, I just hope the staggered columns won't make thinks harder (inverted T may be better).

[Jette]

I appreciate the offer, Koren.

I don’t like everything about Bépo, either, especially the placement of the W key (makes sense for French, where it rarely shows up, but terrible for English, where it shows up a lot); I was using it as example to illustrate the benefit of having separate keys for accented letters. Customizing it would definitely be a plus. I’d definitely be interested in whatever software you come up with for customizing it; I went thought a huge headache getting my Ergodox just right (I made a press-and-release layer for all the <{(-type characters because I’m too lazy to reach all the way up to the number keys).

I used the TECK as an example of the placement of the keys, not necessarily the arrangement. I prefer the classic inverted-T cluster, too, but anything is better than four keys arranged horizontally with totally arbitrary movement positions. Even with Vim, I never really got the hang of it, mostly because using hjkl is slow and largely pointless.

It is six keys per side on the Ergodox; I was looking at this picture, where there are only eight, and they’re all connected.

[Koren]

I was using it as example to illustrate the benefit of having separate keys for accented letters.

Indeed (although I've à, ç and ù on an alt-gr layer myself because I use far more often brackets, parenthesis and other common programming characters). Fully agree on the W, too.

About the layout, I'd still prefer a double regular-sized column on the size instead of a single larger one. I'm used to two additional columns for the right pinkie. But designing and producing a custom keyboard is such a long (and expensive) task that I'll gladly take this as a huge upgrade to commonly available keyboards (including Ergodox, if only for the tenting... I've an EZ in order, but the non-bendable thumb cluster is a big limitation for me, and the thumb cluster on Ergodox is, for no real reason, too far from the rest of the keyboard anyway).

It is six keys per side on the Ergodox; I was looking at this picture, where there are only eight, and they’re all connected.

I think you should see this one as an alternate layout for those who want a keyboard with connected halves, since there was some demand for an older prototype (flat and in a single piece).

The main layout is still the one with two separate half-keyboards, with 6 on each thumb clusters (although 2 raws of 3 x 1.5u keys, not the Ergodox thumb cluster layout)

I'm pretty sure that AcidFire showed this solution mostly to show that you can have a "joined" keyboard if you prefer with the new system he designed to attach parts...

[Jette]

Yeah, I figured that out after I posted (thirty-five page thread, attention span, etc.). That might be interesting as a portable version; I can’t take my Ergodox anywhere. That’d still leave the obvious issue of where to put it (you can’t put it on top of the laptop’s keyboard, because it’ll press keys and cover the mouse), but at least it’d be in one piece.

The biggest thing I see right here is the absence of a sixth key in the row just below the home row. The physical dimensions of the keyboard might make it impossible, but that’d be a good place for two extra keys. That, again, is another reason I’m enamored with the original design, which has six keys for the home row and the rows above and below. It could be an illusion of the photographs, but the current design looks, at once, smaller (fewer keys) and yet somehow larger, taking up more space.

As I’ve said, though, the current design is miles better than anything else I’ve seen, ergonomically speaking (except maybe the Maltron keyboards, but those are like $600 and bigger than a typewriter). And it’s still got more accessible keys than either the Maltron or the Ergodox (I’m not counting the keys in the middle of the Maltron, since I suppose they want me to tap them with my nose, which is harder than it sounds). The bendable thumb cluster is a major improvement; I can only reach two of each of the thumb cluster keys at a time.

[AcidFire]

Greetings from Hawaii! We're curently having a bit of an overcast/overly windy day on Maui, so I was given special permission from the wife to post while we're on our honeymoon

I should probably get the first major announcement out of the way... I quit my job! With a tremendous amount of support from my wife and some careful financial planning, I will officially be working on Axios full time as of November 1st! My last day would have been sooner but unfortunately I do a fair amount at my job and it takes time to get someone new up to speed (we're also on a three week tradeshow/honeymoon). This also means I don't burn bridges and we can work on agreements for ongoing access of the equipment at work until I have the funds for my own.

Since my last post I'm happy to say that very little has changed with the latest revision, with the only notable changes being made to widen the arms to pass more through electrically and to strengthen them at the same time. I've also integrated a better mount for the wrist rest which I am currently working on, or rather will be when we get back. This new arm/mating design has also enabled me to go to what I had originally envisioned for the adjustable arms and the result is a substantially stronger mount, far less prone to slippage than the previous designs suffered from. As a side benefit from playing around with these new arms I've discovered they work exceptionally well as a stand, and I think with some type of shoe design for them will work far better than previous iterations. It's also worth mentioning that I now have modular mounts for 1/4"-20 hard points, which should give those of you looking to mount it somewhere an easier time doing so without driving up the cost of the core unit.

Unfortunately due to a design oversight on my part the new PCB files I sent off were delayed when two of the designs were unproducible, holding up the whole order and preventing me from taking a working set up to Mini Maker Faire Seattle (grumble grumble). Thankfully just about everyone was happy to just put their hands on it and I ended up having a good chat with a few GHers as well and just like last year was a very encouraging push to keep going. More importantly I spoke with a hardware vendor there, and I think we've finally got a solid solution for bluetooth and... a trackpad.

That's right, I've got a preliminary design done for a trackpad module that fits in the same space as the thumb clusters, meaning you'll be able to either mount it up between the halves, or even as one of the clusters under your thumbs. More specifically, I've done two designs; one as a straight trackpad only and the other with the inclusion of buttons under each of the four corners. I'll be ordering PCBs for testing fairly quickly while we're still away so I should have them before the end of October. The matching mechanical designs have also been done so I should be able to post some pics of the mockups when I get back. I promise when I'm more technically skilled or have the money to pay someone more technically skilled I'll get a design done for a trackball, but for now this should help solve many of your mousing needs.

As for the previously mentioned bluetooth, after a long discussion with said vendor (gotta keep it under my hat for now) I'm designing a bluetooth module with a secondary radio, which will be used as the wireless bridge. This keeps costs down (new radio is cheaper and supposedly better than the bluetooth speedwise) as well as giving the option for more wirelessly connected devices as the radio can act as a hub, much like the Logitech unifying receiver set up. Yes, this includes the oft requested numpad/hotkey external module.

We've also settled on a cable standard for the wired bridge between the split halves, which sadly I will keep to myself for now because 1) I've been advised not to as it's a solid marketing point for the campaign and 2) it does still bear testing (I have PCBs waiting for me at home). Why am I telling you guys now? Because I'm excited at how solid and open ended this new connection and the awesomeness it brings to the project. The new cables will be far easier to get a hold of than either 3.5mm TRRS or even the right RJ series cables (phone/ethernet for you non techs). It also enabled me to finally add something else....

The usb hub I've been asked about again and again is now officially part of the design. While not a core component, it is designed to be a 2 minute drop in feature that anyone can add to their boards at any time. Right now, the design adds two external usb ports as well as one internal, with the final being occupied by the keyboard itself. The first version is a usb 2.0 hub with plans to upgrade that to a usb 3.1 hub down the road. Depending on how numbers look, we'll most likely end up offering both side by side until the price of hub controller chips for the 3.1 setup come down substantially (anything quality is just a bit over twice the price of the 2.0). The 3.1 setup is also a bit more complicated since there are far more datalines to pass to the hub and I only have so much room on the PCB but I have a solution in mind. Currently because of design constraints (read: no space left on the PCB) the hubs in the two halves are independent of each other, but I'll see what I can do about that.

That's all the time I can spare for now, I'll be posting up in far more detail with a huge picture dump after I've recovered from jet lag next Monday.

[njbair]

Wow, has it been two months since the last update?

Anyway, congratulations to you on your marriage and career change. Sounds like it's going to be a really exciting time for you. I know I probably speak for many Geekhackers when I say I'll be re-reading your post and taking it all in for a few days to come, but initially it looks like lots of exciting stuff in the works! Looking forward to it.

[hoggy]

Congratulations!  Looking forward to the the pictures.  Enjoy your honeymoon!

[jamadagni]

Nice to hear of your Hawaii Honeymoon (oops, capitalization "accidental")...

On the keyboard side though, looks like you are going to make this much more important a part of life, which I guess is quite good for the project, but: again is there any tentative date in sight, or have you decided to avoid promising any dates because already you have had to skip a couple?

I'm writing this using a 10-year old TVSE mechanical keyboard, which is far better than any membrane keyboard, but my fingers/arms and new computer is asking me when I will be bringing in the split ergonomic thingy...

As for trackball, I already bought a Kensington Orbit so for now I'll just put it between the two halves, but it's the "when" question that keeps putting me off the Axios and towards the ErgoDox EZ, and the fact that the ErgoDox has proven software for it.

Which causes me to ask: what about the software side of things? Are you going to be able to use any existing firmware? Looks like TMK and chrisandreae are valid alternates for ErgoDox with each its own set of special features... Rather than writing new software right from scratch (and go through a long debug/maturation cycle) would it be better/possible to use one of these?

[wasabah]

Holy ****! Congratulations!
Can't wait to see the outcome of this..

[harlw]

wow! subd

[JackMills]

Enjoy the honeymoon. And congrats on that big step of quitting your job. And even more so for committing full-time to this project.
Enjoy Hawai!

[Niomosy]

Congrats on the wedding, AcidFire, and best of luck.  I've been checking in on this one quite regularly.

[AcidFire]

Nice to hear of your Hawaii Honeymoon (oops, capitalization "accidental")...

On the keyboard side though, looks like you are going to make this much more important a part of life, which I guess is quite good for the project, but: again is there any tentative date in sight, or have you decided to avoid promising any dates because already you have had to skip a couple?

I'm writing this using a 10-year old TVSE mechanical keyboard, which is far better than any membrane keyboard, but my fingers/arms and new computer is asking me when I will be bringing in the split ergonomic thingy...

As for trackball, I already bought a Kensington Orbit so for now I'll just put it between the two halves, but it's the "when" question that keeps putting me off the Axios and towards the ErgoDox EZ, and the fact that the ErgoDox has proven software for it.

Which causes me to ask: what about the software side of things? Are you going to be able to use any existing firmware? Looks like TMK and chrisandreae are valid alternates for ErgoDox with each its own set of special features... Rather than writing new software right from scratch (and go through a long debug/maturation cycle) would it be better/possible to use one of these?

Thanks all for the congrats

I've been avoiding giving a timeline because with my work schedule, I honestly wasn't sure what was manageable. Given where I'm now at with development and the fact that I'm now able to move to a full time schedule (without coming home burned out from work), we're tentatively aiming to get the campaign ready to go by the end of November/first week of December and are pulling assets together to make that happen.

Firmware wise the first version will be what I've been working with which is based on the mbed platform, however I've already talked with Koren about getting one of the beta units in his hands since he's been chomping at the bit to get up and running with it. With a full time schedule I do want to take a look at what it'll take to get some of the extended functionality running with TMK. It's entirely possible the final firmware will either be something from Koren or a fork of TMK. This is one of the many reasons we're sticking with open source.

[jamadagni]

Hi AcidFire and nice to hear back from you.

we're tentatively aiming to get the campaign ready to go by the end of November/first week of December and are pulling assets together to make that happen.

"Campaign" in Nov-Dec would mean product shipping possibly when?

[Niomosy]

Congrats on the good, if wallet-breaking, news!

[Steezus]

Hi AcidFire and nice to hear back from you.

we're tentatively aiming to get the campaign ready to go by the end of November/first week of December and are pulling assets together to make that happen.

"Campaign" in Nov-Dec would mean product shipping possibly when?

I think it's a little too early to guess shipping dates. I don't think AcidFire has even contacted any shops at this point to see prices and shipping. I'm pretty sure this is still in the design and testing stage.

[njbair]

Nice to hear of your Hawaii Honeymoon (oops, capitalization "accidental")...

On the keyboard side though, looks like you are going to make this much more important a part of life, which I guess is quite good for the project, but: again is there any tentative date in sight, or have you decided to avoid promising any dates because already you have had to skip a couple?

I'm writing this using a 10-year old TVSE mechanical keyboard, which is far better than any membrane keyboard, but my fingers/arms and new computer is asking me when I will be bringing in the split ergonomic thingy...

As for trackball, I already bought a Kensington Orbit so for now I'll just put it between the two halves, but it's the "when" question that keeps putting me off the Axios and towards the ErgoDox EZ, and the fact that the ErgoDox has proven software for it.

Which causes me to ask: what about the software side of things? Are you going to be able to use any existing firmware? Looks like TMK and chrisandreae are valid alternates for ErgoDox with each its own set of special features... Rather than writing new software right from scratch (and go through a long debug/maturation cycle) would it be better/possible to use one of these?

Thanks all for the congrats

I've been avoiding giving a timeline because with my work schedule, I honestly wasn't sure what was manageable. Given where I'm now at with development and the fact that I'm now able to move to a full time schedule (without coming home burned out from work), we're tentatively aiming to get the campaign ready to go by the end of November/first week of December and are pulling assets together to make that happen.

Firmware wise the first version will be what I've been working with which is based on the mbed platform, however I've already talked with Koren about getting one of the beta units in his hands since he's been chomping at the bit to get up and running with it. With a full time schedule I do want to take a look at what it'll take to get some of the extended functionality running with TMK. It's entirely possible the final firmware will either be something from Koren or a fork of TMK. This is one of the many reasons we're sticking with open source.

If you manage to get extended functionality running with TMK through mbed, is that something that can be ported back upstream for Infinity boards as well? Because that would be awesome. I'm running TMK on both of my Infinities despite the missing boot magic, media keys, etc., just because I like working with it so much better than that web configurator.

[AcidFire]

We've been in contact with a couple of shops already, including the local one I've mentioned a few times who we'll be working with through the final design changes to ensure we've got a proper timeline. Currently we're still aiming to handle pretty much everything but the injection molding in house which shortens our production timeline since we're not sitting a queue with other projects. We're still aiming for a 6 month delivery from the end of the campaign, with the possibility of much sooner if things go well through the final design steps.

As for the firmware, it wouldn't be TMK through mbed, it would just be TMK, or possibly a fork of TMK, depending on what we're finding for the final functionality. It's really tough to say until I've got the latest controllers in hand, but I've got some work arounds coming in the meantime. What is it that you like better about TMK specifically njbair?

[Niomosy]

Great news.  So we've got under 6 months for wallet preparation, everyone!