agent

2019 Feb 14

Shipping is about to resume

By |2019-02-14T21:17:04+00:002019-02-14 21:14|agent, manufacturing, news, tech talk|0 Comments

TL;DR: Delivery temporarily stopped due to the shortage of packaging material which should resume around February 20. We expect to ship every non-module preorder by the end of March. Regarding the ETA of your order, please check out the delivery status page, including its FAQ section.

Hi there, and welcome to our monthly status update! Let’s get right to it!

Manufacturing progress

Since our previous monthly update, we’ve built plenty of UHKs, but we couldn’t ship most of them due to a temporary shortage of packaging boxes.

It’s taken more time for the printing factory to get up to speed after new year, and they expect to deliver the packaging boxes to us on February 20. We’ll make quick progress once the boxes arrive, and expect to deliver every non-module preorder by the end of March.

We didn’t simply ask for another batch of packaging material to be honest. We redesigned the boxes because they weren’t sufficiently robust. The new boxes are not only fancy, but more robust (and more expensive).

I added a news section to the top of the delivery status page which you’re welcome to check any time. This way, you can keep informed about delivery status the easiest way possible.

DeveloperWeek cancelled

In our previous monthly update, we told you that the we’ll exhibit at DeveloperWeek in the Bay Area on February 21-22. Unfortunately, we won’t be able to make it.

The reason is that I fired our marketing contractor because I found his work ethics to be extremely poor. Without him, we can’t staff our booth, so I ended up cancelling the event. Admittedly, this timing is unfortunate, but I only regret having him so long. Of course, no personal data was compromised during or after his time with us.

With the event cancelled, we won’t be able to give away the free passes offered in our previous monthly update. That, I regret. I’m sorry about this, but now that we have cancelled the event, we can’t do anything. I’ll email all of you who asked for free passes shortly after publishing this update.

As far as the project is considered, I think not attending to DeveloperWeek is actually a good thing. We should fully focus on the delivery of preorders at this point. We’ll have plenty of time to do expos later.

Module progress

Robi has implemented the kboot bootloader protocol natively in Agent. Previously, Agent used the external blhost command line utility which was unreliable. This will make firmware updates more reliable which is very important because the modules will require a new firmware version flashed to your UHKs. We have yet to release a new Agent version that contains this improvement.

In the meantime, András advanced the mechanical design of the key cluster module, so it’s closer to the final design to be mass produced.

As stated in earlier updates, we can’t fully focus on the modules yet. Only after shipping every non-module preorder and transitioning to on-demand manufacturing will be able to make heavier progress regarding the modules.

Your feedback

Mikko Ahlroth wrote a very nice UHK review on his blog. I love reviews like his which go into details and capture many facets of the UHK.

In the meantime, Brett Terpstra has been exploring the wonderful world of custom keycap sets. He pimped up his UHK, and wrote a blog post titled The addictive hobby of customizing mechanical keyboards.

We’ll be keeping you updated on all things UHK, and we’re looking forward to talking to you on 2019-03-14.

2018 Dec 13

Shipping UHK webshop orders

By |2019-01-18T16:15:23+00:002018-12-13 18:42|agent, news|20 Comments

Any questions, please search our knowledgebase.

Hi there, and welcome to our monthly status update! Let’s get right to it!

Crowd Supply order delivery progress

Just as promised in our previous newsletter, and according to our delivery status page, we’ve shipped every non-module Crowd Supply order. If you haven’t received yours, Crowd Supply has yet to forward it to you which might take days to weeks. You should be good to go, but any questions, feel free to contact Crowd Supply for support.

Speaking of Crowd Supply, they’re in the process of transitioning their support system, and as a result, your recent emails destined to crowdsupply.com might have been lost. If you haven’t received a reply from them in two business days, then ping them again.

UHK webshop order delivery progress

The assembly of UHK webshop orders is well underway. The reason we haven’t yet shipped any UGL webshop orders is because I haven’t yet finished overhauling our order fulfillment system which is necessary for shipping UHK webshop orders.

I’m nearly ready, we’ll start to ship UHK webshop orders within days, and we’ll ship about 200 orders before the holiday season kicks in.

Estimated delivery dates

As you may already know, we have a delivery status page which contains the estimated delivery dates of pre-orders.

I must emphasize that despite our best effort, these delivery dates are fundamentally inaccurate because numerous factors affect production. There are two main factors we’re already aware of which will affect upcoming delivery dates.

First, our factory will be shut down during the holiday season. The delivery estimation algorithm assumes a constant manufacturing pace, so the estimations will move forward during the holiday season. I’m sorry about this, but I won’t dedicate any more time to tweak the estimation algorithm because I have to focus on more important issues, and we’ll deliver every pre-order soon anyways at which point the delivery page won’t be useful anymore.

Second, a temporary shortage of various components are expected including product boxes and plastic cases. Admittedly, we should have managed inventory better, and we’ll do better going forward, but this will probably delay the delivery of pre-orders in January. We’ll do our best to mitigate the situation.

All things considered, we expect to deliver every non-module UHK webshop pre-order in January to February. Thank you for your continued patience and support!

New Agent feature

The “double tap to lock layer” feature of the UHK is a blessing for most, and a curse for some. Some of you told us that sometimes you accidentally toggle layers (most notably the frequently used Mod layer) due to this feature.

Fear not! The most recently released Agent 1.2.12 is here for the rescue, as it allows you to disable this feature on a per-key basis according to the following screenshot.

Unchecking the “Lock layer when double tapping this key” checkbox will magically disable this feature for the relevant key. Just to clean up any confusion, this feature is only available for layer switcher keys (Mod, Fn, and Mouse) as it wouldn’t make sense for other keys.

This Agent version also makes the warnings that told you that macro support is not yet available disappear. If you still see this message, update your UHK to the latest firmware in Agent, and the macro warning should disappear.

On a somewhat related note, I have written an article titled “How can I type accented characters with my UHK?”. The title gives you a good idea whether it’s for you. It’s also worth reading if you’re interested about the difference between USB scancodes and characters, or if you want to know more about Alt codes.

Pimped UHKs

Some of you keep pimping your UHKs, and we’re always glad to feature your beautiful creations!

A very fancy UHK by @menyao. See Twitter thread.
A runic UHK by @ElDanDanito. See Twitter thread.

Your feedback

The feedback you keep giving us is nothing short of amazing. Sometimes we shake our heads in disbelief when we see loads of enthusiastic tweets pouring in. These are some of the many recent tweets we got from you.

As a closing word, we wish you a Merry Christmas, and Happy New Year! 2018 was quite a year for us, and we’re just getting started! Thank you so much for believing in us and supporting us!

We’ll be keeping you updated on all things UHK, and we’re looking forward to talking to you on 2019-01-17.

2018 Sep 17

Remapping keys in Agent

By |2018-10-12T16:48:31+00:002018-09-17 18:53|agent, howto|0 Comments

Although we did our best to make Agent as intuitive as possible, we get questions from time to time. By far the most usual question is how to exchange the keys of the bottom row.

Let's say you want to exchange Alt and Fn.

