NI 9205 group delay

[Blueprint]

Hi,

I am using an NI 9205 module in sampling loop running at 2kHz in my FPGA code (see image). I cant seem to find out the specs of the delay from a sample is taken till I get it out in form of conversion time and group delay and was hoping for the community to help.

From the NI9205 User Instructions I cant find the group delay of the device, can anyone tell me where to find this?

The ADC is sampling with 250kS/s, I am sampling 14 channels at 2kHz. Since it is only 1 ADC, will the last sample be taken at 14*conversion time + group delay?

I appreciate any help.

[christian_w]

According to the manual there's no delay as long as you access the module from the same FPGA vi. So the conversion is done sequentially channel by channel and by default with 8µs per channel. This will take 112µs for your 14channels and there is enough time until your loop cycle is finished. If you implement pipelining you are able to process the results of the preceding loop right at the beginning of the current loop while the readings for the next loop are done in parallel. I see no timing problem as long as the processing of your code within the loop meets the timing criteria of 500µs.

Hope it helps

Christian

[Blueprint]

Thanks for your response. 

Does this mean that the sigma delta filter is included in the conversion time?

There are listed both 8 us and 4 us convert intervals. How can I interprete the following information:

Accuracy, full-scale step, all ranges
±120 ppm of step (±8 LSB) .......4 μs convert interval
±30 ppm of step (±2 LSB) .........8 μs convert interval

Can I choose the convert interval by other means than asking for a sample at a more seldom interval?

I am timestamping the samples by a local variable being updated by a separate timing loop. I need to get an overview of the timing in when the sampling is taken place to ensure that the phase delay is compensated for when the data is being processed vs absolute time (GPS time). So after the sampling window shown in the list I take a time stamp from my timing engine. Will the last sample be from 8 us before, second last from 16 us before etc?

Not used to ADCs...:)

Thanks for any input.

[christian_w]

As described the conversation time is directly related to the resolution and a lower conversion time (4µs) results in a loss of accuracy. The modules specification in terms of accuracy is met at 8µs conversion time. You can access the conversion time settings of the module from the project explorer by opening the properties of the module (blue module icon). You are working on a FPGA which is hardware, so I think if you sync to your GPS once (hardware trigger) the timing is absolutely determined. I see no need to explicitly timestamp each value.

If you combine 14 readings in one FPGA I/O node, like your screen shot shows and which is absolutely ok, all outputs will be available at once after the last reading is finished (~114µs).

For exact details of the module, I mean more information than you can get out of the help you have to ask NI, but it will not change the way you have to deal with the module.

Best regards

Christian

[Blueprint]

Ok, thanks. I am using 8 us conversion time. Now that I understand the device a little better, let me rephrase some questions:

1. Will the sample from the first channel sampled, in my case Current_Inv1+ be sampled 8*14=112 us before I can access it due to the necessity of the sequential AD conversion?

2. If I split the node up in 14 nodes, the sampling is still sequential in the device, but it will be availiable on the wire earlier, giving way to a pipelining scheme? I see no reason for this unless I want to timestamp each sample.

I think its better to use nr 1 and then keep track of the time delays in the processing of the data.

My system is fairly complex, so I cant explain it all here. In short, the samples taken are grouped in blocks of 1000 samples which is transmitted to a PC which then stores this to a file. The file is later processed to recreate the sampled signal back to its original form. Thus it is important for me to have control of all delays and conversion times, because my system is very susceptible to phase errors. This is also why I am not hardware triggering the sampling, I am timestamping the first sample in each block (half second) and in this block header I also store information of FPGA time drift (which Ive measured to be up to 19 PPM). Do you think I can improve the sampling using hardware triggering?

Cheers!

[christian_w]

To 1) Yes thats how I understand LabViews block items. The outputs will become active if the processing is done and not before or step by step 🙂

To 2) I think if you split the IO access there will be a delay but by using SCTL's it can be minimized and I agree - cant see a reason to do it that way.

I would give the hardware trigger a try. Shouldn't be a big deal to implement 🙂

Christian