[Ovmsdev] WiFi client not switching to better AP
casner at acm.org
Fri Dec 18 15:19:49 HKT 2020
Oh, now I think I understand what you were saying, sorry. I was
focused on the 'else' clause of WifiStaCheckSQ() that triggers a
disconnect and trying to figure out why you would want a disconnect to
occur in WifiStaGotIP(). Instead, I think you were talking about the
'if' clause and saying that if the signal quality was good enough in
WifiStaGotIP() then you would want to connect right away. For the
weak case of the AP barely reachable from the car, you don't want
network.wifi.sta.good to be signaled and WifiConnect() called.
Rather than not calling WifiStaCheckSQ() in WifiStaGotIP() at all,
what we want is that only the 'if' clause would be executed and not
the 'else' clause. That's what calling with a non-NULL argument
accomplishes, as you suggested.
I still ask the question, why is the argument a metric pointer when it
is only used as a flag?
I repeated my walking-around experiment with this code change. It
mostly worked, but in one instance disassociation occurred first at
the wifi driver level before the periodic check of the signal level.
Thus WifiStaCheckSQ() was not called and m_wifi_good did not get set
to false. Then when WifiStaCheckSQ() was called from WifiStaGotIP()
after associating with the closer AP and the signal quality was again
not reading as good enough yet, it caused a network.wifi.sta.bad event
and an undesired reconnect due to my script.
So we also need m_wifi_good = false in some place like WifiStaStop().
On Thu, 17 Dec 2020, Stephen Casner wrote:
> > 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
> 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
More information about the OvmsDev