[Coco] Re: Supercomm: more details

[John E. Malmberg]

KnudsenMJ at aol.com wrote:
> In a message dated 8/13/04 6:09:25 PM Eastern Daylight Time,
> james at skwirl.ca 
> writes:
> 
>>As I see it, DCD should be fed by DTR and RTS...

As you point out, not RTS.  You also do not want to tie two outputs 
together.

> I dunno, it seems that 
>> DTR would be a sensible source for DCD... DCD is more of a 
>> session-based on or off, like DTR and DSR (from what I've seen in the 
>> past) whereas RTS and CTS are more for hardware handshaking...

Except for printers on a local connection.  For some reason the printer 
manufactures implemented DSR/DTR handshaking on them instead of RTS/CTS.

> You have a good point there -- DCD is indeed session-level, like DTR and DSR.
> However, many RS232 interfaces are designed to receive only when DCD is on, 
> to prevent responding to noise on the line (makes plenty sense with a real 
> modem), but I think the practice of feeding RTS to DCD on a Null modem was to make 
> sure the receiving end read data only when the sender was actively sending it.

No, it was a bug because the person who said to do so did not know what 
they were doing.  That bug can be found in both hardware and software 
that is mainly intended for use with PCs.

I have a HAM packet modem with that bug hardwired into it, and it 
requires a b******d cable for me to connect it to use with standard 
computer or terminal equipment.  And it annoys me to have to keep track 
of a non-standard cable because of someone not being able understand a 
specification.

> ISTR some interfaces and software drivers are set up to drop the session the 
> first time DCD goes down

It is a CCIT and equivalent requirement for a host computer session to 
do so.

The DCD signal indicates that the link has valid data.
The DSR signal indicates that the communication hardware is online.

For an example of the difference between DCD and DSR is in communicating 
with a standard modem to dial out from a computer, the computer asserts 
DTR to the modem, and the modem answers with DSR with in a required time 
period.

The computer also optionally asserts RTS and gets a CTS response from 
the modem, for the data handshaking.  Most commercial equipment can be 
configured by software to ignore the RTS/CTS lines as they are often 
omitted from cables.

At this point, the computer can send commands to the modem to get it's 
status, and issues dial commands.

When the remote system answers with it's carrier, the local modem sets 
the DCD signal, this lets the computer know that there is a remote 
system available.

If either the DSR or DCD drops, the computer assumes that the session is 
gone, and it is supposed to drop DTR in response.

When the computer decides to terminate the link, it drops DTR.  This 
should cause the modem to drop the session, and reset it self to it's 
power up defaults.

Some clones of the Hayes modem failed the test of reseting them self to 
the power up defaults when DTR is dropped by the host.  Which means that 
they can be used for initiating dial out sessions, but can not be used 
on a computer to answer incoming dial sessions.

> -- if so, you definitely do want DCD fed from DTR, 
> not RTS.

Yes, if you want to be compliant with the official standards.

-John
wb8tyw(at)qsl.net
Personal Opinion Only