FLIR A6751 Support

[BigMuscle85]

We have camera FLIR A6751 connected to Raspberry Pi via Ethernet. Camera is correctly detected by Aravis by any streaming ends up errors.

> ./arv-camera-test
Looking for the first available camera
vendor name           = FLIR Systems ATS-US
model name            = Xsc Series
device id             = 
image width           = 0
image height          = 1
horizontal binning    = 0
vertical binning      = -1230552100
payload               = 0 bytes
exposure              = 0 µs
gain                  = 0 dB
gv n_stream channels  = 1
gv current channel    = 0
gv packet delay       = 0 ns
gv packet size        = 64 bytes
Can't create stream thread: GigEVision write_memory error (invalid-parameter)

> ./arv-device-test
Looking for the first available camera
vendor        = FLIR Systems ATS-US
model         = Xsc Series
device id     = 
sensor width  = 640
sensor height = 512
image width   = 0 (max:640)
image height  = 1 (max:513)
reverse x           = FALSE
payload size  = 0 (0x0)

** (arv-device-test:1054): CRITICAL **: 01:24:48.529: arv_stream_push_buffer: assertion 'ARV_IS_STREAM (stream)' failed

** (arv-device-test:1054): CRITICAL **: 01:24:48.529: arv_stream_push_buffer: assertion 'ARV_IS_STREAM (stream)' failed

** (arv-device-test:1054): CRITICAL **: 01:24:48.529: arv_stream_push_buffer: assertion 'ARV_IS_STREAM (stream)' failed

** (arv-device-test:1054): CRITICAL **: 01:24:48.530: arv_stream_push_buffer: assertion 'ARV_IS_STREAM (stream)' failed

Some log files: output.txt values.txt

Passing "./arv-camera-test -w 640 -h 512" has no effect. Is it possible to fix? Thank you.

[EmmanuelP]

gv packet size = 64 bytes

That is a strange value. Try to set it to 1500 with arv-camera-test: ./tests/arv-camera-test -i 1500

[BigMuscle85]

unfortunately, it has absolutely no effect and it still reports 64 bytes even with this parameter:

pi@raspberrypi:~/aravis/build/tests $ ./arv-camera-test -i 1500
Looking for the first available camera
vendor name           = FLIR Systems ATS-US
model name            = Xsc Series
device id             =
image width           = 0
image height          = 1
horizontal binning    = 0
vertical binning      = -1230814244
payload               = 0 bytes
exposure              = 0 µs
gain                  = 0 dB
gv n_stream channels  = 1
gv current channel    = 0
gv packet delay       = 0 ns
gv packet size        = 64 bytes
Can't create stream thread: GigEVision write_memory error (invalid-parameter)

[EmmanuelP]

Could you attach the output of ./arv-camera-test -i 1500 -d all and arv-tool-0.8 features ?

[BigMuscle85]

debug.txt features.txt

[EmmanuelP]

And arv-tool-08 control GevSCPSPacketSize -d all:3 ?

[BigMuscle85]

control.txt

[EmmanuelP]

I thought there was an issue with GevSCPSPacketSize bounds, but they look normal:

GevSCPSPacketSize = 192 min:46 max:16266

Could you attach the output of arv-tool-08 control GevSCPSPacketSize=1500 -d all:3, but please trim the beginning of the output until [ArvDomNode::append_child] Can't append '#text' to 'RegisterDescription' ?

[BigMuscle85]

There seems to be some problem with writing the values to the camera.

GevSCPSPacketSize_debug.txt

[EmmanuelP]

Please try this patch:

diff --git a/src/arvgcport.c b/src/arvgcport.c
index 56bd811..c76c6e5 100644
--- a/src/arvgcport.c
+++ b/src/arvgcport.c
@@ -98,6 +98,8 @@ _use_legacy_endianness_mechanism (ArvGcPort *port, guint64 length)
        ArvDomDocument *document;
        ArvGcRegisterDescriptionNode *register_description;

+       return TRUE;
+
        document = arv_dom_node_get_owner_document (ARV_DOM_NODE (port));
        register_description = ARV_GC_REGISTER_DESCRIPTION_NODE (arv_dom_document_get_document_element (document));

[BigMuscle85]

Excellent. Now it finally does something. Thank you.

pi@raspberrypi:~/aravis/build/tests $ ./arv-camera-test -i 1500
Looking for the first available camera
vendor name           = RILF
model name            =  csX
device id             =
image width           = 640
image height          = 512
horizontal binning    = 0
vertical binning      = -1230969892
payload               = 656640 bytes
exposure              = 0 µs
gain                  = 0 dB
gv n_stream channels  = 1
gv current channel    = 0
gv packet delay       = 0 ns
gv packet size        = 1500 bytes
  6 frames/s -    3.94 MiB/s - 13 errors
  0 frame/s  -       0 MiB/s - 31 errors
  3 frames/s -    1.97 MiB/s - 27 errors
  3 frames/s -    1.97 MiB/s - 17 errors
  0 frame/s  -       0 MiB/s - 25 errors
  3 frames/s -    1.97 MiB/s - 24 errors
  7 frames/s -     4.6 MiB/s - 34 errors
  1 frame/s  -   0.657 MiB/s - 15 errors
  1 frame/s  -   0.657 MiB/s - 38 errors
  1 frame/s  -   0.657 MiB/s - 37 errors
  1 frame/s  -   0.657 MiB/s - 25 errors
  0 frame/s  -       0 MiB/s - 25 errors

The second execution runs even without errors with speed over 80 MiB/s. I will check the image data and let you know the result.

