Sleep[STOP] is intermittently missed and millis() wrong with Argon

I am working with an Argon in a solar powered audio artwork. The device sleeps for a minute between actions using System.sleep(D2, RISING, 55) and every hour or so a system status will be published. Occasionally the sleep seems to ‘skip’ completely, ie it appears to go to sleep (LED off) but immediately restarts. The miilis() reported at these times jumps by the the sleep duration.

Is this a known issue? Any workarounds? Am I doing something wrong?

Below is some minimum code that shows the problem. This code sleeps at 1 minute intervals (the sleep duration is adjusted for each interval to get close to 60 secs and is usually 55 seconds. Every 5 sleeps (= 5 mins = 300 secs) the current value of millis() and a synchronised cloud time is published and captured with node-red. The following table summarises a couple of hours operation. The red numbers are where the difference between millis() and Time.now() vary significantly. This is generally the same or less than the sleep interval. the behaviour observed on the serial monitor supports the numbers with the millis value of the logger jumping 50 secs in a few secs across the break in serial connection when the argon sleeps. The jumps don’t appear to coincide with publish events.

The final code is far more complicated and the intermittent problem seems to be causing flow-on effects elsewhere that I haven’t yet diagnosed.

Thanks!

[edit] OS is 1.1.0

int sleeps = 0;
unsigned long wakeAt = 0;
char publishString[64];

SerialLogHandler logHandler(LOG_LEVEL_INFO);

SYSTEM_MODE(SEMI_AUTOMATIC);        // connect to cloud when requested

void setup() {
  Serial.begin(9600);
  delay(3000);
  Log("starting up");
}

void loop() {
  if (millis() - wakeAt > 5000) {  // do nothing for 5 secs
    if(sleeps % 5 == 0) {   // every 5 sleeps publish something (should be every 5 mins +/- a few seconds)
      Log("publishing");
      WiFi.on();
      Particle.connect();
      if (waitFor(Particle.connected, 30000)) { 
        Particle.syncTime();
        waitUntil(Particle.syncTimeDone);
        uint32_t report = Time.now();
        sprintf(publishString,"{\"devicems\": %li, \"epoch\": %li}",wakeAt, report); 
        Particle.publish("SLEEPTEST",publishString, PRIVATE);
        Log("published %s", publishString);
        Particle.disconnect();
      }
    }
    sleeps++;
    int sleepFor = 60 - (millis() - wakeAt) / 1000;
    Log("sleep number %i for %i secs", sleeps, sleepFor);
    System.sleep(D2, RISING, sleepFor);  // sleep so that 60 seconds between waking 
    wakeAt = millis();
    delay(3000);   // time for serial to reconnect
    Log("woke from sleep at %li", millis());
    if(System.wokenUpByPin()) connectForUpdate();
  }
}

void connectForUpdate() {    // connect to cloud for firmware update
  Log("woken from sleep by pin");
  WiFi.on();
  Particle.connect();
  while(true) {
    Particle.process();
  }
}

Summary

This text will be hidden

Interesting, I've seen similar but never tracked it like you have. There's some known issues with Argon sleep, might want to disable until they get resolved. Perhaps the fix to that would also resolve your issue.

What is a known ‘feature’ is that the RTC on the Gen3 devices is really not that reliable or accurate. I have a small mesh network of sleepy end-nodes (Xenons) and I have had to add an external RTC (DS3231) to each so that the time stamping of mesh publishes is correct - otherwise it is all over the place - faster then slower, I am still using the device clock to do the wake from sleep and not the RTC interrupt and I haven’t see it miss a sleep cycle.

Hmmm, yes a ‘feature’ @armor . The accuracy isn’t a concern for this application, but the reliability is. I will be using the Argon as the gateway for a sleepy mesh of Xenons. Hoping to avoid the cost and complexity of RTCs.

You may not notice the skipped sleep cycles (and it took me days to track it down to that), although I guess it should show as unexpectedly early time stamps on your publishes. In my case the project is audio so the unexpected silence (which is key to the artwork) was absent.

Thanks @Fragma. Unfortunately I am on a tight deadline and relying on the sleep function to conserve energy. I haven’t noticed the high power consumption during sleep that you observed.

Correction @Fragma, I have noticed this high power consumption!! When driving the Argon with a bench top power supply (which shows the current) it was indeed running at 80 mA once the first Particle.connect was established and after the Argon had gone to sleep. In my case it was rectified by adding the following lines prior to the sleep command, thus ensuring that the Argon was actually shut down.

        Particle.disconnect();
        waitUntil(Particle.disconnected);
        WiFi.off();
        Particle.process();
        delay(4000);

I’m not sure that the waitUntil, particle.process or delay were all needed, but better to be safe. This was, of course, with SYSTEM_MODE(SEMI_AUTOMATIC). Hope this helps your situation. It doesn’t fix the intermittent skipped sleeps I am experiencing.

Andrew

Thanks, I’ll give that a try

@AndrewS, @Fragma, it seems there is an issue:

3 Likes

Thanks @peekay123, I take it that means the issue is being addressed (with an ugly fix so far). When might this make it through to a release OS ? Days or weeks?

I suspect the Serial1 issue mentioned is also causing my other problems, but I seem to have eliminated that by using Serial1.end() before sleeping.

Andrew

Perhaps using one of the RTC Featherwings will do the trick?

or https://www.adafruit.com/product/2922

1 Like

Hi guys! I am experiencing the same issue with Argon and Device OS 1.4.4. I looked over the community but I couldn’t find any recent information on this case. Are you familiar with what is causing it and is the only solution to turn off the wifi manually with wifi.off(). Even with wifi.off() I am getting around 500 microamps of deep sleep current(with the xenon its around 800 nanoamps).

Yep, I’m still seeing the same issue but manually turning off wifi before sleep and back on after sleep does work.

I’m still experiencing this bug in 1.5.2. Anyone know if it will be fixed in device OS 2.0?