The goals of this post include:

Adding sensor readings taken where the LED hydroponics station is located and read from another location with my house.

Exploring the JeeLabs hardware and software as a solution to the home sensor network.

My Setup

In the last post, I set up the first of what I hope is many hydroponics systems – including the plants all the way to the LED arrays for lighting. Since then, I’ve added a sensor node to the hydroponics system that takes air and water temperature, and humidity. The sensor node then transmits the readings to a receiving node that is approximately 25′ (7.6m) from the sensor node. There is a wall between the receiving and the sensing nodes.

As I explore a variety of wireless options to build a home sensing network, I came across JeeLab’s home networking hardware and software platform. I got interested in trying these out after reading Jean-Claude Wippler’s blog postings. Jean-Claude created the JeeNode and jeeLink during his deep explorations into home sensor networking. He explored, posted his thoughts and findings, and created a software/hardware platform that tackles hard challenges like power consumption, choices of RF, and simplification of attaching sensors to the Arduino. While all his efforts are available as Open Source, he also sells hardware components that implement his findings. Having the ability for Jean-Claude to start a small business based on selling what are basically DIY kits is one of the things I love about the current state of “maker” software and hardware design. Bright and exploratory folks like Jean-Claude put a lot of effort and thought into their work. Through the kit, Jean-Claude provides something that is tangible and useful. I felt paying for his work was more than worth it, regardless if I continued with his home sensor network implementation past a cursory exploration. We only have so much time on this planet. By building on the work of others like Jean-Claude, I can learn at a level of abstraction that is best suited for my abilities and needs. I appreciate that we can support his efforts…the hours upon hours he has dedicated to sharing what he has learned – not through a packaged product from Home Depot – but rather as a kit that someone like me can pick up and learn by doing at a very reasonable price.

I purchased a JeeNode USB v3 and the 915 MHz JeeLink from Modern Device. Being a complete n00b to 433MHz and 915MHz(US)/868MHz (Eur), I asked Shawn at Modern Device which I should get if my goal was longest range. I must not have asked the question right because he recommended the 915 MHZ. As noted by a response from Martynj to a question I asked on the JeeLabs forum about different RF frequencies for home sensor networks:

“…the ISM bands are license-free, shared and not all vendors follow the rules/conventions. The band occupancy varies over time, perhaps invalidating a survey at a particular location.

So you fall back to the basic physics: The strongest signal wins:

good antennas count

433MHz is absorbed more passing through interior walls

Key is Signal/Noise ratio:

Slower data rates decode better in higher noise levels

Maybe another channel in the band is quieter

A rather fuzzy answer but too many YMMV factors to be more specific. The good news is that most “small” nets, with appropriate system design to cope with lost packets work just fine.”

Given the above, I would have preferred getting the 433 MHz – which is international unlike the 915 MHz. I have heard the reason to go with the 915 MHz has to do with less devices using 915 MHz thus a better chance to get a less noisy TX and RX. I’d hoped to use a JeeNode to plug in all the sensors than transmit the sensor data to a JeeLink. I wanted to have the JeeLink spit the sensor data out to the CC3000 breakout board that I discussed in this post.

I know I should have figured this out before ordering the JeeLink, but it would be quite a hack to gain access to the JeeLink’s SPI in order to communicate with the CC3000. From what I can tell, the JeeLink is best suited to being attached via its USB to a PC/Mac or Raspberry Pi. While having the nice plastic case around it is nice, it really is a very restrained Arduino + RFM12B.

CoGs

The components used for the JeeNode/JeeLink hydroponics sensor home network included:

The JeeNode

As noted in the description of the JeeNode I bought from moderndevice.com:

“The JeeNode USB contains Atmel’s ATmega328p AVR microcontroller and HopeRF’s RFM12B wireless radio module, as well as the FT232R USB interface. The ATmega is pre-flashed with the Arduino boot loader and theRF12demo sketch. See the JeeNode description for more details. JeeNode USBs are shipped with the ISM-band 915 MHz or 433 Mhz radio module for orders within the US. In Europe see the JeeLabs shop for 868 MHz radios.“

