CL acquisition hangs when image gets too bright?

[micahsimonsen]

I'm having a bit of a strange problem and I can't be sure whether it's the camera or the board: basically, in any run mode, when the image gets too bright, the aquisition stops and I get a timeout in MAX.This is with a PCIe-1433 and a Point Grey Gazelle. Capping the camera and restarting the acquistion works fine. This happens any time the majority of the image gets to ~80% brightness.

Making things more confusing, this can sometimes be fixed by switching cables (the same model 5 meter NI cable, but just a different one); now, however, I have a couple of cameras that exhibit this with any cable and so I need to get it figured out. It certainly might be a camera issue or some combination and so I'm contacting PGR as well. Anybody have any thoughts on this? Thanks in advance for any info!

[BlueCheese]

This certainly sounds very odd! I suggest being very methodical to try to characterize the problem, especially with regards to swapping out the cable. You could also do things like vary the exposure time or gain to try to force the error explicitly. Additionally, you could perhaps try to see what test image patterns the camera might be able to generate so you could hopefully remove sensor issues and on-camera-processing from the picture, and see if you can reproduce the same problems. Definitely keep us in the loop if you receive any suggestions from Point Grey to try out.

Eric

[muks]

since this is happening in max my guess would be cable or the camera. But still multiple cameras shouldnt be facing this issue. Please let us know if you hear anything

[micahsimonsen]

Thanks for the replies so far.

* If the brightness is overdriven with EITHER gain OR exposure OR aperture OR by shining a light in the camera, it can happen. 

* It seems that choosing different cables or a different camera can change the amount of overdrive required to do this, but it can always be forced.

* If I clip the acquisition window and overdrive outside the window, still happens. If I clip the ROI on-camera and overdrive outside that, does not happen.

* Strangely, in the NI camera file generator, a "Snap" will always succeed, no matter how bright. The "Grab" will fail with a timeout if the image starts too bright.

* Bit of a breakthrough. The gradient test pattern (which contains 16384 of each grey level) works fine no matter what I do with the physical camera. The pseudo-random pattern (Snap attached) causes this failure. 

* In 2-tap mode (which is a no go for frame rate, but I checked for troubleshooting) I can see the pseudorandom pattern with no problems, but overdrive still causes the initial issue.

Unless there's something really weird happening, this makes me think that the problem, such as it is, lies with the board. Something to do with how it is detecting blanking, or the end of the frame, is being fooled by the pattern? 

Thanks so much for the test pattern tip, BlueCheese, I still down have a fix but I know where to direct my attention now.

[BlueCheese · Accepted solution]

I'd suspect your CameraLink cables might not be meeting the performance requirements for the clock speed and distance you are running. Unlike most newer high-speed busses, the underlying encoding mechanism on the wire for CameraLink has a characteristic that the resistance to noise (even among its own pairs) is somewhat dependent on the actual data values being transmitted. Since the frame control signals are passed in the same channel as the image content itself, if there is some noise/interaction between them on the wire they could cause behavioral problems on the acquisition side.

If your camera supports lowering the clock frequenency you might be able to verify that this helps the behavior. If it does, I would recommend trying to replace the cables with higher-quality ones. The CameraLink committee now has an official certification test for cables that is very thorough. I'd suggest making sure the cables you use are actually tested to pass these certification tests.

Eric

[micahsimonsen]

You are the king!

Slowing the pixel clock of the camera from 40MHz to 20MHz fixes this totally (haven't tried intermediate values yet). This explains why switching the cables sometimes worked in the past - seems like maybe something slightly changed and now I can't find any that work.

These are NI 5m cables 199745A-05. If anyone has a source for extremely reliable 5m MDR->SDR cables I'd love to hear it but I'm sure I can work that from my end.

Thank you again! 

[BlueCheese]

Interesting... those NI cables should be high-quality ones....

I'm not that familiar with the Gazelle, but it is possible that it is following the new trend of not using the National Semiconductor chips for implementing the CameraLink physical layer but rather it might be using the outputs directly from an FPGA. This means some of the signal characteristics required are a bit different than what the CameraLink committee tests the cables against and is not fully specified [yet]. To my knowledge, the CameraLink committee is working to determine how to properly certify those designs such that they know independently-qualified cables will work with them. If your camera does in fact use this design, it is possible that the signal characteristics need a higher-quality cable than National Semiconductor-based designs. Keep in mind this is all pure speculation on my part. I am not aware of any specific circumstances where the NI cables have failed to meet reliability needs with existing cameras.

Eric

[micahsimonsen]

That would make sense; I generally have had good luck with these cables. And how's this for a Heisenbug (and a data point towards what you just said)... it's now starting to seem like just making the call to set the pixel click - leaving it at the maximum 40MHz - also solves the problem! No change in frame rate - still 140Hz at 4mp - but I can overdrive 100% of the image and it doesn't halt. A bit more experimentation needed but this one is proving to be slippery.

[BlueCheese]

I did confirm from Point Grey that the Gazelle uses an FPGA-based implementation rather than the National Semiconductor parts. This means that validation of the design for signal compatibility with third-party boards and cables is somewhat up to the vendor currently, since the electrical test requirements aren't formalized yet. I'd suggest talking to Point Grey's support team and see if they have any suggestions.

Eric