core cannot be discovered neither by Android not iPad nor iPhone
telnet device.spark.io 5683 proves there’s no connection issue
Changed WiFi setup number of times:
** Apple TimeCapsule
** BritishTelecom home router
** Android Nexus 5 hot spot
Re-cap of the events
reset and flash the core
core blinks blue
supplied core with WiFi details through spark-cli
core blinks cyan for long period, then blinks green for long period and again cyan, green, cyan, green, cyan, green… forever.
Feels like the core can’t connect to the cloud (blinking cyan) and reinitiates network connection (blinking green). Please see yourself: https://www.youtube.com/watch?v=wpi4fzMFpiU. Core switches from blinking cyan to blinking green at 2:08
Hmmm. I’m using an Apple Airport Extreme (current version). It’s just set to automatic … EDIT: Oh wait, I see I don’t have a tick in the 5GHz name box …
I’ll enable 5GHz and see if it causes a problem for my 'cores. Will get back here shortly.
Right, so you did. Well, I just enabled 5GHz and set a 'core to use it’s unique SSID and it actually connects just fine, surprisingly.
What I was really confused about though, is that when I use spark setup wifi to install completely bogus credentials, my core still connects, though it takes a couple tries. It was then that I realised that the CC3000 module can in fact have multiple WiFi configurations, which it cycles through.
So right now, with this knowledge and other stuff in mind, I’m trying a bunch of stuff to see if I can duplicate the exact same symptoms you are seeing. I’ll get back shortly.
EDIT: Skip to next post first, then back here if no joy.
Here’s some steps I just followed and some observations I made, with a known working core …
Factory reset
Core into DFU mode
spark flash --usb deep_update_2014_06
Core reboots and enters listening mode (flashing blue). Deep update flash not performed yet.
spark setup wifi … but using bogus credentials, so the core cannot connect. Core is now flashing green for a long time. Deep update is still not performed.
Place core back in listening mode
spark setup wifi with correct credentials. Core reboots, connects, then performs deep update, indicated by flashing crimson (purple). Core eventually reboots and connects to cloud.
This tells us that the core must be able to at least establish a WiFi access point connection before it will perform the the deep update. (I highly doubt a cloud connection would be required. But I’m not sure.)
So @ciukes … my question for now is, did you actually witness the lengthy session of crimson/purple LED flashing indicating that the deep update was in progress, directly after the DFU-spark flash --usb deep_update_2014_06 command? (I am guessing “No”.)
My main reason for asking right now is only so that I can replicate the events, to see if I can get my core in the exact same state as yours.
P.S: Incidentally, I’m not sure I have ever witnessed a core flashing cyan in quite that same ‘erratic’ manner. Rapid and for a long time, yes … erratic, no. I originally put this down to video frame rate interpolation, though. Perhaps you could confirm?
Ah!! I believe I may have now produced the exact same symptom. I think you have a corrupt (or invalid) cloud server public key.
I just purposely corrupted the cloud server’s public key and installed it back in my core. I now have the same sort of slow/fast/mostly fast cyan blinking, on and on – seemingly just like in your video.
I did go through @gruvin steps. Core flashes as described but no success at the end
But…
I did set up local spark server ( https://github.com/spark/spark-server ). The core did connect successful to the local server although on number of occasions I have seen this message …
c8a11c6dddc19 HTTP/1.1" 200 2 "-" "-"
Handshake failed: Handshake did not complete in 120 seconds { ip: '192.168.1.84',
cache_key: undefined,
coreID: '55ff6c065075555331341887' }
Wow. OK. That last set of symptoms is something else again. Never seen anything like that. The LED is blinking much more rapidly than for the usual connection error reports. It’s usually more like a 1/4 or 1/2 second cadence. What you’re seeing there seems much more ‘erratic’ and strange. Plus, the yellow color indicates bootloader mode, which AFAIK should never happen on its own, unless something is badly wrong.
I’m fresh out of ideas at the moment. It’s looking now to me like something may be physically wrong with your 'core, unfortunately.
That looks like you have a bad key, hopefully you should get a response soon from hello@spark.io, we can fix that up for you. Otherwise @Dave can help you with this one. Apologies for the inconvenience!
This is a relatively uncommon symptom that basically means that we don’t have the Core’s key stored in our database. It typically happens because of an issue on the manufacturing line - somehow the Core’s key doesn’t get uploaded to our servers from the manufacturing line. Every manufacturing run we’re streamlining the process so this happens less frequently, but unfortunately there are still a few that get through each time. But don’t worry, we’ll make it right!
That does seem to align with the other problem I thought I found. Writing the new server public key changed the behaviour from rapid cyan to rapid yellow flashing. So I'm picking that this 'core didn't get any keys stored in its Flash at all, at the factory. Hopefully then, this last piece of the puzzle will get @ciukes on track.
@zach / @kennethlimcp ... In the meantime, perhaps the docs need to be updated to include these presently undocumented rapid/erratic cyan or yellow flashing meanings? I see no mention of them anywhere at present. Am I wrong?
@kennethlimcp ... I recall you are largely involved with the docs side of things. This doesn't seem to warrant a pull request from me . What do you think? ...
Yeah ... well, but nah, not really. The phrase "flashing yellow/red/orange lights after it connects to Wi-Fi" does not sufficiently describe what we were seeing, IMHO. I read all this previously, of course and I suspect from his comments above that the OP did, too. Yet we both failed to interpret that description as matching what we were seeing.
How about, "My core is rapidly flashing yellow, red or orange after connecting to WiFi"?
I have never seen a 'core flashing "yellow/red/orange" before and I doubt I ever will.
From the perspective of trying to find documentation on "rapid flashing yellow" or "rapid flashing cyan" (previously), the text "flashing yellow/red/orange" simply didn't match.
In hindsight, "flashing yellow/..." is a match. But for whatever reason, I read that more as, "flashing yellow, then red, then orange, repeating", at the time. Plus, I was originally looking for the rapid, "cyan", so later ignored the non-matching text that I'd already parsed previously and filtered out of possible matches.'
The use of fast (but not as fast) flashing yellow for DFU mode confused the issue, also. The flashing is slower for DFU mode. I had seldom seen the much faster and more erratic looking flashing that occurs with bad keys and even then, only cyan (bad server public key) which is not in the list, "yellow/red/orange". So again, no match.
I guess it was more about how I perceived the, "flashing yellow/red/orange" description to not match -- reasons to exclude it -- than reasons to consider it a possible match, if that makes sense.