01-19-2010 03:27 PM
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.
Thanks
Craig
01-20-2010 11:35 PM
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.
01-21-2010 01:57 AM
01-21-2010 03:09 PM
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.
01-21-2010 04:50 PM
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.
01-24-2010 09:07 PM