[Ovmsdev] WiFi client not switching to better AP

[Stephen Casner]

Michael,

Oh ^2.  The argument to WifiStaCheckSQ() is a metric pointer for
MyMetrics.RegisterListener().

Another solution would be to just put the desired part of
WifiStaCheckSQ() into WifiStaGotIP():

    if (StdMetrics.ms_m_net_wifi_sq->AsFloat() >= m_cfg_wifi_sq_good)
      {
      m_wifi_good = true;
      MyEvents.SignalEvent("network.wifi.sta.good", NULL);
      }

                                                        -- Steve

On Thu, 17 Dec 2020, Stephen Casner wrote:

> Michael,
>
> 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().
>
>                                                         -- Steve
>
> On Thu, 17 Dec 2020, Stephen Casner wrote:
>
> > 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