The main issue I was having with the Spark Core was when my cellphone’s wireless hot spot would get reset by Verizon it would cause flashing dark blue indicator on the Spark Core that would require a manual rest. This was happening pretty often lately due to high internet traffic.
The latest firmware update via the web IDE has completely fixed that problem it seems. I have not seen any other problems with the Spark Core after about 60 days of usage.
I’m much happier with not having to manually reset the Spark. Hopefully I don’t speak too soon, if I notice anything change I’ll report back.
I have a found a network that is total rubbish and my core always fails after a while even with the latest CC3300 firmware, so I’ll be happy to test the new patch when it’s available and report if it kills the problem forever.
So, any update on the outcome? You really know how to build up tension ;-).
I am dying to get finally a working version of the Spark Core. I would really like to start working with it. But I won’t start until the connectivity is reliable!
Calling all conspiracy theorists in the community Has TI done a runner?, are their open source issues in issuing the update?, is someone making a takeover of spark labs inc ?, the silence is deafening…
What remains the biggest problem with the and 18 days after getting a RC from TI still little word. Appreciate reliable OTA update stuff may be challenging but still nothing for those who flash locally. Certainly firmware v0.2.0 has helped with reliability but the best uptime I can get is < 24hrs
C’mon @zach@AndyW is there anything you can tell us ?, please.
There’s no silence from us :), you’re hearing news as soon as we get it.
TI has a large testing lab, and we’re waiting for them to be confident about their cc3000 fix. We’ve done quite a bit of planning, and we want to make sure they’ve tested this patch thoroughly before rolling it out to the community. There should be more details in our post-sprint blog post which should come out sometime Monday since we ended this last sprint just this last Friday.
In a potentially unfair teaser, we continue to hear good things about testing on the patch. As much as we want the patch out quickly, it’s also good for them to test very thoroughly. If they find bugs now, that just means more fixes will be included in the next update.
Well, silence is the absence of sound. So if there is no sound (==news) that’s silence, or :-). Have you ever been in a phone call where suddenly the background noise stops? And you ask “are you still there”?
Anyway it’s good news that none of the conspiracy theories seem to hold :-).
There is only one thing I wonder: If TI has such a big QA lab and such a lengthy QA procedure, then how could all these issues have possibly slipped through??? (Not the fault of the Spark, of course). I mean TCP did barely work, UDP does not work (not preserving packet boundaries is no UDP for me)…
you can’t test all the router make in the world. Like android app makers can’t customize for all and some might have an issue. So feedback is important
everyone is in an unique wifi environment and the not a majority is hit with the event even though the fix is definitely needed.
I feel that they moved fast to zoom in on the issue and even took extra steps to get this fix out and I applaud them for that.
core is one of the largest product with a CC3000 and this create new environments untested.
I do not know if they plan to formally release a package that matches the code they have released to us.
I understand that TI has a release scheduled for May/June that will include some additional fixes/features beyond the issues behind CFOD, that may be the next formal release from them.
Thanks @AndyW, Is the fix confined to the CC3000 firmware or does it also impact the Host Driver as well? Also what CC3000 firmware release did the KickStarter Spark Cores ship with?
I’m working on a project and found lots of great information on this data stream. I also purchased some Adafruit CC3000 chips and was able to port functionality from that code into a solution that worked for me. Hopefully it will work for you, too. I’m not a professional developer, so please forgive sloppy formatting. BSD license applies.
typedef struct Result_Struct{
uint32_t num_networks;
uint32_t scan_status;
uint8_t rssiByte;
uint8_t Sec_ssidLen;
uint16_t time;
uint8_t ssid_name[32];
uint8_t bssid[6];
} ResultStruct_t; /**!ResultStruct_t : data struct to store SSID scan results */
void structSSID(){
char ssidname[32];
ResultStruct_t SSIDScanResultBuff;
int res = (wlan_ioctl_get_scan_results(0, (uint8_t* ) &SSIDScanResultBuff)); //loads results into struct
if (res != 0) {
Serial.println("Could not get WiFi Scan results.");
}
int index = SSIDScanResultBuff.num_networks;
int i = 0;
while (i<index){
int _rssi = (SSIDScanResultBuff.rssiByte >> 1);
int _mode = (SSIDScanResultBuff.Sec_ssidLen & (~0xFC));
uint8_t ssidLen = (SSIDScanResultBuff.Sec_ssidLen >> 2);
strncpy(ssidname, (char *)SSIDScanResultBuff.ssid_name,
ssidLen);
ssidname[ssidLen] = 0;
long rssi = _rssi-128;
String myrssi = String(rssi, (unsigned char)DEC);
String encrypted = "";
switch (_mode) {
case 0:
encrypted = "OPEN";
break;
case 1:
encrypted = "WEP";
break;
case 2:
encrypted = "WPA";
break;
case 3:
encrypted = "WPA2";
break;
}
String SSID = ssidname;
String results = SSID + "," + myrssi + "," + encrypted;
Serial.println(results);
int res1 = (wlan_ioctl_get_scan_results(0, (uint8_t* )
&SSIDScanResultBuff)); //iterates the buffer
if (res1 != 0) Serial.println("Get Scan Results iteration
failed");
i++;
}
}