Has anyone else experienced a scenario when right clicking on things in MacOs kills the board and requires it to be unplugged and plugged back in?
Latest firmware and macOs.
Very frustrating.
Not everytime that I right click on things, but maybe one in five or so.
Actually seems to be only the left key cluster that is affected. maybe.
Have the same issue. Fastening module steel guide screws helped to some extent, but did not eliminate the issue completely. Also fastened everything that is possible and still have random disconnects.
Have you guys tried the sticky tape fix featured in the article?
Sorry about the issue! Some are affected by it, but we can only improve the design of later products in this respect.
It’s ok, I’m just curious to find the reason.
Here is what I tried so far. I soldered the contact plate so that it sits much closer to the contact pins and also is a bit tilted to compensate wobling. The connectivity is perfect now, but the issue does not go away. It happens only when clicking the right mouse button. And sometimes (on really rear occasions) when pushing the module down near that key.
For now, I remapped mouse keys to regular full-sized keys on the module and I can work without any issue. But I’m still curious what is going on there.
If it’s not a mechanical connectivity issue, the cause may be interference. If the i2cRecovery counter keeps incrementing without modules, it’s likely interference.
The counter indeed starts to increment rapidly when the issue occurs.
But it only happens when the keycluster is connected. Never (even once) seen an i2c recovery event with keycluster disconnected (I have agent running all the time).
If the “disconnect” happens, there are two things that might help:
Just found something: completely disabling backlight for the whole keyboard makes the issue go away. It literally never happens anymore.
I’ll experiment with that later, probably will try to disable keycluster’s backlight only.
Pushing the key cluster with a decent force to the UHK for a while should be a good test for connectivity issues. If the i2cRecovery counter doesn’t increment during the test (regardless of the backlight, which shouldn’t affect this issue), then connectivity should be robust.
I would guess at power issues then. Reducing backlight of the entire keyboard should help in that case.
That is 100% not a connectivity issue, it is the issue with backlight/power.
Also tried a ton of different cables, 5+ PCs of different types and nothing helps to even lower the rate of errors occuring.
Reducing backlight is also not the way to go, because on lower backlight levels the whinning noise from the LED driver is louder than my cooling system.
That’s strange. My UHK is noisiest with high backlight levels. As I lower the backlight, it goes down.
Yeah, I’ve read about this in article, and while it is strange, that is the fact. Probably it has something to do with failing key cluster module. Not sure.
Is there a way to disable only keycluster’s backlight without switching to individual key led settings?
Well, you can use the set backlight.keyRgb.LAYERID.KEYID macro command.
I guess following placed in a $onKeymapChange any-named macro should do the trick:
set backlight.keyRgb.base.leftModule.key1 0 0 0
set backlight.keyRgb.base.leftModule.key2 0 0 0
set backlight.keyRgb.base.leftModule.key3 0 0 0
should “disable” the backlight - set them to black.
(Although to be fair, this doesn’t disable the led driver - if this was a hardware issue it may or may not help. On the other hand neither would (disable the driver) the per-key RGB mode.)
Also, what is the result of testing with backlight level set to 1 for the entire keyboard?
Thank you.
Using set backlight... does not work for some reason. Getting weird parsing errors.
As for the backlight level:
With backlight level set to 253, the issue does not occur, the whinning is at almost acceptable level and I do still have a backlight. So, that is quite ok as the temporary solution.
Just wondering, is it possible that the cable connecting two halves (or its rj11 connectors) contributes to the issue somehow?
Getting weird parsing errors.
Sorry, I will get that fixed.
Meanwhile, please use:
set backlight.keyRgb.base.128 0 0 0
set backlight.keyRgb.base.129 0 0 0
set backlight.keyRgb.base.130 0 0 0
Just checked and the result is as expected: turning off backlight of the keycluster doesn’t change anything.
Update after 6 months:
After almost destroying the key cluster, the problem turned out to be in a spiral connecting cable - it acts like a pretty good antenna, picking up everything it can “find” in the ether. A cheap, dull, rigid, straight telephone cable makes the keyboard insusceptible to any signals that could be found around my desk.
Now I’m in a search of a cable that is not that rigid as my new one.