Dr. Gerhard Holst, Research Manager and Martin Schwarzbauer, Development Engineer at PCO spoke to inspect about the development status of the Camera Link HS communication interface for high-speed cameras in comparison with CoaXPress. High-speed cameras are no use if the large volumes of data cannot be rapidly transferred to the computer. For this, two rival interface standards exist: CoaXPress and Camera Link HS. While CoaxPress is slowly becoming established, very little is heard about Camera Link HS, although the standard has several advantages over CoaXPress. What is the reason for this?

inspect: CoaXPress (CXP) is increasingly becoming the standard high-performance interface for connecting high performance cameras to computers, but hardly anything is heard about Camera Link HS (CLHS) as an alternative. IS the CLHS interface standard now dormant?

M. Schwarzbauer: On the contrary, it is now becoming fully awake! As CXP came onto the market earlier, manufacturers of cameras and frame grabbers paid more attention to this interface. Because of this, especially in the field of frame grabbers, a gap opened up which will gradually close in the future. As well as this, CXP and HSLink, the predecessor of CLHS were relatively similar. However, there are a few major differences and even advantages in comparison with CXP.

inspect: What are the most important differences or advantages of Camera Link HS in comparison with CoaXPress?

M. Schwarzbauer: There are several differences. However, the main difference lies in the cable connection between the camera and the frame grabber: At the moment CXP is heavily oriented to coaxial cables, while CLHS concentrates on optical cables. Optical cables are especially attractive, because the signal transfer is better. They are not sensitive to electromagnetic interference, they do not produce any interference themselves and they are easy to handle, light and cheap. The situation is different with coaxial cables. As well as this, with CXP, users are currently restricted to a maximum transfer speed of 6.25 Gigabit per second (Gb/s) and a maximum cable length of 68 m, depending on the type of cable. In contrast, with optical cables and CLHS the transfer distance is theoretically infinite and at present the maximum transfer rate is 10,3125 Gb/s. On the other hand, an advantage of CXP is power-over-cable, which means that there is the facility to use the data cable for the camera power supply. This is not the case with CLHS.

G. Holst: I would like to add something here. Coaxial cables for CXP are special cables which have been explicitly designed for this interface and are accordingly expensive, while CHLS uses the cheap standard network hardware of 10 Gigabit Ethernet (10 GigE). This not only applies to cable. With CLHS the transmitter and receiver are based on off-the-shelf Ethernet technology. In contrast, CXP uses special cable drivers for the camera and special cable receivers for the frame grabber, which are matched to the signal.

M. Schwarzbauer: For us, the main differences between the two high-performance interfaces are in the bandwidth, the scalability and the way in which reliable transfer is ensured, i.e. via the Resend and Forward-Error correction mechanisms. In terms of transfer reliability, CLHS is considerably better and more convenient than CXP.

inspect: Who is backing CHLS and what is the present status of the CLHS standard specification? What has already been implemented, what is planned and when will this become available?

