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++;
}
}
I know the Spark team has been planning the roll-out of a patch for TI CC3000 but they want it to be safe for everybody and so I think the testing is taking some time. I think they said this is going to be an “opt-in” patch, so they can go slow and make sure it works.
Yes! We’ll update this thread when we get an official patch from TI, but that is certainly taking longer than we expected. We have an unofficial patch that is a significant improvement, so we’re very optimistic. We’re also working on a smooth opt-in system for delivering the patch to everyone’s Cores, so that should happen in the coming weeks.
Yes, we believe that this release is the same as the one we have been testing and are readying for release. I have asked TI for confirmation, since the link is dead and we can’t validate for ourselves.
I’m actually not using a Spark Core, but another device that uses the CC3000: BrewBit Model-T (code here).
I have just been monitoring this thread as we have been facing the same issues as you guys. We pulled the update into our code in about 10 minutes. It was a very easy upgrade for us, but I am not sure how the Spark patch programmer is intended to be used. So unfortunately, it looks like you will have to wait for the official Spark update.
Edit: Looks like the Spark patch programmer is basically just the stock CC3000 one, so the only change you have to make to this is to replace wlan_drv_patch, drv_length, fw_patch, and fw_length with the values in the CC3000 patch programmer.
Edit: Okay, thanks, success! I was able to flash the new firmware to the CC3000. Tried with my test application and it seems to be a lot more stable. I was able to crash it, though, by making many HTTP requests very fast. Still… But at least it now stays up for more than 5 minutes. Will let you know, if it stays up constantly. Thanks very much!!!
Update: so it still dies after a couple of hours, or when there are too many requests coming in too fast and then you close a connection. :-(. There seems to be some improvement but not much.
core is one of the largest product with a CC3000 and this create new environments untested.