Level-Shifter for XBee & Raspberry Pi

Some projects have mixed supply voltages (e.g. 5 Volt and 3.3 Volt) and sometimes integrated circuits don't work with those unequal signal levels - or worse get damaged by the higher level supply signals.

Level shifter pcb

In case of the XBee which is driven by 3.3 Volt up to now I added a simple resistor divider to get the signals down to the lower supply level (see this older post ). But even if you feed the XBee without translating the different supply levels, I never got any problems (but I wouldn't recommend).

It might look slightly different with the Raspberry Pi, so to be on the safe side I built a simple 2-bit bidirectional voltage-level translator circuit for the alleged thin-skinned RasPi. You just need four 10k resistors, two BSS138 (N-Channel Logic Level Enhancement Mode Field Effect Transistor) and two four-pin headers.

I etched the board by myself but if you want to take the short way, there are already breakout boards and ICs available (e.g. Sparkfun Logic Level Converter, TXS0102 from Texas Instruments or ADuM1250/ ADuM1251 from Analog Devices).

Anyway I wanted to do some practice with my favourite pcb layout software Eagle and designed this simple pcb.

How does the level shifting work? If nothing happens on the bus (in this special case on the I2C-bus, thats what the pcb is labled for, but it also works with RX/ TX or any other 2-bit bidirectional digital purposes) all signals are pulled high by the 10k resistors. If either side goes low, the N-Channel MOSFET steps in and also pulls the signal line low, either because it turns on (low level side) or passes through the body diode (high level side).

Electronic compass

Just a note to a little project I'm building at the moment - an electronic/ digital compass:

There is no XBee involved - but a Nokia5110 lcd display, an Arduino Nano, a 2-axis compass module (HDMM01) and a HCF4050 for level-shifting. Of course you could add a XBee if you are using the compass for a robot or other mobile project.

And yes - the Halloween project is still to be posted. Just give me some more time.

Project XSkull

Halloween. Early darkness in fall. Pumpkins everywhere. Little kids in fancy costumes demanding candies.

XSkull with glowing eyes and moving jaw

So why not greeting them appropiate with an Arduino-based project combining a skull with red glowing and fading eyes and moving jaw which is servo operated and XBee-remote controlled. Haze in the dark from a fog machine which is radio controlled and triggered via XBee. Where the status of the heating-up process is reported back to the remote control where an illuminated switch is lit when the fog machine is ready? Where another switch can control a light or sound source?

That's what I will present in the next weeks until Halloween. Hardware, Arduino-Sketches and XBee configuration will be explained. For the beginning here are some photos. Have fun!

Remote control

 The remote control consists of an enclosure where an Arduino nano and a XBee are the main parts. With a sliding potentiometer you are remote controlling the moving of the skull-jaw. The red momentary switch shows the status of the heating-up process of the fog machine and signals it with the internal LED. If you push the switch fog will evaporate. Everything is driven by a 9 volt battery and the circuit can be activated by a rocker switch. One additional illuminated green switch can control another source like light or sound and signal an additional status to the remote control.

Fog machine

A servo which is connected to an Arduino Uno in the brain of the skull controls the momentary switch on the fog machine so that there is no need to work with high voltage. The light of the bulb which signalizes the heating process of the fog machine is analyzed by a light dependent resistor (LDR) which reports the resistance to the Arduino Uno which then sends the value via XBee to the remote control and lights the LED on the red fog switch when the fog machine is ready.

XBee Internet Gateway now for Windows, Linux and Macintosh

The XBee Internet Gateway - an open-source project written in Python - is now released to be run under Windows, Linux and Macintosh (XBee Internet Gateway Software).

Before you had to connect a Digi ConnectPort or any other form of XBee/ Ethernet combination to feed data through your XBee(s) into the internet. Now you just connect the XBee on a USB adaptor to your PC and run the XBee Internet Gateway software.

Carefully read the installation instructions, because your XBee firmware needs some special settings to connect to XIG. After this it should look like this:

XIG Windows software displayed in browser

Raspberry Pi and XBee

XBee perfboard hooked up to the Raspberry Pi

One nice gadget to play with is the quite new Raspberry Pi. I added a XBee (Coordinator AT) to the RasPi and sent some serial data to an Arduino UNO (and back) with a XBee attached (Router AT) via serial terminal (minicom) and Python.

The RasPi is running on Debian wheezy and the perfboard is connected via two row header sockets to the GPIO pins.


The 3.3V for the XBee is directly coming from Pin 1 of the GPIO-Header (GND from Pin 6), DOUT is connected to Pin 10 (GPIO RXD) and DIN to Pin 8 (GPIO TXD). I didn't test it with a XBee Pro attached, this will certainly draw too much current from the RasPi. The 3.3V supply only delivers 50mA as per this wiki . This is fine with the normal XBee which has 40mA max. current demand as per datasheet. If you need more current (XBee PRO needs 295mA@3.3V when transmitting with maximum output power) you could use the 5V power source with a subsequent voltage regulator as mentioned in the blog entries before. Be careful to use a voltage regulator with enough capabilities to deliver ample current.

Still enough legroom for the Raspberry Pi

One big advantage beside being wireless is that there is no level converter needed as the signals are 3.3V TTL to and from the Raspberry Pi.

To get the whole thing working you have to modify some settings in Debian wheezy. There is a nice walkthrough in this blog.

If you want to communicate via Python you have to get pyserial (sudo apt-get install python-serial or sudo apt-get install python3-serial for Python3). Example code for Python2 to send a value to the Arduino would look like this:

import serial
xbee=serial.Serial(port='/dev/ttyAMA0',baudrate='9600')
xbee.write('8')


For Python3 you would have to change the last line to:

xbee.write(b'8')


to send as a String.

On the Arduino side you could read the incoming data with Serial.read().

Connecting the whole thing together gives a huge amount of opportunities for future projects as one can use the combined cpu power/ linux system/ graphic abilities of the Raspberry Pi and the microcotroller skills and shields of the Arduinos - everything wirelessly connected in a mesh network.

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) {
    lcd.print("0");
    lcd.print(hour,DEC);
  }
  else {
    lcd.print(hour,DEC);
  }
  lcd.print(":");
  if (minute < 10){
    lcd.print("0");
    lcd.print(now.minute(), DEC);
  }
  else {
    lcd.print(now.minute(), DEC);
  }
  lcd.print(":");
  if (second < 10){
    lcd.print("0");
    lcd.print(now.second(), DEC);
  }
  else{
    lcd.print(second, DEC);
  }

  int month = now.month();

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

  // 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);
      delay(50);
      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.clear();

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

    }
  }
}

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

/* REMOTE AND LOCAL TEMPERATURE SENSOR WITH:
ARDUINO UNO, TMP36, AD22100KT, RTC DS1307, TWO SERIES 2 XBEES

AND 16*2 LCD-DISPLAY

Ver 0.1
by Markus Ulsass
http://lookmanowire.blogspot.com/

*/

/*
*** XBEE CONFIGURATION ***
 
 RECEIVER: (BASE STATION)
 COORDINATOR
 ATID 2001 (PAN ID)
 ATDH 0
 ATDL 0
 ATAP 1 API mode enable
 ATSP AF0 sleep period according to longest sleep period on end device

 SENDER: (REMOTE SENSOR )
 END DEVICE
 ATID 2001 (PAN ID)
 ATDH 0
 ATDL 0
 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>

RTC_DS1307 RTC;

// 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
  Wire.begin();
  RTC.begin();

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