PB loosing packets in AT MODE for UART transmission

We made an RS232 to XBEE board adapter and want to transmit data from a PC through an hyper terminal and receive data on another PC in an hyper-terminal with a ZigBee Pro device

We just connected RX, TX and GND and the URAT conf is 115200, 8, N, 1. One is coordinator and the other is router.

We constat that the data are not transmitted in real time but by packets and we are loosing some data. Even if we change the baud rate and also put a second stop bit, nothing change.

Must we connect RTS and CTS ?

Is it possible to transmit byte per byte without loosing data ?

I have been having a similar issue - one of my modules is working fine but one of them loses data and either one is sending data in bursts or one is receiving in bursts. The communication works fine to the boards they are on and communication to the modules from the boards also appears to be fine (tested with some series 1 modules) but communication with these modules isn’t working.

I have tried resetting the modules, changing the configuration of which is the coordinator and which is the end device but the problem persists. This also happens on all baud rates.

Any ideas?

A mesh like Zigbee wasn’t designed to be used this way & there is a physical limit to how many packets can be sent per second from a single node. You are probably already creating too many small packets, so some are getting dropped.

Use something better than HyperTerminal (like Putty or others) which allow the tool to only send full lines of text. So when you hit , the full line is sent in a clean, continous stream. This will work quite reliably.

Will CTS/RTS help? Perhaps, but using the wrong tools is always troublesome, and it might cause other issues.

If you really want a remote dumb-terminal like this, then simple point-multi-point 802.15.4 XBee - which can use broadcasts - will work better. But you do not have the auto-mesh routing with 802.15.4. It is all line-of-sight.

Well I kind of jumped in here and the thread isn’t strictly the issue I’m having.
To explain would sabotage this thread so I will start a new one.

Playing with the RO setting - making it large, could help in this situation as it would delay sending packets.

Foe example, the default of RO=3 means at 9600 baud packets are sent every 3 msec. of course a human can’t type that fast. So trying to bump this up to say 500 (1/2 second) or 1000 (1 second) could allow more bytes to piggy-back into the previous packet.

Note that RO is related to baud rate, so while at 9600 baud RO=1000 is 1 second, at 115Kbps it is only about 100 msec, so still outside of human typing ability.

If you have the DH/DL as broadcast, there is very little room in the buffer to where it will flush some data…

Try changing the DH/DL address to the module you are communicating to.