I’m using two xbee pro S2Bs…I’ve set one as the coordinator and the other as the router. I know for a fact that the network works because data does get transmitted across the link properly. However, I find that the coordinator takes some time to lock to the router and this time is rather unreliable. I’m planning to use the xbee to send an ignition signal to an amateur rocket, so I need a degree of reliability from it. The way this works is that I press a button which causes a character (say ‘F’) to be written on to the serial port which is then received by the router and upon receiving ‘F’, it tells the arduino to send the ignition signal. I’ve tried a bunch of things but can’t seem to fix the problem.
Does anyone have any idea about what might be wrong?
Yes, due to the network type link between the XBees it does take some time to have the link firmly established.
For your application I would ensure that this ‘connect’ time is allowed for before trying to send the ‘fire’ command.
Work that into the count down sequence and have the connect done minutes before going to the final count-down. Also, use a ‘link confirmed’ command and response to verify the XBee’s connection before continuing the count-down.
Thanks for your response…I understand what you’re saying and I’m already taking those precautions- as far as a link confirmation sequence is concerned…my bigger concern is that I’ve noticed that the time to set up the link is nowhere near uniform…so I have no idea how long I have to wait to see whether the link is set or not.
That is correct. The XBees do a lot of work to establish a link. One thing they do is scan for an open RF channel. This can take different amounts of time due to possible interference from WiFi and other RF sources.
Two things to read:
1- General info on 802.15.4 protocols and in particular link establishment. (google and Wiki has info).
2- The XBee document. There is a status that tells what XBee Nodes have connected. Your host code (connected to the coordinator) can query this to find out if/when the remote node has connected.
For your count-down sequence, just allow much longer than might be necessary to establish the link. That could be a ‘build-in hold’ of the count down just like NASA does.
Above, the talk is XBee series 2 (S2). Conversely, the S1’s are far simpler as they don’t use ZigBee and use of a PAN Coordinator is optional. For most simple applications (point to point pairs or star topology, or static mesh), S1s are a great simplification.
I’ve also seen something else that strikes me as strange…I try and send a test sequence out to light some LEDs to indicate lock, and I find that when I send a sequence that’s 4 bytes long - 1234, that seems to be rather unreliable…however, within the scope of my testing, when I send something that’s 9 bytes long - 123456789, I get 124689 at the receiving end, every time. Now, I can get this to work, I think, but I still don’t understand why this is happening.
Steve, yes I’m considering switching to S1’s, but it seems like such a waste to not use the ones I already have.
Slightly mis-matched Baud rates could cause this issue. One possible fix is to use two Stop bits on the TX UART. This allows the XBee RX is re-sync to the next Start bit. Give this a try to see if the dropped characters get fixed.
I think the router was on 22A0 and the coordinator was on 20A0…It’s the latest firmware as far as I know…I updated the firmware before putting it in…
I sent them as ASCII…
Well, so the 124689 problem itself was so repeatable that the whole testing for lock thing could have just been done with that…I was really looking to eliminate this all together, and who’s to say that there isn’t something else that may not be right…but hey, it works well for now is all I can say…thanks for your time!
for fire control… you need to have error detection in your commands.
You can enable 7 bits on parity bit to get simple single-bit error detection.
But better is to either use a CRC or checksum of a multi-byte command, or dumb down and send the same one or two byte command 3 times and the receiving end validates that all are the same, and if not, blink a light, beep, or just do nothing.