(It’s all on 1 page, w/o extras of forced annoying advertising, besides what hosting site may choose to do…)
The reason behind this project was to see how the Digi’s Xbee modules work, and to figure out how to have the remote modules’ inputs read on another module. The local / receiving module is to receive the api frame to be decoded, with the informaton about the status of the remote / transmitting modules’ input pins. If you want to do the actual ‘pin forwarding’ functionality, you have to deviate somewhat from this setup. (The purpose of all this is to get a feel for using the remote rf module inputs as remote control for rc toys down the road, while also having 2-way serial communication capabilities for data transfers.)
To get things going, I got the ‘XBee Wireless Kit Retail’ (sku: RTL-09897 ) from sparkfun.com
( http://www.sparkfun.com/products/9897 ), at a Microcenter store. The package comes with the following pcbs/modules:
- (x2) XBee 1mW Chip Antenna – Series 1 (802.15.4), sku: WRL-08664;
- (x1) XBee Explorer USB, sku: WRL-08687;
- (x1) XBee Shield, sku: WRL-09976;
- and few tall pin m/f headers.
Getting the basics running:
To get things started and working out of the box, the simplest thing to do is plug each of the xbee modules into the carrier boards (usb explorer or the shield). Plug the usb explorer pcb into the pc (take care of ftdis’ drivers if you don’t have them installed yet), short the tx and rx on the shield pcb, and apply the power to the shield pcb.
( -> I’ll get back on the pins to supply power and to short for loopback).
On pc side, (once you have the drivers installed for the ftdi usb-serial converter) the easiest way to check functionality of that xbee module is to install the X-CTU software from Digi’s website. Select the com port that was setup for the port, and try ‘test/query’ the module on the 1st tab. If that works, try reading the modules’/modems’ info (last tab, read button under ‘modem parameters’ section). That should return all of the info about the module, with the factory settings (assuming it’s new, not used).
To see if both of the modules are communicating, with the shield module (and other xbee module on it) wired and powered up properly, on the x-ctu software, in the ‘rang test’ tab, click the run button. If you want the rssi info, it has to be selected before starting the test. The responses are slower if rssi is running, since the x-ctu software is obtaining additional info from the module, and not just sending and receiving the data sample.
Poking around the configurations:
Once you have proven that it is working, you can do as I did, and explore the options. One thing to do is read up through the manual (and scavenging through somewhat limited and spread information, more explanations later), and see what else the module is capable of and has to offer. After reading for a bit, I started to poke around in hyperterminal… This is where you do the poking, but unlike the x-ctu utility’s ‘modem configuration’ tab, you don’t save things into its permanent memory (eeprom). So if some illegal character, command, or else stops communication, simply recycle the power to the module. Using some terminal utility, until you instruct it to write the altered settings into its eeprom, it’s in volatile memory only, and gets restored to prestored settings from eeprom on power up. For the most part, I got the changes to be immediately applied upon exiting the command mode (wait for it to time out without any more instructions, or send the ‘exit command mode’ command). Once you’re playing with them, you’ll see what I mean. Ofcourse, there are different ways of doing same thing. You could use the terminal utility in x-ctu software, starting software twice, and selecting the appropriate ports, before switching to the terminal tab. I chose to created 2 hyperterminal configurations, one for each port, and just open the 2 different files, for the 2 ports.
Per the datasheet, by default the com port settings are as follows: 9600 baud rate, 8 bits, 1 stop bit, no parity, no handshake. For hyperterminal, I also chose to enable the following options too: (ascii send section) send line ends with line feeds, echo typed characters locally; (and in the ascii receive section) append line feeds to incoming line ends, and wrap lines that exceed terminal width.
Complicate it for maximum flexibility:
Here’s where I like to go off on a tangent. For maximum flexibility, usability, and the most options, things end up being a bit more complicated, but still shooting for functional…
What I wanted was to control both xbemodulesess in command mode, at the same time, w/o swapping out the xbee modules out of the usb explorer module. The catch is that the xbee module looses it’s settings from volatile memory, if powered down, say to swap out the modules. I didn’t want to keep on storing the settings into the eeprom, for if something goes wrong, dealing with attempts at recovering it. If you choose to do so, you may. Bottom line, it worked as envisioned for me, since I’m using it in such manner.
2nd serial interface (to the same pc), voltage levels and pin spacings between it all:
Since I wanted to talk to both of the xbee modules at the same time from the pc, and still have one of them act as remote input, I did some extra work. The package comes with one pc capable module (usb explorer), and one microcontroller interface (audrino xbee shield) module. The nice thing about the usb explorer module is that it has all of the following on it accounted for. If you don’t have one, like me, you ‘learn’ to work around ‘minor inconveniences’. To get the 2nd xbee module to communicate with pc, it has to be connected to some kind of serial interface to pc, like the 1st modules’ usb explorer. This is where I used an older ftdi usb-serial module that I had from before. There are a few catches here, to get it working with what I wanted it to do (remote inputs, and communicate with the pc).
(On a tangent again, at this point in time, obviously if you have a serial port or 2 on your pc, you can use rs232-to-ttl level converter as another alternative. Just be sure that the ttl level that you use is the 3.3v type, like the xbee module expects, and not 5v logic level… This is where I’m going next, as what was required to get the things working.)
Some background about the ftdi stand-alone usb-serial module. The ftdi module is capable of having it’s i/o pins operating on 3.3v and 5v logic. That makes things a bit easier to work with, without requiring additional level converters or adapters (additional hacks). The ftdi module can also operate in (usb) bus powered mode, or stand-alone mode (using external power source). Ofcourse, I did some mix-n-matching to get things working as I wanted. In summary, I wired up the ftdi module to bus powered mode, powering a local voltage regulator. The voltage regulator is then supplying the 3.3v back to ftdi module for the i/o interface, and to the xbee module. I chose to buildd a voltage regulator module on a pcb instead of just having loose parts on thebreadboard. This voltage regulator module is using a LM317 (adjustable voltage regulator).
Note that this setup still doesn’t require any additional external power supplies. All of the power is obtained from the usb bus.
The LM317 adjustable voltage regulator has a 220 ohm resistor from output to adjust pin and 330 ohm resistor from adjust pin to common (see the schematic). For ‘sanity check’ reasons, a reverse voltage diode was added on the input. This diode can be bypassed/jumpered, once the wiring has been proven to work properly. The issue with the arises when using 5v to feed the LM317 (non-low dropout type) regulator, with the protection diode. There’s too much voltage drop across the regulator and the diode, to provide the desired output voltage regulation. Once the wiring is working good, you can short the input protection diode, which will allow just enough room for the LM317 to do its job of providing the set output voltage.
4.91Vin 2.83Vout (good enough to xbee module specs).
With jumper in, bypassing the diode:
4.91Vin 3.15Vout (good, where desired, based on resistors).
With jumper in, lowering Vin until it drops to where it was with jumper removed:
(4.91-4.3 = 0.61V dropped additionally across the diode on the input, an 8.5% drop from the desired Vout. Yes, things are just on the border, but they work for the intended purpose.)
As mentionedd before, another option is to use the xbee shield as the adapter interface to serial converter, and its onboard 3.3v regulator. I choose to not use it due to wanting to see the bare minimum of pins required to get things working for the xbee module (yes, I seem to like to do the things the hard way). This manual setup option also helps with the xbee modules’ 2mm pin spacing, compared to the breadboards’ 2.54mm spacing… So yes, I had to get some adapters for that too. My solution to resolve this inconvenience is that I had some 2mm female connectors scavenged from taking things apart. The loose wires of 2mm connector were soldered to 2.54mm spaced male header, to my desired pinout configuration, which plugs into the breadboard. Killz 2 stones with one birdie.
Per xbee modules’ datasheet, the minimum wiring is to connect the following pins:
- 1 Vcc
- 10 GND (COM)
- 2 TX
- 3 RX
AND the following optional pins:
- To use the input lines as digital inputs, just wire the appropriate pin to a switch, which is wired to GND/COM. By default, the xbee modules’ inputs have the internal pull-up resistors (to vcc) enabled.
- To use the input lines as analog inputs, you have to connect the pin 14 (Vref) to a voltage source. I simply chose the Vcc.
See further down for command(s) and parameters to configure the appropriate pin into desired function.
Note that the RX and TX labels are relative to each of the modules. With this in mind, one modules’ TX goes to the other modules’ RX, and vice verse.
Background on annoyance of scarce and spread information:
The annoyance about this (set ?) of products is the lack of contained and detailed explanation of how to use the product(s)… There seem to be a bunch of different versions of the manual. That’s ok. But none of them contain all of the necessary information, that I have found, to explain all of the functionality of the product. Case in point is the api packet frame for remote pin passing. What I ended up getting lucky to get enough details from the following documents and places…
There are some minor differences between revisions… but still not enough information.
Somewhat confusing, but still helpful information to get the point across about input line passing.
AT command brief.
And the background readings
Didn’t read through this one yet myself…
I’m sure that there are more places…
Xbee configuration with terminal access, using AT commands background:
Background: assuming that terminal is setup, and working, data is passed/looped between modules per above, and all of the settings are still at default/factory settings…
To get into the AT command mode, send the ‘+++’ (plus) symbol three (3) times in a terminal program. DO NOT press enter/return. WAIT about 1 second. You will get ‘OK’ reply. Now you are in the AT command mode. You send the commands prefixed with the letters ‘AT’ and end with enter/return (<cr>). Make sense ??? (Should have seen this mentioned in manuals above already.)
To work in command mode, you have to send the commands within 10 (i think by default) seconds of each other. Otherwise, the xbee module will exit the command mode, and implement the changes you typed in so far. If it exits the command mode (you will not get ‘OK’ or “ERROR’ responses back), simply enter it again (‘+++’ like above). Then retype the commands or just continue where you left off when it timed out.
To see what the status is of the setting, just type the command.
To change a setting, type the command and the new value/parameter. Simple enough (should have read it in the manuals mentioned above). You can recheck the setting by typing the command again, without the parameter.
Since I have 2 xbee modules on 2 serial interfaces, with 2 terminal windows setup and running, I just configure one module, switch to the other window and configure the other module. They are both accessible, and available. This convenience was the whole reason mentioned previously…
The minimum configuration:
I used the xbee module on the ftdi shield as the receiving / local. The xbee module on the older ftdi module, with LM317 regulator module and wire pin adapter is used as the transmitting / sender / pin (analog or digital) input. I simply addressed the xbee modules according to the com port that the ftdi modules were configured on the pc (shield ftdi as rx/local = 2; old ftdi as tx/rmt=4).
(Remember get into the command mode 1st, then type in the commands. Each command will respond with ‘OK’ if accepted.)
At minimum to get it working, on the local/rx module (in one terminal window), type in the following commands:
ATMY 2<cr> (sets modules’ address to ’2′)
ATDL 4<cr> (sets to communicate with module set to ’4′)
ATCN<cr> (exits command mode, or just let it time out)
(Get into command mode 1st, then type in the commands. Each command will respond with ‘OK’ if accepted.)
At minimum to get the remote/tx module working (in the other terminal window), type in the following commands:
ATMY 4<cr> (sets modules’ address to ’4′)
ATDL 2<cr> (sets to communicate with module set to ’2′)
ATD0 3<cr> (set to use a0/d0 pin as digital input) (0= disabled; 2= analog in; 3= digital in)
ATIR 400<cr> (0×400 [~1 sec]; 0×800 [~2 sec]; 0×1400 [~5 sec]; can go to 0xffff)
ATCN<cr> (exits command mode, or just let it time out)
As soon as the remote is configured per above, and the module exits the command mode, the delay timer starts. When the timer lapses (per above configuration), you should receive the api frame on the local module terminal window. It will look like garbage in normal text window of terminal program. It’s raw binary data, that needs to be decoded/interpreted… This is where my little program comes handy, that I wrote for myself, to learn about all of this…
By the way, congratulations, tworks
Tworks, change it to not work:
On the remote, by default, it has pull-up resistors enabled. In this example, if you short the a0/d0 line to ground, it will change status. You can see this even in the raw data, if the terminal program displays the ascii characters, instead of just blocks. Also, if you cover up either of the modules with your hand or other body parts, you will see the rssi value change too (different ascii characters). Anytime you feel like adding more or removing channels, changing channels’ function (disabled/analog/digital), or timing between data updates, just enter the command mode, change the parameter, and exit the command mode. The module will function as reconfigured. You screw something up, close terminal port (don’t need to exit program altogether), power cycle the module (in my case unplug/plug back in the usb cable), reopen the terminal port and reissue the commands above.
Here are some more fun commands. Just remember to prefix each with an ‘AT’, per mentioned documentation. Of course, you can view all of these settings in the x-ctu software too.
sh/sl factory serial
ch channel 0x0b – 0x1a
id pan id 0 – 0xffff
cn exit at mode immediately
db receive strength signal (last received)
(wr write into eeprom)
ni sets string identifier
nd node discovery (can look for ‘ni’ match to get response from desired string matching module only)
(returned data consists of info that is from the other modules that reply to it, in this order/format: )
it num of samples before xmit (related to ir, for timing)
pr pull up res on i/o >ff
vr firmware ver >10ec
vl verbose ver
hv hardware ver > 1745
ed energy scan (12 ch’s ?) (set sc to ffff to get 16 values)
sc scan chans >1ffe (pro’s default) (set to ffff, ed returns 16 values)
sd scan duration
Using the app to see the streaming values:
Once the above configuration is setup, the raw data will be streaming out of the receiving (local) xbee module, in the terminal window of choice. I made me a small application in vb2008express, to help me see what is going on, for later development. The application decodes the api stream, and provides the status on the enabled inputs, mode that they are configured as, and the value that is present on that input on the transmitting (remote) xbee module. It also spits out some more of the api packet data, for your viewing pleasure.
Simply start the application, change the value for a valid com port of the receiving (local) xbee module, and click on the open button. When the next data packet comes in, the program will display it, and the decode it if thinks is valid… (The program is not fool-proof, may/definitely contain bugs, but it works for a demonstration… no guarantees, promises, warranties, or anything else, so don’t bother complaining.)
I might write up more later on decoding the api frame for the remote input. For now, there is enough information in the above links to get you going. If you are this far along, and it worked, you shouldn’t have that much of a hard time figuring it out.
And the application: xbee api stream parse (v4) (410)