Now select the base layer of your default keymap in Agent. You should see something like this:

The important thing to understand is that each key has an associated action. Let's click on Alt.

A popover appears that contains the type and properties of the action. The Keypress tab is active so this is a keypress action (type) featuring no scancode and the left Alt modifier (properties).

Now let's see the action of the Fn key by clicking on it.

Now the Layer tab is active which means that it's a layer switch action which activates the Fn layer while holding this key.

You simply have to exchange the actions of the Alt and Fn keys by clicking on them and setting their action type and properties. Make sure to check the "Remap on all layers" checkbox for modifier keys before clicking on the "Remap key" button.

Lastly, click on the "Save to keyboard" button in the bottom right corner.

That's about it! Happy remapping!

2018 Sep 13

Lunar UHKs, Unicorns, and the Freeze bug

By |2018-10-23T20:00:41+00:002018-09-13 22:37|agent, features, manufacturing, news, tech talk|0 Comments

Hi there, and welcome to our monthly status update!

TL;DR: Please update to the latest UHK firmware for macro support, and to help us fix the freeze bug that plagues recent firmware versions. Agent now visualizes secondary roles. We’ve churned out 6 mini batches since our last update. The development of the modules is going slowly while delivering the pre-orders, but we’ll switch to high-gear afterwards.

Update to the latest firmware!

If you’re reading this and already have your UHK, please flash the latest 8.4.5 firmware by selecting the .tar.bz2 file from the "Choose firmware and flash it" option in Agent > Firmware. This will result in many goodies over the factory-flashed 8.2.5 firmware, including macro support and numerous bug fixes.

The only gotcha is the freeze bug. Recent firmware versions cause occasional freezes on some UHKs. This is a longstanding bug, and the only reason we haven’t yet fixed it is because we can’t reproduce it. That’s why we need your help! The more people who use the most recent firmware, the easier we can fix the freeze bug based on your feedback.

If your UHK freezes, please be sure to report it according to the freeze bug issue. No worries, you can always downgrade to 8.2.5 to regain stability.

Fancy UHKs

If you’re a regular reader of our monthly updates then Max is no stranger to you, as he’s on a never ending quest to pimp his UHK. This time, he used the Godspeed Cockpit keycap set to customize his UHK and in his true style, he shared the gory details on Reddit.

In the same spirit, Richard was also busy, and ended up creating the most unicornish UHK with extra rainbow flavour!

Secondary role visualization in Agent

Dual-role keys are powerful. When tapping them they trigger their primary role. While holding them and pressing other keys, the secondary role kicks in. The UHK has always supported dual-role keys, but Agent hadn’t visualized them. Thankfully, this has just changed with Agent version 1.2.9.

Now Agent can render quite complex scenarios, such as a scancode featuring modifiers and a secondary role. This makes the rendering engine of Agent complete, so you can take a look at any layer and know exactly what each key does based on its visual representation.

As an added bonus, we’ve made modifiers show up according to your OS, so for example, Super is Command on OSX and it’s the Windows key on Windows.

Production progress

The 6 mini batches we have produced over the last month have not constituted our fastest pace, but they’re in line with our recent progress. Manufacturing progress occasionally suffers a bit due to a number of factors. For example, our palm rest supplier was on vacation recently, and had to catch up with production. Such cases only cause temporary hiccups, and they can occasionally affect the sizes of mini batches positively or negatively, but we always manage them quite well.

In the meantime, we’ve already pre-ordered the parts of the second large batch of UHKs. The first large batch contained 2,000 UHKs, and the second large batch contains 1,000 UHKs. We’re not VC-funded and fully rely on your support, so being able to pre-order the parts of a large batch is a big achievement for us. This means that production will be uninterrupted in the future, even after delivering the pre-orders. A sincere thank you to every one of our backers for making this huge milestone possible!

Development progress

As you can see, we keep pushing Agent and the firmware, but it’s quite a challenge to do heavy R&D these days because production and related tasks are so demanding.

Customer support is time consuming, as well as developing and fine-tuning backend systems. These tasks are not visible from the outside, but they’re absolutely necessary to keep things going.

Transitioning to our own webshop did end up heavily affecting our backend systems, including the integration and implementation of the webshop, factory automation, order fulfillment, and invoicing systems. Pre-ordering the parts of the second large batch also called for a procurement system which is up and running, but it has taken quite some time to set up.

Due to the above, we could only make a little progress with the modules. András has further refined their mechanical design, and will hand them off to a mold designer to finalize their mechanical features. I figured out how to optimally panelize their PCBs and factory-flash their firmware the most efficient way. We’re mindful about the modules, and will switch to high-gear once the delivery of the pre-orders is over.

Thank you for reading this update! We’ll be keeping you updated on all things UHK, and we’re looking forward to talking with you on 2018-10-12.

2018 Jul 12

Knee-deep in production

By |2018-10-23T19:59:50+00:002018-07-12 20:23|agent, news|33 Comments

Important: Please make sure that your shipping address is up to date! You can change it on your Crowd Supply account page. Please also check out the delivery status page.

Hi there, and welcome to our monthly status update!

TL;DR: Since our last update, we’ve sent out mini batches 10, 11, 12, 13, 14, and 15, which is, yet again, the highest volume batch we’ve produced so far, but not as high as we aim for. We had to allow a week of vacation for our staff in the middle of summer. Without the vacation, we’d have likely hit our target volume, so the ramp-up is still not over. Apart from manufacturing, Agent and the firmware keep advancing, and some major progress is expected soon.

Your recent feedback

A monthly UHK update wouldn’t be complete without featuring your awesome feedback.

Our first English review is out on Reddit, which you’re welcome to read! As creators, reading such nice words is all we can wish for.

But Max, the writer of this review didn’t stop there, and pimped his UHK with the third-party Canvas XDA keycap set.

And Max still couldn’t get enough, so he ended up writing a full-blown UHK keycap replacement guide on Reddit! Thanks so much for the great work, Max!

Third-party keycap sets are clearly in the vogue nowadays. We believe the following picture is quite a sight!

And you keep sending us your nice tweets:

Last but not least, even Michael Bolton approves the UHK.

Please keep it up! We love hearing from you.

Agent and firmware progress

We keep pushing Agent and the firmware at a steady pace. Most of these improvements come in small increments, and many of them are under the hood changes, so it’s hard to notice them. But they add up in a big way over time, and every now and then some user-facing changes are committed.

Some of you found it cumbersome to remap keys on all keymaps and/or layers, so we extended the UI of Agent accordingly. The tooltip should speak for itself.

We also added a separator line between the halves, so it’s easier to locate keys.

The above are frontend changes, but there’s a lot more going on under the surface.

Recently, we’ve been working hard on fixing a Windows-specific firmware bug that is responsible for media key repetition, and not letting your computer go to sleep on Windows. We’ve managed to fix this bug, but then a nondeterministic bug emerged which made the UHK hang sometimes only after hours, which turned out to be very problematic to fix. We believe that we did fix it, but I want to test it thoroughly before releasing a new firmware version.

