Associating Parts to the Schematic Symbols for a RFM69 Breakout Board

Tags

433MHz, arduino, Schematics and Board Layouts

In my last post, I created a schematic for a RFM69HW breakout board.  I am using this effort to increase my understanding of what we are covering in the Contextual Electronics class and understanding of electronic concepts/practical implementations.  This post is the next step in the process of going from “gee – I could use a breakout board that did…” to “I am using a breakout board that I built.”  As it is said: “give a man person a fish and you feed him them for a day; teach a man person to fish and you feed him them for a lifetime”

This post is dah BoM!   Files for the schematic, net list, and BoM can be found on the bitknitting github repository.

Thanks to Those that Go Before

I continue to experience a sense of gratitude to the amazing community of knowledgable engineers who willingly share their knowledge.  THANK YOU! I’ve never enjoyed learning so much (and I am getting better at realizing “Google is my friend!” 🙂 ).

It is important to take a moment and acknowledge these exceptional efforts.

• The folks I noted in my last post – plutonomore, Felix from lowpoweredlab.com, Adafriuit
• Chris Gammel – our very knowledgable and gifted instructor of Contextual Electronics.  A course I would highly recommend if you are interested in turning your prototypes into PCBs and learning tons about electronics along the way.
• Chip – who provided actionable feedback on this post.  His  comment was on chip power dissipation.  I added it when I discuss the part choice for the voltage regulator.  Chip’s feedback is a big reason why I write these posts.  More please!!!!

THANK YOU VERY MUCH!

The Goal

The goal of this post is to associate parts with the symbols on the schematics.  The key things I will be doing include:

• making sure there are accurate models of the chips.  Getting the footprint as exact as possible regarding pad sizes of the components will be key to being able to solder a component onto a PCB.
• identifying and buying parts from digi-key.    

The Process

Each step in the process:

• Start with the net list
• Associate footprints with schematic symbols
• Build the BOM

Is outlined below. I found the hardest task was finding a part. I used Digikey.com for all parts except the RFM69HW, which Digikey does not carry.  Digikey has an overwhelming number of parts.  Imagine a store where there are rows and rows of items – most of the same size – and you have to read the fine print – in this case a whole bunch of gobly gook within a data sheet for a part with words that make sense to the “been there, done that” electrical engineers – while trying desperately to narrow the search.  It was very overwhelming.  This is another area where Chris’s Contextual Electronics course was valuable.  Chris went through many digikey.com shopping excursions with us.  There is a lot to pick up from someone like Chris who has “been there, done that” AND can transfer that knowledge! The second hardest task is creating a footprint in the likely event that kicad does not have the footprint in its system.  I am a n00b to standard SMT component footprints and am extremely glad Chris covered footprint sizes in several of the Contextual Electronics units. This document is helpful if – you are like me 5 weeks ago – 0805 does not mean anything to you.

I will continue using kicad .  The goal is not to document how to use kicad to do the tasks that need to get done.  The main ones for this post – using CVpcb and creating footprints – is covered in this tutorial.  A PDF of the schematic and kicad files are located in the bitknitting github repository).  The kicad CVpcb tool is used for associating the footprint of a part that I’ll find on digikey.com with a schematic symbol.   

Start with the Netlist

The first thing I need to do is create a list of the schematic symbols and then map a footprint of a part to each symbol.  This is done in kicad by generating a net list (This post by the Curious Inventor shows screen shots of a kicad net list).  The net list is super important because it is the glue that binds the design (schematic) with reality (the PCB layout).

Associate Footprints with Schematic Symbols

The next step is to make sure each component found on the schematic has information on the placement of pads that will connect the component to the circuit.  The criteria for my parts selection include:

• in stock
• inexpensive in quantities of 1
• SMT component
• it can do the job
• standard footprint with a size I have a chance of soldering correctly.  Even the larger SMT footprints seem small to my eyes.  

The following sections will go through each type of component using the contents of the BOM spreadsheet related to that type of component.  I will use a BOM spreadsheet that I made in Google Docs to put the information on parts, part size, cost, and ordering URL.  The BOM spreadsheet is located here within the bitknitting github repository. 

Capacitors

Below are the entries for the capacitors in the BOM spreadsheet.  Based on what I learned in the last post, I initially intended on using electrolytic capacitors for the 10uF caps.  They are bigger, but heck – I thought the experts had spoken.  Chris recommended ditching electrolytic and stick with ceramic during my fantastic 1:1.  He noted electrolytic are more sensitive to temperature and voltage, they dry out over time, and they are bulky.  Good enough for me!  I am relieved that I can use 0805 sized 10uF caps.  I watched Chris as he did a search on digikey.com.  One of the filters I didn’t understand what the temperature coefficient.  Chris chose X7R capaciors – which after viewing the excellent table 1 in this post, made sense.  Although X5R capacitors were $.20 and X7R capacitors were $.30, I felt the extra range in temperature afforded by the X7R capacitor was worth it.

Here are my choice for capacitors:

Component	MFG Name	MFG Part Number	Distributor Part Number	Package size	Quantity	1 piece price	1 piece subtotal	100 piece price	100 piece subtotal	1000 piece price	1000 piece subtotal	Distributor Part Number Link
.1u CAPACITOR	Kemet	C0805C104K5RACTU	399-1170-1-ND	0805	2	0.1	0.2	0.01	1	0.01	10	http://www.digikey.com/product-detail/en/C0805C104K5RACTU/399-1170-1-ND/411445
1u CAPACITOR	Samsung	CL21B105KOFNNNE	1276-1026-1-ND	0805	1	0.1	0.1	0.0196	1.96	0.01785	17.85	http://www.digikey.com/product-detail/en/CL21B105KOFNNNE/1276-1026-1-ND/3889112
10u CAPACITOR	Nichicon	CL21B106KOQNNNE	1276-2872-1-ND	0805	2	0.3	0.6	0.1236	12.36	0.07262	72.62	http://www.digikey.com/product-detail/en/CL21B106KOQNNNE/1276-2872-1-ND/3890958

A YIPPEE! moment.  The 0805 footprint is already in kicad. 

Resistors

The schematic uses 2 resistors.  I used the footprint size and then narrowed the search to the least expensive in quantities of 1.  Here is what I ended up with:

Component	MFG Name	MFG Part Number	Distributor Part Number	Package size	Quantity	1 piece price	1 piece subtotal	100 piece price	100 piece subtotal	1000 piece price	1000 piece subtotal	Distributor Part Number Link
470 ohm RESISTOR	Panasonic	ERJ-6GEYJ471V	P470ACT-ND	0805	1	0.1	0.1	0.0149	1.49	0.00544	5.44	http://industrial.panasonic.com/www-cgi/jvcr13pz.cgi?E+PZ+3+AOA0001+ERJ6GEYJ471V+7+WW
10K ohm RESISTOR	Stackpole Electronics Inc	RMCF0805JT10K0	RMCF0805JT10K0CT-ND	0805	1	0.03	0.03	0.0088	0.88	0.0032	3.2	http://www.digikey.com/product-detail/en/RMCF0805JT10K0/RMCF0805JT10K0CT-ND/1942577

ConnectorsI am not surprised about the low price given how common resistors are in a circuit.  I am surprised in the difference in cost between the two resistors.

Connectors

The schematic uses three types of connectors:

• a 7 pin connector in which a male header will be soldered on so that the pins on the header will connect the breakout board to the breadboard.  This isn’t an actual part – but rather througholes on the breakout board. This is similar to how most breakout boards that sit on a breadboard are done.

 

• Test points.  Each test point needs a part.

Here was what I originally chose for test points off of digikey:

Component

MFG Name

MFG Part Number

Distributor Part Number

Package size

Quantity

1 piece price

1 piece subtotal

100 piece price

100 piece subtotal

1000 piece price

1000 piece subtotal

Distributor Part Number Link

TEST POINTS

Harwin Inc

S1751-46R

952-1478-1-ND

http://www.digikey.com/product-detail/en/S1751-46R/952-1478-1-ND/2264564

9

0.29

2.61

0.1888

18.88

0.13068

130.68

http://www.digikey.com/product-detail/en/S1751-46R/952-1478-1-ND/2264564

After bumbling around with test point parts on digikey and talking with Chris, I decided to use 22 AWG gauge solid copper wires as a test point.   By doing so, $2.61 is shaved off the prototype boards and this style is what I am used to.

Each test point will be a through hole on the PCB.  I’ll solder in a different color wire in each, then connect the ends to probes.  For example, I’ll connect the MISO/MOSI/CS/CLK lines to the MISO/MOSI/CS/CLK probes of my logic analyzer.

Using Wires for Test Probes

I’ll remove the test points after I get a few PCBs fabricated – once I feel comfortable that the circuit is working.

 

• A hole for a piece of copper wire acting as an antenna.  There is no physical part. It is just a hole in the board.

 

Voltage Regulator

As I discussed in the last post, I will use the MCP1703:

Component

MFG Name

MFG Part Number

Distributor Part Number

Package size

Quantity

1 piece price

1 piece subtotal

100 piece price

100 piece subtotal

1000 piece price

1000 piece subtotal

Distributor Part Number Link

VOLTAGE REGULATOR

Microchip Technology

MCP1703T-3302E/CB

MCP1703T-3302E/CBCT-ND

SOT23-A

1

0.65

0.65

0.41

41

0.41

410

http://www.digikey.com/product-detail/en/MCP1703T-3302E%2FCB/MCP1703T-3302E%2FCBCT-ND/1776945

A YIPPEE! moment. Kicad has the footprint for the SOT23-A sized chip.  One less part to go cross-eyed attempting to exactly match the dimensions of the part’s pads and placement in the footprint modeler.

Follow up: Chip commented:

Your selection of the 1703 in the SOT-23A case has a more limited power dissipation. That case has a high thermal resistance which in English that means that the SOT-23 will get hotter for a given load current than some of the other cases. Probably not a problem if your only application is to wake up once a minute take a reading, send a packet and then go back to sleep.

If you might use your breakout board in some more continuously transmitting application the SOT-23 might not cut it. Consider the SOT-223 case instead. It is five times as efficient at heat dissipation. For detailed descriptions see section 6.2 of the 1703 datasheet.

Felix had a counter reply:

I’ve not ever seen any heating or smoke out of that regulator in my own practice. Some people reported heating but I suspect they misused it or shorted the outputs (which WILL cause heating).
Wireless programming for instance is very RF intensive for a period of 20-30 seconds or even more depending on the sketch size. And there is no heating. So it’s a bit of a myth that the SOT23A is a bad choice. If it were, I would have replaced it over the several revisions of Moteino.

An aspect I love about community learning!  Folks like Felix and Chip that have “been there, done that”.  They come from a different context and have different experiences to share.

Level Shifter

Also discussed in the last post was the part for the level shifter:

MFG Part Number	Distributor Part Number	Footprint	Quantity	1 piece price	1 piece subtotal	100 piece price	100 piece subtotal	1000 piece price	1000 piece subtotal	Distributor Part Number Link
74LVC245ADB,118	568-2274-1-ND	SSOP20	1	0.44	0.44	0.2793	27.93	0.0033	3.3	http://www.digikey.com/product-detail/en/74LVC245ADB,118/568-2274-1-ND/946736

A YIPPEE! moment.  Kicad has the footprint for the SSOP20 sized chip.

RFM69HW

Last – but certainly not least – is the star of the breakout board, the RFM69HW:

Component

MFG Name

MFG Part Number

Distributor Part Number

Footprint

Quantity

1 piece price

1 piece subtotal

100 piece price

100 piece subtotal

1000 piece price

1000 piece subtotal

Distributor Part Number Link

IN-HOME WIRELESS (@433MHz)

HopeRF

RFM69HW-433S2

RFM69HW-433S2

http://www.hoperf.com/upload/rf/RFM69HW-V1.3.pdf

1

3.85

3.85

3.85

385

3.85

3850

http://www.hoperfusa.com/details.jsp?pid=136

 I put a link to the data sheet under the footprint column because the RFM69HW has a unique footprint:

Creating a footprint for the RFM69HW has brought up a concern.  There are many different in-home wireless parts.  They don’t speak with each other.  In particular, the RFM69HW is not sell in the volume to make me feel comfortable that the part will be around for a few years.  HopeRF has had many chips before this.  I need to find out how long the company has been around, what has been the lifespan of their other chips, and details about distribution in the U.S.  Right now I buy RFM69HW chips from Anarduino.  The cost is lower than other places and the service has been excellent.  With that said, I have no idea if this distributor will be around in the future.  This is something I will look into.  For now, I will continue to use the RFM69HW as the in-home wireless solution.  

Let’s Go Shopping

While not quite as much fun as shopping at Adafruit, I had a grand time putting parts into my shopping cart.  I ended up getting enough parts for 4 boards.  I figured my soldering skills would kill at least one – who am I kidding?  More than one….Also, I will receive 3 PCBs when I order from OshPark.   Here’s my digikey shopping cart:

Next I hopped over to Anarduino.com and ordered 3 additional RFM69HW-433 MHz chips.  I already have one from earlier tinkering that I’ll repurpose to complete the boards.

That’s a Wrap

I found part selection to be tedious.  The data sheets don’t make this task any fun at all!  Each one with their own style.  Each one with particular criteria to pay attention to.  I can tell it will be awhile before I feel comfortable that I am picking the “best” part for the job.  At this point, I am going for “it works”.  Chris and his Contextual Electronics course continue to be extremely valuable on my journey to make this breakout board.

All files – schematics, BoM, net list are available on the bitknitting github repository.

What’s Next

I’m getting to the fun stuff!  This week I’ll be laying out the parts in kicad’s PCB tool – PCBnew – and drawing the traces.  More on that in my next post!

 

Thanks for reading this post.  Please find many things to smile about.

 

 

 

 

 

 

 

Debugging the SPI Bus – When Components Won’t Share

Tags

debugging, SPI

Update 3/2/2015: Bil Herd put out a video on digital POTs.  He explains I2C and SPI at this point in the video.

Update 11/26/2014:  I just finished reading an excellent article: “Better SPI Design in 3 Steps” that is a must read when working with multiple devices sharing the SPI bus.

 

As I got into building the Base System, the SPI bus was used by many of the components.  I had a conceptual view of how the SPI bus worked, after all, it is well described in wikipedia.  

However, I didn’t have a working knowledge.  This concerned me because I was running into “traffic jams”.  In my case, once I initialized the cc3000, the RFM12B could no longer communicate on the SPI bus.

It became frustrating and concerning to not know if I purchased a component that needed to share the SPI bus if indeed it was a good citizen.  This was turning out to mean more than being able to set the CS/SS pin.

I decided to take a step back and try to figure out why there is this failure to share the SPI bus.  It is an OPPORTUNITY TO LEARN!  Since learning is in many ways what gets me up too early each day, I was eager to get to know the details of this all important data transfer bus. 

Peeking into SPI Bus Traffic with a Logic Analyzer

In order to gain a deeper understanding of SPI bus communications, the first thing I did was order the Saleae Logic Analyzer from Adafruit.  I had no clue how to use this…and it wasn’t until I talked to Mark – the incredibly helpful support person at Saleae – who patiently stepped me through using the logic analyzer – as well as watched their “how to” video did it all make sense.  I’ve done phone support at both Microsoft and Sabi.  It is a very hard job.  Especially helping over the phone.  I was very impressed with Mark’s patience in what I thought was my hideously “duh” questions.    A lot of that loyalty comes from how the product is supported.

Steps to debug:

• wire RFM12B and cc3000 to the Arduino
• add logic analyzer wires to the four SPI channels.  
• start the logic analyzer software and load the SPI profile (for both the RFM12B and cc3000).
• capture and analyze the SPI channels when the config information is displayed

Setting up the Logic Analyzer

I’ll be using all eight lines of the logic analyzer.  Four for the cc3000’s SPI traffic and four for the RFM12B’s traffic:

yet another snarly mess of wires. 

Basic SPI Traffic

Nick Gammon has an excellent post on interpreting the squiggles of the Logic Analyzer.  Reading this post gave me a great start at how the SPI lines are used and interpreted.  How terrific to find this resource and that Nick shared his knowledge in such a clear/understandable way.  THANK YOU NICK!!!!

As a sanity check, I started by analyzing the traffic generated by the RFM12B and then the cc3000.

Simple RFM12B SPI Traffic

To get a feel for the SPI bus traffic, I captured traffic that occurs when the function rf12_config() is called.  

The sketch (note: I am using pin 9 for the CS/SS pin):

#include <RF12.h>
void setup()
{
rf12_set_cs(9);
rf12_config(true);
}
void loop()
{
}

This image shows the start of the traffic: 

 

Notice the traffic occurs on the lines connected to the RFM12B.  The Arduino is sending bytes to the RFM12B (MOSI). The RFM12B’s CS pin is taken low to enable it.  The cc3000’s CS remains high.  Once the two bytes are read by the RFM12B, the RFM12B takes the CS high to note the end of sending/receiving data.

One “gotcha” using this Logic Analyzer:  On the plus side it supports the Mac.  On the more challenging UI side is the UI to find the MOSI and MISO transfers and then zoom into them.  To find the MISO and MOSI transfers, I find I have to zoom out to a timeline that shows increments in seconds.  To read the hex values, I then need to zoom into the MOSI or MISO line.  Zooming in is best done by clicking on the line until the timeline expands to show the hex values (microsecond increments).  I can also go to new readings with the N or P (for Next and Previous) keys.  However, I lose context of where I am.  While I have become very used to a trackpad I found I must use a mouse to navigate.

The Logic Analyzer provides a way to export the readings into a CSV file.  This made it far easier to sanity check reading SPI traffic.

Looking at the code in RF12.cpp,rf12_config() calls rf12_initialize().  The code that transfers bytes over the SPI from the Arduino to the RFM12B is listed on the left side of the table below.  Note the bytes on the right side correspond to the code.  For example, RF_SLEEP_MODE is #define’d earlier in RF12.cpp to be  0x8205 and  RF_TXREG_WRITE is #define’d to be 0xB800

rf12_xfer(0x0000); // intitial SPI transfer added to avoid power-up problem    rf12_xfer(RF_SLEEP_MODE); // DC (disable clk pin), enable lbd        // wait until RFM12B is out of power-up reset, this takes several *seconds*    rf12_xfer(RF_TXREG_WRITE); // in case we’re still in OOK mode    while (digitalRead(RFM_IRQ) == 0)        rf12_xfer(0x0000);            rf12_xfer(0x80C7 | (band << 4)); // EL (ena TX), EF (ena RX FIFO), 12.0pF    rf12_xfer(0xA640); // 868MHz    rf12_xfer(0xC606); // approx 49.2 Kbps, i.e. 10000/29/(1+6) Kbps    rf12_xfer(0x94A2); // VDI,FAST,134kHz,0dBm,-91dBm    rf12_xfer(0xC2AC); // AL,!ml,DIG,DQD4    if (group != 0) {        rf12_xfer(0xCA83); // FIFO8,2-SYNC,!ff,DR        rf12_xfer(0xCE00 | group); // SYNC=2DXX；    } else {        rf12_xfer(0xCA8B); // FIFO8,1-SYNC,!ff,DR        rf12_xfer(0xCE2D); // SYNC=2D；    }    rf12_xfer(0xC483); // @PWR,NO RSTRIC,!st,!fi,OE,EN    rf12_xfer(0x9850); // !mp,90kHz,MAX OUT    rf12_xfer(0xCC77); // OB1，OB0, LPX,！ddy，DDIT，BW0    rf12_xfer(0xE000); // NOT USE    rf12_xfer(0xC800); // NOT USE    rf12_xfer(0xC049); // 1.66MHz,3.1V

*

A tool that can help with understanding RFM12B Commands is this  RFM12B Command Calculator.

A Taste of cc3000 SPI Traffic

In my last go around attempting to have the RFM12B and cc3000 boards share the SPI bus, the traffic jam occurred after the call to cc3000.begin().  After that, the RFM12B was not able to transfer data on the SPI bus.  So the taste of SPI traffic I’m interested happens in cc3000.begin()…what state is the SPI bus left in that shoves the RFM12B out of sending/receiving over the MISO and MOSI lines?

Here is the sketch I am using:

#include <Adafruit_CC3000.h>
#include <ccspi.h>
#include <SPI.h>

#define ADAFRUIT_CC3000_IRQ 3 // MUST be an interrupt pin!
// These can be any two pins
#define ADAFRUIT_CC3000_VBAT 5
#define ADAFRUIT_CC3000_CS 8
// Use hardware SPI for the remaining pins
// On an UNO, SCK = 13, MISO = 12, and MOSI = 11
Adafruit_CC3000 cc3000 = Adafruit_CC3000(ADAFRUIT_CC3000_CS, ADAFRUIT_CC3000_IRQ, ADAFRUIT_CC3000_VBAT,
SPI_CLOCK_DIV2); // you can
void setup()
{
Serial.begin(57600);
if (cc3000.begin())Serial.println(“Initialized the cc3000”);
else Serial.println(“Did NOT initialize the cc3000”);
}
void loop()
{
}

I ran this sketch while capturing its SPI bus traffic through the Logic Analyzer.

First, a zoom in on a few bits of initial cc30000.  

 

I note two differences in how the cc3000 transfers bits:

• Note the clock line for the cc3000.  Unlike the RFM12B – where data is sampled when the clock is going low to high on the leading edge, data is sampled when the clock is going from high to low on the trailing edge. Nick Gammon’s post does a great job explaining the SPI “data modes”.  I also thought a post on Sparkfun did a nice job :

The slave will read the data on either the rising edge or the falling edge of the clock pulse. Additionally, the clock can be considered “idle” when it is high or low. In the Arduino SPI library, both of these options are controlled by the setDataMode() function.

• Sampling occurs at a faster rate than it does for the RFM12B. Back to the Sparkfun post for an explantation on sample rates:

SPI can operate at extremely high speeds (millions of bytes per second), which may be too fast for some devices. To accommodate such devices, you can adjust the data rate. In the Arduino SPI library, the speed is set by the setClockDivider() function, which divides the master clock (16MHz on most Arduinos) down to a frequency between 8MHz (/2) and 125kHz (/128).

When the RFM12B Stops Talking

if I run a sketch that initializes the cc3000 using the cc3000.begin() function and then run rf12_config(), something has changed with the MISO line.  Contrast the MISO line readings below with the readings I showed earlier:

Time [s]	Packet ID	MOSI	MISO
4.39353675	0	0x00	0xFF
4.39354125	0	0x00	0xFF
4.393549	1	0x82	0xFF
4.3935535	1	0x05	0xFF
4.39356125	2	0xB8	0xFF
4.39356575	2	0x00	0xFF

All MISO readings are 0xFF.  This was noted by Martyn in a thread on the JeeLabs forum where I asked for help on what was going on:

It [the MISO line] is stuck high after the cc3000.begin(). Since the SPI bus is inverted logic, that maps to the FF (falsely) decoded. 

Once cc3000.begin() has been executed, the RFM12B is unable to communicate over the MISO.  As Martyn noted:

• The breakout board level converter sees the 3V high as an input and drives a 5V high hard independent of CC3000 selected
• The poor RFM12B working at 3V through a resistor divider doesn’t stand a chance to pull this signal down.

An answer on the Adafruit forum gave me pretty much the equivalent information.   

the breakout version of the cc3000 needs something to buffer MISO as it is not tristated

http://learn.adafruit.com/adafruit-cc30 … 

you can look at the cc3000+SD exam.ple sketches for how to share the SPI lines, but no, the CC3000 does not work great with other SPI devices without a lot of care & debugging. this kind of stuff is not easy to fix, if you’re “new to electronics”, you may find this project challenging and we don’t offer coding or library modification support and assistance.our suggestion is to find an RF module that does not require sharing those pins.

At the time I read the replay on the Adafruit forum, I was more or less flailing like a fish on the deck of a boat in my understanding of what was being said.  My  lack of understanding is what compelled me to at least gain a better understanding of the SPI bus and perhaps the challenge of fixing this challenge.  Alsom I got a little thrown with some of the reply:

• what does buffer MISO mean?  I get that the cc3000 leaves the MISO stuck high (see Martyn’s comment below).  Perhaps it just means bytes sent by the cc3000 over the MISO line?
• the suggestion to look at the example sketches.  This made sense if it was a conflict with the CS pin.  However, I’m using different CS pins.  The challenge is in the state of the MISO after cc3000.begin() is called.  Of more interest is the schematic of the cc3000 Shield, which uses the 74AHC125 to tri-state the MISO pin.

 Oleg Mazurov sums up the issue in his post on the SPI bus:

Only one device, the one whose SS line is asserted low, is participating in the transfer by driving its MISO line – all other devices are expected to have their MISO line in a third state.

Can the cc3000 and RFM12B Co-Exist in a Circuit?

A Software Fix

Given my background is in software, the easiest solution I can think of was a software solution.  

1) initialize the cc3000 with cc3000.begin();

2) call wlan_stop()

(see wlan.cpp: Stop WLAN device by putting it into reset state.)

3) when switching RF traffic, wrap the cc3000 calls with wlan_start(0) and wlan_stop()

Here is some snippet of a sketch that does this:

//initialize the cc3000 then stop it to allow RFM12B to use the MISO line

if (cc3000.begin())Serial.println(“Initialized the cc3000”);
else Serial.println(“Did NOT initialize the cc3000”);
wlan_stop();
Serial.println(“cc3000 stopped”);

//nitialize the rrm23b

rf12_set_cs(9);
rf12_config();

//do wiFi traffic

Serial.println(“Start cc3000”);
wlan_start(0);
if (!cc3000.connectToAP(WLAN_SSID, WLAN_PASS, WLAN_SECURITY)) {
Serial.println(F(“Failed!”));
while(1);
}
Serial.println(F(“Connected!”));
/* Wait for DHCP to complete */
Serial.println(F(“Request DHCP”));
while (!cc3000.checkDHCP())
{
delay(100); // ToDo: Insert a DHCP timeout!
}

/* Try looking up http://www.adafruit.com */
// uint32_t ip = 0;
Serial.print(F(“www.adafruit.com -> “));
while (ip == 0) {
if (! cc3000.getHostByName(“www.adafruit.com”, &ip)) {
Serial.println(F(“Couldn’t resolve!”));
}
delay(500);
}
cc3000.printIPdotsRev(ip);
//
// /* Do a quick ping test on adafruit.com */
Serial.print(F(“\n\rPinging “));
cc3000.printIPdotsRev(ip);
Serial.print(“…”);
replies = cc3000.ping(ip, 5);
Serial.print(replies);
Serial.println(F(” replies”));
if (replies)
     Serial.println(F(“Ping successful!”));
Serial.println(“stopping cc3000”);
wlan_stop();
Serial.println(“cc3000 stopped”);

//send traffic back and forth between RFM12B nodes and the Base System…

A Hardware Fix

I have stumbled into the 5V – 3.3V clash of the Arduino and breakout boards.  As noted in this SparkFun learning post on voltage dividers (see the section on Level Shifters):

Many of those sensors operate at a relatively low voltage, in order to conserve power. Unfortunately, it’s not uncommon that those low-voltage sensors are ultimately interfacing with a microcontroller operating at a higher system voltage. This leads to a problem of level shifting, which has a number of solutions including voltage dividing.

Recall what Martyn said:

• The breakout board level converter sees the 3V high as an input and drives a 5V high hard independent of CC3000 selected
• The poor RFM12B working at 3V through a resistor divider doesn’t stand a chance to pull this signal down.

 While I haven’t tried it, I read this to mean I would need to shift the 5v high to a 3.3V so that the RFM12B could pull the MISO line down.  This would be done by a level shifter – which as the cc3000 breakout board and shield schematics show are needed to shift between the 5v of the Arduino’s i/o to the 3.3v of the chip’s.

In my quest to learn, I will try this.  And YIPPEE!! I will be aided by the BitScope 10 oscilloscope I anxiously await to receive in the mail!  Too bad the Logic Analyzer doesn’t support a scope mode.  If I make progress with using a level shifter to solve the cc3000 sharing the MISO line with the RFM12B I’ll let you know through a new post.

Finally

I think I found a workaround.  In the process, I learned a lot about using a logic analyzer and SPI traffic.  As usual, folks on forums were kind in sharing their knowledge – giving insightful and actionable advice.  It is a great feeling to have a better understanding of why a circuit is not working.  I found learning how the logic analyzer can debug in serial communications to be valuable and will certainly come in handy as I continue my quest to build a hydroponics sensor network.  I’m a long way off from a never ending supply of vegetables to feed my family, but I feel one step closer in my ability to build the system.

Hydroponics Sensor Data to Base System then into Excel

Tags

433MHz, arduino, Data Logging, Google Docs, sensors

This post builds on the content of previous posts as well as what I have picked up from the exceptionally helpful folks that have left comments, replied to questions in a variety of forums, and other helpful folks that have published their findings in their blogs and websites.

Time to Log Data

One of the features of the Base System will be to capture hydroponics sensor readings to a local file so that I can then do whatever post analysis and environmental improvements based on readings that are affecting the plants.  In this post I’ll send data from a Hydroponics Sensor Node to the Base System. The Base System will store the data on an SD card in CSV (Comma Separated Value) format.  

I will then open the CSV file in Excel or Google Docs to see if I can notice any trends in the readings or fixes I should make in the pH, amount or kind of nutrients, temperature conditions, and possibly the lighting conditions.

Steps

The steps to do this include:

•  Sending sensor readings to the Base System.  This was done in an earlier post.  While I look into some SPI misbehaviors, I’m going to use a 433 MHz TX and 433 MHz RX  to talk between the Base System and the hydroponics sensor node.  I’ll start by setting up the sketches using two USB ports on my Mac.  This makes it easier to debug because I can open up two terminal sessions and view the Serial.print() statements.  then move the sensor node to the hydroponics system.
• Writing data to the SD card in CSV format.
• Importing CSV file into an Excel spreadsheet.

Parts

• Two Arduino Unos – one for the Base System and one for the sensor node.  Plus two breadboards, as well as the usual amount of wires to hook the circuits together.
• 1 433MHz Transceiver and 1 433MHz Receiver
• 1 SD Shield and SD Card 
• DHT22 Temperature and Humidity Sensor
• DS18B20 Water Temperature Sensor
• Light Sensor
• pH probe and stamp
• LCD with an I2C interface to save on the number of pins used (optional but very helpful)

Sketches and Code

You can download the sketches and code used in this post here.   I’ve decided against showing code in a post.  I’d rather have the code be documented enough so that you understand it.   Please let me know if you find stuff you don’t understand.  I’d like to then update the code as needed so that it is easier to use.  Of course, please suggest improvements!  I hate to remind – but my college degrees are in Geology and I spent most of my working life in management.  We can all improve with your help.

Can You Hear Me Now?

This post is focused on getting sensor readings into an analytics tool such as Google Docs and Excel.  I used some inexpensive 433MHz TX/RX components that I had lying around to send and receive the sensor data.  This YouTube video is a great way to jump start using the 433MHz chips if you haven’t already done so.  The sketches use the VirtualWire library.  You might also be interested in the active forum.  The VirtualWire library documentation notes in section 5, performance,: At 2000bps, Range over 150m  (492 ft) [mileage will vary].  My mileage definitely varied.  I saw a much smaller range.  This is most likely due to RF interference in my house.

Back to the 433MHz. I’ll be swapping these out for my “final” home sensor/automation network solution when I choose it.  I hope not to be spending too much additional time on RF exploration.  I’ve learned to a level where I am by no means an expert, but do feel comfortable with how the different RFs work at the level needed to use for a home sensor/automation network.

Goldilocks and the Three RF choices

One of the areas I wished to explore was the varying RFs to make up the home sensor network.  My goals in this exploration include:

• gaining an understanding and familiarity at the sw/hw level of low cost home sensor/automation network RFs
• choosing a solution for my hydroponics home sensor/automation system

The features I am looking for in a solution include:

• low cost
• “adequate” range (the ability to transmit from anywhere in my house and receive from the point farthest away)
• robust Arduino software library that has the “right” APIs (“right” is determined by need and seems to vary the more I learn!)
• low power
• enthusiastic, helpful internet community
• includes features such as the ability to determine signal strength, node differentiation such that multiple nodes can transmit sensor data to a Base System and the Base System will know which node sent it, and reception by the Base System of uncorrupted packets within a reasonable timeframe.  There are always going to be dropped or corrupted packets.  How easy is it for the Base System to receive uncorrupted sensor readings? 
• requires minimal soldering on my part 

Up until now I have been exploring the capabilities of the various RF solutions, the Arduino libraries that come with them, and what level of support is available.  I’ve stayed away from solutions like zigbee and Z-Wave because of cost (true in both cases) or barriers to entry (true in the case of Z-Wave).  For example, I sent a question to the Z-Wave alliance about exploring Z-Wave.  The chairman (Mark Walters) sent the following email:

Getting involved with native Z-Wave development isn’t for the faint of heart.  To develop one must first purchase a developer’s kit from Digikey and in doing so sign a licensee agreement with Sigma Designs the IP holder of the Z-Wave technology.  The least expensive developers kit is $1,500 and then you will need a $3,500 compiler and about $1,500 worth of developers hardware.  I’m not sure if you want or need to go this route.   You mention Arduino, we really don’t have a fully baked Adriano solution but we do have a very good solution for the RasberryPI.  Please take a look at this solution and see if it will work for you.  http://razberry.z-wave.me/  If you are dead set on Adriano then starting with the Z-Way middleware will save you the whole Sigma Designs developers kit step.

Wow!  Too serious of a commitment and way to expensive for me…I have seen this strategy with what I consider low level technologies before.  However, there is an opportunity to become the 802.11 of home automation/sensor networks.  It is not clear to me that just because I can buy products in Staples that use a wireless technology that it will become the dominant standard.  We saw this with TCP/IP (in some ways versus Novell”s IPX/SPX).  The openness of TCP/IP – as well as its ability to work well across routers across long distances – provided an environment where solutions thrived.  Z-Wave’s strategies (and others similar – or others at a higher price point during exploration stages) sadly preclude these technologies.

Which leads me to think of my exploration of RF for home networking as the story of Goldilocks and the three RF frequencies….The first I tried was the nRF24L01.  I found this solution to be unreliable and not well supported or embraced by the community.  Of course, reliability doesn’t improve since I purchased the chips on eBay.  I found the TX/RX to work intermittently.  The software library was not of the ease of use and quality.   Also, it was not obvious how to participate in a community of folks using them.  I would scurry to different forums and websites, with no dominant forum to absorb the findings of the folks that have come before me.  Thus, it was hard for me to ask questions and get timely and to the point responses.  I’m also concerned with this RF using the 2..4GHz frequency.  We have a lot of BlueTooth devices.  Plus a higher frequency will not have as far a range and will also use more power.  I’ve decided against using the nRF24L01 moving forward.

