Reliability of Spark Core for WiFi and Client.Connection()

We have deployed our first pilot build on top of Spark Core, to constantly measure the power consumption of small scale fabrication industry. We use Wi-Fi 3G dongle to connect the Core. Basically this measures the current sensor and send the data to my cloud ( using http GET ) for every two minutes. All of sudden the data is missing , the Core stop posting the date to cloud. There were two behaviors observed…

  1. The breathing cyan : This means the Core is connected to WiFi but clinet.connect() is keep failing , in this scenario the Core recovers from 5 min to 35 minutes , and posting data , so we are missing the 35 min. of data…

  2. The blinking blue: This is bit odd and show stopping case, core is not recover back and we had to switch-off and On the device again… than core is recovering.
    But the above both stages , we checked the WifI and internet connection, which is fine and we able to browse the net as well as able to send the data to my cloud, through other device ( Which we build on bare CC3000 + Arduino)
    Please help me , how to solve this problem.

The code snippet looks like this…

 String uriTempString = "GET /IndriynEnergyService/api/IndriynPower?strPostObj="; 
TCPClient client;
while (!client.connect(server, 80 )   // till  you get the connection 
    if (client.connected()) {
        Serial.println("Connected !");
        client.println(" HTTP/1.1");
        client.print("Host: ");
        client.println("User-Agent: mywebsite");
        //client.println("Connection: close");

small correction : It is NOT “The blinking blue”, please read as “It is breathing blue”…

I had the breathing blue issue just few hours back and the only difference is due to me running the core off the school hostel network and the traffic is just atrocious such that connecting to the spark cloud becomes an issue,

It might be challenge to run it off the Wifi dongle as for as i understand where the pace you live in, internet might become intermittent randomly.

Just a quick question, is the core patched with the latest CC3000 firmware?

If internet stability is an issue, you might consider storing the data on your Core first, perhaps using the awesome SD/FRAM shield by @kennethlimcp. If possible you could then reverse the data flow, so instead of polling the Core for data, you could push it to the server (using SSE perhaps, or some other fancy stuff). This way you’d make sure no data is lost when the connection falters, and you could check for a decent server connection before posting the data, which should definitely increase the chances of it actually making it to the server.
Anyhow, this is just a random thought, I’m not sure if this is feasible or a logical way to do it, but I thought I’d throw it out here anyway. Good luck!

Thank you Moors,

I am doing the same with local buffer, I am taking 50 values in local buffer and send once and than clear the buffer and doing the same for every. But these application demands real time data to act on. up to 5 min delay itself not acceptable. and the issue don’t seem to be WiFi, since WiFI is working good there…


I don’t think this is the most reliable way to flush data returned to you from the server. I like having two while loops with timeouts, the first loop waiting for client.available() and the second loop reading data until client.available says no more data. If data builds up it can cause you problems.

Thank you bko ,
The Data I am receiving from server is just simple acknowledgement and I am not using. I will include the code to read the message and than flush it.
We thought through this two loops but, we ended up thinking of multithreaded programming( using two loops simultaneously ) in Spark Core, which we do not know… Can you help me , how the code looks like. Could you write some steps for me, would be great hep.

Or Is it a good Idea to use HTTP Client Library , instead of writing my own code?


Hi @spaksiva

There is another thread with a fellow with similar problems here:

He switched his code to be more like this and it worked better but still had some problems:

  unsigned long startTime = millis();
  while (client.available() == false && millis() - startTime < 1000) {
    // Just wait up to 1000 millis
  startTime = millis();
  while (client.available() > 0 && millis() - startTime < 1000) {;
1 Like

Thank you bko,

I implemented the same to my Core, It works better on high speed internet , If I switch to mobile 3G based dongle for 10 feet, it just sends one message and hangs ( breathing but not sending any data) …
Your links are useful and I am going through and experimenting various options…