externally triggered digital acquisition with digital start trigger

[kalganian]

greetings, i'm using a pci 6533 board to acquire digital data from a imager chip. i'm using the ms visual c api.the chip generates a VSYNC pulse after which it generates 352*288=101376 ticks of a pixel clock at which the data is available on a 8 bit wide bus. once all ticks are done, VSYNC pulses again and the next frame is read out.i have the circuit hooked up thus:VSYNC to pfi6PIXEL CLOCK to pfi28 bit output bus to port0following is the configuration code for the card:DAQmxErrChk (DAQmxCreateTask("di_pfi6start_pfi2clk",&taskHandle));DAQmxErrChk (DAQmxCreateDIChan(taskHandle,"Dev4/port0","",DAQmx_Val_ChanForAllLines));DAQmxErrChk (DAQmxCfgDigEdgeStartTrig(taskHandle,"/Dev4/PFI6",DAQmx_Val_Rising));DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandle,"/Dev4/PFI2",DINFREQ,DAQmx_Val_Rising,DAQmx_Val_ContSamps,10*ROW*COL));DAQmxErrChk (DAQmxRegisterEveryNSamplesEvent(taskHandle,DAQmx_Val_Acquired_Into_Buffer,ROW*COL,0,EveryNCallback,NULL));DAQmxErrChk (DAQmxRegisterDoneEvent(taskHandle,0,DoneCallback,NULL));DAQmxErrChk (DAQmxStartTask(taskHandle));following is the EveryNCallback function:DAQmxErrChk (DAQmxReadDigitalU32(taskHandle,ROW*COL,10.0,DAQmx_Val_GroupByScanNumber,frame,ROW*COL,&read,NULL));now, when the code runs, it appears to me that the digital acquisition starts a random amount of time after the VSYNC pulse. basically the data that i read out is not aligned to the begining of the frame but starts at different locations at each time. this problems persists even if there are several tens of milliseconds between VSYNC and the first PIXEL CLOCK. also the way the code is configured, it looks only for the first VSYNC before acquiring data. after that it just grabs a frame worth of data each time. i do not see the frame offset changing from frame to frame ie1. i run the code2. i wait for a VSYNC and grab 101376 bits - instead of bit 1 to bit 101376, it reads bit 101 to 101476. thus it looks like the card had some latency after getting triggered by the VSYNC and could not read bit 1. since it was configured to read 101376 bits, it read them but started from a random point (101 in this case, if i run the code again, it will be different).3. after the first set of 101376 bits, the daq again has to read 101376 bits and this time it reads them from 101477 onwards. thus the offset of 100 bits from the VSYNC remains constant.any suggestions about what might be happening? am i right in my understanding of  DAQmxCfgDigEdgeStartTrig and DAQmxCfgSampClkTiming ? is there a better way of doing this?thanks,kartik

[DJ L.]

Hey kartik,
 
I have looked through some of your other posts to try and find a little more information about your system setup. I was unable to find any information about your pixel clock or Vsync signals, such as what rates the pclk and vsync are running at? For example is the pixel clock running at 1 MHz, 2 MHz, 500kHz, and what rate is the Vsync coming in at?
 
I see in your code that you are acquiring Continuous samples. I was wondering if you have tried just acquiring a Finite number of samples, which would basically give you just one image each time, and does that work, or do you also see the offset there?
 
Next, have you tried to use not only a Start trigger to start an acquisition, but also have you tried to use a Reference trigger? You should be getting the data immediately when the trigger comes in. The reference trigger will allow you to acquire pretrigger samples, but this might not help if it is a random number of bits that you say is offset each time.
 
Another thing that comes to mind is that if you are using the Rising Edge of the Vsync, your Vsync might be high, then goes low, then back high, which could cause the missed signals. You could try using Falling Edge to see if that changes anything, just for a quick test.
 
Your code looks pretty simple, and should work, but I was wondering if you have tried to use any of the example programs and change them up a bit? I would suggest starting with a simple example like the ReadDigPort-ExtClk.c and then add in a trigger. Also, one way to make sure that your triggers are working is by also making sure that you don't get data if the trigger does not come, so basically you can try to disconnect the Vsync and see if your program times out.
 
