<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
Steve,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 17.12.20 um 03:58 schrieb Stephen
Casner:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.9999.2012161831150.2315@auge.attlocal.net">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Mon, 7 Dec 2020, Michael Balzer wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I'll look at this further to see whether a smooth transition from one
AP to another on the same network is possible.
-- Steve
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>