The Ultimate Road Test

The ultimate road test was a competition I entered recently where I got to play with a whole lot of Texas Instruments goodies, including the MSP430 FRAM board and the CC3000 WIFI module.
This article just contains the blog posts I made documenting my projects progress, you can find it all along with my two competitors projects at the Ultimate Road Test Homepage.

29th Match : Hello Everybody

Ready

So to begin with we all have the MSP430 FRAM Dev board and the CC3000 Simple Link WIFI link, all bundled up together.
We have access to all sorts of information and code examples in the MSP430ware database.
And we have a goal, make an awesome home automation project.

Set

Well what I would like to build and what actually makes any sense are two different things. So whenever I go shopping I always forget something, I usually come home with everything except what I originally left the house to get. Or I'll drop into the shops on the way home from work to pick up milk but not realise that I need coffee, sugar and bread?. What if I could grab my new smart phone and see in real time the levels of all of these basic commodities? What if I got a notification on my phone when I ran out of something in the cupboard and it began to generate a virtual shopping list? Sounds like a good idea to me..

GO!

I have an idea and I have some toys to play with, I guess I better get started then.

Cheers!

31st March : CC3000 Up And Running

Well I received my CC3300 Simple Link WIFI Kit a few days back and I have just had a chance today to have a play. I figured that if this whole project is going to be based about this Simple Link then I had better get started and figure out what makes it tick.

I Have Two Networks

I am sure most people will be in the same boat here, I already have a home WIFI connection and I don't really want to turn it off. When I plugged in the Access Point that came with the CC3000 kit I had all sorts of trouble and the internet kept dropping out, turns out that my computer didnt really know where to look so it got confused.

The solution is really simple, all you need to do is give the new device a static IP but do not assign it a default gateway. As far as I understand the default gateway connects the internal network to the Internet, so if you force an IP address but don't give it a gateway it sits there happily networking away without even realising the Internet exists (remember how I understand it might be completely wrong).. Most people probably know how to do this, but I have made a little video just in case, it also gave me a chance to play a bit with video screen capture which I am sure will come in handy somewhere along the track.

CC3000 Demo Application

So the first thing to do is fire up the demo sensor application and see what happens.

Demo apps are nice, they show off some of the awesome features of the board and make you feel like you have done some work. The instruction in the getting started guide explain everything you need to know for this stage, they do not give a great deal of detail into what is actually happening though.. I guess they don't want to spoil the fun for later.

