Digital I/O

Showing results for 
Search instead for 
Did you mean: 

I need to develop a 1MHz bit-rate tester - which card should I use?

Hi there,
I need to develop a bit error rate tester for a device by continually streaming data into the it at 1MHz and at the same time monitoring the output of the device
and checking for bit errors against that which I have put into it. As of yet I am unsure of the time delay between input and output data. 
Also, I need to be able to vary the sampling point on the bits coming out of the device and vary the frequency slightly (900kHz - 1.1MHz) on the data going into the device.
Does anyone know what PCI card(s) would suit me best?
Many thanks
0 Kudos
Message 1 of 10

Hi There,

      There are a number of NI cards that could fit this application. I guess a number of questons spring to mind.......

1. What data type do you need to generate / receive? ( TTL, LVDS, etc.)

2. Is the data serial or parallel and how many bits?

3. Does the DUT generate a clock signal output as well as the data output?

4. Do you need to change the generation frequency on the fly or is a short stop in generation acceptable?

    If you can provide this information we can then work on the best solution for your application.


0 Kudos
Message 2 of 10

Hi there,

Many thanks for your reply

The voltage levels are TTL.

The data to be sent and received is just a one wire serial pulse train without any clocking of the data in/out. However i'm guessing that I will need to use an external clock to help sample the waveform.

The frequency doesn't have to be changed on the fly. It can be set then started.

The format of the data to be sent/received is undecided and may depend on the method of generation/receive that is used.  The bits however cannot be more than 3 of the same logic level in a row.

How the received data is triggered is an essential part of the process I presume as at the moment I am unsure of the DUT in/out timedelay and there is no clock to sync with.

Is that more helpful?

0 Kudos
Message 3 of 10

Hi Again,

     This is most helpful. OK TTL is something that a lot of NI cards will do so that bit is fine. Serial data with no clock can present some problems. The generation of data is essentially easy as you just set the internal clock frequency of the generator card to the desired output data rate and away you go. The DUT will normally handle this kind of data stream by the use of a clock recovery circuit which recovers the clock rate from the data received. This is likely to be how your DUT will work and this is kind of backed up by the fact that you cannot have more than 3 bits at the same logic level in a row, otherwise the clock recovery circuit produces the wrong clock frequency. Now this is where the problems can come in, NI's products do not have clock recovery circuits built in so they will be unable to deal with the data receive side of your testing without some sort of external clock recovery circuit to provide an external clock to the receiving board unless the DUT output data is clocked at the same rate as the DUT input data. If the DUT output data rate is the same as the DUT Input data rate you can use the internal board clock that was used for generation and perform a "trigger when pattern matched" acquisition. If the DUT output data rate is different then you can replicate the DUT clock recovery circuit on some breadboard and use it to provide an external clock. Now to the boards: If the DUT Input / Output data rates are the same (albeit with a delay) you could use a single PCI-6541 or PCI-6551, if the data rates are different you will need two boards, one for TX one for RX. I suggest these boards because they are the only boards capable of fulfilling your requirement to vary the sample point of the bits coming out of the device.


Hope this helps,



0 Kudos
Message 4 of 10
Thanks Nick - these two cards are new to me although I have used the PCI-6534 a couple of times before.
Do you think it will matter to me how much onboard memory I choose?
The data coming out of the card will not be that much. I'm thinking more of the receiving and analysing.
0 Kudos
Message 5 of 10


     I don't think that you necessarily need the higher memory cards as you can do Real Time Hardware comparison if you go for the 655x card. There is a great tutorial here that explains this. It might be  that this hardware compare is also available on the 654x card as well. The only time you may need the higher memory is if you want to store the received data as well for off line analysis.

Hope this helps,


0 Kudos
Message 6 of 10
Thanks a lot Nick - much appreciated.
0 Kudos
Message 7 of 10
I am doing something similiar to you.  One problem with the real time hardware compare is the bit by bit compare result is ouput on a pin in real time but you will still have to wait until the gen/acq is finished to fetch the acquired waveform and perform a BER calculation.  This means the memory depth of the card is important because (as far as I can tell) you can't fetch a waveform and calculate BER all while still acquiring.
0 Kudos
Message 8 of 10

When using the real-time hardware compare feature of the 655x (not supported on the 654x) the error comparison is stored separately from the actual acquisition.  Like the acquisition memory, though, once the memory has been written, you can fetch from them at any time.  That is, if your acquisition is still running but you have already acquired 100points into memory, you don't have to wait for the acquisition to complete to fetch out those 100points.  The same is true for the real-time hardware compare.

If you setup your generation and acquisition sessions to have the "HardwareCompare.Mode" attribute set to "Stimulus and Expected Response" and tell it to loop continuously, then the real-time hardware compare will run continuously as well.  While this is running, you can ping the hardware for attributes such as how many errors have occured (NumSampleErrors), how many samples have been compared (SampledCompared), how many sample have NOT been fetched from memory (SampleErrorBacklog), etc.  When you fetch the errors using "niHSDIO HWC Fetch Sample Errors (U32).vi" you are returned the sample number that resulted in an error.  You can use this value to fetch from acquisition memory to do a more thorough analysis of the fault.

In computing a BER, all you need are to know how many samples have been compared and of those compares, how many were errors.  These values can be returned at any time during or after your acquisition.  However, it is important to make sure that you continually fetch out the errors that you have already looked at.  If your BER is sufficiently high, then in continuous acquisitions you run the risk of overflowing your memory.  In most applications, though, bit error rates are much slower than the actual fetch rate so you can maintain a continous flow of data at high sample rates without trouble.

If you need to do more complex analysis of the bit errors then you need to not only fetch from the error log but from the acquisition memory as well.

I hope this helps.  Happy Holidays!
0 Kudos
Message 9 of 10
Brian,  Just as a finer point of clarification:

The backlog I mentioned above is for the errors captured, not of the actual raw acquired data.   There is an alternate but similar attribute available for the acquisition data.

Also, I mentioned making sure to fetch the errors so that the memory will not overflow.  If the memory fills up errors stop being logged but continue to be counted.  For BER testing where fault analysis is not important, this is a finer point to understanding some of the architecture.
0 Kudos
Message 10 of 10