Hello,
Using mm-iot-esp32, I see print outs such as “his may take some time (~30 seconds)” as a part of connection logic.
Thinking about implementing the low power mode for battery powered devices, the initial connection time of 30 seconds is pretty long, also after connection is established, if the AP is gone, on every connection retry attempt cycle, we have to wait 30 seconds again.
Could you please provide some pointers as to how one can reduce this connection time ?
That message is on the pessimistic side of things. In reality it will take ~10seconds but this will vary based on your country code and network configuration (I won’t really go into the latter).
The current scan implementation mm-iot-sdk uses what is called and active scan. In short when you scan the station is going to sweep across all the 1MHz and 2MHz channels in your regulatory domain and send a probe request. It will then sit for some time on that channel waiting for any APs to respond. This is the dwell time and can be configured using mmwlan_set_scan_config(). Reducing this too much will affect the quality of the scan (i.e. you won’t give the AP enough time to respond).
Another way could be to reduce the amount of channels you scan. I.e. if you know that you AP is going to be on a particular channel you could only scan the channels that it can see. You could do this by changing the channel list you set, mmwlan_set_channel_list(). However, this is not a very practical solution IMO as this effectively requires you to provision your station and access point to match.
All that being said, my recommendation for battery powered solutions would be to maintain association and use something like WNM sleep or increasing your DTIM period. Both have trade-offs but may be acceptable to ensure the low power operation.
On the AP going away side of things. Note that you can use features like tickless-idle to get your host MCU to sleep whilst it is blocked waiting for the connection to be established. The host is not doing a massive amount of work whilst we are scanning. That only comes when you associate and it needs to do the crypto operations to establish the connection.
Hi Rob,
Thank you for the reply, focusing more on the AP going away. Lets say our application is a battery powered camera and when the AP is back (could be gone for hours, imaging the grid power that AP is conencted to is out for example) we need it to automatically re-connect. In this case, even if we assume our host is in sleep mode, how much power is the Radio it self going to consume? I can’t find any reference in the datasheet to “tickless-idle” mode, could you please let me know where I can read about it?
Tickless idle is a feature of FreeRTOS and is will affect the power consumption on the host (ESP32 in this case). You can read about it a bit more in the FreeRTOS docs and Espressif touches on in their docs.
In the instance where the AP goes away for hours I would not expect the station to scan constantly. It would start increasing the time between scans up to a maximum limit. In the next release (coming very soon) you can configure the duration and maximum value for this scan back-off. I.e. you might want something like re-attempt after 5seconds, then 25seconds, and so on up until a maximum of 10minutes which it will keep trying until association is achieved.
I don’t have the exact numbers to hand at the moment. However, section 5.4 of MM6108-Data-Sheet-v4 should give you a rough idea of what to expect. Very roughly speaking:
Transmit current → when we’re transmitting the probe request (pretty short frame at 1 or 2MHz MCS0)
Listen → when the chip is waiting for an AP to transmit a probe response (so in the dwell period)
Active receive → when we are actively receiving a probe response from an AP (1 or 2MHz likely MCS0)
Snooze → the MM6108 chip can/should go into this state in between scan attempts
A good resource for this is section 7 Power Consumption Measurements in the MM6108-EKH05 User Guide V1.0. It looks like it includes the STM32 consumption in the power consumption traces but it should at least give you a point of reference.