Niscope - Understanding to timestamp an acquisition

[Witschas82]

Dear Labview community,

I am currently struggling to understand the timing and would highly appreciate if you could give me hints or an explanation. 

A brief description of my goal:

I am using an ni-5162 in a Schroff Chassis with an ni-8881 controller for data acquisition. 

My signal is triggered with 750 Hz (1.33 ms). After each trigger, I want to sample 85000 samples with a 625 MHz sample rate. According to my calculations, this should take about 0.14 ms, so only 1/10 of the time between each trigger event.

For better tracking, I want to timestamp each event (either at the beginning or the end of the actual acquisition). In order to do so, I use an ni-6614 timing card to generate an 100 kHz pulse train as reference clock. I read this reference clock at each acquisition.

you can find an excerpt of my Vi below, but I also attached the entire Vi to this post. 

No to the problem that I am encountering or that I rather do not understand.

When I consider my 750 Hz TTL trigger signal, I would expect that the duration between each signal is more or less 1.33 ms. When I plot the signal between respective pulses, I more get something like what is shown below:

The time between most of the pulses is indeed 1.33 ms, but there are also occasions with half of the time, or twice, or other multiples. For better visibility, I divided the time by 1.33 ms and get the following:

So what is happening here?

Why is the time between successive trigger events a half-multiple of my 1.33 ms trigger time?

Is there any possibility to write my 100 kHz reference clock to the actually time when the 5162 reads (acquires) the signal?

Probably, I have a lack of understanding here. So any comment would be highly appreciated here.

Thanks a lot in advance and best regards,

 Benjamin 

[GerdW]

Hallo Benjamin,

---

@Witschas82 wrote:

The time between most of the pulses is indeed 1.33 ms, but there are also occasions with half of the time, or twice, or other multiples. For better visibility, I divided the time by 1.33 ms and get the following:

So what is happening here?

---

• You rely on WindowsOS timing capabilities, when "synchronizing" measurements of two different devices. Those "capabilities" are rather limited…
• Those ~0.5/~1.5/~2.0 factors occur in groups: when there is a ~1.5 then there also is a ~0.5 nearby: one cycle needs a little more time, the other about the same less. In sum the delay is cancelled…
• Can't you use the "trigger signal" to actually measure it's timing using the NI6614 card? (Maybe you need a little amplifier circuit to convert your analog signal into something "digital" compatible with the counter module!?)
• Does the NI-Scope offer any trigger output signals? (I never worked with such scopes…)

[Quiztus2]

https://www.ni.com/docs/en-US/bundle/ni-scope-c-api-ref/page/scopefunc/cviniscope_readwaveform.html?...

initialx and actualpoints aren't helping here?

[Witschas82]

Dear Gerd, thanks a lot for your reply. As I am generating an own 100 kHz clock which is stabilized with the onboard OCXO, the timing should not be affected by the windowsOs timing. I verified that with the GPS PPS, and the drift was a few ms per hour. 

But you are absolutely write. I can use the trigger on the 6614 to get the timimg with some hardware modification. 

I was just wondering if the 5162 is doing the acquisition correctly at the point of time when the trigger occurs. 

Currently, I have no access to the hardware, but I will verify your suggestion next week and will report about the outcome. 

All the best, Benjamin 

[Quiztus2]

You query the status in a software loop.  So the counter value is dependent OS ressource scheduling.

[Witschas82]

Dear all,

thanks a lot for your comments and apologies for my delay reply, which was due to annual leave that prevented me from doing exciting lab-work. 

In the meantime, I worked on the timing topic with success.

First, I followed the suggestion of Gerd and used the trigger (as well as the PPS signal) as a gate on the counter card. Afterwards I used the gate as input to the sample clock. By doing so, I get one reference clock per trigger event.

In a next step, I read the value in the while loop of the DAQ when there is at least one sample available (see picture below). I did a few hours of measurements and it seems to work properly. What was important is, that the counter reading has to be done before the fetching of the scope starts (verified by the error wire). Otherwise, and memory overflow occurs. Maybe, this information might also be helpful for others.

Thanks a lot for your help and best regards,

 Benjamin