FarSync FAQ Test

V.35 transmit and receive clocks are output on the Y-AA and V-X V.35 connector pins.

The degree of support for internal clocking varies by adapter type and is as shown below:

Note: some special cable types allow a port to be run in X.21 mode but present the signals on a V.35 connector, this can overcome the limitation where V.35 internal clocking is not provided. For example, a UX35C cable converts between HD26-M (X.21) and MRAC34-F (V.35) and presents a DCE-configured interface.
Click here for more details on the UX35C cable.

The Interface Types supported are dependent on the adapter type as shown below:

* these products can support a subset of the RS530 interface when used with special cables, e.g. the U530 cable for TxU(e).

¹ T4E+ hardware is RS485-capable, but at the time of writing there is no onboard or driver support for this, software support for RS485 will be introduced at a later date, contact FarSite for details.

X.21 interfaces normally provide a Signal Element Timing function (clock) to synchronize data transfer between DTE and DCE. When running at high speed or with long cables, use of a single clock can present problems. This is because the round-trip delay for the clock from DCE to DTE plus the data from DTE to DCE becomes significant compared to the period of the clock. The preferred solution to this problem, which is available on all adapters, is to use the Invert Rx Clock feature.

An alternate approach, available on some adapters, is to use X.21 Dual Clocking. In this mode clock is sent with the data in each direction, so there is no longer a problem with the round-trip delay. In order to use this feature the X.21 Indicate signal has to be relinquished for use as the second clock; the second clock is always an input.

In order to use Dual Clocking mode when connecting a pair of FarSync devices together, a special X.21 Dual null-modem cable is required. This special null-modem cable differs from the standard one in that it requires Sa-Ia and Sb-Ib connections in each direction. Each end of the link needs to be configured for Internal Clocking as well as X21D Interface Mode.

FM0, FM1 NRZI, Manchester & Conditioned Diphase encoding schemes allow clocking information to be embedded in the transmitted serial bit stream. This eliminates the requirement for a separate clock to be provided with the data, as the clock can be recovered from the encoded data.

Support for various encoding schemes by card type is shown below:

*Requires latest hardware and drivers – earlier Manchester-only builds can be updated if required, contact FarSite for details.

FM0 Coding is also known as Biphase-S(pace).
FM1 Coding is also known as Biphase-M(ark).
Manchester Coding is also known as Biphase-L(evel). FarSite products support the G.E. Thomas variant, the IEEE variant is simply the inversion of G.E. Thomas.
Conditioned DiPhase is also known as Differential Biphase-L(evel) or Differential Manchester coding.

When the FarSync M1P is running in FM0, FM1 or NRZI mode a limited range of rates above 512kbps are supported these are: 768K and 1536K.
The FarSync T4Ee, T4E+ and T2Ee are capable of sending and receiving encoded data at rates from 1200bps to 10Mbps.
See the FarSync Flex FAQ for the clock speeds supported by the various Encodings.

When connecting two such FarSync products together, there are two ways of configuring the clock.

The first method  of configuring the clocks (recommended), is to select internal clocking at both ends. In this mode the internal oscillator of each adapter is used to drive the transmitter, with the receiver phase-locked-loop recovering the clock from the data in each case. When running in this mode there will be some small difference in the data rates in each direction due to local oscillator tolerances.

An alternate method of configuring the clocks it to set one end internal and the other external. When running in FM0, FM1, NRZI, Manchester or Conditioned Diphase modes the internal end runs from the adapters local oscillator, the external end runs in a slave clocking mode where the recovered received clock is used to transmit data back to the originating device. This ensures all data is timed to the one clock source, but can result in more jitter in the data transmitted by the external end which can cause problems recovering data at higher speeds.

Although some clocking information is included in the NRZI bit stream, it may be inadequate to allow for reliable clock recovery. For this reason an optional separate one times clock can be provided with the NRZI encoded data, for improved reliability.

Whether Asynchronous Data is supported is dependent on the adapter type as shown below:

*Flex hardware is asynchronous capable, earlier synchronous-only builds can be updated if required, contact FarSite for details.

The UCX35C cable is useful in V.35 applications where the FarSync adapter is required to source clocking, but does not fully support the generation of clocking. The UX35C achieves this by running the adapter in X.21 mode (which does support generation of clocking) and converting this to a V.35 (DCE configured) interface.

