Although we never advertised the UHK mouse layer as a perfect substitute for a mouse, it's surprisingly powerful in the right hands. So much so that apparently it’s possible to create digital art with it. Give it up for Brandon Yu, who’s about to demonstrate the seemingly impossible.
We don’t know about you, but we're officially blown away by Brandon’s skills and talent. Brandon also happens to be a game developer, so feel free to get in touch with him on Twitter.
Want to bring it up a notch? See the module demos.
Hi there, and welcome to our monthly status update!
TL;DR: We’ve released a new Agent version after a long time without changes. We’ve made a functional key cluster module, and made progress with the trackpoint module.
New Agent release
It’s been a whopping ten months since we released the latest Agent version. We’ve actually been working on Agent since the latest release quite consistently, but weren’t able to publish a release due to the lack of a valid Windows Authenticode certificate. Long story short, we finally have a certificate, and recently released new Agent versions.
Feel free to check out the changelog on the GitHub Agent releases page. We’ve mostly fixed and polished a number of issues. A particularly useful feature is a dedicated Mac pointer speed preset which you should try out if the UHK mouse pointer movement feels slow on your Mac.
We’ve also implemented the fanciest UHK feature to this day: Agent shows whether the UHK is split or merged, and displays whether the left half is connected. Obligatory demo follows:
(UHKs are not backlit yet. We'll release a backlight upgrade kit at some point, and future UHK hardware versions will be backlit.)
Admittedly, this feature is pretty useless in itself, but it’ll actually be useful in the future. The same mechanism will be used to show the modules. Imagine connecting your modules, seeing them show up, and be able to configure them with a click of a button. And talking about modules...
Functional key cluster module
After a fair deal of prototyping, the key cluster module actually works. Again, obligatory demo follows:
You probably noticed the little thingie at the bottom of the key cluster module.
As you can see, it’s an FFC cable. Our current FFC cable manufacturer couldn’t make a cable of merely 13 mm length, so we used a much longer off-the-shelf cable for the time being. I actually doubt whether an FFC cable of such short length can be made, but an FPC (flexible printed circuit) can surely be made. But we’ll probably end up using a rigid-flex board as the best solution.
Apart from the above slight change, there’s another issue. I noticed that the responsiveness of the trackball is lacking compared to the previous prototype. The new, smaller hall-effect sensors are probably not sufficiently sensitive to pick up all the magnetic state changes of the mini trackball.
I wired the old mini trackball breakout board to the key cluster trackball board to be able to test it with the key cluster module, and the change in responsiveness was immediately apparent. The right board is super responsive, and the left one skips the beat very often, especially when moving it quickly.
I think we’ll revert to the previous hall-effect sensor, and try to pack them tighter to be able to fit them on the board.
Trackpoint module
We’ve made progress regarding the interconnection of the top and bottom trackpoint boards. There isn’t enough space for an FFC connector on the top trackpoint board which contains the actual trackball sensor, so the cable needs to be directly soldered to it. I designed an FPC for this purpose, and we plan to use hot bar soldering to affix it to the top board.
I used a soldering iron for prototyping purposes. So far, so good!
This module should work well, and I’m excited to write firmware for it, and for the rest of the modules.
UHK unboxing video
ShopzadaPH has made an awesome unboxing video of the UHK which you’re welcome to watch:
Your tweets
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-11-11.
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!
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.
Some of you asked how to mount your UHK to your armchair or custom-made accessories, so let us provide a drawing of the back of the UHK. The drawing features 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.
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.
As a last word, make sure you have Num Lock enabled, otherwise your numpad keys will function according to their bottom function, like Home instead of 7 and such. You can map Num Lock to any key of your UHK.
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!
#GotMyUHK#mechkb now with a nordic layout and added 🦄🌈flavour! Couldn't find an R1 1.5U OEM backspace so will probably 3D print it one day. I never knew keyboards could be this fun! :) Thanks @UltHackKeyboard! 💎 pic.twitter.com/3Y6XKAN9WF
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.
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:
Within days, the injection-molded cases will be scanned with a 3D laser scanner to reveal the inaccuracies for the molds to be fixed.
In the next week, the left and right bottom molds will be fixed according to the above results.
Another week later, we'll mass-produce the bottom parts for the pilot run.
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:
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.
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.
Please note that the UHK 60 v2 has per-key RGB backlighting. This post is about the backlighting of the UHK 60 v1.
We get a lot of inquiries on a regular basis, and it's blindingly obvious (pun clearly intended) that most of you are interested about backlighting. In this post, I'm about to write everything you ever need to know about UHK 60 v1 backlighting.
Luckily, you'll be able to transform your non-backlit UHK 60 v1 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 60 v1 prototypes in daylight
Backlit UHK 60 v1 prototypes at night
In the above pictures, the top UHK 60 v1 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 60 v1 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 60 v1 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 60 v1.
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!
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.
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.
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 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:
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.
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
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.
