dear casper time keepers, thanks for all your good ideas on how to get a pair of time/freq standards 500 km apart to agree to a few ns.
some of you suggested common view GPS, which can get clocks to agree to within about 2 or 3 ns: https://www.nist.gov/pml/time- <https://www.nist.gov/pml/time-and-frequency-division/atomic-standards/common-view-gps-time-transfer> and-frequency-division/atomic-standards/common-view-gps-time-transfer <https://www.nist.gov/pml/time-and-frequency-division/atomic-standards/common-view-gps-time-transfer> also see papers at the bottom of that page. some suggested NIST TMAS service, (time-measurement and analysis service), where you pay a monthly fee for NIST to keep your GPSDO to < 10ns RMS wrt NIST-UTC. https://www.nist.gov/programs-projects/time-measurement-and-analysis-service-tmas i like john's suggestion of letting the oscillator drift, rather than continually trying to correct it. i think several observatories do that - makes sense. best wishes, dan > > *From:* John Ford <jmfor...@gmail.com> > *Sent:* Monday, March 11, 2019 9:41 AM > *To:* LIST <casper@lists.berkeley.edu> > *Subject:* Re: [EXTERNAL] [casper] seeking high accuracy GPS disciplined > time/frequency standards ? > > > > Hi Dan. I've been thinking about this a bit over the weekend, and I think > the problem can be solved by dividing the problem. I think the frequency > standard should not be coupled to GPS, rather a free-running rubidium or > better oscillator could provide sufficient frequency stability and could > also generate a local clock. The CLOCK, then can be either referenced or > calibrated somehow (postprocessed GPS time + ?) to UTC. The local clocks > at the N sites then would not be slaved to GPS, but rather to their own > frequency standard, corrected as needed by filtered/corrected GPS time. > > > > Green Bank does this to some extent, without closing the loop. The > hydrogen maser drives a counter, which provides 1 PPS. But this one PPS is > NOT slaved to GPS, but rather the GPS signal is used to measure the offset > from GPS. The offset is then supplied to the users for their > calculations. The system drifts some microseconds per year. Eventually > the time gets resynced to GPS, when someone decides it's time, or when > something happens to force it. Like a power/UPS outage. > > > > I think you could build such a system that would be accurate to << 10 ns > with respect to UTC using GPS and doing corrections to the GPS TIME after > the fact, and feeding forward the errors into your clock. The corrections > would be a day late, but presumably you are not going to rely on raw GPS, > rather on the time-corrected GPS time. In the meantime your clock will > freewheel with your oscillator, which will be extremely accurate anyway. > > > > John > > > > > > > > On Sat, Mar 9, 2019 at 3:08 PM Dan Werthimer <d...@ssl.berkeley.edu> > wrote: > > > > hi david, > > > > i'm not an expert in atmospheric delay correction and gps, but if you are > interested, > > i think there are several papers about what corrections gps can do and > what it can't do. > > some references are listed at the end of: > > > https://en.wikipedia.org/wiki/Error_analysis_for_the_Global_Positioning_System > > > > the best GPSDO's on the market provide errors of around 10 ns RMS wrt UTC. > > i think most of this error is due to variable atmospheric delays that can > not be removed > > (eg: dispersion errors can be measured and removed, but other propogation > delay errors can not be removed). > > > > best wishes, > > > > dan > > > > > > > > On Fri, Mar 8, 2019 at 11:25 PM Forbes, David C - (dforbes) < > dfor...@email.arizona.edu> wrote: > > That's an interesting question, Dan. You seek a low cost oscillator that > follows GPS without following it too closely. > > Do you have a plot of a typical day of GPS atmospheric disturbance? > > > > > > On Mar 8, 2019 2:55 PM, Dan Werthimer <d...@ssl.berkeley.edu> wrote: > > > > hi robert, randall, dale and casperites, > > > > thanks for your time/freq standard suggestions. > > > > our problem to get accurate 1 PPS wrt UTC is not limited by internal > oscillator stability. > > the problem is mostly about GPS atmospheric delay corrections. > > i don't thinks one needs an ultra stable oscillator in a GPSDO time/freq > standard if one is only interested in 1 PPS accuracy wrt UTC. > > there's no need for rubidium, hydrogen, or microsemi's atomic gizmo for 1 > pps accuracy > > -- an OXCO is fine. > > > > the typical GPS disciplined oscillators (eg: srs and trimble) output 1 > PPS that have 100 ns errors from UTC. > > the best ones we have found so far are made by endrun technologies (< 10 > ns error wrt UTC). > > > > endrun claims to have unique algorithms for GPS atmospheric correction. > > although one can do next day GPS atmospheric correction for atmospheric > delays > > (the next day, there are correction tables available for the previous day > that are location/satellite dependent), > > endrun technologies can do some fairly accurate measurements and > atmospheric delay corrections in near real time. > > we'd prefer not to use next day correction tables in our application. > > > > has anybody used GPSDO time/freq standards that have < 10 ns accuracy wrt > UTC? > > has anybody used the endrun technologies standards ? > > has anybody used GPSDO products from microsemi? > > > https://www.microsemi.com/product-directory/clocks-frequency-references/3826-gps-disciplined-oscillators-gpsdo > > the GPSDO's listed at the bottom of that page have 10 ns wrt utc. > > > > best wishes, > > > > dan > > > > > > > > On Thu, Mar 7, 2019 at 8:57 AM Robert F. Jarnot < > robert.f.jar...@jpl.nasa.gov> wrote: > > Dan, > > I looked into GPS disciplined oscillators for a project, and ended up > using atomic clocks instead, as they are now very small, can be flown, and > have remarkably low power consumption. We have 2 of them, $7500 each. See > https://www.microsemi.com/product-directory/clocks-frequency-references/3824-chip-scale-atomic-clock-csac > > I suspect that a good choice of GPS disciplined oscillators would work > pretty much as well, and be cheaper. > > Bob > > On 3/7/19 8:51 AM, Dan Werthimer wrote: > > > > > > in a somewhat related question. > > > > can anybody give us advice about GPS disciplined oscillators time/freq > standards that are very accurate wrt UTC? > > we don't want to buy a hydrogen maser (too pricy). > > we have been looking at a company called endrun technologies that sell > time/freq standards accurate to about +-10 ns wrt UTC. > > they might be able to match a pair of them that track each other +- 3ns > RMS. > > we need a pair of well matched time/freq standards for coincidence time > stamping/correlation between two observatories for our panoseti experiment. > > (the two optical/IR observatories are 500 km apart, and don't have > masers). > > > > thanks for any advice on this. > > > > btw, we are using white rabbit for time/frequency distribution over 1 Gbe > bidi fiber, > > and we put the white rabbit hardware (VCO and DAC chips) and software on > our FPGA boards for this project. > > (we made our own FPGA boards with white rabbit and kintex7 because we need > a few thousand boards) > > white rabbit does sub-ns accuracy in timing distribution - some white > rabbit users have measured 30 ps RMS. > > > > best wishes, > > > > dan > > > > > > On Thu, Mar 7, 2019 at 12:05 AM Michael Inggs <miki...@gmail.com> wrote: > > Hi Franco > > > > Simon Lewis in the RRSG at UCT has White Rabbit hardware and expertise > (PhD incubating). Snag is that it runs on 1GE Fibre. We also have a GPS > version. The former gives sub ns precision, the latter about 4 ns rms. Send > me a message off line and I can link you. We also have a scheme of aligning > a trigger to both a local MHz clock and the 1 pps. This is all open source > hardware and software. > > > > Regards > > > > On Thu, 7 Mar 2019 at 08:52, James Smith <jsm...@ska.ac.za> wrote: > > Hello Franco, > > > > As I understand it, PTP wasn't terribly useful in our application (though > I wasn't involved with this directly). You can probably sync the little > Linux instance that runs on the ROACH2, but getting the time information > onto your FPGA may prove somewhat tricky. > > > > Are you using an ADC card in the ROACH2? Or is the data digitised > separately? > > > > What we've done with ROACH and ROACH2 designs in the past is more or less > this: > > - FPGA's clock comes from a timing & frequency reference (TFR). > - ROACH2 gets a 1PPS input from the same TFR. > - In the FPGA logic there's a counter which is reset as part of the > initialisation, and some logic that starts the counter going after a set > number of 1PPS pulses (two to three, I forget exactly now). > - The output of this counter is pipelined along with the data and then > sent out as part of the SPEAD data on the 10GbE network. > > The idea here being that you know with a fairly high degree of precision > which pulse your ROACH was initialised on. The counter that comes through > on the SPEAD packet counts in FPGA clock cycles (or multiples thereof, > perhaps you might want to count in spectra), and then you can use the start > time to calculate the timestamp of each packet (Unix time, MJD, whichever > your preferred reference is). > > > > Hope that helps. > > > > Regards, > > James > > > > > > On Wed, Mar 6, 2019 at 7:41 PM Franco <francocuro...@gmail.com> wrote: > > Dear Casperiites, > > > > I was given the task of timestamping ROACH2 spectral data in a telescope > that uses PTP (precision time protocol) as a synchronization protocol. I > understand that ROACH's BORPH come preloaded with NTP (network time > protocol) libraries/daemos, but PTP is preferred because is already in use > in the telescope, and it achieves greater time precision. > > > > Does somebody know if it is feasible to compile/install PTP libraries in > BORPH? > > > > Alternatively, we have though of sending the ROACH the current time > through a GPIO pin using IRIG-B timecode standard. Has anybody done > something similar in the past? > > > > Thanks, > > > > Franco > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > > > -- > > Michael Inggs > > 10 Devon Street, Simon's Town, South Africa. Tel: +27 21 786 1723 Fax: +27 > 21 786 1151 Skype: mikings Cell: +27 83 776 7304 > > "Ex Africa semper aliquid novi" > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups > "casper@lists.berkeley.edu" <casper@lists.berkeley.edu> group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > > * Robert F. Jarnot, M/S 183-701 | robert.f.jar...@jpl.nasa.gov * > > * Jet Propulsion Laboratory, | Google: (657) 229-5204 * > > * 4800 Oak Grove Drive, | Cell: (818) 653-9266 * > > * Pasadena, CA 91109-8099, USA | FAX: (818) 393-5065 * > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
