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.
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 :-)
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
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.
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.
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.
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.