Xbee configuration problems

First of all thanks in advance for any help you can give me...


I am currently using a Xbee PRO S2 module (XBP24-Z7WIT) to sample a analog input and send it to the embedded computer which has a telegesis ETRXUSB3 with ember EZSP firmware.

In order to do this I configurated the Xbee as a end-device with extended sleep mode so it sleeps for 1 min and wakes up takes a sample and send is to the coordinator.

The problem is if I take the Xbee off the range of the coordinator for a period superior to 10 min and put it back on range it sometimes rejoins the network and sometimes it does not.

I have the NJ poarameter with a value less then FF (DE) so it tries to rejoin instead of joining a network with permit join

As I read in the NJ parameter with a value less then FF it should try to rejoin and if it fails it clear its PAN and waits for a a permit join.
One of my question is how many tries does it do before clear its PAN? How much time does it take for it to loose its PAN?
Is there a way to configure it to never clear its pan and only try to rejoin the same?


Thanks for your help...

Here is a m,ore detailed description of the problem:

The System is composed by a coordinator (embedded computer with linux) with a ETRXUSB3 Telegesis module with ember EZSP firmware, and a xbee end device that takes samples from time to time of one of its analog inputs and sends them to the coordinator. The system can also have Netvox smart plugs that can act as zigbee routers.

What we need is to configure a Xbee Pro S2 XBP24-Z7WIT so that it has a cycle as defined below:
- Sleeps for 1 minute
- Wakes up for 3 seconds (this value can be change if necessary we had it with 10 seconds but it did not resolve the problem)
- Takes a sample of the AD1 and send it to coordinator
- Goes to sleep again

The configuration that we are using is as follow (also in attachment):

- XBee Model: XBee PRO S2
- XBee Firmware version:28A7
- XBee Configuration:
- Extended PAN ID (ID):0
- So the End-Device will join any extended PAN ID
- Scan Channels (SC):3FFF
- So the XBee can scan all available channels
- Scan Duration (SD): 3
- Approximately 1,843 seconds
- ZigBee Stack Profile (ZS): 2
- So it is possible for the XBee Device to communicate with the ZigBee-PRO Network that we are using
- Node Join Time (NJ): DE
- Regarding the XBee manual, NJ must be less that 0xFF to be able for the end-device to rejoin
- Join Notification (JN): 0
- It is disable
- Destination Address High (DH): 0
- Not defined
- Destination Address Low (DL): 0
- Not defined
- Maximum Unicast Hops (NH): 1E
- This is the default unicast timeout of 1.6 seconds (NH=0x1E) which is enough time for data and the acknowledgment to traverse about 8 hops.
- Broadcast Hops (BH): 0
- This value allows us to use the maximum number of hops
- Device Type Identifier (DD): 30000
- This is the default value because none of the values of Digi corresponds to our ZigBee Product
- Node Discovery Timeout (NT): 3C
- 6000 ms of timeout
- Network Discovery Options (NO): 0
- This is the default value
- Source Endpoint (SE): A
- Destination Endpoint (DE): 1
- Cluster Identifier (CI): 403
- Power Mode (PM): 0
- Boost mode disabled
- Encryption Enable (EE): 1
- Encryption enabled
- Encryption Options (EO): 1
- To send the security key unsecured over the air during joins
- Link Key (KY): 5A6967426565416C6C69616E63653039
- Interface Data Rate (BD): 3
- 9,600 kbs
- Serial Parity (NB): 0
- No parity
- Stop Bits (SB): 0
- 1 stop bit
- Packetization Timeout (RO): 3
- 3 character time
- DIO7 Configuration (D7): 1
- CTS flow control on the DIO7 line of the RF module
- DIO6 Configuration (D6): 0
- Disabled
- Command Mode Timeout (CT): 64
- 10000 ms of command mode
- Guard Times (GT): 3E8
- 1000 ms period of silence
- Command Sequence Character (CC): 2B
- ’+’ ASCII
- Sleep Mode (SM): 4
- Cyclic sleep enabled
- Time Before Sleep (ST): BB8
- 3000 ms
- Sleep Period (SP): AF0
- 28000 ms
- Number of Sleep Periods (SN): 2
- 2 sleep periods
- Sleep Options (SO): 02
- Always wake for ST time
- Polling Rate (PO): 0
- Enables polling at 100 ms (default rate)
- AD0/DIO0 Configuration (D0): 1
- Commissioning button enabled
- AD1/DIO1 Configuration (D1): 2
- Analog input, single-ended
- AD2/DIO2 Configuration (D2): 0
- Disabled
- AD3/DIO3 Configuration (D3): 0
- Disabled
- DIO4 Configuration (D4): 0
- Disabled
- DIO5 Configuration (D5): 1
- Associated indication LED
- PWM0 Configuration (P0): 0
- Disabled
- DIO11 Configuration (P1): 0
- Unmonitored digital input
- DIO12 Configuration (P2): 0
- Unmonitored digital input
- Pull-up Resistor (PR): 0
- DIO4 (Pin 11)
- Assoc LED Blink Time (LT): 0
- 250 ms (default value)
- RSSI PWM Timer (RP): 28
- 4000ms (default value)
- IO Sample Rate (IR): FFFF
- 65535 ms
- IO Digital Change Detection (IC): 0
- DIO0
- Voltage Supply Monitoring (V+): 0
- Default value

The problem is that with this configuration when the end device fails to communicate with its parent (because it is was out of range or the coordinator is turned of for a period of time) sometimes it does not rejoin the network.

One example of this problem is that we configured 2 xbee devices with the same configuration, turned off the coordinator for a period of 4 hours and when we turned on the coordinator only one of the two devices rejoined the network. the other one did not rejoin the network even with a permit join from the coordinator. Another example is that we had a xbee device working and it stopped communicating with the coordinator we did a permit join and he rejoined the network.

The final example is that we had a working xbee and it stop communicating we did a permit join on the coordinator (the same procedure as before) and it did not work (the device did not join), we then did a power (turned off and the turned on the power) reset and it did not join the network (even with a permit join) then finally we toke off the module form the socket and put it back in (with power turned on) did a permit join and the device joined the network.

This behavior it is making us confused, is there something that we are missing? Can or must we do to resolve this problem?
Some questions that can be related with the problem:

- How much time does it take for a module to give up on rejoining and tries to join by association?
- Is there a way to make it so that it never tries to join by association?
- Is there a way so that it never leaves the PAN that it was associated with? Unless using AT commands or the press of a button.