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 <[email protected]>
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 <[email protected]> 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 -- [email protected]
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
