On Tue, Mar 12, 2019 at 4:01 PM Steve Olney <t0...@internode.on.net> wrote: > > Hi Bob, > > On 13/03/2019 1:30 am, Bob kb8tq wrote: > > Sorry if this is an ongoing / somewhat random dump of a bunch of things … I > > am not doing the > > same sort of thing you are doing. That makes a lot of this a bit less > > focused than maybe > > it could be. > > Thanks for your suggestions - they have been most helpful. It was just > when the discussion turned to Maser clocks and interferometry that I was > concerned that the discussion had "dropped out of lock and drifting with > many ppm" :-)
Hi Steve, let me first off say that what your doing is very impressive; amateur radio astronomy of any sort is rare and to be achieving results on sources many orders of magnitude fainter than the "bright two" radio sources of the Sun and Jupiter is even more impressive. My poorly worded and too brief comment was a poor attempt to say that radio astronomers (pulsar and VLBI) tend to go to the very extremes of clock precision - once the optical lattice clocks make out of the national labs, I am sure they will be first in line... Sorry if I dragged things off topic. However even the VLBI people have offered hope for us mere mortals minus a maser. A regular feature of the VLBI Workshops has been a presentation on "Low Cost, High Accuracy GPS timing"; the latest version is at https://www.haystack.mit.edu/workshop/TOW2017/files/Seminars/tow-time2017.pdf This may well be worth a look; once you get past all the maser stuff, they show that cheap (<$100) ublox6 and 8 chipsets with correction of the sawtooth and some averaging can give few nanoseconds residuals . > > I simply want to know about the behaviour of the GPS 16 HVS under > no-lock conditions. I need that information to optimise a fail-safe > mechanism in my software. Basically, if there is a loss of lock I need > to account for that. In my application, it doesn't matter if the GPS > unit drops out of lock as I can re-schedule the timing event to a > slightly later time when a valid fix is present. All that matters is > that I have an accurate time-stamp. It doesn't matter if that > time-stamp is re-scheduled for a minute or two later. However, if I > know the drift of the 1 PPS output under invalid fix conditions I might > not need to reschedule the timing event at all as long as the > (tdrift/dt) * (how long the invalid fix has lasted) < 1 ms. The value > of tdrift/dt is the key to implementing this. One other thing to look at may be OpenTTP (openttp.org) which is a suite of software to drive commodity hardware and provide GPS Common View processing. This would allow comparisons of your local clock used for time stamping with GPS to (in principle) better accuracy than the previously suggested NTP (still a good idea to run) and traceability back to GPS and UTC. This would allow you to produce a sort-of "steve2gps.clk" file which could be fed to the TEMPO2 software used by astronomers to analyze pulsar timings and provide an extra level of accounting for changes in your local clock, over and above the plan above. I have just started playing it with myself for a few days and have been trying to document as I go (https://adventuresinprecision.space/2019/03/13/adventures-with-openttp/). I've added support for installing and running it on Raspberry Pi's and I'm working on adding support for the ublox6 GPS modules (configuration and logging seems to be working but not analysis yet) and the HP5334B time interval counter (OpenTTP already has support for the ublox M8T GPS chips discussed in the "Low Cost, High Accuracy GPS timing" presentation and the TAPR TICC popular among list members). > > Thanks for your suggestions. > > Cheers > > Steve > > HawkRAO > Cheers, Tim _______________________________________________ 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.
