I have a pair of XBee Series 1s sending serial data, everything works perfectly.
I’ve got one mounted on an Arduino with the XBee shield, the other is connected to my PC through the Sparkfun XBee Explorer USB (http://www.sparkfun.com/products/8687 ). But essentially the PC sees the XBee on the COM3 serial port.
The Arduino is doing some measurements and sending the data to the PC. Again, this all works perfectly.
Now here’s the strange part - the second XBee only transmits the data it receives over wireless when the COM port is open. (I can see the RX LED flash on the Sparkfun board).
This is easily replicated in X-CTU - when I press the “Close COM port” button in the Terminal, the data stops flowing (RX stops flashing) in about a second.
Changing the assertion of DTR and RTS doesn’t do anything - so I’m wondering how else the XBee knows the port is open or closed?
If I set ATD6 to 1, then it responds to RTS flow control perfectly (i.e. it stops sending the received data instantly). But this is not what I want.
Ultimately, I want to move the XBee into its own dedicated circuit and for it to always send the received data regardless of whether anything is connected.
How can I accomplish this? AT settings or hardware solutions work for me.
On the XBee, CTS is an output to tell the mated device to stop sending - the XBee’s buffer is full to within a couple of bytes.
Read up on RS232’s definition of DTE and DCE. This is confusing for newbies. These and DTR and DCD date back to dial-up modems. CTS was used to flow-control data going to the modem at a speed higher than the modem’s channel (modulated signal) can accomodate. RTS was used to ask the modem to prepare to send - a command if you will, so RTS is not often used.
Most devices using asynch. serial can be configured to ignore CTS. Doing so, the responsibility for flow control falls upon the application program’s schemes.
Schema:
According to the XBee Manual, Figure 2-03, /CTS is an output from the XBee to the host to say that the DI buffer is nearly full.
stevech:
On the XBee, CTS is an output to tell the mated device to stop sending - the XBee’s buffer is full to within a couple of bytes.
OK, got that part :wink: And this XBee is not sending, only receiving (specifically, receiving over wireless and then sending over serial).
Read up on RS232’s definition of DTE and DCE. This is confusing for newbies. These and DTR and DCD date back to dial-up modems. CTS was used to flow-control data going to the modem at a speed higher than the modem’s channel (modulated signal) can accomodate. RTS was used to ask the modem to prepare to send - a command if you will, so RTS is not often used.
Most devices using asynch. serial can be configured to ignore CTS. Doing so, the responsibility for flow control falls upon the application program’s schemes.
Oh, I know the terms, just a bit rusty. So at the application level, I've limited the Transmitting XBee to 19200 bps, and am carefully controlling the send rate (3 bytes every 100 milliseconds).
The problem is, on the Receiving end, there’s no “DTE” per se - it’s a MIDI synthesizer. And the article doesn’t mention flow control at all, so I’m wondering what I’ve missed.
Here’s the schematic, and it looks like RTS and DTR are forced high - maybe my board is different, need to check.
If you’re thinking of it in actual specifications, the “RTS” signal that is described within the documentation is the result of shorting RTS and RTR as per TIA-232-E. This of course is a pain for those of us who have to interface with this hardware, but so it goes.
They also provide a fifth signal “Uart Data Presence Indicator” which allows you to de-assert “RTS/RTR” after RxD goes idle and then re-enable it.
This protocol is a historical artifact as a good number of modem manufacturers got it wrong in the standards between RS-232 and TIA-232-E. Hope that helps to keep it a bit clear in your head.
Hardware flow control is usually done with CTS (clear to send). Receiving end takes CTS false and within a few character times, data should stop flowing. But only if the sending end implements hardware flow control and has it enabled.
RTS (request to send, not "ready to send) is not used for flow control unless modems are in the loop.
Much wiser to NOT use hardware flow control. Race conditions galore. Better to have the application messaging do blocked data flows with an application layer flow control. Or use a network layer on fancier systems (e.g., DigiMesh on Series 1).
