Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 5940

MicroPython • Re: Pico W Reliability

$
0
0
Playing with OpenWRT, look what I found: Station inactivity limit 802.11v: BSS Max Idle. Units: seconds. So this is a thing.
It's been a thing for decades but I've never given it much thought. In my experience wireless connected things just work and I have never wondered why they work, how they work, what's going on behind the scenes to make it work.

My guess would be, you turn your device on or bring it out of sleep, if it's already connected to the router, job done, otherwise it silently connects to the router. By the time you've opened a browser or need to have network access the connection has been established or there will be a short delay until that completes.

Let it sleep or turn it off and it either sends a "bye" to the router or the router figures it's gone away after some time so assumes that "bye".

Then repeat from turn-on or wake-up when you pick up that device again.

That would also be the scenario for a standalone Pico W posting temperature data to the cloud. It's time to send data, connect if not connected, send the data, idle for some time, repeat.

But for a server it's different. Once connected that spins and idles while waiting for a request. If it doesn't receive any request, isn't communicating with the router, it's reasonable for the router to say 'that's gone AWOL' after some time, disconnect the device.

And the only way to get it reconnected is through the server initiating a reconnection. And it seems to me that's what we are dealing with here.

So how would a Wi-Fi NAS work, keep itself connected, be always available on the network ?

It may be that a router sends out an 'are you there?' before deciding it's not so the device can cancel any disconnection or it regularly sends some kind of 'no operation' packet so the router resets it's 'gone AWOL' timeout. If it ever does get disconnected it simply reconnects again.

I would presume the networking stack handles most of this in the background, much like it would handle pings and ARP etc without requiring the user code having to deal with those. But maybe the CYW43 and LwIP combo doesn't ?

So a four-fold challenge -
  • What is it supposed to do ?
  • What is it not doing ?
  • How do we catch when it has not done something it should ?
  • How do we substitute something for what it should have done ?
Or, and potentially much simpler, we figure out a means to send a 'no operation' packet on a regular basis which keeps the connection alive, then only have to deal with an actual loss of connection in more adverse situations.

The OP has a 'uasyncio' solution which appears to handle detection of disconnection and reconnection, all while the 'uapi' server keeps running. So all we may need is to send a 'no operation' packet within that same 'monitor_wifi' task.

Anyone know how the undocumented 'wlan.send_ethernet(...)' works ?

Statistics: Posted by hippy — Sat Dec 28, 2024 1:00 pm



Viewing all articles
Browse latest Browse all 5940