WiFi Module For $10?
Last July, I experimented with adding Wi-Fi to the Monulator prototype. With Wi-Fi, a Monulator wouldn't need to be plugged in to a PC to retrieve information. So far, it's working great! I have a Monulator that's scraping a NASA Web site every five minutes, indicating how likely it is I can see an aurora borealis where I live. (Sadly, no auroras yet – they're very rarely visible at 45 N latitude.)
The one bummer about adding Wi-Fi to the Monulator is that it's expensive. The Roving Networks (now Microchip) RN171XV module is about $30 US in quantity, which is simply too much. But then I stumbled across the TI CC3000 Wi-Fi module. It'll do 802.11b/g in the 2.4GHz spectrum, for only $10 US in quantity. It's exciting to think I could add Wi-Fi capability to the Monulator for a modest incremental cost!
I got a development board a couple of weeks ago, and have struggled mightily to get the CC3000 to talk with an ARM microcontroller and my Web server. But I have made real progress!
The CC3000 does not use a serial/UART interface like most of the other Wi-Fi modules. The CC3000 talks SPI. This is great, because SPI can transfer data very quickly (16MHz on the CC3000). SPI is also transfer-oriented, so sending and receiving commands is (arguably) simpler than managing command and data modes of a stream-oriented API (typical of a simple serial interface). Unfortunately, TI did a very poor job of documenting the CC3000's command protocol. There's some low-level documentation on their CC3000 Wiki, but details about command and response data structures is missing completely. I've had to wade through their "host driver" code to understand the protocol. In that process, I also learned that what TI posted to the Wiki is not always correct (a common Wiki phenomenon). Among the revelations, TI says the SPI interface uses a particular style of clock/data synchronization (CPHA=0, CPOL=0, but the next sentence, the datasheet and this forum post describe a CPHA=1 configuration.
Eventually, I got my own CC3000 driver code working, and was able to communicate with the CC3000 at a basic level. I saww that the firmware on my module was quite old (version 1.7, while the current version is 1.10.1). TI provides sample code for updating the firmware, but it only works for their MSP430 and Stellaris microcontrollers, Windows, and proprietary/closed development tools. That won't work for me, so I ported the patch update code. This was rather scary, as I was sure I'd have a bug in my code and would brick my CC3000 module. At a couple of points, it looked like I had. But it turns out their bootloader and update process is robust, and I was able to back out my applied (and messed-up) patches and re-write them correctly.
Commands issued to the CC3000 over SPI are wrapped in an "HCI" structure, which looks a lot like your ordinary RPC (remote procedure call). On top of the HCI layer, they've implemented an API modeled after BSD sockets. But it seems like their sockets implementation doesn't behave quite the same as it does on a PC. For instance, when I'm connected to sharebrained.com via HTTP, my PC sockets test program disconnects after the HTTP body content is downloaded. On the CC3000 side, I receive no indication that the server has disconnected – the socket is not signaled as closed, and I see no indication via select(). So I'll have to parse the HTTP response header (and I should anyway) to figure out when I'm done downloading. Not sure what I should do if no Content-Length is provided by the server. Time to break out the HTTP RFC…
Comments
Great review, what are you using i as access point ? any problems with your 802.11n network slowing down as cc3000 is only g? or does log only logon every 5 minutes?
@ChristianB: Thanks for your interest!
I am using an Apple product as my access point. The CC3000 has caused no problems, aside from when I was using a power supply that was too small. The CC3000 requires almost 300mA peak, and my regulator was current limiting below that level. So when the CC3000 started authenticating with my Wi-Fi network, the voltage would evidently droop, leaving the CC3000 in a weird state that would jam my 2.4GHz devices (e.g. my wife's Wi-Fi connection downstairs, and my Bluetooth track pad). Unplugging the CC3000 was the only way to stop the interference, as the CC3000's SPI interface became unresponsive due to the insufficient current. Once I hooked up a beefier regulator, that problem went away completely.
In my application, the CC3000 will only interact with the network every few minutes, and only for a few seconds (long enough to poll a Web site for data). So the impact on an 802.11N network in the 2.4GHz band should be minimal.
Unfortunately I am not able to enjoy the technical details of all this but I do understand that you are progressing in the design of the Monulator. I hope that a few of them will join my Chronulator very soon. Many thanks for the update !
To be honest I still do not understand how you pick up a value on the Internet before sending it out to the device.
For instance imagine this: as a recreational pilot, I want to visualize the wind velocity, its direction and the barometric pressure in my airfield. These values are published and updated almost in real time on a website. How do I indicate to the Monulator to display those values ?
I hope that my question will not sound too stupid :-)
Hi George. That doesn't sound like a stupid question at all. The Monulator (with the optional Wi-Fi module) can communicate with Web servers without the help of your computer. The Monulator has its own (rather modest) ARM Cortex-M processor, related to the processors at the heart of most smart phones. So with the Wi-Fi module, that processor will be able to connect to a Web server and interpret the data it downloads.
To use your example: Every few minutes, the Monulator would use the Wi-Fi module to open a network connection to the Web server that has your aviation data. It would download the data, and look for "landmarks" that help it find the wind speed, wind direction, and barometric pressure numbers it needs to extract. When it encounters those numbers, it will convert them into values that can be displayed on the meters. You might also choose to color-code the values, so that wind above 10 km/h would be shown with a yellow light, and wind above 20 km/h would be red.
I hope that helps a bit!
Hi Jared,
Your explanation is crystal clear, I fully understand the concept now. There are so many nice applications that can use this device. Colored led's and customized scales on the meters will give it even more flexibility and fun.
Perhaps there should be a way to indicate that data was refreshed recently.
I will definitely keep visiting this space for future development.
Mant thanks George
Hi jboone
I am using this module for one of my project but have lot many doubt in porting their driver over SPI.
Could you please share ur porting code. I my code implemented in polling and no DMA. so that i can follow the same step like you got succeed.
Thanks Mukunthan Kandasamy
George: My current plan is to make the device blink or go dark if it was unable to connect, retrieve, or parse the data. So you'd know something was wrong. Blinking could be annoying, so maybe going dark is the best option.
Mukunthan: I committed my code to [https://github.com/sharebrained/monulator/tree/master/monulator-arm-lpc11u/firmware" rel="nofollow">my GitHub repository][] a few days ago. It's written using some features of C++11, but should be easy to read and learn from.
Hi Jboone,
Thanks for ur reply.
If you have any documentation on SPI implementation, share it please. I walk through ur code. I believe it was implemented by using serial UART instead SPI.
My confusion is i need to change the TI SPI code to NIOS II code. and also inside many functions i saw while(1) in TI code. If you explain or provide documentation. It will be great for me.
Regards, Mukunthan Kandasamy
Sorry,
"I believe it was implemented by using serial UART instead SPI." - Mistyped.
-Mukunthan KAndasamy
@Mukunthan: I'm afraid I don't have any documentation aside from what's on the [http://www.ti.com/cc3000wiki" rel="nofollow">TI CC3000 Wiki][]. All my code was developed from reading the TI source code. I hope my code is easier to read, and can serve you, because it's all I can offer at the moment. TI should've done a better job documenting their API…
For SPI details, you may want to refer to following link.
http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide#Protocol_Description
Hello Jared,
Any progress made on the Monulator ? Would you think that a model would be available soon, even it it is still a prototype ?
Many thanks
Hi George. Thanks for asking. No, no real progress for several months now. I became rather frustrated and disillusioned with building new products around these fussy, fragile panel meters. And I've engaged in a bunch of contract work, which is where I'm spending a lot of my time. So the Monulator is languishing at the moment. Which is a shame when people like you are excited by the concept. I do have enough spare prototype parts that I could send you a prototype that you could play with… But I should say, it just barely works at this point. :-)
So many thanks for your proposal.
Providing that there is no programming involved and it is about functional, I would be delighted putting my hands on a prototype and test it. I already enjoy your Chronulator so messing around with panel meters is what I like.
If you could sell me a prototype I would be very pleased. Please contact me on my mail address for the details.
Many thanks for your reply !
Sadly, it will probably involve programming at this point. I never developed a GUI for setting up the Wi-Fi, for instance. So this may be more trouble than it's worth. On the other hand, I'm presently investigating Chronulator 3.0, and it should be able to do all the things the Monulator could, and then some. My best suggestion would be to watch this space as the Chronulator 3.0 becomes a reality. Then, we can get you set up in style…
A Chronulator 3 that would combine the funtionalities then. That sounds very interesting. Many thanks for your reply ! I will wait.
A bit of a tangent, but in gdb-tui, what is that window on the right edge showing a sequence of numbers? And how did you set it up?
@Karl Palsson: It has nothing to do with gdb-tui – it's just another terminal window displaying serial output from the micro controller. That column of numbers is the number of bytes read from the HTTP request. I think I had it there just to show that data was being received, but the socket was never closed. The stream just stopped.
So conceptually, do these chips (TI CC3000, Microchip ZG2100MC, etc) have built-in web servers, or is that layer done by the host real-time via spi? Similarly for reading the data POSTed by the end-user.
Never having done a tcp/ip stack, I'd imagine implementing a web server is not a small task, but if these modules take care of it, then that seems ideal!
If not, what are your thoughts about pushing the raw data "to the cloud"** and let it do the frontend stuff? Although the embedded device still has the issue of needing the user data pushed back!
**xively (Cosm/Pachube) , thingspeak, open.sen.se, smartthings, etc…
@ben: The CC3000 has a TCP/UDP layer. Have a look at the [http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide" title="CC3000 Wiki" rel="nofollow">][] for more details.
If you want something with higher-level protocol support, have a look at the Roving Networks (now Microchip) modules.
There are also several Kickstarted Internet-of-Everything devices that might suit you better, including the [https://pinocc.io" rel="nofollow">Pinoccio][] (no "h"), [https://www.spark.io" rel="nofollow">SparkCore][] and [https://electricimp.com" rel="nofollow">Electric Imp][]…
May I know how to get started for the command part? I would like to control it with the 8051 MCU, but realized the Host Programming is kind of tough. Can you please share some ideas with me on where to get start? Thanks a lot.
@Kwan: I have published all my code on [https://github.com/sharebrained/monulator/tree/master/monulator-arm-lpc11u/firmware" rel="nofollow">GitHub][]. I stopped working on this a while ago, as I decided the product I was working on was not viable. I believe there are several newer, better CC3000 libraries out there, including one from Adafruit. And I think TI has released a newer module that might have a greater degree of abstraction. But I'm not really sure on all of this…