I have a question about my UHK 80’s behavior when using USB connection while having previously paired it via Bluetooth.
Current Setup:
UHK 80 with both halves connected together and also using the spiral cable
USB cable connected to the right half and my Windows 10 PC
Keyboard was previously paired via Bluetooth to this PC
Issue:
I’m noticing some strange behavior in the Windows Bluetooth panel. The “UHK 80 right half” keeps disappearing and reappearing in the Bluetooth devices list. When this happens, there’s a brief period where I cannot type at all. Also, the “UHK 80” device’s state is constantly change between “Paired” and “Connected”. Here is a 1 minute video to show the issue.
Questions:
Is this behavior normal when using USB while the keyboard is also Bluetooth-paired?
Should I remove/disconnect the keyboard from the Bluetooth panel when using USB?
Is it better to stick to either USB or Bluetooth exclusively?
Any insights from other UHK users would be greatly appreciated. Thanks in advance!
Is it better to stick to either USB or Bluetooth exclusively?
To either usb, or the bluetooth dongle.
Supporting HID over ble is complicated (as its device-dependent as well as OS-dependent) and brings little benefit, so it is on the bottom of our priority list these days :-(.
As for weird things happening, you might be seeing the ble NUS advertisement (which is used for the dongle connection, as well as for left-right communication), although the keyboard should not be willing to pair that one.
No, I don’t have a UHK dongle. I don’t know how “UHK 80 right half” appeared in the device list. I use the keyboard with both halves connected via the spiral cable.
I’ve encountered several issues recently:
Key issues:
Yesterday: “d” key would repeat multiple times from a single press
Today: “e” key had the same repetition problem
“o” key produces “O” instead
I removed the spiral cable while keeping halves connected, and it seems to work again
Configuration problems:
About 3 days ago, Agent showed an alert that configuration was broken and prompted restoration from backup
After restoring, all key bindings and macros were intact
However, the device name on the small display showed “… Backup”
Couldn’t rename the device
After computer reboot, the device name corrected itself
I’m currently using firmware 12.3.2. I’m not sure if these are firmware bugs or related to the configuration restoration issue.
Not exactly. Hunting down every last BLE HID problem yes, and especially problems that require my attention yes.
But BLE HID should be working, and if it is not, it is most likely a task for Benedek, whose availability isn’t super high, but is independent of mine, so if the behavior is reproducible and sufficiently documented, chances are it gets sorted out in a reasonable time.
Thinking about it, I should correct the above statement to “it is on the bottom of my priority list”.
@Richard If you find a way to reveal the “UHK 80 right half” BLE device, please let us know the steps, as it’s essential to reproduce the issue. I tried and couldn’t reveal it.
As a customer spending $700 dollars for a keyboard, and VERY high on my list of reasons for doing so was to have a keyboard that uses bluetooth to switch between several machines effortlessly without a bunch of dongles.
Get multiple seamless BLE HID connections setup and debugged quickly after a new customer opens the box should be VERY HIGH on the priority list.
From a user experience point of view, it’s the only thing disrupting an amazing product experience on the UHK80. Everything else is good enough. The BLE support is bad. There literally isn’t a button I can press on any layer of the keyboard to put the keyboard into and out of pairing mode out of the box. I’m configuring macros to do this. Why?
As a dev, I’d like to understand a bit more about what makes this difficult in the firmware (I’m not experienced in firmware but I have an interest in the problem).
As for enabling/disabling pairing – if BLE HID pairing has a firmware limitation and is basically only possible with one device at a time, then it should be made extremely easy to destroy the current connection and add a new one.
So basically I’d like to have macros on my keyboard on fn2 or something where I can manually say “okay, drop your current BLE HID connection… Okay, now advertise…” and set this connection – preferably even while the device is connected to the machine being paired with by wired USB.
I would disagree that it brings little benefit. It’s literally the 1 thing separating this product from being a knock-down, drag-out success.
It sounds like it’s just a bigger problem then it seemed and first.
It would be totally worth it to solve all those cases to deliver multiple connection BLE HID across devices and OS’s.
The fact that the dongle exists does and works across slightly more devices is not a good reason to de-prioritize this glaring product flaw. The dongle is a bad solution because:
phones/ipads/tablets
it’s USB A and modern macbooks and others are usb C only
USB C to A adapters are gross
there’s many reasons to have multiple machines and buying 10 bluetooth dongles when all those machines have bluetooth is silly
It would feel wonderful to have all the devices in my workspace simply mapped to their own BT connections and be able to seamless switch between them.
Here is a list of problems. Some more relevant, some less:
We have other serious problems. In my eyes, getting uhk work flawlessly over bridge cable, usb, and dongles, without crashing and freezing is higher priority because it benefits all users since the hardware and firmware is the same for everyone. Unlike ble hid which very much depends on quirks of third party devices and their possibly wide variety of behaviors.
Dongles bring benefits over ble hid - they (will) allow surpassing the inherent ble hid throughput limitations. (Once I find time to implement related features.)
I am not a ble expert. Benedek has deeper knowledge, but is scarcely available. We don’t have a dedicated ble expert.
Partly a problem is also c2usb’s integration - Benedek’s custom hid implementation - that hooks directly into zephyr’s drivers. Unless I want to dive deep into his code (which is again problematic from the perspective of efficiency, if I can do it at all), my options are limited, although admittedly not exhausted.
Partly I am reluctant to deal with it simply because dealing with ble is pain. Documentation is scarce. Zephyr APIs change frequently. Number of scenarios to deal with as well as their branching factor is pretty darn high. As a result every code change can easily break something else, and, even if successful, it benefits only a small number of scenarios.
I admit that partly it is also just my distrust in BLE HID, and prior experience with ble devices, as I have never owned a single general purpose bluetooth device (general purpose in the sense that it would act as a peripheral for a third party central) that would work without severe issues, especially a one that would actually manage to implement seamless multidevice support.
Understood. And makes sense. Also, super cool how fast you all respond here.
I already see what is meant by OS Specific quirks. I got both of these macbooks added as BLE HID connections.
The problem with switching seems to be the aggressive reconnection strategy MacOS has with HID devices. Sending a disconnect signal to the to the device gets the UHK to stop trying to communicate with the host, but you actually have to turn off the bluetooth radio quickly before it tries to reconnect to the UHK.
It’s almost like the UHK could benefit from a macro to… deny incoming connections from the device it was JUST connected to… in order to give it time to switch over to to the target device.
I’ve been getting a more experienced with the series of weird steps required to switch hosts with BLE HID. And I’m now wondering how straightforward or how difficult it would be to turn this into a set of actions which could be implemented as macros.
Workflow:
Trigger disconnection from current BT connection from the keyboard (instead of from the OS bluetooth menu)
Hold off that connection from reconnecting for a few minutes (Mac OS aggressively tries to reconnect HID devices)
Switch to next host (already implemented)
Reboot the keyboard (a macro to do what the reset button does, this may already exist, I haven’t checked)
This sequence would be suffient to switch between at least macbook and linux machines smooth-ish-ly. I haven’t tested with my Windows machine. I have one here. I’ll do that next.
I haven’t tried the reboot macro fw yet (still on message-pool-hunt v1.2).
Is it essentially the same as using the reset buttons on the back of the board? If so, will we be able to specify left/right/both halves?
from the product page
