tech talk

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 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 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|28 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 Jun 14

Production and module progress

By |2018-10-23T19:59:20+00:002018-06-14 16:58|modules, news, prototype, tech talk|8 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 5, 6, 7, 8, and 9. This is the highest volume we’ve produced so far, but not as high as we ultimately aim for. We’ve fallen behind with pre-assembly due to the aforementioned staffing issues, but we’re catching up, and the ramp up is still underway. The development of the modules is in progress.

First up, let us share a beautiful and very original picture that we love very much. It’s made by Yukio Miyamoto. He is a masterful illustrator who also happens to be an awesome backer of ours.

Your recent feedback

The feedback you keep giving to us continue to be amazing.

The following is an interesting one. Did you know that when armed with a USB OTG cable, you can connect your UHK to your Android phone, and you can probably also control the mouse pointer? (Recent Android kernels tend to support USB mice.)

Lastly, this one made us laugh out loud:

Please keep them coming! We’re excited to hear about y’all.

Module progress

Production does keep us busy, and we can’t yet devote as much time for development as we’d like to, but we’ve made some progress with the modules.

The following is sitting on my desk, and it might just be the weirdest keyboard ever.

But most importantly, this Frankenstein keyboard is a proof of concept! This is 1 UHK right half and 3 left halves interconnected. The top left half simulates a left module, and the top right half (which is a left UHK half) simulates a right module.

The keyboard halves and modules communicate via the main I2C bus of the UHK. The right UHK half is the I2C master which initiates all communication on the bus. The rest of the devices are I2C slaves. From the standpoint of the firmware, there is no difference between the left keyboard half and the modules.

I basically dremeled a protoboard to size, and created a passive 4 port 4P4C hub out of it to interconnect the pieces. Then I added test keymaps for the modules, and reflashed the firmwares of the left module and the right module, so that their I2C addresses don’t clash with the I2C address of the left UHK half.

This proof of concept works as intended, and now I can type on all the 4 keyboard halves, making me seem like I overcompensate for something.

As you can imagine, this is the first step of many to follow. Next up, I will extract the part of the firmware that will be shared across the modules and the left half, and then create separate firmware projects for the modules, utilizing the extracted code.

Then I’ll attach the peripherials specific to the individual modules to these development UHK left halves, and write firmware code to drive them.

In the meantime, András will finalize the plastic cases and mechanical design of the modules, so that they’ll be optimized for manufacturing. This will, in turn, enable me to design the custom PCBs of the modules.

In a way, developing the modules is like developing additional products – 4 products to be exact, and even though we’ve gained a lot of experience, realistically speaking, there’s no way the modules will be ready by the end of August as originally planned.

Given the above, we’re changing the estimated delivery date of the modules to the end of December which should be more realistic. None of us are happy with delays, but we’d much rather take our time than compromise the quality of the product even the slightest bit. According to your feedback, it’s the right thing to do.

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

2018 Apr 20

Production is up and running

By |2018-10-23T19:55:26+00:002018-04-20 08:35|manufacturing, news, tech talk|31 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: Our factory is up and running! According to the aforementioned delivery page, we’ve already sent out the first mini batch, so some of you should get your orders within days. Given our most recent production data, we’ll be able to deliver batch 1 of 2,000 UHKs and related accessories by the end of July. Many of you will get your orders much faster depending on your place in the queue. Everything’s looking great, and we’ll be transitioning to the modules soon.

Some UHKs of mini batch 1:

Manufacturing progress

Launching mass production wasn’t exactly a smooth ride, which wasn’t really surprising after all. Given our past experience, some things inevitably go wrong despite our best efforts.

We observed that some LED segments displayed gibberish – that is, unidentifiable characters. It was quite a challenge to figure out the root cause of this, but András succeeded. Apparently, the space is very tight around the FFC cable and when the case is on, it bends the cable and some pins don’t connect. The solution? We just have to bend the FFC cables in an M shape prior to assembly.

We also noticed that some pins of some through-hole components, most notably the keyswitches and the 4P4C connectors, weren’t soldered in on some boards. We talked to our PCBA supplier who told us that their selective wave soldering machine had been misbehaving and got serviced recently. They will also use a 3-dimensional automated optical inspection machine from this point forward which should greatly reduce defects. The problematic boards will be reworked.

Then we were faced with a couple of bent plates. We have yet to figure out how these plates could possibly bend, but for the time being, we’ll do heavier QA until the cause is revealed and eliminated.