When you fire up the demo app GUI your FRAM board will start to collect temperature and accelerometer data right away. The CC3000 sends the data to your wireless access point, and the GUI displays the data using a cool space animation. Don't worry if it takes a while for your FRAM to start it's orbit, this is the AP attempting to resolve the FRAMs MAC address, for some it goes through all of the IP address from 192.168.1.1 to 192.168.1.101 before it guesses the right one. This morning I would have had no idea what "resolving a MAC address" meant (I probably still don't), but I think that is what is happening anyway..

Host Programming

That last part was easy right? Well this next part I found quite tricky. To make a kick ass wireless project you really need to have some control, this means whipping out Code Composer Studio and the CC3000 Host Programming Guide.

I found it quite daunting when I started looking at some libraries and the programming guide, there is quite a lot going on here to make this all work (I would hate to think what WIFI projects would be like without a "Simple" Link).

It is getting quite late over here in Aus so I will have to close up soon, I will just leave you with a teaser of what I have managed to far.

Basically the backbone of the project is going to be the CC3000 Simple Link Kit, this is just some hardware to facilitate sending collected data through walls. So my first step was to write some code for my FRAM board which would setup my WIFI link and let me send some data.

I decided I would make a totally original Hello Nick program (it is nothing like a Hello World program) it sends the string "hello nick" to the Acess Point once every second. I used Wireshark to check out what was going on on my WIFI network to make sure everything was working, the boring looking screenshot bellow was actually the highlight of my day (is that sad?).. As you can see, the CC3000 connected to my FRAM board (192.168.1.104) is sending the message "hello nick" to my wireless Access Point (192.168.1.2), wahoo!

Well that is what I did, in a couple of days I will explain how I did it, for anyone that is interested.. Are you excited? I am!

3rd April : How To WIFI

So like I said the other day I have my CC3000 up and running with all the control in the world. The configuration of the CC3000 can be split up into four main parts, and each of them split up into a number of other bits and so on and so forth. Eventually you end up with a huge mess of code, the only way I managed to get my head around it was to get some demo code and break it up into little bits. To have any chance you should make use of three handy libraries that TI have made available, the CC3000HostDriver library, the CC3000 SPI library and the Hyper Terminal Driver library I downloaded them all along with the CC3000 basic application from here.

Get Your CCS Project Ready

Now I did attempt to create my own CCS project and import the three libraries and include them in my own project but I could not get it to work, everything would compile but debug just refused to start (a job for another day).
To get around this I just imported the libraries and the basic WIFI application into my workspace and renamed the project to Bread & Butter. Then I deleted all the source code from the project and created my own main.c file to start off with. The fact that this worked makes me think that the problem is just a small linker setting or something. Your CCS project explorer should now look something like this, remember before you can build your project you must first build all of the libraries using the little hammer button above the project explorer.

The Four Basic Steps

So the setup process can really be split up into four parts three of these steps have to be done every time you turn on the CC3000 and want to connect to the Access Point. The different stages of completion of these four steps are monitored by a state machine with the following states.

Step 1 : Initialise The Driver

The host driver library that we imported doesn't assume where the CC300 is plugged in, the initialisation basically gives it access to some peripherals (digital IOs and such) to control the CC3000.

SET STATE 0x02 (Driver Initialised)

Step 1.5 : First Time Config

This step only has to happen once, it will setup certain connection profiles and handle some other tasks I don't really understand yet. You can also set up different connection modes from here if you want, such as fast connect which will cause the CC3000 to always attempt to connect to the last used AP on power up. Once the first step is finished it will save a value into non volatile memory so it doesn't happen again (unless you force it to). You can use this to setup some intelligent connection modes to skip the next step (hence step 1.5).

Step 2 : Associate With the Action Point

This step will associate your CC3000 with your Action Point, I just force the CC3000 to use the SSID of my action point (TTTcBread&Butter0), like I mentioned before you can use smart connection profiles to skip this step.

SET STATE 0x04 (Associated to AP)

Step 3: Get an IP Address

This step allocates an IP address to your CC3000, you can either use DHCP and let the Action Point allocate your IP or you can use a static IP address. Once this is done check to make sure the IP address is OK, this step is mainly for DHCP if you are using a static IP it should always be OK.

SET STATE 0x08 (IP Address Confirmed)

Step 4 : Open a Socket

Again there are two choices here, you can go for the easy and fast UDP socket or take the time to set up a reliable TCP socket. Of course I went the easy route for now, a UDP socket or "connectionless" socket is super easy because all you do is open the socket and start throwing data at the action point. A TCP socket requires listening and accepting of connections and all it does is give you guaranteed data reception... OK that is pretty good I guess, but it is slower and in this case UDP works just fine.

SET STATE 0x10 (Server Initialised)

SET STATE 0x20 (Client Connected) ---- TCP ONLY

Step 5 : Send Data

With a UDP socket sending data is really easy, just point it at the IP address of the Action Point and press send. I have not tried a TCP socket just yet, I will tell you about it when I get there.
That is enough for today I think.. I will start to explain some of the code that makes all this work in a couple of days.

Cheers!!

9th April : Off On a Tangent

I said I would start talking about code soon, but the last few days I have been working on getting my design up to scratch. My general idea is the real time measurement of the basic things you keep in the kitchen (bread, milk, sugar), I have decided that I will try a few different measurement techniques to keep the project interesting.

Weight Measurement : Milk & Bread

So the most obvious choice would be to use some load cells under everything and be done with it. That approach is kind of boring, also load cells are damn expensive! So I will measure the weight of just the milk and the bread for now, and think of something clever for everything else.
I have sourced two super cheap digital scales from ebay which I will rip apart and hack to do my bidding, I can not believe that I can get an entire digital scale (with a load cell inside) for about a quarter of the price of a single load cell.

Clever Container Measurement : Sugar & Coffee

My clever containers will be used to measure things like sugar, coffee, flour etc etc. The idea is that I will use opaque Tupperware containers with 3-5 light dependant resistors down one side. An LED in the lid will illuminate the inside of the container, shining light on any LDRs above the level of the contents (and hopefully creating a cool effect). Now wires dangling off the container would cause all sorts of trouble, so each clever container will have a TI mcu (probably a launchpad) and an IR LED which it will use to communicate its content and level to a smart shelf. The smart shelf fitted with a bunch of IR receivers will then relay the information to my FRAM board with the CC3000..... Madness you say? Well, probably...

April 14th : Scavenging A Load Cell

Load Me Up

My first set of cheap scales arrived in the mail today and they actually look pretty nice, but all I want them for is the sweet load cell inside. Here are some photos of me taking it apart and extracting the juicy insides.

It Doesn't Suspect a Thing

Juicy Insides

Load Cell Legend

Load Cell Legend

April 15th : More WIFI!

OK I am waiting for some more hardware to play with for my clever container, so I have decided to have another crack at getting a TCP socket working with the CC3000. Like I mentioned before TCP connections give you guaranteed data delivery, because the server needs to accept the clients request to connect you need some software on both the client (CC3000) side and the server (PC/Action Point) side.

The Demo Sensor Application used a TCP connection, but it set the CC3000 up as the server. It makes more sense to me to have the CC3000 set up as the client so the Demo Application didn't help me all that much. For the server side I decided to write my application using the QT framework, it's super easy to use and very powerful.

TCP Connection

I think the easiest way to understand a TCP connection is to visualise it, hopefully the picture I drew below makes as much sense to you as it does to me. All of you devices on the network have a whole lot of ports available, to connect two devices they each need to create a socket which will "plug into" a port. The TCP connection will then connect the sockets with a thread which allows communication between the two devices.

Server:

1. Create a socket
2. Bind the socket to the port and assign an IP
3. Listen for incoming connection requests from clients.

Client:

1. Create a socket
2. Request connection to server

The Code

Well my code is very similar to the Basic WiFi application demo, just better . Well probably not but I have made a few changes that made sense to me, the unsolicited events are now handled in an interrupt that runs every 500ms rather than in random while loops all over the place. The CC3000 is setup as a client not a server, I also didn't bother with a lot of the smart config bits and pieces. I made it fairly flexible (I hope), you will find in the common.h file you can change all the network specific variables such as SSID, IP and port numbers, you can also choose to use UDP/TCP sockets or DHCP/static IP. Oh I also commented the bajeesus out of it..

All it does at the moment is send the string "hello nick" every second, but I'm sure you can think of something more exciting to use it for, anyway it is attached to the blog post and you can download it below.

April 22nd : LED Control

Polling Receive Function

I am still playing with the WIFI, I have been working on a little bit of control. Sending a string from the CC3000 client to the AP server is nice and all but I want to be able to control the clients from the server. I thought this would be as simple as just polling the receive function while the client was connected, I was wrong.. Turns out the receive function on the CC3000 is a blocking function and will sit and wait until some data is received, not particularly useful really. You could just constantly send data from the server, or you can use the select() function. The code below shows how you can poll the clients socket for available data using the select command.

The updated code is attached to the blog post below for your downloading pleasure.

RGB LED Demo

To test and demonstrate my receive function and my GUI I hooked up an RGB LED to three PWM outputs. If you watch the video in full screen you can see that when I turn on the MSP430 board the first 5 LEDs come on to show that the board is initialised and connected, when the connection is established the state is updated at the bottom of my GUI. The sixth and seventh LEDs are the transmit and receive LEDs respectively, they blinks for half a second when any data is transmitted or received. The eighth blinking LED is the heartbeat LED, the CC3000 sends a "." every 500ms as a keep alive byte and the LED lets me know it is still going.

Camera Stand

Fancy camera stand? I think not! Cardboard box and toilet rolls are all you need to make yourself something to hold your camera.. The camera usually sits in the square hole at the top, but in this photo the camera is in my hands.

April 25th: Fresh New Blog

Here we are again, I have some new toys to play with and a few days off work so hopefully I can make some progress on my clever containers. First things first, here is a picture that will hopefully show you how my system is going to work together.. I may have to add some extra bits and pieces to include things like motor and light control. We will see..

An Army of MSP430s

May 1st: A Network of MSP430s

So getting my little network was not as easy as I had hoped. Sure it is simple enough but I kept running into problems or just making very silly mistakes. In my last blog post I showed you a picture of how I would lay out my network, with the CC3000/FRAM at the centre I2Cing to all it's children. I ran into my first problem when I realised that the I2C/SPI module was already being used on the board by the CC3000.
To fix this I decided I would use the serial UART interface and use a launchpad as a brother to the CC3000/FRAM board.

Brotherly Love

You can see in the picture below the master FRAM board connected to the brother launchpad and my re-purposed ATX desk power supply with a chopped up usb cable to power the whole lot.
One convenient off shoot to this setup is that I can let the brother do all of the work looking after all of the sensors so that the master can do more important things like talk to the computer (overlord?)...

Serial UART

Setting up the serial UART between the master an brother was easy enough, for the master I just used some of the dispatcher code that came with the CC3000 demo code. To program the brother I used what I think is the best tool I have ever used for programming embedded devices... Grace..
Grace is TIs graphical programming environment for a whole bunch of their devices, it is essentially an interactive datasheet where you can just click on the peripherals you want to use and set them up as you would like. Not only that it generates perfectly commented C code so you can see how it can all be done without Grace.

I will make a bit of a video tutorial of Grace soon, but at the moment I am a little short of time. So once you have set up the various clocks and uart specific instructions you just have to add some code (which grace helps you with) to use your new serial interface. You can see my send and receive functions below, the receive is handled in an interrupt so no polling is required.

Looking after the children

So the brother can now chat away with the master, so now I needed a way for the brother to keep tabs on all of the children. Although at the moment I only plan to have four condiments being measured I am making sure everything is as flexible as possible for upgrades in the future.
To store all relevant food data I have set up an array of structures which my lanuchpad brother can use to store the levels of all the child containers it can find.

The code below handles all of this (except for the I2C bits which I will talk about later). When the PC sends a request for food levels, the CC3000/FRAM master relays this command to the launchpad brother over the uart. The brother then updates the content of all the locations using the I2C interface. If for some reason the I2C request fails the returned data is set to XX to let the PC know that the particular foodstuff could not be found (i.e probably an error). If the particular foodstuff was there last time but, but not currently there (i.e. someone is using it) then the old data is returned but a '0' is appended to the data to let the PC know that the data is not up to date.

The way I have set this up it will not matter if you pick up one of the clever containers and place it back on a different location on the smart shelf.

So the test setup looks something like this.. The mdf with the three aluminium tabs on it is my prototype smart shelf, I have moved away from IR communication for something better (but that is talk for next time).
Next time I will show you some of my I2C code and also describe my new idea for communicating between the smart shelf and the clever containers.

May 11th : Time Flies When You Are Having Fun

Wow I didn't realise I had lost so much time. So this post is a bit of a catchup to show that I have not been doing completely nothing.
Part of my project will involve measuring the weight of some bread and milk, that's what those cheap scale and load sensors were about a few weeks back. To get any useful data from my scavenged load sensors I needed to get myself some sort of high precision ATD converter.

Weigh It Up

Meet the ADS1131, a high precision 18 bit analogue to digital converter with an onboard amplifier, it is perfect for load sensor applications (just read the datasheet). To test out the chip I decided I would give the TI evaluation kit a go, you can check out the ADS1131REF in the photo below.

So it looks like the board is completely decked out with everything you would need to make your own set of scales. One thing it was missing was a normal sized DC power jack, I have a huge tangled box of wall wart transformers but none of them would fit the supplied jack. Not to be deterred I just piggybacked a normal sized jack on top of the original (saves me from using the backwards 9V battery connector). Oh and another thing, when I received the board it stank! I know this is probably the strangest comment to make on a piece of electronic kit, but it did, I had to air out my room. Anyway.. Let's move on, because this thing is actually pretty cool.

Before you measure anything you have to calibrate the sensor, this is easy enough. You just press the CAL button and follow the prompts, by default the calibration weight is set to 1kg. If you need to change the calibration weight like I did you just press the two PARM buttons at the same time to get to the menu. So you don't have to calibrate every time you turn the thing on, you can save the calibration settings into flash memory. To do this the datasheet tells you to look for instructions in section 3.4.1, don't listen to it, it's tricking you, look in section 2.4.1 instead.. Or just listen to me, enter the menu after calibrating the sensor (press both PARM buttons) scroll right untill you find the "SAVE?" screen, now hit ENT. Simple..

So the next thing to do is get the evaluation kit talking with the rest of my little network, but for now I have some other things to show you..

Eagle Goes 3D

I have played with eagle in the past, it is a very powerful piece of kit and the free version has always let me do what I want. My first board design for my Bread & Butter project is the control board for my clever containers. It is just an MSP430G2553 with a programming header and four points to wire up the LDRs which will detect the level of the goods in the containers. In the images below the LDRs show up as LEDs, I couldn't find an LDR device in eagle so I just used something with adequately spaced holes.

To generate the 3D image I used eagle3D and POV-Ray, once you get the hang of it it is really easy to use, and it generates some really nice 3D images.

May 14th : Yar!

ime to try and communicate with this ADS1131REF board so I can integrate it into my little group. I was looking forward to this because I could finally give my new bus pirate a go. The designers kindly left some test points available on the reference board for the UART interface, I have highlighted these in the image below.

ADS1131REF UART SETTINGS

• 115200 baud
• 8 data bits
• no parity
• 1 stop biT
• no flow control

So getting the data was not a problem, now I have to do something with it. At the moment the hexadecimal values that I am getting don't seem to make a whole lot of sense, I am sure I will figure it out soon enough.

May 16th : Grace Tutorial as Promised

I mentioned a few weeks back how much I loved the grace tool, and I said I would make a video tutorial.. So here you go! This is the first time I have done a spoken tutorial so hope it turned out ok..
In the video I will go through setting up a grace project which will use a capture compare timer to blink an LED every 500ms. Normally for a new chip this would mean digging through data sheets to figure out how to set up a timer, not any more!!

More Weight Scales

The other day I managed to communicate with the ADS1131REF board via serial, but I was left stumped by the data I was getting. Turns out I was just being an idiot, the data returned was not weight data but the raw voltage reading from the output of the sensor. To convert the raw voltage to a usefull weight I needed to calibrate the sensor (of course!). The claibration uses the simple equation below to convert the sensor reading to a calibrated weight.

What's next?

So far I feel like my blog posts talk a whole lot but don't really show my progress, hopefully this weekend I can fix that by bringing a whole lot of this information together into something that resembles my original idea.

Cheers!

May 28th : Home Sweet Home

OK so I did not end up getting the super productive week that I had hoped, I was sent to the middle of the desert in WA for work instead. But I am back in the real world again now so let me try and remember where I was up to.

Launchpad Mini

So as part of my clever containers I designed a mini launchpad board sporting the MSP430G2553. I managed to fab it up using the toner transfer method, this is by far the smallest board I have made with this method, it is not the neatest soldering job but it works a treat..

I did have quite a bit of trouble initially actually, I very stupidly soldered a 47Ohm rather than a 47kOhm as the reset pullup resistor, I wont tell you how long it took me to find this mistake..

June 4th : Joining the Dots

So I have been able to spend some time putting all of the bits and pieces together and I now have something that resembles the idea I had a couple of months back. It is very much still in the prototype/test stage but it works almost as I expected it would. Actually considering all of the I2C, UART and WIFI bouncing around in there I am surprised it works at all..

First of all here is a picture of the system as it sits on my desk at the moment, and a close up of my clever container sitting on the smart shelf. The third picture is the GUI I have written using the QT creator, the GUI is measuring the level of the bread on the scales and the coffee in the clever container (or sugar as it was cheaper).

June 11th : A Little Bit Of Colour

So I remember reading somewhere that we are meant to be including some of the TI lighting solutions in our projects. This sort of this is right down my alley, as it happened I had a bunch of RGB LEDs some of the TLC59025 Led sink driver ICs and a faulty LED driver PCB from my RGB cube that I could cut/hack to make into something new.
At the moment I still have no idea how I am going to include my colourful little addition into my project, but I am sure I will think of something.

I didn't feel like multiplexing with my array so I am using one output for each red, green and blue diode in my LEDs, so for the 3x9 array that is a total of 81 outputs to control each LED individually. The TLC59025 LED driver are really easy to drive, you clock the output data into the shift registers and then latch the output to move the data from the shift registers to the drive registers. You can chain these ICs up in a long cascade to drive as many LEDs as you wish, I am using three separate chains to drive the red, green, and blue channels. This way I can clock in the three data lines at the same time speeding up the process a bit.
Check out these pictures I prepared earlier to "hopefully" get an idea of how to drive these things.

June 12th : Light it Up

Here is a quick video of my little display showing of its true colours. Unfortunately the quality is pretty shocking, I can never seem to get a good video of my light displays (anyone who knows some tricks for filming bright LEDs let me know).

I use Bit Angle Modulation (BAM) for the colour fading, 8 bit modulation allows me to generate 16 million or so colours. I am sure there are plenty of different ways to implement BAM but this is my way and it works, I store the current animation frame in a 9x3 matrix and the interrupt does the rest.

Because the launchpad is pretty strapped for memory and it is a bit sluggish when it comes to playing with floating point numbers, I needed a new way to generate a colour wheel. Usually I create a large array in memory, or use sine functions to generate the colours, this time I decided to go with a clever little conditional function.

My getColour function can generate 768 different colours, you hand the function an integer between 0 and 768 and it will spit out a colour from the colour wheel. I painted a picture below to try and explain myself a little better, the numbers in the image are the integer you hand to the getColour function... Obviously the function fades the colours a little better than I did in paint.

June 25th : Time To wrap it Up

So I think it is about time to compile what I have done so far and call it a day. Here is a bit of a video of my system as it is, as you can see there is still work to be done. My project so far is still definitely in the proof of concept stage but I think it does that nicely. I have a system which is easy to expand upon and no doubt I will continue to play with in the future, I think the idea has promise.

Once thing missing is the web integration, I need to work out a way to give my Bread & Butter project an online presence to make it really useful. I may try and integrate it into my website, I'm sure people will want to know what I have in the fridge..

I will make a final post tonight when I am not at work, this will have all circuit diagrams/eagle files, the code I have written (there is actually quite a lot) and what ever else I have to include to finish off the competition.

I will probably continue work on this project (slowly) for the next few months, it will all be available somewhere on the Internet. Most likely here and on my website www.HowNotToEngineer.com

Well it has been fun, I have learned a lot and got to play with some really cool toys. I would highly recommend going out and trying some of the TI equipment and tools.