As shown in the image below, hooking up sensors is simplified by using ports. Adding a ports abstraction on top of the Arduino’s pins is a key simplification/differentiator of the JeeNode. I found it very easy to attach a digital or analog sensor. There has also been thought and implementation into a simple I2C interface so that sensors that use I2C can be easily strung together. The challenge I had with I2C in my minimum testing was the sensor would need a library that knows about the JeeNode. The sensors chosen for this exploration did not use the I2C bus. I’ll share what I learn if I get the chance to add sensors that use the I2C bus. This post provides more info on JeeNode’s I2C support.

Here are images of the JeeNode’s pin-out:

For now, I hooked up a DHT22 Humidity & Temperature sensor and a Waterproof Digital Thermal Probe Sensor DS18B20 (data sheet) to the JeeNode I bought. Getting the sketch working between a JeeNode and a JeeLink (discussed later) was very easy. A big reason for this is the stability / robustness of both the hardware and software libraries. The hardware I got from Modern Device worked very well. This is in contrast to the nRF24L01’s I purchased on eBay. It was hit or miss what would work on one of the nRF24L01’s. I should know better during prototyping to buy the hardware from places like Modern Device, Adafruit, Sparkfun… that care about the customer experience. I wanted to experiment with buying chips on eBay and see if the experience I had was similar to what others noted – quality is all over the map. My results shown this to be true. Moving forward for prototyping I will try to buy components only from “maker/hacker” companies that have robust product, great support, and a positive community behind them. I have had very positive experiences with all three companies I noted earlier. I am surprised what a “warm feeling” it gives me to buy from them. The additional cost at this point is definitely worth it for the additional value provided.

The other challenge is the pro/con of open source libraries. I scan each library I use. However at this point, I do not know the details of the internals of each c++ library. This is fine for the exploration/prototyping I am doing. Down the road I need to spend time/money on making sure each library I use is robust and efficient.

Reading Humidity and Air Temperature

The JeeNode I got came with four headers that needed to be soldered on. One for each Port. Easy-peasy. It reminds me of making a cake with a cake mix. Soldering the headers is like adding eggs and water. It makes me feel like I contributed to the building of the end product with minimal effort.

Staying with the theme of keeping things simple, JeeLabs provides their own library for the DHTXX. As noted in a blog post on Jeelabs.org: “There is code for these sensors floating around on the web, but it all seems more complicated than necessary, and I really didn’t want to have to use floating point. So I added a new “DHTxx” class to JeeLib which reads them out and reports temperature in tenths of a degree and humidity in tenths of a percent…and it compiles to less than 4 KB.“

After connecting the wires, I ran the dht_demo.ino sketch provided by JeeLabs.:

/// @dir dht_demo /// Demo readout of the DHT11 or DHT22 temperature/humidity sensors. /// @see http://jeelabs.org/2012/04/14/reading-out-dhtxx-sensors/ // 2012-04-02 <jc@wippler.nl> http://opensource.org/licenses/mit-license.php #include <JeeLib.h> DHTxx dht (5); // connected to DIO2 void setup () { Serial.begin(57600); Serial.println("

[dht_demo]"); } void loop () { int t, h; if (dht.reading(t, h)) { Serial.print("temperature = "); Serial.println(t); Serial.print("humidity = "); Serial.println(h); Serial.println(); } delay(3000); }

I changed

DHTxx dht (5);

to

DHTxx dht (4);

Since I was using Port 1 and not Port 2.

The first time I ran the sketch I was getting a Humidity reading of 10 and temperature of 0. Hmm…not right. I took this as an opportunity to try out JeeLabs support. I went to the support forum, signed up for an account, logged in and was all ready to write my question. I felt pretty dumb when I couldn’t figure out how to post a message. So I put my tail between my legs and sent Jean-Claude an email. Wow!!! – he responded within the hour. It turns out I needed to be added to a group. I just read at the bottom of this post that once I registered, my registration would be checked – which could take 24 hours. So it seems like I was impatient!

Jean-Claude pointed me to the code:

/// Interface for the DHT11 and DHT22 sensors, does not use floating point

class DHTxx {

byte pin;

public:

DHTxx (byte pinNum);

/// Results are returned in tenths of a degree and percent, respectively.

/// Set “precise” to true for the more accurate DHT21 and DHT22 sensors.

bool reading (int& temp, int &humi, bool precise =false);

};

