Multi Xbees with CD (Change Detect on IO lines) missing Data

Martin_Wade

I have setup 2 Xbees (plan more later) to monitor Data I/O lines (set to input) and using the Change Detect parameter. They each have a different short My address and are set to a DL of 1 which is my 3rd (master) Xbee. This Xbee is attached to my propeller so that it can watch for API frames with DIO type. In order to test I use the propeller pins to actually cause the changes on the Remote Xbee input pins. If I change 1 pin at a time all is well and I can read the correct IO pin and the correct Orignation address. But if I change 1 pin on both Xbees at the same time one wins and I do not recieve the other ones API frame. I thought maybe I was losing this in the serial reciever so I increased the Rx Buffer and added a routine to monitor the buffer size in use. I am staying way inside the new buffer and can tell that when the collision occurs one frame does not reach the buffer at all. So to me that would indicate that i am getting the collision in the wireless portion and the master is never recieving the 2nd Xbee's API frame. Any thoughts on this. I believe I should be focusing on the following but have not found the right combination yet. I am running API mode on all of them.
RR = retries
RN = CSMA CA backoff component
CA = Detection Level (should I go lower on this number)
Thanks for any help

johnfos

That's puzzling, because it should Just Work, without any need to change RR and its chums.

I can't see what's wrong from the information you give, but if you can post the settings of all three XBees that may help. The way to do that would be to use X-CTU to save the settings in .PRO files, and then attach the three files to a post, eg host.pro, remote1.pro, remote2.pro.

I'm assuming you're using the series 1 XBees, BTW.

Martin_Wade

In order to troubleshoot I rewrote my routine to Poll the remote devices instead of relying on the Change Detect within the Xbee. This seemed to work just fine. Althought this does not resolve my original issue I realized this was a more robust method for my project. I recognized that any lost change detect would be an error in my design system and I really had a zero tollerance for this sensing error. By design it was critical that I not miss a change. The fact that any number of errors could cause a collision, lost RF packet, or lost RS232 packet it became evident that this would be a poor design. So rather than spend any more time on this I just moved over to the poll routine where if I did miss a sense it would catch it on the next poll. As in your comment it should have worked and I may come back to this for another design project but for now I am going to mark it resolved from the work around.
Thanks for your quick response and offer to help.


It's probably right in front of me, but for the life of me, I can't figure out how to turn off the "X Unsolved" heading. If a moderator can change this and let me know for the future that would be great.