The new firmware release will also contain a major feature: the macro engine! We promised macro support a long time ago, so we’re super excited to make it happen. Agent is already capable of editing macros, but the macro engine of the firmware is a critical piece of the puzzle to make macros actually work on your UHKs.

Let me just say that we’re super focused on implementing the promised features, and even more so on fixing bugs. One reason is that they directly translate to a great user experience. The other reason is that as more and more UHKs make their way to you, we keep getting a lot of reports of the same issues, so fixed bugs directly translate to lower overhead. Please do keep reporting bugs, but always use the latest Agent and latest stable firmware versions.

Running production, developing Agent and the firmware, and answering messages is a lot to deal with at the same time, and as a result, we couldn’t devote time for the modules over the last month. We’re asking for your patience, as we’re rather overloaded nowadays.

Thank you for reading this update! We’ll be keeping you updated on all things UHK, and we’re looking forward to talking with you on 2018-08-16.

2018 Jun 23

How can I type accented characters with my UHK?

By |2018-10-30T19:43:14+00:002018-06-23 23:55|agent, howto, tech talk|29 Comments

We get this question from time to time, and the answer is not so obvious as one might think. I'm about to explain it in depth, but first I'll give you the short answer in case you're in a hurry. Please consider the relevant tooltip of Agent:

Hopefully, this explains what to do. You're welcome to suggest a better phrasing in the comments, but this is the short and sweet version. And now on to the more detailed explanation.

Characters vs Scancodes

The most important thing to understand is that USB keyboards (the UHK included) do not send characters to your computer. No, Sir. They send scancodes. When you press a key, a scancode of 1 to 255 gets sent to the computer. It's not a character, but a number!

Now think about this: There are 255 different scancodes which must be mapped to more than 100,000 characters that are used on planet Earth! How so? This is how:

Your operating system translates scancodes to characters based on your actual operating system keyboard layout.

Let me give you an example to make you realize the crucial role of your OS layout. Let's say that an American, a German, and a Russian user purchase USB keyboards of the same physical layout. Now let's take the semicolon key according to the American layout. On all three keyboards, when pressing this key the scancode 51 gets sent to the computer, yet, the character ";", "ö", and "ж" appear of the screen of the American, the German and the Russian users respectively, merely because they use different OS keymaps.

When it comes to mapping scancodes to characters, the situation is actually slightly more nuanced because modifiers also affect the mapped characters. For example, on the US layout Shift + 4 produces "$", and on the Hungarian layout AltGr + U produces "€", but this doesn't alter the nature of the beast.

Alt codes

There's a mechanism called "Alt codes" which allows users to produce various accented characters in a way that is (mostly) independent of the current OS keymap.

  • On Linux, press Shift+Ctrl+U which prefixes your cursor with an "u", indicating that now a unicode number is expected. At this point, enter "2764" followed by Enter and ❤ will magically get inserted. Linux Alt codes are the most powerful and most standard given that they're backed by unicode numbers.
  • On Windows, first you have to have Num Lock enabled. Then hold an Alt key and press a Windows-specific numeric code, and finally release the Alt key at which point the relevant character will be included. Merely 375 different characters can be included this way.
  • On Macintosh, there's also a similar mechanism that is better called Accent Codes. Let's say you want to put an accent to the "o" letter. You press Option+E, then press "o" which results in "ó". The set of characters that can be produced this way is similarly limited as on Windows, although in true Mac fashion, the implementation is much more intuitive.

Alt codes provide a way to output various characters in a way that is mostly independent of the current OS keymap, but they're OS-specific, and they don't work in every environment. For example, let's say that your hard drive is encrypted and you have to type a password before the OS boots up. Depending on your OS, Alt codes may not be available at this point. On Linux, they also can't be used in terminals outside of the X server, so you can't rely on them in every environment.

Alt codes on the UHK

Given that Alt codes are sequences of keystrokes, they're ideally suited to be assigned to keys using UHK macros. For example, you can bind the Alt code of "é" to Mod+e. UHK macros very handy, since they're saved to the on-board memory of your UHK, and always availblable without running special software once you set them up via Agent. I'm about to elaborate on implementing Alt codes on your UHK.

The macro editor of Agent is very intuitive to use, and based on the above one should be able to create macros that implement Alt codes. There are some gotchas, though.

First up, Alt codes are OS-specific which will pose a problem if you use multiple OSes. If so, you'll have to create all your Alt code macros for every OS you use, and then create OS-specific keymaps in Agent and bind the macros of the respective OSes. This is clearly laborous, but there's no way around it. We won't implement USB fingerprinting in the UHK firmware to detect OSes because it's fundamentally unreliable.

The second gotcha is that you won't be able to compose Alt codes with modifiers. Imagine holding Shift, then typing Alt code key sequences, then releasing Shift. Modifiers clearly mess with Alt codes.

Third, some Alt codes are dependent on the state of your OS. You have to have NumLock enabled for Windows Alt codes, and Mac accent codes are dependent on the OS keymap in use.

Accented characters in Agent

Some of you were wondering why Agent doesn't offer or display accented characters. This is one of those features that seem like a no-brainer from a user perspective, but in practice, it's not only incredibly hard to implement, but cannot be implemented properly. Let me tell you why.

In order for Agent to expose accented characters, it must be aware of the current OS keymap. Being a cross-platform application, it'd have to query the actual keymap on Linux, Mac and Windows. A quick search reveals ways to query this information (often rather obscure ways) via OS-specific APIs, but I have found no way to query the actual mappings between scancodes and characters which is critical.

Without the exact, per-key mappings, Agent would have to have a database of every single OS-specific layout, such as "French (Bepo, eronomic, Dvorak way, Latin-9 only)", or "Russian (Ukraine, standard RSTU)". We could extract such a database from the relevant Linux packages, but these layout names are not standardized so they're inconsistent across OSes and the mappings surely differ in some ways.

The bottom line is that it'd take huge resources to implement the above, and we'd end up with a half-assed implementation given that a perfect implementation is practically infeasible. Even if we were able to implement this perfectly, I don't think it would be a good idea. I can foresee users complaining that they set up the é key in Agent, then plugged their UHK into another machine (featuring a different OS keymap), and the é key suddenly became semicolon. Users should actually understand how things work when it comes to this topic.

That's it, folks! If you're still reading, then you're truly one of the brave few. Any questions, feel free to shoot them in the comments.

2018 Jan 19

Pilot run success and what’s next

By |2018-10-23T19:49:06+00:002018-01-19 02:36|agent, manufacturing, modules, news, tech talk|23 Comments

Hi there, and welcome to our monthly status update!

TL;DR: The first 50 UHKs and palm rests of the pilot run were delivered, and according to the feedback we received it was a huge success! The recipients of the pilot run gave us a ton of feedback, so we’ll go over the issues they encountered, and tell you how we’ll fix them in upcoming batches. We’re raising the price of the palm rest to $55, and we’ll raise the rest of the items by 10% soon. We plan to deliver the remaining 1,950 UHKs of the first batch from February to April. We’re putting an increasingly heavy emphasis on finalizing and manufacturing the modules.