Ah – too bad the dht_demo sketch didn’t use the precise parameter! I am using the DHT22 sensor. What the support experience points out to me is JeeLabs is built with great ideas and – so far – good product. But a very small staff. I certainly can relate to and support that!

Once I changed the dht.reading(t,h) to dht.reading(t,h,true) I got more reasonable readings – an humidity of 583 (58.3) and temperature of 167 Celsius (16.7).

dht.reading(t,h,true);

I bought a Waterproof Digital Thermal Probe Sensor DS18B20 (data sheet) from Amazon.com. Since this sensor has been around a long time, the least expensive place to buy one from would be eBay. I’m an Amazon Prime member so I paid a bit more for rapid delivery and free shipping.

The DS18B20 uses Dallas Semiconductor’s 1-wire bus system (i.e.: the “DS” in DS18B20) to communicate with an Arduino. From reading about the key features of the DS18B20, It appears this sensor was designed for scenarios in which there are many. Using the 1-Wire interface means only one pin is needed to address many different DS18B20’s. Also, it uses what is referred to as “Parasite-Power” – meaning the component can get power from a common source, not requiring a dedicated power supply. At first I was thrown by the term “parasitic” but then decided the person who named it saw this feature in a relationship with a power source in which it could just hop along for the ride.

And then…A Yippee! moment. There is a OneWire Library that has been written for the Arduino. The text describing the library notes a 4.7K pull-up resistor is required between the pin and + wire. The Adafruit learning pages has a diagram that shows the wiring for the DS18B20.









The OneWire Library comes with an example sketch. The only change I made was to the digital pin from 10 to 5. Since another digital pin was used for this sensor, I had to use the second JeeNode port. At this point I soldered in the remaining headers on the board and wired the water temperature sensor to port 2. The digital pin on port 2 is pin 5 (refer to the “pin and signal” image above).

I ran the sketch with this change and the Yippee! moment continued. It worked the first time (a very rare occurrence for me).

Arduino Sketches Used to Transmit from the JeeNode and Receive from the JeeLinks

The sketches I am running – rxSensorDataJeeNode (JeeLink) and txSensorDataNode (JeeNode) can be downloaded from here.

As I spent more time with the example One Wire sketch, I realized it’s goal is to send and receive data. I wanted a library that provided a better abstraction to retrieving the temperature from the DX18B20. I found the Dallas Temperature Control library written by Miles Burton works well. With the aid of this library, it was easy to write rxSensorDataJeeNode.ino based off the Tester.ino sketch that comes with the library.

I tested both 9 and 12 bit precision and felt 9 bit precision was “good enough.”

As I scanned through the library, DallasTemperature.cpp, I notices besides the functions that return a floating point value for the water temperature (getTempC() and getTempF), there is also a function that returns an uint16_t value for the water temperature (getTemp()). I like the idea of simplifying, so instead of using floating point math and conversion to Fahrenheit, I used the getTemp() function. As noted in DallasTemperature.cpp, to get the reading in celsius, the number is divided by 16. So after retrieving the number, I bit shifted right by 4 – which is the same as dividing by 16.

The other “gotcha” I ran into was removing a call to the function that resets reading the temperature. When I removed, the water temperature would read 85 – which was not accurate at all! – when I reset the JeeNode. I put in the call to requestTemperaturesByAddress() and all worked well.

Sending the Readings to a “Base System”

My definition of a base system is an Arduino based collector of sensor data that both stores locally and sends the sensor readings and alerts to a web site.

The base station will be built step by step. In this step, the base station will simply be a JeeLink that receives data from the JeeNode.

The JeeLink

The JeeLink consists of a ATmega32 @ 16MHz + RFM12B + compatibility with the Arduino IDE. It acts as the “plug-n-play” receive of sensor data from a JeeNode. It is packaged in a clear plastic casing. I find the clear plastic casing to be a relief to me since unlike my other Arduinos, I don’t feel the JeeLink is as exposed to my spilling of the huge quantities of liquid I ingest while I play with it.

Results

The JeeNode sends the air and water temperature along with the humidity to the JeeLink. The rxSensorDataJeeNode.ino

