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. > >