The second RF I tried was the JeeNode from JeeLabs.  There are many things to like about JeeLab’s products.  A LOT of GREAT THINKING went into different aspects – such as power consumption and RF Frequency.  The library is robust.  There is many postings of why different components are used and details on the software library.  The software library is robust.  The JeeLabs forum is active, extremely knowledgable, and helpful.  The challenges I have include I am not bought into the port abstraction for attaching sensors.  It is easier for me to think in terms of the Arduino pins and not a node representation.  I got spoiled by the DHTxx library that was available for the DHT air temperature and humidity sensor.  I wanted such a library for all the sensors.  Alas, not all the sensors use I2C not have as nicely done libraries.  However, the sensors are extremely simple with extremely simple APIs – so not having the simplified   Also, the RFM12B is an old chip that has been replaced.  I would like a chip that I can get from multiple sources and is not generally discontinued.  Yes, Modern Devices can still get chips based on their agreement with Hope RF.  But it is still a chip that the manufacturers no longer wish to produce.

The third is the one I am using for this post, the 433MHz TX/RX components.  These chips are great for initial experimentation because they are extremely simple to use.  There are significant drawbacks as my knowledge improves on indoor RF solutions.  I found the range to be inadequate.  Either due to RF interference or range, there were many times when I was lucky to get one reading after a minute when sending readings every second.  There was one wall and about 50 ft between the transceiver and receiver.  The library is very basic and extremely simple to use.   There is no support for very helpful features like RSSI feedback to help set up the best reception experience.

The most promising looks to be Hope’s replacement for the RFM12B, the RFM69.  LowPowerLabs looks to have promising “kits” that have been built on the shoulders of the great work JeeLabs has done with their JeeNode.

Transmitting Sensor Data

As you can see from the image of the current implementation of a hydroponics sensor node:

 

 

(…I’ve got to start cleaning up the wires, shrinking its size, put it into a waterproof container, and figure out where to put it so that it doesn’t interfere with the plants!  I haven’t done this so far because I am test, adding, and removing parts.  For example, this version includes a 2×16 LCD that is an immense debugging help.)

The Base System will be receiving sensor readings on air temperature, humidity, water temperature, lux, color temperature, and pH.  I’ve discussed each of these in earlier posts.  Currently what is transmitted is “hard coded” such that the Base System is expecting a packet that contains these readings – and no other kind of packet.  In the future, there will be at least one other type of packet – the header packet which tells the Base Station what sensor readings will be sent and in what order.  For now I went for the “quick and dirty” approach to gathering data.  Also in the future I will support multiple nodes.

As shown in SensorNode433.ino:

• I take a reading every 5 minutes.  Each minute I display the number of minutes that have passed since the last reading on the LCD.Time can be adjusted by changing TIME_INCREMENT_DELAY – the time between updating the number on the LCD and NUM_TIME_INCREMENTS – the number of increments before a reading + 1.  Thus, TIME_INCREMENT_DELAY*(NUM_TIME_INCREMENTS-1) = time between readings.  
• the first byte sent over is the number of sensor readings that will be sent.   This will be used by BaseSystem433.ino  to determine if all the readings are contained in the received packet.
• all readings are sent in uint16_t format.  

 

Here is a line of sensor readings:

Sensor	DEC	HEX
Humidity	43	2B
Air Temperature	68F	44
Water Temp	66F	42
Color Temp	5634	1602
LUX	30000	7530
pH	61 (6.1)	3D

The packet sent over the wire is 13 bytes.  The contents of each byte given the sensor readings is:

6

0

2B

0

44

0

43

16

2

75

30

0

3D

Keep in mind that Arduino is little endian.

As I used in previous posts, I will use the:

• DHT22 for measuring the air temperature and humidity.
• DS18B20 for measuring the Water Temperature,
• TCS34725 for measuring the Color Temperature and LUX.
• Atlas Scientific’s pH Circuit for measuring the pH.

I am not yet comfortable with the pH readings since I do not calibrate as often as I need to.  In the future I will add this functionality using a technique similar to the one shown in the Sparkfun video.

 Since my post on the need to conserve SRAM, I am more conscious of saving SRAM.  I:

• put the freeRam() function into a library called debugHelpers (TODO: GITHUB LINK) so that I can use this handy function to check the remaining SRAM from within any sketch.
• started to standardize on using Serial.print(F(” “)); so that debugging strings go into Flash and not SRAM.
• dropped using the  Dallas Temperature Control Library.  I used the OneWire library instead.  I feel much more comfortable with Arduino programming and always find it best to get rid of abstraction layers when possible.
• Avoided using String objects.  While the flexibility and additional functionality are useful, as David Crocker points out in his blog post, “Five things I never use in Arduino projects”, using String objects come at the cost of dynamic memory allocation and additional memory overhead.

With all sensor readings except the pH reading, values can be returned as uint16_t.  The pH value is different because at a minimum the first decimal place is needed. The pH reading comes in as a string such as “7.45”.  I convert this to an integer that puts the first decimal place in the single digits space and the integer value(the value before the decimal point) in the tens and hundreds place.  For example, 7.45 becomes the integer value 74.  Doing this makes it easier on sending and receiving the packet at the expense at the “goo” needed to map into pH readings.

I added an LCD monitor to the Hydroponics Sensor Node.  This way I could write debug statements to the LCD while the sensor node was running near the hydroponics station.

Receiving Sensor Data

This configuration of the Base System includes an Arduino Uno, the SD Shield, and the 433MHz transceiver.

The configuration plus the additional memory used by the BaseSystem.ino sketch left 595 bytes.   I will definitely have to move to an Arduino that has more than 2K SRAM.  The most likely replacement will include the ATmega 1284P.  No longer does the Base System need to feel closed in because of too little SRAM.  The ATmega 1284P has (a whopping compared to the 2K of the ATmega 328P!) 16K of SRAM.

Viewing Sensor Data

There is code in the BaseSystem433 sketch that checks to make sure the readings are valid, creates a string containing the date, time, and sensor readings in CSV format and then stores the string in the datalog.csv file.  Each time the Arduino is reset/starts, the earlier  datalog.csv is replaced with new readings.  Ultimately, deleting the old data is not what I want.  For now it is the easiest.  Since I know how I could implement a better handling of data logging files, I’ll leave that for something to do in the future.  

At this step I can start to analyze the sensor readings in a spreadsheet application.  This image shows a line chart of the readings for the air temperature.  There is a dip during evening hours, especially during the times when the LEDs are off.

 

While I took a reading every minute, the Base System did not receive all of them so the time between readings varies.  It is good enough for my purposes.   I did have to more the Base System closer to the Hydroponics Sensor Node.  As noted earlier – the 433MHz is not the one I will use in the future for the home sensor/automation network.

I have also included the .csv file in case you are interested in playing around with it.

What’s Next

• resolve or at least gain a better understanding of the challenges I have had with components not sharing the SPI bus.  From a learning perspective, I will go a little deeper than I probably should because – heck learning is extremely motivating and fun – and it will help me better understand interactions between an Arduino and components. 
• send the Sensor readings to the Xively service and analyze from “any device.”
• update what is going on with the hydroponics system. 
• finalize the home sensor/automation network RF.  
• finalize the components of the Base System.
• determine what probe and “stamp” to use in order to help with measuring the amount of nutrients provided to the plant’s roots.

