PCI 5114 Timestamp

[John129]

The only problem I can see is that after each fast trigger i want to be able to record approximately 10us of data at max resolution. As far as I know  each channel of the digitiser card have to trigger of the same trigger output. If i use slow trigger in ext trig, fast trig in ch0 and the data i want to read in ch1 and i understand you correctly ch0 would have to triggger of ext trig and I could work out the position using array manipulation etc but Ch1 would also have to trig of this (at which point i would extract the small part of the data after fast trigger). The problem is at 250MS/s I would be talking about 100-250 MB of data (assuming slow trig is ~ 1Hz) to store on the card (which I dont think my card can do) and have also extract this data which would be slow.

John

[Jennifer O]

Hi John,

Would you be open to a two digitizer solution?  The digitizer has the ability to accurately timestamp each trigger.  By synchronizing two digitizers together and setting one to trigger (reference trigger) off of your slow signal, and setting the other to trigger off the fast signal you can get a clear picture of the pulse relationships.  Obtaining an initial timestamp off each board using a common trigger will enable you to align the timestamps of the two boards.  You can think of this like an initial zeroing to get a common reference point.

This solution would be flexible, allowing a variable number of fast pulses to be seen between slow pulses.  You can also configure both digitizers to take as much or as little data as you like following the pulse simply by setting the record length.  If you had another signal that you wish to measure with the fast pulse, this could be done on the second channel.  If you do not need to measure the trigger pulse, this could even be configured as a trigger (using Ext Trig or a PFI depending on whether you are configuring analog or digital triggering), which frees up both channels for measurement if you need them.

 - Jennifer O.

[John129]

Hi,

Unfortunately I don't think our budget would stretch to buying another digitizer. Currently I may just have to go with the way that gives me an error of one period in the fast trigger tho it does seem strange that there is no for the card to output a timestamp directly from a trigger and can only do it from a Channel input.

John

[Jennifer O]

Hi John,

Although the two digitizer method would be simpler, since you are willing to set the limitation in your application to acquire a set number of fast triggers a single digitizer is an option.  I have a few pointers that may help you resolve the issues you have run into.

1)So long as you are not changing parameters for subsequent acquisitions (i.e. reconfiguring), only the "initiate" function is required to set you running again.  This should be faster to execute than 0.5 seconds.  I expect the value you should find would be on the order of tens of ms.  This will impose a limitation on your slow trigger rate, that anything < your initiate time will not be captured.  This limitation would be reduced to the digitizer rearm time in the two-digitizer solution.

2)You can obtain a timestamp of the first post start-trigger sample to use as your reference point.  Since your trigger would be asynchronous to the clock, this timetamp would have a resolution equal to your sample clock.  I imagine this is much finer than your fast trigger period.  Simply set the "fetch relative to" property to fetch relative to "start".  Then you can fetch a single sample to get a timestamp. Then switch back to "pretrigger" to continue fetching your records normally.  This will remove the need to assume the two pulses coincide.  You will likely want to also set the number of samples to read property.  This would be "1" for capturing the start, and then "#" for each of your records where # is your record size.

- Jennifer O.

[John129]

Hi Jennifer,

Thanks for the ideas. To answer your 1st point, yes you're right it does execute faster that 0.5sec. It was just missing one of the slow triggers while resetting and have sorted that problem out. As for point 2, The idea you had seems to work perfectly (as far as I can tell so far). I just want to confirm though that the first waveform is triggered of the start trigger and the rest of the reference trigger. What I have done so far is tell the card to acquire n+1 samples where n is the no of fast triggers I want to trigger off. Take the timestamp of the 1st one and then delete that waveform from the fetched 2D waveform array. The timestamps of this new array (i.e without the 1st waveform) are then referenced with the extracted timestamp and the waveforms plotted.

Many Thanks,

John

[Jennifer O]

All records are actually triggered off of the reference trigger.  Therefore I can't see a reason to throw out the first record,  however you probably wont need to look at the data from the very first sample (the start trigger sample) other than pulling the "absolute initial x" time of that sample.  This sample is not a record, I will explain more below.

Here is what the flow of events would be, for a pictoral view look for SMC-Based Digitizer Acquisition Engine State Diagram in your High Speed Digitizers Help manual: (Note, the steps below are slightly simplified as you are not using some of the available features for this particular application)

1) Both reference and start triggers are configured along with all other settings such as range and sample rate (idle)
2) Initiate is called and the digitizer waits for the start trigger - your slow trigger, no sampling is taking place yet
3) When the trigger occurs it begins taking pre-trigger samples (you want to read the first one of these to get its timestamp for your start trigger timestamp)
4) If you have configured your records to have pre-trigger samples, the digitizer will ignore reference triggers and continue sampling until it has the required number of samples. If your reference position is 0% so you have no pretrigger samples, the digitizer is immediately ready and waiting to receive the reference trigger, but still acquiring samples.
5) When the reference trigger occurs, the digitizer continues to sample until the required post-trigger samples are aquired.  If more records are requested, it will continue sampling beyond that, but we have returned to step 4 (acquiring pre-trigger samples).

In the typical and default case where the fetch is set relative to pretrigger samples and the number of samples to fetch per record is equal to your record length, you acquire into PC memory only those samples that are considered to be the record.  You will get the absolute time of your first datapoint, and the relative time in how it relates to your trigger. You will get a set of this data if you are fetching more than one record at a time - one for each record.

