Did WiFi Ever Work?

General
1

I don’t mean this in a negative way but it sounds like the Spark Core just can not maintain a WiFi connection without freezing up.

Did the Spark Team ever have the Spark Core working reliably?

Were you experiencing these same issues when you ran the KickStarter campaign?

Did this only start happening with the first production batch of Spark Cores after the Kickstarter ended?

Is it just a few Spark Cores that are unstable? or is it all of them?

I’m going to happily wait for the fix but from the looks of the forum the issues were having now have always existed. Is that the case?

2

Just as a contrary data point, I have a small application that I leave running when I am not actively developing that reads a yahoo weather page and displays the forecast on an LCD.

This will run for days without locking up and often when things go wrong, it is because the yahoo page had an error. If something does go wrong, the core usually resets itself and reattaches to the cloud without any intervention. Once in a while (weekly maybe?), I have to press the reset button because things got really whacky.

But I am running my :spark: on a access point with little or no other traffic. I read the web page every 5 minutes and update the display every 3 seconds, so there is lots of idle time for the cloud functions.

1 Like
3

I am guessing these issues always existed since they likely stem from the CC3000 bowels… but when you run on a decent AP with not a ton of connections and with reasonable high bandwidth and fast ping times, you don’t see any problems. At least I never see CFOD at home. At work it’s unusable. On my iPhone personal hotspot it also works perfectly, while at work too :wink:

As soon as you throw 5000 users at it, pretty much every model of every working router and AP gets tested in a very short time! Boom, explosion of backlog.

1 Like
4

Hi @RWB,

If it helps as a data point, I can say for myself that I have most recently had a core online reporting my home temperature every few seconds for more than a week without interruption. I know this isn’t the case on some networks, but it’s certainly not universal!

Thanks,
David

5

Upon release, the Core was relatively stable on most (but not all) networks that we had tested it on. Today, on a couple of the networks we use every day, the Core is very stable, and will maintain its connection indefinitely; however on our office network it disconnects frequently. @satishgn, who does development on the Core firmware in Bangalore, has never been able to replicate the CFOD issue; his Cores on the handful of networks he has tested have been rock solid. And although CFOD is relatively widespread and there are a couple of dozen people who have chimed in on the forums, keep in mind there are thousands of Cores out in the wild, many of which are maintaining stable connections to the Cloud.

However, @BDub is correct; anytime you suddenly go from testing on a half dozen networks to thousands of networks, you uncover a wide range of issues, and we’re working to resolve them as quickly as we can. We did know that there were some issues that would cause the Core to disconnect sporadically, but we figured the issue was in our firmware and therefore we could fix these problems relatively quickly; the fact that the problem seems to be deep in the CC3000 firmware makes it extraordinarily difficult to debug, which is why it’s taking us so long to get to the level of stability that we want.

One interesting detail: one of the reasons that we didn’t have a ton of experience with CFOD before release is that, up until just a few weeks before we started manufacturing, there was a bug in the CC3000 firmware that meant the CC3000 could not open a TCP socket outside its local network if it was assigned an IP address on the 10.X.X.X subnet. If you search the Adafruit blogs you’ll find some mention of this. This obscured any other problems that we would later encounter on 10.X.X.X networks where, with more devices connected and more traffic, the Core is less stable.

4 Likes
6

The Spark Core is one of the first large scale releases of the CC3000 and is stress testing TI’s code base. Trust me, it’s far more stable than a CC3000 shield on an Arduino or MSP430 Launchpad which are using TI’s drivers untouched!

If you can setup a second WIFi network that just has the Core on it, it’s far more stable. That said, with the latest changes and on my main WiFi network, I’ve had my core running an LCD demo for 3 days!

1 Like
7

I’ve been testing the Spark Core for about 1 week now.

My Verizon Cell Phone is my houses WiFi Hot Spot, I have unlimited data and easily use up 100 GB per month, super fast data speeds on 4G. I take my phone with me when I leave so I’m moving the Phone/Hot Spot multiple times a day unlike a stationary Wireless router which is much more stable.

