Yes I found the view of the sky is important. This is not my first GPSDO, the previous one had an external antenna, but lived in the garage. If I had to update the software the CPU was pulled out, put in the programmer in the house, then back out to the garage. This one is still being refined but I am using in circuit programming permanently connected to the computer so it is in the house running off an antenna next to a window. Wonderful for rapid development but woeful for stability. I think I've nailed the control system, the refinements are to the "user interface" i.e. what the one LED is doing, and what gets logged via the serial port. I am trying for the most basic system that is still usable. So far the LED does single flash at startup, external oscillator working. Fast flashing at startup, running off internal oscillator because no external oscillator. If on external oscillator will go dead until NEMA messages are being decoded (usually a second or two) then at two second intervals flash the satellites in view. One long flash, none. One short flash, 1-3. Two flashes 4-9, three flashes 10 or more. Once the NEMA messages says the data is valid then the system enters run mode, which is where the current refinement is needed. At present it is a short flash for each valid 1ppS (received and NEMA says valid) but no indication of lock. Getting there.
An unobstructed all round sky view is very important for getting the best results out of any GPSDO setup.
![Roll Eyes ::)](https://www.eevblog.com/forum/Smileys/default/rolleyes.gif.pagespeed.ce.XcUK202Yqt.gif)
The first 5 images, attached below, show a series of u-centre sky maps after upgrading my best M8N fake module to a genuine M8T. The first is the last of a series where I'd followed the perceived wisdom of sticking to just a single constellation (GPS in this case) with the remaining four showing the GPS and Galileo constellations after I'd run tests to compare the discrepancy of the time-pulse arrival times (indirectly in my case) between the GPS and the Russian Glonas (18ns) and then the European Galileo (2 or 3 ns) constellations.
Whilst the Russian SVs offer an extra 2dB boost over the GPS signal strengths and shrink the hole in the northern sky, the larger discrepancy in the timepulse does seem to compromise the performance of the GPSDO (a modern respin of the James Miller design BTW), the Galileo constellation having more closely aligned time pulse seemed to offer an improvement so I decided to leave it setup that way for a day or two before deciding whether to stick with the perceived wisdom of using only a single constellation for best results or carry on and gain more reliable coverage out of an increased elevation filter mask angle of 30deg.
After finally getting the M8T to complete a survey in operation (I'd had to slacken my optimistic 10cm variation setting to 17cm to force it to complete the process), I'd finally been able to prove I could still get valid timing data from just a single SV alone and had initially set the elevation filter mask to 42 deg. However, with just GPS SVs, I could be left with only a single SV above the elevation mask angle setting which was a little worrying since the M8T could land up seeing only a single GPS SV that could quite easily be one marked out of service, hence a loss of 'lock' and my lowering the elevation mask setting to 30deg to avoid such an eventuality.
Adding the Galileo SVs into the mix considerably reduces the risk of having only out of service SVs above the elevation mask angle setting. Since there doesn't seem to be any degradation of timing stability over that of using only the GPS SVs alone, I've stuck with that configuration ever since.
One of the main issues with using a navigation centric GPS module like the M8N in a DIY GPSDO (whether it's a "basic" James Miller design or a properly built and configured Lars type) is the subsonic (3mHz or so) 30 to 50ns phase modulation due to the effects of the ionosphere on propagation delay. Switching to the M8T reduced such subsonic phase modulations by around an order of magnitude (a 5 to 7 ns pk to pk phase shift around the nominal 10MHz output frequency of the GPSDO).
For a very long time, I'd been trying to more accurately quantify this subsonic 'phase wobble' by using the 2G tipover effect to fine tune the OCXO in my much modified FY6600-60M AWG to simulate the stability of a RFS for an hour or two given a stable room temperature. All this "micro-management" effort eventually 'broke me' into spending almost 200 quid on an Efratom LPR101 some two months ago (not quite soon enough to test the MK I GPSDO with its M8N receiver module) and I've since been able to verify my initial guesstimate of 6 to 7ns Pk-Pk subsonic phase modulation using the M8T in the MK II design I'm currently running. One of these days, I'll resurrect that MK I on a solderless breadboard lashup to confirm my 30 to 50ns subsonic phase wobbles guesstimate .
Anyway, all of that is by way of a preamble to what the next 17 images are demonstrating (take note of the date/time shown in the bottom RH corner). I started that test run at 21:30 and only thought to start capturing screenshots some 16 minutes later. Although the sequence covers a span of 110 minutes, the whole run time amounted to 121 minutes before I quit due to the dropping room temperature resulted in a drift of frequency in the RFS which I have yet to mount into a thermostatically controlled enclosure.
CH1 is the 'wobbly' GPSDO output. CH2 is the AWG proxy for the more stable RFS which I'm triggering from to emphasise that I'm looking at the way the GPSDO is wobbling compared to an atomic reference free of the ionospheric effects afflicting the GPSDO.
Holding an independent frequency reference to within a nanosecond or two of the average frequency of a GPSDO for more than an hour at a time is a very tall order even for a temperature (and pressure) stabilised Rubidium oscillator, never mind my own setup at the mercy of room temperature variations.
Even so, I had to make good use of the FY6600-60M's external reference feature that allowed me to fine tune the RFS output in uHz increments by using the AWG as its proxy to save wearing out the RFS's trimpot. I won't be trying to fine tune the RFS any further until after I've got it safely housed in its own thermostatically controlled enclosure - the use of the AWG as a proxy, is a rather neat way to get round this, hopefully temporary, situation.
Although my initial motivation for the RFS purchase had been to provide a secondary atomic standard reference, free of the destabilising effect of the ionosphere (and by an order of magnitude less, that of the troposphere) on GPS (GNSS) derived timing and frequency standards by which to quantify these deficiencies built into the GPS/GNSS systems, I do plan to ultimately use it in this Lars based design (or something very similar).
As most of you seem to be discovering, this business of disciplining an OCXO against the flawed timing and frequency reference of a GNSS based time and frequency transfer setup, has rather too much of the "Catch 22" element to be truly trustworthy.
Even the best DOCXOs can "go rogue" from time to time and any microcontroller based setup, based on the assumption that the only variables are OCXO ageing and the effects of the ADC's tempco is almost certain to fall foul of the unpredictable behaviour of the OCXO (and room temperature on critical internal voltage rails). I plan to be as fully cognisant of the many factors that can trip up such microcontroller based solutions. Using the Lars design to control an RFS should let me neatly bypass the "rogue OCXO" issue (effectively cheating the limitations of an OCXO based solution and taking full advantage of the extremely long time constants that can be realised using a microcontroller
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/xsmiley.gif.pagespeed.ic.R8GFI-pF6f.png)
)
If you haven't already tried building a basic GPSDO and examined its limitations in some detail before embarking on this Lars DIY GPSDO project, you're going to leave yourself at a disadvantage. The attached images should help demonstrate the limitations of a GPSDO based on a single frequency timing receiver. You can cheat the worst limitation by spending 200+ quid on a ZED9 module which should eliminate the ionospheric effects, leaving you just the tropospheric moisture content mediated errors to contend with (about an order of magnitude less than the ionospheric effect).
I've just hit the new reduced from 25 to 10 attachments limit (along with the reduced from 5000KB to 4000KB individual size - not an issue in this case). It seems I'll have to make another two supplementary posts to send all 22 images (1.9MiB in total).
John