B4R Question WiFi connection time odd behaviour?

[BertI]

I seem to spend my time hitting idiosyncrasies .. or is it just my interpretation? In this case I spent an afternoon trying to work out why two pieces of similar code took very different times to make the WiFi connection (ESP8266). In the end I found that it was because one of them had a short delay before the procedure which performed the connection and that the culprit in the latter was a wifi.Disconnect statement. To clarify this here is some code I wrote to test the behaviour:

#Region Project Attributes
    #AutoFlushLogs: True
    #CheckArrayBounds: True
    #StackBufferSize: 300
#End Region

Sub Process_Globals
    'These global variables will be declared once when the application starts.
    'Public variables can be accessed from all modules.
    Public Serial1 As Serial
    Private wifi As ESP8266WiFi
    Private stim As ULong
    Private etim As ULong
End Sub

Private Sub AppStart
    RunNative("StopPersistent",Null)    ' no effect on connect time issue if taken out
    Serial1.Initialize(115200)
    Log("AppStart")
 
       Delay(500)            ' if delay is more than a few 100ms then connect time nearly doubles
 
    wifi.Disconnect        ' this appears to be the cause of the issue.
                        ' Use If wifi.Isconnected to avoid unecessarily calling it
       stim = Millis
      Log("Start connect time = ",stim)
    If wifi.Connect2("xyz","12345678") = False Then
        Log("Error connecting to network")
        Return
    Else
        etim = Millis
        Log("End connect time = ",etim)
        Log("Connected to network")
    End If
    Log("Time taken = ",NumberFormat((etim-stim)/1000,0,2),"s")
End Sub

#if C
  void StopPersistent(B4R::Object* o) {
  WiFi.persistent(false);
  }
#end if

The 'StopPersistent' sub does not appear to have an impact on the behaviour but I thought to leave it in incase anyone finds it useful to experiment with (it's supposed to stop WiFi details being automatically written to Flash each time you connect or disconnect but frankly I don't know that it actually does anything and am a bit sceptical about Flash being worn out if you are writing the same values to it each time as usually the lower level code (and maybe hardware even) doesn't erase if the same data is to be re-written).
Anyhow... If I run the above code with the correct credentials for my router it typically takes about 14-15s to connect (if the Delay parameter is 500ms or greater). If the Delay is less, e.g 100ms, then it takes about 7s. In the end I found that the 'problem' was caused by the wifi.Disconnect statement. If you gate this by using something like: If wifi.Isconnected Then wifi.Disconnect then the long connect time issue is resolved. However it begs the question - why should using wifi.disconnect when you are not already connected have behaviour which depends on time after reset?

I don't expect there will be an easy answer to this, so although I've posted in the questions area I guess this might best be considered an observation and something for others to be aware of.

 

[KMatle]

If I get you right: Just do a loop arround wifi.connect2 (5 times is enough) and leave it when connected. My Esps often do not connect on the first time, too.

 

[BertI]

No, it's not that it doesn't connect first time, it's just that I found it strange (and undesirable) that a delay before executing wifi.Disconnect then had an adverse effect on the connection time. To most people this will be of 'academic' interest but in my case I'm always keen to minimise connection or reconnection time, which is probably why I noticed the issue at all. However I also always feel very uneasy about anomalies because until you understand the cause you never know where the underlying mechanism might come back to bite you later. In fact I don't actually know whether it is even necessary to do a wifi.Disconnect before attempting to connect (e.g. in case was already connected but in some kind of stuck state perhaps). Just happened to see this procedure elsewhere and copied blindly

BTW in this example I'm just using DHCP, however to get even faster connection times one method is to force a static IP. In my environment this takes the time down from around 7s to typically less than 1s.