The Pilot Run Was a Huge Success

It’s one thing to design a product, and another to ship it to all over the world. András and I poured our hearts and souls into this project, we obsessed about the smallest of details, and even though we were definitely hoping for the best, we couldn’t know for sure how much you’d like the end product, so it’s safe to say that we were excited.

I’m happy to say that the feedback we received from the recipients of the pilot run was absolutely fantastic! You praised the overall build quality, the nice packaging, the onboarding experience, and the ease of use of Agent among other things.

Let me feature a couple of your tweets:

Thanks so much for the posts, everyone! Your enthusiasm and support have been overwhelming!

Pilot Run Issues

Despite its success, the pilot run wasn’t without issues. In the spirit of transparency, we’ll go through all of the issues you encountered.

Smashed Boxes

There are two small boxes within the main UHK box which got smashed on four occasions out of the fifty pilot run units. We believe that some of these occurrences went unreported, and there may be more. This is what a smashed box looks like:

We spent a ton of time and a fortune on packaging, so this is a big deal. Even worse, on one occasion, even the case of a keyboard snapped apart. Luckily, the owner managed to snap it back with a bit of pressure, but this doesn’t make the issue any more acceptable.

According to the reports we received, only USPS-shipped UHKs were affected. We’re not sure whether it was due to the holiday madness, or if it’s a general issue, but we reinforced the boxes, which will hopefully resolve this issue in the long run.

Sharp USB Cable Recess

There are two recesses in the case which hold the USB cable and they’re way too sharp and chew up the USB cable quickly.

The mold has already been modified, so the edges should be smooth going forward. A backer reported that he easily managed to sand down the sharp edge, resolving the issue in no time. If you’re affected, you might want to do the same, but if you want a replacement case, please just let us know.

Loosely Connected LED Display

Some of you reported strange artifacts appearing on your LED display, which is a sure sign of a loose FFC cable.

The FFC cable connects the display with the left main board. Apparently, we could have done a better job connecting them during the assembly process. As a result, the cables of two UHKs got loose during shipping. We’ll try our best to more thoroughly assemble future batches.

This issue called for our first ever repair guide. We have already emphasized the importance of repair before, and this was the golden opportunity to follow our words up with action. Both affected backers were able to fix the issue using the guide and they even contributed to it. Thanks so much!

Just to get things straight, we don’t expect anybody to repair his/her UHK, but the opportunity is there, and we encourage repair in general. It’s certainly much faster than sending it back and forth to the other side of the world, and especially useful after the warranty period is over.

Feet Molding Issues

On two occasions, visible artifacts were noticeable on some feet.

This is clearly an injection molding issue. We’ll do heavier QA in this respect.

Software and Firmware Issues

A number of issues have been reported recently in the firmware and agent repos. The vast majority of these issues are not critical, but they affect usability in one way or another.

Understandably, we’ve been mostly busy with the critical issues. The most critical was a firmware issue that made the UHK freeze after a while. This was really annoying because it was super hard to find the root cause of it. Luckily, it looks like we’ve been able to resolve this, and it shouldn’t affect more people.

There was another critical issue in which the left keyboard half got bricked during the firmware update process. I’ve made the update process more robust, and improved the update script, which unbricked the unit. This script feature will be integrated into Agent soon. The UHK should very rarely get bricked, and when it happens it should always be unbrickable.

Going forward, we’ll be addressing all of the issues of the agent and firmware repos, but there’s a lot on our plate nowadays, so some may take a while. We’re doing our best.

All Hail Our Contributors

Mikko Lakomaa, an early contributor of ours, switched into high gear after receiving his UHK, and implemented two much-welcomed issues. Thanks to the fruits of his labor, now we can adjust mouse speed and LED brightness via Agent.

Thanks so much for your contributions, Mikko! It’s nice to see Agent improving so rapidly.

Price Increases

Effective immediately, we’re raising the price of the palm rest to $55, and we’ll raise the rest of the items by 10% soon. Let me explain why.

When we originally envisioned the UHK palm rest, its design wasn’t finalized, and we weren’t sure about the materials and technologies we’d ultimately use to craft it. We were also unfamiliar with the costs involved. As the design progressed, we were consistently moving toward an increasingly high-end, premium product which inevitably added to its cost, so much so that up until this point we haven’t had any profit on the palm rests when selling them for $30.

For what the palm rest is worth, $55 is still a bargain considering the market prices. If you search for “wooden wrist rest”, $40 is a usual price tag, but those palm rests are made of one wood piece, not two pieces, don’t feature powder coated black plates, and their geometry is less ergonomical (simpler, thus cheaper to machine) than the UHK palm rest.

Eventually, we’ll further raise the price of the current wooden UHK palm rest to about $80 which is a reasonable market price, but before doing so, we plan to offer a less premium, and more affordable palm rest in addition to the current wooden palm rest.

We’ll also soon raise the price of the other items by about 10%, including the UHK, extra keycap sets, extra cases, and the modules. This is justified by the heavy weakening of the US dollar during 2017. We pay our suppliers primarily in Hungarian forint, so this very much affects us. 10% is actually less than the weakening of the dollar which is about 15%, so we’re trying to not raise prices too heavily.

Nobody likes price increases, but we’d much rather take this route than sacrificing quality, or allocating less funding for R&D. We hope you understand and resonate with our mindset.

Expected Delivery and What’s Next

Going forward, our most immediate goal is to deliver the remaining 1,950 UHKs and accessories (everything but the modules) of the first batch. We expect to deliver these items from February to April, and then the second batch will closely follow.

Our assembly operation is admittedly micro-scale compared to the assembly lines of China. As we previously stated, instead of hiring a Chinese OEM for assembly, we opted to set up our own assembly line in Hungary and operate it in the long term. This has numerous benefits, like rigorous QA and direct control, but the downside is that the throughput of this line is rather low.

It wouldn’t make sense to massively scale up production because the accumulated preorders translate to a huge peak regarding assembly. It’ll considerably settle down after delivering the pre-orders, so hiring a bunch of people only to fire them soon afterwards doesn’t seem like a good idea.

We plan to keep assembly going continuously, and ship so-called mini batches on a weekly basis. We’ll remind you in a future update to change your shipping address before orders start going out, but please do check/change your current address by going to your Crowd Supply account.

As for the modules, fear not, we didn’t forget about them. We’ll be allocating more and more resources to finalize and manufacture them. András has been working on them recently, and this is the latest, and probably final design of the trackball module.

I think András did a great job designing this module. I cannot wait to see it work and give it a whirl (pun clearly intended).

Thank you for reading this update! We hope you enjoyed it, and we’re excited to talk to you on 2018-02-15.

2017 Oct 12

FCC success and development news

By |2018-10-23T19:47:18+00:002017-10-12 16:23|agent, electronics, manufacturing, news, tech talk|14 Comments

Hi there, and welcome to our monthly status update!

TL;DR: We’ve passed FCC certification, and CE is in progress. We’re progressing with assembly, loads of UHK boxes arrived from the printing factory, and the UHK accessory boxes are already packed. The firmware and Agent have matured substantially. We’re waiting for final answers from TÜV to proceed further.