M. Schwarzbauer: Of course, CLHS is backed by the Global Association for Vision Information AIA as the supporter of the standard. Teledyne Dalsa chairs the Camera Link HS sub-committee and provides HSLink as the basis of CLHS. Other companies which are actively working on the CLHS standard include JAI, Matrox Imaging, Silicon Software and PCO. With regard to the CLHS specification, Version 1.0 of March 2015 is the current version. There are the M and the X protocols. The main differences between these are the channel coding and the speeds. As with CXP, the CLHS-M protocol also uses 8B/10B coding with Packet-Resend mechanism, while in contrast the X protocol uses the considerably more efficient 64B/66B coding with Forward Error Correction (FEC). The higher protocol level (Message Layer) is identical with the M and the X protocols. However, I would like to focus on the X protocol, as this will be the future for high-performance interfaces. At present, there is intensive work on the CLHS specification Version 2.0, which should be complete in summer 2016, so that it will be officially available at the VISION exhibition in autumn 2016. There will be extensions in CLHS Version 2.0. For example, the actual image data will have a more universal structure than at present, so that in future 3D data will be able to be transmitted without problems. We consider this to be a great advantage. As well as this we have defined a function in order to measure the length of the cable or the time which a message requires for transmission via the cable. This is necessary for applications which involve very long distances to the camera, in order to determine the correct timeout values for the communication. In addition, the information can be used to compensate for signal propagation delays for Trigger-over-Cable, if e.g. several cables of different lengths are connected to a single frame grabber. This means that the frame grabber can cause a trigger event, which arrives at all of the cameras at precisely the same time in spite of different cable lengths. An additional extension are ROIs, i.e. detailed sections of the image within the image, which can be changed on-the-fly to obtain enlarged or shifted ROIs. These are the most important extensions with regard to the protocol. With regard to the hardware, further plug connectors are being discussed, e.g. QSFP plug connectors will be officially introduced so that a band width of 4.8 Gbyte/s can be obtained via a single plug connector for the X protocol.

inspect: What is the advantage of the fact that with CLHS the IP core is integrated into a Field Programmable Gate Array (FPGA)?

M. Schwarzbauer: This is also possible with CXP. However, a special feature of CLHS is that a Committee-IP core is provided. This can be obtained cheaply from AIA. Non-members of Camera Link HS pay a small fee of USD 1,000, while this is free of charge for members.  The Committee-IP core has a great advantage: If everyone uses this IP core, this ensures that everything is intercompatible. Then there are no different development levels and the same features are implemented. The objective is to enable device manufacturers to quickly implement the CLHS interface and therefore achieve a very short time-to-market. Once the hardware is ready, an experienced developer can integrate and use the IP core in the FPGA within a few days.  The IP core contains all of the features which are necessary to make a connection between two devices, i.e. including the previously mentioned Forward Error Correction. This considerably reduces the time which is required for the integration of CLHS. Many users have already benefitted from the integration of this IP core and the response is very good. As far as I know, with CXP each company develops its own IP core, or buys this somewhere for a lot of money, although under certain circumstances, this may not even meet their requirements. At this point I would like to emphasise that with CLHS, if FPGAs with 10 Gb transceivers are used, no external components are necessary as is the case with CXP. The SFP+ module (electro-optical converter) can be connected directly to the FPGA. Implementation of the hardware is therefore exceedingly simple.

inspect: What has been implemented in CL HS with regard to GenICam and what about interchangeability of devices regardless of the manufacturer?

M. Schwarzbauer: From the very start, GenICam was the focus of attention for the specification of CLHS.  Because of this CLHS fully supports GenICam. The communication protocol GenCP is used for registration access and the Pixel Format Naming Convention (PFNC) is used for the image data. With Version 2.0 the terminology of the CLHS specification is even better matched to GenICam. To my knowledge this is not stipulated with regard to the transport layer GenTL. This is used as a driver interface to frame grabbers. Ideally, for users this means that not only the camera can be exchanged 1:1 regardless of the manufacturer, but also that the frame grabber can be exchanged without having to modify the software. Each frame grabber manufacturer can decide whether it wants to support GenTL.

inspect: From what you say, a significant advantage of CLHS in comparison with CXP is the data security concept. Could you please explain this in more detail?