And lastly, a critical piece of launching manufacturing is our custom developed order fulfillment and manufacturing execution system that I’ve been working full steam on in the last couple months. It felt like building a runway while the plane takes off, but the runway has been built just in time, and now the plane is in the air.

Given the above issues, we started up slowly. According to our most recent measurements based on actual production data, we will be able to ship about two mini batches per week, which equals about 120 UHKs and related accessories. Given this pace, we’ll be able to deliver batch 1 by the end of July, so this is our current delivery target. Of course, many of you will get your orders way faster depending on your place in the queue.

Agent and firmware progress

Starting with the latest firmware, it’s now possible to wake up the host computer with a touch of a key. The LED display also gets disabled when the host sleeps to save power. See the firmware changelog and releases.

Agent got a shiny new desktop icon, it now displays the firmware versions running on the halves of your UHK, and can recover UHKs with broken configurations. See the Agent changelog and releases.

Going forward

The next big milestone is clear: the modules. The modules clearly differentiate the UHK from every other keyboard in the market, and make it the first and so far only modular keyboard ever created.

Personally, I can’t wait to control the pointer in various ways in a finer grained manner without leaving the home row, and I know that a lot of you share our enthusiasm. I’m sure the journey will be just as exciting as getting there, and as always, we’ll make you part of the journey via these updates.

Thank you for reading this update! The next one will be published on 2018-05-17. In the meantime, feel free to keep checking the delivery status page of your much awaited UHKs.

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 Dec 14

Delivering the pilot run units

By |2017-12-14T19:34:03+00:002017-12-14 19:15|manufacturing, news, tech talk|37 Comments

Hi there, and welcome to our monthly status update!

TL;DR: The 50 UHKs of the pilot run and their palm rests have been assembled and will be shipped on Monday. We’ll ramp up production afterwards, and continue the fulfillment of the rest of the crowdfunding starting in January.

Examining the First Samples

Before the pilot run assembly, our contractor assembled four UHK panels, so that we could examine and approve them. We’ve taken a thorough look at them, and I noticed that the 4P4C jacks didn’t seem right. An older version of the jacks was used which we replaced a while ago with another jack. The spiral cable could not be removed from the older jack because its plug was too deep in the jack when the UHK was fully assembled, which is why we changed it in the first place.

Our contractor originally ordered the correct part, but the component distributor quoted an alternative replacement part and didn’t explicitly tell our contractor of the change. It’s pretty hard to spot these replacements in a long component list, hence the wrong part was ordered.

This miscommunication error cost us a couple days to get replacement jacks, but luckily no other issues were found.

PCB Assembly

The next step was SMD assembly which went very smoothly. This is a short video of the process:

As you can imagine, there are a number of steps involved in this process:

  1. The boards go into a solder paste stencil printer machine which applies paste to the pads where the surface-mount components will connect.
  2. The applied solder paste gets inspected by a solder paste inspection (SPI) machine that creates a 3D model of the paste to make sure that it has been correctly applied where needed.
  3. Here come the pick and place machines, which place the tiny surface mount resistors, capacitors, diodes, ICs, and other devices onto the board. All three of our contractor’s pick and place machines were operating simultaneously, which is not really justified for the UHK, but it allows for larger throughput. The machines are usually so fast that their movements can barely be seen by the naked eye, but this time they were operating much slower than usual so that operational tweaks can be made as necessary.
  4. At this point, the boards go through a reflow oven. The oven has multiple zones, each featuring a different temperature according to the specified temperature profile. By the end of this step, the solder paste solidifies, and the components are affixed to the board.
  5. Normally, the boards are inspected by an automatic optical inspection (AOI) machine at this stage, but the process parameters are not fully finalized yet, so a human operator inspected the boards manually.
  6. Finally, the boards are sent to my station where I flashed them on my Raspberry Pi workstation, with a UHK, of course.

The boards not only look beautiful, but they all work perfectly. This is a pretty good start.

We left the boards at our contractor to get the through-hole parts soldered, and some days later they sent us the fully assembled panels.

Mechanical Assembly

Unlike the PCB assembly, the mechanical assembly is a fully manual operation. It involves breaking out the PCBs from the panels, placing the panels into the pre-assembled bottom cases, screwing the metal guides to the plates, assembling the top and bottom cases, and putting the keycaps on the key switches. The result is 50 beautiful pilot run UHKs, ready to be shipped.

