This could be an issue with a bad transmission medium.
Have you tested your cables?
________________________________
From: aravis-bounce@xxxxxxxxxxxxx <aravis-bounce@xxxxxxxxxxxxx> on behalf of
Saurabh Chatterjee <saurabhsaurc@xxxxxxxxx>
Sent: Friday, December 22, 2017 9:09 AM
To: aravis@xxxxxxxxxxxxx
Subject: [aravis] Re: Getting Thermal Imaging data using python and ARAVIS
Ok, I modified the code to print the time taken for each frame.
Indeed, what happened is that it seemed to slow down pretty bad for certain
frames
Eg.
Frame: 110 time taken: 0.0009679794311523438
Frame: 111 time taken: 0.001013040542602539
Frame: 112 time taken: 0.0014612674713134766
Frame: 113 time taken: 0.0010993480682373047
Frame: 114 time taken: 0.004855155944824219
Frame: 115 time taken: 0.48161911964416504
Frame: 116 time taken: 0.001965761184692383
Frame: 117 time taken: 0.0023725032806396484
Because of those bad frames, it slows down the entire frame rate.
So it is probably a packet resend problem.
Now for the bad news. I meddled with the packet resend settings and ended up
even worse off- now the packet error seems to occur practically every other
frame.
I don't even know how to get back to the previous settings.. Hopefully I'll
work it out..
On Fri, Dec 22, 2017 at 6:09 PM, Nial Peters
<nonbiostudent@xxxxxxxxxxx<mailto:nonbiostudent@xxxxxxxxxxx>> wrote:
Hi,
This may be irrelevant to your problem, but some years ago when I was using
Aravis with a FLIR SC645 thermal camera I found that occasionally a frame would
take a huge amount of time to transfer compared to normal. It turned out to be
due to packet resend requests. As soon as a packet was dropped and Aravis
requested a resend, the camera seemed unable to cope, sometimes freezing
completely and needing to be reset. I found that disabling packet resend
requests in Aravis resulted in a more reliable throughput, as long as you can
cope with a frame being occasionally lost. I'm not sure how you do this with
the Python interface (and I may also be well out of date with the current
Aravis release) but in C it was using g_object_set(camera->stream,
"packet-resend", ARV_GV_STREAM_PACKET_RESEND_NEVER, NULL)
As I said, this didn't happen very often, so perhaps it is possible that for
small value of numFrames you don't see this problem, but for larger numbers it
is occurring for one or two frames and slowing things down? You could easily
test this by recording the time taken to retrieve each frame and see if it is
just a few frames that are slowing things down or whether there is an overall
reduction in throughput for large numFrames values.
Cheers,
Nial
On 21/12/17 10:12, Emmanuel Pacaud wrote:
Hi,
Hi,
Le ven. 15 déc. 2017 à 14:52, Saurabh Chatterjee
<saurabhsaurc@xxxxxxxxx><mailto:saurabhsaurc@xxxxxxxxx> a écrit :
For a low value of numFrames ( say 100 ), I get frame rate of 60
For high values ( say 600+ ), the frame rate goes down to about 25 or so..
any idea why that might be happening?
Did you check the CPU and memory consumption of your software ?
How did you setup the acquistion framerate ?
Cheers,
Emmanuel.
--
Saurabh Chatterjee
Phd, Aerospace Engineering
Indian Institute of Space Science and Technology, Thiruvananthapuram