In your application, you are sampling a sample that would ordinarily not be returned as it does not necessarily belong to a record.  In this case that point you sample gets an absolute time.  The relative time is invalid (and you dont need it anyway), as a reference trigger has not yet occurred.

To determine the time between each reference trigger and the first sample taken after the start trigger, use the difference between the absolute time for your first sample and the absolute trigger time of each of your reference triggers.  The absolute reference trigger time can be obtained with the folowing relationship:  absolute trigger time = absolute initial x – relative initial x   (see Time Stamping)

[John129]

I've attached a diagram of the type of scan I get. This is for just one slow trigger i.e it isnt summed data. Each box represents one waveform and essentially what I have done is for each iteration of the slow trigger, divided the time into bins and if the waveform timestamp falls within a bin range the data is placed within that bin and then simply merged them into an array one after the other. In this example I am making the bins range 10ms, It is important to realise though that the data before one of the dashed lines may be some time before the one immediately after as each waveform is only is only microseconds long. I hope the above description makes some sort of sense.
As you can see from the diagram there is always one 'box' of data (which I have coloured red) which appears in the 1st bin. As the slow and fast triggers are not synchronised and not harmonics, at a different time I can see the 2nd diagram. The red box however always stays the in the first bin so it leads me to suspect it is triggered of the start trigger. The time difference between all the blue boxes is similar to the fast trigger period so I know these are triggered of the reference trigger. When I delete the first fetched record array the red box disappears so I know it is the first record recorded and not some kind of wrap around and if it is not due to the start trigger I am at a loss where it comes from.

[Jennifer O]

Hi John,

I have drawn a picture to illustrate my recommended timestamping method.  I have labeled the events A-E, and numbered the samples to describe what I think you might be seeing.  I have made an assumption that each record is 3 samples as an example and have outlined those records.  Triggers are red and initial samples are blue.  The end goal is to get the time between the red triggers (B-A and D-A), however we cannot capture the time of the start trigger, and will substitute the time of the first sample (A' will replace A).


A = Start Trigger
B = Reference Trigger 0
C = First Sample for Record 0
D = Reference Trigger 1
E = First Sample for Record 1

The board will begin sampling after the start trigger occurs.  If you set your pointer and number of samples to read to 1 sample relative to start, sample 1 will be returned with an absolute timestamp of A'.  Your timing error is A-A' which can be up to 1 sample period. This time is used as a reference point and should not be included with your bins, this is just a marker to represent the beginning of bin 1.

Now changing those properties to read the appropriate record # (0), samples per fetch (3) and to read relative to pretrigger, you will fetch samples 5,6 and 7.  Your absolute time is C.  Your relative time is C-B.  Therefore the absolute trigger B is given by C- (C-B). 

Incrementing your record to fetch (1) you will get samples 11-13.  Similarly you will calculate D as E-(E-D).

Finally you will get your relative trigger times as B-A' and D-A'.  If you are already implementing this, and your triggers B, D, F, H..... are not periodic even though you provide a periodic wave could you post a code snippet?  I expect B-A' to vary as the signals are not synchronized, but B&D should never have reason to fall on top of one another.

Message Edited by Jennifer O on 07-18-2008 01:45 PM

[John129]

Hi Jennifer,

As far as my work goes the difference between the sample start and the trigger involves more accuracy that really need. On the subject of posting code, I would do so but unfortunately I am out of the country all week and its on my computer back in the lab (so I can post it when I get back). Essentially all the program is, is a multi fetch which has been set up to have a start trigger and a reference one with a property node containing 'fetch relative to start'. When I execute this i get a series of waveforms as expected (and at the expected time apart). The 1st waveform however is independant of the position of the others so I presuming the start trigger is also initiating a waveform measurement along with the reference ones. If this is the case it is fine and I can easily account for this. I'm just  curious as you say this shouldn't happen.

Many Thanks,

John

[Jennifer O]

Hi John,

I want to verify that you are not continuing to use "Fetch relative to start" throughout your program.  You want to do this for the very first fetch only.  This will give you timestamping of your first sample after the start trigger.

After this point, you will want to move back to "Fetch relative to pretrigger" and control which record and how many samples you wish to take.  If you do not add in this second property node to change the fetch parameter after your first fetch, then the records you will read will not be as you expect.  The timing information for the trigger point will be correct, however instead of reading X number of samples around your trigger you will be pulling in X number of samples starting with the first sample taken after the previous record.  If more than X samples occur between that time and your next trigger, you may not even capture data adjacent to your trigger.

You can experiment with the Multi Record example by adding a property node to set the "Start trigger source", "fetch number of records"  and the "fetch relative to" property prior to calling initiate.  Then add a fetch (to capture the start trigger), and another property node to set the "fetch relative to"  back to pre-trigger.  Place these functions between the initiate and the fetch that already exists to capture your record information.  You will notice that the data that plots is different.  For example, if you set your reference point to be 0% (all samples should occur after your reference trigger, since there are no pretrigger samples), you would expect your first sample to be approximately equal to your trigger setting.  By default this is 0V unless you configure a different trigger level.  If you set the fetch relative to property to pretrigger this looks correct, with each record beginning at roughly 0V and increasing.  If however you continue to use start, then the data does not occur immediately following the trigger as you would expect.

By skipping the second part as I am guessing you did, the behavior you describe would be expected, however I don't think it is actually the ideal measurement you are looking to obtain.