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.