Hi, Folks,
Could you tell me the meaning and function of DTS and RTS?
Thank you very much
Best
J
Is Wikipedia broken today?
DTR is data-terminal-ready. If this is not asserted, then the DCE should not send data. RTS is ready-to-send. It means "I would like to send some data but I am being polite and waiting until you are ready."
They are very rarely used. 99% of the time they aren't connected to anything.
I think you have one of your abbreviations wrong
RTS means Ready Request To Send and its counterpart is CTS Clear To Send
DSR means Data Set Ready and its counterpart is DTR Data Terminal Ready
Back in the days of modems the Data Set was at one end of the link and the Data Terminal at the other (I can never remember which was which).
These signals are used for flow-control between the two devices. The USART on an Arduino does not have the facility for either system. However it is sometimes necessary to set these values on a PC when communicating with an Arduino.
...R
Edit to change Ready to Request
Edit to note that the following may be incorrect - see the rest of the Thread
Request is used in the sense of "please may I send" and not "please will you send"
Robin2:
Back in the days of modems the Data Set was at one end of the link and the Data Terminal at the other (I can never remember which was which)....R
Which is why "null modem cables" were sold by the millions (I remember one time at work we decided to rewire some computer stuff we were moving and found 7 null modem cables strung together - well, it was an odd number so it did what it was supposed to (all this was hidden in an overhead cable tray).
gpsmikey:
Which is why "null modem cables" were sold by the millions
Indeed. But I don't think I ever figured out whether one was needed except by trial and error - usually trying to get a printer to work.
...R
Robin2:
Indeed. But I don't think I ever figured out whether one was needed except by trial and error - usually trying to get a printer to work....R
Which was exactly how we ended up with 7 of the buggers hooked up in the cable tray. Each time something had changed, someone had experimented until they found what worked (which seemed to involve adding a null modem cable 
)
RTS = Request To Send
Pete
el_supremo:
RTS = Request To SendPete
Thank you. I will correct my earlier Reply.
I just realized that, while you are perfectly correct, Rquest to Send is ambiguous. It does mean "Please may I send" but it could equally mean "Please will you send". The second one is actually handled by CTS.
...R
These days, CTS in one direction and RTS in the other direction. Actual use as "may I send" is old-style...
westfw:
These days, CTS in one direction and RTS in the other direction. Actual use as "may I send" is old-style...
My understanding is that B asserts CTS to tell A that it can accept a message and A asserts RTS to let B know that it has a message to send. But A won't send the message until C B asserts CTS
Is that incorrect?
...R
@Robin2. You're correct (except "But A won't send the message until B asserts CTS"). But the RS-232 standard has been ignored, worked-around or heavily modified such that it doesn't mean much any more - mostly because technology has marched way ahead of what was available at the time the standard was first described.
Pete
The big problem happened because in the original definition, it was created for a terminal of some sort connected to a modem etc. But then along came all these other configurations where a modem is talking to a computer - now which is the which from the viewpoint of the definition. That was where life started getting complicated. Then we had all the various things people would build that ran on serial - back in the day of discrete logic etc. every pin was important and often the control signals were not even used because that required additional logic and cost. When it was simple and there was a terminal (or tty) connected to a modem, then the definition worked, but these PC things and other configurations really created a situation where the definitions didn't apply ... so they were worked around and ignored (then there was always the XON/XOFF version of software flow control that required more processing power, but less hardware)
el_supremo:
@Robin2. You're correct (except "But A won't send the message until B asserts CTS").
Age is catching up with me - my fingers seem to be detached from my brain. Maybe its time to buy the white suit.
...R
Robin2:
Age is catching up with me - my fingers seem to be detached from my brain. Maybe its time to buy the white suit....R
Sadly, I know that feeling all too well. I still remember when core memory was :o
These days, CTS in one direction and RTS in the other direction. Actual use as "may I send" is old-style...
My understanding is that B asserts CTS to tell A that it can accept a message and A asserts RTS to let B know that it has a message to send. But A won't send the message until C B asserts CTS
Is that incorrect?
If you're using "Hardware flow control" using RTS/CTS, then you're incorrect - RTS and CTS are symmetric in that case (which is the more common usage, these days.)
If you have a half-duplex modem or maybe an RS485 adapter, then your conception of RTS/CTS is more correct.
Wikipedia's RS232 entry has a good explanation.
westfw:
If you're using "Hardware flow control" using RTS/CTS, then you're incorrect - RTS and CTS are symmetric in that case (which is the more common usage, these days.)
Ahh ...
I think I overlooked the fact that RTS at one end is connected to CTS at the other end.
I think this means that I was completely wrong with my statement that RTS means "please may I send" and it actuall means "please will you send".
If so, then B asserts RTS which A sees as CTS and knows that it has permission to send data to B.
Apologies for the confusion.
When we have this sorted out I will correct Reply #2
...R