LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Fast data acquisition and transfer

Hello

 

I am buiding a control setup for the scanning microscope. I am using the PCIe-7852R FPGA.

1. I have a resonant scanning mirror with 16kHz frequency. This means, that e.g. if I want to have a 512 pixels in the line, I need to acquire the data every 61ns. So from what I understand is impossible, as I can only acquire with the multiplication of the ticks, i.e. every 1 tick (1 tick = 25ns). That means I would have to acquire every 2 ticks. Whould that be a correct assumtpion?

2. I have a detector (MPPC - multi photon pixel counter from Hamamatsu Photonics). It has both analog and digital output. Wich output should give me a faster readout of the photons? Will I be able to read the analog input from the FPGA every 2 ticks? 

3. Assuming I get the full readout from 512x512 pixels, what would be the best way to store the data on the FPGA and then transfer them to the host? Or will I be better of in transfering the data with every read, i.e. every 2 ticks? Would that be even possible?

Thanks for help in advance.

 

0 Kudos
Message 1 of 5
(3,254 Views)

Hi Piotr,

 

Well, this won't be easy! But certainly possible.

 

The I/O is going to be the hardest thing to get fast since you are limited by the hardware. The board you have is an R-Series board, this means it has a mid-range (in terms of speed) front end. You are limited to:

 

Analog - 750kS/s or - 1.33uS

Digital IO - 40MHz - 25ns

 

So analog is a no-go with this board (there are other systems that could do this though if necessary).

 

Digital may work depending on the interface available on the module. Looking at the device it looks like perhaps it just outputs a pulse when it counts? If this is a case you need to look at how fast you expect it to count as you need to sample faster than that. If you are reading a count every 61ns I presume you are counting much faster in which case 40MHz doesn't necessarily give a lot of room on top of this.

 

As you can see, the first thing to get right is the IO, the rest follows from there.

 

If the IO supports it, you can generate different frequency clocks to get closer to an ideal period for you.

 

In terms of the transfer, if you just need to view it on the host (no processing on FPGA) then just streaming it is probably the easiest method. A 512x512 frame on that FPGA is very large for the onboard memory (or possibly impossible, it has 1,728kbits).

 

Also this device is PCIe x1 which means you are limited in streaming rates by the bus of 250MB/s which I imagine you might be pushing as well.

 

Depending on IO, the bad news is on the face of it this application maybe too hard for the card you have, you may find you need to look at FlexRIO or a new R-Series with more memory and faster interfaces. You will need to do the maths to work it out.

 

Cheers,

James

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 2 of 5
(3,237 Views)

Thank you very much for the answer. That means that the analog input is a no go, at least this is clarified. I am not sure if I understood you correctly, but does that mean, that if I derive a different clock for the FPGA, e.g. 200MHz, will I be able to acquire the data with 200MHz frequency or this is only true for the onboard FPGA operations? 

You said that FlexRIO card would be a better solution in my case. Would you reccomend any particular cards?

0 Kudos
Message 3 of 5
(3,216 Views)

That is right about the 200MHz as even the digital IO on that card is only rated to 40MHz.

 

It would depend on your whole application, did you say there is some control as well?

 

For analog there are some 40-120MS/s front ends which may work. For digital there are some 100MHz digital interfaces which may work.

 

If it turns out the IO is OK but the bandwidth is a problem then just looking at a PXIe R Series card would be easist (since the IO is simpler).

 

Either way I think you need to work out exactly what your IO requirements are for the digital interface since the FlexRIO modules are very specific so you would want to be sure before parting with any cash! But it seems like if you are reading counts at 16MHz (61ns ish) the counting frequency will need to be much higher than is easily done on the NI cards (if you expect 100 counts then that means 3.2GHz) so the analog signals may be the better option with the faster flexRIO modules.

 

As I say though I still don't fully understand the output of that module and how it interacts with the mirror etc. so take my advice at the minute with a pinch of salt!

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 4 of 5
(3,208 Views)

Sorry just reading that last post back was a bit of a brain dump!

 

Basically if you are expecting digital counts in the GHz range then analog is probably the easier interface, but the current card won't do it.

 

If I understand correctly, if you were going to do analog then probably the FlexRIO with an appropriate speed (>16MS/s) analog front end but you would need to see what other control signals might be involved since the FlexRIO would only have analog (and perhaps a couple of digital trigger lines).

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 5 of 5
(3,200 Views)