Joining PAN

XBee & XBee Gateway XBee - Zigbee
1

In my application, I need to be able to associate devices to their controller. The devices use API Routers and the controllers use API coordinators. To always make sure the right device connects to the right controller, each coordinator is given a fixed PAN withing a known range. When the devices are first powered up, they don’t know which controller they belong to, and so they attempt to join each PAN in the range until they find a controller that a) exists and b) accepts them. In theory, this should be fairly simple. In practice, it has been quite a pain.

Originally, we ran an unencrypted network. The devices determined if they had joined a PAN by waiting for the Modem Status message after joining. If the Modem Status was 0x02, the device was joined. This never quite worked well, because quite often, the device would attempt to join the PAN, but the Modem Status would never come in. This became worse when we enabled encryption.

So, rather than look for the Modem Status message, I decided to be a bit more direct and use the AI command to read out the Association Indicator. This is where things get interesting.

Let’s say I have one coordinator and three devices. The coordinator is on PAN 0x1234, The first device attempts to join 0x1234 and succeeds (the AI command eventually returns 0x00). The next device now attempts to join 0x1234. While polling the AI command looking for joined, first I’ll see 0xFF (Scanning), but then I’ll see 0xAC (Secure join error - network security key received unsecured). A little later, I’ll receive 0x22 (Scan found no valid PANs based on SC and ID settings). A little later, 0xAC again, then 0x22. Eventually I’ll timeout and move on to the next PAN in the range. But, the device that was joined continues to operate normally. This means that it was able to join properly, but the next device was not. Eventually (sometimes hours later) the device will actually join.

My NJ option is set to always allow joins.

What could cause the 0xAC error? Why would one device connect and not another? Why will the same device eventually connect? Has anyone else seen this kind of thing, or do most people use automatic PAN selection or push button association techniques?

Any help would be appreciated.

Jeff.

2

Some further observations.

It seems that if the router is powered off and back on, it will then connect once. If for any reason it leaves that PAN, when it tries to reconnect, it gets the unsecured key error every time it tries to reconnect. It’s as if there was something leftover in the module from the first connection, and power cycling clears that.

Also, if the coordinator is issued the NR=1 command to reset the network, all of the currently connected devices reconnect, and the devices that were not able to connect before are now able to connect.

Because our devices can be moved from one network to another, they can’t just pick one PAN and stay with it forever, they need to be able to scan to find an appropriate PAN. I can’t do a complete reset of the module beforehand, because that would involve resending the key which could be snooped on the serial line. I don’t think it is a good idea to have the devices issue the NR=1 command, because one device having trouble shouldn’t cause the whole network to reset.

3

What version of the DigiMesh firmware are you using?

4

Coordinators are 2164. Routers are mostly 2341. They were soldered on the boards before they could be upgraded to 2364.

5

I wonder if this in the release notes is at play:

"12. Joining problem fixed where a trust center could not allow devices to join more than 1 hop away. "

6

That does sound like it might be related. Perhaps you can run a few wires from a dev board over to your circuit so you could update the firmware to 2364 that way, or maybe over-the-air from your Coordinator via XCTU ver. 5141.

Keep in mind, over-the-air upgrade only works from an API interface, but since you listed your Coordinator version as 2164 you should be all set. I think that’s the only way you’ll find out if this is the issue or not. I’m suspecting it is.

Also, I moved your thread to the correct forum based on your firmware version (ZB correct, DM 24 incorrect).

7

I built a few new boards with 2364 and the first one looked like it was working better for a while. It connected properly three or four times in a row, but didn’t connect properly after that. I’m still investigating why.

I have 5141 X-CTU and it wouldn’t update that firmware over the air. From scanning the release notes, I got the impression 2341 doesn’t support that. I know I tried it, and it didn’t work. I did see 82001817_D.zip on the support site, but I have no idea what to do with it or if I need it at all.

Also, installing X-CTU on a new PC showed me yesterday that there is a 2x70 firmware out that I didn’t know about. Should I update to this?

8

Hi my name is Jorge, i’m looking for the firmware of xbee pro series 2, thanks for your help

9

Can you send me a link for download the firmware for XBEE pro series 2. Thank you

10

http://www.digi.com/support/productdetl.jsp?pid=3430&osvid=0&s=365&tp=1

11

and the X-CTU for an application on a microcontroller.

12

thank you¡¡¡

13

I have a problem with the instalation of the Xbee pro series 2, this device couldn’t be install and it isn’t posible to find a driver from the page of digi, these page says

General Drivers are not applicable to this product.

i don’t know what to do

somebody could tell me how to install this device

14

Could you please start a new thread? These questions are not relevant to the thread topic.