next topic »

[Reply #30 on:]

Nick, do you think a glitch like that might be power-supply related? I've only used the low-power modules, but a friend has some Pros and I know he ran into some sort of power issue that was fixed with an external supply. I forget the specifics, I'll check back with him.

I couldn't resist trying to duplicate the problem with my low power S2 modules, but failed miserably, which is to say everything worked fine. I used a modified version of the "client" and "server" sketches posted previously.

I am a hands-on type, and another obvious thing that I didn't realize until I put the hardware together, is that when the "server" sketch prints the received characters, the XBee is of course sending them back to the "client" unit. I was fiddling with two-way communication and got a pretty nasty echo loop going which is what made that light come on for me. So @falven, one more thing to try, yank the jumper from the JP3 header on the "server" shield, to prevent that XBee from echoing back what it receives. Not sure why that would make a difference for you when it's not an issue for me, but what with different shields, S1 vs. S2 and all, might as well try it, it's simple enough.

Here are links to a screen shot and a pic of my hardware setup.
http://img546.imageshack.us/img546/9849/screengx.jpg
http://img4.imageshack.us/img4/4834/hardwareb.jpg

[Reply #31 on:]

Hard to say without more diagnostics. After all, in the case of my robot car, something that should have worked perfectly in theory was just showing very low voltages on the oscilloscope. Hence I had to add a buffer chip. So sometimes just hearing a description of the problem doesn't help.

However a solitary 0 (as I surmise is happening) could be caused by attempting to read from the serial port before things have stabilized (eg. one part has "come online" before another). I think a short delay, before opening the serial port, might help.

[Reply #32 on:]

Hard to say without more diagnostics. After all, in the case of my robot car, something that should have worked perfectly in theory was just showing very low voltages on the oscilloscope. Hence I had to add a buffer chip. So sometimes just hearing a description of the problem doesn't help.

However a solitary 0 (as I surmise is happening) could be caused by attempting to read from the serial port before things have stabilized (eg. one part has "come online" before another). I think a short delay, before opening the serial port, might help.

Nice catch! Adding a simple delay(500) right before opening the serial port did the trick! I now get garbage-free data!



Thanks for all the help Jack and Nick, and sorry you had to pull out all the equipment right before we solved the issue
This was a great learning experience. You can really count on this community for help. Hopefully, in the future, I can provide someone else with the same dedication you guys gave my problem.

Just for third-party reference the two problems I was having were:
1. The garbage byte ð or y the after you initiate serial.
    a. to fix this you add a small delay(500) before you initiate serial (Serial.begin(x)).
2. Incorrect/improper baud rates
    b. Fixed this by changing the baud rate of the XBees in a terminal client ATBD1B207 and also changing it in the arduino sketch (111,111). Serial port still reads it fine at (115,200).

Cheers,
-Francisco

[Reply #33 on:]

Glad that it's working. It's still a mystery to me why taking those steps was necessary.

[Reply #34 on:]

Glad that it's working. It's still a mystery to me why taking those steps was necessary.

I agree on the first one, why does 111,111 baud work but not 115,200? That doesn't make any sense considering, like you said that both the arduinos and the XBees use crystal oscillators.
The second one makes sense though, need the delay before serial.begin because the arduino needs a power up cooldown time.

[Reply #35 on:]

The second one makes sense though, need the delay before serial.begin because the arduino needs a power up cooldown time.

Hmmm, not sure what that means, exactly. And strange I haven't noticed it. A 500ms delay does the trick. I'd wonder how short I could make it and still have it work.

[Reply #36 on:]

The second one makes sense though, need the delay before serial.begin because the arduino needs a power up cooldown time.

Hmmm, not sure what that means, exactly. And strange I haven't noticed it. A 500ms delay does the trick. I'd wonder how short I could make it and still have it work.

I tried 1ms and it works. That's the lowest I can go...

[Reply #37 on:]

Really! Interesting! Maybe if you sneak up on it you can take it out, haha! But then there is delayMicroseconds() ...

[Reply #38 on:]

Really! Interesting! Maybe if you sneak up on it you can take it out, haha! But then there is delayMicroseconds() ...

Interesting... Brought it down to 100 microseconds and this was the output.



Edit 1: Up to 750 now, still garbled data.

Edit 2: This really blew my mind... 1000



Edit 3: Seems like 1ms was not the ideal amount, but i'm getting a lot les garbling than when  I did 1000 microseconds...



Keep in mind this is writing from cold boot. Every one of those "Hello's" is me hitting the reset button on the Arduino. It resets and writes "Hello" once.

[Reply #39 on:]

Just so I'm clear, in the screen shots in the last post, COM3 is the receiving XBee and COM4 is sending?

[Reply #40 on:]

Keep in mind this is writing from cold boot. Every one of those "Hello's" is me hitting the reset button on the Arduino. It resets and writes "Hello" once.

That may be making the situation seem worse than it is. An async serial stream will need a few bits for the receiver to get in sync so this may be introducing additional errors into your test. It might be a more representative test to keep the sender running and send your test message at regular intervals.