Camera Interfaces and Protocols
Here, we talk about three bus systems that combined cover a wide field in the digital camera world:
- IEEE 1394 , or FireWire, or i.Link , obviously now and in the future the standard for high-speed serial bus systems;
- Universal Serial Bus (or USB), which is very common with Web cameras ;
- Camera Link , a high-end parallel camera connection.
IEEE 1394 (FireWire)
IEEE 1394 is a serial bus system; it got its name from the standard IEEE 1394-1995 and was originally developed by Apple Computers under the name ADB (Apple Desktop Bus). Later it was called FireWire and, finding its way into Sony Notebooks and Desktop computers, i.Link.
A number of main advantages, such as hot plugging or bus self-configuration, were the reasons that 1394 established itself in (at least) the multimedia world. In particular, the combination camcorder and multimedia notebook is very common.
In this section, we discuss the fundamentals of the 1394 standard, as well as the 1394 digital camera specification, which naturally is very important for this image distribution chapter. Finally, we discuss how to get images into LabVIEW and IMAQ; by the way, we also do this for similar bus systems in the next sections. For more details see [26].
Fundamentals
The following enumeration summarizes the most outstanding features of 1394 (taken from [26] and slightly modified). Of these, the most important are discussed in the sections below.
- Scalable performance: IEEE 1394 currently supports speeds of 100, 200, 400, and 800 Mbit/s; an increase towards 1,600 and 3,200 Mbit/s is planned.
- Hot insertion and removal: Devices can be dynamically attached or removed from the bus without the system being powered down.
- Plug-and-play: Each time a device is attached or detached, the bus is reconfigured and reenumerated. This configuration does not require intervention from a host system (PC).
- Transaction types: Support is provided for isochronous and asynchronous transfers.
- Layered model: Communications are based on a transaction layer, link layer, and physical layer protocols, realized both in hardware and software.
- Support for 64 nodes: Sixty-four node addresses (0-63) are supported on a single serial bus. The node address 63 is used as a broadcast address.
- Peer-to-peer transfer support: Serial bus devices can perform transactions among themselves , without the intervention of a host CPU.
- Fair arbitration support: Arbitration ensures that isochronous applications are guaranteed a constant bus bandwidth, while asynchronous applications are permitted access to the bus according to a fairness algorithm.
- Cable power: Power available from the bus can be either sourced or sinked by a given node.
Figure 3.3 shows a typical 1394 bus structure, illustrating some important issues regarding the bus topology:
- Though the logical structure of the entire system is a bus, it is realized by a number of point-to-point connections. Nevertheless, all devices on the bus can be accessed by all the others.
- Usually, the number of ports of a single device varies from 1 to 3 so that devices can be connected to each other and no further devices, such as hubs, are needed.
- Repeaters, as shown in Figure 3.3, can be used to lengthen the bus cables. [1] Moreover, every device with more than one port can be used as a repeater, even when the device is powered off.
[1] The cable length, as specified in the standard, has a maximum of 4.5 meters. However, there are cables on the market with a length of 10 meters and they work fine.
Figure 3.3. Typical 1394 Bus Structure with Single- and Multiport Devices
1394 Devices
Figure 3.4 shows how a 1394 PCI card is listed in the Windows Device Manager. It depends on the high-level protocol where other devices appear; for example, a camera may be listed under Imaging Devices. Repeaters are not listed in the Windows Device Manager.
Figure 3.4. Windows Device Manager Listing 1394 Devices
The next figures show some 1394 devices that use different high-level protocols. For example, Figure 3.5 shows a Zip100 drive and a hard drive that use the SBP2 protocol for mass storage devices. Both drives have two 1394 ports each.
Figure 3.5. 1394 Zip100 Drive and 1394 Hard Drive
The 1394 cameras are naturally of interest for this book. Figure 3.6 shows an example of a Sony 1394 digital camera, which also was used for an example in this book. The digital camera specification and protocol are discussed later in this chapter.
Figure 3.6. 1394 Video Camera
Figure 3.7 shows two 1394 repeaters, one of them without housing. The integrated circuit on the circuit board is the phy chip , responsible for the 1394 physical layer. Real 1394 devices need at least one additional IC, the link chip , responsible for the 1394 link layer. Important for the functionality of the bus is that the phy chip can be powered over the bus, thus enabling repeating functionality even when the device is powered off.
Figure 3.7. 1394 Repeater (1STT Components; www.1stt.com)
The link chip is shown in Figure 3.8 on the left circuit board. On the right board, the link layer as well as the transaction layer were integrated in an FPGA. Both boards represent examples of 1394 interface boards using the PC104 form factor.
Figure 3.8. 1394 PC104 Boards (1STT Components; www.1stt.com)
1394 Communications
As mentioned before, IEEE 1394 supports two data transfer types:
- Asynchronous transfers do not require delivery at a constant data rate. They do not require a constant bus bandwidth and therefore do not need regular use of the bus, but must be given fair access over time. Moreover, they require a response from the target node, resulting in an additional transaction. Typical examples for asynchronous transactions are control commands to a device or data to be stored on mass storage devices, such as hard drives.
- Isochronous transfers require data delivery at constant intervals. Here, not a unique device address but a channel number is defined, and the data is streamed to one or more nodes responding to this channel number. These transfers require a guaranteed bandwith and therefore regular bus access, and they have higher bus priority than that of asynchronous transfers. Typical examples are audio or video data streams.
The bus bandwidth allocation is based on a 125 m s interval called the cycle period. In this interval, a mix of isochronous and asynchronous transactions can share the overall bus bandwidth. As shown in Figure 3.9, isochronous transfers are based on a 6-bit channel number, which are used by isochronous listeners to access reserved areas of memory buffer.
Figure 3.9. Isochronous and Asynchronous Transactions[26]
Asynchronous transfers target a particular node and are all together guaranteed a minimum of 20% of the overall bus bandwidth. This implies that a particular node is not guaranteed a particular bandwidth but is guaranteed fair access to the bus; this mechanism is explained later.
The resulting maximum data payload size for both asynchronous and isochronous transfers is shown in Table 3.2.
Table 3.2. Maximum Data Payload Size for Asynchronous and Isochronous Transfers
Cable Speed |
Maximum Data Payload Size (Bytes) |
|
---|---|---|
Asynchronous Transfers |
Isochronous Transfers |
|
100 Mbit/s |
512 |
1024 |
200 Mbit/s |
1024 |
2048 |
400 Mbit/s |
2048 |
4096 |
800 Mbit/s [ |
4096 |
8192 |
1.6 Gbit/s [ |
8192 |
16384 |
3.2 Gbit/s [ |
16384 |
32768 |
[
[
As indicated above, the hardware and software implementation is realized by four protocol layers , each equipped with a set of services for communication purposes with the application:
- Bus management layer: It provides bus configuration and management activities.
- Transaction layer: Here, only asynchronous transfers are processed . Each transaction consists of a request subaction and a response subaction.
- Link layer: It provides translation of transaction layer request or response, address and channel number decoding, and CRC error checking.
- Physical layer: It provides the electrical and mechanical interface for the transmission of the raw data transferred over the bus.
Read more about 1394 communication in [26].
1394 Cables, Connectors, and Signals
The IEEE 1394 standard cable consists of two 6-pin connectors and a single 6-pin cable. The connectors on both sides of the cable are identical, unlike other systems, e.g., USB.
Figure 3.10. 1394 6-Pin Connector (Plug and Socket)
Cross sections of this 6-pin connector (plug and socket) are shown in Figure 3.10. Two of the six wires carry bus power (VP and VG); the other four form two twisted wire pairs named TPA/TPA* and TPB/TPB*.
Figure 3.11. 1394 4-Pin Connector (Plug and Socket)
Later, a 4-pin connector was designed by Sony especially for hand-held or battery operated devices, for example, camcorders, since such devices do not need to draw power over the bus (Figure 3.11). These cables consist only of the two twisted wire pairs. Moreover, the small 4-pin connector fits better into small designs.
So, 1394 supports three different types of cables:
- standard cables with identical 6-pin connectors on both ends;
- cables with identical 4-pin connectors on both ends, for example, for connecting a camcorder to a notebook PC;
- cables with a 4-pin connector on one end and a 6-pin connector on the other end.
Figure 3.12 shows cross sections of the required cable types; naturally, the cables with 4-pin connectors and 6-pin connectors require only four conductors.
Figure 3.12. Cross Sections of 4-Conductor and 6-Conductor Cables
The signaling over the two twisted wire pairs is based on data strobe encoding (DSE); see Figure 3.13. If one of the twisted pairs carries the data, the other one carries a strobe signal, which can be used to derive a clock signal by an XOR operation. The main advantage of this encoding is that only one of the two signals changes state at a time, thereby reducing electromagnetic interference.
Figure 3.13. Data Strobe Encoding
1394 Bus Configuration
The main difference from other bus systems like USB is that 1394 can work without a host processor. This enables a number of configurations, such as direct data streaming from a camera to a hard drive if an appropriate protocol is installed on both devices. On the other hand, the bus has to perform a number of procedures:
- bus initialization (bus reset),
- tree identification, and
- self-identification.
A bus initialization or bus reset occurs when power is applied to a node or removed from a node or when a node is attached to or removed from the bus; these occurrences force all nodes to return to their initial states. This reset clears all topology from the nodes and prepares all nodes to begin the tree identification process.
The tree identification process redefines the topology of the bus in accordance with the new device situation. After the process, a single node will be the root node and therefore each port will be identified as a parent or a child. [2] Any node can become the root node regardless of where it connects into the network of nodes.
[2] A port identified as a child node points to a node that is farther away from the root.
After that, the self-identification process begins, during which all nodes select a unique physical ID and return self-ID packets that identify themselves and parameters that describe their capabilities. Figure 3.14 shows an example of a 1394 bus topology using a FireWire data analyzer.
Figure 3.14. Example of a 1394 Bus Topology
1394 Bus Management
After the completion of the configuration process, nodes have to be found to take over certain roles in the bus management process. The following tasks are defined in the 1394 specification:
- Cycle Master initiates the start of isochronous transactions at regular 125 m s intervals.
- Isochronous Resource Manager tracks the number of isochronous channels available and the amount of isochronous bus bandwidth available and allocates these resources when requested by serial bus nodes.
- Bus Manager publishes maps that specify the topology of the serial bus and that indicate the maximum packet speed supported by each cable segment in the system and other tasks [26].
Another process described here among the bus management features is arbitration , which means that each node is guaranteed fair access to the bus. Both isochronous and asynchronous arbitration processes are possible; the isochronous process simply guarantees a certain amount of bus bandwidth; therefore, we talk only about the asynchronous process.
The process of asynchronous fair arbitration is based on the following three items:
- The fairness interval ensures that each node needing to initiate a transaction gets fair access to the bus. It has to be ensured that each node that has an asynchronous transaction pending is permitted to obtain bus ownership once during each fairness interval.
- The arbitration enable bit of a node must be cleared after its asynchronous transaction has started. The reason is that once a node has performed an asynchronous transaction, it is not allowed to request bus ownership until the next fairness interval begins.
- The arbitration reset gap follows the fairness interval and sets all arbitration enable bits again. Note that the arbitration reset gap occurs automatically after all nodes have finished their transactions and all arbitration enable bits are cleared.
Power Management
The power distribution part of the 1394 specification defines four different types of node power classes:
- power providers,
- alternate power providers,
- power consumers, and
- self-powered nodes.
For example, an industrial camera or a repeater is a power consumer; a video camcorder is a self-powered node.
1394 Digital Camera Specification
Especially interesting for our application field is the specification for 1394 cameras. You can download the entire document from www.baslerweb.com or www.1394ta.org.
Figure 3.15 shows an example of an isochronous stream packet carrying 4:4:4 YUV video data. The first two lines, containing the header and the header CRC, are identical in every isochronous stream packet; [3] the rest of the lines contain the video data payload.
[3] The content of the fields is not discussed here; read more about it in the specifications or in [26].
Figure 3.15. Isochronous Stream Packet (Video Data YUV 4:4:4)
Another important field is the setting of some important camera values (here called features), such as Brightness, Sharpness, Hue, Saturation, Focus, Zoom, and some more, which are located in the register area. Again, details can be obtained from the specifications; but we see in the next section that a detailed knowledge of these issues is not important, because LabVIEW performs a number of tasks for us.
1394 Images in LabVIEW
Using images from 1394 cameras in LabVIEW and IMAQ Vision is easy since National Instruments released a special plug-in for IMAQ Vision called "IMAQ Vision for 1394 Cameras." If this tool is installed, the IMAQ Vision Builder offers an additional acquisition module called "NI-IMAQ for IEEE-1394." If this module is selected, images can be acquired from the 1394 camera just as from any other vision device.
Definitely more interesting is that some properties of the camera, such as Zoom, Focus, Brightness, and others, can directly be set by a control in the IMAQ Vision Builder (see Figure 3.16). The camera then reacts immediately to the property change. Of course, this is also possible directly from LabVIEW; we try it in the following exercise.
Figure 3.16. 1394 Camera Image and Properties in IMAQ Vision Builder
Exercise 3.1: 1394 Camera Images (1394 camera required).
Create a LabVIEW program that captures an image from a 1394 camera and changes some camera attributes. For the image capturing use the functions IMAQ1394 Grab Setup , IMAQ1394 Grab Acquire , and IMAQ1394 Close (see Figure 3.17).
The properties of the camera can be changed with the function IMAQ Vision Attribute . The camera property is selected with the Attribute control and the value can be transmitted by the respective slider control.
Figure 3.17. Setting 1394 Camera Properties in LabVIEW
In general, 1394 cameras are a great opportunity for vision engineers , especially if you consider the digital image transfer, the asynchronous transmission of camera properties, and the camera power supply, all of them using a single 6-wire serial cable.
Universal Serial Bus (USB)
The Universal Serial Bus (USB) was intended to make an end with the number of PC interfaces: There were (and still are!) the serial (or RS-232) port, the parallel port, PS/2 ports for keyboard and mouse, and some other interfaces inside the PC itself. The main idea was to use only a single interface (e.g., USB) for all these connections.
The reason why this vision has not come true was the relatively low data rate of 12 Mbit/s, which has turned out to be a major disadvantage of USB, especially if mass storage devices (hard drives or CD writers) are connected to a system.
Anyway, USB is established with a certain number of devices, such as mice, some disk drives, keyboards, and (of interest for us) cameras. In the following sections, I explain some fundamentals and key data of USB, some examples of USB devices, and some details, which include the physical, the signaling, and the data environment. Finally, I mention the new standard USB 2.0 and what it means to the existing USB world.
Fundamentals
USB can connect up to 127 devices with a host. The USB standard 1.1 distinguishes between two types of devices:
- devices such as mice, keyboards, cameras, which are called functions ;
- USB hubs, which provide one or more ports for the connection of other devices.
Figure 3.18 shows how these devices are listed in the Windows Device Manager: the USB controller itself, which today is usually integrated in the PC main board, the USB root hub, and the devices (here a mass storage device) appear in the same submenu.
Figure 3.18. Windows Device Manager Listing USB Devices
This structure can again be seen in Figure 3.19. The controller, usually a PCI card, integrates the USB host controller and the USB root hub, to which all other devices or hubs must be connected.
Figure 3.19. USB Hub Types [27]
Figure 3.19 also shows that the USB structure is a tree type; starting at the host (root), the additional hubs or devices form branches or leaves . Therefore, as shown in Figure 3.20, two data directions can be specified:
Figure 3.20. USB Hub Performing Downstream and Upstream Connectivity [27]
- upstream (to the host);
- downstream (from the host).
Two different types of plugs ensure that these directions cannot be mixed; mixing them would result in a forbidden loop structure: in the upstream direction the well-known (flat) A-plug, and downstream the almost quadratic B-plug. Read more about cables and plugs in Physical Environment .
Another limitation (besides the maximum of 127 devices) is the number of tree levels, which is limited to seven, including the root hub. This implies that the number of hubs connected logically in series is limited to five.
USB Devices
Any USB communication can be performed at one of two (three with USB 2.0) speed levels:
- low speed (1.5 Mbit per second);
- full speed (12 Mbit per second);
- high speed (only USB 2.0; 480 Mbit per second).
This results in a number of tasks that USB hubs have to perform. (Figure 3.21 shows a typical USB hub.) Usually a hub has to do the following tasks:
Figure 3.21. USB Hub with Four Ports
- repeat data arriving at its ports in upstream or downstream direction; [4]
[4] A device that performs only this function is called a "repeater.".
- recognize devices attached to its ports;
- intercede between the different bus speeds;
- distribute and control power to its ports. This is an important issue and results in the big advantage that devices connected to a USB port need not have their own power supply. Therefore, the hubs are divided into two types:
- bus-powered hubs, which receive their own energy from the bus. They are limited by the amount of power they can get from the bus and can therefore supply a maximum of four ports.
- self-powered hubs (no limitations concerning power).
Moreover, the USB specification defines a number of device classes, which are listed below. This list is taken from [27] and does not give any information about the definition state of the device classes; that means that some specifications are not yet released.
- Audio Device Class: Devices that are the source of real-time audio information.
- Communications Device Class: Devices that attach to a telephone line (not local area networks).
- Display Device Class: Used to configure monitors under software control.
- Human Interface Device Class (HID): Devices (mice, keyboards) manipulated by end users.
- Mass Storage Device Class: Devices (floppy drives, hard drives, and tape drives) used to store large amounts of information.
- Image Device Class: Devices that deal with images (either still or moving).
- Physical Interface Device Class (PID): Devices that provide tactile feedback to the operator. For example, a joystick with variable resistance for simulating increased stick forces and turbulence.
- Power Device Class: Devices that provide power to a system or to peripherals. For example, uninterruptable power supplies and smart batteries, which can be either stand-alone devices or integrated into the interface.
- Printer Device Class: May be merged with storage device class.
Figure 3.22 shows an example for a USB camera and for a USB mass storage device.
Figure 3.22. USB Mass Storage Device and USB Camera
Physical Environment
The cross section of USB cables is shown in Figure 3.23. The cable on the left is intended only for low speed (1.5 Mbit/second) and does not require shielding. For low speed, the cable length should not exceed three meters.
Figure 3.23. Cross Sections of Low-Speed and High-Speed USB Cables [27]
Full speed (12 Mbit/second) USB cables must be both shielded and twisted pair for the differential data lines (right side of Figure 3.23). The maximum cable length for full speed is five meters if the signal propagation delay is equal to or less than 30 ns over the entire cable length. If the propagation delay is higher, the cable must be shortened [27].
The other two wires that can be seen in the cross sections carry cable power, which is 5 Vdc and can provide from 100 to 500 mA. A number of peripherals do not need this cable power, for example, printers. Finally, Figure 3.24 shows a USB cable illustrating both an A- and a B-plug.
Figure 3.24. USB Cable with A- and B-Plug
Signaling Environment
The USB standard uses a special type of data encoding called NRZI (non-return to zero, inverted). This encoding and the use of differential signaling, which is shown in Figure 3.25, ensure data integrity and significantly decreases noise problems.
Figure 3.25. USB Cables Using NRZI Encoding and Differential Signaling [27]
Other tasks are performed by the monitoring of the differential data lines:
- detection of device attachments and detachments by monitoring the voltage levels of the differential data lines;
- detection of the possible device speed (low or full speed; full speed devices have a pull-up resistor on the D+ line, low speed devices have it on the D- line).
You can find more details about NRZI in [27].
Figure 3.26 shows the NRZI data encoding itself. The Data line shows the original data, and the NRZI line contains the encoded data; the NRZI signal remains at its status when data is 1 and changes status when data is 0.
Figure 3.26. NRZI Encoding [27]
A problem may occur if the data contains a large number of consecutive 1s. Therefore, after six consecutive 1s, a transition of the NRZI signal is forced, thereby ensuring that the receiver can detect a transition in the NRZI signal at least at every seventh bit. The transition is forced by additional bits in the data stream, resulting in a stuffed data stream. This method is called bit stuffing .
Data Environment
The USB specification defines four transfer types [27]:
- Interrupt transfer: Interrupt transfers are linked to devices usually using interrupts for their communication, such as mice and keyboards. Because USB does not support hardware interrupts, these devices must be polled periodically.
- Bulk transfer: Sending data to a printer is a good example of a bulk transfer: It is a large amount of data, but it does not have a periodic or transfer rate requirement.
- Isochronous transfer: Isochronous transfers require a constant delivery rate (similar to IEEE 1394). They are used, for example, for video or audio data.
- Control transfers: Control transfers are used for the transfer of specific requests to USB devices. They are mostly used during the device configuration process.
Individual transfers consist of a number of packets, which are themselves combined with transactions. Packets are categorized into four types:
- Token packets are sent at the beginning of a USB transaction to define the transfer type.
- Data packets follow token packets in transactions with data payload to or from USB devices.
- Handshake packets are typically returned from the receiving agent to the sender, thus providing feedback relative to the success or the failure of the transaction. In some cases, the USB device being requested to send data to the system may send a handshake packet to indicate that it currently has no data to send [27].
- Special packets: An example of a special packet is the preamble packet, which enables low-speed ports.
The transactions are divided into three categories:
- IN transactions,
- OUT transactions, and
- Setup transactions.
Moreover, the communication at the application level takes place over pipes , which act as logical channels and connect the application with a virtual end point at the USB device, no matter whether the device is connected directly to the root hub or to one or more additional hubs.
You can read more about pipes, transfers, transactions, and packets in [27].
USB 2.0
Version USB 2.0 of the Universal Serial Bus adds the following amendments to the standard:
- The (already discussed) high-speed standard with 480 Mbit per second;
- The additional task for 2.0 hubs to negotiate between different speed modes;
- The necessity for split transactions if a USB 2.0 host has to communicate with a slow full-speed device.
The other principles of the standard as well as the cables remain unchanged.
USB Images in LabVIEW
Getting images from USB cameras into LabVIEW and IMAQ Vision is not as easy as it is with 1394 cameras; the reason is simple: IMAQ Vision does not support USB. Here, we have to use some tricks, providing the following functions:
- Display the image from the USB camera in a resizeable window.
- Somehow capture the image from this window and copy it to the PC's clipboard.
- Read the image from the clipboard and display it in an IMAQ Window.
For functions 1 and 2, we need additional software:
- For displaying the image from the USB camera, you can use any proprietary software that came with your camera; or, you can also use a tool like graphedt.exe , which is part of Microsoft's DirectX SDK and can be downloaded from http://www.microsoft.com. This tool lists all of your imaging devices and displays an image in a video renderer window (see also Figure 3.27).
Figure 3.27. Importing USB Camera Images in LabVIEW
- Transferring the image into the clipboard is not easy. I suggest that you use a software tool like ImageXpress from Pegasus Software (http://www.pegasustools.com). The trial version will work here. After the package is installed, you can import an additional ActiveX control in LabVIEW; for example, if you downloaded version 6 of ImageXpress, it is called IMAGXPR6Lib.IImagXpress.ctl .
With this equipment, we can do the following exercise.
Exercise 3.2: USB Camera Images (USB camera and additional software required).
Create a LabVIEW VI that captures an image from a USB camera (Figure 3.27). Use a special software tool (e.g., graphedt) for the image display and another (e.g., ImageXpress) for the capture.
After importing the ImageXpress ActiveX control into LabVIEW, use the methods Capture and Copy through two LabVIEW Invoke Nodes. Note that the image, which should be captured and copied , must be placed over the ActiveX control in the LabVIEW Front Panel window. For optimization, the control itself can be resized to fit the display window.
Once the image is stored in the clipboard, it can be transferred into an IMAQ Window with the function IMAQ ClipboardToImage . See Figure 3.27 for further details.
Camera Link
Although Camera Link is not really a bus system ”because it is only used for connecting a digital camera to a frame grabber ”it is discussed. The Camera Link interface is important for digital video systems because it allows really high data rates.
Figure 3.25 on page 102 shows the use of differential signaling for USB purposes. The main advantage of this technology is immunity from disturbance and interference signals from outside of the cable area. Imagine a disturbance signal that influences both of the signal wires; because only the signal difference of these two wires is used, the disturbance signal is (more or less) deleted in the subtraction result.
Camera Link uses this technology as well. Here, a standard called low voltage differential signaling (LVDS) is used for the cable transmission. National Instruments introduced a system called Channel Link , consisting of a transmitter (converting 28 bits of CMOS/TTL data into four LVDS streams) and a receiver (converting the streams back to CMOS/TTL). In addition, a phase-locked clock is transmitted over a fifth LVDS stream. The major advantage is the significant reduction of the number of wires from the transmitter to the receiver, resulting in smaller connectors and cable outlines.
Figure 3.28 shows the base configuration of the Camera Link interface, which is based on Channel Link. In this configuration, a single transmitter/receiver pair is used together with four separated LVDS streams reserved for general-purpose camera control and two LVDS pairs reserved for serial communication between camera and frame grabber.
Figure 3.28. Camera Link Block Diagram (Base Configuration)
The base configuration, using a single transmitter/receiver pair, is limited to 28 bits of video data, which may not be sufficient for all purposes. Figure 3.29 shows the extension of the Camera Link interface to a medium configuration, which includes another transmitter/receiver pair, and to a full configuration, using in total three Channel Link transmitter/receiver pairs.
Figure 3.29. Camera Link Block Diagram (Extension for Medium and Full Configuration)
Table 3.3. Camera Link Configurations
Camera |
Ports A,B,C |
Ports D,E,F |
Ports G,H |
|
---|---|---|---|---|
Control Lines |
(X0-X3, Xclk) |
(Y0-Y3, Yclk) |
(Z0-Z3, Zclk) |
|
Base configuration: |
Yes |
Yes |
||
Medium configuration: |
Yes |
Yes |
Yes |
|
Full configuration: |
Yes |
Yes |
Yes |
Yes |
Table 3.3 is an overview of all three possible configurations. The base configuration requires one single MDR cable; medium and full configuration both require two MDR cables.
Camera power is not provided through the Camera Link connectors, but it can be supplied to the camera through a separate connector. In fact, most of the camera manufacturers use their own standards.
You can get more information about Camera Link from a number of suppliers, for example, from www.basler-mvc.com.
Comparison of Digital Camera Interfaces
Now that we have discussed the most important bus systems for imaging applications in detail, we can extend Table 3.1 and compare in Table 3.4 the most interesting features of the three camera interfaces.
Compression Techniques
|