When using self controlled wireless, recommendations for identifying wireless failures

I currently have the following function:

function blockUntilConnected() { server.setsendtimeoutpolicy(SUSPEND_ON_ERROR, WAIT_FOR_ACK, TIMEOUT_WIFI); /* Configure with the server every time we connect (required) * This call will force an automatic wifi connect, since we've changed the * send timeout policy to SUSPEND_ON_ERROR (automatically connect). * * This call will block until complete, or the imp will go to sleep if it fails. */ imp.configure(DEVICE, [], []); }

But I want to obtain the failure to connect reasoning as is available with server.connect() to better debug if my Imp’s inability to connect is due to lack of signal, dhcp issues, or other. Is there any possible way to obtain that without using a callback functionality and use the blocking nature of imp.configure instead?

Ideally the imp.configure could/should return null OR the numerical value as is passed to the callback from server.connect.

Because the policy is SUSPEND_ON_ERROR, it will suspend (which results in a warm boot for retries) vs returning, hence no error code is available.

Is there a reason you are needing to do a blocking connect vs non-blocking with a callback that continues your “post connect” data flow on successful connect?

This function came from sample code provided by your team, which have been a big help. The main reason we are using the blocking code segment is to avoid a potential race condition that occurs because the non-blocking will not fire the callback if already connected. (race condition between the check for server.isconnected() and server.connect() execution).

If you want to avoid race condition, and always execute the callback (even if it’s already connected), you want something like this:

`server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_TIL_SENT, 30);

function onConnectedCallback(state) {
// if we’re connected
if (state == SERVER_CONNECTED) {
// do something
} else {
// do something else?

function Connect(callback, timeout) {
// check if we’re connected before calling server.connect()
// to avoid race condition
if (server.isconnected()) {
// if we’re already connected execute the callback
} else {
// otherwise, proceed as normal
server.connect(callback, timeout);

Connect(onConnectedTimeout, 30);`

Edit: I changed the code a little bit to make it more generic.

The concern with the provided code though is that if the thread preempts between the .isconnected() check and the (assuming false was returned) the server.connect() and another execution code does trigger the connect, then when the thread is active again, the server.connect will not execute the callback. Since there is no transactional guarantee that the code execution will be coupled - I am concerned of entering a state that skips the callback due to this.


Squirrel code can’t interrupt other Squirrel code (it can only queue something to be executed next)…

When RETURN_ON_ERROR is in effect, and the device disconnects from the server (for whatever reason), the only way it can reconnect is with an explicit call to server.connect().

Because of these two things, I don’t think there is a case where the Connect function could be preempted, and cause the onConnectedTimeout function to not execute.

…you can also keep track of an issued connect (eg “isconnecting=true”). As Matt says, squirrel is single threaded; you cannot be pre-empted by other squirrel.

Some things can happen asynchronously to the squirrel thread, though. If, for example, isconnected() returned true, but (on a system thread) a disconnect happened before the server.connect() was called, then you’d get a queued onunexpecteddisconnect callback.

Hence: you need to register your callbacks at the top of your code.