very fast data receive using USB and processing the data

[msaifuddin]

Hello everyone,

I need to create a LabView program which is capable of receiving data through USB (FT2232H) at 25Mbps and save it after some processing. I am waiting for my hardware. In the meantime I have searched for the capability of LabView for acquiring data at 25Mbps but could not find much information.

Could anyone please help me answering the following questions.

1. Is LabView capable of acquiring data at 25Mbps speed via USB without any data loss in a windows machine?

2. How should I handle the data so that the data will not be missed due to delay in the processing and saving part?

Cheers!

[crossrulz]

You will not get sub microsecond timing in a Windows environment.  But this may still be possible.

You will definately need a really good computer (lots of RAM, fast multi-core processor).  And you should also learn the Producer/Consumer architecture.  The idea is to have a loop just for reading the data and sending it to another loop for processing.  This data is sent using a queue.  This will allow the reading to go along as fast as it can and have the processing happen in another thread.  I would go as far as to say you should put your saving of data to disk in yet another loop, recieving data from the processing loop via another queue.

[Jarek]

I would start from reviewing the informations from the FTDI website. From what I know you will need to handle the data using FTDI libraries (DLLs). When you get through the programming manual you will have the idea how to do it (and then you can ask questions that can be answered).

Here an article from 2008 about streaming data to disk:

http://www.ni.com/white-paper/7677/en/

[msaifuddin]

Hi Jarek,

Thanks for your reply.

I have already gone through the information from the FTDI website and I have installed  their D2XX library for LabVIew and also tested using the example provided.
I know FT2232H module is capable of handling data up to 40Mbps. But I could not find anything related to receiving high speed data specificly in LabView on the pc side and bottlenecks related to that for a windows machine.

Besides I was looking through the methods for pipelining but I was not satisfied what I have found (e.g. using feedback node) and so I asked if there is any other way of doing that. Thanks to crossrulz for informing me about producer/consumer architecture.

Cheers!

[nathand]

---

@msaifuddin wrote:

I know FT2232H module is capable of handling data up to 40Mbps. But I could not find anything related to receiving high speed data specificly in LabView on the pc side and bottlenecks related to that for a windows machine.

---

You won't find any specification on how fast LabVIEW can handle data because there is none. It depends on what sort of computer you have, how many other processes are running at the same time, how efficient your code is and how much processing needs to be done on the data. You'll have to test it, and then identify the bottlecks and work around them if you can't get the desired speed.

If you need an estimate before you receive your real hardware, you might try writing some LabVIEW code that attempts to generate similar data at the same rate, and see how fast it goes. Then see if you can process the data as it is generated. This won't be completely analogous, but it will give you a sense of whether it's reasonable on your computer.

[RTSLVU]

Consider the Producer/Consumer design pattern.

Then it just comes down to can you read the data fast enough.

Example https://decibel.ni.com/content/docs/DOC-3792

[Sam_Sharp]

Are you using the FTDI device in bit-bang mode (i.e. reading/writing the digital IO lines directly rather than using it as a serial port)?

I believe the FTDI D2XX driver for LabVIEW includes VIs for this - I have been able to use a similar device for SPI communications (which is obviously fairly high-speed digital communications). I believe the VIs allow you write a buffer of SPI data to the device and the timing and the timing is then handled by the FTDI driver/device.

I wouldn't be surprised if there was a similar function for reading digital IO data...