Aloidia is a staggered, split, fully wireless solar-powered mechanical keyboard with extremely long battery life.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
Adobe Portable Document Format - 626.50 kB - 02/22/2023 at 13:35
Adobe Portable Document Format - 637.23 kB - 02/22/2023 at 13:35
I haven't had the time to work on this project recently, but I wanted to share the magnetic interlocking feature of the keyboard. It was quite the challenge to place the magnets with the very small clearance between the bottom of the board and the PCB. After a few redesigns of the case, it seems to work fine. You can see a video of it here
Currently, the memory displays can give information about connection status as well as battery level. I've chosen an icon as the battery level but it is also possible to have the percentage displayed. A very slight issue with the current setup is that the LDO powering the display discharges itself very slowly when its enable pin is low (TPS7A0333DBVR). The next iteration will use the P-version of that same LDO (TPS7A0333PDBVR) which has active discharge when disabled.
After playing with the new memory displays and changing some settings, I was able to get to a steady ~65uA of current when idle, and under 30uA when in deep sleep. This is amazingly low and will allow the user to use the keyboard hopefully for multiple years with solar panels before recharging the keyboard. There still needs to be a day-by-day battery log over multiple months to have a real estimation though.
I had written in a previous log that the navigation switch had quite heavy chatter. What's weird is that it only happened for 3 of its 5 positions. I first thought it was mechanical, but ruled it out after measuring with an oscilloscope on a standalone navigation switch.
The second possible cause was crosstalk between the lines. This was quite unlikely as the affected lines weren't that close to each other.
The third cause could be bad contacts in either the 6PDT switch or the JST connector. I first thought it was the switch because bypassing it and connecting the navigation switch directly to the switch matrix eliminated chatter. The issue with this "solution" is that it was impossible to switch out to the horizontal encoder without desoldering.
Wait a second... The horizontal encoder... Well, that was the cause of everything: both the navigation switch and the horizontal encoder were using the same interface board (presented in the first log). This interface board has capacitors between the A/C and B/C lines of the rotary encoder for very crude hardware debouncing. The thing is, when the navigation switch was selected, the capacitors were then between the UP, DOWN and CENTER lines, which meant that activating one charged the capacitor, inducing a voltage spike in the other lines.
The solution is then very simple, which is to not populate the capacitors when soldering the navigation switch on the interface board.
You can see below the 2 capacitors that are used when the horizontal encoder is soldered.
They should be removed when soldering the navigation switch
The second iteration is working quite well. You can see below a typing test done with Boba U4 silent tactiles:
(35) Aloidia keyboard typing test - YouTube
At the time of writing this log, I'm still waiting for new memory displays.
After testing the second iteration of the board, there are a few issues that should be improved on for the third iteration:
I've also mentioned it before, but I also plan on developing a development kit for the nRF52840, with different hardware components to maximize power efficiency. The parameters that could be tested are:
Currently, the three solar panels can provide up to 50uA under artificial light, and from 150-1000 uA under sunlight depending on if it is directly or indirectly exposed. The power consumption of one of the halves is 140 uA on average when idle, and down to 25uA in deep sleep. When turned off, current leakage is around 3-7 uA. Current is measured with the nRF PPK2.
While I still need to properly measure the average power daily consumption, a simple estimation can be made. The keyboard uses around 1000-1500uAh per day, and the solar panels can provide 600-1200uAh per day depending on the lighting conditions. In the best case scenario, the battery should be able to maintain its voltage at all times. In the worst case scenario, it will consume around 900uAh per day. With a 500mAh battery, it should last 555 days, or around a year and a half on a single charge.
One important factor to keep the power consumption down is the choice of rotary encoders. One must make sure that they are closed on every detent, which ensures that no current will be wasted in possible internal pullups. In practice, I found the EN11 and ACZ11 series of rotary encoders to do the job. The ACZ11 has fairly weak detents, which makes it prone to be stuck between two detents, increasing the power consumption. This is why I've chosen to go with the EN11 encoders. I chose the ones with a threaded bushing, which allows me to thread in a cover cap for a cleaner look.
In a future iteration, the following could be optimized for reduced consumption:
It could be interesting to design an evaluation board with multiple different ICs to test their performance. But that's a project for another time.
The keyboard works wonderfully over bluetooth. However, how can I decrease its power consumption even more? The answer is simple, and has been used with many products before, such as logitech keyboards: dongles.
With standard bluetooth, one of the halves of the keyboard acts as a central, whereas the other one acts as a peripheral. The peripheral is mostly asleep and only wakes up when an interrupt is triggered by a keypress. The central, however, has to listen to the peripheral to be ready when it sends its keypresses. It can then relay the information to the computer. The disadvantage of such a system is that the peripheral will last much longer than the central, as it is asleep most of the time. A solution, however, is to program a dongle as a central, and have both halves act as peripherals. This provides many advantages:
- As both halves are peripherals, they are both asleep most of the time, which increases the battery life by almost an order of magnitude
- The dongle, being plugged into the computer, acts as a USB keyboard. This means that the keyboard can still be used on computers where bluetooth is not available, or in certain situations where bluetooth cannot be used (e.g. in BIOS)
First, to test the firmware, I used the left half of the first iteration as a dongle:
It's however not a very compact solution...
In the end, I chose to go with the nRF52840 MDK USB Dongle by Makerdiary. What is great about this dongle is that it has an exposed reset button, as well as broken out SWD pads.
The integrated UF2 bootloader can only be accessed by pressing the reset button while inserting the board. Not very practical, if you ask me. Moreover, it is not compatible with the UF2 file generated when compiling the ZMK firmware, probably because of different partitions (softdevice, flash, ...). To solve both of these issues, I simply built and compiled the Adafruit nRF52 UF2 bootloader for the MDK nRF52840 dongle. It can then be flashed to the dongle with a J-Link after unlocking it with nRF Command Line Tools. I've also observed that the bootloader needed to be compiled with softdevice for it to work correctly.
Designing the case is probably the hardest part of this project. There are a lot of parts: PCBs, plates, solar panels, displays, tenting feet, ... which need to fit in a fairly small form factor, while keeping a nice and clean look. Some of the parts were so close to each other that a clearance of 0.2mm was sometimes needed.
The whole case can be 3D printed. Some interesting numbers:
- 10 PCBs
- 60 M3 screws/heat inserts
- 20 M2 screws
- 10 spacers
- more than 20 unique 3D printed parts.
In total around 150 parts need to be assembled (without counting the switches).
Hotswap encoders/navigation switches
One of the unique features of this keyboard is to give the user the choice to optionally use a navigation switch (right) or a horizontal encoder. Both are 3-parts assemblies which were quite complex to design given the small footprint that it takes on the board, and the precise fit that is required to fit inside of the mx switch footprint.
Printing the palm rests is quite tricky, as they need to be printed vertically to have good surface finish with no layer lines on the top. As they are quite thin and tall, this results in z-wobble at higher layers even after sanding. This issue is even more exacerbated because it is printed on a bed slinger type of printer (MK3S+). A core XY would likely result in less wobble as the part stays static while printing.
A solution is to add manually generated supports and large brims:
Surely, one of the most interesting features of the board are its memory displays. They are very low power, have high refresh rate and boast a fairly high resolution. But they are fragile. And I mean VERY fragile.
I ordered four memory displays from aliexpress, as they are the only ones from which you can order with a MOQ < 1600. Out of the four, three were defective...
Here you can see the sole working memory display. Zephyr provides a driver for this display, but it sadly doesn't support rotation (which is crucial in my case because of how the displays are placed on the halves). I had to manually modify the driver to support flipping the display 180 degrees. Currently, I've modified the zephyr driver directly, which is not ideal as you wouldn't be able to compile locally without having the modified RTOS. Eventually, I will move the driver from Zephyr to a custom driver defined in the ZMK repo, or wait for Zephyr 3.0, which should support LVGL rotation.
Edit: I've now moved it to its own driver. You can check the implementation in my ZMK fork.
Right now, the display has its EXTCOMIN and EXTMODE pins low, which is not ideal. This is because sharp memory displays require the VCOM signal to be toggled periodically to prevent DC bias thus reducing lifetime of the display. In the Zephyr implementation, this is done by toggling the EXTCOMIN pin while EXTMODE is high. As can be seen below, the current implementation works but it will probably be reviewed in a future iteration. Fortunately, as the memory uses 3-wire SPI, and because I made it compatible with the e-paper display which uses 6 pins, there are 3 free pins which could be used to control both the EXTMODE and EXTCOMIN signals.
It was working, but...
I didn't realize how fragile the FFC cable was... I'll be ordering new ones soon...
The second iteration of the board aims to correct all of the mistakes that were spotted when testing the first iteration:
For this iteration, I used ENIG finish, which provides excellent planarity.
As I mentioned in an older log, the e-paper display was quite noisy when exposed to direct light (and even worse with sunlight, which, for a solar-powered board, is obviously not ideal). I then chose to design a breakout for the LS011b7dh03 from Sharp Devices. This breakout is mechanically compatible with the previously designed e-paper display, with an almost identical footprint.
Assembling the boards
Aloidia rev2 PCB assembly - YouTube
Left half fresh out of the oven
After soldering the THT components:
The two halves assembled:
Create an account to leave a comment. Already have an account? Log In.
What You think about this layout? https://klawiatura.wordpress.com/
I d love more detials regarding the project, ESd protection,it is indeed very helpful.thanks
I’d love more details on the built in tenting / magnet locations.
Visually this reminds me of the nullbits snap.
I really like all the ESD protection, over/under current, wireless, etc. But I also have some suggestions. I think it will be good if it can connect to multiple devices (Win, Mac, Android, Iphone, etc) then you can switch connection to whichever devices, and also the n-key rollover, lastly probably the latency. From what I experience NuPhy air 75 used to have some keys that doesn't register if I type little bit faster. So maybe 1000 hz polling rate and good connection will be really good. Just my suggestions. Even without the features that I mentioned above, your boards is already really good. Split, Wireless, solar charging, just wow.
How do the 2 keyboards talk to each other? Do they auto connect to each other through bluetooth? Is there a parent/child relationship?
There are 2 options, with one of them being more efficient:
1. One of the halves acts as the "central". It handles all communication to the computer via bluetooth or USB. It constantly listens to the peripheral via BLE, and retransmits the data back to the computer. The disadvantage of this method is that the central has battery lifetime which is much lower than the peripheral.
2. The two halves are peripherals, and the central is a dongle connected to the computer. In that case, both halves have the same lifetime and communicate with the central via BLE. The halves are asleep or idle most of the time, which increases the battery life by a lot. Moreover, as the dongle is constantly connected to the computer, it acts as a USB keyboard so it's possible to type in places where bluetooth is disabled, e.g. in BIOS. This is the method that was chosen in this project, but the keyboard is compatible with both.
And yes, in both cases the peripherals auto-connect to the central.
Very nice project, it would be nice to see a detachable numpad on this too.
Thanks! A magnetically detachable numpad could be a really nice addition, definitely something to consider!
Very cool series, a course teaching how to make the keyboard, I have a notion of electronics, but I've never done anything practical, it would be really cool
to develop and learn electronics could be a paid course - firstname.lastname@example.org
Where did you buy the horizontal encoder???
It's the EVQWGD001, you can find it on AliExpress
Become a member to follow this project and never miss any updates
Oh myyy, this is a beautiful keyboard. Told myself I was semi-done with this hobby (more-so just focus on customising my already bought keebs and not joining anymore GBs), but if this becomes a group buy....I'm 100% in. Awesome work! Wish I was knowledgeable enough in electronics to create my own keeb this complicated :D