[time-nuts] Synchronization

Tue Dec 3 09:07:37 UTC 2019

Hi Anton,

OK, so it looks like you mostly need to improve your relative timing
between cameras rather than high-accurate time-stamps of cameras in
absolute time.

Now, synchronizing cameras to the same clock (which by no means is
necessarily accurate, just common and good enough) is something
routinely done in TV-production. Classically a black-burst signal
(really a PAL or NTSC signal containing a black screen, but full
synchronization and color-burst signal, often is the color-burst not
needed) is used to input to GENLOCK (GENerator LOCK) input. Thus, you
have a synchronization signal genertor, and you deliver the signal to
the camera and it locks up to that. By keeping cable delays low enough,
the returned signals is relatively inline such that today re-aligning
them can be done using a line-store, in which up to 8 or 16 lines can be
buffered to produce a slightly delayed version but now coordinated
phase. Before line-stores, cameras had matched length cables, such that
timing was well within the 37 ns allowed for analog mixing. For modern
HDTV cameras, a tri-level sync-signal may alternatively be used, even if
many supports the classical analog PAL/NTSC black-burst signals.

I would start by looking at the cameras, and see if there is a way to
lock the cameras to a signal. That way the actual capturing is aligned.
As soon as that is done, the time requirements is much relaxed,
typically all you need to do is know what time it is and what frame in
the second it is. If you run any variant of 30/1.001 Hz (about 29,97
Hz), this have a bit of additional pain, but that can be explained.

Cheers,
Magnus - was on a SMPTE synchronization call yesterday

On 2019-12-03 09:05, Anton Strydom wrote:
> Hi Tom
>
> Thank you for all your input thus far it is appreciated
>
> The "CLOUD" I am talking about is a Point Cloud and I am attaching an
> example for your perusal.
>
> I am also attaching a screengrab of a real time stereo video where you can
> see the misalignment of the images
>
> Presently the system is purely experimental and has to be real time.
>
> Post processing is done to forecast possible movement and once a "trend"
> has been established it can be accelerated over time using the point cloud
> 3D model and the mesh it is built on
>
> The points monitored (targets) are surveyed in points as are the camera
> placements
>
> Using a combination of OpenCV and Tensor Flow a number of observations and
> precise measurements are possible thus allowing modeling of the structure
> over accelerated time using the movement data collected from the structure
> etc etc.
>
> Yours sincerely
>
> Anton
>
> On Tue, Dec 3, 2019 at 9:00 AM Tom Van Baak <tvb at leapsecond.com> wrote:
>
>> Hi Anton,
>>
>>  > My question is what good synchronization of a gps clock in Nano seconds?
>>
>> That's not much to go on; there are so many variables. To start with,
>> almost any cheap eBay GPS/1PPS receiver these days will give you time to
>> within a couple 100 ns with no special effort on your part.
>>
>> If you have a fixed location, a good antenna, a clear view of sky, a
>> modern GPS receiver with 1PPS output, and have the ability to apply
>> sawtooth correction in h/w or s/w, then you can probably get within 10
>> ns. Many commercial and DIY GPSDO are based on this assumption.
>>
>> Note that this "10 ns" is relative timing. To obtain 10 ns absolute UTC
>> is much harder because you have to calibrate and compensate for antenna
>> delay, amplifier delay, cable and connector delay, receiver delay, 1PPS
>> buffer amplifier, output cable, and edge detection delay, etc. So almost
>> nobody can do absolute timing on the cheap.
>>
>> Fortunately for many applications (e.g., GPSDO) it's not necessary
>> because most of those fixed phase corrections cancel.
>>
>> Then there's the question if your application is based on a surveyed
>> fixed location -- if static, or ground mobile, or airborne. Do you have
>> any size, mass, or power constraints? Do you need a local oscillator /
>> time base or is this just raw, live 1PPS ticks from the receiver? Do you
>> need good results now in real-time or can you wait a day or a week to
>> get better results after some post-processing?
>>
>> So the rough answer is that these days 100 ns is easy for under $50; 10
>> ns is possible for under $500; and 1 ns absolute is near impossible
>> unless you have a lot of development time and money, not to mention
>> atomic clocks and test equipment to validate that extreme level of
>> performance. Plus the expense of trip(s) to your national NMI for UTC
>> calibration at the ns level.
>>
>> Does that help? If not, can you summarized your technical requirements
>> in more detail for the group? There are a number of people on the
>> mailing list who have done recent measurements using the ublox F9-series
>> receivers and those results should be helpful in your quest.
>>
>> Precise timing and 3D imaging sounds like an interesting application.
>> You mention clouds though; do they move fast enough that milliseconds or
>> nanoseconds matter? Can we see your math? I'm curious but confused. For
>> example, nanoseconds matter for triangulation of high energy atmospheric
>> cosmic rays, but I've not heard where nanoseconds matter for
>> photogrammetry.
>>
>> /tvb
>>
>>
>>
>> On 12/2/2019 12:01 AM, Anton Strydom wrote:
>>> Good day All
>>>
>>> I am new here.
>>>
>>> I have been busy with GPS systems for the last couple of years and have
>>> also developed a number of low cost high accuracy L1 units.
>>>
>>> I also play around with photography and especially in the field of
>>> photogrammetry and 3D point cloud situations.
>>>
>>> Time being the one thing that influences everything to do with accuracy.
>>>
>>> My question is what good synchronization of a gps clock in Nano seconds?
>>>
>>> Obviously the closer to 0 the better I would guess.
>>>
>>> Thank you in advance
>>>
>>> Yours sincerely
>>>
>>> Anton Strydom
>>> _______________________________________________
>>> time-nuts mailing list --time-nuts at lists.febo.com
>>> To unsubscribe, go tohttp://
>> lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>>> and follow the instructions there.
>>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.