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.



Perfboard back side




4. 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.

Update:

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).

WARNING.

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.