RoadTest: TI Single Node Wireless Sensing Bundle
Author: eortiz45
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: ZigBee modules with Arduino.
What were the biggest problems encountered?: Some initial software hiccups with Energia 18. Limited documentation on the Anaren side.
Detailed Review:
My Roadtest for the TI Single Node Sensing Bundle
Last year, I was fortunate enough to be selected to road test a TI Single Node Sensing Bundle, which included the following boards:
A sweet little combo that allowed me to prototype a couple of wireless projects that I had on my mind for some time.
The contents of these kits are pretty standard if you are familiar with the Launchpad family of boards. The CC3200 is a WiFi enabled board, built around the ARM Cortex-M4 microcontroller. The MSP430FR6989 is a flash-ram based MSP430 device, with an LCD on board (which is super helpful for debugging wireless applications, more on that later). The CC110L booster pack includes two Anaren AIR based booster packs that are compatible with the booster pack standard, so you can use them in pretty much all launchpads, as long as they don’t interfere in pin usage. It’s important to note that you need two of these boards to create your network.
In addition to the contents of the kits, I had an MSP432 based Launchpad that I use in my current work, so I used it in conjunction with the sensing bundle to create my prototypes.
As with all embedded device hardware, they are only as good as the software and documentation that accompanies them and this is the area that I suffered the most with these kits. Why? Because we tend to forget that crucial step from prototype to finished product, and it was really harder than I expected.
I started with my usual tool for Launchpads: Energia, the tried and true IDE that I have been using for some time for my hobby projects. I had version 17 installed in my computer, but I saw that version 18 was readily available, so I figured I would try the new version … and it was a huge mistake. At this point, I didn’t have a project; I just wanted to replicate what we saw in the webcast that accompanied this sensing bundle, so I plugged one of the AIR modules to the FR6989, loaded the WirelessTest example from energia and it compile perfectly, loaded it into the board, simple enough. Now, I needed a second module to actually test the boards, so I connected the other AIR module to the included CC3200 launchpad and plugged it in. When I tried to change the Energia target board, I noticed that the new version had this board manager thing, so I had to download the support for CC3200. And then it happen, WirelessTest failed to compile: tens of compilation errors referring to missing libraries and files. I swapped the AIR to my MSP432… no luck. To make the story short, after two or three hours of reading, playing around with the libraries and the source files, I wasn’t able to compile any example that included the AIR modules, none, zero. I was about ready to give up on Energia, I was even downloading CCS, when I figured I would try my old Energia installation, version 17. And it worked! Everything, out of the box, for both the MSP432 and CC3200. So I figured there is something broken in my E18 install, I would love to hear from someone who knows what I’m doing wrong.
Now, let me be clear, these modules are fantastic for quick prototyping of ideas; I went from concept to working prototypes in a matter of a few hours, and I was super happy with the support from Energia once I got it working, but the initial frustration was bigger than I was used to with Energia, and certainly not expected.
As I mentioned, I had two prototypes in mind when I got the boards, one of them intended for data collection at my workplace, and the other one for experimental data gathering.
I tackled the data collection first as it was the simplest one. At work, we have a small “atmospheric isolation chamber”, which is to say a glorified test chamber where we want to control the temperature and humidity in a 10x10x5in volume. This is accomplished through a Peltier module that draws heat from the sealed chamber. So we wanted to independently (that is, not using the build in temperature sensor in the peltier module) monitor the temperature inside the sealed chamber, so we could compare in real time what the module was telling us versus another source of measurement. Due to the size of the chamber, we didn’t want to stick a thermometer in the chamber, so we used a small temperature sensor, connected through the I2C to my MSP432 launchpad, with the AIR module attached to it.
The second AIR module is connected to the FR6989 Launchpad and I used the LCD screen to display the temperature readings and signal strength of the link. And let me tell you, it worked beautifully. I started my design with the simple WirelessTest sketch from Energia that created a continuous back and forth communication between the two devices. Then I modified this example to interrogate the slave AIR module at a given interval. The FR6989 would receive the data and put it into the LCD screen, and write it to a serial interface for logging purposes.
The LCD on the FR6989 also became a superb tool to characterize the modules themselves, as I modified the example to also show the signal strength, using the RSSI from the AIR module; I just converted this to a series of 4 bars that were displayed in the Launchpad. Using this I came to two interesting conclusions about the AIR modules:
For this particular application, range was not a big concern, since we had the two boards just inches away from each other, and the transmission power was good enough to travel through the acrylic walls of the chamber.
Overall, it was a great solution, and it took us from concept to working prototype just a couple of days. Coding was maybe just a few hours, and characterization was a whole afternoon.
Now, in my particular industry, every external software library that we use is consider SOUP (software of unknown pedigree), unless we go through the process of validating the libraries and the software for an intended purpose. And this is where I had a really hard time taking my prototype from Energia to something acceptable for my management that I could certify in earnest. When I started digging into porting the Energia project to CCS, or porting it over to IAR, that’s when I realized the task was bigger than I expected. The amount of library over library that Energia includes for these examples to run is huge. But that is the price we pay for simplicity in prototyping, and not really the fault of the devices, so consider it an annoyance but not a deal breaker.
For my second project, I wanted to create a solution for a distributed sensor network. The use case is simple, imagine you have a long stretch of rainforest and you want to monitor a series of environmental parameters over a series of days, you don’t want to go walking to each predefined spot to read the sensors, so you place multiple “sensor boards” right in the boundary of wireless range between boards, like this:
The idea is that the sensor network will “self-discover” its nodes and figure out which other nodes are before and after an individual node. So the network inquiry will start from the node that is connected to the CC3200, which is connected to the internet or a host PC. This node will use the broadcast feature to scan for other nodes, in theory, this node will only see one other node, and this will be the first slave node. This new node will in turn initiate a broadcast looking for more nodes, and it should only find two nodes, one that is already its master and a new slave node. This will continue until the last node will only find its master, and will identify itself as the end node. With this information, a message chain will flow from the end-node to the master-node that contains the information of the network and some characterization. After this, the master node will be able to send messages to specific nodes, even if the node is too far away to be reached from the master. Also, the master node will be able to coordinate simultaneous readings of environment data, utilizing a real-time clock to synchronize the nodes.
This is a very interesting and fun project, and I was able to implement the master and slave nodes in an afternoon of work, utilizing the examples located in Energia, and the code I already developed for the other project. Once again, I went from idea to functional prototype in an afternoon, a very powerful proposal when we are talking about wireless applications.
My overall impression with this kit is that I would really recommend it for the hobbyist that wants to enable short range, low power networks on their projects. Apart from the software issues that I experienced with Energia (most likely my fault, or sheer ignorance), I was able to create concepts very fast, with a minimum level of fuzz.
Now, taking these projects or prototypes, to next, professional level are a different story, and I wouldn’t personally consider these AIR modules my first choice for professional solutions, in my opinion the documentation from Anaren is not that great, but maybe their commercial support is better.
Overall, a great kit, a quick and easy way of adding low power wireless communication to your projects.