The UX35C cable passes data and clocks straight through but loops control signals at the HD26-M (X.21) and MRAC34-F (V.35) connectors. Control is looped to Indicate on the X.21 side; RTS is looped to CTS and DTR is looped to DCD and DSR on the V.35 side. The single X.21 clock drives both transmit and receive clock to the V.35 interface.

Products such as T2P, T4P, T1U, T2U and T4U can use the UX35C cable; the cable attaches directly to a T1U or T2U, connects to a T2P via a MTU2 cable and connects to a T4P or T4U via a MTU4 cable.

The UX35C cable cannot be used with the M1P.

FarSync T2U-PMC, T2Ee, T4E, T4Ee, T4E+ and Flex do not require the UX35C as they fully support internal V.35 clocking.

The U530 cable is useful in applications where a FarSync adapter that does not natively support RS530 needs to be connected to a RS530 system. The U530 achieves this by running the adapter in X.21 mode and converting this to a DB25 RS530 (DTE configured) interface.

The U530 provides balanced TxD, RxD, RTS, CTS & TxC. Since only a single clock is provided on the interface, the attached device must guarantee phase and frequency locked transmit and receive clock. Please refer to the U530 cable diagram to determine signalling compatibility with a particular application.

Products such as T2P, T4P, T1U, T2U, T4U, T2Ue and T4Ue can use the U530 cable; the cable attaches directly to a T1U, T2U or T2Ue, connects to a T2P via a MTU2 cable and connects to a T4P, T4U or T4Ue via a MTU4 cable.

The U530 cable cannot be used with the M1P. For M1P, use a P530 or Q530 cable instead.

FarSync T2U-PMC, T2Ee, T4E, T4Ee, T4E+ and Flex do not require the U530 as they fully support RS530.

The Internal Clock Rates (Clocks generated by the adapter) supported are dependent on the adapter type as shown below:

T2Ue, T2U-PMC, T2Ee, T4E, T4Ee and T4E+ support a large number of clock speeds. Supported rates vary according to Slave/Master configuration. The Master clock is the internally generated clock operating independently on each port.

The T4E+ operating in Manchester Encoding, Conditioned Di-phase, FM0 or FM1 signalling modes (clock extracted from the data) can support all the speeds in the table below from 2,400 bps onwards. The T2Ee and T4Ee supports these modes from 100 bps upwards.

The Slave Clock is an external reference clock sourced from one of the cards ports (A – D). The other ports (A – D) or CT Bus may be phase locked to this reference (see below for table of permitted speeds).

Note: Listed rates are those supported by latest driver/firmware, older versions support a subset of these.

For FarSync Flex clock rates see FarSync Flex FAQ.

Note: Listed rates are those supported by latest driver/firmware, older versions support a subset of these.

There are several configuration parameters that can affect the behaviour of the of transmit and receive processing. These parameters relate to configuration of the resources on the FarSync card/device itself. In the case of both Linux and Windows, these parameters can be configured using either the supplied configuration utilities or programmatically (e.g. by an application that you develop). For details of the configuration mechanisms available please refer to the OS-specific FarSync product documentation.

• Number of Transmit Buffers (on the FarSync card/device) – This can be one of the following values: 1, 2, 4, 8, 16, 32, 64 or 128
• Number of Receive Buffers (on the FarSync card/device) – This can be one of the following values: 1, 2, 4, 8, 16, 32, 64 or 128
• Transmit Buffer Size – This defines the size of each of the transmit buffers on the card/device. The buffer size can be any value from 1 to 32k-1. Note that, as described below, there are limitations on the number/size combination. Also note that for the FarSync Flex this value is limited to the range 4, 8, 16 and Nx32 when running in transparent mode.
• Receive Buffer Size – This defines the size of each of the receive buffers on the card/device. The buffer size can be any value from 1 to 32k-1. Note that, as described below, there are limitations on the number/size combination. Also note that for the FarSync Flex this value is limited to the range 4, 8, 16 and Nx32 when running in transparent mode.

Buffer Size Considerations:
When configuring the number of buffers and their size, there are several considerations to keep in mind:

