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.