Power requirements of an RF remote control

[Peabody]

In a recent thread on IR remotes, Ian.M made the point to me that WiFi is generally expensive power-wise, so putting it in a remote might not be the best setup.  Instead you might have an intermediate device such as a mains-powered Pi Zero that would communicate with the battery-powered IR remote at one end, and with the target device over the network by WiFi.

The thread related to Roku devices, and the power issue raises the question of how modern Roku "point anywhere" remotes, which operate by RF in some way, manage to get decent battery life - if they do.  My Roku 2 remote is IR-only, so I don't have an RF remote to play with.  My interest is not so much the Roku specifically, but the use of RF in battery-powered devices in general.

While I can't find any documentation on it, my understanding from Roku Forum comments is that modern Roku remotes have two, possibly three, options for RF communication with the Roku puck or stick, in addition to the IR option:

1.  Bluetooth
2.  WiFi network
3.  Direct remote-to-puck RF of some kind, not involving the network or the router.

From my limited experience, the main issue is whether the remote has to stay on to remain paired, or can it go into deep sleep but still respond quickly enough when a button is pressed.

I don't know enough about how Bluetooth works to even ask a question.  But for WiFi, it seems the remote would have to stay awake and communicate periodically to remain paired.  If it had to go through establishing a session with the router when a button is pushed, it seems that might take too long.  Is that right, or do I not understand  this part of the WiFi protocol?

As for direct RF, it seems to me that in theory such a connection could operate exactly like IR does, even using the same codes and the same 38K "carrier".  The difference would be that the underlying frequency would be 433MHz or something like that instead of 940nm infrared light.  You would still have a 38K demodulating receiver to provide the OOK signals.  This system, like IR, would require no pairing, would be one-way, and would permit putting the remote into deep sleep, awakened by any keypress.

Does anybody have any information on the direct RF option?  I've found no Roku documentation confirming it even exists.

Here's a DIY Roku remote that uses WiFi:

https://medium.com/@nchourrout/building-a-better-and-bulkier-roku-remote-fa34bcb185c3

The ESP8266 is set up as a WiFi client, and as far as I can tell from the sketch, it never sleeps.  Could it be put to sleep and still respond quickly enough when it wakes up?  How do people generally deal with this when using an ESP8266 in a battery-powered device?

[Benta]

WiFi is power-hungry, no question about that. For a simple RF remote for your region, I'd suggest 915 MHz (902...928 MHz).
Very low power, simple pairing and on-demand activity/transmission (=pressing a key). It's 100% comparable to IR.
Lots of chipsets/modules out there.

[Nusa]

Or you can load the roku android or ios app on a smartphone and see if that does the job you need done. Saves you the effort of building any hardware. Still relatively power-hungry, but you're already used to charging your phone regularly, so it hardly matters for most.

[Peabody]

What I'm trying to understand is the options I might have for wireless things totally unrelated to Roku.  My interest in the Roku RF remote is just how it deals with RF power-wise, and whether it can sleep.  If it does ok and gets decent battery life, then I need to know how it does that.

Since the original post, I finally got the right search term, and found that the direct RF connection used by Roku is something called WiFi Direct.  In fact, I found that even though I have an IR remote, my Roku 2 is a broadcasting access point for WiFi Direct at about 80% of the power of my router, and on the same channel.  But I found a Roku setting that let me turn that off.  But otherwise, I'm not sure WiFi Direct is any different than regular WiFi in terms of power requirements.  It still seems to me it would have to stay on all the time.

[Nusa]

That's mostly a matter of looking at the datasheet for the device in question and how the software you write makes use of the device in terms of duty cycle and tansmit power. For this kind of application, remember that a device that appears "on" to a human might actually be in a sleep mode much of the time, waiting for a key to be pressed.

Here's a datasheet for one of the 8266 devices. Page 13 talks about power.
https://cdn-shop.adafruit.com/product-files/2471/0A-ESP8266__Datasheet__EN_v4.3.pdf