MATRIX VISION - mvBlueCOUGAR-X/-XD Technical Documentation
i.MX8M Mini

General

CPUARM Cortex®-A53 @ 1.6GHz
Cores4
RAM1 GB
USB2.0 Interfaces2
USB3.0 InterfacesNone
Ethernet1000 MBit
PCIe1 x 1 Lane
Gen 2.0

The carrier-board used in this test: MBa8Mx from TQ-Systems GmbH

Note
If you are looking for more information and guidance about installing mvIMPACT Acquire driver packages via the Yocto Project, please choose an API-manual suited for your programming language and then go to chapter "Installation From Private Setup Routines -> Embedded Linux -> Yocto Project". All API-manuals can be found under https://www.matrix-vision.com/manuals/.

Benchmarks

GigE Performance Test

Test setup

Additional Settings Applied On The System

To improve the data transfer between the camera and the ARM device the network buffers may need to be increased. The modification can be applied at runtime or can be included in Yocto recipes (sample recipes are given in chapter "Installation From Private Setup Routines -> Embedded Linux -> Yocto Project" of mvIMPACT Acquire API manuals).

In /etc/sysctl.d/62-buffers-performance.conf:

SettingValueDescription
net.core.wmem_max16777216Maximum memory size of a socket buffer for sending in Bytes
net.core.rmem_max16777216Maximum memory size of a socket buffer for receiving in Bytes
net.core.netdev_max_backlog10000Maximum number of packets which can be buffered if the Kernel does not manage to process them as fast as they are received

The importance of setting these parameters as above is explained here: Network Performance Settings.

Results

Note
The tests using GigE Vision™ device were conducted using a MTU value of 1500 Bytes. This limitation is caused by the default kernel which only supports MTU value up to 1500 Bytes. In this case, a reliable data transmission can only be achieved when NO de-Bayering is carried out on the host system. If de-Bayering is required on the host system, the transmission bandwidth (i.e. DeviceLinkThoughput) has to be limited (to e.g. 42[MB/s]) and the RequestCount has to be increased (to e.g. 30) to avoid frame loss. If the NIC supports jumbo frames, you can also increase the maximum supported MTU (to e.g. 8000 Bytes) by customizing the kernel to improve the performance when de-Bayering on the host system.
A Request in the mvIMPACT Acquire API represents a buffer where an image with the current device configuration is captured into. In order to avoid losing images at a high FPS, it's recommended to increase the number of these request buffers (i.e. ' RequestCount' in ' SystemSettings', by default the value is set to 10), so that the driver can continue capturing image data even if the host application is slower at processing an image than the camera transferring one.

The following scenarios have been tested:

  1. When de-Bayering is carried out on the host system: The camera delivers Bayer8 image data to the host system. The Bayer8 image data then get de-Bayered to RGB8 format on the host system. Due to the limited max. MTU of i.MX8M Mini, the transmission bandwidth (i.e. DeviceLinkThoughput) has to be limited and the RequestCount has to be increased to avoid frame loss in this case. Also see the Note above.
  2. When no de-Bayering is performed: The camera delivers Bayer8 image data to the host system. No de-Bayering is performed. This settings results in a lower CPU load and a higher frame rate. The behavior is identical to monochrome cameras.
CameraResolutionPixel FormatFrame Rate [Frames/s]Bandwidth [MB/s]CPU Load (averaged over 4 cores)
mvBlueCOUGAR-X104iC2064 x 1544BayerRG8 (on camera) -> RGB8 (on host)13.242~28.25%
mvBlueCOUGAR-X104iC2064 x 1544BayerRG8 (on camera) -> BayerRG8/Raw (on host)37118~22.6%