[Ovmsdev] WiFi client not switching to better AP

[Stephen Casner]

Following up #2:  Perhaps we can just remove the call to
WifiStaCheckSQ() in WifiStaGotIP()?  If the IP address has just been
assigned then the radio must be working well enough to exchange DHCP
packets.  That would avoid the problem I observed that the signal
quality measurement was not yet accurate at that point.

With that call removed and with a script "wifi reconnect" attached to
the network.wifi.sta.bad event I can walk to the corners of my house
carrying the OVMS module and see it switch cleanly among my three APs.
See the attached log.

                                                        -- Steve

On Wed, 16 Dec 2020, Stephen Casner wrote:

> Following up: I see that OvmsNetManager::WifiStaGotIP() calls
> WifiStaCheckSQ() at the start of the connection, but it looks like the
> radio hasn't fully adapted yet or something.  The signal quality can
> be -95.5 -99.2 dBm and sometimes even -127.0 dBm, which looks like an
> uninitialized value, even though wifi scan says the RSSI is -60.  (Is
> RSSI calibrated to dBm for this system?)
>
> If I stop the looping by "wifi mode off" and "wifi mode client" then I
> see a good signal quality -79.3 reported after getting IP, and then if
> I do "wifi status" the reported signal quality is -56.0 dBm.  This is
> all with my test OVMS v3.0 sitting on my desk.
>
> So would it make sense to introduce some delay here if the signal
> quality is not good enough yet?
>
>                                                         -- Steve
>
> On Mon, 14 Dec 2020, Stephen Casner wrote:
>
> > On Mon, 7 Dec 2020, Michael Balzer wrote:
> >
> > > If you don't mind frequent disconnects in poor Wifi situations, a simple
> > > solution now is to attach a "wifi reconnect" command call to the
> > > "network.wifi.sta.bad" event. I added that command on the Wifi rework some
> > > months ago.
> >
> > I tested this today with the three APs in my home but ran into
> > trouble.  It looks like the event was emitted again at the end of the
> > reconnection process so another reconnect was performed and it kept
> > looping.  See the attached log.  I have not investigated this
> > carefully.
> >
> > > For a better, general solution, we could e.g. count the "network.wifi.sta.bad"
> > > events on the same network (or better: check the event frequency) and
> > > disconnect when reaching some (tunable) threshold. The next automatic scan
> > > then connects to the best network available. Getting stuck in the "bad signal"
> > > state for too long would also need to trigger a disconnect.
> >
> > I'll look at this further to see whether a smooth transition from one
> > AP to another on the same network is possible.
> >
> >                                                         -- Steve
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sq2.txt
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201216/5f69af49/attachment.txt>