How to avoid or minimize 'Maximum number of requests reached at'

Using Aravis
21

A packet resend request can be send several times, after the packet timeout is reached. The number of request and the the actual resends can be different.

How the frame are triggered ? Physically, using an electric signal ?

The machine has to write in a register periodically before the heartbeat timeout to keep the control of the camera.

22

Yes, and the timing is approximately 1 ms accurate.

So that is nothing to worry about, I think. Ok.

23

The following settings work quite well, almost no missed frames:

“packet-timeout”, 1500,
“frame-retention”, 25 * 1000,
“packet-request-ratio”, 2.0

auto socket buffer and two to eight arv buffers.

However, like I wrote down earlier, we are running with two camera’s and the output of the two camera’s must be stitched. With this settings, after some time the frame numbers start to divide. Sometimes after 1 hour of running, which is very odd. When we stop triggering, wait some time and start triggering again, the frame numbers are still out of sync. We do not understand why this happens and it’s hard to find out how to fix this.

The numbers:
Camera 1:

[GvStream::finalize] n_completed_buffers    = 51792
[GvStream::finalize] n_failures             = 1
[GvStream::finalize] n_timeouts             = 1
[GvStream::finalize] n_aborteds             = 0
[GvStream::finalize] n_underruns            = 0
[GvStream::finalize] n_missing_frames       = 0
[GvStream::finalize] n_size_mismatch_errors = 0
[GvStream::finalize] n_received_packets     = 95837884
[GvStream::finalize] n_missing_packets      = 1
[GvStream::finalize] n_error_packets        = 5
[GvStream::finalize] n_ignored_packets      = 35
[GvStream::finalize] n_resend_requests      = 81688
[GvStream::finalize] n_resent_packets       = 55408
[GvStream::finalize] n_resend_ratio_reached = 0
[GvStream::finalize] n_duplicated_packets   = 72588
[Stream::finalize] Flush 8 buffer[s] in input queue
[Stream::finalize] Flush 0 buffer[s] in output queue

[GvStream::finalize] n_completed_buffers    = 51802
[GvStream::finalize] n_failures             = 0
[GvStream::finalize] n_timeouts             = 0
[GvStream::finalize] n_aborteds             = 0
[GvStream::finalize] n_underruns            = 0
[GvStream::finalize] n_missing_frames       = 0
[GvStream::finalize] n_size_mismatch_errors = 0
[GvStream::finalize] n_received_packets     = 17355035
[GvStream::finalize] n_missing_packets      = 0
[GvStream::finalize] n_error_packets        = 0
[GvStream::finalize] n_ignored_packets      = 50
[GvStream::finalize] n_resend_requests      = 1639
[GvStream::finalize] n_resent_packets       = 623
[GvStream::finalize] n_resend_ratio_reached = 0
[GvStream::finalize] n_duplicated_packets   = 1315
[Stream::finalize] Flush 8 buffer[s] in input queue
[Stream::finalize] Flush 0 buffer[s] in output queue

We actually think about moving back to the proprietary driver (MVS), because we did no thave those problems with MVS. However, we would like to use open source software. What can we do to find out why it does not work or how can we use the same settings as MVS does so we do not have lost frames and unsynced frames etc?

24

Hi Maikke,

In the returned buffers, there is timestamp property set using the timestamp send by the device. Using this value you should be able to better understand what is the issue, and see if there is missed frames for example.

A missed frame can happen if the exposure time is too long, or because of a bad quality trigger signal. Sometimes there is feature to configure the trigger debouncing.

Emmanuel.