andy@progress.COM (Andrew Klein) (02/14/91)
I have a 3b1 but no documentation. Can anyone provide me with the recommended cable pinnings for an external modem? Your help is much appreciated. Please e-mail me. -- Andrew Klein UUCP: mit-eddie!progress!andy Progress Software Corp. Internet: andy@progress.com 5 Oak Park Bedford, MA 01730
bruce@balilly.UUCP (Bruce Lilly) (02/18/91)
In article <1991Feb13.172049.21792@progress.com> andy@progress.COM (Andrew Klein) writes: >I have a 3b1 but no documentation. Can anyone provide >me with the recommended cable pinnings for an external >modem? Your help is much appreciated. I'm posting, beacause this should help answer another recent poster's question regarding modem connections. function 3b1 pin modem pin frame gnd. 1 ___________ 1 TD 2 ___________ 2 RD 3 ___________ 3 RTS 4 ___________ 4 CTS 5 ___________ 5 DSR 6 ___________ 6 signal gnd. 7 ___________ 7 CD 8 ___ DTR 20 ___|_______ 20 TC 15 ___________ 15 RC 17 ___________ 17 RI 22 ___________ 22 ETC 24 ___________ 24 -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
thad@public.BTR.COM (Thaddeus P. Floryan) (02/19/91)
andy@progress.COM (Andrew Klein) in <1991Feb13.172049.21792@progress.com> writes: I have a 3b1 but no documentation. Can anyone provide me with the recommended cable pinnings for an external modem? Your help is much appreciated. Please e-mail me. Email has been sent, per: For the 3B1, you simply need a cable that passes all 25-wires straight through; its RS-232 port pinnings are as "standard" as anything I've seen on any other computer. If you cannot readily find such a cable or don't relish the thought of 5 pounds of wire hanging off the DB-25 connector, the minimum pinnings with which one can connect to a modem comprise (and is what I use to connect to ARK 24K, Digicom 9624LE, Telebit T2500, VenTel, etc. modems from my 3B1s): (1)-----(1) <-- optional, but recommended (2)-----(2) (3)-----(3) (4)-----(4) <-- only if hardware flow control is used (5)-----(5) <-- only if hardware flow control is used (6)-----(6) (7)-----(7) (8)-----(8) (20)-----(20) If you want to connect a terminal to one of the RS-232 serial ports on the 3B1, you must make a "null modem" cable which, for the 3B1, is: (1)-----(1) <-- optional, but recommended (2)-----(3) (3)-----(2) (4)-----(5) <-- only if hardware flow control is used (5)-----(4) <-- only if hardware flow control is used (7)-----(7) (6)--+ | (8)--+--(20) +--(6) | (20)--+--(8) The above "null modem" cable "fakes" a modem's DSR (6) and DCD (8) signals to a DTE (terminal or 3B1) device based on the DTR (20) signal at the other end. If you're going to be using the HDB UUCP software suite on your 3B1, you will quickly encounter some frustrating "Cannot connect to device" problems which are easy to fix in the software config files. If you have a problem in that regards, post the question and I'll reply; I just fixed another person's system several days ago ... requires use of not-well-documented tricks in the Devices and Dialers files and requires about 30 seconds with an editor once one knows HOW to do it (for those who remember my "... even put Mother Theresa on a killing rampage ..." criticism of HDB two years ago :-) Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
thad@public.BTR.COM (Thaddeus P. Floryan) (02/19/91)
bruce@balilly.UUCP (Bruce Lilly) in <1991Feb17.174820.18716@blilly.UUCP> writes:
I'm posting, beacause this should help answer another recent poster's
question regarding modem connections.
function 3b1 pin modem pin
frame gnd. 1 ___________ 1
[...]
CD 8 ___
DTR 20 ___|_______ 20
TC 15 ___________ 15
RC 17 ___________ 17
RI 22 ___________ 22
ETC 24 ___________ 24
I disaggree with that wiring of DTR to CD at the 3B1 end. It is MOST
important for the 3B1 to be able to detect when the modem:
1] connects, via its CD signal going true, and
2] disconnects, via its CD signal going false.
In my response to andy@progress.COM I posted the correct cable pinnings for
use with a modem and for use with a terminal; that posting should have been
just a few articles before this one.
One of my companies makes a "device" that interfaces modems to host computers
with most of the sales going to phone companies and the DoD, so I'm no "babe
in the woods" concerning modems. I have tested hundreds of different modems
over the years and can just about solve any modem-related problem that you
can imagine; you shoulda seen the response I received earlier this evening
from a guy pleading for help with a modem that hasn't been made since 1978 and
I was able to produce ALL the docs he needed from my files! :-)
My product even includes the capability of autobauding from 300-19,200 using
an asynchronous UART (MC68681); if you don't understand why I mentioned that,
don't bother asking because it's a trade secret and has caused all competitors
(incl. Lockheed and other biggies) to drop out of this line of business (after
they pooped their pants! :-)
The ONLY real "problem" I've had with modems has concerned the HDB UUCP
software suite re: the frustrating "Cannot connect to device" problems, which
now, after resolving all the documentation errors, are easy to fix in the
software config files. If you have a problem in that regards, post the
question and I'll reply; I just fixed another person's system several days ago
which requires use of not-well-documented tricks in the Devices and Dialers
files and requires about 30 seconds with an editor once one knows HOW to do it
(for those who remember my "even put Mother Theresa on a killing rampage"
criticism of HDB two years ago :-)
Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]bruce@balilly.UUCP (Bruce Lilly) (02/20/91)
In article <1840@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >bruce@balilly.UUCP (Bruce Lilly) in <1991Feb17.174820.18716@blilly.UUCP> writes: > >> CD 8 ___ >> DTR 20 ___|_______ 20 > >I disaggree with that wiring of DTR to CD at the 3B1 end. It is MOST >important for the 3B1 to be able to detect when the modem: > >1] connects, via its CD signal going true, and > >2] disconnects, via its CD signal going false. Unless CD is asserted, a write to/read from a tty port will fail. So something like: echo ATZ >/dev/tty001 will not work, if a modem connected to the port has not asserted CD. The connection I gave will work, as DTR is asserted when the port is open(2)'ed. > [ Thad thumps his breast for a bit ] > >The ONLY real "problem" I've had with modems has concerned the HDB UUCP >software suite re: the frustrating "Cannot connect to device" problems, which >now, after resolving all the documentation errors, are easy to fix in the >software config files. If you have a problem in that regards, post the >question and I'll reply; I just fixed another person's system several days ago >which requires use of not-well-documented tricks in the Devices and Dialers >files and requires about 30 seconds with an editor once one knows HOW to do it >(for those who remember my "even put Mother Theresa on a killing rampage" >criticism of HDB two years ago :-) Nothing in any of the HDB UUCP files will affect the example given above. I've been using the connection above with no problems whatsoever. Thad, why do you feel that ``it is MOST important for the 3B1...''? 1) What will break given the connection I posted? 2) How would you be able to write to the modem (simply) from the shell? Sidebar: many modems have a hardware (and possibly software) option to continuously assert CD so that writing to the modem is possible when carrier is not present (e.g. refer to page 2-4 of the Digicom Systems, Inc. 9624LE User's Manual). -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
gandrews@netcom.COM (Greg Andrews) (02/21/91)
In article <1991Feb20.023929.24345@blilly.UUCP> bruce@balilly.UUCP (Bruce Lilly) writes: >> >>I disagree with that wiring of DTR to CD at the 3B1 end. It is MOST >>important for the 3B1 to be able to detect when the modem: >> >>1] connects, via its CD signal going true, and >> >>2] disconnects, via its CD signal going false. > >Unless CD is asserted, a write to/read from a tty port will fail. So >something like: > >echo ATZ >/dev/tty001 > >will not work, if a modem connected to the port has not asserted CD. The >connection I gave will work, as DTR is asserted when the port is >open(2)'ed. > >>[Thad's comments about HDB-induced anger deleted] > >Nothing in any of the HDB UUCP files will affect the example given above. >I've been using the connection above with no problems whatsoever. > >1) What will break given the connection I posted? > >2) How would you be able to write to the modem (simply) from the shell? What will break is detecting that the other modem has disconnected on you, or that you've lost the connection due to phone line trouble. Also your system will not notice when a dial-in user disconnects without logging off - your system won't kill their processes and restart getty because it doesn't know they're gone -- DCD is still on! Not very secure... >Sidebar: many modems have a hardware (and possibly software) option to >continuously assert CD so that writing to the modem is possible when >carrier is not present (e.g. refer to page 2-4 of the Digicom Systems, >Inc. 9624LE User's Manual). Heck, that's the DEFAULT setting for most modems. The REAL solution to your Question #2 above and the problem as a whole is to change the modem's DCD handling. What you want is for DCD to be on always (allowing writes and dial-out access) until a modem connection is broken. Then DCD should turn off for a short period of time and come back up. You get access to the port and carrier sensing all at the same time. Telebit modems can control DCD this way by setting S131=3. If you have an older revision with S53 instead of S130/S131, then set S53=4 and wire the modem's DSR (pin 6) to the system's DCD (pin 8). The amount of time DCD stays off is controlled by S47 (normally 200 milliseconds). -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'
thad@public.BTR.COM (Thaddeus P. Floryan) (02/21/91)
bruce@balilly.UUCP (Bruce Lilly) in <1991Feb20.023929.24345@blilly.UUCP> writes:
Unless CD is asserted, a write to/read from a tty port will fail. So
something like:
echo ATZ >/dev/tty001
will not work, if a modem connected to the port has not asserted CD.
The connection I gave will work, as DTR is asserted when the port is
open(2)'ed.
Oh? Then perhaps you'd like to explain why HDB UUCP, Kermit, Pcomm, etc.
all can "talk" to a modem whose CD signal is not asserted TRUE at the 3B1's
RS-232 interface port?
Has everyone so quickly forgotten the anecdote posted last month about a
person who called the US Naval Observatory time service number in Washington,
DC, only to later find a humongous phone bill because the modem wasn't strapped
to properly drop CD when the connection was to be terminated?
Seems people have forgotten my posting two years ago when I brought up HDB
UUCP on my 3B1 and I claimed that HDB was brain-damaged and "... would put
even Mother Theresa on a killing rampage...". The docs for HDB UUCP in this
regards are truly bad for the "stock" SVR3.2 version (but are OK in the docs
for the 386 SVR3.2 manual set). Some of the docs do appears in the SVR3.2
Utilities Release Notes in obscure places.
Remember: the "stock" version 2 uucp worked correctly talking to a modem when
CD wasn't asserted, but the HDB did NOT work correctly until one used the
very poorly documented "\M" (for CLOCAL) in Dialers and ",M" in Devices.
Nothing in any of the HDB UUCP files will affect the example given
above. I've been using the connection above with no problems
whatsoever.
I just one paragraph above mentioned the "\M" and the ",M" ... those options
ONLY work for HDB and for precisely the reasons I've described time and time
again.
Thad, why do you feel that ``it is MOST important for the 3B1...''?
1) What will break given the connection I posted?
2) How would you be able to write to the modem (simply) from the shell?
1) If some data connection terminates abnormally (i.e. without the "OO" from
uucico), your line may stay connected forever. Not good for one's pocketbook
on a long-distance call. One should ALWAYS respect the condition of DCD & DTR
for unattended (i.e. automatic) modem usage.
2) I would never care, under normal circumstances, to write to the modem direct
from the shell, but when I do, I would simply do:
ls -l /dev/tty*
and for each ttyXXX's [major,minor] pair, simply do:
mknod modemXXX c major (minor+128)
and then you can do what you wanted to do, WITHOUT the (improper) need to
continuously assert CD from the modem. In case this isn't clear:
$ ls -l /dev/tty0* /dev/modem*
crw-r--r-- 1 root root 0,128 Feb 20 19:49 /dev/modem000
crw-r--r-- 1 root root 0,130 Aug 25 15:26 /dev/modem001
crw-r--r-- 1 root root 0,131 Aug 25 15:26 /dev/modem002
crw-r--r-- 1 root root 0,132 Aug 25 15:26 /dev/modem003
crw-r--r-- 1 root root 0,133 Feb 16 06:59 /dev/modem004
crw-r--r-- 1 root root 0,134 Aug 25 15:27 /dev/modem005
crw-r--r-- 1 root root 0,135 Aug 25 15:27 /dev/modem006
crw-rw-rw- 1 uucp users 0, 0 Feb 20 19:48 /dev/tty000
crw-rw-rw- 1 uucp users 0, 2 May 13 1990 /dev/tty001
crw-rw-rw- 1 uucp public 0, 3 Jan 7 1990 /dev/tty002
crw-rw-rw- 1 uucp users 0, 4 Feb 20 14:22 /dev/tty003
crw-rw-rw- 1 uucp users 0, 5 Feb 16 06:59 /dev/tty004
crw-rw-rw- 1 root users 0, 6 Mar 2 1988 /dev/tty005
crw-rw-rw- 1 root users 0, 7 Mar 2 1988 /dev/tty006
I exploit that capability in my highly-modified version of Boyd Ostroff's
"modemon" package for the 3B1. Hmmmm, perhaps I should email that stuff to
Dave for posting to comp.sources.3b1 since it easily solves EVERYONE's modem
and uucp problems.
Having created such "modemXXX" devices permits handling them from the shell
or other programs as do the "\M" and ",M" for HDB UUCP.
All this can be summed up as:
**********************************************************************
* The correct assertion of a CD signal from the modem to a DTE (i.e. *
* a 3B1) is as important as is a DTR signal from a DTE to a modem. *
**********************************************************************
Bruce continues:
Sidebar: many modems have a hardware (and possibly software) option to
continuously assert CD so that writing to the modem is possible when
carrier is not present (e.g. refer to page 2-4 of the Digicom Systems,
Inc. 9624LE User's Manual).
I have 2 of those modems (and their manuals); the page is "1-4" in the Digicom
9624LE manual, and the description is either:
"DCD Forced on"
OR
"DCD normal RS-232"
The "normal" state of DCD is for the signal to be asserted true ONLY when there
is a data carrier detected (DCD) (i.e. one's modem is talking to another).
I hope everyone can convince Bruce to pay your phone bills for "terminated" but
still live phone calls if you take his advice in this regards! :-)
And please note I'm NOT trying to impugn Bruce. Modem problems are a common
question thread I handle at user and technical meetings. Most modem manuals
would have been better never written due to how much they confuse the issues,
and I have yet, after 25+ years, to find a "good" modem manual.
Thad "Mr. Modem" Floryan [thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad]gandrews@netcom.COM (Greg Andrews) (02/22/91)
In article <1861@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: > "Telebit modems can control DCD this way by ..." > >The Telebit solution works and (appears to be) a solution for many people's >problems, but few (if any besides Telebit's) modems are so featureful; doesn't >bother me because I have some T2500, and the {"\M",",M"} solution with HDB UUCP >takes care of the problem for all other modems (including the Digicom 9624LE >and ARK 24K which are also connected to my 3B1 systems). Hi Thad, I sumbitted the Telebit solution because that was the only one I was aware of. I had seen the \M and ,M parts of the Devices files, but didn't know what they were for. Thanks for mentioning them to a relatively new comp.sys.3b1'er. >I still submit the proper action is for a modem's DCD to be asserted FALSE >until a carrier is detected and the modem is ready to "talk" much the same as >a terminal's (or computer's) DTR should be asserted FALSE until a terminal is >powered-up and/or on-line. I agree completely with you. Apparently the difference between the Ver. 2 dialout processes and the HDB ones is that the newer ones don't open the port with CLOCAL set anymore (unless you tell them to)... Wonder if that was merely an oversight, or if something else in the system needed it to work this way...? -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'