Group Actions
Engagement
  • Author Author: BigG
  • Date Created: Date Created
  • Views 1521 views
  • Likes 1 like
  • Comments 4 comments
Related
Recommended

[IoT_Grass #6] IoT Backyard Challenge GGMS - Summary

BigG

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 Plot.ly 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="https://plot.ly/~BigG/4.embed?width=800&height=600"></iframe>

 

<iframe width="800" height="600" frameborder="0" seamless="seamless" scrolling="no" src="https://plot.ly/~BigG/5.embed?width=800&height=600"></iframe>

 

But first things first. I would like to thank Element14 and its co-sponsors Texas Instruments and Plot.ly for selecting my project to roadtest the TI Simplelink CC3200 WiFi Launchpad and to demonstrate the graphing power of Plot.ly 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: https://www.adafruit.com/product/439). (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:

 

image

 

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):

 

image

 

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

 

image

 

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

 

image

 

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 (https://learn.adafruit.com/tsl2561/downloads) 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 Plot.ly I created my own code which was based off Plot.ly'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 Plot.ly to improve timestamping of my data points. At present the CC3200 handles 18 Plot.ly 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 Plot.ly 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 Plot.ly 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 Plot.ly 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 Plot.ly 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

 

image

 

Over the course of this challenge the data streamed to Plot.ly 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):

 

image

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:

 

image

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

 

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

Attachments:
imageIoT_Backyard_GrassNode_Overview.pdf
  • in reply to janisalnis

    Yes nice to see that at least one of my nodes is still working through the tough weather conditions, considering that I did not coat the boards with sealant (I should have as it's now caused damage on node 1). We've had so much rain of late and with the cold mornings plenty of condensation. Here is node 2 this morning...

     

    image

  • in reply to janisalnis

    Sure, here is a quick explanation of the transceiver.

     

    The HC-12 Serial Port Communication Module operates within 433 to 473 MHz frequency range with up to 100 channels spaced at 400kHz intervals. 20dBm max transmit power with 8 power transmission settings. Receiver sensitivity -117dBm at 5000bps. The module has 5 connector pins: VCC (3.2 to 5.5V), GND, RXD, TXD and Command SET pin. To send data (communicate) via TXD, or receive data via RXD, you set the Command SET pin HIGH. Command settings are changed using basic AT commands and these are done when you have Command SET pin LOW. The useful commands are as follows:

     

    As explained, I coded using Energia, which is very straightforward. Here is a cut and paste of the code extract (apologies if I unwittingly created error).

     

    #define hcINT             11
#define HC12              Serial1

#define  NODE_ID1         0x11 

const unsigned int
  RFTIMEOUT =              2000,
BUFFsize =               48;

String
  charString =           "";

unsigned long
  t_now =                 0L;

void setup() {
  pinMode(hcINT, OUTPUT);
  Serial.begin(9600);
  HC12.begin(9600);

  Serial.println("Checking HC12 is working");
  Serial.println("");
  delay(500);

  digitalWrite(hcINT, LOW);
  delay(100);
  Serial.println("AT");
  HC12.print("AT");
  HC12.flush();
  delay(5);
  checkRFresponse();
  Serial.println(charString);
  delay(5);
  if (charString.equalsIgnoreCase("OK")) {
    HC12.println("AT+DEFAULT");
    // INSERT YOUR PREFERRED AT COMMANDS HERE
    delay(15);
    checkRFresponse();
    Serial.println(charString);
    delay(45);
    digitalWrite(hcINT, HIGH); // Ready to receive data
  
    // INSERT REST OF YOUR APPLICATION SET UP CODE HERE
} else {
   Serial.println("HC12 Error - No response received");
   while (1);
   // OR INSERT ERROR CORRECTION / FIXES HERE
  }
}

void loop() {
  if (HC12.available()) {
    checkRFresponse();
    charString.trim();
    Serial.println(charString);
      // This is a code snippet showing how data transmiited using print command. Alternative can use write command to send bytes etc.
      if (charString.startsWith("N_") && charString.indexOf("17")) Serial.println(charString);      // Notification that Remote Node has just initialised
      else if (charString.toInt() == int(NODE_ID1)) {
          HC12.println(charString);
          HC12.flush();
          //NODE_ID1recd = true;
        }
}
}


/**************************************************************************/
/*
    Clears the serial char buffer used for RF communication
*/
/**************************************************************************/


void clearBuff(char *buffName, int multi)
{
  for (int i = 0; i<BUFFsize*multi; i++)
    buffName[i] = NULL;
}


/**************************************************************************/
/*
    Standard routine that waits to hear back from RF device
*/
/**************************************************************************/


void checkRFresponse()
{
  t_now = millis();
  charString = "";
  while(1) {
    if (HC12.available()) {
      HC12.readBytesUntil('\n', charBuff, BUFFsize);
    }
    if (charBuff[0]) {
      charString = &charBuff[0];
      charString.trim();
      clearBuff(charBuff, 1);
      if (charString.length()) break;
    }
   if ((millis() - t_now) > RFTIMEOUT) break;
  }
}

     

    Re plotly. I only set my max points as 30 on one chart and 45 on another. This can be increased to get a longer time span / show more data on chart. I am also updating every 4 minutes or so, which is not really needed but was doing for demo and testing (i.e. to learn about behaviour etc.). If interval extended or even better I set trigger thresholds on preset events (e.g there is no real need to send periodic data overnight) I can get far more than 6 hours if needed. But you are right for long term event datalogging I would use in combination with another cloud based system.

     

    I quite like Temboo, which is a new arrival that has huge potential through its own SDK as you can use to interface with any web service API. They already have a good range of libraries which can also be used.

  • Great post!

     

    Liked your wireless transmitter node concepts.

    I would like to learn how you implemented the serial port RX TX with CC3200. Could you share the code, please.

     

    It is nice what you could manage to do with Plotly. I looked today that your plots are still updating live. You visualise only the last 6 hours. May be it is true that who cares about older things.

  • Very good post.

     

    Good detail, well written, follows a logical progression and provides good test results.

     

    Well Done,

     

    DAB