Shipping Status

Right now, we’re working on assembling the palm rests, and on Monday the UHKs and palm rests of the pilot run will be shipped. Exciting times!

Being located in Hungary, the first UHKs of the pilot run are expected to arrive in Hungary, then to the rest of the EU, then to the US, then to the rest of the world. We deliver the EU units directly, and the non-EU units via Crowd Supply (based in the US). We can’t change this in any way, or ship directly to everyone due to accounting reasons. Please note that except for the above, we do ship on a first come, first served basis. You will receive a shipping confirmation email with a tracking number from Crowd Supply when you order ships. If you need to change your shipping address, do so now through your Crowd Supply account. For questions on shipping, see The Crowd Supply Guide.

We’re hoping that most, or all of the pilot run UHKs will arrive before the holidays, but being just before the holiday season, we’re not sure.

Starting in January, we’ll scale up production and plan to fulfill the first batch of orders in 1-2 months. Afterwards, the second batch will follow. We’ll be keeping you up-to-date.

Thank you for reading this update! We wish you a Merry Christmas and Happy New Year, and we’ll talk to you on 2018-01-18.

2017 Nov 16

FCC and CE passed, PCBA follows

By |2018-10-23T19:48:07+00:002017-11-16 19:27|manufacturing, news, tech talk|22 Comments

Hi there, and welcome to our monthly status update!

TL;DR: We’ve passed both FCC and CE! We’re assembling the PCBs of the pilot run next week and shiping the first pilot run of 50 UHKs around the end of November. We’ll do our best to start to delivering the rest of the UHKs in December, but we may slip to January due to the holidays.

CE passed

We assumed that CE is a piece of cake after we passed FCC so easily, but as it turned out, it wasn’t a walk in the park at all. First, I got a message from TÜV Netherlands saying that we failed CE. They shot one of the UHK prototypes with an ESD gun at the bronze inserts in the back. A discharge of -6kV made the prototype permanently dysfunctional.

Given that FCC was already done by TÜV Netherlands and TÜV Hungary is entitled to certify CE, I called back both prototypes to Hungary. Upon arrival, I investigated the failed one, and saw that the microcontrollers in each half and the FB7 ferrite bead of the right half were fried. After replacing these parts, the prototype was perfectly functional again.

In order to prepare for the next CE test, András fabricated a couple of rubber caps which I glued to the bronze inserts inside of the plastic case to isolate them from the PCB.

Armed with this fix, we went to TÜV to conduct the next test.

Oddly, not only the sealed inserts passed the test, but the non-sealed inserts, too. We couldn’t reproduce the issue that TÜV Netherlands hit, but we found another one.

When Balázs shot the magnet of the right half with the ESD gun, the prototype failed. The lights went out, and operation could only be restored by power cycling the prototype. Even though it’s not a terminal failure, according to the standard, this is a fail.

We came up with an idea on the spot: insulating tape. We stuck some tape to the ends of the right magnet inside of the case which made the prototype hardly ever fail. This wasn’t a sufficient solution because the magnet had to be better sealed. We figured that epoxy should work really well because it withstands 11 kV/mm, and just as assumed, it did solve the issue indeed.

This is the preliminary CE pass for your viewing pleasure:

And this is the pass section of the official FCC certification:

Ultimately, we’ll modify the molds to seal the magnets with plastic. ABS withstands 20 kV/mm, so it’s an even better insulator than epoxy, and we won’t have to apply drops of epoxy during the assembly process. Until the molds get modified, we’ll apply epoxy to the current cases that we ship to the EU (CE being EU-specific).

Now that we’ve passed both FCC and CE, we’ll launch PCBA very shortly. Our PCBA contractor is eager to start. Surface-mount assembly is scheduled for next Monday, through-hole assembly is scheduled for later in the same week.

Colored cases

We recently visited a company to choose the colors of the non-black cases. Instead of using their stock colors, we ended up asking for custom colors according to the rendered images that you can see on the order page.

I’m happy to report that the first colored UHK cases just rolled off the assembly line.

We can’t wait to see the colored UHKs fully assembled!

Miscellaneous progress bits

The correct back stickers have finally arrived, and we applied them to the back of the cases. Next, the top and bottom cases are (separately) assembled featuring all the bells and whistles.

We recently noticed that the pad printing of the right case buttons is off. The position of the print has been misaligned by 2 mm. New case buttons will be printed this week.

