Newsgroups: comp.dcom.sys.cisco
Path: utzoo!utgpu!cunews!bnrgate!bwdls61!bwdls56!fortinp
From: fortinp@bwdls56.bnr.ca (Pierre Fortin)
Subject: Re: Appliques can fail .....
Message-ID: <1991Mar3.225534.6358@bwdls61.bnr.ca>
Sender: usenet@bwdls61.bnr.ca (Use Net)
Organization: Bell-Northern Research, Ottawa, Canada
References: <32744@boulder.Colorado.EDU>
Date: Sun, 3 Mar 1991 22:55:34 GMT

In article <32744@boulder.Colorado.EDU>, bmar@cac.washington.edu (Bill Mar) writes:
>
> We had similar symptoms while evaluating the new Codex 3500 56k DSUs on
> a production circuit between two cisco routers.  Problem was resolved by
> replacing the V.35 applique with a later vrs 6.  Apparently vrs 4 and 5
> incorrectly inverted some of the data and/or clock lines, which was
> corrected in vrs 6.  The symptoms do not neccessarily show up
> immediately, because four pairs of different vendor/model DSUs tested
> fine on this circuit.  When the 3500s were tried, they BERT'd the
> circuit ok, PING'd locally ok, but could not PING across the link. 
> Codex concludes the 3500 is designed to enforce industry standard data
> and clock phase relation, while the older DSUs allowed out of spec phase
> and the frequently less than desirable results. 

I too spent *MANY* long hours working this problem about 20 months ago; I
posted a number of replies in the past...

In your reply, you are quite correct in stating that the problem is fixed in 
the R6 appliques.  The problem was with inverted clock pairs.  Let's see if
I can summarize quickly:
 
    R3:  inverted clocks
    R3+: (+ means jumpers and trace cuts) some boards were improperly
         modified (QA problem)
    R4+: cisco forgot to tell the manufacturer to *stop* applying the mods...
         result: undid the etched fix.
    R4:  I don't recall if this one was completely OK (all these months and
         a week in the Mexican sun... :^)
    R6:  OK, although I would have made one more minor change; I agreed with
         cisco at that time that this last one was a cosmetic nit.

The reason that some units _appear_ to work is related to either their
signal rise/fall times (worse as slope gets longer), or the data/clock
relationship (measured in nanoseconds).  The bottom line here is that the
data lines were changing at the *same* time as the data was being clocked
into the modems.  The problem was always on the sending end.

If you are having these problems, you might try the following:
    - use a breakout box or
    - make a special cable to
    
      - invert SCT or
      - invert SCTE or
      - invert both
 
Another problem area is the cable type you use between the applique and 
modem.  We eventually designed our own cable since most generally available 
cables will not work properly (loss and crosstalk) over more than a couple
of meters.  We tested our design to 70feet, but order only 35- and 50-foot
units.

> 
> Bill Mar
> Univ of Wash
> Seattle, WA

Cheers,
Pierre

P.S.:  If anyone kept copies of my original postings, please repost them
       (or email to me at fortinp@bnr.ca).  I suppose we should have written
       a book on V.35 back then...  Looking back, it would have been salt in
       our wounds...  :^)

Cheers,                      
Pierre Fortin       fortinp@bnr.ca         (613)763-2598