We are using a NI-PCI 6541 HSDIO card for simultaneously generation and
acquisition of data. For this, we use some C code that is largely
comparable with the DynamicAcqAndGen-SourceSynchronous.c example code
and this does work okay. One thing that surprises me however is the
long delay between the moment the acquisition is started and the
generation is started.
The code I used to make the measurement is (somewhat stripped):
And the typical results is something like 20000us = 20ms.
When I look into the captured data and see when data that is being
generated caused a response in the acquired data, I see that this
typically translates to something like 115000 samples, which translated
to 2.6 ms on 45 MHz generation/acquisition frequency.
Combining these results, it seems to me like setting up the acquisition
takes about 17.5 ms and starting generation about 2.5 ms. Both the 17.5
ms and the 2.5 ms are pretty long to my opinion, we are using a recent
Pentium 4 machine.
Is there any way to reduce this latency?
NB: I tried to do a niHSDIO_CommitDynamic( RxSession ) earlier on but that gives errors.
Do you have the ability to trigger the acquisition from the generation
session? You could route a Data Active event from your generation
session as a start trigger to your acquisition session. In this
fashion, your acquisition will not actually receive data until your
generation session is generating data. You would need to start
your acquisition session first so that it is looking for the trigger
before the generation task sends it. If you have an open PFI
terminal and your DUT has some synchronous event that it can export,
that would be the signal to trigger from. However, if your DUT
does not have a synchronous event, you could route the event and
receive the trigger on the same PFI channel. I would recommend
using PFI 0 with no cable attached to minimize transmission
effects. This would not account for any latency in your
transmission path (ie DUT propagation delay) but would remove
significant latencies introduced by software timed operations.
The capture buffer taken by the 2.5 ms delay is not a problem. I
already used a trigger in a particular situation and it works okay.
The actual worry (unlike the title) is the (processor) time it takes. I
find it strange that starting acquisition takes about 17.5 ms and
generation 2.5 ms while the complete capturing is done in the hardware
of the card and a commit has been done; I would expect this could be
done by writing a start bit to a certain register and that should take
less then one us. We use the card in repetitive mode where the
acquisition results will provide the data for the next acquisition
session and these delays severely limit the overall performance.