PCI 5114 Timestamp

[John129]

Hi Jennifer,

Yes you're right that was the situation. Although even with that method it still seemed to be triggering off the reference trigger (as I was seeing signal and had it just continued after last acquisition i would only have got noise. Changed the program around to the advice you gave and it seems to be ok although I wont have oppertunity to test it on equipment for about a week. I've enclosed the programs (the original and the now modified one (v. 2)) although bear in mind they are a work in progress so I haven't really had time to tidy it. The only part which involve acquisition
are sequence 0 and 1:0

Many thanks for all the help,

John

[Jennifer O]

Hi John,

Post back if you find you are still not getting the results you are looking for once you get a chance to test this out.  Your second revision should let you get the timing information you are looking for.  I see you are trying to configure the start trigger after calling initiate  You will want to include this setting in a property node before calling initiate.  You cannot set the start trigger while the task is already running.

For the first application, so long as your triggers were occuring fast enough and your records were long enough you would probably see much of the data you were looking to acquire with the first method.   I will try to explain the difference in an example, to show how the first case will give you a skewed result even though it might not look obvious.

I see you are setting your record based upon time, so I will use that instead of number of samples.  Here are some numbers to set up the example

1.You configure your records for 20 ms of data immediately following each trigger and no data leading up to the trigger (you have set 0 pre-trigger samples).
2. Your fast triggers are coming in at roughly 40Hz (every 25ms) starting at time = 0ms.
3. Your application begins (ie the start trigger occurs) at 10ms.

So a timeline of your application is that there are reference triggers at 0ms, 25ms, 50ms, 75ms and 100ms.  The first one at 0ms is ignored because your start trigger has not been recieved. We will begin acquiring data at 10ms after receiving the start trigger.

In the second application we will capture a few samples relative to start so that we capture the 10ms start trigger timestamp.  Then we move to sample relative to the reference triggers.  This gives us 20ms immediately following each reference trigger, i.e. 25-45ms, 50-70ms, 75-95ms etc for the records we fetch. Your timestamps will be 10ms (start), 25ms(reference trigger of first record), 50ms etc.

 In the first application where you continue to fetch relative to start the data you acquire will be different.  The reference trigger is really like a stop trigger.  It tells the digitizer when to stop taking data for a given record.  The setting of 20ms of post-trigger samples tells the digitizer to stop acquiring a record and move onto the next 20ms after the reference trigger is received.  So at 25ms the digitizer continues to sample record 0 until 25ms+20ms=45ms.  Then it begins the next record on the next clock, lets make that 46ms for illustration. 

So you will now acquire 20ms relative to the start of each record.  This gives you  10ms-30ms, 46ms-66ms, 71ms-91ms etc.  You are still capturing data at the rate of the reference trigger, however the data you fetch is now mostly right before the trigger instead of all after.  Now your timestamps are 10ms (start), 46ms(start of second record), 71ms etc.  So the time between your faster triggers will still be appropriately captured at 25ms, however they are incorrectly referenced to the slow trigger, reporting 36ms instead of only 15ms as you saw in your revised application.

Its a little difficult to explain in a post.  I hope giving numbers as example helps illustrate the difference.

[John129]

Hi,

Sorry for the very late reply but was caught up in other things. From your previous post I can see the differences between the two setups and have used the second. I have recently upgraded onto a system with a fast trigger of about 1kHz and a slow trigger of 1Hz. Working at a sample rate of 250MS/s I get the error that the data has been already overwritten when I try to read the start trigger. I'm not 100% sure of the system but I assumed it was on a circular buffer which only recorded the time regions that were set up to be acquired i.e. 10us after each fast trigger, but I have been wondering whether its storing all the data after the start trigger, filling up the buffer and before I can fetch the start timestamp has overwritten the data. What confuses me is that its an intermittant problem and other times it seems to be ok.

[Jennifer O]

Hi John,

A buffer will be created for each of the records you configure.  This buffer is circular, and there isn't a good reason in your application to be seeing a buffer overflow or data overwritten error, except if the timestamp (first sample) is being overwritten. The buffers are automatically set as large as possible to minimize these types of errors.  This error can happen if too much time has elapsed between the start trigger and reference trigger, causing the buffer to fill and the first sample to be overwritten.The reason why it could be intermittent is the varying time between a start trigger and the first reference trigger (slow and fast triggers). 

Here is one suggestion to avoid this:

1)In your earlier application you did not configure the number of samples to fetch to get the initial timestamp.  Since you arent looking at the data, try setting this number to 1, or even 0.  Also, configure less records or use a slower sampling rate to allow the buffers to be larger or take longer before having to overwrite any samples.