When we decided to make our keyboards wireless, we envisioned a seamless experience that would leave no feature out: Bluetooth that pairs with up to 5 devices, low-latency RF, possibility of using the keyboard wired, switching between those 3 modes as quick as a flash, connect seamlessly every single time with no hiccups.
Well, well... that has been more challenging than we expected 😅 And now we're here to tell you what's happening, why it's happening and how we are working to fix it.
Real issues?
Just on a side note, the Defy keyboard works perfectly fine for most people in most scenarios.For example, when we went to Pycon Italy, we put our keyboards to the test and were constantly switching between modes and multiple BT devices that were quite far away, and our experience was flawless.
But we know that some of you suffer from these connectivity bugs, which make the experience less satisfying.
These "bugs" mostly fall under three categories:
- Not really bugs, but confusing UX design
- Hardware malfunctions disguised as bugs
- Real firmware bugs
UX issue
The keyboard can be used in Bluetooth (BT) mode even when it's wired, allowing connections to other devices while connected to a desktop. This creates a bit of issues:
- Turning the computer on might unintentionally switch the keyboard to BT mode if it receives power from the computer faster than the data- then it starts blinking. If you press the top left key it switches back to wired mode.
- Potential confusion arises as the keyboard can work wirelessly with the toggle at the back switched off.That toggle controls the battery rather than the connection mode.Powering the keyboard externally allows for BT or RF connectivity regardless of switch position.
Consideration has been given to simplifying options to just BT or RF and possibly using a physical button for switching modes to avoid automatic switching confusion. This could have been done from the beggining but our goal was to create that simeless experience. We can not add that physical switch, but we can add a digital one that will be configurable via Bazecor.
Hardware malfunctions
We've also had a small percentage of PCBs (under 1%) malfunction in a way that looks like a firmware bug due to a small trace that can get damaged during manufacturing and causes intermittent failures.
In some cases, one side of the keyboard randomly disconnects, or the battery reading of that side doesn't show on Bazecor. And then it works again. To fix this, we are constantly improving our quality control in the PCBa factories. We also redesigned the PCBs to prevent damage—batch 2 already has this fix—and, of course, we replace any damaged PCBs for all the customers experiencing this issue.
Pure firmware issues
For example, on some Windows computers, if you're using wired or RF, you need to replug the neuron when the computer wakes from sleep. This happens because sometimes the keyboard gets "confussed" and mixes communications. This can be fixed by working on the communications, making sure that the code base is more robust and specifically ensuring that the sides of the keyboard and the neuron are all ready to receive information before sending the data.
Also, switching between BT devices doesn't work if you have Superkeys in your number row; this is a Superkeys bug (which have been in beta for sometime now). When you pair to a new device, the first time we need to type a code, and there you need the numbers. If you have already paired the keeb to a device this won't happen. You know; in this case the Superkeys are not very "super".
And, the last one: it has to do on the flashing of the firmware into the Defy. Your configuration might get "deleted" when updating the firmware (what really happens is that your layers are not reloaded). We have a backup system in place, so restoring it requires no more than two clicks, but ngl; it's quite scary if you don't know that. The solution will be that, of course, Bazecore was able to reload the layers itself but, a quicker solution is adding a pop up that says "hey, no worries, your layers seems to be gone but you just need to reload them, buddy". We are working on it 😉
Why is it still like that?
Yes, we know that you are all thinking: "But, Dygmates, if the keyboard has been out for over half a year now; why haven't we fixed these firmware bugs yet?
Well, there are a few reasons. The first one is that we are doing things that have never been done, which is difficult.
- There's no other split mechanical keyboard that works via BT, RF and wired, so there was no firmware we could just use.
- QMK is only wired, and ZMK wireless keyboards only work via BT.
- Plus, we love how intuitive and easy-to-use our configurator software is: you can make changes easily and save them to your keyboard at the press of a button. So we had to pave the way, and the road has been bumpy.
- Of course; there are sometimes that we don't find a bug until we have shipped hundreds of keyboards; there are the customers who make us aware of them.
The second reason is that, with so many connectivity options, there are far more corner cases and uses that we couldn't even fathom until thousands of you started using the keyboard.
- When a bug shows up in one of those corner cases, it takes time to replicate and fix it.
The last one is that we're still a small company 💖, which forces us to relocate resources to other projects.
In the past few months, the firmware team has had to focus on adapting the firmware to the Raise 2 so it can pass the certification tests and we can manufacture the PCBs. Some resources have been dedicated to making sure our firmware was released correctly under the open-source license. The team has been working on fixing the issues for over a month now. We have to bear in mind that the firmware team not only develop features and fix bugs but, actually, develop the firmware that needs to be used during manufacturing, like the one for the jig tests we explained in our last video.
The Plan
The good news is that these new foundations we are working on will already solve many of the issues and improve the keyboard's overall reliability; it's just going to take a bit of time. And, what is it that we are exactly working on, then?
- Making the flashing procedure super robust to avoid problems on the reload of the layers
- Reworking the SPI communication with the neuron, so the neuron and the sides communicate properly
- Seamless device switching
- Power efficiency. We are looking for ways to make the chips take "micro naps" when not in use
We have prepared a roadmap of our work in firmware and software which you can check it out here: dygma.com/roadmap. We want to keep you guys informed about what we are working on at any given time and the next issues we'll tackle.
Of course, we also want to thank you for your patience and understanding with all the issues mentioned.
It's in our DNA to be innovative and try to do things that have never been done, like our tenting solution, this 3-way connectivity on a split keyboard, or even being the first keyboard with RBGW LEDs. But some of those innovations have bitten us in the derriere.
We could settle and stop trying to find the limits of what's possible, but that wouldn't be any fun. Instead, we'll keep working relentlessly to offer you the seamless wireless experience we envisioned.
Thank you, dearest Dygmates 💖 it's amazing to see that we can always count on you, guys. Don't forget to check the video if you want to hear what Luis, our CEO, has to say about all this 😉
And, as always, if you have any questions, feel free to ask us on Reddit or Discord. See ya!!
