gnu@hoptoad.uucp (John Gilmore) (09/18/89)
The standards bogons are at it again.
Following on the massive success of the RS-232-C standard (and its
followon RS-449 which basically nobody ever adopted), there is a
new alternative connector for RS-232-C circuits. Of course, it
has even more wires than the current one, though it is physically
smaller due to improved connector technology.
The new specification is to use a 26-pin version of the "double density"
50-pin SCSI-2 connector. This makes it somewhat smaller than the current
DB25 connector, but not much.
The spec is simple, you use pins 1-25 the same way they were on DB25's
and you don't connect pin 26.
This specification is NOT a new standard. It is an "EIA/TIA
Telecommunications Systems Bulletin", TSB-26, February 1989. It is
four pages long and costs $10 from Electronic Industries Association in
Wash, DC. It was prepared by the TR30.2 Subcommittee on Data
Transmission Interfaces. It states: "This Technical Bulletin does not
constitute a formal change to the standards in question but the
information contained herein will be considered in their next
revisions...Although the connector presented in the attached drawing is
not presently the subject of an American National Standard or an
international standard, the values presented reflect current industry
agreements."
When I read the above I was relieved. THE MISTAKE IS NOT MADE YET!
I encourage any and all readers to make sure their companies don't use
this connector. What we really need is a SMALL connector with a
minimum number of wires. Not a perpetuation of the completely bogus
RS-232-C standard.
Draft goal spec of new connector:
* Cheap and physically small
* Easier physical connection than RS-232-C (no little screws)
* No options -- make it hard to mis-implement it
* No spare pins -- two mfr's can't use them for different things
* Connect 90% of data devices without trouble.
* (the other 10% can use RS-232-C or RS-449 or something else.)
* Provides limited power to local devices like keyboard/mice/modems
* Shieldable to reduce RFI (necessary for residential devices)
* Uses RS-423 signal levels (RS-232 compatible, and work at higher
data rates too)
* Compatible with RS-232-C and RS-423 signal levels and definitions
so that trivial converter cables can be made
* Connectors can be mounted directly on PC Boards (cheap for mfrs)
* Mounted connectors provide physical support for small devices
(e.g. cigar sized modem could plug right in with no cable).
Draft signal spec:
GND
TX Data
RX Data
I'm Here (DTR)
You're Here (DSR/CD)
TX Clock (synchronous modems and flow control)
RX Clock (synchronous modems and flow control)
+5V, fused and current-limited
Simple devices can use GND, TX, RX, maybe 5V. Modems can use I'm Here
(DTR) and You're Here (CD). If You're Here goes away, you drop the
connection (e.g. host logs people out; modem hangs up phone). I'm Here
should reflect software ready status (come on with carrier on phone;
come on after software has bootstrapped on host, goes off during crash
or power failure). If you need flow control or you are running
synchronous, the clock lines are used. If TX Clock is being driven
from outside, you use it as your transmitter clock; if the other side
needs to flow control you, it stops the clock or slows it down as
required. You do the same to the other side by slowing or stopping RX Clock
to alter the data flow on your RX Data line.
The simple devices and modems would be RS-232 compatible with just a
cable. Synchronous modems, ditto. Flow controlled RS-232 devices that
can use external clock could be adapted with a matchbox sized device
(powered from the connector). Differential TX/RX (AppleTalk, long
distance wiring, etc) ditto.
There should be no male/female connectors; any connector should
fit into any other one. Ideally you could plug it in with a 180 degree
rotation to cross the lines (I'm Here <-> You're Here and etc). That way
you can not only plug two devices together with a single cable, but you
can also extend the length by plugging N cables together -- and if it
doesn't work, twist any connector by 180 degrees and plug things back
together; now it should work. In other words, if you insert the plug
one way, you get straight-thru; the other way you get everything swapped.
For this there would have to be two pins of GND and two of power, but
that is probably a good idea anyway.
The SCSI-2 connector spec'd above does not have this property; it has
male and female versions. So even a 10-pin version of it would not be
worth writing a new standard for. We should try to interest connector
manufacturers in designing one that meets these criteria.
--
John Gilmore {sun,pacbell,uunet,pyramid}!hoptoad!gnu gnu@toad.com
"Watch me change my world..." -- Liquid Theatrecurt@dtix.dt.navy.mil (Welch) (09/18/89)
In article <8539@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >There should be no male/female connectors; any connector should >fit into any other one. Ideally you could plug it in with a 180 degree >rotation to cross the lines (I'm Here <-> You're Here and etc). That way >you can not only plug two devices together with a single cable, but you >can also extend the length by plugging N cables together -- and if it >doesn't work, twist any connector by 180 degrees and plug things back >together; now it should work. In other words, if you insert the plug >one way, you get straight-thru; the other way you get everything swapped. >For this there would have to be two pins of GND and two of power, but >that is probably a good idea anyway. If there was one type of connector with an equal number of male and female pins that could plug into itself, then you wouldn't need to twist it 180 degrees. All output signals would be connected to one gender, and all input signals would be connected to the other. There would only be one type of cable that could be used to connect any two devices together. It would cross connect the male pins from one end to the female pins on the other. With this type of cable, you could also plug multiple cables together to extend the length (still without needing to twist it 180 degrees). I've wanted RS-232 type devices to be wired like this for over 10 years. Curt Welch curt@dtix.dt.navy.mil
Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org (Geoffrey Welsh) (09/18/89)
> From: gnu@hoptoad.uucp (John Gilmore) > Message-ID: <8539@hoptoad.uucp> > The standards bogons are at it again. > > Following on the massive success of the RS-232-C standard (and its > followon RS-449 which basically nobody ever adopted), there is a > new alternative connector for RS-232-C circuits. Of course, it > has even more wires than the current one, though it is physically > smaller due to improved connector technology. In the hopes that levity is not taboo in this newsgroup, I present you with a proposed new serial communications standard: ===== DL-232 -- A New Standard by Dave Lyons (CompuCenter Iowa: JoeApple; CompuServe 72177,3233) I may never understand how the designers of the RS-232 "standard" for serial communication managed to use 25 wires where only 3 are really necessary. Maybe they made a deal with the companies that make cables, connectors, and switch boxes...I just don't know. Well, I thought of a few things that the RS-232 standard lacks, and since there are already so many extra signals, a few more can't hurt anybody, right? Heck, let's go for 50-pin connectors and cables and add the following new signals. (Just to make sure this isn't compatible with any old equipment, all OLD signals are moved up one pin number (Carrier Detect becomes 9 instead of 8, etc., and pin 25 goes to pin 1). Pin Name Description --- ---- ----------- 26 XCAT Should be connected to chassis of devices. Used with the next two signals, this provides protection against cats who haven't learned not to walk on floppy disks or serial equipment. This signal should supply about 2000 volts (at a VERY low current level; wouldn't want to HURT the cute little thing, just teach it not to walk on anything in the computer room). 27 CATGND Cat ground. Used with pin 26. This signal should be connected to another part of the chassis or the tabletop. 28 CTD Cat detect. 29 SD Self-destruct. This signals causes the device to destroy itself. 30 SDACK Self-destruct acknowledge. Acknowledges that the device has destroyed itself. 31 VADIC This signal indicates to a computer that the device on the other end is a modem that uses VADIC protocol. (Note: CompuCenter Iowa users should jumper this signal to SD and then buy a decent modem.) 32 STBIT1 Stutter bits. With pin 33, sets the number of "stutter bits" (0 to 3 of them) to be included before each byte transmitted. This may reduce the number of people who feel inferior to computer equipment by showing them that computers have problems communicating with each other. 33 STBIT2 34 CABR Cable ready. It's not enough to know that the Data Set is ready (DSR) and the Data Terminal is ready (DTR). We also need to know that the CABLE connecting them is ready. 35 GRR Gremlins ready. Not everybody knows it, but there are little green guys inside most modern computer equipment. Most of the time they sleep, but other times they cause trouble. The next 6 signals are for dealing with gremlins. 36 220A Used with pin 37, supplies 220 volt power for the gremlins' air conditioning. On hot days when gremlins can't sleep, applying power to these pins may solve your problems. 37 220B 38 110H 110 volts, hot side. When the 220 volt power doesn't help and gremlin problems persist, use this with pin 39 to supply 110 volts for the gremlins' TV and video game center. 39 110N 110 volts, neutral side. 40 MOON Indicates the phase of the moon. Sometimes solves mysterious problems. 41 LHI Pins 41 through 45 can be used to implement the "like" protocol when the normal RTS/CTS protocol isn't enough. This one means "Like HI" and is used to establish a connection. 42 LHTY2 Like HI to You Too. Acknowledges pin 41. 43 LLTT Like Listen To This. Requests permission to send data. 44 LOK Like OK. Grants permission to transmit data. 45 LWOW Like WOW. Acknowledges receipt of data. 46 HEY Pins 46 to 50 may be used to implement the "Eighties" protocol when RTS/CTS and "Like" protocols won't do the job. This signal is similar to RTS (Request to Send). 47 NP No Problem. Acknowledges HEY. 48 HUH? Signals that data was not received correctly (possibly wrong number of stutter bits). 49 YEAH Acknowledges data received. 50 KMG365 Like YEAH, but for avid Emergency One fans. That makes 50! Let's hear your suggestions for MORE serial signals. Maybe we can get 100 and REALLY make the cable manufacturers happy. -- Geoffrey Welsh - via FidoNet node 1:221/171 UUCP: {{uunet!}watmath!xenitec!}zswamp!171.0!Geoffrey.Welsh ARPA: Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org
news@bbn.COM (News system owner ID) (09/18/89)
John Gilmore writes:
< The standards bogons are at it again.
At least the ISO hasn't gotten involved yet (yea, 100 conductor serial
cables, what a GOOD idea! :-) )
< Draft goal spec of new connector:
< ...
<
< Draft signal spec:
<
< [1] GND
< [2] TX Data
< [3] RX Data
< [4] I'm Here (DTR)
< [5] You're Here (DSR/CD)
< [6] TX Clock (synchronous modems and flow control)
< [7] RX Clock (synchronous modems and flow control)
< [8] +5V, fused and current-limited
< ...
< There should be no male/female connectors; any connector should
< fit into any other one. Ideally you could plug it in with a 180 degree
< rotation to cross the lines (I'm Here <-> You're Here and etc). That way
< you can not only plug two devices together with a single cable, but you
< can also extend the length by plugging N cables together...
True wisdom.
Let's see. Number them like I did, then make a connector that has
something like this (from the perspective of the TX device
2 1 6 4 8 (TX side)
(8) 5 7 1 3 (RX (inverted) side)
Where the (8) is either used as a +5 load, or is not connected. Note
that the grounds and +5s run next to the transmit and recieve, to help
noise shield things.
A suggestion: The TX side should be female, the RX side male. This
looses the ability to flip and play, but wins in that there is no
possible way to hook it up wrong. I say female for TX so that there
is less change of shorting the +5 output by abusing pins.
In general, I like the mechanicals of the squeezed SCSI and SMD
cables; perhaps something like them, only not D shaped but rectangular
instead, and with clips and receptors on both sides, in some manner or
other.
One thing I would add is that the data rates must be capable of up to
at least 1.2 Mbps, maybe more, to be really useful for a number of
years to come (V.32 is, after all, 1/4 of the max. real RS323 speed
(actually, that's debatable).
-- Paul Placeway
<pplaceway@bbn.com>, <paul@cis.ohio-state.edu>sl@van-bc.UUCP (Stuart Lynne) (09/19/89)
In article <8539@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >The standards bogons are at it again. Looks good, but can we have hardware flow control? Please. }Draft signal spec: } } GND } TX Data } RX Data } I'm Here (DTR) } You're Here (DSR/CD) } TX Clock (synchronous modems and flow control) } RX Clock (synchronous modems and flow control) } +5V, fused and current-limited You can Send I can Send -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
edward@ucbarpa.Berkeley.EDU (Edward Wang) (09/19/89)
In article <8539@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >... If TX Clock is being driven >from outside, you use it as your transmitter clock; if the other side >needs to flow control you, it stops the clock or slows it down as >required. You do the same to the other side by slowing or stopping RX Clock >to alter the data flow on your RX Data line. Don't you get into round-trip-time problems with long wires and high data rates? Anyway, I think we should just forget this single-character transmission business. Packet protocols have so many advantages (error detection, etc.), and character-at-a-time IO is already so heavily penalized that we almost never have just one character to transmit. (Keyboard input is at such a low rate that it doesn't matter.) Short of that, it's a great idea to clean up rs232c.
wtm@neoucom.UUCP (Bill Mayhew) (09/20/89)
The recent articles about cobbling up a universal interface are pretty close to the midi specification used by manufacturers of electronic musical instruments and controllers. The midi specification uses 5 pin DIN connectors for everything. All devices have female connectors. All cables have male connectors on both ends. Every cable is essentially a null modem, with the leads cross-connected. Midi standardizes everything to the same baud rate too: ~31.5 Kbit/sec. I don't particularly like a rate that low, but... at least that isn't a worry. There are five leads: Txdat, Rxdat, Txclock, Rxclock, and ground. In theory, I suppose you could use a nonstandard baudrate and sync to the clock. As it stands now, the clock leads are optional. I think midi uses a low data rate because inexpensive optical isolators are used as line receivers. It's too bad that genderless connectors weren't desgined for midi, as there are many times I've wound up with two short midi cables when I actually wanted one long cable. The Atari ST series computers are supplied with a midi connector port as standard equipment. Not all uses are for music. There are several Atari games out that use the midi connector as a poor man's network for multi-machine play. It's too bad that we're still saddled with RS232-C that dates from about 1962. ...and I hate those 9-pin DE connectors on AT machines even more than 25 pin DB connectors! Bill
GPWRDCS@gp.govt.nz (Don Stokes, GPO) (09/20/89)
In article <8539@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > The standards bogons are at it again. > [etc on a replacement for dear old RS-232C] > Draft signal spec: > > GND > TX Data > RX Data > I'm Here (DTR) > You're Here (DSR/CD) > TX Clock (synchronous modems and flow control) > RX Clock (synchronous modems and flow control) > +5V, fused and current-limited I'd like to add my tuppence worth here, and suggest that such a device use an already existing connector, eg a DB9 (I have reservations about that particular example, due to the IBM AT usage for serial - I still haven't forgiven them for using DB25s on parallel ports). My reasons for saying this stem from experiences with the so-called DEC-423 cabling system introduced by Digital a couple of years ago. Technically, the scheme is quite good - uses 6core cables, with a modular jack, in a the pattern 1=DTR, 2=TD, 3,4=GND, 5=RD, 6=DSR. It works well - except that DEC seems to be the only place you can get connectors from. (Fortunately, converter plugs are available, which helps a little, and they haven't completely abandoned the DB25, which helps a lot.) One thing guaranteed to kill a standard dead is lack of availabilty of parts, particuarly something as mundane as cable connectors. When/if the standard is published, it has to be possible for a manufacturer to go out and and say "I want a thousand of these" from day one. Don Stokes ZL2TNM / / vuwcomp!windy!gpwd!don Systems Programmer /GP/ Government Printing Office PSI%0530147000028::DON __________________/ /__Wellington, New Zealand___________don@gp.govt.nz________ Blessed is the user who expects nothing, for he or she will not be disappointed.
klg@dukeac.UUCP (Kim Greer) (09/21/89)
In article <895.2515121C@zswamp.fidonet.org> Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org (Geoffrey Welsh) writes: > > In the hopes that levity is not taboo in this newsgroup, I present you with >a proposed new serial communications standard: I hope so too. This group has gotten a little boring lately. (pin-outs omitted here) >That makes 50! Let's hear your suggestions for MORE serial signals. >Maybe we can get 100 and REALLY make the cable manufacturers happy. > I would like to offer a few as well, mainly used at installation time: (Note: Must be accessed in sequence.) 51 DWIM Do What I Mean 52 DIRMI Dammit - I Really Mean It 53 COJSWP Commme Onnn - Just Start Working - PLEEEASE 54 TIYGTTC That's It - You're Going To The Cuisinart 55 SUWTTA Shut Up With The Tildes Already 56 MIGFUWU Modem, I'm Getting Fed Up With You 57 LMBIGTKM Look - My Boss Is Going To Kill Me 58 PYHVIJ Perhaps You Haff Velatives in Jerrrrmany ? 59 HISFW Hey ! Is It Finally Working ? 60 WYAGTUTMAA What ??!? You Aren't Going To Use The Modem, After All ?!?
njs@scifi.UUCP (Nicholas J. Simicich) (09/24/89)
In article <287@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >In article <8539@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >>The standards bogons are at it again. > >Looks good, but can we have hardware flow control? Please. > >}Draft signal spec: >} >} GND >} TX Data >} RX Data >} I'm Here (DTR) >} You're Here (DSR/CD) Um, er, I think this is a problem. DSR and CD are really two separate things. Let me try an example. The modem is on, but is not connected. Is it there? If it is connected, and on, I presume it is there. What if the connection drops. Is it there? But it really is there, just the connection dropped. How is this signaled? Unfortunately, after dealing with this crap for a while, I can't imagine that in band signaling of this condition would be a good idea. You need another lead, and this lead has no valid counterpart from the terminal side. I'd rather not give up ring indicate, either, but that is less important. >} TX Clock (synchronous modems and flow control) >} RX Clock (synchronous modems and flow control) >} +5V, fused and current-limited > You can Send > I can Send This is a good addition, in my opinion. Put it in the spec that XON/XOFF is illegal! -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)