



04/27/2012 – 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.
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
09/15/2011 – Linux_v2
09/14/2011 – Linux_v1
07/11/2011 – Windows
05/19/2011 – Windows
03/14/2011 – Windows




Version 2.1.2 (09/14/2011)
http://hg.commtech-fastcom.com/fscc-linux/downloads




Version 2.1.0 (05/02/2011)




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
12/29/2010




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.












08/19/2010 – Windows
- Linux




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














More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 