We also noticed that the LED display was hard to see in bright light, so we asked our supplier for some new samples, and they were able to improve upon the design. Now the manufacturing of 3,000 new LED display films is in progress. They’ll likely arrive next week, at which point, we’ll remove the old films from the displays and apply the new ones.

The outer boxes into which the smaller product boxes will be packed for shipping are being manufactured and are scheduled to be ready next week.

I’ve been super busy with the firmware, landing about 150 commits in the firmware repo since our last update, and released a new version. You’re welcome to read the changelog.

Robi has finished the cross-platform build system of Agent and released versions for Linux, Mac, and Windows. The next step will be the the auto update feature, and integrating the firmware upgrade scripts to Agent, so Agent will be able to update the firmwares of the keyboard halves and modules.

As for the estimated delivery schedule, we plan to send out the 50 pilot run UHKs by the end of November. Then we’ll wait about a week or two for the feedback of the pilot run recipients to make sure that everything is up to snuff. Afterwards, we’ll try our best to launch the delivery of the remaining 1950 UHK of batch 1 in December, but due to holiday season we may have to postpone the shipments to January. We’re trying hard to deliver as soon as possible, but we won’t rush things at the expense of quality.

Thank you for reading this update! We’ll talk to you on 2017-12-14.

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 Aug 17

Further steps towards mass production

By |2018-10-23T19:45:43+00:002017-08-17 18:14|electronics, manufacturing, news, prototype, tech talk|23 Comments

Hi there, and welcome to our monthly status update!

TL;DR: We’ve been making good progress towards mass production. The corrected prototype PCBs have been manufactured, tested, and sent to TÜV Netherlands for final certification. The PCBs for the pilot run are being manufactured. The configuration parser of the firmware has been fully implemented. BusPal got fixed, allowing us to update the firmwares of both keyboard halves. We’ll close the order cancellation period for batch 1 in a week.

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

Closing order cancellation for batch 1

Order cancellation for batch 1 will be closed in a week. You’re likely to be in batch 1 if your order was made on or before 2017-07-12. The reason is that we’ve already summarized the orders of batch 1, and we’re assembling these orders according to that plan. It’d cause a lot of potential problems to update the orders in the middle of assembly, and the best solution forward is to disallow order cancellation. You can cancel your order until 2017-08-24 but not afterwards. Thank you for understanding!

Assembling the plates and switches

Our team is working to assemble the 2,000 UHKs of the first batch. Right now, they’re busy with putting switches into the plates. So far, 1,000 pairs of plates have been assembled.

They’ve also half-assembled 150 pair of cases including the magnets, magnet-counter parts, and inserts, and excluding the small rubber feet and the back stickers. It’s a joy to see the fruits of their labor.

Miscellaneous parts

Lately, some simple but necessary parts arrived from our suppliers, such as the USB cables and the bridge cables. What you see are only some of the many boxes.

We’ve also finished with the metal guides. There are 16,000 of them.

1,300 flip-out feet have been molded.

These are a some of the 5,000 case buttons manufactured so far.

2,000 pairs of vertical PCBs have been fabricated. These will mate with the modules, or with each other when the UHK halves are merged.

Palm rests

Finally, the palm rests for the pilot run are now ready.

Adding a pair of these palm rests to my prototype truly elevated the overall look and comfort level. It was like putting on the crown jewel.

Please note that backlit UHKs are not available yet. See our Everything about UHK backlighting post.

Electronics progress

Luckily, the bypass capacitor related fix that I outlined in our previous update solved the I2C communication issue, even though my initial fix didn’t.

When I soldered the through-hole capacitors to the previous version of our PCB it seemed like a success, but it wasn’t. I realized that communication was still unstable. Then I started emailing back and forth with Eben Qiu, field application engineer of ISSI, and he persuaded me that this must be the issue.

Eben sent me an application note titled AN-035-EN Layout Guidelines for IS31FL3731-SASL2 and a further Layout guideline document tailored to the UHK. Based on his advices, I slightly but carefully redesigned the board around the LED driver ICs. The main thing is that the bypass caps must be put as close to the GND and VCC pins of the ICs as possible. GND and VCC traces must be as thick as possible.

Redesigned PCBs featuring bypass caps close to the LED driver ICs

I’m happy to report that the new layout has made I2C communication rock solid, but it’s still possible that it’ll hang every now and then, so we’ll combat this issue in two other ways.

