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.
