Continuous collection of photodiode data in LV

[StuE]

I'm trying to use the high sampling rate of the AD2 to monitor my probe beam in a transient absorption experiment controlled in Labview. I need to run at probably between 100kHz-10MHz, depending on the response of the PD itself and how well it samples the laser, and I need to capture every pulse (the laser rep rate is between 125kHz down to 1kHz, pulses are sub 100fs visible, but the photodiode's response is slower since I'm running it in photovoltaic mode unbiased, which reduces the sampling requirement on the SD2).

Ideally, I'd like to be able to collect data for an arbitrary amount of time. In reality, this means a few seconds to collect up to 10000 spectra on my spectrometer, and the accompaning data from the photodiode via the AD2.

However, running the AD2 at 100kHz in a simple labview vi that just initialises the AD2 and reads the output of the analog channel I'm using, I can see via the waveform timestamp that every time the buffer fills up there's a ~570ms space before the next readout (eg timestamp of the 8001st datapoint from the 8000th datapoint, for a buffer of 8000 samples). This will screwup my data correction something fierce.

I'm currently using a while loop and shift register to extract the data just to see what it's giving me for now (see attached screengrab).

Is there a better way that I can readout the photodiode signal so that I'm just constantly pulling data off of the buffer, or create a circular buffer or something? I've checked the digilent examples (this code is a simplification of one) but can't see anything that helps me. Any recommendations for functions that will allow me to maximise the memory allocated for the buffers would be great, too.

Cheers!

[JColvin]

Hi @StuE,

I'm not certain what what might be able to be done differently in your setup since you've stripped down the process for what you need done. What you are needing is WaveForms SDK function (which is what the LabVIEW functions call) to adjust the buffer size used by the analog inputs, though I'm not certain what the maximum buffer size is, nor do I believe this function is implemented within LabForms. The function names you would be looking for in WaveForms SDK (available as part of the WaveForms download available on it's Resource Center here), are FDwfAnalogInBufferSizeInfo, FDwfAnalogInBufferSizeSet, and FDwfAnalogInBufferSizeGet.

Let me know if you have any questions about this.

Thanks,
JColvin

[StuE]

5 hours ago, JColvin said:

Hi @StuE,

I'm not certain what what might be able to be done differently in your setup since you've stripped down the process for what you need done. What you are needing is WaveForms SDK function (which is what the LabVIEW functions call) to adjust the buffer size used by the analog inputs, though I'm not certain what the maximum buffer size is, nor do I believe this function is implemented within LabForms. The function names you would be looking for in WaveForms SDK (available as part of the WaveForms download available on it's Resource Center here), are FDwfAnalogInBufferSizeInfo, FDwfAnalogInBufferSizeSet, and FDwfAnalogInBufferSizeGet.

Let me know if you have any questions about this.

Thanks,
JColvin

Hi @JColvin

 

thanks for replying. Essentially I just want to record the signal from the photodiode using the AD2 for several seconds at a high rate, so all I need is to use it like an ADC. Right now I'm accomplishing this via the oscilloscope functionality, but if there's an easier way I'd love to hear it.

 

I did find those functions in the SDK and am trying to implement them in labview (around a million other things, unfortunately), but I assume I'll be limited to 2x8192 = 16384 samples. Ideally, I'd like to write to the buffer in a circular fashion, or even write into ram/solid state drive rather than the AD2 buffer. I'm not sure if that's feasible considering it runs via USB2, but it isn't much information.

Any suggestions would be greatly appreciated; I find it frustrating that the buffer is the only thing limiting me, other than the the AD2 is great!

[JColvin]

Hi @StuE,

You can set the acquisition mode to be in a different mode than the single acquisition mode (FDwfAnalogInAcquisitionModeSet) which I believe is the default mode and will only fill up a single buffer that then needs to be read and then refilled. There are other modes such as ScanShift, ScanScreen, and Record mode (detailed more on page 22 on the WaveForms SDK Reference Manual) that would do what you are wanting. Specifically the ScanScreen mode does write to the buffer in a circular fashion, though I personally don't know the limitiations associated with reading from and writing to a buffer at the same time.

Otherwise what you may want to do Record mode since that runs up to 1 MHz from my understanding ( @attila would be better able to confirm specs on this). I'm also not certain how tight your timing requirements are, but since changing the buffer size and some of the other functions aren't so easily changed, it may be worth it to just have LabVIEW call python scripts (or c based scripts, both available with samples in WaveForms SDK folder with Analog Input examples. Again, I'm not certain on your timing constraints so that may not be of help to you.

Thanks,
JColvin

[xc6lx45]

A couple of thoughts:

What you're looking for is "streaming" data acquisition. It's fairly routine with industrial test equipment e.g. PXI or PCI based "digitizers". But, not sure what to expect with "budget-friendly" equipment. Disclaimer: I don't know the AD2 at all.

You may be able to solve this problem with a $70 Artix- or Spartan FPGA module and the onboard 1 MSPS/12 bit ADC. The necessary RTL design is relatively straightforward: boilerplate XADC and dump the ADC frame to a UART on end-of-conversion. The UART data rate can go up to about 3 MSPS using FTDI's driver API on the PC side (DLL?) so e.g. 8 bit at 250 ksps should work. I think I tested 6 MBaud once but don't take my word for it and beware of "relatively" straightforward things in FPGA land...

Would a 192ksps sound card work?

[StuE]

On 2/1/2019 at 4:56 AM, xc6lx45 said:

A couple of thoughts:

What you're looking for is "streaming" data acquisition. It's fairly routine with industrial test equipment e.g. PXI or PCI based "digitizers". But, not sure what to expect with "budget-friendly" equipment. Disclaimer: I don't know the AD2 at all.

You may be able to solve this problem with a $70 Artix- or Spartan FPGA module and the onboard 1 MSPS/12 bit ADC. The necessary RTL design is relatively straightforward: boilerplate XADC and dump the ADC frame to a UART on end-of-conversion. The UART data rate can go up to about 3 MSPS using FTDI's driver API on the PC side (DLL?) so e.g. 8 bit at 250 ksps should work. I think I tested 6 MBaud once but don't take my word for it and beware of "relatively" straightforward things in FPGA land...

Would a 192ksps sound card work?

@xc6lx45Thanks for taking an interest; part of the reason we chose the AD2 was the 14bit (rather than 12bit) ADC. I have not FPGA experience; I shoot lasers. If I can get this working it's better because when I eventually move labs whoever takes over has a better chance of picking up where I left off.

 

Having said that, if you've got a suggestion I'm willing to try it.

[xc6lx45]

BTW, if you use a 1 MSPS ADC for 10 kHz bandwidth, you may gain the two bits from oversampling gain. E.g. accumulate 64 samples and use sum[21:6].

It causes some deviation in the frequency response "sin(x)/x", if in doubt use less averaging than theoretically possible.

Just be aware that the smooth early learning curve is designed carefully into some technologies e.g. Labview. FPGA in general is not one of them... No free lunch here. I'm still hoping someone will say it's possible with AD2.