Archive for the 'Electronics' Category

Quick test with Xbee alternative: Ciseco XRF module

This is a quick post to explain how to get a pair of Arduinos talking to each other wirelessly, using XRF wireless modules from Ciseco. They actually work straight out of the box, but if like me you like to have some instructions to get you going then hopefully you’ll find this post useful.

I’ve recently started learning/playing/experimenting with Arduino - an open-source microcontroller. Reading around, I saw lots of people mentioning Xbee wireless modules, which enable your Arduinos to talk wirelessly to each other (or to your computer) which sounded fun. However, the Xbee modules I’ve seen generally tend to operate at 2.4 GHz (along with every other wireless device in my home and the houses around me like cordless telephones and wi-fi), so I wasn’t really keen to add the the radio pollution in that band. They’re also moderately expensive (starting price circa £20 each with a range of 100m or so, and don’t forget you need a pair). But then I came across the XRF wireless module from Ciseco.

For about £10, you get a wireless module that’s pin-for-pin compatible with Xbee (Series 1), works over a range of different frequencies (868.3MHz by default, but also 315MHz, 433.5MHz, 868MHz, 903MHz and 915MHz), and has a standard range of approximately 300m (although ranges of over 3 Km are claimed). At this point I should make it clear that I’m a complete beginner at this stuff, but I was curious so emailed Ciseco with a few of my newbie questions. Their responses were quick and made everything sound simple, so, loving a bargain and challenge, I decided to order a pair and have a tinker.

Shopping List

The shopping list was pretty minimal. I already had an Arduino Uno and an Arduino Ethernet, so as well as ordering 2 x XRF modules, I also ordered 2 x Ciseco Xbee shields. These sit between the Arduino and the XRF, and were about £17 each. So although these are about the same price as alternatives, they have some nice features like an onboard 3v3 regulator, automatic disabling of the TX/RX lines when uploading a new sketch to the arduino (means you don’t have to unplug the XRF/Xbee when replacing the sketch), and space to solder on additional components (sensors, things that go blink etc….).

A simple test

I was assured that using the XRF was easy, and that when using the Xbee shield it was simply a matter of:

  1. Plugging the three PCBs together (Xbee shield into the Arduino, and the XRF into the Xbee shield),
  2. Enabling the XRF module by holding pin 8 high, and
  3. Reading/Writing between the two Arduinos using standard commands.

I admit that it sounded much easier than I was expecting, so, with a little disbelief, I dropped the following code onto my arduinos. First up, a “Beacon”. This just sends the letter “H” (for Hello) every few moments, and listens for the letter “K” (for OK) in response. (Actually it doesn’t care if the letter K is in response to anything - it just listens for the K regardless.) If a letter K is received then the status LED on pin 13 of the Arduino Uno it lit for a moment, and because this LED is difficult to see (with two PCBs stacked on top of the Uno) I added in a piezo buzzer too — wiring it straight on to pin 7.

You can grab the PDE file for this sketch here: XRFTestBeacon.pde. This should compile to 3566 bytes. Note that it doesn’t do much on its own; you need to grab the second file below.

