CC3000 echoServer/chatServer hangs after few transactions

on several forums, users report issues with this chip per se.
Some discuss skipping it and using the second generation product.
 
Hi Steve,

As Second Generation product, do you mean CC3200 ?
But Adafruit and others don't provide pcb module yet ... :-(
In the mean time, as mentionned in forums, I added "#define SEND_NON_BLOCKING 1" in socket.cpp, and delay(5) between each client.print() calls with smaller strings (ie.: not the whole HTTP response in a single call), and it seems to work, at least since 2 hours, it didn't hang.
I'm a bit disapointed about TI not having take care of this issue ealier.
 
Yes, I think I read that the second gen product (get it right this time Bangalore or your fired) is expected in 2nd half 2014.
I have had bad experiences with T.I. and RF modules - much of the work is done over 'there' and I suffered that with the Anaren modules that used TI.
 
Hi Steve,

Do you mean that you went away from CC3000 ? Which technologies did you choose instead ?
I've just ordered some other modules : one HLK-RM04 and one USR-WIFI232-G2. Do you have any others to suggest ?

About TI, I think that if they doesn't care about their crappy products, they will melt off in multiple companies, like Motorola did few years ago. That sad ! (I'm remembering when I've graduated in '80, they were both giants !)
 
Not the CC3000 but rather the TI CC2530 as incorporated into a module sold by Anaren.
I suppose the CC3000 has the same support tail... I had to deal with the developers and documentation people in India. And do so via Anaren, not TI. TI tried hard to "hide" that they outsourced documentation, firmware and perhaps other aspects of the chip and firmware (IEEE 802.15.4 w/o Zigbee is what I was working on). Their documents on the API were crazy dumb. They didn't understand what they were to write about, in the least. If I asked a simple question, it went over by proxy and back again a week later. And you've been there too, eh? The answer was irrelevant.

Well Phillips spun out to NXP; Moto to Freescale; HP Test to Agilent; Tektronix to DumbName; What's TI got in assets other than semiconductors?
Most of these were national brain trust assets of the US. The MBAs run amok.
 
From some Forum comments I am gathering that they are doing a lot better with the cc3100.

What bugged me the most is that their marketing material indicated that it would support multicast DNS ( mDNS ) wich is required if you want to seamlessly integrate a device into ZeroConf networks e.g. apples Bonjour implementation of ZeroConf. That never materialized.

The cc3100 seems to do much better in that and other aspects.
 
Headroom said:
mDNS is RFC6762 and the associated
DNS-SD is RFC6763
Both belong to the area zeroconf networking
Click to expand...
Why is multicast essential for DNS discovery, within the scope of a LAN? If the client uses DHCP, we're done. If not, then by definition the NATed clients have the gateway's LAN IP and can unicast to that gateway to ask if it can provide DNS server(s) addresses. If no response, the client can subnet broadcast to get a DNS address. Propagating that to other subnets, etc, makes sense at the enterprise level. I can't see a case for propagating that across the edge router to the WAN since most Fortune 1000 and so enterprises control their DNS - either operate their own or proxy it to a WebSense or some such.

What am I missing that drives the need for the terrible complexity of IP Multicast for this DNS discovery? Esp. at the consumer, SMB and SOHO level.
 
stevech said:
What am I missing that drives the need for the terrible complexity of IP Multicast for this DNS discovery? Esp. at the consumer, SMB and SOHO level.
Click to expand...

Let's say I've got this fancy new product and want you to be able to control/configure it from your iPhone.

I can

(A) Write an App that controls the product and takes care of figuring out where the device is on the network. Upside: You don't have to do anything special to talk to the device. Downside: In addition to developing the product, I have to write the code for the app, and I have to make separate apps for iPhone, Android, Windows, Mac, Linux.

(B) Put a webserver in my product and tell you you're responsible for figuring out the IP address of my device on your network, e.g. http://192.168.1.36. Upside: my product will work with all devices because every modern device has a browser. Downside: Try explaining to my mom how to go into her router and figure out the IP address of a specific device on her network, multiplied by the kabillion versions of consumer routers.