Also, another option you have is to just wait for your first Vsync pulse to come in as a Start trigger, and then just acquire until you are done, and do post processing to extract the image data instead of trying to retrigger on every Vsync. Basically a continuous acquisition with post processing. This depends on what you are trying to accomplish overall, and whether or not you can post-process.
 
One last option that you have, especially if you are acquiring at really slow rates, is to check out the Burst Protocol Sample Timing type. This is basically a handshake protocol and if you are running slow enough, you can set up the Vsync as a Pause Trigger (which is only available in Burst Mode).
 
I hope this helps. Please let us know if you have further questions or concerns, and let us know how things are going. Thanks, and have a great day.
 
Regards,DJ L.

[kalganian]

hi dj l,thanks for the reply. i've tried to run the system at several different clocks and still get the same problem. these speeds have ranged from fastest: PIXEL CLOCK @ 2 MHz and VSYNC @ 12 Hz. at this speed there is at least 5 ms between the VSYNC falling edge and first PIXEL CLOCK rising edge.slowest: PIXEL CLOCK @ 250 kHz and VSYNC @ 1.5 Hz. at this speed there is at least 40 ms between the VSYNC falling edge and first PIXEL CLOCK rising edge.i see the same problems in both cases.i have tried both edges of VSYNC with the same results. i favor the rising edge as it give more time for the card to get ready for acquisition.continuous acquisition with post processing to correct for the offset will be my last resort, though i am pretty sure that what i'm trying to do is doable...in any case, what i'm trying to do currently is a single (just the first one) start trigger on VSYNC and then grabbing a frame's worth of data before dropping into the callback function. is it possible to make a digital start trigger retriggerable? ie 1. wait for VSYNC2. acquire frame's worth of data3. goto 1i have confirmed that if i block VSYNC, the card times out.i have not tried the reference trigger or acquiring finite samples yet. i'll try those and get back to you about that.my code was based on the nidaqmx examples. in particular DAQmx ANSI C\Digital\Read Values\Read Dig Port-Ext Clk and \DAQmx ANSI C\Analog In\Measure Voltage\Cont Acq-Ext Clk-Dig Startthanks,kartik

[DJ L.]

Hey kartik,
 
Sorry for the late reply, but I wanted to check to see how things are going with your image acquisition with a high speed digital i/o application. Unfortunately, the 6533 (and 6534) do not support fast re-triggering natively on the hardware. Your best method is to acquire all of the data and do post processing on it in software to discard the vertical and horizontal blanking pixels. The approach that you were trying before of configuring a digital input task, waiting for a trigger and perform a finite acquisition, then closing the task to reconfigure the hardware to wait for the next trigger is the closest you can get to retriggering. How did the reference trigger work for you? Basically taking the "Read Dig Chan - Int Clk - Dig Ref" Example and placing it inside a loop is your best bet, unless you have some external circuitry that could gate your pixel clock to only acquire when your data is valid.
 
You might also consider other boards that might work for you, such as an image acquisition device, like the 1422 or 1424, or maybe a more advanced High Speed Digital I/O product like the 6541/42 or 6551/52. Please let me know if you have any further questions or concerns. Thanks, and have a great day.
 
Regards,
DJ L.

[kalganian]

Hi DJ,Here is an update:Kartik and I tried to grab one set of pixels (finite samples) to aquire a single image rather than continuous video.  We used vsync as the start trigger, and in another attempt, as a reference trigger.  The images always come back with a seemingly random frame shift, indicating that the aquisition does not start at the first clock signal after the start trigger, or at the nth clock signal before the reference trigger.Any insight you have would be greatly appreciated.Thanks,Elliot

[DJ L.]

Hey Elliot,
 
Because the 6533 (and 6534) do not support fast re-triggering natively on the hardware, your best bet is to acquire all of the data and then do post processing on it in software if you need to discard the blanking pixels. I am assuming that you have tried the following in your code:
While Loop
{
  DAQmxCreateTask
  DAQmxCreateDIChan
  DAQmxCfgSampClkTiming
  DAQmxCfgDigEdgeRefTrig
  DAQmxStartTask
  DAQmxReadDigitalLines
  DAQmxClearTask
}
 
If you are doing something different, please let me know. Also, are you missing every other frame or missing 2 or 3 frames in between?
 
Regards,
DJ L.