XBEE1

A overview of the Digi series 1 Xbees

XBEE OVERVIEW SERIES 1:

XBEE Series 1

series1pic.jpg

Series 1 are good for:

  • Peer to peer communication,
  • Remote pin data polling and limited mesh networking.
  • The benefits are ease of setup, tested code and no firmware setup so they come ready to go from the box.
NETWORK OVERVIEW:

Xbee is a wireless RF transmitting device which supports a self checking network protocol 802.15.4:

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
  • or”8-N-1”

(for Z-term press shift to select port, to exit Screen control-'A', then control-'\')

Addressing:

Series 1 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 short 16 bit address(in HEX) that you can identify your xbees with:

"ATMY" (to retrieve number)
"ATMY" (HEX NUM) (to set MY as (HEX NUM))

To set who your sending to use:

"ATDH" 0 (set to 0) "destination high part of address" 
(set high part 0 because we don't use it)
"ATDL" (whatever the MY HEX NUM is) "destination Low part of address"

Command Mode AT:

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

Basic commands (Remote pin polling):

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

Here are two function sets i really like:

Polling XBEE pins remotely without a micro-controller (virtual wires):

pins can only measure up to 1.7 volts* You can have pins on one xbee output the input from the pins of another xbee. The individual pins of the first xbee are mapped to the pins of the other xbee and have to be used in pairs. For example, if you want to do a analog read the pairing would be pin 20 (AD0) from the sender which can only be linked with pin 6 (PWM0) on the receiver.

 list of linked pins:

    Send          		Receive
ANALOG: 
     pin 20  (AD0)		pin 6 (PWM0)
     pin 19  (AD1)  		pin 7 (PWM1)
     pin 18  (AD2)		Serial out only
     pin 17  (AD3)   		Serial out only
     pin 11  (AD4)   		Serial out only
     pin 15  (AD5)   		Serial out only
     pin 16  (AD6)   		Serial out only
DIGITAL I/O:
     pin 20  (DIO0)		pin 20  (DIO0)
     pin 19  (DIO1)  		pin 19  (DIO1) 
     pin 18  (DIO2)		pin 18  (DIO2)
     pin 17  (DIO3)   	pin 17  (DIO3) 
     pin 11  (DIO4)		pin 11  (DIO4)
     pin 15  (DIO5) 		pin 15  (DIO5) 
     pin 16  (DIO6)		pin 16  (DIO6)
     pin 12  (DIO7) 		pin 12  (DIO7)  


To set up virtual wires the pins need to be set with the AT command:

{{: xbee:picture-1.gif }}



Example commands for analog reading:
NOTE-VEREF PIN for voltage analog

Pin 14 is the voltage reference for the analog channels, if your not using the same voltage that is supplying 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)
REMOTE (sensors)                       BASE (output to here)    
DL 0x1  (set destination)              DL 0x2  (set destination)  
MY 0x2  (set MY ADDRESS)               MY 0x1  (set MY ADDRESS)    
D0 2  (SET D0 (pin 20) to anal in)     P0 2 (SET P0 (pin 6) to anal out)    
D1 2  (SET D1 (pin 19) to anal in)     P1 2 (SET P1 (pin 7) to anal out)    
IR  0x14 (set sample rate in HEX)      IU 1 (send serial out uart ) 
IT  5 (num of samples before send)     IA 2 (tells who to link/listen to)


*The IA command is important, it tells who to listen/link to.
*You can also do all this in API mode by just framing the data packet.

Here's a list of the rest of the commands for I/O linking:

picture-2.jpg

Sleep mode:

Sleep function: sleeppower.jpg

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

sleepmode.jpg

Pin Hibernate:
  • (SM = 1) (sleeps according to state of pin 9)
  • Pin/Host-controlled
  • 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.

Pin Doze:

(SM = 2) (same, power diff)

  • Pin/Host-controlled
  • 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

Command mode API:

API MODE:

(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: apiframedata.jpg

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

[Checksum] :

To test data integrity, a checksum is calculated and verified on non-escaped data.

To calculate:

Not including frame delimiters and length, add all bytes 
keeping only the lowest 8 bits of the result and subtract 
from 0xFF.

To verify:

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:

variable:

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.

Navigation
Print/export
Toolbox