and other things I haven’t thought to list.  

Using JeeNodes as the Basis for a Wireless Hydroponics Sensor Node

Tags

arduino, home network, JeeLab, JeeLink, JeeNode, RF, RFM12B, wifi, wireless

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:

Assembled JeeLink+JeeNode USB v3 + Shipping	$81.04
DHT22 Air Temp & Humidity Sensor + Shipping	$16.32
DS18B20 Water Temp Sensor (free shipping with Prime)	$7.99
Total	$105.35

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("\n[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);

Reading Water Temperature

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

RE: RFM12B End of Life? – Added by martynj 7 months ago

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.

My Indoor Veggies – Entry 2

Tags

home sensor network, hydroponics, LED

This post goes over first go-round of a hydroponics system that is using a DIY LED setup.

I started with a basic DWC system in our basement that used one T5 bulb for lighting.

As noted in this post, the LUX was 9950.  I started measuring the  KWH with a Kill-A-Watt and found the TD5  bulb used 1.15 KWH.  The PAR value was 100 µmol photons m2s-1

The T5 provided 9950 LUX.  It will be interesting to see how the LED system compares relative to its PAR and LUX values.

Since then, I have found that I am lazier than I thought.  I want the plants within an area I frequent regularly.  That would be the kitchen.  Many years ago we redid our kitchen to include an eating area with a big round table which has hand, footprints, and drawings done by our kids when they were little.  Luckily we love our home with no plans of selling.   We had plants surrounding the area behind the seats.  Unfortunately, our two cats delighted in using the dirt as a cat box so we removed the plants and covered it up.  I’ve decided to reopen this area to a hydroponics system that surrounds the back.  What is nice about the hydroponics system is it is all water.  I can keep the cats out of the system, and I’ll figure out how to keep one of them from eating the leaves and puking them up.  He likes to do that.  

Since I like to get hands-on, I’ll be adding and adjusting constantly as I explore the “best” way to grow vegetables that we can pick to make a fresh salad or have a snack.

My initial start is what I refer to as my “Basic Hydroponics System.”  Disclaimer: I am just starting on my journey into hydroponics.  I do not claim my setup would work well for anyone else.  I am hoping it provides some knowledge to a fellow n00b and hopefully those more versed in this area will let me know what could be better.

The Base of my Hydroponics System

I’m going to start by growing tomatoes, cucumbers, spinach, and dwarf sugar snap peas.  I picked these because they are some of my favorite vegetables.  They also struck me as a fairly diverse group.  I thought a diverse group would give me a wider range of results given my early stages in hydroponics using LEDs as the light source.

To start with, my indoor garden includes two 5 gallon buckets purchased from Lowes each for under $3. I also got two bucket lids  at $1.28 each.  

In one I put a 6″ net pot.  I bought a 10 pack for $21.  Assuming I’ll use them all, the one 6″ net pot cost $2.10.  I put three 3 inch net pots in the other bucket.  The 3 inch net pots cost $6.50 for 1 dozen.  THe cost for three was $1.63.  I got a pump + hose + airstone from petco for $13.  I filled the net pots with ““Easy Green Hydroton Growing Media, 10 Liter Bag” ”  (aerated clay pellets).  The bag cost around $25 making me think there must be a less expensive alternative – like gravel or something that people try to get rid of.  Something I need to look into.

I put a  rock wool cube ($12.84 for a pack of 45 – $.29 each).  There are other options that might be better such as perlite or coir.  Another area where I need to know more about.  I chose rock wool because it was used in the DIY article I started with. 

What About the Temperature?

Water Temperature

 

I wasn’t sure what water temperature would work best for the vegetables.  Google searches (at least with the search terms I was using) did not lead to any additional knowledge, so I asked the question on the hydro subreddit and got this information:

______________________________________________________________________________________

[–]ElWaffles 4 points 1 day ago

Ideal water temp should be 68 up to like 72. 80f is no good for holding oxygen.

 

[–]thewsPlant Eater 2 points 1 day ago

For water you normally want to keep it under 72F no matter what if you can.

Air temps don’t matter as much, but they can’t stand full sun and temps in the summer (90F+ heat). Of course they don’t like under 40F temps very much either, and they don’t do very well with short days (supplemental light if in a greenhouse in the winter).

 

–]Potatonet 1 point 14 hours ago

Hi,

During veg to early fruit set: 70-78 During mid-late fruiting: 75- low eighties

The tomatoes need the heat for proper sugar conversion and flavor, especially in a hydro situation, no one likes a water ball.

 

[–]squarepush3r 0 points 1 day

air temperature range ideally 55-80 range

water temp from 55-80 as well

____________________________________________________________________________________________________

 

 Given these answers, my current thoughts is to keep the water at about 72F/22C.  Before I automate and to compare the sensors that are used to hand held units, I also got a digital thermometer.  The current temperature of the water is 62F/17C.  Since this is a little lower than I want, I went ahead and ordered two submersible heaters whose temperatures can be adjusted.

 

Air Temperature 

The Dance Between PAR and Air Temperature

 

I just read an interesting research paper (Tomato quality is more dependent on temperature than on photosynthetically active radiation) that concluded air temperature is more important than a higher PAR value.   This image is interesting.  The researchers plotted the different quality characteristics of a tomato relative to a Control group (where Control means 100% PAR values).  The 70% and 50% PAR values reference the samples that were considered in shade.  What is shown here is the tomatoes in the shade did not have readings that were very different from those in the sun.  

 

SSC can be interpreted as sugar content.  The sweeter the better! 

 

Based on the results summarized in the above image, the report concludes “…growers in our region could obtain tomatoes of similar quality under lower PAR than natural sunlight.

 

Now that PAR value has been discounted, the researchers looked at tomato qualities based on temperature ranges.  850C is the cumulative degrees measured over 45 days.  Dividing the numbers by 45, 850C = 18.8C/66F and 1000C = 22.22C/72F

 

 The paper notes (wow! learning new words like organoleptic!) Regarding organoleptic properties, all parameters showed slightly lower values at the lowest T cum  interval  (T cum < 850◦ C) (Fig. 7). It was concluded that daily T cum has an effect on tomato quality, with lower values of T cum leading to higher and lower values of antioxidant and organoleptic properties respectively.  They seemed to discount the variation in Vitamin C based on a comparison of mixed results by other researchers.  Having my background in science leads me to think any of these results can be reasonably disputed but they are a stepping stone to a great knowledge of how temperature and PAR values effect tomatoes during their flowering stage.

 

Although they found yield had a quite different outcome.  Lowering the PAR value by 30% from sunlight decreased the yield by 14.3% and a 50% lowering decreased the yield by 38.1%.  Also, fruit size decreased as the PAR value lowered to 50% of sunlight.

 

I have found over the years that there is research can’t help itself but by being subjective.  It is not the data, however the interpretation.  With that said, as I build up my knowledge base, I’ll follow some of the findings.  I view the settings of the hydroponic system(s) as an iterative process.

 

