1

Using Andrew Rapp's XBee-API, how can I sample I/O data via a coordinator from more than two endpoints?

I have 17 Series 1 XBees. I have programmed one to be a coordinator (API mode = 2) and the rest to be endpoints. Using XBee-API I am sending a Force I/O Sample ("IS") remote AT command, unicast to each endpoint. This works perfectly well when there are up to two endpoints, but as soon as a third is added, one of the three always becomes non-responsive (times out with XBeeTimeoutException). It's not always the same physical unit that stops responding, but it is always the third one (for example, if I send Force I/O Sample to Device1, Device2, and Device3, Device3 will time out, and if I change the order to Device3, Device1, Device2, Device2 will time out.

If I set up more than three XBees, about 1 out of 3 will time out - but not every third one.

I've verified that the XBees themselves are fine. I've searched the Internet and Stack Overflow in particular to no avail. I've tried using a simple ZNetRemoteAtRequest. I've tried opening and closing the XBee coordinator serial connection once for all three devices, once per device, and once per program run. I've tried varying the distance between the coordinator and endpoints (never more than five feet apart). I've tried different coordinator configuration parameters (from the Digi documentation). I've tried changing out the XBee for the coordinator.

This is the code I'm using to send the Force I/O Sample request to each endpoint and read the response:

xbee = new XBee(); // Coordinator
xbee.open("/dev/ttyUSB0, 115200)); // Happens before any of the endpoints are contacted

... // Loop through known endpoint addresses

XBeeRequest request = new ZBForceSampleRequest(new XBeeAddress64(endpointAddress));
ZNetRemoteAtResponse response = null;
response = (ZNetRemoteAtResponse) xbee.sendSynchronous(request, remoteXBeeTimeout);
if (response.isOk()) {
     // Process response payload
}

... // End loop and finally close coordinator connection

What might help polling I/O samples from more than two endpoints?

EDIT: I found that Andrew Rapp's XBee-API library fakes multithreaded behavior, which causes the synchronization issues described in this question. I wrote a replacement library that is actually multithreaded and correctly maps responses from multiple XBee endpoints: https://github.com/steveperkins/xbee-api-for-java-1-4. When I wrote it Java 1.4 was necessary for use on the BeagleBone, Plug, and Zotac single-board PCs but it's an easy conversion to 1.7+.

spork
  • 1,185
  • 1
  • 11
  • 17

1 Answers1

1

Are you using hardware flow control on your serial port? Is it possible that you're sending requests out when the local XBee has deasserted CTS (e.g., asking you to stop sending)? I assume you're running at 115200 bps, so the XBee serial port can keep up with the network data rate.

Can you turn on debugging information, or connect some port monitoring hardware/software to display the data going over the serial port to the local XBee?

tomlogic
  • 11,489
  • 3
  • 33
  • 59
  • Hardware flow control is being used. The local XBee may have sent the stop character, but it's going through rxtx and then xbee-api before it reaches my code. xbee-api appears to have management for this, but the point of my using the library is to avoid knowing about things like which control bytes are sent at what time - what I'm saying is I know very little at this level. I'm in the process of setting up a test to gather exactly what data is being sent to and returned from the local XBee on each request. I'll update here once I have usable data. Thanks for the suggestion. – spork Mar 13 '13 at 16:03
  • You don't need to worry about start/stop characters in the serial stream -- that would be software flow control. You're right that the libraries should be taking care of all of that. It will be helpful to know if there are additional packets coming from the XBee that aren't making it through the library to your code for some reason. – tomlogic Mar 13 '13 at 17:01
  • I was able to capture the data being sent to the XBee and the XBee's response. Although the information I've read on xbee-api and S1 XBees indicates hardware flow control is used by default, the data reveals a constant start byte is being used. By removing xbee-api and using rxtx directly I found that when a request is sent to the XBee, the serial input appears to interrupt the serial output before it's even done sending - and the response is just a -1 indicating end-of-stream. I'll be continuing to investigate over the weekend. – spork Mar 15 '13 at 17:48
  • Double-check your baud rate and test the XBee with Digi's X-CTU (if you're on Windows). If you're not averse to C, you could try compiling Digi's [Open Source XBee ANSI C Host Library](https://github.com/digidotcom/xbee_ansic_library) to test the serial connection. It works for Win32 (MinGW/MSYS) and POSIX systems. But note that it uses API mode 1. – tomlogic Mar 16 '13 at 00:50
  • 1
    I've double-checked the baud rate - set to 115200 on the XBee and the same when establishing the connection. C's out for me, but I found what I believe is the issue: xbee-api fakes synchronous XBee communication by using thread synchronization. It assumes the remote XBees will respond immediately and when they don't, the inbound messages get garbled. I was able to fix this by ditching xbee-api and writing my own code to send requests to all XBees and allow them to respond in whatever order they wish. I'm marking your answer, because I appreciate the help you've provided in troubleshooting. – spork Mar 28 '13 at 20:12