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.
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.
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
— Wavi (@Riichrd) September 12, 2018
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
Talk to you on 2017-07-13!
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:
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!
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.
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!
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.
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.
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!
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.
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!
There are 4 feet mounting positions per keyboard half located in the corners of the halves:
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:
A foot can be mounted with 3 screws and can be rotated in 90 degree increments:
In any of the 8 positions, a feet can be unmounted (no elevation), mounted and closed (slight elevation), or mounted and opened (large elevation):
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:
The palm rest is fixed to the keyboard with 2 screws per keyboard half, screwed into the stainless steel inserts of the UHK:
Given the number of combinations, we can't go over every possibility, but we'd like to highlight the most popular ones.
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.
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.
4 opened feet are used in the inner positions and oriented towards the center of the keyboard.
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.
And this is the injection molding tool of the case buttons which is also functional:
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 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!
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.
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.
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.
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:
And the ISO version:
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!
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 core||AVR8||ARM Cortex-M4||ARM Cortex-M4|
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:
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!
We're looking for a firmware developer. Please read for more and get in touch with us!
A month ago in our previous newsletter we promised to send you an update on the post-campaign happenings on January 14th, so here it is! There is a lot of ground to cover, so fasten your seatbelts and we'll get right to it!
Extra keyboard cases & keycap sets are for sale
Some of you contacted us to purchase extra keycap sets and cases, and we've been very much willing to serve your needs, so why not offer them as extra perks? You're welcome to purchase them on our campaign page.
Meet Agent, the configuration application for the UHK
We're proud to show you the first screenshot of Agent, our cross-platform configuration application. It's being developed by Árpi, a new developer of ours. Please keep reading for more.
The mechanical design is being finalized
András is hard at work finalizing the mechanical design of the keyboard case. Mold making is by far the most time consuming task of the manufacturing process, so it's supremely important we start as quickly as possible in order to deliver on time.
We've already struck a deal with the manufacturing firm for the injection molding tool for the plastic case and the cutting tool for the steel plates, and we're in the process of discussing relevant design issues with them. Sourcing of the raw material for the steel guides is also in progress – from a well-esteemed Austrian company.
From the very beginning, we've been mindful to design the UHK for manufacturing, but there are some details yet to be finalized. One such detail is the connection between the two halves and the modules.
Originally, we used a battery connector because it was easier to use an off-the-shelf part – but later we figured out a much better way: dedicated pogo pins. This is a more robust and better looking solution than the battery connector. The 6P4C connector was also replaced by a 4P4C connector and its wiring has been reversed. This way a standard telephone cable can be used to interconnect the two keyboard halves.
There are a couple of details like the above, and András is rapidly moving forward to address them, so that we can submit the CAD files to manufacturing as soon as possible.
Two developers have joined to our ranks
Back in August we were contacted by Árpád Csányi, who expressed interest in the UHK. Fast-forward to November, and we managed to meet in person over a couple of beers after I gave a talk on the UHK in Szeged, Hungary. It was apparent that he was interested in the project, but I wouldn't have thought in my wildest dreams that he'd end up being the front-end developer of Agent, our configuration application! Árpi is not only a powerhouse of UI/UX ideas, but he's very much willing and able to implement them.
After I created some mockups of Agent he quickly followed up to present his ideas and improvements. He then started to write HTML and CSS to make the mockups go alive! We're making rapid progress and are aiming to freeze the UI/UX specification of Agent by the end of January.
Please note that these mockups are a work in progress but you're welcome to add your suggestions to the docs. Don't forget to uncheck the View -> Print layout option in Google Docs or else some pictures will be cropped.
Right after open-sourcing our design a, mysterious GitHub user started contributing to our electronics repo. Say hi to Mr. Spencer Owen, who is very much into devops and using his rad skills, he set up a visual diff mechanism in our electronics repo, so that now we can actually see the changes of the circuit boards that get modified by contributors. This is very much needed because unlike plaintext files, circuit boards can't be diffed in the traditional way.
Right now Spencer is working on making the PCB compatible with Matias switches. Due to the lack of compatible keycaps, this doesn't mean that we'll be able to provide Matias switches from the get go, but we're trying to future-proof the PCB so that the opportunity will be there, and eventually we can make it happen.
Moving to ARM, and looking for a firmware developer
It's been a pleasure and privilege to work with Árpi and Spencer and I'm very much looking forward to further expand our team. It may surprise you, but we're not actually primarily looking for an AVR developer. We're looking for an ARM Cortex-M4 developer! Why's that? Let's consider the following table:
|Processor core||AVR8||ARM Cortex-M4|
The above numbers are pretty telling. The ARM processor costs only a buck more than the AVR but it's about 10 times more powerful! The plan is to replace the AVR on the right keyboard half with ARM, and keep using AVRs in the left keyboard half and in the modules – which don't need as many resources as the right half.
We could possibly stick to the ATmega32U4 and implement the planned feature set, but the available 2.5 RAM is very tight. It'd require us to always think about how to not exceed memory and vastly optimize the firmware for memory consumption. This would slow down development and wouldn't give us room to implement more sophisticated features later on. Bulkier AVRs are moderately more powerful and considerably more expensive, so I truly believe that ARM is the way forward.
It's also very important to note that the MK20DX256VLH7 is not just another ARM microcontroller, but the brain of the Teensy 3.1 and 3.2 development boards. This is great news because there's a huge amount of support available out there!
Are you familiar with the Teensy 3 platform, or do you know somebody who is? Do you enjoy the thrill of Open Source? Would you love to work on a one-of-a-kind mechanical keyboard, and help push innovation further? If so, we'd love to have you on our team! Please read for more and get in touch with us!
We're making rapid progress on multiple fronts, but there's still a lot to do! We plan to finalize the UI/UX specification of Agent by the end of January. I'm sure that we'll have a lot to talk about in our upcoming updates.
Thanks for reading, and talk to you soon – on February 18th!
Great news, everybody! We've just reached, then surpassed $230,000, so the 1st Stretch Goal is now funded!
Here is the result of the color poll. Given the level of interest, we decided to offer the top 4 options, and black for purchase versus the originally promised 3 options. Colors galore!
We'll ask you about your preferred color after the campaign.
2nd Stretch Goal: Free UHK Toolkit
We've been thinking for a while of offering something that is very dear to our heart: a toolkit. The UHK is designed to be hacked, and so this toolkit is perfectly aligned with our philosophy, enabling you to tear down your beloved keyboard in no time. We will give a FREE toolkit to everybody who pledged towards the keyboard once we hit $250,000. So let's make it happen!
Special deals are running out
Just 30 hours to go, and this is your last chance to save $50 and get the UHK at Special Early Bird pricing of just $200!
If you don't have enough funds right now, You can get a $50 coupon and with this coupon you will be able to order the UHK anytime after release at the same Early Bird price of just $200!