Re: [time-nuts] Synchronization

[Anton Strydom]

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  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  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.partri...@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-boun...@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  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 

Re: [time-nuts] Lowest Power NTP Server

[Hal Murray]

> I have one of the little USB volt/amp meters, but I'll have to dig to find it.

0.28 amp.  [Pi 2B with GPS hat and USB WiFi]

It goes up to 0.36 when I send it a big file over the net.

No change when I send it 100 ntp packets/second.



A Pi A+ (no ether) without GPS with USB WiFi is bouncing around between 0.10 
and 0.15 amp.

I haven't figured out why this one is bouncing and/or why the other one isn't 
bouncing.



-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@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] WiFi timings

[Hal Murray]

I have several systems that have been running/testing ntpd for ages.  I'm a 
pack rat.  Here is some data from the last year.

The blue/green dot is PC=>AP=>Pi and then back.
The box is the same pair of machines starting at the Pi.
The red dot is PC=>AP=>laptop and back.

100K packets for the laptop, 400K each set for the Pi.

The Pi is an A+ using a tiny low cost USB WiFi thingie.

My WiFi setup is anchient.  The AP is an Cisco/Lynksys WRT54GL.  The laptop is 
only 6 feet away.  The Pi is several rooms away.


-- 
These are my opinions.  I hate spam.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Trimble Tbolt temperature

[Tom Van Baak]

Most TBolt measure board temperature to about 1/100th C resolution. This 
is the correct behavior. Some TBolt report temperatures that seem to 
step in 1 C increments, or they report a constant -55 C, or they glitch 
once in a while. These are bugs.


You can replace the DS1620 chip if you want. It's perhaps best to locate 
the 20-year old version of the chip. There are lots of threads about 
this in the archive.


The DS1620, working or not, has no effect on the performance of a 
running TBolt. So I've never bothered replacing any of mine. It may have 
a slight effect on extended holdover performance. It's a long story and 
I'm not sure if anyone has actually verified or quantified this.


Here's additional info about the TBolt & DS1620; it's more complex than 
you think:


"Strange temperature peak"
https://lists.febo.com/pipermail/time-nuts_lists.febo.com/2011-May/039188.html 



"Trimble Thunderbolt GPSDO Temperature Sensor Details"
http://leapsecond.com/pages/tbolt-1620/

"Dallas state machine glitch"
https://www.digitemp.com/docs/ds1820-report.pdf

/tvb


On 12/3/2019 1:47 AM, Christophe Huygens wrote:

Hi all,

I am back on time-nuts after many moons.

Lady heather shows constant -55deg C for my Tbolt.

all else seems to function fine (is in a constant T environment, sort of)

Any thoughts

br and thanks

Xtof

___
time-nuts mailing list -- time-nuts@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@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] Trimble Tbolt temperature

[Arthur Dent]

-55 degrees seems to be a common temperature displayed by a defective
DS1620 temperature chip.
https://datasheets.maximintegrated.com/en/ds/DS1620.pdf

-Arthur
___
time-nuts mailing list -- time-nuts@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] Trimble Tbolt temperature

[Arthur Dent]

If you choose to replace the DS1620 keep in mind that there are different
revisions of the chip and the 'E' revision displays the temperature in
larger steps than the previous revisions but the 'D' version is still
pretty common and it probably doesn't make any difference other than how
the Lady Heather graph will look. I'm not sure how the newer revision chips
work. The DS1620 chips are fairly cheap on eBay and several sellers have
them.

Check the discussion on the chips from 2010 that describes how to check the
revision.

https://www.mail-archive.com/search?l=time-n...@febo.com=subject:%22%5C%5Btime%5C-nuts%5C%5D+DS1620+Variants+in+the+Thunderbolt%22=newest=1
-Arthur
___
time-nuts mailing list -- time-nuts@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] Symmetricom Syncserver S300

[Bob Darlington]

Guys, I have a broken Syncserver S300.  OCXO, gps, 60kHz receiver
internal.  No Rb or anything special.  It's been broken since 2015.  It was
fine till I power cycled the thing, but that's the way it goes with .gov
surplus stuff sometimes.  It ran for years before that.