Thus based on the results of this article and given I am mostly interested on the organoleptic 🙂 qualities, as with the water temperature, I will maintain a constant 72F air temperature using the space heater noted earlier in the CoGs for the base system.  The space heater will be too small as the amount of plants grow. For now I’ll be able to gauge results on a smaller amount of plants at the lowest possible cost.

 

I will not raise the PAR values for this setup.  I will do another LED setup that emits higher PAR values.

The Food

 

To start out with, I am using Dyna-Gro – Grow 7-9-5 Plant Food.  I chose it because It was recommended on a DIY Hydroponics blog posting, it got good reviews on Amazon.com (note to self: be more skeptical about reviews!), and it advertises itself as a nutrient supplier that spanned the vegetation and flowering cycles. I’ll see how well it works and then change as I see what works and learn from others.  

_____________________________________________________________________

Note:

The 7-9-5 refers to the percentage of Nitrogen-Phosphorous-Potassium.  I’ll most likely change the nutrient mix once I evolve my learning on the appropriate nutrients for the plant and plant cycle.

 

 A thread on the hydro subreddit had some advice on what this expert uses:

_____________________________________________________________________

uranium_hexanitrate 3 points 7 hours ago

Start with clarifying your NPK: 13-11-9. You want the nitrogen for vegetative growth, and while 13 is a bit on the low side, it’s certainly more than adequate. Many people will use a balanced fertilizer (10-10-10 or 20-20-20) and still get good results, so super-high nitrogen need not be applied.

Back off on nitrogen and up the phosphorus and potassium for blooming. Peppers aren’t picky; you can probably make do with the same formulation all the way.

_________________________________________________________________________________

As noted here:

“In hydroponics, the plant roots are constantly provided with all the water, oxygen and nutrients they need….As a general rule, a plant consumes more nitrogen during the formative or vegetative stage, and more phosphorus, potassium and magnesium as it flowers. Throughout its growth cycle, the plant will also consume calcium, sulfur and micro nutrients such as iron, manganese, boron, molybdenum and copper.”    

(image from here)

_____________________________________________________________________ 

 

Measuring nutrient levels

There are two measurements that are important to stay on top of – the pH value and theEC/TDS/PPM  value of the water the plant roots call home.

Measuring PPM

I bought this inexpensive TDS Tester.  It seems to work pretty well.  Also, it seemed that several on the hydro subreddit used this tester with success.  The first reading I got before adding Dyna-Gro was 50 ppm.  I added 100ml to each 5 gallon bucket.  The new ppm reading is 1540 ppm.  According to the information found here, 1540 ppm seems like an acceptable value.  Like everything else, I’ll adjust as I learn more. 

Measuring pH

Maintaining the right pH level is important to how well the plant can absorb nutrients.  I found this image to be helpful:

 

I used a PH Meter to measure the pH.  It turns out the pH was too basic at 7.  I ordered General Hydroponics pH Down to get the pH around 6.  (FOLLOW UP: Do NOT use this pH meter! I discuss this in an “Indoor Garden Report.”

There are many different products that can be used to measure the pH value.

 

Pieces of the Base System

 

Bucket	Lid	Rockwool cube	Net pots	Clay pellets	Submersible thermometer	Space Heater	Nutrients	TDS Tester	pH Down	pH meter

 

 Cost of Goods

All dollar amounts are pre-tax.

Shared

•  Space Heater:   $12.97 
• Plant Food: $18.33   
• TDS Tester: $15.59 
• PH Meter: $12.57 

Per System

 

 

	1 6” Net Pot	3 3” Net Pots
Bucket	$2.78	$2.78
Bucket Lid	$1.29	$1.29
Net Pot(s)	$2.10	$1.63
Rock wool	$0.29	$0.87
Clay pellets	$1.55	$0.72
Air pump, etc.	$12.99	$12.99
Submersible Heater	$18.28	$18.28
Total	$39.28	$38.56

 

The LED Setup

I went over the components I would use in my first LED system in this post.  My husband and his friend built me a fixture from sheet metal they had lying around then mounted the CPU heat sinks on the fixture.  I put one LED array (cool white) on one heat sink and the other warm white on the other heat sink.

I set up this LED circuit:

 

 

 

 

 

I used spade terminals to attach the wires to the power supply.  I got these at Home Depot.  The smallest amount I could be in this size and type was 75 for $6.97.   I used 5.  Plenty more are left for future projects.

 

As the hours past, the heat sinks rose to a temperature in the mid-90F.  The steel plates got into the mid-80’sF.  I mounted each LED on a CPU cooler.  These acted as very nice heat sinks.  They both have a fan.  So I powered them up with a 12V wall wart.

 

How Much Light is Enough? 

superAngryGuy had a great posting in the hydro subreddit on the amount of LUX a plant should get:

15000-20000 lux____ the lower end of what we want for veg growth

35000-40000 lux____ what we want to try to hit for flowering

75000 or so lux_____ it’s pointless to go beyond this level of light intensity, saturation level

 

 During this past summer, I measured the outdoor PAR value in mid-August on a day that had a few puffy clouds as well as the PAR value for the T5 light I had previously been using.  The measurements were:

Outside – Sun	1865 µmolphotonsm2s-1
Outside – Shade	170µmol photons m2s-1
T5	100µmol photons m2s-1

 

 

 

 

 

 

I was going to add an Arduino + RF so that I could control the PWM/DIM in order to lower the brightness of the light.  This is easy to do since as you can see in the image each LDD has a DIM pin.   For now I’ll stay with what I have here and won’t use a dimmer since full daylight lux is around 10,000 – 25,000 LUX and direct sunlight is between 32,000 and 130,000 LUX.  Although both superAngryGuy’s and the wikipedia entry on LUX point to direct sunlight for flowering tomatoes. 

 

Given the outside sun PAR value, I am concerned the PAR values on the plants are too low.  They are however much higher than outside-shade and the T5.   Down the road I’m sure I’ll be adjusting the LED setup.

 

 

 

Cost of Goods

I did not provide a CoGs for the LED system in my post “Introducing the  Components of the First LED Circuit.”   So I’ll provide one here:

 

 

CXA2520-0000-00N00Q450F-ND	$15.30
CXA2520-0000-00N00Q20E8-ND	$16.60
2 CPU Coolers	$13.98
2 WM9779 CREE CXA25 LED Holder	$6.44
Meanwell s-250-48 Power Supply	$45.00
2 Meanwell LDD-1000Hw LED Driver	$14.66
Spade terminals	$0.45
Timer	$12.32
Total	$124.75

 

 I could have used an Arduino for the timer but felt using a wall plug-in timer is a simpler and less expensive way to go.  Also, the Power Supply and timer can be used for additional LED set ups so the cost of adding more will be less than this initial cost (up to a point).

 

What’s Next?

I’ll be updating this post with weekly updates.  My next step is to focus on what I want to be notified and automated using an Arduino and RF – which right now I have moved on from nRF24 to JeeNodes in my exploration of RFs for home sensor networks.  More on that in the next post. 

 

submer