[time-nuts] Synchronization

Wed Dec 4 06:01:43 UTC 2019

Hi Bob

" If you set up several units as base stations and then stream corrections
from then,
you can indeed get down to the CM level real time with a number of L1/L2
systems.
The key is that you need to stream the corrections"

I have a number of LEA 6T modules so therefor instead of running a NTP
server I am going to configure a LEA 6T unit as a Rover on each of the
RPi's and setup a separate Base on another RPi and have the base broadcast
RTCM using the WiFi this should theoretically be sub decimeter accurate and
that should equate to at least microsecond synchronization I think

On Tue, Dec 3, 2019 at 10:01 PM Bob kb8tq <kb8tq at n1k.org> wrote:

> Hi
>
> It looks like “your thread” just ran into “my thread” :)
>
> I’m doing some digging on a low power WiFi based NTP setup. RPi’s will be
> part of (but not all of) the mix there. So far the conclusion is that
> milisecond
> timing is what you are going to get from a NTP on a WiFi based RPi.
>
> ====
>
> If you set up several units as base stations and then stream corrections
> from then,
> you can indeed get down to the CM level real time with a number of L1/L2
> systems.
> The key is that you need to stream the corrections.
>
> Bob
>
> > On Dec 3, 2019, at 11:20 AM, Anton Strydom <agstrydom at gmail.com> wrote:
> >
> > Thank you everyone for your input I am very grateful
> >
> > The cameras are pairs sitting on a multiplexer so the problem is not the
> > camera pair synchronization but the RPi synchronization
> >
> > The ZED-F9P modules work well but still does not give continuous
> centimeter
> > accuracy as does the Hexacon (Leica) or the Hemisphere equipment that I
> > have here
> >
> > Yes basically Lidar but with a twist in that I use at present normal 8MP
> > RPi V2 roller shutter cameras that adds to the problem in a different
> way.
> > I am switching to Global Shutter Cameras that will alleviate the shutter
> > issue.
> >
> > Each of the units that I use is equiped with 1 to 3 pairs of cameras.
> > Therefore multiple streams into a single platform.
> >
> > GPS stability I do not think is my biggest problem and I wish I could do
> a
> > screen grab of the image the moment the RPI's synchronize to a NTP server
> > at the same time.
> >
> > Reading through the replies and has prompted me to do the following
> > experiment:
> >
> > I have a number of different gps units here, I am going to test the
> > different ones as follows L1 recievers on each of 4 RPI units deployed
> > around a bridge at the university, sync each unit to it's gps time and
> then
> > repeat the experiment with precision timing L1 units such as the UBlox
> LEA
> > 6T units both as autonomous and Base Rover combinations doing RTK, L1,
> > L1/L2  autonomous, L1, L1/L2 RTK and the Dual frequency autonomous and
> also
> > RTK
> >
> > That should give me an idea of what I am looking for and I will report
> back
> > with the results
> >
> > Thank you all for your input once again
> >
> > Yours sincerely
> >
> > Anton
> >
> > On Tue, Dec 3, 2019 at 4:22 PM David C. Partridge <
> > david.partridge at perdrix.co.uk> wrote:
> >
> >> So you're processing something like a lidar image - from one lidar
> device
> >> on a single platform or multiple many on multiple platforms?  Is your
> >> concern how stable ONE GPS receiver is, or do you need to have multiple
> >> GPSs synchronised within a certain number of nS?
> >>
> >> If the latter how close do you need then to be synchronised ?
> >>
> >> David
> >>
> >>
> >> -----Original Message-----
> >> From: time-nuts [mailto:time-nuts-bounces at lists.febo.com] On Behalf Of
> >> Anton Strydom
> >> Sent: 03 December 2019 08:06
> >> To: Discussion of precise time and frequency measurement
> >> Subject: Re: [time-nuts] Synchronization
> >>
> >> 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.
> >>
> > _______________________________________________
> > 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.
>