I was wondering if anyone else had the same experience as me. I’ve noticed that the left side battery runs low (down to 2-3%), whilst the right side battery is still up at about 50%.
I use dongles on my computer, and have the two sides connected with the cable.
I have noticed that one side will be drastically lower than the other, but haven’t worked to actively track which one and by how much. Since I don’t move around with my keyboard much, I disconnected the batteries at around 80% and got one of these to keep it plugged in all the time: Amazon.com: Anker USB C Cable,4 ft 2-in-1 USB C to USB C Cable 140W Max,Fast Charging for iPhone 16/16 Pro/16 Pro Max/16 Plus/15 Series,Galaxy S24,MacBook Air/Pro,Lenovo,iPad,and More (USB 2.0,Braided,Black) : Electronics
@mlac Can you comment on left side battery drain?
My new UHK80 used for a few hours wirelessly, both charged to 100%, is currently sitting at 78% on the left half and 96% on the right half.
LED brightness is set at 24/255 on battery, and I use FN2+Pause to sleep when walking away. Left half seems to be draining at 5.5x the rate of the right half.
My usage was sparse, LED timeout is set to 6s, and I was mostly watching videos or browsing in that I was not interacting with the keyboard. The right side battery drain seems correct to me.
This seems to be an existing reported issue: UHK 80 - Left side battery drains within a day · Issue #1304 · UltimateHackingKeyboard/firmware · GitHub
I also have the keycluster attached. The keycluster does not seem to update beyond 15.0.1 even when forcing an update with agent v9.
Is the only way to resolve this to detach the keycluster?
I don’t have a key cluster module to verify the latest version, but yours is probably up to date. The modules don’t get updated very often, and they’re not necessarily going to match the main keyboard’s firmware version.
I have a UHK80 with key clusters. Normally use wired but often use wireless too. I don’t see the left side draining in a day as per the issue #1304
Now the percentages of the left goes down faster than the right but from what I recall that is because the left side battery is smaller than the right side so I would expect an asymmetrical reduction in battery status.
Obviously with backlight on, batteries will drain fast.
As for the disparity, right has (much) bigger than left half - this is because right has more keys, unlike left acts as the brain of the keyboard, so it does more computations, handles host communication - and seems that we have a bit overshot that 
.
I am wondering if just showing lower battery levels on right than what they actually are would make people more comfortable 
.
Comfortable or not, you won’t be able to hide the fact that the left will run out of juice earlier than the right 
If you have the spiral cable connected, can the right supply power from its battery also to the left? (with no USB power connection on any half)
Weirdly, since FW v16.0.0, my batteries seem to remain fairly even. I don’t have a key cluster, and I usually use the bridge cable, but before this latest FW, left-half drained much faster 
.
It seems to have been a bug with Agent. I connected the keycluster to my UHK60, and the firmware read for all was 14.2 ; I was able to update to 16.0.0 by flashing when connected to UHK60.
However, this does not seem to help. Detaching the key cluster is the only way I am able to stop the battery drain. Unless the OLED reports battery percentages incorrectly, leaving the keycluster attached seems to drain the left half battery even when the keyboard is sleeping via FN2 + Pause.
I think there’s enough people reporting this problem on 1304 + my own experiences it seems reasonable to treat the keycluster as the root of the problem.
I asked codex to rootcause the issue, and if you are not opposed to LLM based tools, it might be worth your time to look at this: uhk80-left-keycluster-power.md · GitHub
There is an implicit bias in that I asked it to evaluate why keycluster might be causing the battery drain, so it might have tunnel visioned on it even if the problem is elsewhere. However, the contents seem reasonable and logical to me.
That is not surprising as the llm is trained to sound reasonable and logical.
A problem is that it always picks one rabbit hole to go down at random, and isn’t capable of even considering that it might not be in the correct one.
This is one such case.
I see.
Regardless, the issue is with the keycluster module. The trackball isn’t even as responsive as it should be. In its current state, it is hard to regard the keycluster as a supported module for the UHK80.