You know the drill: a new month always brings a new status update. Let’s delve into what’s happened lately!
Tooling status
Our mold making contractor has been working on the top molds of the UHK case and are on schedule. Here are the molds of the top case parts:
At this pace, the end is near. We should be able to test the final plastic parts within weeks!
LED display
In our previous update, we showed you the mold for the LED display. Since then, our supplier baked a complete unit featuring the PCB, the LEDs, and the epoxy inside. The result is a blindingly bright LED display!
The display is so bright that it’s rather overkill at night. Luckily, the LED driver ICs that we use allow us to precisely set the brightness level - which we will expose as a user option eventually.
And this is how it looks when scrolling the alphabet on it:
Actually, it looks better in real life, but not when recorded with a mobile phone under suboptimal lighting conditions.
Some problems still have to be resolved, though. The forward voltage of the white LEDs are considerably higher than of the red/yellow LEDs which results in an unbalanced charlieplexed LED matrix that has a tendency of ghosting which is noticeable, especially when only the white LEDs are on:
There are several ways of fixing this issue, so if everything goes well we’ll simply throw a couple of diodes at the LED matrix and make our supplier redesign the PCB of the display. We really try to keep the white LEDs, but in the worst case scenario, we’ll use LEDs of a different color instead, whose forward voltage matches that of the red/yellow LEDs.
Another issue to be resolved is acoustic noise. The LED driver ICs generate a high frequency noise that is slightly disturbing. This is due to the capacitors and inductors, which shrink and expand according to the PWM signal that drives the LEDs. There are about a half dozen ways to deal with this issue. Some of them increase costs, others increase complexity. We may end up combining multiple approaches to get the best result.
Firmware
Lots of things have been happening in firmware land lately. The FRDM dev boards that feature the processors we use have already been working for a while, but the firmware wasn’t tailored to our PCBs.
First up, I tried to set up the multipurpose clock generator of the K22 MCU which made me realize how much of a hideous beast it is. It would have likely taken me weeks to make it work, so instead, I summoned Santiago who set it up like it was a walk in a park.
Then I went on to implement the key matrix scanner, made the left keyboard half send key states to the right keyboard half, implemented a rudimentary USB communication protocol, exposed the EEPROM and LEDs via USB, and made all the peripherals work.
Not being a battle-hardened firmware developer, it’s always the low-level MCU programming that gives me the biggest headache. Now that these parts are in place, we can finally focus on implementing the high level architecture, protocols, features, and cleaning up the codebase.
The only major low level feature left is the bootloader, on which Santiago is working, and he should finish in November. In the meantime, we can simply use hardware USB programmers to program the firmware via the ARM SWD ports of the UHK.
Currently, the firmware is able to exercise the full breadth of hardware features, proving that our current generation PCBs work as expected. Next up, I’ll send a couple of assembled PCBs to our developers and contributors, so that they can make Agent communicate with the UHK via USB, and develop the firmware further.
Agent
Jozsi and Nejc have been working hard on Agent.
Nejc implemented a data layer that persists the state of Agent into local storage. That’s right folks, from this point on, all of your keymaps and macros will be automatically saved. Mad props to Nejc for his hard work!
Jozsi implemented the rendering of mouse actions, updated to the latest (and now stable) Angular and TypeScript, and removed loads of legacy code.
I’ve written a couple of scripts in the usb branch of the Agent repo to demonstrate USB communication by reading and writing the EEPROM and LED driver ICs of the UHK. My half-baked code will eventually be refactored and integrated into Agent.
Graz meetup
Usually, Santiago is located in Madrid, but nowadays he lives in Graz, helping a major customer of NXP. Living near us, he recommended that we should meet, and we have gladly taken the opportunity. I also asked Nejc whether he wants to join - to which he said yes. And so, the four of us could finally meet in person.
There was no shortage of interesting conversation and fun times. Apart from a fair amount of geek talk, we ended up showing our apparent lack of pool skills.
And that wraps up this update! Looking forward to talking to you again on 2016-11-18.
So it seems that it's down to the electronics and software. What is the status of the PCB's? Did you already got some samples and tested it?
Now comes the final version of the PCB, indeed. We'll have to reduce the amount of acoustic noise which might call for minor tweaks to the PCB. I'm also about to make a couple of DFM-related improvements to the PCB, and it should be good to go. We're less worried about the software. The hardware is the the more time consuming part of the project.
Like I always say: WOOOHOOOOO!
Thanks for rooting for us, Wezzy!
Hi, since I am planning to purchase this month, will my order be also delivered with the same batch on December 2016? My location is Japan. Thanks!
Hi Joel, Your order will be delivered at the same time as the rest of the orders, so no extra delay will be introduced. Thank you for considering to support us!
Regarding the LED driver noise please keep in mind that some people (me included) are quite sensitive to high frequencies so simply pushing the noise just outside of the human hearing range is sometimes not enough.
Thanks for the idea, Schwert! I'm also one of those noise-sensitive people, and we'll make sure to not only rely on our hearing, but actually measure the frequency and make sure it's well outside human hearing range. We'll also actually silence it as much as possible.
Glad to hear you're taking this more seriously than some big companies *cough* logitech *cough*
Just out of curiousity, which Logitech product is affected?
http://jdc.koitsu.org/logitech/ and in my case a 70€ performance MX
Thanks for the link - this has been terribly educational! It's quite crazy to see that even industry heavyweights make mistakes like this. We'll do our best to reduce, or rather eliminate the noise as much as possible.
Most offices in my field prevent USB devices from working unless it's a standard mouse or a standard keyboard. I want to be sure I can plug my keyboard at work without any surprises.
In your crowdfunding video, you stated that the UHK can be configured on a computer with Agent installed, then unplugged and used on another computer without installing drivers. Therefore that satisfies my requirement.
However, in the FAQ, there is mention of an "adaptive mode to auto-switch keymaps according to the current application". How is this achieved? How does the keyboard become aware of what's the foreground application?
Hi G.Y.,
Adaptive mode is an exception to the rule, indeed. The way it will be implemented is that Agent will watch the foreground application and instruct the UHK to switch keymaps accordingly. Apart from adaptive mode, however, everything will work without installing special drivers, just as you stated.