[aravis] Re: Debugging latency & long pause issues with Blackfly camera...
- From: John Stowers <john.stowers.lists@xxxxxxxxx>
- To: aravis@xxxxxxxxxxxxx
- Date: Thu, 17 Apr 2014 16:00:18 +0200
Hi All,
We have been running our systems with the increased buffer size as
suggested by Tom, and this gave a good improvement.
For another performance boost I suggest adjusting the nice level and
scheduling priority of the process which receives the camera data.
You might need to adjust /etc/security/limits.conf to allow non-root owned
processes to adjust their nice-ness and scheduler priority.
John
On Thu, Apr 17, 2014 at 3:51 PM, Patrick Doyle <wpdster@xxxxxxxxx> wrote:
> After all of that, it turns out that there was a bug in the firmware
> in my camera (which has firmware that is newer than that available on
> the Point Grey website). Point Grey sent me a new firmware image
> (1.31.3.0) and the timestamps now make sense.
>
> Now, on to debugging the lost packets problem… I anticipate that Tom's
> suggestion that I increase the network buffer sizes will go a long way
> towards making that problem go away.
>
> Emmanuel,
> Would you object to a (yet to be written, let alone tested and/or
> debugged) patch to add a packet-resend flag to the gst plugin? Now
> that I have timestamps working, I am less concerned about dropped
> frames, as I will be able to detect those events from the camera
> timestamps.
>
> --wpd
>
> On Wed, Apr 16, 2014 at 9:39 AM, Patrick Doyle <wpdster@xxxxxxxxx> wrote:
> > Actually, after writing my long email, my long email, I (finally)
> > decided to look at the PointGrey documentation. Scanning through
> > their Technical Reference manual, I see that they offer the ability to
> > encode the timestamp, gain, exposure, brightness, etc… in the first N
> > bytes of each image transmitted. They then go on to document the
> > timestamp format that gets encoded in the image as being a 32 bit
> > integer, where the top 7 bits represent seconds, and wrap around every
> > 128 seconds (presumably incrementing the high order 32 bit register
> > when they do so, as I observed). The next 13 bits contain a 13-bit
> > "Cycle Count" in units of 125 uS that increments from 0 to 7999. And
> > the lower order 12 bits contain a "Cycle Offset", which I don't
> > understand yet. It seems reasonable that the out-of-band timestamp
> > would follow the same format as the in-band data.
> >
> > Scanning briefly the 3 data logs I collected, I see that the 13 bit
> > Cycle Count value increments by 100 for each frame received when I
> > (think I) configured the camera at 60 fps, and by 200 for my 30fps
> > log.
> >
> > Hmmm…
> >
> > --wpd
> >
> >
> > On Wed, Apr 16, 2014 at 9:22 AM, Emmanuel Pacaud <emmanuel@xxxxxxxxx>
> wrote:
> >> Hi,
> >>
> >> Le mercredi 16 avril 2014 à 09:02 -0400, Patrick Doyle a écrit :
> >>> I can think of 3 possibilities:
> >>> 1) Handle timestamps from BlackFly cameras as a special case within
> >>> the Aravis framework.
> >>> 2) Extend the Aravis framework to allow it to report raw timestamps
> >>> received from a camera and write my own gstreamer plugin to convert
> >>> Blackfin timestamps to ns.
> >>> 3) Do something smarter suggested by one of you.
> >>
> >> A last possibility is to contact PointGrey support and submit what you
> >> have observed. It can be a bug in Aravis, but also in the camera
> >> firmware. If it is the latest, a fix in the firmware would be the best
> >> solution.
> >>
> >> Cheers,
> >>
> >> Emmanuel.
> >>
> >>
>
>
Other related posts:
