features

2019 Aug 13

Module PCBs are ready

By |2019-08-13T20:40:32+00:002019-08-13 20:40|design, electronics, features, modules, news, prototype, tech talk|4 Comments

Hi there, and welcome to our monthly status update!

István, our PCB designer, has been on steroids, and he finished the PCBs for every module! The boards are being fabricated right now, and are expected to arrive in a week – at which point I'll assemble them.

We already showed an inside look of the key cluster module in an earlier post, so this time, I'd like to showcase the right-side modules. I'll feature three images per module: the assembled version, the half-assembled version, and the latest PCB which is being fabricated.

Please note that the following modules are only prototypes. Their color is not representative, and neither is their surface quality, which will be way smoother once the modules get injection-molded. The color of the PCBs will also differ, as we'll use black soldermask for the final boards.

Trackball

The trackball only has a single PCB. It utilizes the ADNS-3530 optical sensor, which happens to be the most compact optical sensor according to my knowledge. The retaining ring can be removed by rotating it counter-clockwise, so one can easily clean the ball.

Trackpoint

The trackpoint is composed of two boards. The top board is provided by our supplier and contains the actual trackpoint module. The bottom board is designed by us, and its purpose is to do protocol translation between the PS/2 protocol of the trackball PCB and the I2C module protocol of the UHK.

Touchpad

The touchpad module is composed of two boards. The bottom board is a trivial one which simply routes the pogo pin header to an FFC connector, supplying power and data to the top board. The top board does the actual sensing using the Azoteq IQS572 touchpad sensor IC. The top side of the touchpad will be covered by black film.

When I said that that the boards are ready, what I really meant is that these boards should be fully functional. Their design is not set in stone yet, but we expect only very minor changes going forward. Even our mechanical design is fairly advanced and should contain the mechanical features needed for injection-molding.

As I previously mentioned, we don't have a solid ETA on the modules yet. As you can see, we're making rapid progress, and we'll get there, but we surely won't rush them, as we want to get them right.

Your feedback

You guys keep sending your awesome tweets, and we're always eager to read and feature them! If you got your UHK, please share your love!

We'll be keeping you updated on all things UHK, and are looking forward to talking to you on 2019-09-10.

2019 Jul 17

How to use macros on the UHK?

By |2019-07-17T23:29:24+00:002019-07-17 23:28|agent, features, howto|1 Comment

Once in a while, we get emails asking how to use macros on the UHK, so let's see how.

First up, the macro has to be created. You can see some default macros under the Macro section of the sidebar. You can add new macros with the plus button.

Second, you have to assign the macro. You can assign a macro to any key of any layer of any keymap. Let's say you want to assign the "Go to UHK site in browser" macro to the Q key of the Fn layer of the "QWERTY for PC" keymap. This way, the macro can be triggered via Fn+Q.

To assign the macro, simply go to the target keymap, choose the target layer, and click on the target key. Then the key action popover will appear. Click on the Macro tab, choose the desired macro, click on the "Remap key" button, and finally click on the "Save to keyboard" button that appears in the bottom right corner.

You've made it! Happy macroing!

2019 Jun 16

UHK mounting layout

By |2019-06-16T22:52:18+00:002019-06-16 22:47|features, howto|0 Comments

Some of you asked how to mount your UHK to your armchair, so let us provide a drawing of the back of the UHK. The drawing displays the 8 bronze inserts that allow for mounting.

Click on the image for its higher resolution version, or download the drawing in PDF or DXF format.

2019 Jun 06

Mapping a virtual numpad on the UHK

By |2019-06-06T21:29:45+00:002019-06-06 21:26|agent, features, howto|0 Comments

People ask from time to time whether we provide a numeric keypad. The answer is no, but one can create a virtual numpad very easily in Agent, the configurator application of the UHK.

See the following screenshot. The numpad is mapped to the Fn layer, and its keys are laid out in a familiar fashion.

The big advantage of a virtual numpad is that one doesn't have to reach out all the way to the other side of the keyboard. This results in increased productivity, and the mouse is much closer, too. That is, if you even use a mouse after mastering the UHK mouse layer.

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.

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!

2017 May 27

Everything about UHK backlighting

By |2018-10-23T16:48:51+00:002017-05-27 14:03|features, news, prototype, tech talk|42 Comments

We get a lot of inquiries on a regular basis, and it's blindingly obvious (pun clearly intended) that most of you are most interested about backlighting. In this post, I'm about to write everything you ever need to know about UHK backlighting.

First off, let me make it clear that currently we don't offer a backlit UHK version. The reason is that right now, we're solely focused on delivering the (non-backlit) UHKs, palm rests, and modules to our awesome backers. Everything else will follow afterwards.

On the bright side of things (pun clearly intended again), you'll be able to transform your non-backlit UHK to a backlit UHK by soldering LEDs to the circuit boards, and optionally replacing keycaps. Let's take a look at the following pictures:

Backlit UHK prototypes in daylight

Backlit UHK prototypes in daylight

Backlit UHK prototypes at night

Backlit UHK prototypes at night

In the above pictures, the top UHK features opaque keycaps and the bottom has backlight friendly keycaps. Please note that these pictures are a bit misleading because in real life the brightness of the opaque keycaps is much dimmer than of the backlit keycaps. It's also worth noting that the final backlighting will be better. We'll optimize the placement of symbols for more even light distribution and carefully choose the best LED. The most important takeaway is that opaque keycaps may suit some, but probably aren't a great choice for most.

In order to make your UHK backlit right away, you can purchase a number of LEDs and solder them to the PCBs. You will have to use 3mm (T-1) LEDs. Be careful to choose a LED type whose rim is not larger than the lens itself, otherwise the LEDs won't fit into the keyswitches. Also make sure to use single color LEDs as bicolor LEDs won't work well. You can pick any LED color but LEDs of the same forward voltage should be used, otherwise ghosting may occur. Fear not, we'll provide detailed instructions for soldering.

Alternatively, you can wait for our backlight upgrade kit that we'll release later. The backlight upgrade kit will contain white LEDs and a backlight friendly keycap set. In the beginning, we'll only provide US ANSI and ISO versions.

As for the release dates, we're really not sure yet. We'll probably release the backlit UHK version and the backlight upgrade kit about a year after delivering the first batch. We're also unsure about the price but it will be reasonable compared to the price of the UHK.

It's worth mentioning that although backlighting is a nice feature, the labels of non-backlit keycaps are easier to see in daylight.

Multiple brightness settings will be provided. One is a global brightness setting of 100 levels that affects every LED including both the LED display and the LEDs beneath the keycaps. The other is a per-key brightness setting of 256 levels which will enable us to do all kinds of fancy animations. This per-LED brightness setting can also be applied to the LED display as a whole. The formula is: actual brightness level = global brightness * per-LED brightness.

We plan to implement RGB backlighting eventually but surely not anytime soon, as it will require a complete redesign of the PCBs.

We also got a question about whether it's possible to solder only a couple of LEDs, for example only the LEDs of the home row. While it is possible, it will likely cause ghosting issues when using different per-key brightness values. This problem can be solved by telling the LED drivers which LEDs are actually present. We can implement a related user interface in Agent to mark individual LEDs populated/unpopulated, but we will only do so if there will be enough interest for this seemingly special use case.

Lastly, I'd like to note that while backlighting is clearly a neat feature, it's not necessarily better than not having backlighting. In broad daylight, the letters of the opaque keycaps are easier to see than the labels of the backlit keycaps. This is also true when the backlighting is off and simply backlit-friendly keycaps are used due to their material.

So this is it! Hopefully, all your questions are answered now. If not, please ask away in the comments. Have a beautiful weekend!

2016 Aug 18

Updated delivery schedule and a bonus

By |2018-10-21T19:24:00+00:002016-08-18 15:57|demo, design, electronics, features, manufacturing, modules, prototype, tech talk|22 Comments

Another month has passed, and so it's time for our monthly status update! This one will contain a bad bit of news, a good bit of news, and lots of news bites on our progress.

Updated delivery schedule

Over the last few months, a lot of you have been giving positive feedback on our progress and appreciated the detailed updates. According to our Crowd Supply campaign page, the goods are expected to ship at the end of September.

We're trying our best to deliver on time, busting our ass day by day, usually even on weekends, and still, it's quite apparent that we can't meet this deadline even if we bend over backwards. So the delivery schedule needs to be revised:

  • The keyboard and palm rest are expected to deliver by the end of December
  • The modules are expected to deliver in April 2017

Please let us explain the reasons.

Our April delay that was caused by our previous bank (which we abandoned forever) has definitely contributed to this one, as it caused a lot of overhead, and we could only pay to our mold making contractor in a delayed manner.

Another reason is design delays. We have just finished the design of the feet and the palm rest. Getting the design right has definitely taken longer than expected and now the molds of the feet are about to be made. As a rule of thumb, we rather take the time to get the design right than to rush things and end up with a mediocre product.

We have to focus on the core keyboard first and implement the modules afterwards. So the mold of the modules will be created right after the mold of the keyboard. We will pay the extra shipping fees because of the separate shipment of the modules. That's the least we can do.

We're running things in parallel as aggressively as we can to hit our updated schedule. For example, a mold of our special keycaps just got ready in Taiwan, the mold of the case and the cutting tool is being created in Serbia, and our contractor for the LED display has just started to work on their mold.

We're very sorry for this delay. We understand that you can't wait to put the UHK under your hands and waiting sucks. We're asking for your patience and to remedy the situation a bit we'd like to offer something, which is an…

Anodized aluminium palm rest

There are plenty of ways to make a palm rest and we have considered various designs over time. One of the candidates involved a beautiful anodized base plate milled from solid aluminium.

Of course they come in pairs. This is the left one.

Of course they come in pairs. This is the left one.

It was clear from the get go that it won't be cheap and we were thinking about making it available as a premium product later. But now, it's our golden opportunity to make up for the delay of the project schedule. So I'm here to announce that we will provide this anodized aluminium palm rest to those who purchase the palm rest pledge before keyboard shipment! The price for the aluminum palm rest will go up afterwards.

Now that we wrapped up the bad and the good news let's move on to the rest.

Tented UHK prototyped

Since our latest update we got the feet 3D printed, screwed it onto the back of a prototype and shoot a picture of it.

Tented UHK prototype

Everything feels right about the feet and we're satisfied with the overall design. The palm rest is yet to be fabricated. We'll make sure to show it to you as soon as it gets ready.

The state of the mold

The molds of the bottom cases are complete. This is the left one.

The molds of the bottom cases

The remaining molds are also in the works, and in our true style, we'll be posting more pictures as they get made.

Injection molded UHK keycaps

The UHK features two keycap types that are non-standard. One is a concave-shaped, 1.75U, row 4 keycap used by the Mod and Space keys, and the other is convex-shaped, 1.5U, row 1 keycap used by the backspace key.

I'm happy to let you know that recently, our keycap supplier got the molds ready for these keycaps and sent us a couple of samples:

Injection molded Mod and Backspace keycaps, take 1

Injection molded Mod and Backspace keycaps, take 2

These custom keycaps are impeccable and totally consistent with the rest, just as expected. They put a smile on our faces because custom parts like these are major milestones for the project.

The state of the modules

Not much has been said about the modules recently, so it's time to share some information on them. We've actually made a couple of videos of them in action, so that you can get an idea how the modules feel and behave.

Please note that the plastic case and electronics of the modules are not ready yet. So far, the key components have been chosen so we show you the guts of the modules directly connected to the PC.

If you are curious about the exact ICs that we use inside of the UHK, or in the modules then you're welcome to delve into our datasheets repository.

As for the number of buttons of the right-handed modules we're not exactly sure yet but we're aiming for two buttons per module.

Let's see what we have!

Trackball module

The trackball module features an ADNS-3530 optical sensor which is remarkably tiny and communicates over SPI. This demo board translates SPI to USB but we'll use a KL03P24M48SF0 microcontroller to translate SPI to I2C which is spoken by the UHK.

Trackpoint module