If I leave my phone sit and the WiFi on then I can get the Spark Core to stay connect for 24 hours straight also. But a reset will always been needed eventually.

One thing I want to use the Spark Core for is for sending sensor data to the cloud so it can be viewed online, I want to set the sensor up and never touch it again. So for now I’m just going to wait for the fix to begin doing that because unlike others who have non mobile wifi points I usually will have to reset the core a few times a day if I’m in and out of the house a few times a day. I don’t plan on paying for a home based internet connection so the only solution for me is to be patient for the fix or rig up a external Watchdog timer for the ATTiny 85 in the mean time.

It’s very cool to see the Spark Core sending data to be logged, graphed, and displayed online in a nice clean interface. I can’t wait to integrate this technology into my current and future product line.

Thanks for every bodies feedback, its all interesting.

8

Oh well if the hotspot is coming and going, yeah, there may be issue! I know they’re working very hard on making the reliably try to reconnect and recover from failures, so I don’t think we’re that far away. :smile:

Rigging up an AVR to reset the Core for now might not be a bad option. ATtiny’s are only a couple of dollars, you could also get a full ATmega328 and plug it straight into your Arduino Uno, program it and then hook it straight up to the Core (5V, GND, One GPIO and Reset). You’d only need a resistor divider to bring the 5V output down to 3V3 on the reset pin (no external crystal needed, the ATmega328 will just run slower with the built in oscillator).

You can find the ATmega328’s with Uno Bootloader on Amazon for $6 with free Prime shipping and $3 non-prime. Virtualbotix even has a complete “Arduino on a Breadboard” kit for $8 w/ Prime!

Hell, if you needed I could even program up this DIP package MSP430(G2452) to act as a Watchdog Timer and drop it in the mail for you (free of course); I’ve literally got a bunch laying around. It runs on 3.3V so you’d literally hook it directly to the Core, zero extra parts required!

[If anyone else is interested in one I’ll do it for the cost of the chip ($2) and postage.]

9

If you have a test environment that produces a lot of CFOD Please try this test file and report back:

Use http://nscdg.com/spark/0_inact_20_sec_recovery_log_core-firmware.zip2

This has recovery code in it to detect the CFOD and does a reconnect in about 20 second total.

I have ran it for over 72 hours with no issues (hangs or faults) and recovers from network issues in 20 seconds.!

It will Log CFOD;s as

0000164364: void SPARK_WLAN_Loop() (582):Resetting CC3000 due to 2 failed connect attempts

The test will send a udp packet every 60 seconds to 10.10.0.1 and also does an http get of a lot (3880+ bytes) of data from nscdg.com

Log data goes to Serial1 (3.3V tx,rx pins)

All the log data is critical, because the faults are logged after being detected and mitigated so they do not sent the CPU into a hardfault. Please send the logs and LED observations. (if it dies in a red …—… Blink N …—…)

1(Faults,RGB_COLOR_RED,HardFault) 12 (Faults,RGB_COLOR_RED,NMIFault)
3 (Faults,RGB_COLOR_RED,MemManage)4 (Faults,RGB_COLOR_RED,BusFault)
5 (Faults,RGB_COLOR_RED,UsageFault)
6 (Cloud,RGB_COLOR_RED,InvalidLenth)
7 (System,RGB_COLOR_RED,Exit)
8 (System,RGB_COLOR_RED,OutOfHeap)
9 (System,RGB_COLOR_RED,SPIOverRun)
10 (Softare,RGB_COLOR_RED,AssertionFailure)11 (Softare,RGB_COLOR_RED,InvalidCase)

1 Like
10

@david_s5

Can you please link me to some instructions on how to flash this new firmware to my Spark? I’m capable but do need some sort of step by step instructions to follow.

I would much rather try this code than rig up a ATTiny 85 for now.

11

@RWB

see

https://github.com/spark/core-firmware/blob/master/README.md#3-device-firmware-upgrade-utilities

And

https://github.com/spark/core-firmware/blob/master/README.md#4-flash-it
1 Like