Significantly asymetric power drain between left and right halves

[opie4624]

Overnight power drain while entirely idle (for 12+ hours). This morning, for example, the left half was completely drained, while the right was at 68% after a full charge cycle ended before the idle period started.

v17.2.0 all wireless, with dongle, touchpad and key-cluster modules

[kareltucek]

Hi!

As for the assymetry, we know about it. There is not much to do about it unfortunately.

Right has significantly bigger battery. The reason behind that is that it has more leds and that it acts as the brain of the keyboard - more workload, managing multiple bluetooth connections, etc.. But with disabled backlight, most of the draw is the normal component upkeep, which is symmetric.

Another problem is the keycluster, which draws a lot. Disconnecting it should double the left's life.

Still, basic diagnostic check:

• How long does it actually last?
• Is that with disabled backlight?
• Please check left half's firmware logs ( https://github.com/UltimateHackingKeyboard/firmware/blob/master/doc-dev/guides/logs.md )

[opie4624]

Hey @kareltucek, I was actually about to submit a patch that reduces the timer for checking for a merge when in sleep mode. It looks like the left half keeps checking every 500ms even when asleep. However, I'm struggling to get it to build so I can test:

CMake Error at /home/akraut/code/zephyr/cmake/modules/FindZephyr-sdk.cmake:160 (find_package):
  Could not find a package configuration file provided by "Zephyr-sdk"
  (requested version 0.16) with any of the following names:

    Zephyr-sdkConfig.cmake
    zephyr-sdk-config.cmake

If you have any suggestions on how to get it to build?
In the mean time, I can try to time it with and without the key cluster and enable logging.

[kareltucek]

Push it into github and use the CI is by far the least painful and time-demanding one.

As for local setups, I am using linux with the build.sh script. In that case ./build.sh setup, ./build.sh switchZephyr and ./build.sh build right sequence "should" work.

[kareltucek]

But a single gpio read every 500ms won't consume any significant power. For perspective, scanning the entire switch matrix 1000 times per second doesn't cost any significant power. The power is in keeping peripherals up all the time and ready for operation.

We need to implement machinery that can put all the peripherals to sleep and resume, ideally without disrupting uhk's operation. I am working on it as a background task right now.

[rg-software]

Just wanted to echo the sentiment above: in my case, I see about 10% drain per day in sleep mode (the PC is turned off) for the left side and maybe 3-5% drain for the right side. I do have a key cluster and a trackpoint.

Regardless of the reasons, there is something fundamentally wrong here. My other wireless keyboards can last for weeks without much drain at all, and I certainly did not expect I'll have to charge UHK twice a week.

[kareltucek]

Yes. Two actually:

• The firmware (peripheral drivers to be exact) aren't optimized for low power co sumption yet - there were always more urgent things to do. But I am working on it these days.
• Modules were designed in the uhk60 era, when power consumption wasn't a concern. As of now, it seems there is an electrical design issue with the keycluster, which unfortunately makes it consume what it consumes, and can't be remedied eith a firmware patch.

[rg-software]

Maybe it is still possible to remove power supply to the modules completely in the sleep mode? At least to me, inability to use a peripheral to wake up a keyboard looks like a much lesser evil than power drain.

[kareltucek]

I totally agree, unfortunately no one thought of that when designing uhk80, so the module is hooked straight onto vcc 😞.

[kareltucek]

New measurement says that the blackberry trackball eats 6mA, while the rest of the board 4mA. Those 4mA may be reducible. The trackball probably not.

[kareltucek]

Here is a tentative pre-release of the power-optimized firmware: uhk-firmware-17.2.0-staging_260730.tar.gz

Would be glad if you could try it and give feedback. (E.g., bluetooth handling has been significantly reworked.)

[kareltucek]

With usb reconnection fix applied: uhk-firmware-17.2.0-staging_260731_v2.tar.gz

[rg-software]

I have checked the new firmware (it takes time to see the actual drain). In my case there is an improvement for the right side, maybe to 1.5% drain a day (but note I do have a trackpoint module there), and maybe no significant improvements to the left side (~10%) with the key cluster.
I will also check tomorrow and then see what happens if I remove these modules. Of course it would be great if you ever get a chance to revise them.

[rg-software]

Actually, I haven't checked the bluetooth connection yesterday but now I see it is broken :( No idea if it is caused by this update but I have no other thoughts. First I saw that my existing bluetooth connection does not work, so I thought, okay, I'll repair. But now the keyboard is not discoverable. I checked on two machines (Arch Linux and Windows), same result.

P.S. Flashed the 17.2.0 version again (bundled with Agent), works now. The last update apparently breaks something.

[kareltucek]

Have you switched to the connection first on uhk?

We are transitioning to a single-point operation by default. UHK wont start advertising until you tap the relevant action.

[rg-software]

How do I do that? The manual says bluetooth is always advertised.