[EmmanuelP]

Ok. This legacy stuff is causing troubles for a while. I have never managed to understand how to reliably check for the switch to legacy mode.

Could you send me privately at emmanuel@gnome.org the content of arv-tool-0.8 genicam.

Thanks.

[BigMuscle85]

File sent.

Now ./arv-camera-test -i 1500 works with full speed @ 640x512 125 Hz without errors. Viewer shows image correctly but framerate falls down to 20-30 Hz with tons of errors. When streaming at 320x256, it runs at 125 Hz without any error.

Unfortunately increasing MTU size above 1500 bytes is not supported on Raspberry Pi 4, but it's out of this topic.

[BigMuscle85]

I was able to increase MTU size to 9000 bytes, but any time I pass e.g. ./arv-camera-test -i 4096 packet size is reduced to 2023 bytes. Pass argument -j never sets the packet size correctly to the requested size but it results in hundreds of errors only and no image is received.

Camera is connected directly to Raspberry Pi. Is it possible to say what can cause this problem?

[EmmanuelP]

I guess you are using aravis master. This version now automatically looks for the highest allowed MTU if the default one does not work. After a quick search on the internet, 2000 seems the highest working MTU on the raspberry PI4.

What gives: ARV_DEBUG=device ./tests/arv-auto-packet-size-test ?

[BigMuscle85]

I recompiled Raspberry kernel to allow high MTU size, now I have

pi@raspberrypi:~/aravis/build $ ifconfig
eth0: flags=4163<AKTIVOVÁNO,VŠESMĚR,BĚŽÍ,MULTICAST>  mtu 9000
        inet 169.254.174.179 síťová_maska 255.255.0.0  všesměr 169.254.255.255
...

And the command returns

pi@raspberrypi:~/aravis/build $ ARV_DEBUG=device ./tests/arv-auto-packet-size-test
[GvDevice::new] Interface address = 169.254.174.179
[GvDevice::new] Device address = 169.254.180.237
[GvDevice::load_genicam] xml url = 'Local:flir_ntx_gige_fl01_pb0ip01_128bg_1_1_37_77A11FFC.zip;3fff8000;1546f' at 0x200
[GvDevice::load_genicam] Xml address = 0x3fff8000 - size = 0x1546f - flir_ntx_gige_fl01_pb0ip01_128bg_1_1_37_77A11FFC.zip
[GvDevice::load_genicam] Zipped xml data
[GvDevice::new] Packet resend = yes
[GvDevice::new] Write memory = yes
[GvDevice::new] Legacy endianness handling = no
[GvDevice::auto_packet_size] Try packet size = 576
[GvDevice::auto_packet_size] Try packet size = 8421
[GvDevice::auto_packet_size] Try packet size = 4498
[GvDevice::auto_packet_size] Try packet size = 2537
[GvDevice::auto_packet_size] Try packet size = 1556
[GvDevice::auto_packet_size] Try packet size = 2046
[GvDevice::auto_packet_size] Try packet size = 1801
[GvDevice::auto_packet_size] Try packet size = 1923
[GvDevice::auto_packet_size] Try packet size = 1984
[GvDevice::auto_packet_size] Try packet size = 2015
[GvDevice::auto_packet_size] Try packet size = 2030
[GvDevice::auto_packet_size] Packet size set to 2030 bytes
Packet size set to 2030 bytes on camera RILF-

[EmmanuelP]

Packet size set to 2030 bytes on camera RILF-

From aravis point of view, everything is normal. 2030 is the biggest packet that can be transmitted from the camera to your raspberry. This is determined by asking the camera to send test packets and check if the packets are actually received by aravis.

[BigMuscle85]

I have an additional question to see if the problem is caused by the packet size.

We have more FLIR cameras. Two of them support GigE and have frame rates 50 Hz and 125 Hz. When I run simple console application that does not display any image (e.g. arv-camera-test), I get full frame rate without any error (when packet size is set to 1500 bytes). But when I start displaying the image (e.g. arv-viewer or our application via OpenGL), the frame rate hardly reaches 30 frames/sec and I get tons of errors. And CPU usage goes to 100% very often.

But when streaming some other high-speed camera using different interface (e.g. FLIR 60 Hz USB 2.0 via v4l), it streams with full frame rate without any problem with CPU usage being under 50% all the time.

Can there be some performance problem in Aravis?

[EmmanuelP]

Good performance and reliability of GigEVision can be tricky to get. There is so many parameters to tweak: packet size, network physical layout, CPU availability for the stream receiving thread, stream congestion in case of several devices, network adapter performance. But once everything is tuned, it is possible to saturate a gigabit ethernet link using a few percent of a middle range CPU core.

Also, speaking of arv-viewer, I'm not happy with the performance of the GStreamer pipeline I'm using. It is certainly fixable, but did not have time to spend on this issue yet. I prefer to focus on Aravis as a library for use in other projects.

On the other hand, USB3Vision is easier to set up, and without special tuning, it is possible to get a reliable 150MB/s. Even in this case, there is room for improvement here, either by using libusb async API, which has started in https://github.com/AravisProject/aravis/pull/328, or by using National Instruments kernel driver https://github.com/ni/usb3vision

[EmmanuelP]

Ok. This legacy stuff is causing troubles for a while. I have never managed to understand how to reliably check for the switch to legacy mode.

In the genicam data, all register are defined as BigEndian. Schema claims 1.1.1.

Could you attach the beginning of the console output of arv-camera-test -d all, just before when image are received, with the device informations ?

I'm interested in seeing if the device is actually big endian or little endian.