This project has moved. For the latest updates, please go here.

My tests results

Jun 27, 2012 at 12:54 PM

I test the GBee library with XBee modules and I have some problem.

One side I use PC connected to a Digi XBIB card, other side a FEZ Panda II card.

 I use this code to initialize the connection :

using GBee = NETMF.OpenSource.XBee.Api;

private GBee.XBee m_xBeeGB = null;
�
m_xBeeGB = new GBee.XBee("COM1", 9600);  
m_xBeeGB.DataReceived += new GBee.XBee.XBeeDataReceivedEventHandler(On_GBee_DataReceived);
m_xBeeGB.Open();

With XBee serie 1,

XB24, stack 802.15.4, software version 10EC, default parameters

I have this response after open(), depending of the XBee configuration :

AP = 0 : Message « … XBee must be in API mode (AP=2)… »

AP = 1 : No message, all is OK, I can send and receive message.

AP = 2 : Message « … XBee must be in API mode (AP=2)… »

 

With XBee PRO serie 2, stack ZigBee

XBP24-ZB, ZigBee Coordinator API, software version 21A0, default parameters.

XBP24-ZB, ZigBee End Device API, software version 29A0, default parameters.

 I have this response after open():

AP = 0 : Message « … XBee must be in API mode (AP=2)… »

AP = 1 : Message « … XBee must be in API mode (AP=2)… »

AP = 2 : Message « … XBee must be in API mode (AP=2)… »

To solve my problem side End Device, I have used the solution described here http://rapplogic.blogspot.fr/2009/02/xbee-zb-pro-upgrade-pin-sleep-trick.html . I have set SM=1 and fix the XBee pin9 to 0v to disable the sleeping mode. After this the init of the XBee device with AP=2 run very well on Panda II side.

 PC side it's random, sometimes opening the port is well sometimes it was the error message above.

Problem occurs if I try to open the COM port when the XBee is in sleeping state.

Best regards

Christian

Coordinator
Jul 6, 2012 at 11:40 AM
Edited Jul 6, 2012 at 11:42 AM

Hello Christian,

You are correct about the sleep mode. This is something that you need to know before playing with XBee. I think for start you should program your modules with coordinator and router firmware because those never fall into sleep and you are able to communicate with them. also I think we could add something to the driver to indicate the you cant communicate with the module due too sleep mode. But the problem is that we can't communicate with the device so the reason can be sleep mode, wrong COM port, AT instead of API mode etc. We can't distinguish between those reasons before we actualy communicate with the device...