M. Schwarzbauer: One of the requirements of CLHS is the necessity not to lose data in case of individual bit errors. Because of this, mechanisms for the correction of bit errors were defined for Camera Link HS. There are two different solutions for the CLHS protocol: On the one hand, protocol information (Protocol Headers) is transferred several times (data redundancy) and on the other hand the application data (content of video and command data) are secured with a Cycle Redundancy Check (CRC) so that the data is re-sent in case of an error (Resend mechanism).
In contrast, the CLHS X protocol uses 64B/66B coding with Forward Error Correction. Due to the technology, channel coding on the Physical Coding Sub-Layer (PCS), there is no additional overhead due to the FEC. Therefore, for a physical coding block, up to 11 Bits can be corrected for block errors without an additional latency time. With the use of FEC and the elimination of the necessity for the Resend mechanism, the CLHS X protocol greatly simplifies implementation into the FPGA.
At present CXP does not use any error correction for video data. Otherwise the mechanisms are similar to those of the CLHS M protocol. It must be emphasised that the CLHS-M protocol and CXP use the 8B/10B protocol for channel coding. This means that here, on the lowest level, 20 % of the band width is “wasted” without any error correction measures. With 64B/66B channel coding, the CLHS X protocol is far more effective with only a 3 % loss of bandwidth.
inspect: For CLHS, special attention was placed on trigger capability. Why is that so and what are the advantages to users - for example with regard to line scan cameras?
For Teledyne Dalsa line scan cameras it is very important to be able to trigger these with a very high frequency of about 200 kHz with jitter which is as low as possible. The CLHS protocol was oriented to this. In addition, there was the requirement for direct control of the sensor. For example, with CLHS, different colours can be exposed for different times using the different trigger signals. CLHS not only uses high frequencies with low jitter of approx. 3 ns for triggering, but also the trigger packages, which contain the trigger information are very universally structured, so that various trigger events can be implemented. As has already been mentioned, with CLHS V2.0 the trigger characteristics will be extended so that the latency time of the cable or the entire transfer path can be determined. By using several trigger times, which depend on the latency time of the channel, the frame grabber can ensure that the cameras can be triggered at exactly the same time. This could be of great interest for 3D applications with several cameras.

inspect: What are the advantages of CLHS for multi-camera systems, 3D applications or multicast applications?

G. Holst: For multi-camera applications, the mechanical structure is much simpler with CLHS and we gain advantages in terms of performance and cost. Nowadays Big Data i.e. large data volumes are becoming the focus of attention, for example in all new microscopy methods. Up to now, the bottleneck has been between the camera and the computer. In the field of Life Science we have customers who use two of our sCMOS cameras simultaneously in microscopy applications. The image data has to be transferred to the computer very rapidly for further processing, analysis and evaluation. If this is implemented with conventional ‘Camera Link full’, this means that we need two cameras with two thick, rigid and expensive cables, as well as two frame grabbers. With CLHS we only use a single two-channel frame grabber and optical fibre cables, which only cost 50 Cent per metre. As well as this, with a data rate of 1 Gbyte/s for the pco.edge camera the data is transferred to the computer without compression.
For 3D applications, we must make a differentiation, as in this case there are very different solutions, for example 3D applications with stereo systems or with stereo systems and strip image projection. These are all applications in which large volumes of data must be transferred to the computer and calculated with precise synchronisation. CLHS is particularly attractive if the data needs to be transferred and processed quickly, for example with Aicon 3D Systems which record tyre movements with several cameras which are mounted on the car (Wheel  Watch System). Even in the first version, the CLHS protocol fully supports multicast applications in which data are transmitted to various computers and where different analyses have to be carried out.

inspect: PCO has already presented the first high-speed camera with CLHS at several exhibitions. Why has PCO got onto the CLHS bandwagon? Which characteristics were important?

G. Holst: From the start of CLHS a band width of at least 40 Gb/s was on the roadmap. That was not possible with CXP and is hardly possible even now. Because of this, we invested a great deal of time in order to introduce the 10 Gigabit layer, i.e. the X protocol into the CLHS specification. The interface was to be easy to handle and update and was to last for quite a while. We build sCMOS cameras. Here, the high data rate makes great demands on the interface and as well as this we have customers who require cable lengths of more than several hundred metres. For example, our CLHS camera is used in a linear accelerator at the exit points of the electron beam. As far as radiation is concerned, this is a very nasty environment. CXP is out of the question here.