All results are of data type uint16_t. Note the JeeLabs readings of air temperature and humidity (using the DHTXX library) provide a one decimal precision. For example, the air temperature recorded was 21.3 C.

Currently the sensor data is not being stored – either locally or on the web. That will be addressed in my next update to this home hydroponics sensor network.

What’s next

Within the stages of crawl, walk, run – I am definitely in the crawling stages when it comes to having an quantifiable and automated home hydroponics system. This small step helped me better understand one possible home network solution based on Hope RF’s RFM12B as implemented on Jean-Claud’s JeeNode. I am happy to support the JeeLabs effort because the continued efforts of Jean-Claude and the community that has rallied around JeeLabs provides smart thinking and implementation in the area of home sensor networks. As with all steps in which I try stuff out, I have a better view on what next to focus on. I will soon start:

adding 802.11 to the “base system” and sending the sensor results to a web server

adding a data logger to the “base system” to accommodate the times when the web server can’t be reached or to keep more granular data than what I transmit to a web server.

I then wish to:

explore and add TDS measurements

explore and add pH measurements

add an LED to the sensor node that is green when data is sent and red when data cannot be sent

add better error detection and reporting

keep evaluating home sensor network RF solutions

add several (6 or more?) sensor nodes

look into switching 802.11 with an Ethernet connection for the base system, since there will be one in the home and can be hooked up to an Ethernet connection on (one of my) router.

make a PCB hydroponics sensor node and base system.

other priorities as I gain more experience in hydroponics, home sensor networks, Arduinos, and manufacturing PCBs.

One challenge I noted was the future demise of the RFM12B from Hope RF. Of course challenges bring opportunities, so what will be better? For now, I’ve included a section on announcements and rebuttals regarding Hope RF’s support of the RFM12B.

Is the RFM12B’s Life About to End?

Wait just a second…am I starting to explore a RF solution that is going extinct? Should I continue with RFM12B solutions?

A thread on the JeeLabs forum was started a few months ago. The topic was how the manufacturer of the RFM12B (Hope RF) is stopping production of this chip and moving on to the RFM69W

This topic reminds me of an end of term exam:

Contrast and compare the following phrases.

If it ain’t broke, don’t fix it! (T.B. Lance)

That (design) is so ’90’s (DIY TV)

Agreed, for the RFM12B series, the underlying Silicon Labs chip is an “old” design, but so is the venerable 555 chip. It has “legacy” status for some time. That in itself doesn’t imply much – simply that if you have any technical questions not covered in the existing documentation, don’t call Tech Support!

The design is sound, the process is stable and Hope RF makes them in 10,000 batches, starting from raw silicon wafers. Yes, Hope have flagged some Distributors that the family is ‘reaching end of life’, perhaps partly in an attempt to promote more recent designs. But Manufacturers are pragmatic, as long as the bulk orders keep coming in, they will keep making them. The original R&D cost is long since paid off so this keeps the burdened cost low and their margins healthy.

The suggested “replacement” module is a poor match. It is not form, pin or functionally compatible, so considerable work will be needed to adapt to it. It does have some enhancements for very low energy consumption, more flexible modulation schemes etc. and is around the same price point. IMHO, it is a poor strategy to expect your customer base to jump through hoops to make un-asked for changes – this risks throwing open the doors on evaluation of other vendors.

Yes, eventually the product family will become unobtainable. But by a stroke of brilliant foresight (actually not, just from the need to order very large quantities to keep the Shop prices as economical as possible) JeeLabs has access to stock levels that will last, at the current run rate, with growth, well into 2014. And yes, bring your creditcard, HopeRF are accepting orders right now and have not issued even a hint of a date when this may stop.

Bottom line – Rumours of my death are greatly exaggerated. (Mark Twain)

Jean-Claude wrote an enlightening post about JeeNode’s future regarding the RFM12B.

My Thoughts on JeeLabs Hardware and Software

My conclusion is the JeeNode hardware and software is stable and has the design and implementation considerations that are important to me. They solve the challenge of a simple sensor node that is easy to use and appears to have enough range for my prototype network. I will continue to evaluate alternatives but will probably go ahead and use JeeNodes (or at least the RFM12B with JeeNodes) as the wireless network for the home network sensor piece.



