Dropping the connection to spark cloud

I think any code that uses any sort of blocking process will drop the connection quicker. I’ve noticed I2C use absolutely kills the connection.

When will the fix on github be picked up by the web firmware loader ?

BTW - my core has been up now for over 2 days solid - sods law isn’t it :slight_smile:

1 Like

I’m testing firmware with the Set_NetApp_Timeout() fix right now.

Longest I’ve ever run without failure before is ~18 hours, I’ll report back in 24.

For those who are trying to manually fix this issue, get the latest master branch of both “core-common-lib” and “core-firmware” before building and loading the firmware onto the Core. The fix should also be made available soon via the cloud server.

1 Like

Sadly, the single Set_NetApp_Timeout() fix does not fix the Cyan Flash Of Death.

I now plan to try and probe the SPI bus between the STM32 and the CC3000 and see if that yields any clues.

I can confirm that picking up all the fixes from the current source tree (assuming they are in master, as they are supposed to be) does not fix this problem (aka CFOD.) Behaviour is unchanged.

Will probe up SPI bus later today - I fear the biggest problem will be finding a useful trigger for the analyser.

SPI bus analyser shows that after CFOD, the SPI bus is idle.
No interrupts from CC3000, no polling status by the STM32, no activity whatsoever.
More news as I get it.

1 Like

OK - I have at least one failure in captivity, with 8 Sec of SPI traffic before the failure and 4 Secs after. More news as the trace is analysed…

1 Like

Hmm, I have been having rather mixed results with my Spark Core. I just hooked it up to my Freetronics LCD shield, and successfully had it running for about 5000 seconds.
Anyway, whilst pondering in my awesomeness, drifting away at the seconds counting upwards… the wife started defrosting some meat in the microwave.

Instant drop to the core! Like almost the entire time the microwave was on, the spark was losing connection to the internet! Now, either my microwave is emitting some harmful badness to the living area, or perhaps the spark is super sensitive on the inbuilt antenna? Anyone else using a microwave nearby?

-KegRaider.

How old is your microwave? This isn’t uncommon on older or cheaper units. They emit radiation all over the 2GHz spectrum, which is in fact the frequency they cook at!

I use my Core across the room from a several thousand watt 4 year old Kenmore unit with no issues. Try changing your wifi channel or enabling “Adaptive” / “Spread Spectrum” / “Interfearance Robustness” modes on your router!

1 Like

That is just one of many interferences that will cause the connection to drop. Which actually can happen all the time without the user knowing, but the recovery is what is critical here. For any implemented application to work over a long period of time, the core cannot suspend the application to wait for a reconnect. The reconnect task should happen in the background, so that when your heating up a burrito it does not take down your core.
I am in a commercial environment and there are a lot of access points around and many for the same SSID, i know the core is trying to switch to other AP’s on the same SSID but typically fails then waits around untill a successful reconnect. Meanwhile the application is not running…

@dmarten, a fix for your application running while the Core is re-connecting is implemented if you want to play on the bleeding edge:

My core (still running original firmware and simply temperature reading app) has been up now for over a week.

It could be that it’s never lost connection in that time but I reboot my dd-wrt router automatically every day.

I would add to this though that I’ve just queried the temperature through the cloud API and the return was nonsense - as if it’s not actually been reporting (although you’ll notice it does know it’s there) …

{
  "cmd": "VarReturn",
  "name": "temperature",
  "TEMPORARY_allTypes": {
    "string": " \u0000P\u0000",
    "uint32": 536891392,
    "number": 536891392,
    "double": null,
    "float": 1.0868491504456741e-19,
    "raw": " \u0000P\u0000"
  },
  "result": " \u0000P\u0000",
  "coreInfo": {
    "last_app": "",
    "last_heard": "2014-01-15T22:41:48.120Z",
    "connected": true,
  }

I’ve reprogrammed it and its back correctly -

{
  "cmd": "VarReturn",
  "name": "temperature",
  "TEMPORARY_allTypes": {
    "string": "\u0000\u0000\u0003�",
    "uint32": 948,
    "number": 948,
    "double": null,
    "float": 1.3284309441799266e-42,
    "raw": "\u0000\u0000\u0003�"
  },
  "result": 948,
  "coreInfo": {
    "last_app": "",
    "last_heard": "2014-01-15T22:45:09.033Z",
    "connected": true,
  }

Hi. I too am having this issue. I was looking into the AP side of things, and confirming that in the flashing cyan state, I could still see the core attached to the AP. Also have a simple flashing LED app.

I had a question. How do we know what version of the cores firmware we are running, so that I might know when there is an update that will fix the flashing cyan issue?

1 Like

It's not exposed. There are a couple of other posts about this. Here's one:

https://community.spark.io/t/programmatic-access-to-firmware-version/995

Hello everyone,

Someone please help me out,

I’ve two cores with me and both of then aren’t getting connected to the cloud they are only flashing cyan, I tried many times but still it’s the same situation? Can Someone tell me what the problem could be?

I’ve even applied CC3000 patch also to both of them.

Thanks in Advance

Hi @anirudh,

I’m not sure if someone has suggested this yet, and this is certainly not obvious, but have you tried updating the keys?

Grab your core IDs with: https://github.com/spark/spark-cli#spark-identify

And then you can update your keys with: https://github.com/spark/spark-cli#spark-keys-doctor

Thanks!
David

I’m not sure if reviving the topic is better than starting a new one, but seems like this problem still hasn’t been solved. I’ve just bought a photon, and I’ve succeeded in claiming it, flashing the “blink” app to it, and all. When powered-up, the photon will quickly go to the “breathing cyan” in a second or two. Unfortunately, it disconnects from the cloud intermittently and goes to the “flashing cyan”. Than goes back to breathing cyan for a few seconds. Etc. This never ends. I’ve tried a computer power source, as well as a power pack. The firmware is 0.4.9. And, basically, it’s in practice disconnected from the cloud most of the time. It’s mostly still available on the LAN though (ping will find the device about 9 out of 10 times). I’ve got a good router with other devices that are on 24/7 and do not disconnect constantly. Needless to say that, with this problem, successfully flashing a program on the photon is a rare and happy event.

Where lies the flaw? It is because the photon wifi hardware is of poor quality? Are the Photon Cloud servers overloaded/difficult to reach? Or could this be eventually fixed by a future firmware upgrade? Is anyone working on this? I planned to use the photon as a remote data sensor, but because of the brittleness of its connection, I’m not sure I can use it. And even worse, when the “cloud disconnection” happens, the device stops executing the program-- so I can’t even workaround this by buffering the data values and transmitting everything in the (too) rare connected moments…

Or maybe there’s a solution and I’ve not stumbled on it yet.

Help?

As for the blocking when connection is lost, SYSTEM_MODE(SEMI_AUTOMATIC) and/or SYSTEM_THREAD(ENABLED) might help with that.