Machine Vision

Showing results for 
Search instead for 
Did you mean: 

PCIe-1427 12-bit pixel depth, vertically interlaced

Are there any known issues with the PCIe-1427 frame grabber acquiring images with 12-bit pixels that are vertically interlaced?


I am designing an area scan CCD camera with a Camera Link (base configuration) interface operating at 66MHz.  The camera outputs 12-bit pixels that are vertically interlaced on two taps (even pixel/odd pixel on every pixel clock).  I am having trouble with the PCIe-1427 capturing all of the horizontal lines with the aforementioned configuration.   The frame grabber will only capture the first line in the ROI.


For testing purposes I have the pixel value set to an incrementing pixel count in the lower 8 bits and an incrementing line count in the upper 4-bits.  I am interfacing the with the PCIe-1427 via the NI-IMAQ C API.  My C application will capture the image with imgSnap() and write the raw capture buffer to file for analysis.  I also write the capture buffer to a PNG file using imgSessionSaveBufferEx().


Here are a few observations that may be helpful.

1)  The frame grabber will recognize the first line received, regardless of the y offset.  For example, if one capture has a Y offset of '0', the framegrabber will capture the entire first line  (i.e. line count = 0).  If another capture has a Y offset of '8', the frame grabber will capture the entire 8th line (i.e. line count = 8).  This indicates to me that the framegrabber is correctly recognizing LVAL and FVAL signalling because for non-zero y offsets, the frame grabber will not capture the lines that are not in the ROI.  All further lines are not written to memory.  The x offset works correctly for the captured line.


2) I brought out IMG_TRIG_DRIVE_VSYNC, IMG_TRIG_DRIVE_HSYNC, IMG_TRIG_DRIVE_FRAME_START, and IMG_TRIG_DRIVE_AQ_IN_PROGRESS to the external TTL_TRIG lines on the 15-pin D-SUB connector and captured them with my oscilliscope.  All of these signals seem to behave correctly.

* AQ_IN_PROGRESS is asserted when imgSnap is called and is deasserted when the frame timeout is reached (6000ms in this case)

* FRAME_START is asserted shortly after VSYNC is asserted.  FRAME_START is deasserted shortly after VSYNC is deasserted 

* VSYNC is active during the entire frame readdown process and HSYNC is active during line readdown and deasserted between lines

* HSYNC and VSYNC matches LVAL and FVAL in my simulation. 


3) I have modified my design to accommodate the various timing requirements I have found on the NI forums and NI-IMAQ help files:

* Programmable delay between the assertion of FVAL and the assertion of LVAL for the first line.  The default is 16 pixel clocks.  I have tried various values, from 256 clock cycles to zero clock cycles (with SynchronizeEnables(Yes)).

* Programmable delay between the assert of LVAL.  The default is 16 pixel clocks.  Again, I have tried various values between 256 and 1 pixel clock. 

* Toggle LVAL 4 times prior the assertion of the FVAL at the beginning of the frame

* DVAL is tied high. 


4) If I cut the horizontal resolution in half and change the tap configuration to 1-tap, the frame grabber will capture all of the lines (only the even pixels because they occupy pixel A in the Camera Link base configuration).  This also indicates to me that the frame grabber is correctly interpreting the LVAL and FVAL signals.


4) If I drop the bit-depth down to 8-bits, I can capture the entire frame with the 2-tap, vertically interlaced configuration.  10-bit and 12-bit pixel depth configurations only capture the first line.


I have attached a '.icd' file that should my camera configuration. 


Any help would be appreciated.




0 Kudos
Message 1 of 6

Hello Craig,


I could not find any known issues with acquiring 12-bit images on the PCIe-1427. It is strange that you are able to acquire 8-bit images with no problems using the same LVAL and FVAL signals. I will have to discuss this with other engineers here and post again on this thread. I will let you know what I find out.

Vivek Nath
National Instruments
Applications Engineer

Machine Vision
0 Kudos
Message 2 of 6
Your help is greatly appreciated.
Here are another couple of data points:
6) I modified my camera to output 12-bit, non-interlaced pixel data on the camera link interface.  I modified my .icd file accordingly to change the camera configuration to a single 12-bit tap.  Strangely, the results are the same as the 2-tap configuration.  The frame grabber will only capture the first line in the ROI.  I had assumed that I would be able to capture the entire image because of 4th observation in my previous post (albeit at the cost of doubling the line readdown time).  If I drop the bit depth down to 8-bits, I am able to capture the entire image (10-bits does not work either). 
7) In my camera design, the lines are read out in two line "bursts".  By this I mean that two lines will be sent out one right after the other with only a small (programmable) number of cycles between assertions.  Then there will be a fair bit of time until the next two line "burst" is sent out.  Not sure if this could be contributing to this problem but I thought it might be pertinent (perhaps a buffer overflow?).  From my understanding that PCIe-1427 does not have a frame buffer, instead it relies on system memory to store the image data and assumes that PCIe bus will keep up with the camera link data.  Is there any chance the lack of onboard memory is contributing to this problem?

0 Kudos
Message 3 of 6

It is not easy to say what exactly is causing this behavior. There is nothing in the camera file that stands out as being incorrect. There are a few things I would like to know:

1) In 10-bit or 12-bit mode, is your image acquisition timing out or are you getting a black image after the first line?

2) What exactly happens to your LVAL, FVAL and pixel data signals in 12-bit pixel depth mode? Would you try monitoring these lines with an oscilloscope when generating 12-bit image data with your camera?


We might be able to isolate the problem with this information in hand.

Vivek Nath
National Instruments
Applications Engineer

Machine Vision
0 Kudos
Message 4 of 6

I can quickly answer #1.  Could it be both?  The image aquisition is timing out AND I am getting a black image after the first line.  I get the following error from imgSnap():

IMAQ Error: A timeout error occurred while waiting for the specified event.  If waiting for an image, verify that all video data is acquired within the timeout period.  If waiting for a signal, verify that the signal assertion occurs within the timeout period. 

In addition, the PNG file returned by imgSessionSaveBufferEx() has the first line with image data and all subsequent lines are black. 

I have a frame timeout of 6 seconds, far longer than the measured image readdown time.  


In regards to #2, I have take a little time to put together a timing diagram.  During the debugging process, I did monitor LVAL and HVAL (via the both HSYNC and VSYNC triggers on the frame grabber and the FVAL and LVAL test points from the FPGA on my camera).  As I only have a little two channel 60MHz scope, my visibility is limited, but I will do my best to capture an accurate timing diagram of the HSYNC, VSYNC, AQ_IN_PROGRESS, and FRAME_START signals on the frame grabber.  Perhaps it will provide the necessary insight.  

0 Kudos
Message 5 of 6
I will continue to assist you through the service request you have with us.
Vivek Nath
National Instruments
Applications Engineer

Machine Vision
0 Kudos
Message 6 of 6