First, I’ve made sure that the state of the LEDs is cached by the master MCU and it only sends updates to the LED drivers when the LED values actually change. By minimizing the amount of communication, we also give minimal chance to the LED drivers to screw I2C.

Second, we’ll make the I2C driver much more robust, so that it’ll be able to recover immediately from errors. Only this solution will result in true robustness.

Having the chance to give the board more attention, I also improved the acoustic noise of the UHK. The noise level was already better than it used to be a while ago, but a subtle high-pitched noise could be heard in a very silent environment. Fortunately, Eben also shared another application note with me titled AN-012-EN Reduce acoustic noise of IS31FL3236 EVB.

I ended up using tantalum electrolytic capacitors instead of ceramic capacitors, which outperformed my wildest expectations in the acoustic noise department. The newest boards are so silent that I cannot hear a damn thing, even when putting my ear as close to the keyboard as possible. And that’s when every LED is driven with full power, which would generate the most noise.

Next up, we went to TÜV Hungary to conduct final measurements at their lab. We finished in the record-breaking time of an hour for both of our prototypes, with the best results so far, and then left the prototypes there. They will send them to TÜV Netherlands for final FCC and CE certification. We should have those papers soon.

Finally, I sent the gerbers to our PCBA contractor, and they started fabricating the boards of the pilot run.

Firmware progress

We’ve already had a fair number of talented contributors, and it looks like we keep attracting some of the best talent, and this time truly one of the best in the world.

The name of our most recent contributor is Erich Styger and his name is familiar to everybody who has ever worked with Kinetis microcontrollers. That’s because if you search for a Kinetis related issue, you’ll bump into one of his blog posts as the first result which usually also contains the solution to your problem.

Erich started out as a compiler engineer, then accumulated more than 20 years of experience as an embedded systems engineer, and now he works as a professor at the Lucerne University of Applied Sciences and Arts, and works with the ETH Zürich, and also for NXP. His MCU on Eclipse blog is the go-to place for everything Kinetis, and many consider him the world’s most knowledgeable professional in this space.

As you can imagine, Erich is very busy, but over a fair number of emails I’ve managed to persuade him that the UHK is the best thing since sliced bread, and given the development capabilities and open nature of our keyboard, he became quite interested in it. So much so that he allowed me to send him a prototype, then he sent us his fair share of contributions.

Every one if his contributions is a definite step forward, but the one I consider the most valuable is his BusPal fix, as it finally enables the right side firmware to route the firmware to the left keyboard, allowing us to upgrade the firmware of both keyboard halves, and coincidentally the firmwares of the modules, too! He’s also written a relevant blog post on his blog.

Mad props and a pilot run UHK with a palm rest goes to Erich. I feel fortunate, thrilled, and honored beyond words to have him contribute.

Meanwhile, Eric (not Erich), our intern has been hard at work and finished fully implementing the configuration parser. He also started implementing the macro engine. Unfortunately, his internship period is over, so the macro engine is not ready yet, but he was making great progress which I’m very happy about. Thanks so much for your hard work, attention to details, and diligence, Eric!

With the configuration parser in place, the UHK is able to switch across keymaps which was the last major remaining parser related issue. The macro engine will not entirely be ready by the time of the pilot run, but we’ll be gradually shaping it, and it should be ready in the not so distant future.

In the meantime, I implemented an async I2C EEPROM driver, so now the firmware is able to transfer the configuration to and from the EEPROM, enabling the UHK to persist the configuration.

Estimated delivery and standing issues

These are the major standing issues that affect the delivery of the pilot run:

  • Top case parts: We’ve already molded numerous cases, but we’re still working on improving the surface quality of the top parts. The molds should be ready in 1-2 weeks at which point we’ll manufacture 150 pairs of them.
  • Packaging and back stickers: We’ve been working a lot on the design of the packaging of the UHK and the palm rest and we believe they’ll be very fancy. We’ve ordered 3,000 UHK boxes and 1,500 palm rest boxes which may take 3-4 weeks to be manufactured but hopefully we’ll be able to get some of them earlier for the pilot run.
  • PCBs: The PCBs are being manufactured and are expected to be ready in August. Then our PCBA contract manufacturer will assemble 50 of them for the pilot run.
  • FCC and CE certification: We don’t have a solid ETA about this, but chances are good that this will be done by the end of August.

The bottom line is that we’re doing absolutely everything we can to deliver the pilot run by the end of August.

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-09-14!