John, Dan etc, I spent some time following the Time Nuts list about ten years ago. The consensus there was that if you use GPS to discipline an oscillator, then you want to run the GPS correction signal through a really long time constant low-pass filter, about ten hours. That lets it average out all the orbital atmospheric errors.
This means that your local oscillator needs to have the stability to achieve your 100ns accuracy over that time period. Rubidium will certainly do that; a really good crystal can also do that. The Rb source may cost less than the really good crystal source. 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto: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<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu"<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>. -- * Robert F. Jarnot, M/S 183-701 | robert.f.jar...@jpl.nasa.gov<mailto: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<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu<mailto: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<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto: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.