Symptom: 4 red front panel lights, nothing on the serial port (front serial
port, don't know if there is another inside), and during boot the VFD on
front spins the hourglass.  It gets to booting or loading OS and eventually
just freezes.

Digging through the archives I see a similar issue described and that
system seems to have been resolved by noticing high frequency ripple on at
least one of the DC power supply lines and replacement of a capacitor.
Well, I saw that, and I found a bulging cap, and replaced it.  And sure,
maybe the ripple is better but it's not perfect and it didn't fix the
problem.  There's a lot of trough hole electrolytics in the PSU.  The one I
changed required desoldering of a daughter board that was bolted to some
other bits.  A real pain.  15 minute "fix", but a pain.   I don't see any
of the others bulging but that doesn't mean they're all good.  I don't know
if the ripple I see is even coming from the PSU or the main board, or if
it's even a problem.

There was some speculation about CF card corruption. I didn't chase that
down.

I'm done!

If anybody in the USA is interested in continuing on this repair project, I
will give you the unit for the cost of shipping.  I don't know what that
will be, but I assume under $50.  The unit has rack ears and cosmetically
is a 9.5 out of 10.   Talking to TVB, his suggestion was to test with an
external clean power supply to rule that out.

In the very least it's a pretty nice 1U rack enclosure.

Please, ping me direct and I'll let the list know it's spoken for.  I'll
let the next owner ask for help! I'll image the CF cards to keep around
just in case.  Again, USA only.  Somehow shipping clocks will be under ITAR
rules and I don't wanna go there.

-Bob N3XKB
___
time-nuts mailing list -- time-nuts@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] USB over optical fiber

[David Van Horn via time-nuts]

I suppose this is vaguely time-nutty. 

I have an application where I need to take USB into an EMC faraday cage.
I see a number of optical fiber implementations available, and the prices 
($200-300) are acceptable, but I’m worried about noise that the downstream end 
may cause, since it will need to be inside the cage.

Does anyone have experience with these?  Ones to stay away from?



--
David VanHorn
Lead Hardware Engineer

Backcountry Access, Inc.
2820 Wilderness Pl, Unit H
Boulder, CO  80301 USA
phone: 303-417-1345  x110
email: 
david.vanh...@backcountryaccess.com

___
time-nuts mailing list -- time-nuts@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] Trimble Tbolt temperature

[Christophe Huygens]

Hi all,

I am back on time-nuts after many moons.

Lady heather shows constant -55deg C for my Tbolt.

all else seems to function fine (is in a constant T environment, sort of)

Any thoughts

br and thanks

Xtof

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[Bob kb8tq]

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  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.partri...@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-boun...@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  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
>>> 

Re: [time-nuts] Lowest Power NTP Server

[Bob kb8tq]

Hi

> On Dec 3, 2019, at 7:55 AM, Hal Murray  wrote:
> 
> 
> If a Raspberry Pi fits your energy budget, that's probably the simplest way 
> to 
> go.  There are lots of them running with GPS hats.
> 
>> More or less, 0.5W on a 5AH 12V battery runs for 120 hours. Something at 5W
>> only runs for 12 hours ….. 
> 
> My Kill-A-Watt alternates between 02 and 03 watts for a Pi 2B with USB WiFi 
> and GPS.  I don't know how inefficient the wall wart is.

A full up desktop on an RPi 4 runs at about 0.57A at 5V with all the usual 
stuff 
attached. Various sources suggest that the Pi Zero W is down around 0.1A at
5V with the WiFi turned on and headless Linux doing its thing. The question 
is / was - can you go lower than the 1/2W by using something other than the 
Pi Zero W. 

> 
> I have one of the little USB volt/amp meters, but I'll have to dig to find it.
> 
> 
>> My target is “a couple of mili seconds” so a microsecond or five is sort of a
>> non-issue.
> 
> What sort of client software are you considering?  Real ntp client or some 
> hack?

Each of the devices on the network will be running whatever it’s OS happens 
to have available. There will be a mix of OSX, Windows, IOS, Linux and 
(probably)
Android devices. NTP *seems* to be the most likely common denominator. 

> 
> Do you need accurate real time or can you post process things?

Real time

> 
> How good is your WiFi connection?  (more in another msg - long tail with a 
> bump)  Real ntpd has a filter of 8 packets that ignores most of the outliers. 
>  
> Dumb ntp just smashes the clock to its calculated value which follows the 
> tail 
> wherever it leads.

WiFi should be ok. Delay through the low power router is on the “things to test”
list. The total budget is server + WiFi + client. I’d like to keep each part 
below 10 ms
90% of the time. Ideally I’d like the sum to hit that target. 

> 
> 
>> My main concern is that the clients are likely to be a bit “time challenged”
>> and some of them could need fairly high update rates.  
> 
> What do you mean by "time challenged"?  Hardware or software?

The “stuff” may be out in the rain and snow. It may go from indoors to 
outdoors. 
It likely has weird power management modes it goes into. The devices (hopefully)
have a real time clock. I have no control over which RTC in some of the devices.

