[IoT_Grass #4] IoT Backyard Challenge GGMS - Time flies when waiting for grass to grow

Thanks to an unseasonally warm September month I finally have plenty of long grass to work with...

and the grass sensor node is coming along slowly but surely. Here is my first attempt at the grass node sitting in shorter grass... yes I mowed the grass too (well most of it as still need the long grass for testing).

By way of summary of progress.... not quite like clockwork...

Quite a few mistakes were made on my first build attempt. Firstly, the placement of wiring was messy and then the gap right between the two boards to accommodate the battery was too narrow. I fell into the classic trap of rushing to build due to the tight deadline before thinking through the design. So word of advice, don't forget to some engineering before doing some making. I am a great fan of the Fritzing breadboard mode as this mode quickly validates your wiring layout and you get a nice visualisation too of how things are connected (2nd design of mine shown later on).

Anyhow, my first hack attempt very quickly flagged a shortcoming in my original design (so okay the rush to build did have a benefit in my case - so next tip, don't over analyse and wait till things are perfect before making something). It highlighted once again that both hardware design and software development have to be considered in tandem from the very start of a project. One feeds off the other, so don't treat as sequential steps. I had intended to use two Adafruit breakout boards, the TSL2591  as the top light detection sensor as had a greater dynamic range (to avoid saturation) and then 2 x TSL2561's for the middle and bottom sensors as these were cheaper and also one could change the I2C addresses with these boards so they would not conflict the TSL2591 (which you could not address). This seemed a reasonable approach from a hardware design point of view. However, once you start to look at the software development side, you immediately find yourself making more work for yourself trying to handle two types of I2C devices.

Hence I am now using 3 x TSL2561's, each with their own unique address (as this is possible) and all I needed to do in the software point is use the Adafruit open source library and create three instances of the class for top, middle and lower sensor. With I2C I simple join the SDA and SCL of each board and as they already have pullup resistors all the work was taken care of. As I was never planning to take continuous readings I have now decided to utilise the interrupt pin on one of the TSL2561's and set up a low light threshold trigger to wake up the grass node as I only want to take measurements when light is low (hence I will never have the saturation problem in this case). The interrupt feature is a really handy feature for my application.

So now that the main part of the sensor design was sorted, the next step was review the wiring layout to determine how many input output pins I needed to help determine which MCU would work best. I was fortunate enough to get hold of a LaunchPad MSP430G2553 for the purposes of seeing whether this MCU would do the trick. I used Energia as my method to get "to know" the board. I had no problems using Energia for the basic examples and the compile and upload process removed all the headaches I was getting when using CCS. Energia is a bit like buying a simple hatchback to drive and go about your business. I find this really helpful with the prototyping stage. With CCS, you are getting a high performance hatchback but you first have to train to become a mechanic as you would be expected rather than required to know the ins and outs of the engine and would need to adjust the suspension before you drive the vehicle. However, the Energia system needs to mature so expect a few quirks along the way. I did not have success using the TSL2561 library as it makes reference to AVR routines and I did not want to spend time just yet manually checking throught.

Also other tests did not quite go the way I wanted using I2C on the MSP430G2 board as it did not have enough memory to do what I needed to do (mainly because of all the extra debugging / test code I added to see how things are doing). Maybe once the code is optimised it would shrink down significantly to make this workable, as this board does have some good positives and compiles really easy. So I decided to stick with what I know best as this ensures all the logic is sorted out in the code, which then ultimately feeds back to choice of hardware (remember they are intrinsically linked).

Here is the Fritzing wiring layout of the node design so far:

And here is the prototype all wired up and ready for its first tests:

The MCU board for the node to get me to first test of logic is an Arduino pro mini 3.3V as it has a reasonably efficient voltage regulator on board, which at least takes away that headache to get me started. However, I find putting Arduino's to sleep to really be a pain in the neck.

The node has a moisture sensor which doubles up as the means to peg the node into the ground. An optional temperature probe could also be included as the 3rd "peg" in the ground.

According to Spectral responsivity of light sensor (see chart) channel 1 is more sensitive closer to the 800nm range, so I decided to use two Infrared LED's at different wavelength, one at 890nm and one at 940nm to provide a better spectrum of light for the sensor to pick up. This will probably require tweaking down the line. I am also using LED's with a narrower beam angle of 10 to 15 degrees.

I am also using an HC12 433MHz serial RF device to handle communication between the node and the CC3200, which is the main controller and gateway to the internet. The aim would be to create a wireless sensor network using (most probably) the MQTT-SN messaging protocol if the CC3200 was externally powered rather than battery powered, as the CC3200 would act as my messaging broker. However, as the aim is for the CC3200 to operate off batteries or solar power with backup battery, this method would not work as the CC3200 has to sleep as well. So I need to have a means to wake up the CC3200 using the serial RF device first then it can process the messaging payload from the RF device and then it can go back to sleep again. Hence this will have to be interrupt driven.

To close off. I had put the CC3200 to one side for a couple of weeks to help the brain absorb and digest all the information. I will be getting back to this part of the project now that things are becoming much clearer and my first node is built.