The following issues have begun occuring recently after I upgraded to UltimateHackingKeyboard/firmware: 10.4.0.
When moving the mouse with the Trackpoint module as usual,
Randomly, there is no input from the UHK for about 10-20 seconds.
During the periods when UHK input is blocked or jammed:
Nothing is sent from the UHK - no mouse movement or keyboard input.
Other USB peripheral devices continue to function (e.g., a Logitech mouse).
The small screen on the UHK remains unaffected - it continues displaying the name of the current keymaps profile.
To resume normal functionalities, there are two “fixes”:
To fix it immediately, unplugging and plugging back in helps (related, here is a post where such event is triggered by a right-click, on MacOS).
Or, just take a short break It will get back in a minute for sure.
Below is a list of UHK and PC combinations where I have encountered the issue. In total, I have experienced this problem with 3 out of 4 UHK units that I regularly use.
UHK V1 with Win 11 laptop
UHK V1 with Win 11 desktop, over KVM switch
UHK V2 with Win 10 work laptop, over KVM switch.
Across all my UHK units, I’ve been using the same config file, with all parts flashed with UltimateHackingKeyboard/firmware: 10.4.0. Previously, with dated firmware from 2020/2021 or so, I have never experienced such outage.
Next steps:
Updating to Firmware 10.5.0: I just forced the UHK Agent to update itself and found this new firmware option;
If #1 fails, I’ll try to tighten the screws, as László mentioned in this reply.
It’s strange that 3 of your 4 UHKs suddenly started to freeze.
If this were a mechanical issue, it’d only manifest itself on one of your UHKs, not three, but please try to tighten the screws regardless, as suggested, just to be sure.
It’s also worth trying other firmware versions, although nobody has reported such issues.
My guess is that, somehow, heavy electromagnetic interference has been introduced into your environment. This troubleshooting guide may help.
I hope we’ll solve this soon, and keep us in the loop.
Here is my current understanding of the reported issue: it has to do with the unofficial crossover cables I use, and the same cable may perform differently depending on whether it is UHK V1 or V2, and which specific firmware the keyboard has.
Note on firmware: with old firmware (V8.10.12), both UHK V1 and UHK V2 are NOT picky about the cables. They just work. However, with the current firmware (V10.5.0), UHK V2 starts to be picky about which cable it gets. In short, what works fine with UHK V1 may not necessarily work with UHK V2 under V10.5.0.
After tightening the screws in no avail, I’ve observed various cable-involved failures with UHK V2:
Upon connecting the left half with a specific cable, the right half together with the trackpoint module will stop to work - the mouse cursor barely moves and none of the keys work (on both halves);
With another cable that works fine with UHK V1, the following may occur, with the left half not registering any input and not visible in the UHK Agent.
Answering my own question: to troubleshoot a keyboard freeze issue with UHK, if a bridging cable is involved, one may first consider merging the halves to isolate the cable issue. Then, one may swap cables around to find the right match, and stay with it
This makes sense. The extended length (the maximum length the cable can reach when straightened) is quite long, leading to high parasitic capacitance and a high chance of picking up electromagnetic interference and such issues.
The best solution is to use a straight (non-spiral) cable that is as short as possible.
Suspect that a combination of 1: Window’s “Phone Link”, 2: Galaxy Watch “WiFi” settings, with Mobile Data off, & 3: Galaxy Phone connected to USB Hub (which also connects to my UHK) started the issue.
Ended up trying to update to V10.5.0, but had serious issues. I suspect interference from 1 or all of hte 3 mentioned above, created issues with the update - so I was unable to do it on my main workstation. Luckily, moving to my other PC, with a fresh UHK agent, allowed me to get my left keyboard working again (had to keep them connected).
Unfortunately, my Key Cluster Module & Trackpoint modules seem to be totally unresponsive. I did the screw loosen/tighten on both of them, but nada…
So, I’m waiting on some new cables to come in, hopefullly that makes the diference. But, man, what an unexplained loss. Just seemingly out of nowhere - this happens…
@adrianegraphene, you have the UHK V2, correct? In my experience, the UHK V1 units are more forgiving with cable compatibility than the V2 units. Given that your UHK functions properly when the two halves are directly connected, I wish you good luck in finding the suitable cable
Here are a few open questions when it comes to UHK+Cable combinations:
Does the compatibility issue have to do with increase power draw, which may have been introduced in newer firmware?
If we were to force “no-light” on UHK V2, can it behave more like UHK V1, which doesn’t have any light to begin with?
Observations about power draw - I have been using the UHK daily for several years. Only after upgrading to V10.4.0 (or V10.5.0) did I learn about the FTY error code, which stands for “not enough power” (as detailed on the FAQ page). This error code may appear on the UHK V2 when used with a ThinkBook laptop. Swapping USB-C cable for UHK helped.
You are right, @llinfeng it is a UHK V2 I’m working with. I had the V1 for 6 months and never had issues. V2 is going on 8 months now & since newer version - I’m starting to have these issues. I wonder if I try to reset my configurations and use a version before 10.4.0, that I’ll get my baby back.
I’ll see how the new bridge cable go, but I am not optimistic. The UHK agent instantly detects the left half when I connect, but the 2 modules are not detectable at all.
I don’t know. But I’ve been running V2 through a large workstation. And I’ve been able to run it on my ThinkPad P16s G2 with no issues.
I tired in
set leds.enabled 0
“$onInit”, but $onInit doesn’t seem to work for me (not sure if it ever did). So I just set up a macro where I can manually turn off the LEDs. That did not resolve the issue. Modules are still undetectable.
Thank you for your good wishes! I’ll see if the new bridge cables make a difference when they come int. Worst case, I’ll reset the device configuration…
Something VERY odd that I noticed just now… and it happened once before last night… When I plug my right module in (trackpoint). The program “Microsoft 365 Apps for enterprise - en-us” is opened on Windows 11.
When I plug my right module in (trackpoint). The program “Microsoft 365 Apps for enterprise - en-us” is opened on Windows 11.
To isolate things, does it also pop open when you only keep the right-half connected? I remember it quite clearly, that my trackpoint module and the right-half were working fine, until they are frozen all at once when I joined the left-half to the system with a faulty bridging cable.
RE: to track why that “Microsoft 365 Apps for enterprise - en-us” gets launched on itself, you may find KeyHistory useful from AutoHotKey - once called in AHK, KeyHistory will bring up a window with all input events triggered by mouse/keyboad.
KeyHistory is interesting… I’m not sure I need it anymore, but I’ll keep that in mind. I just messaged support and saw an FAQ about bricked modules, which helped me recover my key cluster module. However, I’ve not gotten my trackpoint module to work yet.
I am more optimistic than before, and will see if support’s response or my new cable helps fixs the issue with my trackpoint module. Thanks!
The link you provided seems like an admin edit link, which we wouldn’t have access to. If so, then, Yes, I tried that a few times too.The 1st bridge replacement cables came in and I am not seeing any difference for the trackpoint module.
I sent the wrong link, indeed; the one you provided is the correct one.
Frankly, I’m getting out of ideas regarding your trackpoint module. If it’s under warranty, we can send you a new one if you contact us, although I’m not sure it’ll fix your issue.
I am still puzzled by this happening independently on 3 different units given that we received no similar reports.
They must have something in common:
environment? (High electromagnetic interference?)
same computer, or at least computer brand/model? (Some motherboard issue?)
some software running on all your computers?
same usb hub brand? (Badly implemented usb protocols, or power issues?)
using same trackpoint module with different keyboards?
air dampness?
One last thing that comes to mind however improbable:
By a chance, have you done any soldering on your pcbs? I find that the UHK is very temperamental when it comes to even a little rosin spread over the PCB. Had multiple weird issues in the past that were all resolved by just cleaning the PCB with alcohol.
@kareltucek Here is a summary of what I know based on my collection of UHK: in short, third party cables matter a lot and powered USB hub works better than non-powered ones.
All my UHK units are back to normal after cable swap. This includes 3 UHK V1 units and 2 UHK V2 units. I’ve been pairing them mostly with Windows 10/11 machines, over multiple USB hubs/splitters/adapters. Powered USB hubs tend to create less connection issues when switching hosting computers, where I was using a KVM switch to reuse the same monitor setup across personal PC and work laptop.
Since I learned about the FTY error code only recently on a ThinkBook Plus Gen 4 (launched some time in 2023), I suspect these newer laptops may have weaker USB-C connectors(?), making some UHK V2 unhappy about that. On this ThinkBook Plus Gen 4 laptop, I even need to go with a powered USB-C splitter to drive UHK V1.
I have been seeing something similar on my V2 — but haven’t reported it, since I am struggling to isolate what might be causing it.
It seems to happen most frequently inside MS Office products (Excel, Teams, Outlook etc.), and appears to get triggered most often when I am trying to “right click” on something, using the alternative buttons on one of the modules (most frequently the key-cluster module).
I have however been struggling to pay more attention to things when it happens, to be sure about any of the above.
What I will add, is that — yes, I too see everything freeze up for 5-10(?) seconds, despite the keyboard appearing to be normal (so, nothing dies/gets lit up on the LED display) — however, I have moved on to simply unplugging/re-plugging any of the two clusters (key-cluster or trackball), instead of unplugging the keyboard itself from the hub. This does the trick, and instantly restores things.
Can also add that I have yet to see this happen on the V1 (although, the V1 is at the home office, and I spend all day on the V2 at work — so not the same usage pattern), and both V1 and V2 are plugged in via hubs (albeit different brands).
Figured I would add my 2 cents about the cluster unplug working — but will pop something up more definitive, when I have an inkling of what/where it is consistently triggered.
however, I have moved on to simply unplugging/re-plugging any of the two clusters (key-cluster or trackball), instead of unplugging the keyboard itself from the hub. This does the trick, and instantly restores things.
Noticing the same issue with my V2. It seems to happen only on right mouse button clicks on the left side three button module. Sometimes it will unfreeze by itself after a few seconds, sometimes it won’t unfreeze unless I press a few random keys on the module or move the scroll wheel on that module (only interacting with the module itself not any other parts of the keyboard).
@mlac already did the fastening I think the module is solidly in place. It doesn’t happen with any other keys on the module. I also tried remapping the rightmost button as a right click but it worked fine. It happens if I apply pressure on the module from the right (to make sure is connected) so I’m pretty sure it’s not due to the module coming loose from the keyboard.
It will get back in a minute for sure.