A overview of xbee series2
Series 2 are good for:
- Advanced networking
- Longer distance networking
- Energy saving “end” devices and meshes that need to self “heal”
- Also it supports endpoint function:
An endpoint is a distinct task or application that runs on a ZigBee device, similar to a TCP port. Each ZigBee device may support one or more endpoints. Cluster IDs define a particular function or action on a device.
Downsides are: Slower transmission rates and you have to configure the firmware, as of right now (2008) the firmware is not tested thoroughly and buggy.
With the Series 2 the network consists of one coordinator per PAN ID, routers (that join to the coordinator and each other) and end devices who can't pass messages but can go into energy saving modes.
If coordinator is powered off then back on with a different address on the same channel, the routers stay together on the old address till they get a network reset or power up then down.
SO: If the coordinator might get powered on then off you should hard code the channel so it re-associates in the right network. The coordinator takes charge of setting the addresses,
SO: To send in API mode you have to do a network poll to see who's there before broadcasting or you could use the hard coded 64 bit address.
Xbee is a wireless RF transmitting device built which supports a self checking network protocol ZIGBEE: it transmits on these frequencies:
•868-868.8 MHz: Europe, allows one communication channel (2003), extended to three (2006). •902-928 MHz: North America, up to ten channels (2003), extended to thirty (2006). •2400-2483.5 MHz: worldwide use, up to sixteen channels (2003, 2006).
The data out is transmitted Serially from the uart using 8-N-1 formating (start bit, eight data bits (least significant first) and a stop bit)
SO: the communication/terminal should be set with:
- 9600 baud rate
- No parity
- 8 Data Bits
- 1 Stop Bit
(for Z-term press shift to select port, to exit Screen control-'A', then control-'\')
Series 2 Addressing: Each Xbee communicates on a channel and within a specified PAN ID group, to access this use:
"ATID"(to retrieve number) "ATID" (HEX NUM)(to set PAN ID as (HEX NUM)) use FFFF as HEX NUM input to enter broadcast mode
Each xbee radio comes with a unique hard coded 64 bit address that is on the bottom cover it can be accessed by the AT command:
"ATSH"(to get the high bits) "ATSL"(to get the low bits)
There is also a personal 16 bit address (as ASCII) that you can identify your xbees series2 with:
"ATNI"(to retrieve number) (NODE IDENTIFIER) "ATNI"(ASCII string)(to set NI as (ASCII string)) *overrides the MY address*
to see who's in your network:
"ATND"(returns all devices in your PAN ID)
to set who your sending to use:
"ATDN"(ASCII name)sends to that node (if two with same name sends to first born)
Command modes: The two command modes AT and API address how the information comes out the xbees Uart. It is the protocol in which the xbee communicates with the user. The data packet transfer between xbees always occurs in the same format no matter what command mode it is in.
AT command mode Examples:
Getting the destination address and Setting it. (from manual) Method 1 (One line per command)
Basic op commands:
"ATWR" (writes to firmware) "ATRE" (restores firmware setting) "ATFR" (powers off then on hard reset) "ATGT" (sets the amount of time before exiting command mode) "ATCN" (used to get out of command mode)
Polling XBEE pins remotely without a micro-controller:
- (currently virtual wires functions are not working with the series 2 but you can still poll them and get the pin state out serially)
- pins can only measure up to 1.7 volts
With the series 2 xbees you can remotely poll pins after setting them using the
VEREF PIN->used for analog voltage
Pin 14 is the voltage reference for the analog channels, if your not using the same voltage that is suppling the xbee with power you need to enable this and hook it in to your channel.
"ATAV 0" (to enable VREF pin) 1 (to use internal ref)
"ATDO3"(sets digital pin 20 as a digital in)
+++(enter command mode) "ATIS"(poll channels)
AT command mode returns a list of numbers (in ASCII) separated by <returns> '\n' the list is composed of the following:
- (BYTE 1) number of samples (in packet) <return>
- (BYTEs 2) (Digital channel mask of) all digital pins reported on as list <return>
- (BYTE 1) (analog channel mask of) all analog pins reported on as list <return>
- (BYTEs 2) if digital pins are on, two bytes are given with the corresponding bits on or off to represent the pin state
- (Bytes n) Two bytes are given for each analog channel that gives their voltage.
To convert the A/D reading to mV, do the following:
AD(mV)= (ADIO reading/0x3FF)*1200mV
Bit masks hold channel information in a series of bits so a mask of:
would yield the channels 0,2,4 as on or active.
would yield 0,1,2,5 ect.
Sleep Modes enable the RF module to enter states of low-power consumption when not in use. In order to enter Sleep Mode, one of the following conditions must be met (in addition to the module having a non-zero SM parameter value):
(SM = 1) (sleeps according to state of pin 9)
- Typical power-down current: < 10 μA (@3.0 VCC)
- Wake-up time: 13.2 msec
Pin Hibernate Mode minimizes quiescent power (power consumed when in a state of rest or inactivity). This mode is voltage level-activated; when Sleep_RQ is asserted, the module will finish any transmit, receive or association activities, enter Idle Mode and then enter a state of sleep. The module will not respond to either serial or RF activity while in pin sleep. To wake a sleeping module operating in Pin Hibernate Mode, de-assert Sleep_RQ (pin 9). The module will wake when Sleep_RQ is de-asserted and is ready to transmit or receive when the CTS line is low. When waking the module, the pin must be de-asserted at least two 'byte times' after CTS goes low. This assures that there is time for the data to enter the DI buffer.
(SM = 2) (same, power diff)
- Typical power-down current: < 50 μA
- Wake-up time: 2 msec
Pin Doze Mode functions as does Pin Hibernate Mode; however, Pin Doze features faster wake-up time and higher power consumption.
To wake a sleeping module operating in Pin Doze Mode, de-assert Sleep_RQ (pin 9). The module will wake when Sleep_RQ is de-asserted and is ready to transmit or receive when the CTS line is low. When waking the module, the pin must be de-asserted at least two 'byte times' after CTS goes low. This assures that there is time for the data to enter the DI buffer.
Cyclic Sleep Modes:
Cyclic Sleep Remote:
- (SM = 4) (self wake with timer)
- Typical Power-down Current: < 50 μA (when asleep)
- Wake-up time: 2 msec
The Cyclic Sleep Modes allow modules to periodically check for RF data. When the SM parameter is set to ‘4’, the module is configured to sleep, then wakes once a cycle to check for data from a module configured as a Cyclic Sleep Coordinator (SM = 0, CE = 1). The Cyclic Sleep Remote sends a poll request to the coordinator at a specific interval set by the SP (Cyclic Sleep Period) parameter. The coordinator will transmit any queued data addressed to that specific remote upon receiving the poll request.
If no data is queued for the remote, the coordinator will not transmit and the remote will return to sleep for another cycle. If queued data is transmitted back to the remote, it will stay awake to allow for back and forth communication until the ST (Time before Sleep) timer expires. Also note that CTS will go low each time the remote wakes, allowing for communication initiated by the remote host if desired.
Cyclic Sleep Remote with Pin Wake-up:
(SM = 5) (self wake with timer and pin 9)
Use this mode to wake a sleeping remote module through either the RF interface or by the de-assertion of Sleep_RQ for event-driven communications. The cyclic sleep mode works as described above (Cyclic Sleep Remote) with the addition of a pin-controlled wake-up at the remote module. The Sleep_RQ pin is edge-triggered, not level-triggered. The module will wake when a low is detected then set CTS low as soon as it is ready to transmit or receive.
Any activity will reset the ST (Time before Sleep) timer so the module will go back to sleep only after there is no activity for the duration of the timer. Once the module wakes (pin-controlled), further pin activity is ignored. The module transitions back into sleep according to the ST time regardless of the state of the pin.
[Cyclic Sleep Coordinator (SM = 6)]
- Typical current = Receive current
- Always awake
(API mode allows for the sending of command WITHOUT entering command mode.) This is great to send to multiple sources or to send out varying AT commands (like polling pins, or setting a micro-controller reset).It is a bit time consuming in the beginning but once you have the code down it works well.
Entering API MODE:
- AP = 0 (default): Transparent Operation (UART Serial line replacement)
API modes are disabled.
- AP = 1: API Operation
- AP = 2: API Operation (with escaped characters)
the DATA frame:
- BYTE 1 :Ox7E (is the start byte signals start) (1 Byte)
- BYTEs 2-3 :length (of packet as a 16 bit (2 bytes) number) (2 Bytes)
- BYTEs 4-n : API identifier ( tells what kind of packet) + info (n BYTES) (1 BYTE)+ (n BYTEs)
- BYTE n+1 : checksum (1 Byte)+ (n BYTEs)
API identifier gives what kind of packet it is, use it to identify how to parse the rest of the packet.
To test data integrity, a checksum is calculated and verified on non-escaped data.
Not including frame delimiters and length, add all bytes keeping only the lowest 8 bits of the result and subtract from 0xFF.
Add all bytes (include checksum, but not the delimiter and length). If the checksum is correct, the sum will equal 0xFF.
to calculate checksum (since you only need the last Byte of the number) you can do:
byte checksum = OxFF
Then add each byte that you send to checksum, it will automatically truncate. Reverse for decoding.
FRAME ID: (used for the reply status message of a transmit request)
Identifies the UART data frame for the host to correlate with a subsequent ACK (acknowledgment).
Setting Frame ID to ‘0' will disable response frame.
When you send a transmit packet the xbee sends back the status of that request (weather it was successfully sent or not) you have to “tag” it with a frame id so you know which request made it or not. its good to increment the FRAME ID requests you make so you can keep track of them. setting zero will prompt no status message to be sent.