[conspire] EIA RS-232-C, ... Re: DE-9, not DB-9 (was: ...

[Michael Paoli]

> From: Texx <texxgadget at gmail.com>
> Subject: Re: [conspire] DE-9, not DB-9 (was: conspire list hacked?)
> Date: Mon, 4 Mar 2019 15:37:24 -0800

> The computer industry found itself in a spot with multiple interfaces for
> multiple things.
> MoBos were MUCH easier to build if you could cut down on the number of
> different types of interfaces.
> The original mouse port was a db9 serial.

DE-9 :-}
Calling something what it ain't, don't make it so.*
*well, ... to at least some certain point, anyway.
So, yes, technically and correctly, it's DE-9, not DB-9.
Heck, even if you do a web search - try both - you get more than 10x
the results using the correct term DE-9 (or DE9), as compared to similar
with DB ... heck, even more of a difference if you exclude Aston Martin
(yes, Aston Martin almost as common as DB-9 ... but DE-9 much more common
and popular and widely deployed ;-) - and much less expensive too)

> The original serial interface was designed for terminals and modems.
Yes, DTE - Data Terminal Equipment, and
DCE - Data Communication Equipment (generally one's modem).
And, at least per the specifications, those remain the two
pinouts - and along with that genders, of the connectors and
pins/sockets ... that part of the specification tends to get
abused a *lot*, but per the specification, DTE is always male (pins),
and DCE female (sockets).  Some places it is (or at least was) almost
always done per spec - e.g. modems - almost always properly a
DB-25 DCE female.  Theoretically terminals would be DTE male - though
they are almost always DTE, they'd very commonly be female rather
than male (my hypothesis is terminal manufactures didn't want to have
to deal with issues of bent/broken pins on connector - the male connectors
were more vulnerable to that issue - the female connectors (sockets)
not so much.  One of the few other places I recall where DTE was actually
properly done as male, was the original IBM PC (not the AT) - if you
got a serial card for your IBM PC, it was DB-25 DTE male.

With the IBM Personal Computer AT, they changed it to use a DE-9 male -
wired to what became the defacto standard for putting a single channel
RS-232-C signaling into a DE-9 configuration - and on the PC AT, it was
male and considered the "DTE" configuration on the PC AT - the complement
that would connect to that was of course female, and considered "DCE",
adapters between 25 and 9 were considered "straight through" if
they connected to DCE or DTE DB-25 and presented on the other end as
a DE-9 likewise coming out as DCE or DTE respectively (the cable didn't
particularly care - it's the pinout and some other details that matters).
These "straight through" would typically be Male-Female (MF) - but not always
so.  Gender changes would be MM or MF, all pins(/sockets) straight through
(pin 1 to pin 1, 2 to 2, ... 9 to 9, up to 25 to 25 if a DB-25).
Null modem cable/adapters would re-wire between the connectors on each
end, such that one could connect two DTE (or two DCE) devices together
(they could not otherwise be directly connected e.g. with straight-through,
as the signals would all conflict - transmit would be connected to transmit,
receive to receive, etc.).  However DTE to DCE they do go direct, because
on one the transmit is out, the other in, etc.  There are also slightly
different ways (and ongoing debate remains) exactly how to wire a
"null modem" connector.  Why?  Because there's not a 100% correlation of
all the signal+control lines between DTE and DCE and how they're used,
so there exist a moderate amount of variations among how "null modem"
cables/adapters are wired.

Oh, and why is it called "null modem"?  Think of this:
DTE--[DCE_modem-----phone_line-----DCE_modem]-DTE
replace that with:
DTE--[null_modem_cable/adapter]--DTE
oooh, typically much faster and ... don't even have to dial!  :-)
So, yeah, in generally connecting DTE most efficiently to DTE
or likewise DCE to DCE.

> The RS-232 standard actually has TWO data channels in it, the second being
> a much slower interface.

Yes, two full (or almost entirely full) quite duplicate data channels -
*including* control signals too!  I don't recall anything about the
2nd channel being *slower* though.

I've *almost* never seen the 2nd channel used, though.  The one place I did
run into that, was some Sun Microsystems equipment.  Some of their servers
came with a DB-25 port, that has *both* serial channels fully active per
the full RS-232-C specification.  Since dang near nobody else actually
did that, they also came with an adapter cable, that would split those
two channels into two DB-25 RS-232-C DTE male connectors - one for
(what Sun) called the "A" serial port (at least if I recall correctly),
and the other, the "B" serial port (the connectors on the cables were
definitely labeled that way).  Both fully functional and in most
all ways highly symmetric - mostly configured, used, etc. same way on the
host and each capable of same speeds (I think the only difference was
serial console probably used or defaulted to the "A" serial port).

> This secong channel was designed for controling the modem and the dialer.

Nope ... well, at least not on any equipment I've ever seen.
Got example where 2nd channel controls modem/dialer?  I'd love to see!
Each has their own separate set of data and control lines and signals.
Oh, and in case one is wondering why IBM on the AT went to a DE-9?  Likely
very simple - the connectors were quite commonly available economically,
they saved real estate (could fit 2 connectors in where 1 fit before - or
put something else in where the 2nd connector would otherwise be).  And
9 is really the minimum number of pins/lines needed to do the full single
channel of RS-232-C ... well ... 9+9 != 25 ... what happened?  I don't
recall without looking it up (feel free to), but I think some unused or
highly rarely used lines were dropped - but other than that, it just
split out and used the single channel.  And, no, not as easy as a
one-to-one correspondence on the first 9 pins of DB-25 ... quite different
than that and different ordering/arrangement, but in any case, down to 9,
and I think they combined two of them (earth/chassis/cable ground, and
signal ground, if I recall correctly) ... something really pretty easy to
be done as much of the time even with DB-25 those were already common /
bonded together somewhere in the circuitry anyway.
(I think I may still have somewhere in my archives, EIA RS-232-C full
specification - they didn't hand 'em out for free, but one could purchase
a copy ... I have a copy (well, copy of such a copy)).  Pretty interesting
too ... does well cover lots of details, like minimum and maximum
rise times, maximum capacitance between lines (two lines in a cable are
also a capacitor after all - pair of conductors separated by a dielectric
material ... as length goes up, so does capacitance ... part of wire signal
cable specs includes capacitance per ft. (or other length unit measure).
The spec also has lots of information on voltages on the signal,
maximum amounts (it's designed such that, at least in theory, no matter how
one miswires/misconnects an RS-232-C pair of devices, the electronics should
survive - many other interfaces would fry if similarly misconnected ...
in all my years, only once had an RS-232-C interface die from incorrectly
connecting to another RS-232-C interface (and I ended up replacing the
failed IC on the printed circuit board - I think it was on a terminal - but
long time ago, so I forget exactly what the hardware was).

> The "ATDT" command set allowed "in band signalling" and this removed the
> need for the second data channel.

Uhm, yes and no ... the second data channel wasn't used for that,
(at least on anything I ever saw)
it was signal lines of the first channel.  And the Hayes (compatible)
ATDT (etc.) command set didn't *replace* data lines, it mostly added
functionality or otherwise replaced other functionality (that wasn't the
only such command set, but it quickly became most popular and defacto
standard).  What those commands did, among other things, was allow one
to get the modem to dial a number ... or to hangup a call.
*none* of the RS-232-C control lines have anything in them (well, the spec.)
about how to dial a phone number.  "Back in the day", the modem didn't
do that anyway ... you couldn't (legally) just plug a modem into a
phone line.  You dailed number on phone, and once modem answered,
set handset into a set of rubber(ish) cups, to establish an acoustic
(non-electrical) connection to the modem - the modem then listened to /
talked to the phone, with it's speaker and microphone in those cups.
ATDT command sets would be useless with that as the modem couldn't
control the phone.  Years later, one could directly connect modem
to phone line, so ... hence use/"need" for ATDT, etc. command set.
Now one could command the modem to pick up the phone line, and dial
a number.  Or likewise tell it to hang up the phone line.

Random - "Hayes compatible".  I'd often test modems to see if they were
"Hayes compatible".  Some of the ways I'd test was to use more obscure
features/capabilities that Hayes implemented, that most other "clone"
modems didn't bother with, e.g.:
DTMF (Dual Tone Multiple Frequency) dialing, a.k.a. Touch Tone (TM)(or (R) or
whatever).  The full DTMF spec has not 12 (as on common US phones),
but 16 digits/symbols it can dial.  Each sends a pair of tones, one for
row, one for column.  Full spec. has another column to the right, labeled
from top to bottom, A, B, C, D (and not to be confused with the little
letters printed above most of the numbers).  Well, the Hayes can also
dial A, B, C, and D.  Many clone modems failed at that.  (maybe some day
I ought set up a voicemail system that requires folks to also be able
to dial A, B, C, and D.  ;->)
600 baud - the Hayes 1200 (and up) modems, also supported 600 baud.
Many/most of the "clone" modems didn't support 600 baud.

Another semi-random bit ... Unix (not to be confused with Linux).
Yes, sure, Unix could and would use Hayes (compatible) and other
modems with other command sets.  Unix would generally *require*
not just the transmit/receive data lines (at least on modem lines)
but additional signal lines.  It would use out-of-band (control) signals,
notably when carrier dropped (the modem lost communication with the
remote modem), the modem would drop the DCD line, and Unix would then respond
to that by dropping - I think DTR if I recall correctly, which, one would
need to correspondingly have the modem properly configured, but when so
configured, once the Unix host dropped the DTR line to the modem, the
modem would respond by hanging up the phone (and Unix would also
SIGHUP the processes with that modem tty device port as associated
controlling terminal device).  Also, in part of that (modem, etc.)
configuration, there would be no way to signal the modem in-band
(e.g. to call a very expensive number in some other country)
so long as the DCD was asserted (carrier detected).  The modem would
be configured to only accept AT(etc.) commands after DTE (if I recall
correctly) had been dropped.  Oh, also, for non-ancient Unix, for security
and such, once it did the modem hangup, it wouldn't allow any other existing
processes to have that tty device open - I forget the system call, but
I believe it essentially would invalidate any existing file descriptors
open on that device.

Linux, on the other hand, has all kinds of different tweaks and such,
so one can, if I'm not mistaken, do entirely in-band signalling, or
nearly so.  That may not necessarily be *preferable*, but it will do
it ... and can also support much or all of the out-of-band signal line
stuff too.

And as for mere minimum number of lines one can usefully use RS-232-C
over?  Three.  The (primary channel) transmit and receive lines plus signal
ground.  That's how Unix/Linux terminals should be wired up - don't need
any more, and generally shouldn't use more than that for just terminal
connections.  They'd also be configured for software flow control -
X-on/X-off (^Q/^S).  More full RS-232-C (additional lines) can of course
do hardware flow control (that control them out of the data band, but rather
in the control signal(s)), but generally one would do software, not hardware,
flow control on terminals.

> The "Xon-Xoff" protocol removed the need for hardware handshaking.
> The DB25 which was about 3in wide shrunk to the DB-9 that was only 3/4in
> wide.

Again, not "shrunk to" - DB never shrunk, but was - in large part,
replaced (at least for many common computers and peripherals) with a
DE(-9) configuration.

> What we got from USB, was the ability to use the same protocol for
> keyboard, mouse, serial, external drives, and in some cases audio & video.
>
> USB serial ?  How does that differ from RS-232?
> USB serial is "TTL level" which means the signal is either 0 or +5 and
> thats it.

Nope.  A proper USB to "serial" (RS-232-C - though often done as a  
DE-9M DTE rather than DB-25M) does level conversion, so it's not TTL  
levels.  TTL levels
would typically not interact successfully with an RS-232-C (at least signal
level) interface.  Note, however, there are lots of (non-standard) variations
of RS-232-C signaling.  E.g. yes, TTL - that's how the Raspberry Pi does it -
uses TTL levels - so that won't work talking to proper RS-232-C equipment.
However, level converter chips are readily available, so a circuit to convert
between the two is simple - very handy to talk to more standard equipment,
but if you only want to talk to another Raspberry Pi, why take the extra
space/power/expense to do the level conversions?
Current loop - is much less susceptible to noise causing problems with
signal.  It's used, e.g. on ye olde land line telephone.  Also is(/was? are
they all gone yet?) used on many/most teletypes and teletype service.
It was (mostly) RS-232-C-like ... but instead of by voltage, as RS-232-C
is, the signalling was done by current - that's also quite handy where
there may be very large variations in the length of the wired
connection (e.g. up to miles or more).  If I recall correctly, at least
if everything is done within spec., maximum length on RS-232-C works out
to be something like 25 (or 50?) ft. or so ... if one bends/stretches the
spec, lengths of up to about 150 to 300 ft. or so can sometimes be obtained
(and also generally requiring low capacitance cabling).  Some interfaces/
chips even push such as a "feature" - that they can do the signalling
over significantly longer lengths - with suitable cabling - and otherwise
standard RS-232-C signaling equipment on the other end.  (I dealt with
standard RS-232-C terminals in warehouse that were well beyond what pure
RS-232-C spec distances would handle - yet we were able to get them to
generally work quite reliably - I think our longest was around 200ft. or
so.)

> RS232 is interesting.  It was designed to tolerate long cable lengths.
> Ones were between -5 and -25, zeros were between +5 & +25.  Voltages
> between -5 & +5 were invalid as weere voltages in excess of 25 or either +
> or -.

Yep, +-25V absolute max on the spec.  Nominal signal levels at +-12V.
And, as you can see, TTL ain't quite gonna make it (or at least not
reliably so).

> Default USB serial is 115k baud.
>
> By moving to USB, you could also plug any usb device into any usb socket as
> the bus queries the device and figures out whats what.
> Its all about making computers easier to use so that even morons could use
> one.

Oh, don't worry, they keep making more creative morons.  And yes, it is
possible (but difficult) to improperly insert USB and fry electronics,
and, at least in theory, USB-C was also designed to be yet more resistant
to such "creativity".

> Technology has marched so far along that even the dimwitted YOTUS
> (Twitterer Of The USA) is able to use one!

> On Mon, Feb 18, 2019 at 11:21 AM Michael Paoli <
> Michael.Paoli at cal.berkeley.edu> wrote:
>
>> DE-9 (or DE-09), *NOT* DB-9 (nor DB9 nor DB-09).  Many folks get this
>> wrong ... sometimes even vendors' documentation is incorrect.
>> A DB-9 (were there such an animal) would have the same shell size as
>> a DB-25, but with only 9 pins.
>> Once upon a time, Electronics, Etc. in Berkeley had an excellent
>> display of the various connectors ... and their proper labeling.
>>
>> See also: https://en.wikipedia.org/wiki/D-subminiature
>>
>> > From: "paulz at ieee.org" <paulz at ieee.org>
>> > Subject: Re: [conspire] conspire list hacked?
>> > Date: Mon, 18 Feb 2019 18:32:00 +0000 (UTC)
>>
>> > Regarding USB cables.  Before USB there were serial ports.  In those
>> > days, we all had a variety of devices with the DB-9 connector.
>> > Using a new connector with an older device was a challenge.  Several
>> > companies offered adapter cables.  The ones by FTDI actually worked
>> > well.  On the outside they looked like a simple cable with USB A
>> > connector on one end and DB9 on the other.  Molded into the cable
>> > was a custom chip that provided an active interface.  More than
>> > once, I had to explain to someone that they couldn't just use an
>> > Ohmmeter to figure out the pin connections.