• Maximum Buffer Space – The maximum buffer space per port per direction is 64K, the largest buffer size permissible is 32K-1 and the maximum number of buffers possible is 128.  The following table show the maximum buffer size that may be selected for a given number of buffers.
  

  FAQs - FarSync - Max buffer size

  Number of Buffers	Max Buffer Size (Kb)
  1	32-1
  2	32-1
  4	16
  8	8
  16	4
  32	2
  64	1
  128	0.5

• Keeping the Transmitter Busy – In most real time applications, it will be a prime consideration to keep the transmitter busy for as much of the time as possible. Therefore the application will want to use at least two transmit buffers, so the next buffer can be loaded while the current buffer is currently being transmitted. From the table above, this would limit the maximum frame size that could be handled to 32K-1. Similarly, if you have many small buffers, the rate of transmit completions may be greater than the rate at which your application can transfer buffers to the driver. This could lead to periods of time where the transmitter may be idle.
• Receive Buffer Overruns – If your application has to receive many small frames at a high line rate, then you may need to change the default configuration to increase the number of receive buffers, or there is a risk that some of the received frames could be lost. The port statistics should indicate if this condition may be occurring. If you are seeing these receive errors it will be necessary to increase the number of buffers. This may also mean that you need to reduce the buffer size. For example, you may change the default setting to 16 buffers of 4096 bytes, or 32 buffers of 2048 bytes. Please refer to the OS-specific FarSync product documentation for details of how to view the port’s statistics etc.
• Transparent Mode – In transparent mode similar considerations apply. In this mode the application will always receive data in full receive buffers. Although it is not always necessary to fill the transmit buffers, if the application is required for maintaining the transmit bit stream, then it is important to make sure that there is always a buffer ready for transmitting while the card is transmitting the current buffer. If the application does not read the data fast enough, then the card will signal receive buffer overruns. If the application doesn’t provide data fast enough to the driver then this will cause a “Transmit Unavailable” indication from the card. This is not necessarily an error, it depends on whether it is a requirement or not for the application to maintain a continuous bit stream and transmit “idle” patterns when there is no real “user” data. Therefore, any error recovery from this condition would depend on the characteristics of the transmit bit stream.

The maximum recommended speed for each interface type is as follows:

Where a particular FarSync device supports termination, enabling this feature will offer improved performance at higher speeds by reducing crosstalk and signal reflections.

¹ RS232 synchronous rates of 128kbps or more are possible by using encoded data or by using terminal timing with NRZ (where available) or by the appropriate use of receive clock inversion where terminal timing is not available.

² Synchronous rates of up to 10Mbps are supported by using encoded data or by using terminal timing with NRZ (where available) or by the appropriate use of receive clock inversion where terminal timing is not available.

See FarSync Flex FAQ

There is a known problem that when using Windows 7 and you have updated your drivers to Version 6.2.7, or if you have installed a fresh copy of Version 6.2.7, that the device no longer works.  If Device Manager reports an issue with the driver saying that it “cannot verify the digital signature for the drivers required for this device”, then the issue is that the version of Windows 7 that you have does not have the Windows Update installed that support SHA2.  Please install Windows Update KB3033929 to resolve this issue.

Version 6.2.7 of the Windows drivers was the first version to use SHA2 digital signatures.

The solution to this problem is to press No, then turn on the .NET Framework 3.5 as follows:

View FAQ PDF

If this error occurs when insmod is trying to insert a module, such as the error below, then this is normally due SELinux:

To check SELinux status:

$ sestatus

SELinux is enabled and set to enforcing

Set SELinux to permissive:

sudo setenforce permissive

Start farsync again

sudo /etc/init.d/farsync start

We get a warning that the FarSync driver is still loaded, but the Permission denied error is no longer displayed.

Try stopping and starting farsync a few more times, just to make sure:

Definitely looks like a SELinux issue, we can either:

1. Leave SELinux in permissive mode, in which case we need to make sure the permissive setting is carried across reboots by editing the /etc/selinux/config file and setting SELINUX=permissive.
2. Set SELinux back to enforcing and add a custom policy module, which can either be done manually or via a script. The sample script below demonstrates creating a custom policy module and loading the newly created policy module.

   View Sample Script