Wake on any RX

[HansSanitizer]

I was wondering if there was any way to wake from deep sleep from an RX message of any sort (wifi, bt, Lora).

Maybe an alternative question would be what is maximum power savings that can be achieved while being ready to recive a message.

[jcaron]

@hanssanitizer Leaving the LoRa radio in RX mode means the LoRa chip will be drawing a bit over 10 mA at all times.

What are your constraints in terms of battery size and battery lifetime? A relatively large 2500 mAh will be emptied in 10 days in this scheme, not even counting what is drawn when the LoPy is awake, so probably less than a week overall, depending on how often it wakes up, for how long, and what it does.

If that's something that is acceptable for you, then one could probably explore modifying the firmware to handle that, though my guess the complexity will arise from having to bypass all the LoRa chip initialisation on startup.

Note that if that kind of power budget is acceptable, maybe just using the light sleep modes may be OK and probably much easier.

For reference, the original LoPy uses the SX1272 while the LoPy4 uses the SX1276. I believe the FiPy uses the SX1276 as well.

[HansSanitizer]

@jcaron Thank you for taking the time to reply, I really appreciate it. I suppose my constraints in a nutshell would be requiring a wakeup to occur when one end node sends a transmission to another end node. These two nodes would not be distanced very far from each other, so perhaps bluetooth might be an option here.

Looking over the documentation there seems to be only one medium offered by pycom that accomplishes the task of waking from a sleep mode when receiving a transmission (on the FiPy, receiving data from LTE).

Reference: https://docs.pycom.io/firmwareapi/pycom/machine/

The products with LTE connectivity (FiPy, GPy, G01), require the LTE radio to be disabled separately via the LTE class before entering deepsleep. This is required due to the LTE radio being powered independently and allowing use cases which require the system to be taken out from deepsleep by an event from the LTE network (data or SMS received for instance).

I guess I am looking for the same functionality to be available in a LoRa radio. Initialize the radio as a class C device put the esp32 to sleep leaving the LoRa radio on in an RX mode, once the radio has something in the RX buffer it would wake up the esp32 to handle it. I know the typical chips from SX implement a FIFO buffer, and usually have a couple of interrupt pins available.

Reference: https://www.semtech.com/uploads/documents/SX1272_DS_V4.pdf Table 17, Table 28, Table 29
I should note that I am not sure if this is the radio used on the PyCom boards, but generally speaking SX chips follow this standard of having configurable DIO pins

Although doing things in this fashion may break from LoRa spec (due to timing considerations), for the task of waking based on input from another device it should be possible.

So my question then becomes, is there any way to leave the radio on when going into sleep modes? As far as any shield using the deep sleep functionality (pytrack, pysense, etc) I would assume the answer is no (even for LTE), as the PIC co-processor appears to cut all power from the entire Pycom module (which is a nice feature, and covers a lot of use cases where devices are built to periodically push sensor data at a given interval).

This then leads me to believe that I would need an additional radio hooked up to the board with its own power supply, configure it in a fashion to toggle a pin connected to the PIC to wake the unit from sleep (which is what I am currently investigating). The downside to this is that there is already a LoRa chip available (and the way its set up allows for such ease of development).

Again, I would like to thank you for taking the time to respond to my post, and I will also investigate BT for this purpose to see how much power it requires.

[jcaron]

@hanssanitizer Listening for a transmission uses power. It's very difficult to keep listening while still have a very low power consumption.

In the case of LoRa, the usual strategy is that one listens only after having sent a frame (and in LoRaWAN class A, that's the only way you can receive anything).

For Wi-Fi, there are power-save modes where the device periodically wakes up and polls the AP for any queued packets. Not sure if those are fully implemented in the ESP32 and/or available through the python interface, and how much control you have (AFAIK some of the critical parameters such as beacon interval are controlled by the AP, not the device).

For BLE, it depends a lot on the role of the device (central or peripheral), use of advertisements, connected status, etc. In theory you could have a device advertising and checking for connections while drawing relativement little power if you bump the advertisement interval. nrf52 devices can in theory go down to less than 10 µA in such a mode with advertisements every second or two, not sure if the ESP32 can be as efficient.

Then there's the issue of finding an ESP32 mode which reduces power as much as possible but still keeps the relevant radio working. It probably won't be deep sleep, and I'm not sure other sleep modes reduce the power consumption enough.

An alternative is to have the device in deep sleep with all radios off, and wake at regular intervals to poll for information. The whole game is then to find the right trade-offs involving:

• wake-up interval. The longer the better for power draw, but it means it takes longer for the message to be received
• how long the device stays awake, which is very dependent on the technology and network parameters (e.g. RX Window for LoRa, DHCP delays for Wi-Fi...)
• how much power you draw while awake (depends on technology and various settings)

If you have more details about your constraints (type of network which can be used, whether you control the network infrastructure or not, distance to cover, number of devices, how long you can wait for a message, battery capacity, expected battery lifetime...) maybe this can be refined a bit.