We’re aiming to send out the pilot run UHKs in October, and start the delivery of the rest of the first batch of 2,000 UHKs in November. If you backed us after 2017-07-13 then you’re in the second batch, which is expected to ship in March 2018.

FFC and CE certification

A week ago, we got great news from TÜV:

“All FCC 15 ready and just PASS for Radiated Emission. Producing the report now.”

Then I asked about CE, and to my surprise they told me that they didn’t know that we also needed CE measurements. I searched my emails to see whether I miscommunicated something, but I didn’t. Not only did I mention both FCC and CE, it was part of the subject line. It’d have been hard to make this any clearer.

I told TÜV that we would really appreciate if they wrapped up CE as fast as possible, especially considering the recent delays that they added to our project. They promised me that we’ll have the official CE report by the 18th. They did not promise an ETA regarding the FCC report, but told me that it’ll be ready “soon”.

To be perfectly honest, given the recent complications, we’d like to switch to an alternative certification body, but it’s way too late, and we don’t have any other options in Hungary. Going forward, I’ll be pinging them regularly to try to keep this under control. I believe this will get sorted out soon, and we’ll receive the certification papers shortly.

Our contract manufacturer is eager to start production, and as soon as we receive the reports from TÜV, we’ll start the PCBA of the pilot run units.

Manufacturing progress

Even though the PCBs are not assembled yet, we’re working on assembling and packaging everything else.

There are two small boxes inside of the main UHK box, one containing the USB cable, the other containing the bridge cable, the flip-out feet and their screws, and a lock strip that securely locks together the halves if you choose to use it. We’ve packed 500 of these boxes.

We’ve tested 500 USB cables and 500 bridge cables, and they all worked flawlessly. This is a good sign. Our cable suppliers definitely seem to be on par.

Right now, the case buttons are being pad printed. These are the first samples:

We’ve chosen the top, brighter color sample, even though the difference is hardly noticeable in this picture. Unlike our first pad printing supplier candidate, this supplier seems to perform just as expected. The prints are razor sharp, spotless, precisely positioned, and the correct font is used.

The cases are semi-assembled and we’re waiting for the back stickers to proceed further. We already received 3,000 stickers from the printing factory, but they were shiny instead of matte. Then we received a supposedly corrected batch of 3,000 that were matte, but lacked anti-scratch coating.

Now the printing factory will print yet another 3,000, and we’re hopeful that they’ll get it right this time. This journey is as expensive for them as it is time consuming for us. Once we get the correct back stickers, we’ll apply them to the case, and then glue small rubber feet to the cases,concluding their assembly.

We’re also making progress with the colored cases. This is the first colored case sample of a random test color:

Last but not least, 3,000 UHK boxes have arrived from the printing factory:

Being pre-assembled boxes, they take up quite a lot of floor space. 15 pallets to be exact. Maybe we shouldn't go with preassembled boxes next time.

Firmware progress

I’ve been heavily focusing on the firmware during the last couple of weeks and managed to make quite a lot of progress.

More than anything else, I wanted to make the I2C communication between the keyboard halves rock stable. Placing the bypass capacitors as closely to the IS31FL3731 LED driver ICs as possible made the communication much more robust, but from time to time it halted. The capacitors couldn’t totally negate the parasitic capacitance of the I2C bus, and these LED drivers being as picky as they are, the problem persisted.

Eventually, I managed to find a solution that is described in the AN-686 application note. The core problem is that when I2C communication halts in the midst of the communication, it makes the state machine of the slave that is being addressed wait for further data. Just as suggested by the application note, I clocked through the slave by toggling SCL until SCA went high.

This helped tremendously, and it made communication always recover when disconnecting and reconnecting the keyboard halves, but when using the keyboard over an extended period, the left half eventually became non-responsive.

I could reproduce this issue fairly reliably by making the right keyboard half reenumerate as the bootloader. This interrupted the communication with the left keyboard half, but didn’t unpower it, which always happens when disconnecting it. I also figured that the left KL03 MCU is the culprit because when I rebooted it, the communication always resumed. I needed to fix this issue.

First try: I2C watchdog

I thought that the issue could be solved by implementing an I2C watchdog not only for the right keyboard half but also for the left keyboard half. This proved to be a lot more difficult than anticipated thanks to a bug that I made earlier.

I created a timer interrupt, and put the I2C recovery code into it to reinitialize the I2C driver. Among other things, it called the Init_I2C() function. I realized that when commenting out Init_I2C() within the timer interrupt, the firmware worked, but when uncommenting it, it hit a hard fault. This was seemingly impossible because the hard fault also got hit when I deactivated the timer interrupt, so Init_I2C() wasn’t ever called within it.

I couldn’t figure this out, so I managed to summon Santiago who delved very deep into the issue. It also turned out that the debug version didn’t work at all, so he had to figure this out by looking the disassembled, gcc-optimized ARM assembly code of the firmware.

Santiago finally concluded that the issue was that I defined the I2C_Handler struct within a function so the struct got allocated in the stack, but after returning from the function this variable got deallocated. The problem is, the KSDK still tried to use the struct even after being deallocated, which triggered a hard fault.

The issue didn’t surface when referencing Init_I2C() once across the codebase because the function that contained the definition of the I2C_Handler struct got inlined so it was like being defined in main(), and never got deallocated. But when referring Init_I2C() twice, it wasn’t inlined anymore and the issue surfaced.

After this incident, I’ll surely think twice about making KSDK variables global. For even more details, Santiago created a slide which you’re welcome to study.

Unfortunately, even though my left-side I2C watchdog was running, it still didn’t do the trick. Somehow, communication didn’t recover. Which brings me to my second try.

Second try: hacking the KSDK

At this point, it was down to debugging. I needed to see not only what went over the wire between the MCUs of the left and right halves, but also what was happening inside of the KL03, especially regarding the state of its I2C driver. Using the debug feature of Kinetis Design Studio didn’t work for me as it pauses execution and given the realtime nature of the communication, it doesn’t behave as expected.

Then I tried to make semihosting work which basically allows the microcontroller to dump strings via the debug probe to the console using printf(). Unfortunately, I couldn’t make semihosting work because it crashed the microcontroller for some reason that I couldn’t figure out. Semihosting would also have posed a significant runtime overhead anyways, and it might have made the firmware behave differently, so maybe it’s not a big loss. In any case, I had to find an alternative solution.

Finally, I figured that I’d just use a spare peripheral of the microcontroller to dump relevant data, and I ended up using the SPI peripheral of the KL03. For this, I needed to temporarily repurpose two GPIO pins that were used to scan a row and column of the keyboard matrix. This made the prototype practically useless for touch typing temporarily, but that’s a small price to pay.

At this point, my prototype looked like this:

The halves are interconnected by two spiral cables via an adapter board. The adapter board features a 4P2T switch which allows me to disconnect and reconnect the halves easily for testing purposes. The adapter board also breaks out the wires of the cables. The wires I’m interested in are the SDA and SCL – the clock and data lines of the main I2C bus of the UHK.

