Xbee unreliable on initial lock

Hi,

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?

Thanks in advance.

Siddharth

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.

Hi,

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.

Strange that characters are dropped. I use S2 XBees and never had a problem with dropped characters running in ‘transparent (AT command) mode’.

What is the Baud rate of the serial link?

Is the Baud rate of the connecting serial device Exact?

A slight mis-match of Baud rates could cause this.

The Baud rate is 9600 on both the Xbees and the arduinos they’re sitting on…

Is the Arduinos 5V?

What are you using as the 5V to 3.3V level shifte from the Arduino TX data to the XBee RX data?

Using the Sainsmart Xbee shields…

http://www.amazon.com/SainSmart-Shield- … bee+shield

Do you have a link to the data sheet and schematic to that shield?

I want to see how they do the 5V to 3.3V level shift.

And the answer to my above question:

"Is the Baud rate of the connecting serial device Exact?

A slight mis-match of Baud rates could cause this."

Unfortunately sainsmart doesn’t have a datasheet for their shield that I can find anywhere…

I have realized though, that this 12469 sequence is so repeatable, that I can actually maybe use this as a lock-testing sequence…

Just another thought.

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.

Will try…

Alright so I ran a bunch of tests…and here are the results:

  1. Two stop bits vs one - no change

  2. Instead of using a for loop, i manually wrote Serial.println(‘1’)…Serial.println(‘9’) and it still wouldn’t print 3,5,7.

  3. I played with the delays, still no change.

  4. I got it to write out 11-20 and all of those got written out just fine.

  5. I changed the coordinator to a router and now it receives all bytes.

Do you think this may have been a firmware problem?

Exactly which firmware version did you have in the XBee when it was a coordinator?

What firmware version did you load?

When you send 1, 2, 3, etc are these raw binary or ASCII characters?

This “Serial.println(‘1’)” look to be an ASCII character ‘1’.

This is all sounding strange?

It could have been a firmware issue. Is everything working as you need it now?

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.