Commtech's Fastcom Product Support Blog

I get a lot of questions about how far an RS-422 signal can go or how fast can an RS-422 signal be driven.  Unfortunately the answer is not exactly cut and dry.  This is an exerpt from the RS-422 specification (TIA/EIA-422-B).

The maximum permissible length of cable separating the generator and the load is a function of data signaling rate and is influenced by the tolerable signal distortion, the amount of longitudinally coupled noise and ground potential differences introduced between the generator and the load circuit commons as well as by cable balance.   Increasing the physical separation and the interconnecting cable length between the generator and the load interface points increases exposure to common mode noise, signal distortion, and the effects of cable imbalance.  Accordingly, users are advised to restrict cable length to a minimum, consistent with the generator-load physical separation requirements.

The curve of cable length versus data signaling rate given in figure A.1 may be used as a conservative guide. This curve is based upon empirical data using a 24 AWG, copper conductor, unshielded twisted-pair telephone cable with a shunt capacitance of 52.5 pF/meter (16 pF/foot) terminated in a 100 Ohm resistive load.  The cable length restriction shown by the curve is based upon assumed load signal quality requirements of:

a. Signal rise and fall times equal to or less than, one-half unit interval at the applicable data switching rate.

b. A maximum voltage loss between generator and load of 66%

At the higher data signaling rates (90 kbit/s to 10 Mbit/s), the sloping portion of the curve shows the cable length limitation established by the assumed signal rise and fall time requirements.  As the data signaling rate is reduced below 90 kbit/s, the cable length has been limited at 1200 meters (4000 feet) by the assumed maximum allowable 66% signal loss.

When generators are supplying symmetrical signals to clock leads, the period of the clock, rather than the unit interval of the clock waveform, shall be used to determine the maximum cable lengths (e.g., though the clock rate is twice the data rate, the same maximum cable length limits apply).

The user is cautioned that the curve given in figure A.1 does not account for cable imbalance, or common mode noise beyond the limits specified that may be introduced between the generator and the load by exceptionally long cables.

On the other hand, while signal quality degradation within the bounds of figure A.1 will ensure a zero crossing ambiguity of less than 0.5 unit interval, many applications can tolerate greater timing and amplitude distortion.  Thus, correspondingly greater cable length may be employed than those indicated.  Experience has shown that, in most practical cases, the operating distance at lower data rates signaling rates may be extended to several kilometers.

Cables having characteristics different from the twisted pair 24 AWG, 52.5 pF/meter (16 pF/foot), can also be employed within in bounds of figure A.1.  First, determine the absolute loop resistance and capacitance values of the typical 24 AWG cable provided by the cable length associated with the data signaling rate desired from figure A.1.  Then convert those values to equivalent lengths of the cable actually used.  For example, longer distances would be possible when using 19 AWG, while shorter distances would be necessary for 28 AWG.

The type and length of the cable used must be capable of maintaining the necessary signal quality needed for the particular application. Furthermore, the cable balance must be such as to maintain acceptable crosstalk levels, both generated and received.

It has come to my attention that some (maybe not all) Linux kernels of the vintage 2.6.27 (specifically Ubuntu 8.10) and later will cause the SuperFastcom driver to seg fault upon being loaded with an insmod.  Apparently someone decided that the DSCC4 kernel module is associated with the PEB20534 serial controller’s PCI device ID and therefore would be the correct driver to load when that PCI device ID is detected.  This would be incorrect.

To get around this problem, you will need to add the DSCC4 and hdlc modules to modprobe’s blacklist so that they do not automatically get loaded.  Edit the file /etc/modprobe.d/blacklist and add these two lines to it somewhere:

blacklist dscc4

blacklist hdlc

Reboot your PC and verify that these two modules are no longer with an lsmod.  You will now be able to correctly insmod the SuperFastcom’s superfc.ko kernel module and use the card as intended.

If anyone knows how to get them to NOT load these modules by default, let me know and I’ll see what I can do.

This new software release includes these new features:

• 01/07/2008 – Linux
  -updated with mods for 10 board install on centos
  -update pty to allow flush on devnode (without exiting)
  - modify driver to handle xdu as flush, update so 2.4 threading operates
• 05/07/2008 – Linux:
  -Fixed up various PCI nasties to make the driver compile in kernels at around 2.6.24

This new driver can be found here: superfastcom_2008_05_07.zip