Apart from I2C, I also soldered two wires to the MOSI and SCK pins of the SPI peripheral. And finally, I connected the two I2C wires and two SPI wires to my Logic 4 analyzer.

What you can see above is the result of the fixed code. Channels 0 and 1 are the SDA and SCL of the I2C. Channels 2 and 3 are the MOSI and SCK of the SPI. For every byte sent by the master over I2C, the status byte and the received byte get dumped over SPI on the slave. The received byte correctly gets dumped over SPI right after receiving it, which is the way it should be.

The core issue was that the KSDK I2C driver is designed for fixed-size messages, but the UHK messages are variable-sized. They contain a header of a byte length, and a 2 byte CRC16-CCITT checksum. I ended up hacking the KSDK of both the left and right keyboard half to make it deal with our variable-length messages.

The effort that went into making the keyboard halves and the modules communicate reliably is quite incredible. It makes me appreciate already established and widely implemented protocols like TCP/IP that just work. I’m so happy that this critical foundation is in place.

Apart from the above long journey, I implemented loads of fixes. Now we have a pretty changelog, and versioning conventions.

Agent progress

Robi has been really pushing hard recently. I’m impressed by his work, and his efforts came to fruition as Agent is now able to read and write the configuration of the UHK. It’s a wonderful feeling to plug in the UHK, see the configuration appear on the screen, reconfigure it, and merely click a button to save the new configuration to the keyboard.

The smoothness of the user experience resembles the configuration applications of the largest keyboard manufacturers, but all things considered, Agent offers much more sophisticated configuration options than those keyboards.

It’s been a long journey to get there. And wouldn’t it be cool to visualize the development of Agent over its lifetime? As a matter of fact, it’s very much possible with Gource, so let’s take a look at it:

While we’re at it, let’s also take a look at the firmware repo:

There’s still a lot to do, but given the current state of the firmware and Agent, even the pilot run recipients should experience a smooth ride.

Thanks so much for your support!

In our previous update, I elaborated in detail on the manufacturing challenges which have been causing us delays. After publishing our update, it felt awesome that so many of you got in touch with us and expressed your fullest support. We’re glad that you share our pursuit for quality, understand the nature of the delays, and agree that the UHK is worth the wait.

What has been said about the challenges of manufacturing clearly reverberate in this update. After all, who would think that it’s possible to mess up mere stickers (twice), or misunderstand clearly written, basic instructions about the certification process. But it’s the real world, and human errors do happen.

PCB assembly should happen shortly, just after we get the FCC and CE reports from TÜV. Then we’ll quickly assemble the pilot run units and send them out, and the rest of the first batch will follow. We can’t see any major challenges ahead us, we just have to wait longer than anticipated which is something none of us like, but it’s seems that it’s the nature of the hardware business.

Thanks again for your support and understanding! Let’s keep in touch, and we’re excited to talk to you on 2017-11-16.

2017 Jul 13

Just before the pilot run

By |2018-09-17T19:09:39+00:002017-07-13 18:42|agent, electronics, manufacturing, news, tech talk|10 Comments

Hi there, and welcome to our monthly status update!

TL;DR: We’re making rapid progress with the assembly process. The firmware and Agent have matured significantly and become truly cross-platform. We have to make a minor design change on the PCB that will set us back by 2 weeks. Batch 1 has sold out and batch 2 will ship starting December.

You can always check out the expected delivery date and update your shipping address on your Crowd Supply account page.

Batch 1 has sold out

Given the uninterrupted pre-sales period since the end of our campaign, the first batch of 2,000 UHKs has just sold out. That means that going forward, new orders will fall into batch 2 which can be expected to ship in December.

Your orders will still be served on a first-come, first-served basis, but this delay between batch 1 and batch 2 is inevitable as we ramp up production.

Starting from batch 3 we expect to have a decent stock, so we’ll be able to provide you UHKs without any delay.

The inner assemblies are coming together

The inner assembly is comprised of a number of parts that reside inside the UHK case.

16,000 metal guides are already made. We'll have to press-fit the pins into half of them. Speaking of the pins, we’ve further optimized them. We’ve switched to using pins with spherical ends and a hardened surface, resulting in a heavenly smooth, yet solid merge-split experience. Perfecting these guides was an art unto itself.

Guides with spherical pins

600 pairs of plates have been manufactured and zinc-plated.

Zinced plates

We’ve learned that seemingly mundane parts like keycap stabilizers can take surprisingly long time to assemble. There are two identical left and two right parts that slip together, then a metal wire is inserted into them. Thankfully, we’ve already finished assembling 5,500 of these.

Assembled stabilizers

The above results in assembled plates like these.

Assembled plates, front side

Assembled plates, front side

Assembled plates, back side

Assembled plates, back side

So far, we’ve assembled 150 pairs of plates, and 50 pairs of those will be used for the pilot run. These plates will travel to our PCBA contract manufacturer who will solder them together with the PCBs. Afterwards, the guides will be screwed to the plates, completing the inner assemblies.

Outer assemblies and miscellaneous parts

As you can imagine, one of the most complicated parts are the plastic cases. So far, we’ve manufactured 150 pairs of bottom cases, and 2,000 pairs of case buttons.

Left bottom cases

Left bottom cases

Right bottom cases

Right bottom cases

Case buttons

Case buttons

The molds for the upper cases are being tweaked and we expect them to be perfected within 1-2 weeks, at which point we’ll put them to good use and manufacture 150 pairs of top cases.

Apart from the above, there are still a fair number of parts that go with the outer assemblies including the magnets, magnet-counter parts, rubber feet, inserts, back stickers, and a couple of screws.

Since our last update, we’ve also ordered 2,000 USB cables and bridge cables. Fun fact: the total length of these USB cables is 3.6 kilometers, or 2.23 miles.

Firmware progress

The firmware already works pretty well, but the configuration parser was very basic a month ago, only capable of parsing layers. It was clearly incomplete because it should parse not only a single layer, and not even a single keymap, but the fully-fledged binary configuration containing a set of layers, macros, and various items.

To my surprise, I received an email about a month ago from Eric Tang. Given his passion for keycaps, we’ve already exchanged numerous emails with Eric, but this email was different.

Eric asked me whether we have an internship program. He caught me by surprise and even though we’ve never had an internship program, I asked him what was on his mind exactly. As it turned out, Eric has written his own keyboard firmware based on AVRs and LUFA, making him the perfect candidate to develop the configuration parser of the UHK.

Since then, Eric has made tons of progress and now the firmware is able to parse almost the whole UHK configuration except macros. He’s now working on making the LED display show the abbreviation of the actual keymap, and then he’ll finish off macros, and develop the macro engine.

I feel very fortunate to have been contacted by Eric, and am having a great time working with him. The configuration parser shall be implemented soon!

Agent progress

Quite a few things have happened with Agent.

Right after Eric started working on the configuration parser, he couldn’t make Agent work on his Mac. I originally believed that it’s a privilege escalation issue, but Robi investigated further and realized that it’s a much deeper problem.

