Generating Ideas are like planting seeds. The planting is easy, it's keeping them alive that's challenging. So while some people gently cultivate their seeds in cosy climate controlled environments, others like me prefer to scatter seeds knowing that some will fall on fallow ground, some will be taken by others and some will germinate.
So I would like to thank Element14 and its collaborating partner Texas Instruments for pulling me out of my comfort zone and allowing me the opportunity to germinate this idea in the Internet of the Backyard Design Challenge glass house for all to see. As I like the learning by doing approach where it's all about the journey rather than the end result, this is going to be an interesting few weeks for me. Nothing like some hot coals under your feet to get you moving.
So what is my project all about.
I will use my IoT DNA template to explain my proposed solution structure...
D = Data capture, data channelling/filtering & data distribution.
N = Networks, nodes, notification process and knowing what talks to each other & how.
A = Alarms, alerts, actuations, authentications, access control and degree of automation.
My Data Capture Challenge:
The aim and challenge of my Grass Growing Monitoring System is all about the capturing of sensor data from nodes and hopefully unlocking value from this data by using the visualisation tools provided by Plot.ly. At this stage I'm keeping an open mind as to whether my theories work in practice.
Applying the theory of light reflection and absorption, sunlight or any other band of light should create small lux differences above and below grass level depending on time of day (the angle of light) and the height of grass (to envision, a little modelling helps thanks to Sketchup 3D and its shadow settings).
To capture LUX (degree of illuminance), I plan to use a light-to-digital converters that transform light intensity to a digital signal output. The ones I will be using are from TAOS and use the I2C protocol with changeable address registers. These sensor also provide two data outputs through a full spectrum broadband photodiode (visible plus infrared) as well as one infrared-responding photodiode. Most people apply the sensor by subtracting one from the other to get the visible spectrum of light, but I thought to try out something novel. I plan to add in some narrow focus IR emitters on my node which provides me with an input control mechanism. This will be especially useful at night where I hopefully be able to capture IR light changes on the sensors.
As I need to stick my sensor node vertically in the ground I also thought for good measure (i.e. a nice to have feature if it's doable) to measure soil moisture using a soil moisture sensor and soil temperature using a DIY soil temperature probe. Both of these will be analog signals, which may prove tricky. For some novelty I thought to convert the analogue readings to I2C especially as there are chips that do this for you using 18bit ADC conversion which could hopefully improve measurement accuracy at low voltages on a noisy prototyping board.
From an operational point of view, I though that for this to work all I need is very short data samples (no more than 1 second of sensor data capture) twice daily (morning and evening) and then once or twice (to be sure) at night when dark using IR emitters. The rest of the time the sensor node can sleep / hibernate etc.
As we are having very small data samples at node level, this data will be transmitted as soon as data capture has completed using wireless comms to either a central control unit that will relay to cloud via WiFi, if using RF devices on nodes, or nodes could send directly to cloud server (i.e. plot.ly streaming function) if using WiFi module directly on node. The choice between WiFi and RF is part technical, part commercial and part driven by past preference.
To be honest I have been prejudiced by previous WiFi modules (other brands) on the market and their cost and complexity, and so always start with RF unless compelled to do otherwise. It is only now sinking in, having done my sums that the commercials for the CC3200 look very good considering that the launchpad is around $30 (under €25). It is only for the very simple comms scenarios where RF still wins when combined with a cheap 8-bit micro. The determination of development complexity is only going to come out the wash through experience and this challenge.
For me personally, I was originally very sceptical of online compilers but when looking at them from a time to learn, time to develop, time to modify and time to market they are winning me over. Hence I now tend to start new projects by using development boards that are mbed enabled or I use one of TI's competitor WiFi modules (rhymes with limp). I also do not see myself as an embedded software engineer / technical specialist as I have more of a systems and data management skill set. Hence to test concepts and prototyping, I find it easier to use open source or IDE frameworks with very active online communities to help me along. Hence I am approaching the TI programming interface with great trepidation. However just to add that so far I am very impressed by the quality of TI's documentation. There are volumes to get through but so far so good.
Hence my choice for this challenge at the node level is to use RF with a tried and tested familiar micro rather than WiFi to give me enough time to get up to speed with the TI CCStudio as well as try to exploit all the features of the CC3200 in such a short space of time.
My Network and Node level design challenge:
I am therefore using the launchpad as the central controller which will act as gateway to the plot.ly system together with RF to talk to my nodes capturing the data. I have chosen a 433MHz module as these are easy to use and give good network coverage and will use either Arduino or ARM M0's for sensor control / data measurement.
I will also use the CC3200 laumchpad to provide other UI features and possible control mechanisms (e.g. use it to drive a solenoid attached to garden tap). The node structure for the challenge is to have up to 3 nodes. The eventual aim is multiple nodes placed across a garden, park, football pitch etc. and would look something like this (again thanks to Sketchup for the graphic wizardry):
My Notifications challenge:
Data visualisation is more important for my project than messaging at this stage. So on the CC3200 web page I will show the plot.ly charts. Notification and browsing of data will really just be for the authorised user(s). Public sharing of data can be handled elsewhere if needed in future.
I am no gardener so cannot assure others that what I have read is correct or otherwise. But there looks to be a "science" behind grass cutting, otherwise known as the "1/3rd rule". There is plenty of info on the net. Here are two links I found...
The aim of project is to eventually calibrate measurements to determine when grass longer than it should be. Unfortunately grass does not rapidly grow overnight so not sure if we will see anything of real significance during this challenge. The draft design of my node will look something like this... note for familiarity sake (and the fact I had a drawing of one already) my node diagram shows an Arduino, although I may to end up using an AMR M0/M0+ as preferred 3.3V controller. If I used WiFi on node itself instead of RF then the CC3200 would be an excellent candidate of choice (reasons as noted above) as well as the fact that it can work off 2 AA batteries. The challenge is then form rather than function to get all the components to fit neatly on the stick. Considering that there are already boards out there such as LPCXpresso, this would be possible to achieve. Batteries on my stick would be attached behind etc. At this stage no real thought on enclosure (outside scope of challenge really) but would think something like a clear acrylic (UV resistant?) cover, would work as well as some good 3M waterproofing / UV sealant on board itself.
Access Control and any Automation challenge:
There is no automation features in this project. Of course if system proves reliable and consistent at determining grass height and growth rates then who knows. Links to an irrigation system seem obvious enough. There are even these fancy Husqvarna lawn mowers (wouldn't we all want one of these) which could "link in" so as to become even more lazier and mow only when notified... https://www.youtube.com/watch?v=bpj7eUAA-fk
Finally brief progress report...
So far so good with getting started and running the demos. Uploaded CCStudio and seen some video tutorials. All good so far. Plan to start working through examples. UPDATE: having success with examples. Confidence is building but still a huge amount of info to get through.
In terms of board itself... well I have a saying (applies mainly to hardware), "a little asymmetry goes a long way". When I unpacked the Fuel Tank BoosterPack I found that it was not obvious which way to attach the thing as it fits either way round. It would have helped simple folk like me if there was some asymmetry by for example making one side 8x2 rows and the other 12x2 rows. This way I would be in no doubt which way to connect these packs. UPDATE: I just found the TI solution in their hardware guide (i.e. the recognise the issue). Unfortunately the battery pack does not provide the indicator... http://www.ti.com/lit/ug/swru372/swru372.pdf
Page 7 of hardware doc: "A compatible BoosterPack can be stacked on top of the LaunchPad using the 2x20 pin connectors. Note that the connectors do not have a “key” to prevent the misalignment of the pins or reverse connection. Ensure that Vcc and 5V pins, are aligned with the BoosterPack header pins. On the CC3200 LaunchPad, a small white triangle symbol is provided near Pin-1 (see Figure 3) to orient all BoosterPacks. This same marking, provided on compatible BoosterPacks, needs to be aligned before powering up the boards."
Regarding batterypack, I think as a future upgrade (together with triangle marker) they should enhance and include a connection for a solar panel to handle battery recharging. Otherwise delighted that I finally discovered the answer buried in documentation to the burning question of what is the "CHARGE-IN" point used for.