/* XRF Arduino Test Sketch - Beacon
 * Full details of this example:
 * Simple sketch to check the XRF radio modules are working.
 * Broadcasts the letter "H" (Hello) every 5 seconds.
 * I'm using 2 x XRF modules and 2 x Xbee sheilds from Ciseco, and an
 * Arduino Uno and Arduino Ethernet. The default XRF baud rate in 9600.
 * This sketch (1 of 2) is running on the Arduino Uno, which has a
 * built in LED on pin 13. A piezo beeper was connected to pin 7 for
 * audiable acknowledgment of activity.
 *  Created 4 Dec 2011
 *  by Mark Sweeting -

int LEDPin = 13; // built in to the Uno PCB
int XbeeEnable = 8; // powers up the XRF when using the Xbee shield
int BuzzerPin = 7;
int BuzzerTone = 6000;
unsigned long lastBeaconTime = 0;
unsigned long nowTime = 0;
unsigned long LEDTime = 0;
int beaconInterval = 2000;
int LEDPeriod = 300;

void setup()
  pinMode(LEDPin, OUTPUT);
  pinMode(XbeeEnable, OUTPUT);

  // Turn XRF on
  digitalWrite(XbeeEnable, HIGH);


void loop()
  // Get the current time since power-up
  nowTime = millis();

  // Send the letter 'H' ("Hello") on the serial line every few
  // seconds
  if((nowTime - lastBeaconTime) > beaconInterval)
    lastBeaconTime = nowTime;

  // If we receive the letter 'K' (for "OK"), then turn the LED on
  // for a moment and beep the buzzer
  if(Serial.available() > 0)
    if( == 'K')
      LEDTime = nowTime;

    digitalWrite(LEDPin, HIGH);
    tone(BuzzerPin, BuzzerTone);

    // Turn LED off after a short period
    if((nowTime - LEDTime) > LEDPeriod)
      LEDTime = 0;
      digitalWrite(LEDPin, LOW);

The beacon “relay” code is even simpler: it just listens out for the letter “H” and sends a letter “O” in response. It was running on an Arduino Ethernet, and this doesn’t have a status LED on pin 13 so there was nothing for me to blink without wiring things in. For the purpose of the demo there was no need.

You can grab the PDE file for this second sketch here: XRFTestBeaconRelay.pde. This should compile to 2234 bytes.

/* XRF Arduino Test Sketch - Beacon Client Relay
 * Full details of this example:
 * Simple sketch to test a pair of XRF modules are working. Listens
 * for the letter "H" (Hello) on the serial line, and sends the letter
 * "K" (OK) in response.
 * I'm using 2 x XRF modules and 2 x Xbee sheilds from Ciseco, and an
 * Arduino Uno and Arduino Ethernet. The default XRF baud rate in 9600.
 * This sketch (2 of 2) is running on the Arduino Ethernet which
 * doesn't have a built in LED, so there's nothing for us to blink by
 * way of acknowledgement.
 *  Created 4 Dec 2011
 *  by Mark Sweeting -

int XbeeEnable = 8;

void setup()
  pinMode(XbeeEnable, OUTPUT); 

  // Turn XRF on
  digitalWrite(XbeeEnable, HIGH);

void loop()
  // listen out for the letter "H", and send a "K" if we get one.
  if(Serial.available() > 0)
    if( == 'H')

So once I’d plugged everything together and the sketches were loaded onto the Arduinos, I powered them up, waited, and bingo! The beeper started to beep, meaning the letter “H” was being received by the second module, which was sending the letter “K” back in response. So it really was as simple as the folk at Ciseco said it would be!

I’m sure I’ll be posting more about the XRF modules in time as they’re pretty canny devices. In the meantime, it’s worth checking out the Openmicros forum (run by Ciseco, and includes a good support forum) as they’re very quick at responding to queries.

Arduino, 74HC595 Shift Register, and a 7-Segment LED Display

So I’ve recently started tinkering with Arduino. Arduino is a pretty easy to use open-source microcontroller. And it’s cheap!

Being a novice I decided to work through a book called Beginning Arduino by Michael McRoberts. I’m up to Chapter 7 and it’s now talking about multiplexing and LED dot-matrix displays, so I wanted to have a tinker. Not having a dot-matrix display to hand I decided to see what I could come up with myself. I had purchased a Sparkfun Beginner Parts Kit (KIT-10003) and a SparkFun Inventor’s Kit (RTL-10339), which meant I had a small 7-segment LED display (common anode) and a 74HC595 Shift Register IC.

I gave up trying to work out the maximum current I could source (or sink) with the 74HC595 — different sources quoted different values — so to be on the safe side, and to make the project a little more interesting, I decided to write some Arduino code that would only allow one segment in the display to be illuminated at once, but that would cycle between the segments so quickly it would look like they were all on at once. This gave me a chance to look at multiplexing and bitwise operations.

Segments for my display (and this is pretty much universally adopted) are identified by the letters A to G (+ DP, or DecimalPoint), as indicated in the following diagram:

                    F / G / B
                  E /   / C
                    ---  * DP

The pinout for my display is shown in the crude diagram below:

    Common anode (+) pins: 3 & 8
               +---+---+---+-+-+---+---+---+   [+]
               |   |   |   |   |   |   |   |
           /   V   V   V   V   V   V   V   V
       LEDs    -   -   -   -   -   -   -   -
           \   |   |   |   |   |   |   |   |
               |   |   |   |   |   |   |   |
               o   o   o   o   o   o   o   o   [-]
          Pin: 7   6   4   2   1   9   10  5
      Segment: A   B   C   D   E   F   G   DP

So in order to display the number “4″ we need to illuminate segments B, C, F & G, or connect pins 6, 4, 9 and 10 on the LED display to LOW:

                       . . .
                      /   /
                    .   /
                   . . .

Rather conveniently, a byte is made up of eight bits, so I can use a byte to describe the state of each of these 7 segments (8, if we include the decimal point) for any given character or symbol I might want to display.

The character “4″, shown above, can be described in this binary notation as “0b01100110″:

    LED Segment:  A B C D E F G DP
         On/Off:  0 1 1 0 0 1 1 0

A description of which segments need to be on for each digit, in this binary form, is held in the “numbers” array. This array holds the digits 0 to 9, and A to F.

As discussed, to display the number “4″ we need to illuminate segments B, C, F & G. However, there is a risk that running four LEDs with the 74HC595 could mean too much current is drawn. We’re working at 3.3v, and have a 220 ohm resistor on the cathode, so this should limit the current to about 15 mA. This is safe for the shift register to sink, but sharing this across 4 LEDs would make them pretty dim. So this is where multiplexing comes in!

The code below works out which segments need to be illuminated to display or character, and sequentially lights them up one by one. Only one LED segment is ever on at a time, but the sequence runs so quickly that it looks like all the segments are on at once.

So enough of the theory, and on to the code!

Wire it up

First, the wiring diagram. The wiring is described in the code comments below if you find it hard to follow this diagram.

Grab the code

Download the source code: _7SegCounterMultiplexer.pde (this is a slightly longer version of the code below — it has more annotations & comments).

  7-Segment LED counter, multiplexing using 74HC595 8-bit shift

  Displays a digit by illuminating each individual segment that makes
  it up on the display sequentially, rather than illuminating each
  segment at once. This is done very quickly (multiplexing) to give
  the illusion that all the nesersary segments are illuminated at
  once. This is because the 74HC595 can’t source or sink that much
  current, and lighting all segments for the digit ‘8′ at once for
  example could require too much current and damage the chip.


    Vcc = 3.3v on Arduino

    Arduino pin 5 => 74HC595 pin 12
    Arduino pin 6 => 74HC595 pin 14
    Arduino pin 7 => 74HC595 pin 11

    74HC595 pin 1  (Q1)   => LED Pin 6  (B)
    74HC595 pin 2  (Q2)   => LED Pin 4  (C)
    74HC595 pin 3  (Q3)   => LED Pin 2  (D)
    74HC595 pin 4  (Q4)   => LED Pin 1  (E)
    74HC595 pin 5  (Q5)   => LED Pin 9  (F)
    74HC595 pin 6  (Q6)   => LED Pin 10 (G)
    74HC595 pin 7  (Q7)   => LED Pin 5  (DP)
    74HC595 pin 8  (GND)  => Ground
    74HC595 pin 9  (Q7S)  => Not connected
    74HC595 pin 10 (MR)   => Vcc (High)
    74HC595 pin 11 (SHCP) => Arduino pin 7
    74HC595 pin 12 (STCP) => Arduino pin 5
    74HC595 pin 13 (OE)   => Ground (Low)
    74HC595 pin 14 (DS)   => Arduino pin 6
    74HC595 pin 15 (Q0)   => LED Pin 7  (A)
    74HC595 pin 16 (Vcc)  => Vcc

    LED pin 3 or 8 => 220 Ohm resistor => Vcc

    Created 6 Nov 2011
    by Mark Sweeting -

const int latchPin = 5;  // Pin connected to Pin 12 of 74HC595 (Latch)
const int dataPin  = 6;  // Pin connected to Pin 14 of 74HC595 (Data)
const int clockPin = 7;  // Pin connected to Pin 11 of 74HC595 (Clock)

unsigned long t1;
unsigned long t2;
int i = 0;

// Describe each digit in terms of display segments
// 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F
const byte numbers[16] = {

void setup()

  // initialisation time
  t1 = millis();

  //set pins to output 
  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);
  pinMode(dataPin, OUTPUT);

void loop()
    // update digit every two seconds
    t2 = millis();
    if(t2 - t1 > 2000)
      t1 = t2;
      if(i > 15) { i = 0; }
    // display the current digit

void show( byte number)
  // Use a loop and a bitwise AND to move over each bit that makes up
  // the seven segment display (from left to right, A => G), and check
  // to see if it should be on or not
  for(int j = 0; j <= 7; j++)
    byte toWrite = number & (0b10000000 >> j); 

    // If all bits are 0 then no point writing it to the shift register,
    // so break out and move on to next segment.
    if(!toWrite) { continue; }

    // Otherwise shift it into the register

void shiftIt (byte data)
    // Set latchPin LOW while clocking these 8 bits in to the register
    digitalWrite(latchPin, LOW);

    for (int k=0; k <= 7; k++)
      // clockPin LOW prior to sending a bit
      digitalWrite(clockPin, LOW); 

      // Note that in our case, we need to set pinState to 0 (LOW) for
      // “On” as the 74HC595 is sinking current when using a common
      // anode display. If you want to use a common cathode display then
      // switch this around.
      if ( data & (1 << k) )
        digitalWrite(dataPin, LOW); // turn “On”
        digitalWrite(dataPin, HIGH); // turn “Off”

      // and clock the bit in
      digitalWrite(clockPin, HIGH);

    //stop shifting out data
    digitalWrite(clockPin, LOW); 

    //set latchPin to high to lock and send data
    digitalWrite(latchPin, HIGH);

    // put delay here if you want to see the multiplexing in action!

So how does it work?

Hopefully the code is documented pretty well. However there are a few bits that could be expanded on further perhaps. First, the function show(). It takes a whole byte as an argument (called “number”, which in hindsight may not be the best name to choose…), and remember that these bytes describe each segment that should be on (or off) in the 7 segment display.

So this function moves over each segment in the LED display (A to G, plus the decimal point), and works out if the segment should be off or on in order to display the chosen number. For example, to decide if segment “B” should be illuminated when displaying the digit “6″, we perform a bitwise AND with their two byte values:

    "6" is 0b10111110 and Segment B is represented by the 2nd bit from
    the left  You can see it's value is Off.

    The Bitwise AND operation results in the following:

       10111110  first operand
     & 01000000  second operand
       00000000  outcome of bitwise AND: all bits are Off.

In this example, Segment B isn’t needed to display the digit “6″ so we jump on to the next segment: Segment C:

       10111110  first operand -- "6"
     & 00100000  second operand -- Third bit, Segment C
       00100000  outcome of bitwise AND: Third bit is On.

In this case we need to turn Segment C on, so we call shiftIt(00100000) and pass in a byte that tells us to turn on the third segment on the display. shiftIt needs to clock in all 8 bits, even though only one of them will be on. I’m not about to explain how Shift Registers work — check out the Arduino site for a good explanation and lots of code samples — however I should point out that we need to set a bit LOW when we want to turn an LED segment on, because we’re using the 74HC595 to sink current rather than source it because our display has a common anode.

So there you have it.

There are probably better ways to display digits on an LED, but it’s an interesting technique none the less.