As it turned out, libusb, the library we used to make Agent talk to the UHK via USB isn’t supported on the Mac anymore. Apparently, recent OSX versions implement a new version of the USB subsystem which broke libusb.

Luckily, Robi found hidapi, the perfect alternative for libusb. In his true fashion, he didn’t waste his time, and ported Agent to use from libusb to hidapi. As a result Agent now runs perfectly on all the three major OSes.

Now, there’s only portability problem to be solved. blhost, the command line utility that updates the firmware of the UHK also utilizes libusb and it segfaults on OSX now that libusb is broken on Mac. Unfortunately, NXP doesn’t seem to care but fortunately, Santiago made me aware of pyKBoot, a python command line application that speaks the kboot protocol just like blhost, but which uses hidapi instead of libusb. I’ve toyed with pyKBoot a bit, and looks like it’s a viable alternative to blhost.

I think we can use pyKBoot but I’m not fond of it because we’ll have to package it as a standalone, self-contained executable, possibly using PyInstaller which will likely make the bundle size of Agent considerably larger than optimal. I’d really like to replace pyKBoot eventually with something more native to Agent. I think the best way forward is to port pyKBoot from Python to TypeScript later down the line.

Speaking of other parts of Agent, Robi has also implemented an auto-update mechanism. We have yet to refine it, but it seems to be already working.

Józsi also implemented a more general rendering mechanism for Agent, enabling it to render both ANSI and ISO keymaps according to your UHK version.

Electronics issues

Few days ago, I started to heavily test my backlit UHK prototype and found a serious issue. For some reason, the communication between the keyboard halves interrupted from time to time and eventually died.

Frustrated but determined, I delved into the issue and figured that it was caused by the LED drivers. When I disabled the LEDs, the prototype was rock stable. I further narrowed the cause, and found that the issue only surfaced when I enabled one of two LEDs, the LED of the right Alt key or the LED of the comma key.

I couldn’t make sense of this, so I got in touch with Integrated Silicon Solution Inc., the manufacturer of the LED driver ICs that we use. As it turned out, we didn’t place the bypass capacitor of the LED driver close enough to the IC. I soldered a through-hole capacitor as close as I could to the LED driver on my prototype and it solved the issue in no time.

Even though we don’t provide a backlit UHK version yet, many of you have expressed your desire to solder LEDs to your UHKs, so this is a big deal. Even more importantly, we already utilize the left side LED driver to drive the LED display and even though it didn’t produce such issues in itself, I fear that such issues could surface on a quite a few UHKs out of 2,000 UHKs, so this issue must be resolved.

Admittedly, this sucks, but thankfully, it’s a very minor PCB redesign which I’ll implement in about a day. We will, however, have to get new prototype PCBs made, assembled, and tested, so it will translate to a 2 week delay.

If there’s someone to blame, I surely am. I should have tested this way earlier. I’m sorry about this, but I’m also thankful because TUV hasn’t started testing our prototypes for the certification process and our PCBA contractor hasn’t started to manufacture the PCBs for the pilot run yet. I sent them notice just at the last minute. If I didn’t, we would have lost a lot of money due to this issue.

All things considered, even despite the PCB redesign, we’re getting very close. Pilot run notification emails will be sent out soon, followed by 50 UHKs, and followed by the rest of the 1,950 UHKs of batch 1. We cannot wait to finally ship!

Thank you for reading this update! As always, we’ll be keeping you updated on a monthly basis via our blog and newsletter.

Talk to you on 2017-08-17!

2017 Jun 15

Tweaking the molds and preparing for the pilot run

By |2018-10-21T19:28:58+00:002017-06-15 20:37|agent, design, electronics, features, manufacturing, modules, news, prototype, tech talk|19 Comments

Hi there, and welcome to our monthly status update!

TL;DR: The BOM is fully finalized and ordered. The UHK prototypes have improved a ton in the EMC department. Agent and the firmware has evolved a lot. The key cluster and trackball modules have been mechanically prototyped and tested. New developers joined our forces. We've tested the molds and found some issues which will introduce some delay. We plan to ship a pilot run of 50 UHKs in July. The rest of the UHKs are planned to be shipped starting from August. Please read on!

You can always check out the expected delivery date and update your shipping address on your Crowd Supply account page.

EMC improvements

We've been visiting the EMC lab of TÜV since our first successful test. The reason is twofold. First, we wanted to improve on the results, and second, there were some further tests to be done.

The testing results that we shared with you the last time already passed, but the safety margin was only 2 dbμV/m, instead of the recommended 5 dbμV/m. Our worry was that the margin was so thin that it was possible for the final test to fail. We really wanted to avoid any potential failure, so we have been tweaking various resistor and capacitor values, and have been trying various bridge cables and USB cables to make the margin wider.

You know what made a drastic difference? The USB cable. As soon as we tried a USB cable with a ferrite choke on the keyboard end, the EMC graph changed very substantially. Don't worry, this ferrite choke is only 24 mm x 14 mm in size, and it's very light so it doesn't weigh down the cable.

The updated EMC graph

According to this graph, we went from a 2 dbμV/m safety margin to about 18 dbμV/m! (See the vertical distance between the blue mark around 100M and the red line.) Given these results, we'd be extremely surprised not to pass the final test.

We've also conducted some further tests that we haven't done before. First, we put the prototype into the test chamber and tried to disturb it with focused radiation. We were watching it with a camera to see whether the LEDs go out, and checked it after the test. The prototype didn't break a sweat and kept functioning perfectly.

In the second test, the USB cable was put into a metal cage, and got a healthy dose of radiation. The criteria for this test is that the device can go out of service, but ultimately, it must recover by the end of the test.

The first time this test was executed, the LEDs on the left keyboard half went out and it didn't recover. After that, I made the firmware much more robust, and as a result, the left keyboard half was able to recover like a champ.

Speaking of LEDs, we got so many inquiries about backlighting that it justified its own post, so here you are: Everything about UHK backlighting.

Things are looking so good in the EMC department that I fully finalized and ordered the BOM for the PCBs of 2,000 UHKs, and if everything goes well the UHK will be certified very soon, possibly in June.

Agent progress

A lot has been happening to Agent, our configuration application recently. Józsi is still involved in the development of Agent, but he told me that going forward, he cannot guarantee a fixed number of working hours per month because his life got a lot busier. This made me search for the right candidates, and I'm happy to report that I found two excellent developers.

Róbert Kiss is busy with some of the most pressing Agent issues. Agent has an initial OS-specific privilege escalation step that allows it to access the USB interface of the UHK. Robi implemented the missing Windows-specific part of the privilege escalation step. He's also set up a build process, so that now Travis generates releases for Linux and Macintosh, and AppVeyor generates releases for Windows, and these files get uploaded to the releases section of GitHub. He's also mostly finished the auto-update mechanism of Agent.

Attila Csányi will be busy with a number of important but less time consuming issues given his limited time. He's already made the macro layout more responsive and made the currently selected key highlight and animate very nicely. These seemingly small issues add up big time when it comes to user experience.