> 
> Normally ntpd adjusts the clock rate to match the actual crystal.  It's 
> called 
> drift.  Deep inside the OS there is a magic constant that converts ticks from 
> clock to ns.  You need a side door to adjust that constant.  Real NTP client 
> software does a good job of using that knob.  It tracks temperature.

Writing custom software for a half dozen OS’s and even more clients is not 
inside
the scope of work for this project. I simply want to run something reasonably 
standard that will “do time” across a number of platforms. 

> 
> -
> 
> I don't know of any NTP software that has been well tuned for working in 
> ultra low power.  (But I haven't been looking and I don't track the 
> literture.)  For low power, you probably want to turn off the CPU crystal and 
> PLLs.  That turns into timekeeping using two clocks, the RTC while sleeping 
> and the normal CPU crystal when running.  You need a way to recover the time 
> from the RTC quickly and accurately and you also need to keep track of two 
> clock drifts.

For a server (that gets inquiries at any time) the “wake up” process is going 
to be a
problem with a deep sleep approach. The GPS on the server also would need to 
wake 
up and get going. That combo is going to give you a mighty long turn around 
time on
a request. I also suspect that the requests will come in often enough (compared 
to a 
minute or two long GPS lockup) that it would never go into deep sleep anyway.

Indeed a lot of that is a guess ….

Bob

> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[Anton Strydom]

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.partri...@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-boun...@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  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 

Re: [time-nuts] 100 MHz decade Divider II

[Gerhard Hoffmann]

Am 01.12.19 um 23:40 schrieb Bob via time-nuts:

 From Gerhard's and other list comments I'd never choose Morion oscillators.


I did not want to belittle Morion. In fact, their current crop is top notch.

But an oscillator that has spent 20 years on a cell phone tower

and that has cooked it's innards at 80°C for this time may have

drifted away or fail some specs.

Esp. when it looks like having been removed from its old home

with hammer and sickle.


regards, Gerhard



___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Lowest Power NTP Server

[Hal Murray]

If a Raspberry Pi fits your energy budget, that's probably the simplest way to 
go.  There are lots of them running with GPS hats.

> More or less, 0.5W on a 5AH 12V battery runs for 120 hours. Something at 5W
> only runs for 12 hours ….. 

My Kill-A-Watt alternates between 02 and 03 watts for a Pi 2B with USB WiFi 
and GPS.  I don't know how inefficient the wall wart is.

I have one of the little USB volt/amp meters, but I'll have to dig to find it.


> My target is “a couple of mili seconds” so a microsecond or five is sort 
> of a
> non-issue.

What sort of client software are you considering?  Real ntp client or some 
hack?

Do you need accurate real time or can you post process things?

How good is your WiFi connection?  (more in another msg - long tail with a 
bump)  Real ntpd has a filter of 8 packets that ignores most of the outliers.  
Dumb ntp just smashes the clock to its calculated value which follows the tail 
wherever it leads.


> My main concern is that the clients are likely to be a bit “time 
> challenged”
> and some of them could need fairly high update rates.  

What do you mean by "time challenged"?  Hardware or software?

Normally ntpd adjusts the clock rate to match the actual crystal.  It's called 
drift.  Deep inside the OS there is a magic constant that converts ticks from 
clock to ns.  You need a side door to adjust that constant.  Real NTP client 
software does a good job of using that knob.  It tracks temperature.

-

I don't know of any NTP software that has been well tuned for working in ultra 
low power.  (But I haven't been looking and I don't track the literture.)  For 
low power, you probably want to turn off the CPU crystal and PLLs.  That turns 
into timekeeping using two clocks, the RTC while sleeping and the normal CPU 
crystal when running.  You need a way to recover the time from the RTC quickly 
and accurately and you also need to keep track of two clock drifts.

-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[David C. Partridge]

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-boun...@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  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@lists.febo.com To unsubscribe, go 
> > tohttp://
> lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
> >
>
> 

Re: [time-nuts] Synchronization

[Bob kb8tq]

Hi

Ok, for survey work there *is* an alternative. It takes care of the location 
of the “rover” as well as the time. uBlox has a ZED-F9P module for around
$100 that will do the trick. It is L1/L2, but the cost penalty isn’t all that 
great
in this case. I don’t know if that would be a practical thing in this case or
not ( = if the entire budget is $20 …. it’s not). 

Bob

> On Dec 3, 2019, at 3:05 AM, 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  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@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 

Re: [time-nuts] Synchronization

[Magnus Danielson]

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