Commtech's Fastcom Product Support Blog

04/27/2012 – LabVIEW

• Commtech is pleased to announce the initial release of our FSCC Family instrument driver for National Instrument’s LabVIEW.

Working with the motherboard manufacturer Gigabyte we have discovered an incompatibility between the SuperFSCC/4-PCI card and the onboard PCIe to PCI bridge chip (ITE IT8892E CXS).  I have been assured that the issue has been identified and will be applied to future motherboards manufactured by Gigabyte.  The manufacturer of the bridge chip, ITE, has released a new version of the chip that addresses these problems: ITE IT8892E EXS.

If you have an afflicted motherboard you may be able to contact Gigabyte support and get them to replace the chip for you.

I am trying to get more details from ITE about the cause of the failure.

I have recently had reason to do some power measurements on the SuperFSCC/104+ RS422 card.  Here are my results.

• 2 ports set to RS422, idling 1′s: 400mA
• 1port set to RS422, 1 port RS485, idling 1′s: 300mA
• 2 ports set to RS485, idling: 200mA
• 2 ports set to RS422, transmitting and receiving random data @ 1Mbps on both ports: ~450mA

I have messed around with the settings a bit and I don’t see any big changes in the power consumption.  I feel pretty good saying that maximum operational power draw of the card is 500mA.

I may have missed posting a few software updates here and there, so here is a bit of a rollup:

09/21/2011 – Lnux_v1

• Add fc-async module to the async code and removed the bits about patching  the kernel for 2.6 and up.

09/15/2011 – Linux_v2

• Fix build errors caused by new kernel requirements. init_MUTEX(x) removed in 2.6.37

09/14/2011 – Linux_v1

• Fix build warnings and errors caused by new kernel requirements.  This   has been tested to build up to kernel 3.0

07/11/2011 – Windows

• Modify behavior of Isosync mode to prevent system hang when large number of   interrupts occur on a modem control line.  Please enable Isosync mode as boot  default, then reboot before connecting external clock signal.

05/19/2011 – Windows

• Driver version 1.0.0.94 – basically just a recompile to fix some previous build errors  Including update fscc_basic_settings with tooltips and new boards recognized  Signing all drivers

03/14/2011 – Windows

• Had to update the fscc.cat file to allow installation in win7-64

fscc_2011_09_21

Version 2.1.2 (09/14/2011)

• Fix build error with kernels 2.6.37 and up
• Fix problem with SuperFSCC/4-LVDS installation
• See changesets for full list of changes

http://hg.commtech-fastcom.com/fscc-linux/downloads

Version 2.1.0 (05/02/2011)

• Fix comments in code
• Add make help target
• Migrate from google code to bitbucket
• Added code and examples for various transmit modes
• Fixed dma insmod parameter
• Add SuperFSCC-LVDS and SuperFSCC/104 to the driver
• See changesets for full list of changes

http://hg.commtech-fastcom.com/fscc-linux/downloads

• FSCC Family = Base FCore version 9.0B
• SuperFSCC Family = Base FCore version 4.16

Fix XREP with TXT. Keeps the frame from restarting immediately when XREP and TXT are both set.

I just found a tool online that will calculate the programming data for an ICS307-02 clock generator that is used on our Async335 cards as well as the ESCC-PCI-335.

http://www.idt.com/?app=calculators&device=307_02

The input frequency is always 18.432MHz.
Desired output frequency is what you are trying to get.
Allowable Output Frequency Accuracy: Lower is better
Clock 2 output: Off
Output Driver: CMOS
Crystal Load Capacitance: 00
Allowable Duty Cycle Range: 45-55
Operating Temperature: -40 to 85 C

We have officially released a 2.x driver for our FSCC series of cards using Linux.

This release is a departure from the 1.x series most of you are used to. We have broken API compatibility with the hopes of creating a new driver platform designed to use current kernel practices and ease as many complaints as we can from the old series.

If you already have an application designed to use the 1.x series of drivers you don’t have to make the switch. If you haven’t yet started application development we recommend using the new series. While compatibility has been broken it is very similar to the 1.x series of FSCC drivers so users of the old series should have no problem picking up the new driver.

If you would like to get started using this new driver start by download the driver from the following link then following the README file included.

http://code.google.com/p/fscc-linux/

http://hg.commtech-fastcom.com/fscc-linux

Considering this is a new driver if you find any issues or have any recommendations please let us know. Any information you can give us will help our entire user base.

01/05/2011

• Update writereg example program.  It was incorrectly checking the return variable of deviceIoControl() for information.  This will resolve any issues that you may see with IOCTL_FSCCDRV_WRITE_REGISTER saying that it failed when it really passed.
• Fix line endings on Visual Studio project files and .txt files on the CD

12/29/2010

• New linux code that will fix build errors on newer kernels.

fscc_2011_01_06

Sometimes ‘setserial’ can memorize serial port configuration without requesting whether you would like this to happen. This can cause difficult to determine bugs when switching between serial cards. One way of determining if this is happening to you is by taking a look at the setserial output to see if there are more ports listed than the number of ports in your computer.

Here is a sample ‘setserial’ output showing this situation. I had 2-port card in the computer then replaced it later with a 4-port card. It memorized the configuration of the 2-port card and stored it’s configuration values at /dev/ttyS[4-5] upon reboot. So if you load up your program that uses /dev/ttyS4 expecting to use the first port of your new 4-port card it will not work.

asyncpci335_2010_09_23.zip

esccp335_2010_09_23.zip

08/19/2010 – Windows

• Add installer to the Windows 7 32-bit driver.
• Added in the Windows 7 (64 bit) driver with installer.
• Added SET_PROGBITS and GET_PROGBITS and associated example programs
• Modified Sync driver to remove an errant DbgPrint that was causing some BSOD on some customers’ systems.

- Linux

• Add most recent driver that includes the bridged PCIe boards

fscc_2010_09_23.zip

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.

Download here: fscc_2010_04_02

03/17/2010 – Windows

• Modified Sync driver’s WRITE_REGISTER IOCTL calls and all example program that called them. The driver was returning a value that was 2*sizeof(ULONG) and the example programs were only expecting to get a single ULONG back, so it was overflowing some variables sometimes. Changed driver to return nothing and the examples to expect nothing.  Thanks Joseph.

fscc_2010_03_17

fscc_2010_03_12

fscc_2010_02_02.zip

asyncpci_2010_02_02.zip