(C) Like "B" but use mDNS. Upside: You can tell people to access your device by typing "bubblelight"[*] in their browser bar. Downside: mDNS required.


Arguably (A) is the path of least resistance for the generic consumer because it requires the least work on their part -- everybody knows how to use the App store. This is why you see apps for things like the Phillips Hue and Belkin WeMo. Getting into the hands of the maximum number of customers means making things as easy for them as possible. But I'm just a poor developer and I don't have the time/money to develop an app for the iPhone, much less for Android and Windows Phone and Macintosh and Windows and Linux.

(B) is going to severely limit your market. Nobody[**] wants to have to figure out the IP address of a device.

So my hope is (C). Actually my hope for the product I was developing with the CC3000 was (C), but TI's half-brained implementation showed that wasn't going to happen. Fingers crossed with the CC3100.


[*] or "bubblelight.local", depending on your network and client
[**] "nobody" as in "my neighbor who thinks the Internet is magic voodoo", not people like us who know how the series of tubes really works.

(edit - typos)
 
Last edited:
I could attempt to answer Stevech's question but the book "
Zero Configuration Networking: The definitive guide" written by Stuart Cheshire, one of the co-authors of the RFC does undeniably a better job then I could ever do and is well worth the money. I bought the Kindle edition when I was in process of overhauling the ZeroConf Bonjour library.

For the purpose of hobbyists that don't want to write their own application there is TouchOSC, which is available on iOS as well as a for Android. That will require a user to use the OSC protocol, which can be done using Oscuino library maintained by the inventors of the OSC protocol.

This is not just theory but works perfectly for remotely controlling my Lighting systems

Hardware wise I am using the WIZ820io, which does support mDNS (well the library needs a slight mod/addition). That is connected to a TP Link TL WR703n WiFi pocket router.

Once I insert the plug the it into the wall receptacle it takes just a few second until the OSC service is registered on the network.
Then I can just open TouchOSC, click on the "info" button and a moment later the Service pops up and I can just select it. network configuration done and I can now control my lighting system from my iPhone, iPad, Android Phone etc.
No selection of Protocol, IP address or port necessary by the user.

There is your "hobbyist" solution.

What I had hoped for with the CC3000 was to be able to have a much smaller footprint WiFi solution. This seems to be possible with the CC3100.
 
Last edited:
What I had hoped for with the CC3000 was to be able to have a much smaller footprint WiFi solution. This seems to be possible with the CC3100.
Click to expand...
No. It will be a larger footprint. This is a 64pin QFN (Editied: Sorry mis read that, I had QFP) and require two crystals a mirriad of Caps, Inductors and other supporting widgets, and based on 1000 units for parts, will cost More than the CC3000. Oh and you will have to get the product FCC certified as it's not a module anymore.

Also it is not footprint or anything print the same as the CC3000. It may be a better product than the CC3000 but it no way the same or drop in replacement for the CC3000.

For all it's flaws the CC3000 is still the smallest fully TCP/IP stacked unit on the market, for a low cost and FCC complient.

It is a shame that the CC3000 does not have SoftAP, and is a bit twitchy with anything server related (Web server, Echo Server, etc), but they can be worked around.
 
Last edited:
I have to admit that had not looked that deeply into it.
Looks like we can't have our cake and eat it too :/
Maybe the next time around they'll get it right.
 
No. It will be a larger footprint. This is a 64pin QFP and require two crystals a mirriad of Caps, Inductors and other supporting widgets
Click to expand...

The CC3000MOD is 13.5x16.3mm. The CC3100 QFN is 9x9mm so my guess is even with the additional Flash chip and discretes you're not talking about a massive increase in PCB real estate.

