Dropping the connection to spark cloud

I have some weird s**t going on. I have a core currently plugged into a relay board fed from a 12V 5A power supply

Firstly, the spark core will not program more than once without manually entering bootloader mode. It has been doing this all day, from the demo led flasher to something slightly more complex.

Next, the following knuckle-dragging code resets the board at the end of the loop. This is evidenced by the main led flashing green, then flashing cyan, then breathing cyan. Also the setup code runs. This happens at the end of every loop.

If I change the rly_on_time to be 100, the program runs a lot quicker, but runs without problems. Also the core can be remotely programmed without forcing bootloader mode.

The latest is the board has difficulty entering bootloader or factory reset modes. Currently the web IDE gives me an error 400 when i try to flash the device.

Thoughts?

// A short routine to walk through the relay board

int pin_rly1 = D0;
int pin_rly2 = D1;
int pin_rly3 = D2;
int pin_rly4 = D3;
int Led_out = D7;

int rly_on_time = 1500;

void setup() {
pinMode(pin_rly1, OUTPUT);
pinMode(pin_rly2, OUTPUT);
pinMode(pin_rly3, OUTPUT);
pinMode(pin_rly4, OUTPUT);

pinMode(Led_out, OUTPUT);
  // signify the program has booted - light the blue led
  digitalWrite(Led_out, HIGH);
    delay(900);
  digitalWrite(Led_out, LOW);

}

void loop() {

for (int i = 0; i < 5; i ++)
  // we are going to walk through the relays 5 times
{
  digitalWrite(pin_rly1, HIGH);
    delay(rly_on_time);
  digitalWrite(pin_rly1, LOW);
  
  digitalWrite(pin_rly2, HIGH);
    delay(rly_on_time);
  digitalWrite(pin_rly2, LOW);
  
  digitalWrite(pin_rly3, HIGH);
    delay(rly_on_time);
  digitalWrite(pin_rly3, LOW);
  
  digitalWrite(pin_rly4, HIGH);
    delay(rly_on_time);
  digitalWrite(pin_rly4, LOW);
}  
digitalWrite(Led_out, HIGH);
  delay(900);
digitalWrite(Led_out, LOW);

}

Hey everyone - thanks for sharing all the debug info. We’re doing some testing on our side as well to figure out exactly what’s going on, but we haven’t yet got this one figured out yet. Keep the info coming!

On further testing, things start to play up if I change the rly_on_time to be 500. It works 2 out of 3 cycles. At this value the core can still be flashed easily by the web IDE.

At rly_on_time = 450 it seems to be quite stable.

@nil_orally You’re experiencing a bug where user code with long delays blocks the Core-to-Cloud communications. See here:

We’re working on a fix for this, but in the meantime if you keep your loop() short (no more than a few seconds), that should resolve your issues.

Thanks Zach. That’ll teach me to be lazy!

No worries @nil_orally! Just created a new thread for your issue:

In my case it fails running tinker. So excessive delays are not my root cause.

Yep, that mention of delays and blocking code was specifically for @nil_orally

Not picking a fight, just keeping the torch alight for whatever problem gets tinker wrapped around the axle :slight_smile:

Just chiming in to say that I’m having the same problem with both the cores I’ve tried. One is running Tinker and the other is running a simple bit of code to fade the RGB LED (with a 3 second delay in between)

Both Cores will lose connection with the Spark Cloud and display a blinking cyan light. They don’t both lose their connection at the same time so I don’t think it’s an issue with my wifi (multiple Apple Airport Extreme APs using the same SSID) and the time between losing the connection is not predictable. They do not reconnect without being reset either by power-cycling or by pressing the reset button. When reset they reconnect instantly.

Any update on this issue? I’m monitoring two temperature sensors and have added an “uptime” variable (which I’m polling from a Python data collection script along with the temperature values.) I have a maximum uptime record of 102 minutes over the course of several days (which entails me noticing that the core is blue-flashing-of-death and then resetting it.) I usually get about 30-45 minutes of runtime before it hangs, but sometimes I get as little as 6 minutes (my polling cycle is 1 minute.)

Upon resetting the core, it usually connects back up within a few seconds (maybe 10 max?), but one time it had only the built in D7 LED lit and was unresponsive - requiring a factory reset to resolve.

I’ve been hoping to collect several days worth of data, but all I’m doing is wearing a path in my carpet resetting the core.

Since collecting my temperature data hasn’t been very fruitful, I am going to load a simple sketch which exports the “uptime” and let my script poll that to see how it does. Just as a data point, I was having the blue-flash-of-death running just the blink sketch overnight. I’ve been careful not to put delays in my code. I’ll post back with what I find.

Dave O

1 Like

Still top on our list, but we’ve been slow on development during the holidays; will get to it most likely this week, or next week at the latest.

I have the same issue. However I have two cores (currently in use, both with chip antennas). One of the cores is fine, the other does this ‘flashing cyan’ after a few hours of being online.

Hours! I’m happy if mine run for some minutes!

But I have faith: They have done such a great job so far! They will fix it!

Just got the cores! Looks promising…
But it also looks like i have this same issue… a simple blinking LED sketch will eventually ‘reset’ and go back to flashing cyan. pressing the reset button will get it there much faster, but i was planning on embedding the module where it would be difficult to press a button.
I did not realize that verification/handshake did not occur in the background. having the unit suspend the loaded program and wait around until a reconnect will not be ideal for most of the applications i had in mind. Hopefully this will be addressed. The priority of the local application should be higher than the reconnectivity of the cloud connection.

When connectivity is lost and then reconnected, does the local sketch restart from the beginning, or was it suspended and continues on from where the disconnect occurred?

Once the spark goes into the blue-flash-of-death, only a physical reset (i.e. press the RESET button) will get you re-connected. If the spark actually re-connected on its own, this would be much less of a problem (for my application at least.)

Dave O

If you are looking for someone to test something out, please let me know. I don’t have a JTAG shield, so I’m perhaps not the best candidate, but still happy to give it a go if needed.

Dave O

1 Like

Just throwing this out…my arduino with Wifi shield was doing this exact same thing. In fact, it looks like I have the same router that the screen capture was taken from.

I went into my router and changed from N/G/B to g/b only and it cleared everything up and my CORE is running with out dropping the connection either.

2 Likes

We’re still working on a fix for this bug where the core doesn’t always reconnect on its own, we will post updates here when we can.

I’m looking forward to the bug fix(es). Right now I only get about 10 minutes of use before the connection drops and it gets stuck in flashing cyan. I have a wide variety of Arduino+WiFi devices, and all of them but the Yun suffer from terrible connection drop problems that make them effectively unusable for embedded applications. What’s the point of having a wireless sensor that stops transmitting data 10 minutes after it’s installed? Spark Core has the perfect form factor and capabilities for a lot of projects, but it has to be rock solid. The bad news is that it’s currently the least reliable wireless device in my drawer full of unreliable wireless devices. The good news is that it’s still in active development, so I will keep my fingers crossed that this little guy who has once again gone from running my code to blinking cyan at me in the time it has taken to write this message will eventually be ready for production use.

1 Like