[Ovmsdev] WiFi client not switching to better AP

[Stephen Casner]

Michael,

> the RSSI is read for the connection in use, -127.0 is the value for the
> unconnected state. The value needs to be smoothed as it's quite jumpy, so may
> need 2-3 seconds after connect to get to the actual value.
>
> IP association normally takes long enough from connect to get the RSSI into a
> usable state, and thus the WifiStaCheckSQ() call in WifiStaGotIP() is meant to
> switch to the network as soon as possible.

It's not clear to me what scenario you are describing.  When you say
"switch to the network" are you talking about switching to a different
Wifi network than the one from which an IP address was obtained?  (If
so, that does not make sense to me because we just chose the current
one as the best in our scan.)  Or are you talking about switching to
the modem network because the Wifi we're trying to connect to does not
have good enough signal quality so we should give up on it?

> For the case of fast DHCP association, you could try speeding the RSSI
> adoption up by checking for m_sta_rssi == -1270 and skipping or weakening the
> smoothing in that case, so the first RSSI read after a connect will be used
> immediately / stronger.

I tried checking in WifiStaCheckSQ() for -127 and skip emitting the
network.wifi.sta.bad event, but more often the value was -95 to -98 so
that check was not sufficient.  Hence the idea to just remove the call
to WifiStaCheckSQ().

> But I remember that first value being far too
> optimistic in my test cases, which were having a single AP barely reachable
> from the car. I suggest testing that case specifically, as it seems your
> current test setup is close to a best case scenario.

So this is the scenario where you are connected to the modem network
and then Wifi hears one of its configured networks and so tries to
take over from the modem?  It seems like the decision to ignore the
Wifi should be made earlier based on the scan before trying to
associate and do DHCP.  Is the problem that the RSSI from the scan is
too optimistic?  If so, should multiple scans be done for the
smoothing before trying to associate?  Or is the scan always
unreliable and you have to connect for a while to get an accurate
measure?

If you're talking about have a good Wifi connection established but
then hearing a new network and switching to it when it doesn't have
good signal quality, shouldn't that be known from the scan?  (Again,
unless the scan is just not reliable.)

> OTOH, removing the WifiStaCheckSQ() call in WifiStaGotIP() would introduce at
> most 1 second delay for the netmanager to switch to the Wifi network, as the
> next ticker.1 run would trigger the switch. So that's not critical I think.

That's what I was thinking, so simply removing the call would avoid
the unreliability of the signal quality measure at the time the IP
address is obtained.

> Another option: WifiStaCheckSQ(NULL) triggers the events unconditionally of
> the previous state, just by the current signal quality. That was meant to
> process a changed threshold configuration, but I don't remember why I did that
> in WifiStaGotIP(). Maybe that's why the "bad" event got triggered twice? You
> could try passing ms_m_net_wifi_sq there instead of NULL.

I can try this, but I'm not clear on the logic yet.  Why is the
argument a metric pointer when it is only used as a flag?

                                                        -- Steve