Connected Device Architecture – CC3000 Wifi Breakout

In ITP, Radio Gaga

Some Background

I originally wanted to focus on turning radio waves into DC current but unfortunately could not achieve any meaningful results. So in the remaining time I had, I decided to go after an idea that I’ve had for some time. I’ve always wanted to build a pair of connected devices that two people far from each other could share to create a passive connection. These devices would measure sound as a means to gauge how much activity is happening on one end and output a corresponding level of feedback on the other end. The initial plan was to have the sound I was generating in my apartment control the intensity and behavior of a diffused light pixel in my sister’s place for example. However, I feel like the light pixel idea only brings value to the user when the other person is active and I want an object to add value to the space even when it’s dormant. Therefore, as I investigate this further, I want to look into a sculpture that looks cool in itself but activates sound, motors ect when the other remote party is active. My inspiration for these objects is Peter Vogel’s circuit sound sculptures as seen below.




Building a connected System

With the tight time constraints on the project, I thought I was going to rely on for my backend. Dweet is a really handy free service that lets you send information from your arduino to the cloud and retrieve info as well. I used it before for a project that quantified water usage and then displayed all your info on an online dashboard. It was great in that case as it was easy enough to post my JSON info to dweet’s servers and then I could easily parse the JSON using Javascript. However, what I realized is that arduinos are not nearly as suited when it comes to parsing strings and JSON. So I got the system working where one device was sending sound values and the other devices was retrieving them using a HTTP GET request, but unfortunately, it was nearly impossible for me to access the info I wanted in dweet’s nested JSON response. All of this led me to the conclusion at 2am that I would need to build my own server so that I could isolate and prepare the variable in the simplest possible way. This would greatly reduce the pain of dealing with strings on the arduino side. Here’s a little diagram of how everything will be communicating.




I thought I would carefully document my process as a lot of the material I found on people trying to do something similar with the CC3000 wifi breakout was unnecessarily confusing. I love the CC3000 breakout from Adafruit for how versatile it is, especially for smaller projects, but I paid the price due to the sparse documentation on the component. Most examples that I found use the Arduino Yun which allows you to use the Bridge Library to do Curl requests. From what it looked like, these curl commands made it very simple to do HTTP GET and POST requests. With the CC3000, I had to do a little more heavy lifting. Below I will bring you through exactly how I got everything working. For the sake of simplicity, this system has one arduino publishing information and the other one receiving information.


Arduino post device code


Now that you have the whole code above, let’s take a look at a couple key specifics that you should understand. For that, let me highlight a specific part of the code below.



While we are sending a POST Request in theory because it’s saving info to our server, it’s actually a GET Request. The reason we’re doing this is because HTTP POST Requests on arduino are much trickier unless your are using the Yun where you can use the Curl Command. Typically, on the server side you would use Body Parser to access the info in the POST request but in this case we will use req.params to extract the variable we’ve injected into the GET URL. In this case, it’s the variable “soundLevel”. You can see specifics on this in the Node.JS section. Here’s a screen shot of what you should be seeing in your Serial Monitor.


Screen Shot 2016-03-16 at 11.18.18 AM


Arduino Get device code


The GET Request syntax should feel pretty familiar to the POST device, however, the important thing to get right here is how you’re reading the response.



Some examples you may come by with the CC3000 will have this part of the code without IDLE_TIMEOUT_MS in the while function and that could lead to some problems. A lot of times, the server would just hang and stop the code all together but this timeout function ensures that if one particular request doesn’t go through, it will just ping the server again. Make sure to define IDLE_TIMEOUT_MS at the top of the code as you can see in the full code above this excerpt. I also included this in the Post Device code to ensure that it would run smoothly.


The other key to getting this all to work is to be able to parse the answer we get from the HTTP GET Request so we can use that sound variable for whatever we want. While we made sure we were only sending back the sound variable so that the arduino would have to do minimal work to parse it out, there are still the HTTP headers that are a slight pain. That’s where the if statement above comes in. I added a special character ‘$’ to the variable on the server side so I could easily flag where the body of the GET Request started on the arduino side. Once I separated out the body (a.k.a the actual value I want) I just turn it into an Int and can start using it. As simple as that sounds, it was oddly the trickiest part of all of this for me. Thankfully, my professor Surya helped me out with this. Here’s an example of the type of readings you should be getting from your Serial Monitor for the GET Device.


Screen Shot 2016-03-16 at 1.17.27 PM


Server Side – Node.js code

The server side of this project is pretty straight forward, particularly with some of the aforementioned explanations I provided. For a quick snapshot at what it looks like, here’s the routes and model files.






Lastly, to tie everything together, here is all my code up on Github. I hope this helps!



Submit a comment