And so the IoT Backyard challenge is sadly drawing to a close. Like most engineers, no project is ever really complete as there is always room for improvement and so I feel as if I've only just got started with developing my application. The TI Simplelink CC3200 WiFi Launchpad has proved to be a great MCU board to work with and offers great value and versatility (offers 2 coding methods through CCS or Energia). I am now streaming 18 data points to through their API. I have 2 charts created using 9 tokens for each. Here they are (these charts are live and so show everything as is, including strange once off events as I write... Also note that these links may go off line at any time without notice).


<iframe width="800" height="600" frameborder="0" seamless="seamless" scrolling="no" src=""></iframe>


<iframe width="800" height="600" frameborder="0" seamless="seamless" scrolling="no" src=""></iframe>


But first things first. I would like to thank Element14 and its co-sponsors Texas Instruments and for selecting my project to roadtest the TI Simplelink CC3200 WiFi Launchpad and to demonstrate the graphing power of by showing that it can help ascertain grass length in a garden, field etc. This challenge has allowed me to germinate an idea and to apply the learning by doing approach of developing a working prototype during the past 10 weeks or so. Hopefully each of my previous blogs gave you sufficient insight into the challenges I faced and achievements made along the way.


It started with me sketching out the key challenges involved in the project using an IoT DNA template:

  • ascertaining what Data to capture
  • assessment of communication Network, design of sensor Nodes and what type of Notifications or messaging needs to be applied
  • and finally, development of logic to reduce manual intervention and to Automate as much as possible with a review on types of Alarms and Alerts that would ensure the system works dependably


The other aim of mine was to keep things simple and to apply the approach of get the logic right first to allow me to Test Early, Test Often and to Test following a Structured Process. As such my intentions were to utilise ready made open source hardware modules where ever possible and to bundle these into something suitable to deliver the objective of my project. This method means you often have to compromise on achieving maximum design efficiency on things like power management, memory, processing performance in exchange for having a module that you know just works.