The trackpoint module features a sensor of an unknown part number (our supplier signed an NDA with the manufacturer so we don't know) but it's remarkably similar to the now defunct SK8702 trackpoint module which features the SK7102 controller. Our supplier only provided an incomplete datasheet to us, which is not a major problem because the module speaks PS/2.

We'll use the FlexIO capability of the KL03P24M48SF0 microcontroller to implement a protocol translator which will translate from PS/2 to the I2C protocol of the UHK.

Touchpad module

This is an Azoteq ProxSense TPS43 touchpad driven by the Azoteq IQS572 capacitive controller. The touchpad is connected via the Azoteq CT 210 configuration tool to the PC.

Being an I2C device, the controller will directly connect to the UHK. We'll have to design a custom-sized touchpad, however, featuring the IQS572. Luckily, Azoteq provided a design guide for that.

It's not a coincidence that I mentioned the name of Azoteq a fair number of times above. Back in the day I blogged that we're looking for a suitable part, then they contacted to us and provided the most awesome support ever!

Key cluster module

The key cluster module features a couple of keys and buttons which are simple to scan by the microcontroller. The tiny trackball is a Blackberry trackball which uses hall effect sensor along the 4 axis. We haven't yet hooked up the Blackberry trackball to control the mouse pointer but you can find plenty of videos on YouTube of its various applications. I recommend watching Sparkfun's video of their trackballer breakout board which explains it in detail.

Introducing our firmware developer

A while ago, we reached out to you looking for a firmware developer. We've gotten quite a few excellent applications and please let me take the opportunity to thank every one of the applicants for contacting us.

Without further ado, let me introduce you our firmware developer, Santiago González Fabián from the sunny city of Madrid.

Santiago González Fabián

My name is Santiago González and I've been playing with electronics and computers since I can remember, but I discovered the amazing world of embedded systems in the Electronics Engineering Bachelor where I felt in love with 8051 and ASM code.
I've programmed 8 bit and 32 bit MCUs in C and Assembly mainly, and my focus the last 4 years has been the Cortex M world, working at Freescale and NXP as Field Application Engineer trying to solve all kind of issues with Embedded Systems all over Spain, from Automotive to Industrial equipments, from 8 Kb Flash devices toggling LEDs to 2 MB Cortex M7 doing Ethernet, Motor Control and RTOS scheduling at the same time.

Embedded systems are my job and my hobby (Although I also climb mountains in the weekend) so in my free time I look for new challenges in several places (Stack Exchange, HackADay, Electronic Forums…) and that's how I met László and UHK, in my weekly check of NXP Community. After having a look into the project and the open source philosophy behind it, I decided I would love to help if possible. Now the UHK PCBs have arrived to Spain, so I can begin the Bootloaders development :). I cannot wait to start coding!

The new prototype sitting on Santiago's desk

The new prototype sitting on Santiago's desk

Since first getting in touch with Santiago, I've exchanged almost a hundred emails with him about deep technical stuff. It's apparent to me that he's highly knowledgeable, a truly excellent communicator, and his enthusiasm clearly shows. We couldn't ever wish for more than that.

The bootloaders of the UHK are a lot more complex than those of regular keyboards (not that most keyboards have a single bootloader to begin with). This is because our design is highly modular, composed of separate keyboard halves and modules, each running separate firmware images. So naturally, we want to enable you to upgrade the firmware of every module over USB with a click of a button.

The idea is that the right keyboard half will run the master bootloader that will directly upgrade the application firmware from the PC. The left keyboard half and the modules will run the slave bootloader which will connect over I2C to the master bootloader, which will in turn relay the firmware image from the host computer over USB.

KBOOT 2 already supports the above scenario, but a fair amount of customization has to be done by somebody who really knows what he's doing.

Apart from implementing the bootloaders, Santiago will be working on parts of the firmware that require deep knowledge of the Kinetis platform, like the FlexIO based PS2 to I2C protocol translator of the trackball, and such.

Still reading? Then pat yourself on the back because you deserve it! Talk to you on 2016-09-15.

2016 Jul 14

The feet and palm rest design is nearly complete

By |2018-10-21T19:22:02+00:002016-07-14 16:12|agent, design, electronics, features, manufacturing, tech talk|29 Comments

Howdy all! It's time for our regular monthly progress report. Let's get right to it!

Feet and palm rest design

András has been busy designing the feet and palm rest of the UHK. The current design is close to final, so we're excited to show it off.

But first, please fasten your seatbelts. The UHK is highly modular and configurable in nature and the feet and palm rest are no exceptions. There are a lot of combinations of feet configuration so let's dive in!

The design

There are 4 feet mounting positions per keyboard half located in the corners of the halves:

feet mounting positions without palm rest

When using the palm rest, the number of feet mounting positions (4) is unchanged, but their location spreads across a larger area because the bottom 2 feet per keyboard half are mounted to the palm rest:

feet mounting positions with palm rest

A foot can be mounted with 3 screws and can be rotated in 90 degree increments:

foot-degree-animation-640

In any of the 8 positions, a feet can be unmounted (no elevation), mounted and closed (slight elevation), or mounted and opened (large elevation):

foot mounting animation

The bottom of the feet are rubberized, even sideways, and the UHK has its own small rubber feet so the keyboard won't slide in any configuration:

Rubberized foot

The palm rest is fixed to the keyboard with 2 screws per keyboard half, screwed into the stainless steel inserts of the UHK:

palm rest screws

Given the number of combinations, we can't go over every possibility, but we'd like to highlight the most popular ones.

Positive tilting

4 closed feet are used in the top positions of this configuration. The palm rest is not featured on these pictures but you can use it if you want to.

Side view

Side view

Isometric view

Isometric view

Bottom view

Bottom view

Negative tilting

In this configuration, 4 closed feet are used in the top positions and another 4 opened at the bottom positions mounted to the palm rest.

Side view

Side view

Isometric view

Isometric view

Bottom view

Bottom view

Tenting

4 opened feet are used in the inner positions and oriented towards the center of the keyboard.

Side view

Side view

Isometric view

Isometric view

Botttom view

Botttom view

There are so many possibilities that we'll surely end up writing a manual just on this topic. Stay tuned!

Mold and cutting tool progress

It is apparent that our Serbian contractor is hard at work. This is the sheet metal contour cutting and bending tool. It's already functional, but we have to wait for the assembly of the rest of the tooling so that the holes of the MX switches will be cut, too.

sheet-metal-contour-cutting-and-bending-tools

And this is the injection molding tool of the case buttons which is also functional:

injection molding tool of the case buttons

We're happy about the progress of our Serbian contractor and can't wait to see even more hunks of steel.

The 6th generation PCBs are being fabricated

Lately, I've been working on redesigning the schematic and PCBs of our latest prototype. These are the fruits of my labor:

The back side of the right PCB

The back side of the right PCB

The back side of the left PCB

The back side of the left PCB

The improvements are plentiful, featuring:

  • the super powerful MK22FN512VLH12 and MKL03Z8VFK4 MCUs
  • IS31FL3731-SALS2 LED driver ICs per keyboard half allowing for per LED backlighting (we can't provide LEDs and translucent keycaps yet but the ICs will be on board)
  • 2×5 0.05" ARM programming header + Tag-Connect TC2030-NL header + TC2030 header per board for extra developer goodness
  • optionally solderable reed switch per board to reset the MCU without disassembling the case to make it easy to hack the firmware even if jump to bootloader feature gets screwed
  • optionally solderable I2C breakout header for developing modules in a breadboard friendly fashion
  • optionally solderable test LED per board for debugging purposes
  • pogo pins and I2C (versus the previous UART protocol) between the keyboard halves enabling the use of modules mechanically and electronically

A small batch of these boards are being fabricated right now at Eurocircuits and can arrive in any moment. I'm also about to order loads of components real soon which will be soldered onto the boards. These PCBs are supposed to resemble the final production boards very closely, so we'll make sure to give them a fair amount of testing.

If you are one of those people who grok electronics please don't hesitate to check out our electronics GitHub repo and give us feedback about the schematic and boards. We consider every single suggestion as we really want to get the design right.

Progress on Agent

Agent has been heavily refactored lately as we port the legacy jQuery codebase to Angular 2 step by step. This is one of those things that's hard to notice by looking the application but it's very significant regarding the long-term development of Agent.

This brings me to the star of the month. Give it up for Mr Nejc Zdovc from the beautiful town of Celje, Slovenia!

nejc

My name is Nejc Zdovc and I have been programming for the last seven years. I have a Master's degree in Computer Science and Information Technologies. I was drawn to Angular 2 community last year and ever since, I've enjoyed pushing its boundaries. At the beginning of this year, I was having wrist problems and that's why I was looking for a new ergonomic keyboard. I stumbled on the UHK and, with a little research, I found out that this is an awesome project, so I decided to start contributing. For the last few months I have been helping József with Agent.

Nejc has been helping out a ton with the Angular 2 port. Previously, only keymaps were managed by Angular 2, but he made the whole application governed by Angular 2 by componentizing it. He ported the side menu to Angular 2 and wrapped select2 into a component. This is serious progress and requires a lot of dedication. The work is not over yet but his help has been a quantum leap forward.

You know what's crazy? Nejc and Sam don't have a UHK at their hands yet and still, their contribution has been above and beyond expectations. I wouldn't have expected developers contributing substantially before we deliver the hardware, but apparently it's already happening. This is Free and Open Source at its best, folks! I can't even imagine what will happen after delivery. I'd love to see our GitHub repos blown away by contributors!

As a token of our appreciation, Nejc and Sam will get a well-deserved developer unit soon, then eventually a final UHK with all the bells and whistles. It's really the least we can do for them.

We've just arrived to the end of this update. I hope you enjoyed it, and talk to you on 2016-08-18.

2016 Feb 18

2nd UHK post-campaign update: PCB design now supports LEDs and Matias switches

By |2016-11-07T20:51:56+00:002016-02-18 13:58|design, features, news, prototype, tech talk|7 Comments

Time flies! We promised to touch base every month – so let's get right into what we've been working on!

The mechanical design is being sent to manufacturing

András has been having his fair share of CAD-filled days lately, and as a result we're days away from sending the design of the case off to manufacturing. He's made a million little tweaks and a couple of more significant changes.

Foot design – adjustability and portability

The fixation mechanism of the feet is definitely a major one. We brainstormed foot design ideas for a while, and finally found the best option. To keep the UHK as compact as possible, it will feature adjustable (flip open) feet that are entirely removable in addition to the small, flat rubber feet. This way if you decide not to use the adjustable feet, they won't occupy any extra space. And if you do want them, they can be easily installed with 3 screws per foot. Once you do, you're able to flip them open in a moment. The current design allows for positive tiling, negative tilting, and tenting – The best of every world! András has yet to finish the design of the adjustable feet so stay tuned for more news.

8 feet in total, 3 mounting holes around individual rubber feet
8 feet in total, 3 mounting holes around individual rubber feet
Mounting bosses - 3 per foot, as seen from inside the case
Mounting bosses – 3 per foot, as seen from inside the case

PCB design – LEDs and Matias switches

We're also stoked about having added pins for LEDs and Matias switches! We use universal switch footprints that combine the pins of Cherry switches (optionally with fixation pins), Matias switches, and LEDs. We designed the stiffening ribs of the bottom case in a future proof manner by routing them around the hybrid switch footprints to avoid mechanical interference. Please note that we won't be able provide either an LED, or a Matias UHK version for a while, but the opportunity will be there for modders. You can see the pins on the following section view.

Back section view

Physical layout – finalized

Another major change is the finalization of the physical layout. Fear not, you shouldn't even notice the subtleties if you aren't watching very closely. Space and Mod has been split right where the G and H keys meet. This is the best option ergonomically, as it's right between the hands of touch typists. This gave us an opportunity to use more standard keycaps so those of you who want to replace keycaps will be in a better situation. Lo and behold, our final ANSI physical layout:

UHK ANSI layout

And the ISO version:

UHK ISO layout

Funny thing is, poor András has been working day and night to implement this seemingly small change, as it affected the geometry of the CAD model in major ways. He definitely deserves a day off… only to work even harder as we march towards manufacturing!

Speaking of the above, I've created a dedicated layouts and keycaps FAQ page on our site lately, and while being there also spruced up the main FAQ quite a bit to satisfy your endless curiosity.

The state of the ARM port

In our previous update we were looking for a firmware developer to port our existing firmware to NXP's Kinetis platform and develop it further. We've been getting quite a few impressive applications and suggestions.

Say hi to Mr. Jan Rychter, who has been eager to help us, and offer his very valuable advice. Since first contact we've been exchanging emails full of geek talk. And did I mention that he's also a most esteemed backer of the UHK?

Jan got me up to speed in no time. As it turned out, Teensyduino is not the best foundation for a serious firmware application. It's nice for prototyping purposes but NXP's sophisticated Kinetis SDK is a much better platform for this purpose.

Unfortunately, the MK20DX256VLH7 processor that we originally planned to use is not a good choice because KSDK won't ever target it. As crazy as it might seem, there's a more powerful, fully supported, and cheaper alternative on the market: the MK22FN512VLH12.

How powerful and cheap, you ask? Let's compare!

Processor nameATmega32U4MK20DX256VLH7MK22FN512VLH12
Processor coreAVR8ARM Cortex-M4ARM Cortex-M4
Rated speed1672120Mhz
Flash memory32256512kbytes
RAM2.564128kbytes
Price3.64.554.04US Dollars

Mind blown. Twice the power for less price? I'll take that on any day of the week!

Right now, there are a couple FRDM development boards on my table, one of which running our Kinetis firmware port which enumerates as a keyboard + mouse USB device. This is already looking great, and you can expect further major progress shortly, so the port is definitely within reach, and I'm happy taking this direction.

Agent is coming along nicely

Árpi is on a mission to make Agent the most beautiful keyboard configurator application ever crafted. He never ceases to amaze me as he massively cleans up the UI of my original mockup while keeping the original functionality intact. This is the most up-to-date screenshot of Agent:

Agent with final side menu

You're welcome to check out Agent in the browser. Please note that there's only a minimal UX code behind the UI, but it should give you a good idea about the final interface.

Thanks for reading, and talk to you on 2016-03-17!