You know the drill: a new month always brings a new status update. Let’s delve into what’s happened lately!
Our mold making suppliers 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!
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 great 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.
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.
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.
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.