[Ovmsdev] WiFi client not switching to better AP

[Michael Balzer]

Steve,

I see you already followed the bread crumbs ;-)

I wanted to have the whole good/bad event emission logic in one place & 
still think it's good for clarity.

If we need to force good/bad state, I suggest adding a method for this 
right after WifiStaCheckSQ().

Regards,
Michael


Am 18.12.20 um 17:08 schrieb 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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201219/352715cd/attachment.sig>