exceeding the 100 byte limit

Sounds like the diode and 47k resistor essentially drop the voltage by about 1v and the current by quite a bit while eliminating a reverse voltage. Sparkfun added a little headroom insurance there! Very cool.

These XBees seem quite finicky to me – at least at the 57600 bps rate I’m trying to use. They may be more stable at lower speeds, and the XCTU loopback range tests between two radios always seems to work fine even at 57600 with no ACK in the MAC setting (MM=1). It’s puzzling that when the radios get a little out of their element or away from the factory software that they cough and gag something fierce. During loopback tests, XCTU still says “57600, 8N1 and no flow control” but it’s hard to fathom how the same setting doesn’t work with an external streaming app at the same speed. It leads me to believe that XCTU is doing something behind the scenes and the Digi folks aren’t telling.

I’m obviously missing something here, but I sure don’t know what. Sheeeeesh!!!

There could be a baud rate issue here. You mentioned in an earlier post that the Renard system uses PIC controllers. I just did a bit of googling for Renard, and it seems the PICs are clocked at 18.432MHz.

The baud rate is normally derived by dividing the system clock by a fixed factor of 16 and then by a further variable factor - the latter being adjusted to get the rate right. With a 16MHz clock such as the XBee has, and to get 57600 baud, the nearest (integer) value for the variable factor is 17, leading to an actual rate of 58823.5 baud. A PC serial port will give a true 57600 rate, so when the XBee is connected to a PC the discrepancy is about 2%. That’s generally good enough for reliable operation. If I’m right about the 18.432MHz for the PICs, their variable divider would be 20 to give exactly 57600 baud.

So in theory the PICs are giving exactly the same rate as a PC would, and so things should work just as well. What I’m wondering is whether increased noise levels “away from the factory” are enough to make the 2% discrepancy significant.

Since the XBee is running faster than the true rate, you can slow it down a bit by setting the XBee to use two stop bits. (You mentioned two stop bits earlier, but you didn’t say which end they were configured.) To set two stop bits on the XBee, use the NB parameter (ATNB=3) to set mark parity, which amounts to the same thing. But if you’ve already tried this, then I’m temporarily out of ideas.

Well, except that I still think a non-zero setting for RO is a better idea…

Also, does the flow control setting of the XBee match the flow control settings of whatever is plugged into its uart? Anytime I hear about data just “stopping”, I think of flow control mismatch, for that’s the most common reason.

Hi again, my new friends!

I thought I had posted this at one time, but it’s not in the thread, so I thought I’d bring some closure to my problem.

I discovered why the XBee was just “stopping.” It was a voltage problem caused by a defective zener diode. The zener/resistor combination was supposed to limit the input voltage to 3.3v but it was defective and was just letting everything through – so the XBee’s DIN pin was getting the full brunt of 7-12 volts and, well, it kind of gave up the ghost. It was a completely unexpected issue with a brand new component and once the zener was replaced, it settled in nicely and ran without locking up anymore.

It was interesting that the original XBee that was taking the hit seems to be okay. I don’t know if it was damaged internally or not, but it sure seems to be okay. Performs as well as any of the other XBee modules I have, anyway.

The wireless adapter I’ve created works about as well as I could expect it to, given that flow control is not in the cards. I still notice a loss of data, but it ranges in the neighborhood of .014 - .044%, which I can live with. Dropping anywhere from 14 - 44 bytes every 100K is barely noticeable in the displays if the technique uses is “blinky” (on/off or flicker) and only slightly noticeable on a long fade up/down action of 3-5 (or greater) seconds, which appears as a slight flicker during the action instead of a perfectly smooth fade. So all things considered, it’s a workable wireless adapter for the Renard controllers.

I certainly appreciate everyone’s assistance here, as well as the Digi tech support folks, and from the looks of it right now, this is a completed project that requires no more attention. Using a streaming flow of data at 57,600 baud without flow control, I seriously doubt one could ever expect zero data loss.

Message was edited by: dirknerkle