Luckily, Józsi is still involved with the development of Agent. Lately, among other things, he's implemented ISO/ANSI layouts. Agent used to display only the ANSI layout but this change will allow it to show the correct layout, be it ISO or ANSI as soon as you plug in your UHK.

Firmware progress

Substantial progress has been made with the firmware recently. The easier part was making the communication between the halves more robust. First up, I added a CRC16-CCITT checksum to the messages between the keyboard halves to improve message integrity. Next up, I implemented a recovery mechanism for LED drivers so that the LEDs also recover when disconnecting/reconnecting the halves. I also made the communication packets between the halves more efficient and smaller.

The harder part is upgrading the firmware of the left keyboard half and modules via USB. You see, it's fairly easy to upgrade the firmware of the right keyboard half because it's directly connected to the host computer. The modules and left keyboard half however are not directly connected via USB. They're connected via an I2C bus to the right keyboard half.

The plan is to implement a proxy mode for the right keyboard half, so that it can route the firmware from the USB host to the left keyboard half and to the modules via I2C. Luckily, such a protocol translator is already implemented so we can use it. It's called BusPal, and it's part of the KBOOT (Kinetis bootloader) package. Unfortunately, it's not nearly as mature as KBOOT, and it was obvious that integrating it to the UHK firmware won't be a walk in the park. I was searching for a proficient developer to make this happen but despite my best shot, I couldn't find a right candidate, so I had to try to integrate BusPal myself.

There were three variants of BusPal within the KBOOT package but I noticed that only one supported USB, so I picked it. In the beginning, I couldn't even build it because it was developed using the the proprietary IAR embedded workbench, not with the free Kinetis Development Studio that is based on Eclipse and GCC. I simply started by putting BusPal into a subdirectory of our firmware repo and trying to make it work. It was an uphill battle at first because BusPal has a huge codebase of which we need very little functionality. Just making the compiler happy has taken days, and after that it was even more work to make it functional. Luckily, over the course of about two weeks, BusPal enumerated over USB and could talk to the left keyboard half. Well, mostly.

Now, I can send protocol commands to the left keyboard half via BusPal but they don't work every time. As it turns out, the ROM bootloader of the KL03, the processor of the left keyboard half is buggy as documented by errata ID 8060, and these bugs have to be worked around. I can erase the processor and query properties, but the firmware upgrade command breaks. Given my myriad of responsibilities, I'd much rather delegate this last step, and it seems that I might have just found the ultimate developer. More about him later.

The state of modules

Up until this point, not too much has been said about the progress of the modules. That's because our primary focus is getting the UHK to market, so András only works on the modules when he has some free time.

At last, I'm happy to show you the first version of the 3D printed modules:

These prototypes were printed using a white, powder-like material, but the final modules will be offered in black color.

Originally, we created two versions of the modules, one of them being totally flat, the other one being angled.

Flat key cluster module on the left, angled key cluster module on the right

We've been experimenting with a front and a top mini trackball on the key cluster module, but concluded that the top one is much more usable, so we'll ditch the front-sided mini trackball.

Angled trackball module on the left, flat trackball module on the right

The trackball module from the inside without the PCB

The reason we've made two versions is to test them and see which version is more ergonomic. The flat modules made our thumbs stretch significantly less, so we're confident that they're a better choice. This is also very fortunate from a manufacturing standpoint as the space inside of the modules is very limited, and even more so in their angled versions, so the flat versions will be easier to design and manufacture.

We also found that it's not a good idea to use two buttons per module because the inner button which is closer to the UHK usually gets pressed when pressing the case button of the UHK. Our plan is to only feature a single button per module, the outer button that is farther from the case button of the UHK.

This is a big step forward, but there's still a lot to do in the future. These plastic cases don't contain PCBs yet, so they will have to be designed. Luckily, the left keyboard half is an module from an electrical, firmware, and protocol standpoint, so we will be able to reuse its schematic and firmware. These plastic cases of the modules are only made for mechanical testing purposes and need to be redesigned here and there because they are not manufacturable, and lack structural support.

Molding plastic parts

I'm a software developer by trade, so I have little knowledge about injection molding. A couple days earlier however, I was fortunate enough to observe the process up close in an injection molding facility where we tested our molds.

The mold of the top right case

As so many things, injection molding looks deceptively simple. Plastic flows into a mold, and the perfect plastic part falls out of the machine. Just like on this video:

In practice, lot of things can make a plastic part less than perfect, such as warping, which is the major issue we have mostly fixed.

You see, warping is a very common phenomenon, and it's usually so slight it doesn't matter. In our case however, it does. As it turns out, of all the keyboards ever created, the UHK is probably the most sensitive to warping. This is because when the plastic cases of the two keyboard halves are merged, it becomes extremely pronounced.

When the UHK is merged and the halves warp even slightly, a very slight V shape can be noticed. This shape raises the four outer legs while the four inner legs firmly touch the ground which is obviously unacceptable.

Surface finish issues, such as sink marks and surface defects are another category of injection molding issues we have to deal with which we have also mostly fixed.

One way to fix the above issues is to tweak various mold and injection parameters which we were actively pursuing quite successfully during our three-day stay at the factory. It's mind-boggling how many parameters can be tweaked, such as the injection speed, pressure, after-pressure, mold temperature, the duration of the molding process, and many more. To make things even more complicated, these parameters are not single numeric values but rather graphs, and multiple points of the graph can be set along the time axis!

The other way to fix these issues is to modify the molds themselves. This is usually more time consuming and involves machining the molds in various ways. Some of our issues can only be solved this way.

We have a rough schedule in place regarding the plastic parts:

  1. Within days, the injection-molded cases will be scanned with a 3D laser scanner to reveal the inaccuracies for the molds to be fixed.
  2. In the next week, the left and right bottom molds will be fixed according to the above results.
  3. Another week later, we'll mass-produce the bottom parts for the pilot run.
  4. Within a month, we'll get all the molds fixed, fine-tune technological parameters, and manufacture every plastic part for the pilot run.

As for the big picture schedule:

  1. In July, we’ll manufacture a pilot run of 50 UHKs and send them out to our pilot testers, which include the various developers, contributors, and backers who have helped us along the way and indicated a willingness to help us rigorously test the UHKs before the main production run and work out any final kinks should they arise. All 50 pilot run units have been assigned, but if any of our pilot testers drops out and we need to fill a spot, we'll solicit volunteers. We haven’t talked about the pilot run yet, but we think it’s critical for the first UHKs to be tested before we actually start the main production run.
  2. In August, we'll launch the mass production of the remaining 1,950 UHKs. The goods will flow out continuously and be shipped approximately in the order they were purchased. Since we are using fulfillment centers in both Hungary and the US, there will be some variation in when your order is shipped, depending on your shipping address, but, basically, the sooner you ordered your UHK, the sooner you'll receive it.

Thank you for reading this update! As you can see, we have to deal with the molding issues which do introduce some delay, but at the same time, we're also making rapid progress. We're asking for your patience and support during these last miles. We'll make sure the UHK will be worth the wait.

As always, we'll be keeping you updated on a weekly basis on social media, and on a monthly basis in this blog and our newsletter.

Talk to you on 2017-07-13!