Camera Link i/f spec - signal requirements on FVAl/LVAL/DVAL

Hi - Can someone point me to where FVAL, LVAL, DVAL relationship requirements are? I look at the i/f spec on alacron.com, but it doesn't list any.

I'm looking for something like After FVAL goes valid, LVAL should go valid within one line time, after LVAL goes valid, DVAL should go valid withone one pixel time, etc.

Thanks.

Reply to
fastgreen2000
Loading thread data ...

Have you read the camera link specs ? If I remember correctly (I haven't used camera link for years), there are many possible FVAL/LVAL/DVAL modes. FVAL/LVAL can be edge or level sensitive. Most camera link devices are configurable to accommodate several modes of operation. The real fun begins when you find out that your camera and your frame grabber don't support a single common mode :-)

Best regards,

Laurent Pinchart

Reply to
Laurent Pinchart

I don't think there are any. I've always assumed not - just do something like:

  • Once FVAL has gone high, you are ready to start a frame.
  • When LVAL has gone high (which may be in the same cycle as FVAL going high) you have the start of a line., set X to 0. If waiting for start of frame, set Y to 0 also, otherwise incrememnt Y
  • Whenever DVAL is high, increment X, and do something useful with the data.

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Reply to
Martin Thompson

Technology

formatting link

It gets more complex than that depending on the camera. I find it is safest to use (not LVAL) as a clock enable for FVAL. There are some cameras that allow FVAL to go inactive before the end of the last line of the frame. Also you need to be able to selectively ignore DVAL. Some cameras do not provide this signal, others only assert it during LVAL, so you can't use it as a clock enable for the control signals.

There is no minimum specification for FVAL to LVAL assertion. Assume they can go active on the same cycle. Also assume there is no maximum FVAL to LVAL timing. Furthermore LVAL may or may not be asserted between frames while FVAL is low.

And of course last but not least, there is a "Basler" extension to the Full Camera Link spec that allows

80 bits of data per clock (Camera Link only goes up to 64 bits) by completely re-numbering the data outputs and only replicating the LVAL signal on the 2nd and 3rd Channel-Links. You also lose the DVAL and SPARE signals in this mode, and FVAL is only on the first Channel-Link. Basler is no longer the only camera maker to use this mode.

HTH, Gabor

Reply to
Gabor

Technology

formatting link

Another point. If you are designing a camera, or camera-like device you intend to hook to a framegrabber, it helps to make these signals well-behaved as follows:

1) Don't use DVAL as a data enable unless you need to reduce your clock speed below the Channel link minimum. Many framegrabbers expect data on every clock during LVAL. The best approach is to tie DVAL high. 2) Allow several clock cycles from assertion of FVAL to assertion of LVAL for the first line. Leave FVAL asserted until a few cycles after deassertion of LVAL for the last line. 3) Don't assert LVAL while FVAL is deasserted.

4) Make all lines (assertion period of LVAL) the same length. If your data does not represent a rectangular array, re- format it to fit this.

5) Provide the same number of lines in each frame.

You can violate any of these rules as necessary, but realize that for each one you violate your list of compatible framegrabbers gets shorter.

Reply to
Gabor

Ooh, fun - I haven't seen one of those!

True.

And I recall a JAI camera which had LVAL and FVAL active low!

Maybe I'll look at Firewire for our next camera interface :-)

Any decent link layer/phy combined chips out there which I can get in prototyping volumes and haven't got to mess with PCI for?

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Reply to
Martin Thompson

I'm doing exactly that - sending video data as if I'm the camera, to the frame grabber.

The only thing I'm not doing is #2 above. All my valids line up, LVAL and DVAL identical. All transitions occur at the rising edge of CLK.

I guess it's time to call the frame grabber maker...

Thanks.

Reply to
fastgreen2000

I'm doing exactly that - sending video data as if I'm the camera, to the frame grabber.

The only thing I'm not doing is #2 above. All my valids line up, LVAL and DVAL identical. All transitions occur at the rising edge of CLK.

I guess it's time to call the frame grabber maker...

Thanks.

Reply to
fastgreen2000

To use National Instruments framegrabbers with their IMAQ software, you have to follow specific rules, one of which requires the camera to toggle LVAL four times before the start of each frame. What's amazing is that this really important piece of information is buried in the help file for their Camera File Generator program and their wonderful front-line tech support people don't know about it.

Apparently this toggling clears the FIFO in the framegrabber's FPGA, or something. If you don't do it, then images aren't displayed properly.

-a

Reply to
Andy Peters

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.