ASK THE EXPERTS
More Answers From Cliff Hayes
Camera Link exists as MDR and SDR terminations. I would like to get an adapter that converts either the MDR to SDR, or SDR to MDR, with the goal of stocking one cable type and adding the adapter to make the terminations match the application. Example: I have an MDR-MDR cable, and suddenly someone shows up with a SDR-equipped camera: Instead of buying and routing a whole new cable, I'd love to just convert the MDR to SDR. Note the worse case is if had an SDR framegrabber and SDR camera, I'd consume two adapters.
Yes, this is a question that comes up time to time regarding our RCX C-Link fiber optic Camera Link extenders. They have MDR connectors on them, but often times we need to connect them to cameras or framegrabbers with SDR connectors. For us it is fairly simple because it is usually a short cable that is needed and we stock the short MDR to SDR cables, but sometimes even the short cable adds too much bulk/length. In any event, I haven't found anybody who makes a small adapter for MDR to SDR. Maybe something akin to a gender changer, right? It's possible to design a small PCB with an MDR and SDR connector which could perform as an adapter, and I believe we had a customer do this. I don't know if anyone makes them commercially though, but some of our customers would definitely find them useful. The drawback I see is that the SDR connector is not as robust as the MDR connector, therefore having an adapter hanging off along with the cable/RCX C-Link might be a bit much for it to handle.
How is data transmitted over camera link affected by using cable lengths longer than the 10 meter limit typically specified? Is it just that the highest frame rates cannot be realized, but lower frame rates are possible? Or is it that the image integrity is compromised?
What Ron said is correct. It comes down to pixel clock frequency and how many bits you're sending per clock cycle. Higher clock frequencies and more bits per clock mean the error tolerances need to tighten up or else you'll get corrupted data. Therefore, cables generally get shorter as you go up with Camera Link modes and clock frequencies, however there are higher quality cables and active cables to address that. EDT makes Camera Link to fiber optic converters which can support the full range of Camera Link and get your around any cable length limitation you might come up against.
I'm developing an application for the acquisition by linescan with Xilinx ML605. I developed an IP that manages the LVD signal correctly. I can read the clock output from linescan and I can deserialize the data acquisition using a PLL. But, I have a problem with the correctly deserialization of data. I request the last update of Clink’s standard but I don’t find the position of data for deserialize. The problem consists in the identification of the bits of the pixels on the data lines. Thank you for your attention.
I think what you're looking for is covered by the specs on the National Semiconductor Channel Link transmitter and receiver chips. I'm looking at the Camera Link 2.0 spec and in section 7.0 Chipset Criteria, you'll see the specific National parts listed, such as: Transmitter: DS90LV047, 3.3V Receiver: DS90LV048, 3.3V I've found this Channel Link Design Guide from National useful: http://www.national.com/assets/en/boards/channellink_design_guide.pdf Email me if you can't get it.
Greetings, I have an FPGA board that has JPEG 2000 images stored in its memory and need to send the images to another device that has a Cemara Link standard-based interface. The Camera Link docuement explains the overall communication protocol: for example for a basic interface there are 3 8-bit pixel-data lines and 3 main control signals FVAL, DVAL, and LVAL. In my case, the images that I have are in the following format: meta data + byes of image data. In the case of basic interface, do I just load the image data 3 bytes at a time, put them in parallel on the pixel-data lines while the FVAL, DVAL, LVAL signals are raised until the end of image bytes? Is this the basic idea? Thank you in advance for your time, look forward to your kind reponse.
That is essentially correct. Typically DVAL is ignored unless needed (data that has too slow of a pixel clock for Camera Link, or to enable BINning for example) since LVAL and FVAL are sufficient in most cases. Most CL framegrabbers have an option to recognize or ignore DVAL. Also, of course, you'll need the output to be coming through the National Semiconductor Channel Link chips or equivalent. You could use EDT’s Camera Link Simulator to help you accomplish your goal here. We can output CL data via DMA through our board. We include a utility and its source code (send_tiffs) in our software package that allows you to send TIFFs from the host PC, through the CLS board and out to another CL device. What you would have to do is modify the existing code that reads in the TIFF to read in the JPEG instead. Our API/SDK is free and available on our website as well if you need further functionality. Please contact me if I can be of any further help.