Skip to content

Conversation

@cringeops
Copy link
Contributor

I found it absolutely terrible in terms of UX to wake the screen with encoder press. It feels much more natural to wake it with encoder rotation.

If we don't want it to be the only option, we can still make it an option via the settings menu.

@Sfinx
Copy link

Sfinx commented Jul 18, 2025

The encoder can be unintentionally rotated in pocket when you listening radio with headphones while walking

@cringeops
Copy link
Contributor Author

The encoder can be unintentionally rotated in pocket when you listening radio with headphones while walking

That's definitely true, but if you are actively using the receiver and it goes into sleep, it's much more intuitive to wake it with a rotation. We need either a menu option to toggle this behavior or implement a mechanism to discard unintentional rotations.

@max-arnold
Copy link
Contributor

max-arnold commented Jul 19, 2025

@cringeops Hi!

Unfortunately, this change breaks an existing use case: SLEEP_LOCKED was added to allow carrying the receiver in a pocket (one user even uses a short wire antenna as a lanyard).

But if your use case involves automatic sleep timer, we can allow wake up on rotation in a similar way as it was done for click: https://github.com/esp32-si4732/ats-mini/blob/v2.28/ats-mini/ats-mini.ino#L800-L806

Undo your change, then add something like this (untested) below the changed line:

if(encoderCount && sleepOn() && currentSleep) {
  encoderCount = 0;
  sleepOn(false);
}

But this is not enough. To wake up from CPU Sleep mode you need to configure the encoder rotation pins to interrupt the Light Sleep mode.

And all of this requires thorough testing in all modes.

@cringeops
Copy link
Contributor Author

@max-arnold Thank you for your input! Indeed, my use-case involves sleep on timer. I propose the following logic: we allow wake with a rotation only on sleep on timer, and ignore rotations when sleep is invoked by user (putting the device to sleep with a long encoder press before putting it in a pocket, for instance). I believe this logic to be the best of both worlds: user can intuitively wake the device and continue band tuning with a rotation if it sleeps on him, and it won't accidentally wake in a pocket when put to sleep by user.

@max-arnold
Copy link
Contributor

max-arnold commented Jul 20, 2025

Currently there is no distinction between the ways a receiver was put to sleep. For simplicity, I just check if currentSleep is non-zero (it contains the Settings->Sleep value), and then allow wake up on click instead of long press. The code snippet above uses the same logic for encoder rotation.

Maybe it is worth adding another sleep state (not just true/false) to remember how the device was put to sleep (timer vs long press) and allow different wake up gestures based on that

@cringeops
Copy link
Contributor Author

cringeops commented Jul 26, 2025

Okay, I followed the same logic with currentSleep. It's not ideal, of course, but it allows us to avoid additional global state for a sleep trigger flag.

I tested and verified the following use cases:

  1. Sleep timer is disabled. Device never wakes up on rotary events regardless of the sleep mode configured. Tuning in unlocked sleep mode is working.
  2. Sleep timer is enabled. Device wakes up on rotary events in CPU sleep mode. Tuning in unlocked sleep mode is working and does not wake the device allowing to keep the screen turned off for QRM reasons mentioned in issues.

While I find my changes quite useful for me, I see an obvious issue: I can't keep sleep timer enabled to walk with the radio in my pocket because rotary events will wake it. To avoid that, I have to disable the timer and put the device into sleep manually. So, there is a decision to be made: we either go on with this compromise solution or actually implement a sleep trigger flag to differentiate between user-invoked and timer-invoked sleep.

Edit: Also, I just realized that in locked mode the device won't actually wake up. It means that this piece of logic is not needed at all.

@max-arnold
Copy link
Contributor

Could you please rebase this PR against the latest main branch?

@cringeops
Copy link
Contributor Author

Sure, I will do that on a weekend once I turn back to the project. I'm still thinking on the actual logic of this feature, to be honest. I think we probably should separate sleep mode and lock functions because I deem they should be independent of each other. For example, I may want to have a CPU sleep with locked encoder when on the move and CPU sleep on timer when I'm casually surfing the bands but want my radio to wake up on encoder action.

Therefore, I propose the following logic:

  • Wake on rotation menu toggle.
  • Sleep modes are boiled down to CPU sleep and screen off.
  • If user wants to tune with a screen off, he disables wake on rotation and sets screen off sleep mode.
  • Sleep on timer always imply unlocked encoder (and it will require a state flag for that, yes).

@max-arnold
Copy link
Contributor

Wake on rotation menu toggle.

I would prefer to avoid adding another menu option

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants