Path: utzoo!mnetor!perle!jeff
From: jeff@perle.UUCP (Jeff Cole)
Newsgroups: comp.dcom.lans
Subject: Re: RS232 cable
Message-ID: <267@perle.UUCP>
Date: 6 Nov 90 22:55:38 GMT
References: <2404@gould.doc.ic.ac.uk> <789@sci34hub.UUCP>
Reply-To: jeff@perle.UUCP (Jeff Cole)
Organization: Perle Systems Limited  Scarborough, Ontario, Canada
Lines: 46

In article <789@sci34hub.UUCP> gary@sci34hub.sci.com (Gary Heston) writes:
>
>From the EIA RS232C spec, page 8, paragraph 3.1:
>
>" ... The use of short cables (each less than approximately 50 feet or 
>15 meters) is recommended; however, longer cables are permissible, 
>provided that the resulting load capacitance (CL of Fig. 2.1), 
>measured at the interface point and including the signal terminator,
>does not exceed 2500 picofarads. ... "
>

Using the current rev. of the specification, EIA RS-232D, ( 1986 !! ),

 Page 11, paragraph 3.1 : 

    "The maximum accceptable length of cables ( particularly the
    extension cable) is not defined.  It is determined by the 
    electrical requirement in Section 2.1.4".

Sec. 2.1.4 basically says 2500 picofarads, among other considerations.


This is really part of the issue of cabling LANs  ( and I use the term
loosely with respect to RS-232) in general, in which 
hard and fast rules are not possible to pin down, except under such 
conservative conditions that practically everybody would ignore them,
because the system would "work" under less severe circumstances.

Rules of thumb ( often disguised as "Site Planning and Preparation"
documents ) are about the best that can be done.  Individual sites will
vary in terms of the cable type, length of runs, ambient noise levels,
etc.  This variation in site characteristics leads to variation in 
bit error rates for sites which aggressively cable.  ( i.e. push the
guidelines ).  Eventually some sites will cable themselves in such a way
as to cause operational problems.  

Good network management tools will help customers identify these problems,
especially the ones that are not visible  ( e.g. the network that loses 
one third of its packets, but can still run due to upper layer recovery
mechanisms, at a significantly reduce throughput ).

-- 
Jeff Cole                                     370 Tapscott Rd.
Perle Systems Limited                         Scarborough, Ont.
UUCP: ...!uunet!mnetor!perle!jeff             Canada   M1B 3C4
( some ramblings about my opinions vs. company policy etc., etc. )