As such after tweaking here and my final grass node was eventually built using the following components (Total Cost: $75 rounded up per node)


  • Arduino Pro Mini 328 3.3V/8MHz was used primarily because of its form factor (small enough to fit onto node) and because it included a relatively efficient voltage regulator for battery power usage. It also had sufficient memory for my purposes. (Cost $9.95 from Sparkfun)
  • 3 x Adafruit TSL2561 Digital Luminosity/Lux/Light Sensor Breakout modules were used as these were individually addressable using I2C prototcol, they had the required pull-up resistors already included and the TSL2561 has very low current draw of about 0.5mA when actively sensing, and less than 15 uA when in powerdown mode (source Adafruit: (Cost $5.95 each from Adafruit)
  • HC-12 wireless serial port communication module (Buy 433Mhz Wireless Serial Transceiver Module - 1 Kilometer [800132001] | Seeedstudio) was used as these are very compact, easy to use, have power transmission / power saving settings and provide good radio coverage with good distance and work through walls etc. allowing sensors which are outside to communicate with CC3200 which was inside (Cost $12.90 from Seeedstudio).
  • Grove moisture sensor was chosen only because I had some of them lying around as they are not really suitable for long term use (see picture below) and were primarily used to peg the sensor node into the ground. (Cost $4.90 from SeeedStudio)
  • A Water sensor from SeeedStudio was used to detect rain / dew in grass as I had one spare and I also made a DIY version too. (Cost: $2.90)
  • A waterproof 2xAA Battery Holder with On/Off Switch from Adafruit (Cost: $3.95)
  • A clear enclosure from SeeedStudio (Cost: $2.90)
  • A 1/2 of a prototyping board from Farnell (Cost: $7.50)
  • Sundaries such as wiring, 2 x Lithium 3.6V batteries, LED's etc. (Cost: $12)


To illustrate the evolution of my grass nodes, here is the first one which did not work out due to wiring issues and was not used:




This was my second grass node, which was made using 2 protoboards and 4xAA battery holder sandwiched between, inside a DIY wooden enclosure with clear cover and some trusty Sugru (FIX THAT THING | Sugru) to help seal it (tape was added later to protect from heavy rain):




Then finally the third node was made on a single protoboard and placed inside a transparent off-the-shelf enclosure:




Here are the two nodes in the grass placed side by side for "photo opportunity":




The CC3200 WiFi Launchpad was used as the gateway to the Internet and received the data from the nodes through a HC-12 RF module attached to the Serial1 port, as defined by the Energia pin map for cc3200 (Guide_CC3200LaunchPad | Energia).


An overview of the system is attached below in a PDF file. The system was coded using the Wiring framework (Arduino IDE for grass nodes and Energia IDE for CC3200 WiFi Launchpad).


For Arduino I made use of the Adafruit libraries ( to capture Lux data. I used the default configuration options to get me started and proved sufficient to provide good data during the day. At night, if I used IR LED's I would need to (i.e. would need to amend code) increase sampling sensitivities and use dedicated IR channel to ensure a more accurate reading. I had originally intended to attach an I2C UV sensor but there was not enough memory available and hence put aside. Besides there is no real value to have a UV sensor attached on each node. Hence a separate UV sensor node is in the pipeline as future system enhancement which will also include an ambient temperature sensor to capture more environmental information. Arduino is put into a deep sleep and wakes up periodically based on an AVR timer method.


For CC3200 WiFi Launchpad I made use of the WiFi client library to connect my launchpad to my local WiFi network. I also used the Temboo email library, which proved very easy to use, to provide email notifications from my system. To send data to I created my own code which was based off's standard Arduino library code. See my previous blog which has code attached. A number of tweaks have been made subsequently to increase the number of data streams sent to to improve timestamping of my data points. At present the CC3200 handles 18 streaming tokens as well as incorporate the Temboo functionality without issue.


Originally I had intended to include a web server interface using the OOB example as reference through CCS and had successfully created and uploaded html pages and images using the Bootstrap template (see previous blog). However as I found through testing, uploading images and html to flash significantly limits the amount of available space on the flash for code. When I left my html and image files on the flash I only had 64kbytes of flash available. With flash reformatted I have the full 260kbytes available. At the moment my program is 82kbytes offering good scope for further enhancements and more data capture possibilities.


Data transfer between wireless nodes and CC3200 uses a very basic communication method where nodes publish data based on timing and internal events and cc3200 simply listens out for RF communication.


For example, if and when any wireless node starts or reboots it transmits a simple notification message "NS_11" where 11 represents the node ID. It is not critical if these messages are missed by CC3200 but as I only have a few nodes they've always been picked up. When CC3200 sees the "NS_" identifier this triggers a notification email to say that Node 11 has just rebooted. This method very quickly helps you identify if a node is "in trouble" and is frequently rebooting / resetting itself. Before any node transmits data it sends out a notification message and then waits for a confirmation message back from CC3200 to say it is ready to receive data. Once cleared to transmit, the node publishes information (see PDF for data format and more detail). At present no further checking is made as proven to be quite resilient in this case (no doubt if nodes were further away and / or in a more "noisy" environment I would need to add in further checks and balances).


The CC3200 main task is to parse the data received from the nodes and to stream this data to for charting purposes. It also monitors how frequently each node sends data. If no data has been received from a node for sometime a timeout event is triggered which causes an email notification message to be sent informing you that communication has been lost between CC3200 and the node. This is most likely to happen due to loss of power on the node due to battery issues (at present I am not actively monitoring battery voltage on the node and is something which would be needed as future enhancement).


The CC3200 also monitors itself and send out an email if and when it restarts.


An underlying purpose of the project was to use the functionality of to ascertain automation criteria, such as notifying the user when grass growth is reached a preset threshold. As in previous blog, early indications have proved that Lux sensors could be used for such purposes. Other novel features have also come to light, such as monitoring Lux spikes at night (e.g. has a security application for remote locations outside where car headlines or torchlight would be detected and could trigger a notification message) or how often it rains and for how long (similar for dew point / condensation on grass through water detection sensor).


Proper application of can also assist the user in correctly interpreting data being streamed. I illustrate by way of example. The most common form of time series charting is a line drawn on the chart. The first common mistake made is if the scale changes on the y-axis. On you can fix the y-scale to ensure that ='ve or -'ve changes seen remain consistent and you also have the ability to change the scale itself from linear to logarithmic scale. Another technique which I have applied is to use colour coded bands to help you ascertain significance of delta y. These bands do not need to be a straight line and do not need to remain fixed at a certain level. Thus in my case the bands help you interpret your data




Over the course of this challenge the data streamed to has helped me formulate thresholds and logic that can now be used to automate notifications, alarms and alerts.


Here is one where I used a torch to see if node 1 was working ok in the heavy rain (code has been amended so that if and when very low light is detected all ratios remain at zero to prevent spurious data being shown):


moisture_and_lux_sensor_data_from_node_1 (8).png

This chart shows when the IR LED's turned off once daylight was detected again (only node 2 had the IR LED's would turn on if no visible light was detected). As you can see a different bottom/middle/top lux relationship exists when IR LED's were used:


moisture_and_lux_sensor_data_from_node_2 (2).png

So overall I have been very pleased with the progress made using CC3200 and the results I have produced on


I very much look forward to tackling the next challenge if and when it presents itself.