The CC3000 also requires support components (caps, inductors, antenna), albeit yes fewer than the CC3100 will require. Discretes are cheap, however, so I'm not sure how much more this adds to the bottom line. I'm not sure what the crystals cost, but it's my understanding you can leave the 32Khz one out if you don't care about low power mode and/or have a free MCU pin to drive it.

and based on 1000 units for parts, will cost More than the CC3000.
Click to expand...

TI's quoted price for the CC3100 in qty 1000 is $6.70 (http://newscenter.ti.com/2014-06-16-Add-Wi-Fi-to-anything-with-TIs-Internet-on-a-chip).

DigiKey says $14.49 each for the CC3000, no discount (http://www.digikey.com/product-deta...5883?WT.z_cid=ref_octopart_dkc_buynow&site=us)

Mouser says $13.77 in qty 500 (http://www.mouser.com/ProductDetail/Texas-Instruments/CC3000MOD/?qs=sGAEpiMZZMul4LbMdexInYO9dzLxESeK), my guess is the next step will not be less than $6.70.

Oh and you will have to get the product FCC certified as it's not a module anymore.
Click to expand...

TI's promising (http://e2e.ti.com/support/wireless_connectivity/f/968/t/348777.aspx) there will be pre-certified modules for the CC3100 and CC3200.

For all it's flaws the CC3000 is still the smallest fully TCP/IP stacked unit on the market, for a low cost and FCC compliant.
Click to expand...

I agree and I did one design last fall using the module, but it left me with enough of a distaste that I'm not going to do that again. I'm currently waiting for the CC3100, if it's (A) not usable by December or (B) doesn't exist by December then I will have to pick another vendor….

(edit - corrected size of the QFN)
 
Last edited:
TI's promising (http://e2e.ti.com/support/wireless_c.../t/348777.aspx) there will be pre-certified modules for the CC3100 and CC3200.
Click to expand...
;) yeah right! TI promised a lot of things for the CC3000 and never delivered.

And according to the Datasheet, both xtals are required. But hopefully if mouser have it up on there site as something that can be ordered, then it should (fingers crossed) be available this side of December.
 
Last edited:
johnnyfp said:
;) yeah right! TI promised a lot of things for the CC3000 and never delivered.
Click to expand...

I agree again, like I said that's why I'm watching what they're doing but I'm not holding my breath.

My opinion is that TI picked too pokey of a MCU when they designed the CC3000 (internally it runs on an 8-bit 8051) and they've run out of space trying to fix the bugs they've had since launch, much less add promised / new features.

The CC3100/3200 have significantly upgraded MCUs (32 bit Cortex M3 ARMs) and a (relatively) large external Flash so hopefully they learned their lesson.

The chips are scheduled to ship in mid September, as is the announcement of the modules…so soon we'll find out.
 
I should also say that I already know the CC3100 has problems.

It has an internal webserver and you can store whatever HTTP-ish files you want on the external Flash chip, but it's static content only. Their version of "dynamic HTML" is you can send as few small (<64 bytes) variables back and forth but there's no way to do e.g. "here's a graph of the last 24 hours of sensor data".

It does support mDNS but Windows boxes (still by far the dominant device you'll see on a network) require Bonjour for Windows to be installed to use it. Requiring additional software is a sure-fire way to reduce your market size. Windows does have its own mDNS-ish protocol called LLMNR, but you'll need to write that yourself (or port the one Valkyrie-MT is working on).

Android doesn't support mDNS, LLMNR, or anything else but it can use a local nameserver and many consumer routers do that these days, but the CC3100 doesn't send the client name in the DHCP negotiation…so, too bad for the fastest growing segment of the mobile and tablet world.
 
AFAIK Windows LLMNR only supports link-local name resolution, so you an connect to a device with its name rather than it' IP address. That is about as rudimentary as it gets. It does not support service registration, or service discovery, the two parts that make Bonjour so successful in the Apple world.

The fact that neither Android does nor Windows support mDNS is a indicator that competition is not always beneficial for the customer. With Avahi, however Linux does support mDNS.
 
You must log in or register to reply here.
Back
Top