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.

This software update includes:

Windows:

Updates to merge code changes to fix various Serocco issues,

Added wait for CEC after flush to prevent data loss on a write immediatly following a flushtx

Download the new software package here: gscc_2008_05_07.zip

This release includes the drivers for Windows and Linux that address the issue from this post.

You can get it here.

The Fimrware on the GSCC card has been updated to fix an issue with the PCI interrupt line.  The PCI interrupt line on Fastcom:GSCC boards prior to REV03 will be asserted during the time between power on and SEROCCO configuration.  This will lead to an apparent system lock on single CPU machines if the interrupt is shared with another device, and that device is enabled/active.  The asserted interrupt will continuously interrupt the system falling through the shared driver (which correctly does not claim it).

The Firmware fix adds a bit to the board features register space that masks all outbound PCI interrupts from the Fastcom:GSCC card.  (BAR1:Offset 4:bit0)  If this bit is a ’1′ then no interrupts will be generated from the GSCC card.  If this bit is a ’0′ then the board will interrupt as necessary.  The poweron default for this bit is ’1′ (interrupts disabled).  You must now write to BAR1+4 with a 0×00 in order to properly use this card.  This change effects all drivers (linux/windows/dos) and requires a driver update to use the new board/firmware.

A customer has reported and we have verified that this problem exists.  Apparently when you turn on inter-frame time fill = flags (CCR2H:ITF=1) something gets fouled up in the transmitter and an extra flag somehow gets stuffed onto the beginning of your frame.

The rest of the data in the frame is still valid, but there is an extra 7E at the beginning.  The CRC that is calculated by the transmitter is correct, so when the receiver calculates and checks the incoming frame’s CRC, it will fail.  The receiver is including the extra 7E in the CRC calculation and the transmitter did not.  This could be one way of detecting this condition.

Unfortunately it does occur on every transmit.  It seems to be more along the lines of every 10th transmit.

It seems completely independent of baud rate or size of frame or frequency of frames.  It just happens whenever ITF=1.

A possible solution might be to disable ITF and enable preamble transmission, set the preamble byte to 0x7E and set the number of repetitions to 8.  This will hopefully allow the receiving device synchronize correctly to “flags” without idling flags.

A customer has reported and we have verified that this problem exists.  Apparently when you turn on inter-frame time fill = flags (CCR2H:ITF=1) something gets fouled up in the transmitter and an extra flag somehow gets stuffed onto the beginning of your frame.

The rest of the data in the frame is still valid, but there is an extra 7E at the beginning.  The CRC that is calculated by the transmitter is correct, so when the receiver calculates and checks the incoming frame’s CRC, it will fail.  The receiver is including the extra 7E in the CRC calculation and the transmitter did not.  This could be one way of detecting this condition.

Unfortunately it does occur on every transmit.  It seems to be more along the lines of every 10th transmit.

It seems completely independent of baud rate or size of frame or frequency of frames.  It just happens whenever ITF=1.

A possible solution might be to disable ITF and enable preamble transmission, set the preamble byte to 0x7E and set the number of repetitions to 8.  This will hopefully allow the receiving device synchronize correctly to “flags” without idling flags.

It has come to our attention that the GSCC controller chip (the Serocco PEB20532) has slightly different behavior than its predecessors in Extended Transparent Mode. In the past, in order to enable transparent reception one was supposed to reset the receiver active bit (RAC=0). We had incorrectly assumed this was still true. The Serocco chip actually requires that RAC=1 for transparent reception. Who knew?