Coordinator+Router configured for transparent comunication(1047,1247 firmwares)
When my program (JAVA+librxtx) send data from coordinator to router all work good, but when data transmited from router to coordinator it looks like some coordinator recv some first bytes and than RX LED stop light and no data recv.
when i use comand like “cat /dev/urandom > /dev/ttyUSB0” (send some random stream) all works good.
i need bedirection comunication so i can anderstand why transmition stops.
when transmition stops tx on ftdi continue blinking
if i pres reset button on hanging transmiter(not all devices only rf module) after 10s i see that few data transmited and stop.
Connecting usb->com together directly work, so i think that is nor librxtr\java\ftdi problem
both xbee xonnected to ftdi only with power,ground,rx,tx
Can you Save the Profile from the Modem Settings tab (text file) and post this so we can see what the XBees parameters are set to.
Depending on which Firmware the XBee is running check parameters to set either number of bytes in the FIFO before transmitting and/or time without data transfer before transmitting would be a starting point.
I insert delay 20*1000/baudrate after each byte send and all works now.
But I dont understand why it hangs)))
Paketization set to 0 (do not use packetization). now i think to set paketization buffer to data bufer size - in my case each device sends data by blocks of constant length 10bytes in one side and 18 on other.
Thanks!)))
But what can you say about hanging? why? and how unfreeze it if it happend withow hardware reset. semple delay transmition for a few second dont unfreeze device.
Ok, it is sounding like you could be over running the XBee’s serial Buffer. Try again without the delays but monitor the CTS line from the XBee with an O’scope. When CTS is low the XBee can accept more data into DIN but when the internal FIFO Buffer gets almost full CTS goes high the signal the connected device to stop sending data.
Another issue may be the XTAL clock frequencies used by both the XBee and the other device. The XTAL frequency can not be divider into an integer to get the exact Baud rate on the XBee and there is a largish error at high Baud rates. One solution is to send data with two Stop bits. This acts as a small delay that allows the UART timing hardware to re-sync on the next Start bit.
802.15.4 devices like XBee send bytes in chunks of about 100 per wireless link data frame. So in transparent serial mode, you have to have some flow control in your application, or you must observe the CTS (clear to send) state. On a PC, you can turn on hardware handshaking for that COM port open instance. But IMO, it’s best to have an application program scheme to preclude overrunning the channel.
This is true for any data link.
Also, don’t use a PC baud rate of 115K or higher. Too little margin for error.