I created a web / websocket server and encountered the following quirk:
When I hit the CC3000 with 15K of data it stalls after sending app. 70% of the data.
After inserting a delay of 50ms per websocket-message of 120 bytes (about the max length of a websocket message) the CC3000 transports the data flawlessly.
Is my assumption correct that the CC3000 should be approached with small blocks of data intermingled with short delays?
The method I use looks like this:
…<- ack with 120 bytes
req ->… delay(50)
…<- ack with 120 bytes
…goto loopstart (pseudo code off course! ;))
…<- ack with last block < 120 == end of comm.
I’m testing it now, and this method works fine. A pitty that I loos speed…
Ooh, interesting! In my testing I was able to achieve speeds of ~30-60KB (I think it was bytes and not bits). My code was fairly aggressive about reading out / emptying bytes from the socket buffer. If you’re seeing corrupted packets during the transfer, it’s possible you’re seeing the “ACK Storm” bug we identified a while back. We have an experimental patch in the wild that fixes this issue, and we’ll be releasing an official patch hopefully this week.
Are you building locally or on the build IDE? The current build IDE uses the current
compile-server2 branch which still has a TCP buffer size of 512 bytes ( https://github.com/spark/core-firmware/blob/compile-server2/inc/spark_wiring_tcpclient.h ), so it’s possible your app will also perform better with more ram (also coming very soon!)
I’m a step further now. Downloading a 15KB html file goes very fast, Indeed in less than a second, and stable for more than 3 hours…
The files are transfered through a websocket that is opened after the DOM (on the client) is fully loaded. Then the error appears with hi speed websocket interaction, see my pseudo code model. It’s a Q&A setup.
Sending a file in a series of packets through plain TCP works good.
Files send through a websocket in chunks of 64 bytes (should be 120+ plus OH) needs a pause between receiving a request and the ack with data, 50ms is fine, 20ms to short.
I compile locally and I’ve updated the firmware files today from github So I work with the 128 byte buffer. I checked that in the source file. A closer look at my code shows me I send 64 bytes a time, that should be 120, sorry…
Wireshark shows perfectly formatted messages, so that;s okay.
My guess is a timing problem in the cc3000, haven’t even looked at the datasheet. Will do that tomorrow, but I think that’s more for the TI guys… ha!
By the way, my compliments to you all, it’s an awesome platform. I come from years working with atmel, arduinos and raspberry pi et cetera. But the solution you guys are perfecting is so much better!
At this moment I’m porting my code to spark, takes some time but it’s worth it.
Awesome, glad you’ve got the download working, and thanks for posting your findings!
Please let us know if we can help make anything easier / better!