inspect: So a scalable and future-proof camera solution is very important? What about the selection of the CLHS interface?

G. Holst: Our intention was to specify an interface which is easily scalable. Today’s requirements for transfer volumes are increasing rapidly and we do not want to have to design a new interface from first principles for every jump in speed. This meant that scalability was a very important point. Up to now, CLHS looks very good. With the pco.edge camera we have a single channel application and with the pco.flow we have a camera with four independent cables which can be connected to computer systems in any way. Due to CLHS it does not matter whether the four cables are connected to a single frame grabber or whether four frame grabbers are used for the camera.

M. Schwarzbauer: Above all, with regard to the future I would like to emphasise that standard components are used for CLHS, which is a great advantage of CLHS in comparison with CXP. This means that we are going with the flow with Ethernet. If speed requirements increase, CLHS will also benefit, because we use precisely the same hardware.  This minimises the investment risk. We use the lowest protocol level which is necessary for this technology. This has nothing to do with the Ethernet protocol as such, but only relates to the physical layer, which specifies where a data package starts and finishes. Therefore it is entirely conceivable that if in future optical modules for 25 GigE are available for the consumer market, we will also be able to use these 1:1. With CLHS we do not need to rely on any special hardware. In contrast, with CXP investment in new chips is necessary for each jump in speed. This is completely eliminated with us.
inspect: How do you estimate future developments. Is there not a danger that 10 GigE will force out both high-performance interfaces, CXP and CLHS?

G. Holst: Efforts are being made to run GigE Vision with 10 GigE. However, as far as I know, no manufacturer uses the full bandwidth of the interface. Above all, there is always a protocol overhead, which is needed so that the camera behaves in compliance with GigE or 10 GigE. In my opinion, this also involves a loss of scalability. 10 GigE may be possible for a PC, but as soon as there are several cameras or a camera with several 10 GigE connections, the PC very rapidly reaches its limits. As well as this, the complexity of the camera design increases due to the necessary Packet Resend buffer, which has already been mentioned. Because of this, cheap integration of this interface into a camera becomes increasingly complex.

M. Schwarzbauer: Another disadvantage of GigE or 10 GigE is that because the UDP protocol is used at network level, there is no safety layer, which means that data packages can be lost. Although there is a Resend mechanism in GigE Vision, this requires that the image data have to be temporarily saved in the camera. Installing a memory in the camera simply in order to eliminate such errors is too expensive. The faster the camera becomes, the faster the memory needs to be. This makes it very expensive to design the camera so that it matches the interface. 

inspect: What do you consider are the market opportunities for Camera Link HS in the future and on what do these mainly depend?

M. Schwarzbauer: All three interfaces, 10 GigE (Vision), CXP and CLHS will be on the market. Ultimately it is the camera or the application which decides which interface is best suited. If you are talking about genuine high-range, then CLHS will primarily have the advantage in the future. Above all this is because we can upgrade the speed more cheaply and easily than with CXP - and that is an enormous advantage.

G. Holst: Internally we have made a definite decision that our new cameras will all be equipped with CLHS. At present the FPGA is not suitable for low-cost use, as it needs a 10 Gb transceiver. However, if you compare this with CXP, CLHS is considerably cheaper. CXP is expected to have a 12 Gb/s model available by the middle of next year. CXP will then be equivalent to the CLHS X protocol with 10 Gb/s. However, high quality coaxial cable is considerably more expensive than optical cable. It is therefore obvious that a band width of 10 Gigabyte per second via cable is cheaper with CLHS. As well as this, within a few years CLHS will become even more attractive in comparison with CXP due to the use of off-the shelf Ethernet hardware products. As has already been mentioned, CLHS already includes a high quality Forward Error Correction with a net data rate of 1.2 Gbyte/s band width. Because of all the advantages which have been described, we expect that when the first systems with the CLHS X protocol come onto the market, the acceptance of CLHS will increase.