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? 
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 
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 
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
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
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. 
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 ?)