Photon losing cloud connection after multiple wake from sleep cycles

Troubleshooting
1

On a battery powered photon I am putting the device into sleep thus
System.sleep(wake, CHANGE, param.sleepPeriod);

The device wakes every param.sleepPeriod seconds or when the button attached to wake pin is pressed.

if (pinReadFast(wake) == HIGH)
{
    tft.exitSleep();
    hangOn(200); 
    runState = waking;
    isTriedConnectOnce = false;
    if (!Particle.connected() && !isTriedConnectOnce)   //V081/V118
    {
        Particle.connect();
        isTriedConnectOnce = true;
    }
}
else
{
    tft.exitSleep();
    isTriedConnectOnce = false;
    runState = wakefrompowersave;
}

In the controller function that handles wakefronpowersave:

if (!Particle.connected() && !isTriedConnectOnce)
{
    Particle.connect();
    isTriedConnectOnce = true;
}

This then publishes an event and waits for a timeout period (15 seconds) then goes back to sleep if no cloud function has been received to wake as per the button press.

This works for a while (I have not built up from more than 10-15 minutes of cycle) but then I find that both the wake cloud function and the button press interrupt do not re-connect to the cloud. I thought Particle.connect() restarts the WiFi module (which would have been switched off by sleep) or is it that Particle.connected() is returning true when it is not connected?

2

What system version are you running?

3

0.6.3 with SYSTEM_MODE(SEMI_AUTOMATIC) and SYSTEM_THREAD(ENABLED)

4

Are you using a lot of heap space (e.g. via extensive use of String)?

How does this manifest?
Does it not even try to connect or does the LED blink but the device never make it to the cloud?

However, you have the device that misbehaves. Try adding some debug output to your code to check all the relevant factors that might contribute.
When you say ...

... why not check that in your code (e.g. via Serial.print())?

1 Like
5

@ScruffR, Heap space usage - I have a Cloud Var with system.freeMemory() this is stable over long periods, so not a heap memory loss issue. You have helped me with that one elsewhere before!

It manifests as flashing green LED after a wake from sleep which although it has the wifi credentials and the WAP is available never manages to connect to wifi and thus not to the cloud either.

I figured that after exit from sleep that I could call WiFi.on() before Particle.connect() - this seems to have solved the problem. I thought that Particle.connect() turned on the wifi module but perhaps this doesn’t always happen after cycling many times through sleep and wake (the device sleeps for 3 minutes and wakes and listens for 15 seconds).

Regards using Serial.print() - a small oversight in the PCB design means that it is not possible to plug into the micro USB socket when it is installed in the device! This was my first proper device.

1 Like
6

I have no proof (or wasn't really searching) but I also had the impression that Particle.connect() used to turn on the radio implicitly, but for several system versions now this doesn't seem to be the case anymore.
However, the intended behaviour of System.sleep() should be that the system reestablishes the exact same radio/cloud status as the system was in before going to sleep. Hence if you didn't switch the radio off before going to sleep it should be switched back on after wake.
But I know there were issues with exactly that behaviour in older versions and I'm not sure whether 0.6.3 has the fix in it already.
Could you try 0.7.0-rc.6 for that reason? (don't try 0.8.0-rc.1)

7

@ScruffR, This is what I was thinking of in the reference documents. To be fair, it does not say turns on wifi module.

Particle.connect() connects the device to the Cloud. This will automatically activate the Wi-Fi connection and attempt to connect to the Particle cloud if the device is not already connected to the cloud.

I am not switching the radio off before sleep and assumed that System.sleep() handled turning the radio off and back on.

I have devices out in the field so I am not going to use a RC version - unless you know that 0.7.0 is about to launch!

8

I didn't mean you should deploy that to production units, but it might still be advisable to test RCs against your own use cases on a bench device to have a chance to either see that a current issue will acutally be cured in the next release or to file any found issue to be repaired - maybe even before official release.
Just hoping the next official release will actually do what you expect, just to find out "not quite", is another missed chance.

e.g. I have before successfully filed issues that were severe enough to postpone the release and call for another RC which actually fixed them in the next or following sprint.