[time-nuts] Accuracy/drift of Garmin GPS 16 HVS 1 PPS output under invalid fix conditions...

[Taka Kamiya]

I have an older version of this.  GPS 16 LVS.  I was using it with NTP and I wasn't watching it too closely.  I don't even know if they are the same thing internally.  I vaguely recall, with LVS, when lock is lost, PPS was gone, too.

--------------------------------------- 
(Mr.) Taka Kamiya
I'm stuck in a wormhole....  Hello, worms! 

    On Tuesday, March 12, 2019, 11:02:50 PM EDT, Bob kb8tq <kb8tq at n1k.org> wrote:  
 
 Hi

Maybe if we keep the thread alive long enough *somebody* will measure a GPS 16 simply to get rid of us :) 

What if you put an accurate clock on the micro that feeds the AND gate ( yes, the one we threw out last message). 
Let it “flywheel” (= produce it’s own 1 ms accurate pulse) when the GPS goes away. Windows may have trouble 
with 1 ms sort of stuff. Micros don’t have much trouble in that regard. 

More or less “substitute” the output of an oscillator you know is good to << 1 ms over 15 minutes when you need it.

Bob

> On Mar 12, 2019, at 6:20 PM, Steve Olney <t0502 at 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" :-)
> 
> 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.
> 
> Thanks for your suggestions.
> 
> Cheers
> 
> Steve
> 
> HawkRAO
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


_______________________________________________
time-nuts mailing list -- time-nuts at lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.