I have a local terminal and a remote device connected by a pair of Xbee-PRO XSC modules.
When the remote device is streaming bulk data, everything is fine. But when typing interactively to a command shell on the remote device, many characters are dropped.
The remote device buffers outgoing characters and only sends them to the Xbee when the CTS pin is asserted. I can’t really detect any pattern to the dropped characters except it maybe seems to happen after a slight pause in typing. It happens much worse with a cyclic sleep mode enabled, but also happens with both modules in SM0 (no sleep mode.)
Anyway, querying the terminal-end device’s status shows good signal strength (ATRS gives 0x32) and no transmit failures (ATTR gives 0) so I’m not sure what’s going wrong. Any ideas? I’d like to incorporate these into a product but I do need to have the interactive command shell and it’s really not usable with the characters being dropped.
I’ll try to further refine the problem in the next few days…
So, this happens also when using the adapter boards that come with the dev kit. Strict adherence to RTS/CTS flow control doesn’t make any difference. It appears the problem
is that if you send a byte within a short time after receiving one, the one you send just
vanishes. I realize these aren’t full-duplex devices, but it seems it should be possible to
sort of fake it with some sort of arbitration.
Faililng that, it would be useful to know how long I have to wait before sending a “reply” after receiving a character in order to have a decent chance of it being transmitted successfully…
anyone try using these modules with lots of back-and-forth of small packets before?
It sounds to me like a problem with the serial settings on the remote device’s command shell or on the local command shell. What settings are you using?
That seems unlikely given that it works perfectly in either direction when streaming data as fast as possible, and only fails when switching “direction” frequently. Both ends are in factory configuration 9600/8N1. There’s no problem when replacing the radio pair with a wire, for instance.
Further experimentation shows that it happens much less or not at all when running the serial interfaces at a higher data rate than the RF data rate.
Weird, and I’m afraid I’ve run out of ideas. Well, that didn’t take long, did it?
If no-one else has any suggestions I think you’d do well to open a case with the fine folks at Digi support. They’re very helpful and knowledgeable over there.
Thanks for your suggestions… I may do that. For the time being I’ve found it works acceptably if I insert long (several character-time) delays between sending characters I expect to elicit immediate responses.