Hello all! I finished some experiments with Manual mode on the Core, and decided to post my (somewhat interesting) findings. For what it’s worth.
You can call WiFi.connect() without calling WiFi.on() first.
Reading WiFi.RSSI() without turning WiFi.on will result in a hard fault. (Interestingly, reading WiFi.SSID() simply returns an empty string.)
WiFi.connecting() will return 1 (TRUE) even if it is NOT connecting. As in: WiFi.on() -> (WiFi.connecting = 1). The value goes to FALSE after it is connected.
If WiFi is not connected, WiFi.hasCredentials() returns 0 (FALSE), even if credentials are stored! As soon as WiFi.connect() is called, it returns 1 (TRUE). It remains TRUE when connecting goes to FALSE (I.E. connected)
WiFi.RSSI() will return -127 if not connected to WiFi. This is due to the low-level wlan_ioctl_get_scan_results call, which does not return any SSIDs until the WiFi.connect() call has been made.
NOTE: WiFi.connect() only blocks for about a second; user code continues to run while the connection is negotiated.
NOTE: WiFi.listen() is 100% blocking. Call it, and you might as well have instructions on your product box, “Press Reset if this mode was entered by accident.” In wlan.h, there are definitions for extern INT32 wlan_smart_config_start(UINT32 algoEncryptedFlag); and extern INT32 wlan_smart_config_stop(void);. Ah yes, I know…the Core is deprecated anyway, so never mind ;-).
you can call WiFi.connect() without calling WiFi.on() first.
The intent is that functions that get the system in a certain state don’t need any prerequisties (to make it simple and unambiguous).That’s why WiFi.connect() works without WiFi.on(). The same should be true of Spark.connect() also!
Reading WiFi.RSSI() without turning WiFi.on will result in a hard fault. (Interestingly, reading WiFi.SSID() simply returns an empty string.)
Fortunately this is fixed in the upcoming 0.4.x release.
WiFi.connecting() will return 1 (TRUE) even if it is NOT connecting. As in: WiFi.on() -> (WiFi.connecting = 1). The value goes to FALSE after it is connected.
Great catch! I’d noticed this just a few days ago, and added a new internal flag (WIFI_CONNECTING) so that we can distinguish this state correctly.
If WiFi is not connected, WiFi.hasCredentials() returns 0 (FALSE), even if credentials are stored! As soon as WiFi.connect() is called, it returns 1 (TRUE). It remains TRUE when connecting goes to FALSE (I.E. connected)
I believe this is fixed in the 0.4.x release. Also we have a new option - WiFi.connect(WIFI_CONNECT_NO_LISTEN) that specifically instructs the device not to enter listen mode.
WiFi.RSSI() will return -127 if not connected to WiFi. This is due to the low-level wlan_ioctl_get_scan_results call, which does not return any SSIDs until the WiFi.connect() call has been made.
Interesting result. I wonder if that is the correct value to return,or if it should instead return an error code (a positive number.)
You’re perfectly correct that WiFi.connect() only blocks while the device connects to the AP. DHCP resolution is performed asynchronously, which is why WiFi.ready() doesn’t return true immediately after WiFi.connect() returns, but becomes true a few seconds later, once the IP address has been assigned.
Mathematically, that is correct. Because the wlan_ioctl_get_scan_results call returns a (somewhat) zeroed array until WiFi.connect() is called, the mathematics _returnValue = ((wlan_scan_results_table[8] >> 1) - 127); will return (0 - 127), or -127. Whether that should be an error code is entirely up to the Particle team!
Yes, I’m aware of adding error traps on functions for even some of the dumbest situations—and programmers end up trying to find a balance between a padded cell and a tightrope walker.
@mdma , Also could you confirm if you’re looking at the case where under MANUAL mode after a cold power up (at least 2 minutes unpowered), WiFi.connect() and/or (client.connect( server, serverPort)) fails to connect? I can’t tell which exactly, though the tcp connect function seems the likely fail. A simply push of reset button restores the functionality.
I posted an issue #580 previously but I’m not knowledgeable enough to know if I conveyed the issue clearly.
Thanks
