Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!SEKA.SCC.COM!enger
From: enger@SEKA.SCC.COM (Robert M. Enger)
Newsgroups: comp.sys.proteon
Subject: 4-into-6 coding, and the "clasic" pronet-80 problem
Message-ID: <9003181948.AA03200@seka.scc.com>
Date: 18 Mar 90 19:48:51 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32

Folks:

As many of you unfortunately know, Pronet-80 boards can exhibit
a sensitivity to the contents of the frames they are asked
to convey.   33hex is always specified as one of the data
types that annoys the Pronet-80 boards.  

Does anyone know what 33Hex maps into under the 
4-into-6 coding used by Proteon?  Is 33hex the
worst case test for the Pronet-80 given the
4-into-6 mapping they use?  If not, is there
a more sensitive test that we can use to detect when our
boards are on their way to the great repair-depot in the sky?

Can anyone offer a technical explanation of the situation?
Is it that the "rf" (120mbps) stages become miss-tuned,
causing waveform deformation beyond the ability of the
receivers to acurately "demodulate" (loose terminology)
the signal?  Why is their design so sensitive?  These
boards keep going bad.  Are the drivers (amplifiers)
too weak to fight the cable capacitance or something?

Has anyone found a way to "help" the situation?
Perhaps a way to appease the deficiency of the design
(or whatever the problem is) by using lower-capacitance
cabling, or cabling with a different characteristic
impedence, etc??

Thanks for any insight anyone has to offer,
Bob Enger
Contel Federal Systems
enger@seka.scc.com