Temperature-Sensor Network with RTC and LCD Part V

Wow. More than a month since my last entry. Time is flying by. About 50 days since I started the project and my rechargeable batteries (I had to change the first three after a few days, because one cell was dead) still work in my outside sensor. My RTC is wrong by about 1.6 seconds per day and the deviation is very constant so this error can be erased by software. To compare the temperatures I used a Clock with inside/ outside temperatures I bought some time ago. The temperatures were accurate and so I finally assembled a device which I can buy for about 20 Euros in any electronics store. You might ask why so much effort for such little outcome? Wait for adding an ethernet shield, more Xbees, door bell/ mail alert, light and rain indicators and so on. And everything is broadcasted in the network!

LCD display with date, time, inside- and outside-temperature
For the last part there is unfortunately a lot of code to sift through. I made as many comments as possible - if there are any questions just put it in a comment on the page.

void loop() {

  DateTime now = RTC.now(); // new RTC object named "now"
  // get time and date from the RTC DS1307

  int hour = now.hour();
  int minute = now.minute();
  int second = now.second();

  // print time and date on the first line of the LCD
  // and make some adjustments regarding leading zeros
  // time display will change every second

    lcd.setCursor(0, 0);

  if (hour < 10) {
  else {
  if (minute < 10){
    lcd.print(now.minute(), DEC);
  else {
    lcd.print(now.minute(), DEC);
  if (second < 10){
    lcd.print(now.second(), DEC);
    lcd.print(second, DEC);

  int month = now.month();

  lcd.print("  ");
  if (month < 10) {
    lcd.print(now.month(), DEC);
  else {
    lcd.print(now.month(), DEC);

  // wait one second to show off as a "real" clock ;)
  delay (1000);

  // here we are reading the serial port, that means everything that comes from the XBee Coordinator
  // the packet size (I/O Data Sample) is expected to be at least 23 bytes
  if (Serial.available() >= 23) {

    // look for the start byte, in this case I chose part of XBee end device address for easy parsing
    // this is a quick and dirty solution and you are welcome to make a better code for this
    // and of course you have to adjust the code for your XBee end device
    if (Serial.read() == 0x6F) {

      // blink debug LED to indicate when data is received
      digitalWrite(debugLED, HIGH);
      digitalWrite(debugLED, LOW);

      // read the variables that we're not using out of the buffer
      for (int i = 0; i<9; i++) {
        byte discard = Serial.read();
      // read the two bytes for the analog value
      int analogHigh = Serial.read();
      int analogLow = Serial.read();

      // combine high and low analog value, because it's in two bytes
      analogValue =  analogLow + (analogHigh * 256);

      // calculate temperature from TMP 36
      // 1.2V/ 1024 (10 bit ADC), 0°C is 500 mV, 10mV/ °C temperature coefficient
      float temperature = (((1.171875*analogValue)-500)/10);

      // we take 10 analog temperature samples and calculate the average

      temperature_sample=0; // reset temperature_sample value to zero

      for (int i=0; i<10; i++) {
        // calculate the temperature from the AD22100K
        // 5V/ 1024 (10 bit ADC), 1.375 V at =0°C, 22.5mV temperature coefficient per °C
        temperature_read = (analogRead(0)*0.0048828125 - 1.375) / 0.0225;
        temperature_sample = temperature_sample + temperature_read;
      temperatureInside = (temperature_sample/10);

      // print inside and outside temperature in the second row of the LCD
      // display will only change when data is received


      lcd.setCursor(0, 1);
      lcd.print("IN ");
      lcd.print(" OUT ");


There are still some things to consider and to change in the future. There is for example no adjustment for negative temperatures in the display, the parsing with the XBee address could be improved, the back light could be adjusted by software.


Temperature-Sensor Network with RTC and LCD Part IV

Are you ready to continue? I have to give an advance warning because the project becomes a bit confusing regarding the Fritzing-Schematics.
Nevertheless I will post the final add-on for the base station just to be complete: the 16x2 backlight LCD. If you are not sure about how to connect a 16x2 LCD there is a fantastic site which will give you full information about this topic: How to connect Arduino with a character LCD. In the meantime this is the current version of the breadboard. 
If you followed up to this point it will be no big effort to connect the last item!

Although we haven't built the remote sensor yet, I will start to show the sketch so you have a break building circuits.

Let's start with some information about the project and the configuration of the Xbees - I already mentioned the base station XBee configuration here.

Sketch Part I: project description, explanation how to configure the XBees (this is done via X-CTU and/ or terminal program):

Ver 0.1
by Markus Ulsass


 ATID 2001 (PAN ID)
 ATAP 1 API mode enable
 ATSP AF0 sleep period according to longest sleep period on end device

 ATID 2001 (PAN ID)
 ATD0 2   pin 0 in analog in mode with TMP36
 ATIR 3E8 sample rate 1000 millisecs (hex 3E8)
 ATSM 4   sleep mode cyclic sleep mode
 ATSP AFO sleep period (AFO = 2800 ms * 10 = 28 seconds)
 ATST 7D0 time before sleep 2 seconds (hex 7D0 = 2000 ms)

As mentioned before you should already be familiar with the configuration of the base station ("RECEIVER"), I will now explain the settings for the remote sensor:
  • ATID 2001: We select the same PAN ID for the end device, else we would likely have serious communication problems between coordinator and end device
  • ATDH 0, ATDL 0:  We leave both destination addresses at 0 (no broadcast) to send any information directly to the coordinator
  • ATD0 2: Analog Pin 0 (physical pin 20) is set to analog input mode. Remember the XBee will look for a maximum of 1.2 volt input so you might have to use a voltage divider depending on your analog sensor
  • ATIR 3E8: The periodic I/O Sampling Rate is set to 1000 milliseconds (that's 3E8 in HEX), this means a sample is sent every second from the remote sensor to the coordinator, given that the end device is awake
  • ATSM 4: We set the Sleep Mode to "4" which means we enable the cyclic sleep mode for the XBee end device
  • ATSP AF0: The Sleep Period is set to the maximum of 28 seconds hence we set the parameter to AF0 (HEX) or 2800 milliseconds. Because the sleep period is multiplied by 10 we get our 28 seconds.
  • ATST 7D0: This value sets the Sleep Timer which decrements the given parameter before the end device falls asleep again provided there is no RF signal received. For testing purposes we set this value to 7D0 (HEX) which is 2000 milliseconds. Later we could decrease this value to save energy. For the time being I will keep this value this high, because we could easier get access to the XBee if something goes wrong.
Sketch Part II: including libraries, declaring and initializing values:

// include the library for liquid crystal code:
#include <LiquidCrystal.h>

// include the library for DS1307 RTC connected via I2C and Wire Library
#include <Wire.h>
#include <RTClib.h>


// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(7, 6, 5, 4, 3, 2);

int debugLED = 13;            // for debugging purposes only
int analogValue = 0;          // declare and initialize analogValue for remote sensor
float temperatureInside = 0;  // declare and initialize temperatureInside for local temperature

Not a lot to explain, just the settings for the several devices connected and some values set for later use.

Sketch Part III:Setup:

void setup() {
  pinMode(debugLED,OUTPUT); //debugging LED set to output

  Serial.begin(9600); // start serial transmission with 9600 baud
  Serial.flush();     // flush the serial port

  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);

  // start Wire and RTC

  // check if RTC is running
  if (! RTC.isrunning())
    Serial.println("RTC is NOT running!");

Again the comments should be sufficient to explain the code. If there are any open questions regarding the language check the reference on the Arduino homepage.

I think that might be enough for this time. In the next part we will continue with the sketch and will start with the remote temperature sensor.


Temperature-Sensor Network with RTC and LCD Part III

We continue with the base station and start to implement the temperature sensor.

There are a lot of temperature sensors available. You could use simple thermistors, analog temperature ICs (like TMP36 or LM335) or digital ones like the Dallas DS18X20 (X stands for S/ B). They all have their pros and cons and I like to experiment with different sensors.

Analog Devices AD22100KT
This time I chose the Analog Devices AD22100KT in a TO-92 package. It's a "Voltage Output Temperature Sensor with Signal Conditioning" and has a large temperature span of 200°C (-50°C to +150°C) a nice linearity and accuracy (according to the datasheet). The datasheet declares an initial error of 0.5°C (at Ta = 25°C, AD22100KT) and a maximum error of 2°C. That sounds much better than the LM335 (at Ta = 25° it's 2°C inital error for LM335, max. 6°C) I worked with at some higher cost for the part and with 60°C more temperature range. Voltage supply is at least 4 (up to 6) volts and quiescent current ist 650µA maximum. As we connect the sensor directly to the Arduino both values are not that important this time (it will be if we connect a temperature sensor directly to the XBee - more on that later).

Datasheet Analog Devices AD22100
You will need a 1k ohm resistor and a 0.1µF capacitor between Vout and the analog input to drive the temperature sensor.
The datasheet also gives insight into the formula we later need to calculate the temperature from our analog readout: Vout = (V+/ 5V) * [1.375V + (22.5mV/ °C) * Ta]. It's the formula where we see the sensor has a temperature coefficient of 22.5mV/ °C (that's techspeak and means the voltage changes by 22.5 millivolts per degree celsius).

The next module ist the Real Time Clock (RTC) DS1307. It's one of Dallas Semiconductor (now Maxim Integrated Products) famous clock-ICs and it's quite easy to build and program. You connect the IC via analog inputs 4 and 5 to the Arduino. That are the I2C pins of the microcontroller and you can use one of the RTC libraries that are available (you can find a great tutorial here).You only need two resistors for the SDA and SCL lines, the 32,768kHz crystal and the 3 volts backup battery (like a Lithium 2032 3 volts coin cell).

Well so far we are almost done with the base station. Please be aware that the left and right power rails of the breadboard are not connected, because the left power rails have 3.3 volts and the right rails are supplied by the 5 volt output from the Arduino UNO.

Arduino UNO with XBee, RTC DS1307 and AD22100KT
In the next part we will finish the base station by connecting the LCD and having a look into the code for the Arduino UNO. In the meantime have fun!


Temperature-Sensor Network with RTC and LCD Part II

XBee on perfboard
Part II of the temperature-sensor network starts with the Base Station.
The XBee Series 2 sitting on the base station connected to the Arduino UNO is configured in Coordinator API mode. I use the following settings (all other settings are the default Coordinator API setttings of the firmware) which are programmed via the X-CTU software from digi:
  •  AT ID 2001 (PAN ID) (see #1)
  •  AT DH 0 (see #2)
  •  AT DL 0 (see #2)
  •  AT AP 1 (see #3)
  •  AT SP AF0 (see #4)
  1. The extended PAN ID for my network (AT ID = 2001) is 2001 (I hope it will be no "Space Odyssey" though)  - but you can take any 64-bit value up to 0xFFFFFFFFFFFFFFFF or even leave it to 0 where the Coordinator would select a random PAN ID. Be sure to set the same ID to the other devices which should join the network.
  2. The Destination High and Low Address is both set to 0 (AT DH = 0, AT DL =  0) which defines the coordinator.
  3. API mode (AT AP) is set to enable (=1) because we want to receive and parse packets instead of just routing the traffic via the serial port like you would do in transparent mode.
  4. Perfboard back side
  5. The last setting is for the sleep period according to longest sleep period on a/ the End Device(s) (AT SP = AF0). This is to take care that the Coordinator (or any Router which is configured to this length of sleep period) will buffer the messages for the End Device long enough to get them transferred when the End Device awakens (no snooze allowed!). The sleep period is set to 28 seconds on my End Device because the sleep period is multiplied by 10 the value is 2800ms in Decimal or AF0 in Hex.

Unfortunately and for the sake of formality I have to say that my wiring seen in the following picture could be of risk to damage your XBee! As the Arduino UNO runs on 5 volts and the level on the TX pin (digital pin 1) is about 5 volts when HIGH, the DIN pin of the XBee (pin 3) could be exposed to more power than allowed. So I give no guarantee that your XBee is as robust as mine - take care of it and use a level shifter in any case!
XBee with level shifter

Update: For the last days I tested a very simple level shifter, which works for me. I have very low traffic though and there may be problems with higher data transmit rates, but for the time being I just added two resistors (22kohm and 33kohm) as a simple voltage divider and now have maximum roughly 3 volts on DIN of the XBee. So that may be a quick workaround.

Part III will continue with the base station.


Offroad: XBee Coordinator API + Arduino UNO + RTC +Temperature Sensor + LCD-Display AND Remote XBee (Sleep Mode with low power consumption) + Temperature Sensor - PART I

What a long headline you might think - but this actually describes very well my longer absence to the blog.

I'm sorry to be again off-road to the book, but before starting with the last Connect-Port experiment in Chapter 7 I still have some things on my to-do list that developed from the preceding chapters of the book.

With the knowledge of all the things learned until now I was eager to implement my first own little project to get a simple temperature sensor network (one outside/ one inside temperature) with a real time clock (RTC) and displaying everything on a LCD-display working.
Base Station (breadboard version)

It's consisiting of:

Base Station:
  • XBee in Coordinator API mode
  • connected to an Arduino UNO
  • Temperature sensor connected to Arduino (AD22100)
  • LCD-Display (16*2) connected to Arduino
  • Real-Time-Clock (RTC DS1307) connected to Arduino 
 Remote Sensor:
Remote Sensor
  • XBee End Device Sleep Mode
  • TMP36 temperature sensor connected
  • Voltage regulator MCP1700 (with very low quiescent current <2µA)
  • running on three AA rechargeable batteries

Part II will be on describing the Base Station.


Lights, Camera, Actuate! - Part II

Sometimes it's a good advice just to let one or two days pass and everything works. I started from scratch as I hit a roadblock while doing the "Direct Actuation Example". In the end everything worked, but it was a rocky road.

XBee Coordinator and three XBee Router (nodes) connected
As you can see in the picture I configured three nodes (XBee Router AT firmware 2270) with the following AT commands: ATID 2001, ATJV 1 and ATD0 4 (digital pin DIO 0 digital LOW, physical pin 20). Maybe it's a good habit to reset/ restore values after you used the XBees in other projects and to flash the firmware when starting a new project. That's what I also did for the Coordinator, which I programmed in API mode, with ATID 2001, and ATAP 2 (API mode 2). I'm not sure if this might be the source for the problems - in the past I only checked "Enable API" and "Use Escape Characters (ATAP =2)" in X-CTU on the "PC Settings"-Tab. and wrote the AT commands to the XBee. Everything seemed to work. This time I configured API mode 2 on the "Modem Configuration Tab" and then wrote the AT commands to the XBee.

In the picture at number "1" you can see a node queried and responding with the actual state DIO 0 (physical pin 20). Number "2" shows a pushed rocker switch and the toggled pin 20 on another node.

This was my Breadboard configuration where the 3.5mm jack plug goes to my power switch (see blog). I used a BC547A instead of the 2N3904 but many of the standard NPN-transistors will do. I took a 10k ohm resistor which fed about 0.5mA to the base of the transistor (Ibase = Vcc-Vbe/ Rbase). Enough to drive the minimum 6 mA needed by the power switch optocoupler to drive the relay in the power switch.

For testing purposes I configured a breadboard with only a LED to show if the XBee DIO 0 was LOW or HIGH. This was my breadboard configuration.
Breadboard with XBee Router, voltage regulator and transistor to drive LED
ALWAYS check the pin configuration of the electronic parts. For example the pin layout for 2N3904 is "EBC" (Emitter-Base-Collector from left). The BC547A I used has "CBE". A BD139 has "ECB". Confused?
In my breadboard layout above there is a BC547A and the voltage regulator is a LC33FV, which has Vin, GND and Vout (from left).


Lights, Camera, Actuate?

This is the first time I really ran into trouble - the "Direct Actuation Example" (chapter 6, page 172) doesn't work.

I configured everything as described in the book (Coordinator API (ATAP=2) via USB connected to PC, Router AT on breadboard with voltage regulator, transistor and power switch) but unfortunately the processing code gives me an "XBee request timed out" error.
I can click on the red rocker switch but nothing happens - I just get further timeout errors.
I reconfigured everything many times, re-wrote the firmware and AT commands on the XBees, replaced the XBees with others (I have four at the moment) but I keep getting the timeout error.
I'm quite new to Processing and don't know much about the xbee api - I'm not even sure that this is a software error.

So I'm stuck at the moment. 

As I can see there are some people out there following the blog, maybe one of them might have a solution to my problem.

While I was preparing the direct actuation example I had some issues with the wiring depicted in figures 6-4 and 6-5 on pages 178/ 179 and the text on page 176 describing the PowerSwitch Tail in the book. See the Errata for further information.

There is a new PowerSwitch Tail available at powerswitchtail.com and now they also have a 240 volts version! This might be even better than the one I purchased at ELV (s. blog posting), because you might switch it directly with your XBee (3.3 volts with 3mA!) with no need for the extra resistor and transistor.

And guess what's driving the relay this time? An optocoupler! What a coincidence!


Offroad: Salvage Time

For the "Direct Actuation Example" (page 172 and following) I will have to deviate from the proposed course of action due to two reasons. First in germany we have a 230 volts AC power grid. That means I have to substitute the 110 volts power switch tails (SFE COM-09842) with a 230 volts version as proposed in one of the preceding blogs 230 volts power switch interface .
Second I would like to build an RF alternative where no direct connection between microcontroller/ XBee and the switching device is needed. For that project I needed only one additional (electronic) part and was to stingy to order it online and pay a multiple of shipping costs compared to the tiny electronic part I needed. I was surprised how much of "them" I found in my pile of old electronic devices waiting to be salvaged (you can find more about that here). Could you guess what I was looking for?
Details shortly.


I was looking for

You can switch a lot of things with the help of optocoupler. They have names like "4N35", "CNY17F-4" or "PC817". The special thing is that the circuits aren't galvanically connected. You can learn a lot of optocoupler here.


Sleeping Be(e)auty

Voltage regulator LM2937, XBee (End Device), LM335
One thing I was really waiting for was the "sleep mode" feature of the XBees. This might be a huge energy saver.Mobile Sensors with XBees running on two batteries without microcontroller could be as tiny as a pocket lighter and run for months (or years) without changing the power source!
Thinking about solar powered/ energy harvesting devices they could even stay longer connected to a (sensor-) network with the possibility of bidirectional communication (transmitting sensor data or actuate a device). A lot of applications could come into mind where neither wires nor a AC power source is required.

With "Sleep Mode" End Devices are introduced in Chapter 6 which differ from routers mostly by falling asleep for a certain amount of time. Because they do, you might have trouble. I will tell you later what my personal experiences were while digging through the first pages of the chapter.

To begin with you have to configure the XBee as an end device and configure the corresponding AT commands for your intended project. Again everything is described very well in the book. Until text meets "expert" (me).


Check all the settings twice while programming the commands via the terminal. After writing it to the XBee flash your bee might turn into a lifeless piece of epoxide resin if you made a "fat finger trade"  - that means you typed in any command that turns the XBee into a dumb object. Or into a hyperactive. As I did.

In the parts list of the "Simple Sensor with Sleep Project" there is an alternative configuration with two AA batteries mentioned. If you read my blog entry about the LM335 issues, you might have noticed, that I had some problems getting exact temperature readings if the supply voltage falls below a certain value. I suspect unless the batteries are very, very fresh you might get into trouble with this double AA option and get erroneus readings. I tried it with batteries and rechargeable batteries and both didn't work at room temperature.

But everything worked fine with "normal" supply voltage. I put my multimeter into current measurement mode and could observe how the current consumption fell from about 41.75mA to 2.39mA for a second to go up again like the interval (ATSM4, ATSP64, ATST14) programmed into the XBee.

LM335 directly connected to PIN 13
2.39mA.Hm. That's not zero while sleeping. The LM335 draws 1mA at 25°C (supply voltage 3.3V, resistor 330 ohms). The rest goes to the voltage regulator (quiescent current 1.4mA, datasheet says 2mA so that's in line with the specs). I did some tests and connected the Vcc of the LM335 (330 ohms resistor) to pin 13. This pin is only "HIGH" when the XBee awakes. So the temperature sensor only draws current, when the sleep mode is inactive. At room temperature everything worked well - I got the same temperature readings as before. I'm still thinking about getting the 3.3 volts without voltage regulator. Two batteries are not sufficient for the LM335, three would be too much for the XBee (Vcc limits: 2.1 - 3.6 volts). Any hint how to solve this problem is appreciated.

One last word regarding typing in the AT commands for the sleep mode. Somehow while testing some options I typed in something wrong. The result was a non- or better hyperactive reacting XBee. I spent a lot of time to get the device into command mode with the help of the terminal in X-CTU. If you look for the green "DTS"-light and at the same time typing in the "+++" you have a chance to talk again to the XBee. I was lucky and tried to program the settings described in the book. And again my XBee got hyperactive. In the end I flashed a router firmware (after an arcade like typing to get into command mode) and then went back to an end device firmware. Keep in mind to activate "always update firmware".


Offroad: Programmable XBees

If you were wondering if there is a way to put some logic into the XBees have a look at the digi.com Website. Under "Learning Center -> Video and Recordings" you find a lot of XBee related video stuff. One of the recent additions to the XBee product line (see XBee/ RF Family Features Comparison) are the programmable XBees. They are called "XBee-Pro ZB (S2B)" (XBee-PRO Programmable Extended Range Embedded RF Modules) and have a 32 KB Flash/ 2KB RAM Freescale MC9S08QE application processor. You get full insight of the new Bees if you search for "Programmable XBee" in the video section.


LM 335 issues

2.9 volts, 2* 3.3 volts
Those LM335 issues as stated in my last blog entry are still bothering me. I did some additional tests and found out something interesting (at least for me). If the voltage drops below 3 volts, the LM335 begins to post erroneous values. That may be no surprise because the circuit has a typical operating output voltage of 2.98 volts (at 25°C) according to the datasheet (page 2 "Temperature Accuracy").

I wonder if 3.3 volts as used in the preceding experiments are enough power to operate the LM335. I couldn't find any minimum operating voltage specs in the datasheet except an application information on page 6 ("Minimum Temperature Sensing") where V+ is 15 volts for three temperature sensors. My guess is, apart from powering the LM335 with the needed current  through R1 (400µA to 5mA) you need at least 5 volts for stable operation. Tell me if I'm on the wrong track.
I'm also still wondering how to calculate R1, which in my understanding supplies the required current to the LM335. Any input from a reader would be very welcome.
At the moment I'm preparing chapter 6 "Sleeping, then changing the world" where operation with two AA-Batteries is used to power the end nodes. Having the questions above I'm wondering if any operation only from batteries and without voltage regulator is possible at all. The XBees will be no problem - they operate from 2.1 to 3.6 volts according to the datasheet (the PRO needs 3 to 3.4 volts). But what about the LM335?

Update: While surfing the web I found some entries how to calculate R1. As the temperature sensor acts like a voltage divider and everything bases on Ohms law you have to calculate the circuit voltage (in our experiment 3.3 volts) minus the LM335 voltage (depending on the temperature, at 25°C 2.98 volts) and divide it by the needed current (400µA to 5 mA). In short: R1= (Vcc - Vlm335)/ (0.4 to 5mA).
That gives you an envelope which you have to adjust to your expected temperature range.

Sounds a bit confusing? Here are some examples:

Vcc is 3.3 volts, temperature is 25°C (= 2.98volts Vout LM335):

R1 = (3.3V - 2.98V)/ 0.0004A = 800 ohms (400µA = 0.0004A)
R1 = (3.3V - 2.98V)/ 0.005A = 64 ohms (5mA = 0.005A)

So for "room temperature" (25°C) the suggested value of 300 ohms for the circuit works well (everything from 800 to 64 ohms actually should work at least exactly with 25°C ambient temperature according to the datasheet).

What if temperatur changes?

It's 10mV per °K so to reach 3.3V as output from the LM335, everything above 55°C might be a problem because supply voltage almost equals LM335 output voltage (2.73 volts + 0.55 volts = 3.28 volts). At -40°C (= 2,33 volts Vout LM335) and 64 ohms (as calculated above) you would exceed the current with a value of 6.25mA. With 300 ohms you are still safe (3.3mA current for LM335 at -40°C).

So from -40°C to ~55°C and 3.3 volts supply voltage taking 300 ohms for R1 we might be safe.

What if supply voltage changes?

Let's assume supply voltage drops to 2.93 volts generated by two (rechargeable) batteries. At "room temperature" (= 2.98 volts Vout LM335 at 25°C) we might have a problem (at least in a normal climate condition).
Temperature has to drop to about 10°C or lower (2,83 volts Vout LM335) where you could use a R1 from 2 ohms (5mA LM335 current) to 20 ohms (400 µA LM335 current). With the suggested 300 ohms you would fall below the required current for the LM335.

The options:
  1. You could use a second power supply/ step-up converter with at least 3.8 volts (according to the datasheet the LM335 operates up to 100°C). You might have to adjust the resistor value for R1 to your expected temperature range. Same for digital sensors like DS18S20/ DS18B20 because power supply ist 3 to 5.5 volts according to the datasheet.
  2. Take an alternative temperature sensor like the TMP36. This part needs a supply voltage from 2.7 to 5.5 volts which would be almost perfect for two-batterie powered devices and maybe also for a two rechargeable batterie-pack if the voltage stays above 1.35 volts each (I'm not sure how low the voltage might drop before the TMP36 quits working).
For more insight on temperature sensors there is a great tutorial at Ladyada.net.


Hot and cold bee(r)s

Voltage regulator, XBee, LM335
One of the most common applications (with microcontrollers) is measuring temperature. Whether it's the current outside temperature, the climate in your freezer or for controlling the heating installation in your house - you will need at least a thermal sensor. With XBee you need no long wires at all and additionally you can create a temperature network around the house and display everything on your computer (with a little help of Processing). Awesome!

LM2937ET-3.3 (top), LF33CV (bottom)
That's what the "Simple Sensor Network" is about in chapter 5. New to the game are 3.3 volt regulators and the very ubiquitous temperature sensor LM 335 (Datasheet). I couldn't get the recommended LD1117V33 and bought two different voltage regulators instead - LM2937ET-3.3 and LF33CV . Two different ones because I wanted to test how much power they use while regulating and which one would be better for any power saving mode, if there is a difference at all (more on that later). In any case check the order of the legs - in my case for both regulators from left to right with the writing on the front: IN, GND, OUT (the LD1117V33 has GND, OUT, IN).

Update 5-15-2011: I was revisiting the voltage regulator wiring as I was beginning the "Direct Actuation Example" in Chapter 6, pages 172 following. It looks like the LD1117V33 is wired the wrong way in Figure 5-6. According to the datasheet the legs are GND, Vout and Vin when viewed from the front. The upper rail for GND  in Figure 5-6 is connected to Vout, Vcc 3.3 volts is connected to Vin. It also looks like the capacitor and the hookup wires from the power plug are connected the wrong way. So be careful and double check the whole voltage regulation for this experiment. The text and figures 5-4 and 5-7 seem to be ok. I submitted it to the Errata and got the following answer:
"Unfortunately 3.3V regulators do not have standardized lead arrangements. As the instructions say on page 145, 'The regulator has three legs - typically, ground, output, and input - when viewed from the front (where the writing is). Sometimes these legs are in a different order, so find and check the data sheet if you're not sure!'
Fritzing uses one of the alternate pin arrangements (IGO). We can bring this up with them and redo the diagram in a future printing, but the caution still applies." 
Setting up the three XBees is a nobrainer - the AT commands are very well explained in the same chapter so no surprise at all. If you haven't done so it's now time to solder another breakout board for the new XBee. Then everything has to be placed on the breadboards.

There is little room near the voltage regulator if you take (bigger) capacitors (e.g. suited for higher voltages) - Figure 5-4 looks a bit crowded near the regulator. I took capacitors with a small form factor rated for 16 volts which might be more than enough. Anyway you could place them as suggested in Figure 5-6 (page 149) then you have more room for everything. I'm not sure the capacitors should be very near the regulator, maybe someone out there could answer this question.

Be aware that the resistor connected to the + (middle pin) of the LM335 is 300 ohms and not 300 kohms as described in figure 5-6 and 5-7.The voltage regulator (labeled with "7833") and the temperature sensor are both labeled "U2" in Figure 5-7 - only a minor typo - but you should "cut" the ground connection from Pin1 (XBee) and the voltage regulator. Figure 5-6 shows the correct connections.

Next is installing "Processing". Everything went fine on my computer and I only had to replace the COM-port entry which is "COMx"  (x stands for the port number) in Windows. I had two sensors connected and after starting the Simple_Sensor_Network.pde everything took place like it is described in the book. There was only one error in the lower window: "[XBee Packet Parser Thread] [WARN] [com.rapplogic.xbee.api.PacketStream] Found unescaped special byte base10=19,base16=0x13,base2=00010011 at position 4". The program worked anyway.

One thing you really have to think about if you are planning to use the LM335 is calibrating the sensor. I have five sensors and some are "wrong" up to 3 degrees centigrade. I also had some trouble calibrating the sensors and it looked like they were still shifting after calibrating them. In the past I used to take the (digital 1-wire) DS18x20 temperature sensors - I'm still not sure if there is a way to connect them directly to the XBee and send the data to the coordinator for displaying it on the computer (another new item on my TO-DO-list).


Happy Easter!

Currently I'm working on the "simple sensor network". Well, this is how it sometimes looks like in my shop while working on the projects. But this time strange objects found their way on the table!

Happy Easter!


Twilight Bee

Chapter 4 shows how to use the XBee direct without help of the Arduino (at least on the sensor side). This was one thing I was really waiting for, because getting rid of the microcontroller makes the whole thing much smaller and less energy consuming (and also cheaper!). There is no logic in the XBee used in the book, but you can already do a lot of things with the existing digital/ analog pins.

Romantic lighting sensor
For the "romantic lighting sensor" a LDR (for more background read this fantastic LDR tutorial) is used as the sensor connected to the XBee. Theory: The "data" is acquired by a voltage divider which ideally and depending on the fixed resistor puts out a voltage of up to 1.2 volts.

I had some LDRs on stock which had values of about 1 kOhm at 100 lux and about 8 kOhm at 10 lux (the darker the more resistance). This was almost equal to the LDRs recommended in the books parts list (page 94) so I could also use the 20kOhm resistor. Could I?

added lines of code to print the values
Although everything is described very well in the book I had to really think about this whole voltage divider idea. I finally think I found (my) error. Until now I always connected the variable resistor to Vcc and the fixed resistor to ground in other experiments. So if the resistance went down (brighter light) the higher the value on the anlaog input pin on the microcontroller and vice versa. The code on pages 101-103 says exactly this. But this time the values were inverse. The brighter the light the lower the resulting value/ volts.

In my example this meant (I added some lines of code to get the results in the serial monitor):

~ 100 lux

~ 100 lux: analogValue of 97 (0.11 volts)
~ 10 lux: analogValue of  611 (0.71 volts)

In the experiment the LDR is connected to ground and the fixed resistor to Vcc. If I calculate the formula:

Vout = (R2 (LDR)/ R1 (fixed resistor) * R2 (LDR)) * Vin

~ 10 lux

I get (at ~ 100 lux, LDR resistance ~ 1 kOhm, fixed resistor = 20 kOhm):
Vout = (1 kOhm/ 20 kOhm + 1 kOhm) * 3.3 volts
Vout = 0.157 volts

for ~ 10 lux (LDR resistance ~ 8 kOhm):
Vout = (8 kOhm / 20 kOhm + 8 kOhm) * 3.3 volts
Vout = 0.94 volts

The calculated values show the same trend I found in the practical excercise.

LDR covered to lower the brightness
The funny thing is that the experiment exactly works as it should be. If it's too bright (in my case at about 20 lux) the light goes out and if it's too dark (< 10 lux) the same. In between the LED is on.

I'm kind of stuck now with this experiment. Do I have an error in reasoning or should the code tell exactly the inverse: analogValue low = too bright, analogValue high = too dark)?

Anyone to the rescue?

230 volts power switch interface

For the "direct actuation example" (chapter 6) I still needed an alternative for the power switch tails (SFE COM-09842) because in europe there is largely 230 volts in the power grid.

Parts of SI 230-2
I found the SI 230-2 230 volts switch interface at ELV (thanks to Olli!) which you can either assemble by yourself (14,95 Euro/ ~ $21.53) or buy the already assembled part (24.95 Euro/ ~$35.90). I chose to build it by myself and it's quite easy to solder and put together. No SMD parts and everything fits very well. Only the instructions could be a bit more detailed.
You can switch the interface with 4-18 volts DC (6-48 mA) with a maximum switching frequency of 0.5 Hz which means you can switch every second or longer.
Assembled SI 230-2
It operates up to 230 volts with 16 amps - so you could drive almost everything needed in the house. The switch input socket is for a 3.5mm audio mono jack plug.

In the meantime I also built the "romantic lighting sensor" and will post the results in a few days.


Buzz LightBee

Arduino meets XBee.

After some Arduino basics, installing the IDE was quite easy. You only have to watch for installing the windows drivers for the Arduino Uno board. That's what I forgot, but after reading the IDE-installing-tutorial everything went fine.

If you already did some programming in C or any similar language and played with some microcontrollers the IDE and language look quite familiar. If questions arise, there are a lot of tutorials and information available not only on the Arduino Homepage but in serveral other Arduino communities and information sites (s. page 64/ 65) around the web.

Next is heating up the soldering iron because the breakout boards have to be finished. If you plan to order the breakout boards from Sparkfun pay attention to the wrong part number in the parts list on page 67. The right part number is "BOB-08276". If you have to order additional electronics parts like LEDs or resistors, consider buying the 2.54mm/ 0.1" headers and the 2mm female headers there. They might be much cheaper there.

Fixing the male headers
Third hand tool
A very good advice mentioned in the book is putting the male headers into a breadboard and then putting the breakout board on top and soldering both together. After that you can put the female headers into the breakout board, turn it upside down and use a third hand tool to solder the female headers.

3.3V voltage check
Wiring the boards together is quite easy because there aren't that much connections. Just remember to unplug the wire into RX (pin 0) on the Arduino before uploading the compiled code. Also a good advice is checking the voltage BEFORE putting the XBee on the breakout board. One drawback in the printed (black & white) edition is that Vcc/ GND (+/-) are not labeled, so you have to take care when wiring everything together. Any labeling in future (printed) editions would be a great help.

Button system
If you don't want to buy the long jumper wires, you can solder them easily by yourself by connecting any adequate wire and a single headerpin of the male 0.1" headers, solder both together and put a heat shrink tube over the connection.

There is not much more to say about the button and the bell system. Everything is described very well, so I did not hit any roadblock. Except I first had a buzzer which draw too much current and didn't buzz but sounded more like whining, I had no issues at all. After replacing it with a 5mA type, the buzzer was clearly audible.


Offroad: With RSSI one XBee finds the other

I like manuals.

After my first very basic range experiments (see previous blog Bee-Chat) I questioned myself if there is a more accurate way to determine signal strength. Of course there is and you only have to look into the XBee manual.
Search for "RSSI" (RX Signal Strength Indicator) and you will find at least two sections where the RSSI function is described in detail.

For example in AT-mode, which means the XBee is either capable of command or transparent mode, you could type in "hello" then put the XBee in command mode with "+++" and then enter "ATDB". You get a hexadecimal value which "returns the RSSI value (measured in –dBm) of the last received packet". This only works if there is a direct connection, but for the moment this is the case and it does the job.

Very simple distance check
The lower the value the better. 

I got hexadecimal "1A" when laying two XBees side by side. As far as I understand this means -26dBm. I tried some other positions (inside my house) and the value went up to hexadecimal "5C"/ decimal 92 in the corner furthermost away.

This opens a lot of options for future applications.

If you are one of those people who regularly forget where they left their keys, two XBees could help. Or you need any sort of very simple distance meter (yes, radio waves are not that great for accurate distance measurement), proximity sensor or whatever application where a raw value of distance of two things is needed - two XBees would do. A lot of things might be possible with this already embedded function...



After I could configure one XBee module to communicate via the serial terminal application Tera Term (Hyperterminal/ Windows XP also worked for me) the next step in the book was the "Basic XBee Chat".
I wrote down the low bit of the 64-bit address of each XBee and set up everything as described (PAN ID, ATDH and ATDL). I programmed everything with ATWR to the modules and double checked the configuration by typing in the AT commands without values.
I connected both XBee modules with the computers and both responded to my inputs in Tera Term.

Time to chat.

Nothing happened. Uh.

Finally I ran into trouble (but thats what I like most, at least most of the time). It was quite easy to find my mistake by reading the Troubleshooting and turning my brain on. Of course you have to tell the Coordinator XBee the destination address of the Router XBee and vice versa. The bees chatted a bit and then it was time to do some extra work for them. A range test.

I was impressed how far you can go with only 2 milliwatts. I covered every place in my house which has quite thick stone walls and is 3 floors high plus attic.Every signal was received by the coordinator which sat in the other corner of the house. So there is no need for a bee-network at all - at least in the house - and for everything else there are much more powerful bees out there.

For more thoroughly checks one could build a signal strength meter, if range is crucial. Time to read the XBee manual.


Talking to my bee

Today I started with the practical part (page 32). I downloaded and installed X-CTU from digi.com and even if digi.com says the software is suited only for 32bit systems everything went well on my Windows 7 64-bit. I don't use Linux or Macintosh on my desktop so I can't say much about that.

After installing and updating the new firmware versions I attached one XBee on the XBee explorer USB adapter and connected it with my USB A-to-B-mini cable to my laptop. Windows automatically installed the required USB/ serial drivers.

With X-CTU I could conduct the "test/ query" option on the "PC Settings Tab". Also reading the modem configuration was easy and worked well from the beginning. I then configured two XBees as described - one as a Coordinator AT and one as a Router AT. I marked them with a label "C" and "R". Again, no hassle at all.

The book makes a wonderful job describing everything so accurate. So there were no problems installing Tera Term, configuring it and typing the three "+++".


I just talked to my bee!

Using AT commands went smooth again - I just have to get used to not to press return after the three "+++". Talking with one bee now seems easy - next will be the bee-chat.


Delivered, Part II

Before ultimately beginning with the experiments , I again scanned through the book one more time and looked through the parts lists, almost sure I forgot something to order.

So I discovered that I would need some temperature sensors (LM335) and 3.3V voltage regulators (I took 2 LM 2937 ET3,3 and 2 LF 33 CV instead of LD1117V33). I will explain later, why I took two different regulators. I'm also not sure if the 500 mA they deliver will be sufficient. Anyway I have to substitute the 110V Power Switch Tails (parts list printed edition page 173), because in germany we have 220 volts. I have an idea for a workaround, but more on that later.

LM 335, LM 2937, LF 33 CV, headers and resistors
I also ordered some male and female headers and some resistors which I didn't find in my inventory.
I really like the german online-distributor Reichelt, where you can get almost everything you need if it's about electronic parts. They are almost always a bargain. But this time - and it was the first time ever I had an issue with them - they delivered a parcel weighing 1305 grams but the electronic parts are only 34 grams. Not very eco-friendly - maybe that's their standard package for the smallest deliveries they have.
Xbee explorer, breakout boards, Arduino Uno, breadboard

I planned to etch some pcb's later on as mentioned before. But for the time being I switched back to buy assembled parts. That saves time (I'm already quite impatient to wait any longer to start). So I ordered some required parts at Tinkersoup (thanks to Anton for replying my mail so fast) - there I also got the badly needed xbee breakout boards! That was the fourth order for this project and it went as smooth as all the others. Great service.
And: Thank you Internet!


Delivered! USA 1 : 0 GER

WOW. That was fast.

Xbees, Arduino Uno, XBEE Explorer USB, mini breadboard

Looks like that are supersonic bees I ordered at Mouser.com. They arrived (from Fort Worth, TX) before the other stuff from germany came to my doorstep.
So it's USA 1 : Germany 0 (obviously it's NOT soccer).

Now it's time to let'em loose!