Spark cores reset after EXACTLY one hour

I have two spark cores

both run the default tinker app and are breathing cyan

EXACTLY one hour after powering them up, they both restart themselves.

Any ideas why ?

note that the DHCP lease time on my router is 2 hours.

mhwlng, are these brand new cores or have you done a recent factory reset on your cores?

The cores are new, I received them yesterday…

I have done a factory reset

I have updated the tinker app from android

and I also updated the ti firmware to cc3000-patch-programmer-ti-patch-1.13.7

I powered the cores on one at a time or both at the same time

that made no difference

Just wondering how is the observation made for exactly 1 hour?

Try flashing ome new code and see if the same issue arises? :slight_smile:

I factory reset a brand new core and set pin D7 with android tinker and left it. No reset after several hours!

The DHCP Lease time of my router is 2 hours
DHCP Clients begin to attempt to renew their leases once half the lease interval has expired.
So the 1 hour interval is most likely related to that ?

Test :

I power on the spark cores. (breathing cyan)

I use tinker to set D7 LED to ON.

I wait EXACTLY one hour.

I observe the RGB led on the spark core

After EXACTLY one hour, the RGB led starts to flash for about 20 seconds, exactly like when you power it on.
I can see in my router logs, that a new DHCP lease has been requested. (just like when powering on the core)

Then the spark core breathes cyan again.

D7 LED is still ON.
I don’t know if that means that the core was never reset ?

I don’t know if the RGB flashing is ‘normal’ when requesting a new DHCP lease ? (and I mistook it for a reset) ?

I don’t know if the RGB flashing means that the network will be disconnected for 20 seconds every hour ?

Have never seen this behavior as we have people who runs their :spark: cores continuously for hours.

Maybe the best description would be:

I don’t know if the user() code continues to run but you can test and let us know :smiley:

Something like a blinking D7 led code and see what happens when the core asks for a lease?

I installed the flashing led application

it stops working for 20 seconds every hour, while the new DHCP lease is requested.

after that the led starts flashing again

@zachary,

this seems like an interesting issue we have not heard from other users.

How can we go about dealing with short DHCP leases?

I believe you’ve got the full picture here @mhwlng.

  • The Core does not reset when the DHCP lease expires, but it does drop off the network until it gets another lease.
  • I believe the loop() should continue to be called while getting a new DHCP lease, unless your code is waiting on some network activity.
  • After the Core is back on Wi-Fi, the handshake with the :spark: Cloud does block user code, but normally it does not take more than a second.

Can you try changing the DHCP lease time on your router to 90 minutes and see whether this changes the timing of the Core’s reconnection? What about a 4 hour lease time?

Here’s a code snippet that might be helpful in logging the times online and offline:

static bool wasConnected = true;
static int loopCount = 0;

void printTimeAndLoops() {
  Serial.print(Time.timeStr(Time.now()));
  Serial.print(" - # of loops: ");
  Serial.println(loopCount);
}

void setup() {
  Serial.begin(115200);

  // wait for Serial input to start logging
  while (!Serial.available()) delay(100);

  Serial.print("Setup called: ");
  printTimeAndLoops();
}

void loop() {
  loopCount++;
  if (Spark.connected()) {
    if (!wasConnected) {
      wasConnected = true;
      Serial.print("online ");
      printTimeAndLoops();
    }
  } else {
    if (wasConnected) {
      wasConnected = false;
      Serial.print("offline ");
      printTimeAndLoops();
    }
  }
}

When using your blinking led example (which doesn’t have any network functionality), the loop freezes for 20 seconds (i.e. the led stops flashing) every hour while a new DHCP lease is requested…

I don’t know if that is because the delay function calls some network functionality internally ?

I will perform the tests that you suggest.

I performed your test :

with DHCP lease time set to 90 minutes, the spark core now requests a new dhcp lease after 45 minutes.

Setup called: 19:06:46 # of loops: 0
offline 19:51:50 # of loops: 540767
online 19:52:14 # of loops: 656380

I did another test:

I added a delay (1000); at the end of the loop

to see if the ‘delay’ function is blocking when the network goes offline ?

Setup called: 19:58:27 - # of loops: 0
offline 20:43:33 - # of loops: 2695
online 20:43:57 - # of loops: 2698

the time difference between offline and online is 24 seconds
while the loop count only incremented by 3.

@mhwlng, FYI the delay() function will call SPARK_WLAN_Loop() while it delays. To your code, it looks like it’s blocking but the “background” firmware is being called. :smile:

I assume that the spark firmware also calls network functions between calls to loop()
That does not seem to be blocking when the network goes offline?

So I don’t understand why delay has to block ?

What is the difference between:
-network calls inside the delay function
-network calls between loop() calls

I also don’t understand why it has to take 24 seconds ?

if I do : ipconfig /release, ipconfig /renew on my pc. that takes 5 seconds.

@mhwlng, there is no difference between the calls. By definition, delay() is a blocking function in the user code. Spark just adds the background call so it dosen’t stall the cloud connection.

As to why it takes 24 seconds, @zachary may be better at answering that. The CC3000 module may play a part in that timing and wireless in general takes longer than LAN connections.

I understand that delay() is a blocking function by definition…

I meant why is it blocking for 20000 ms instead of 1000 ms

while there are no delays between loop() calls

p.s. I just switched my laptop on and it connected to the same wifi access point within 2 seconds.

Can I ask how you derived the 20ms?

I mean 20 seconds, not milliseconds (’.’ is thousand-separator in my country)

see test results in previous posts.

first test without delay : loop counter increments a lot in 24 seconds
second test with delay : loop counter increments 3 times in 24 seconds

Something else I noticed :

When powering on the spark, it only takes 5 seconds to connect to the wifi and the cloud and start running the loop() code. (so why the 24 seconds dhcp renewal ?)