albertson.chris@gmail.com said:

If you are building a PLL, it's a lot easier to filter a 10KHz signal than a
1 Hz signal.

--
These are my opinions.  I hate spam.

On Thu, Jul 14, 2016 at 1:34 AM, Hal Murray hmurray@megapathdsl.net wrote:

You are correct.  But this guy is building a nixie tube clock.  The
clock should increment the seconds at the tick of the UTC second.
There really is no way to do this without using the PPS.  The serial
data is not aligned with the UTC "tick"
GPS receivers work just like the old telephone time service "At the
tone the time will be..." and then comes the leading edge of the 1PPS.

If he were building a frequency standard then, yes the 10KHz signal
would be the best one to use.

--

Chris Albertson
Redondo Beach, California

Why I was even thinking about it at all was that one of the models I
looked at said the 10KHz was more accurate than the 1PPS, so I was kind
of thinking about that. If the Ubloxes have 1PPS which are just as good
then there is no reason to think about a 10KHz.

John S.

On 7/14/2016 9:45 PM, Chris Albertson wrote:

Hi

Ok, I guess we need to go into this again:

All of the output signals generated by one of these cheap GPS modules
come from the internal TCXO on the module. All the signals.

None of the TCXO’s on any of these modules are tuned to match the GPS.
None of them, zero, not any.

All of the output signals from all of these modules are matched up to GPS
by guessing which clock edge to use.

The result for all of these modules and all of their output signals is a signal
with a lot of jitter.

All GPS based systems are limited by the noise of the GPS signal. It is
really dirty at short time intervals. The shorter the interval, the more noise
it has. Any signal that directly tracks GPS will be very dirty.

The only way to clean up GPS to make it useful as a frequency source is
with a very narrowband loop.

If you are implementing a < 0.01 Hz wide loop, it is no harder to do at 1 Hz
than 10 KHz or 100 MHz. In many respects it is easier to do at 1 Hz.

If the objective is a time display that is read with a human eye, anything
under 1 ms is not of much use. Your eye can’t detect it. Getting to 1 ns
is a different task than getting to 1 ms. A Hydrogen Maser flywheel is
not needed as part of a basic wall clock design.

Lots of variables, but also lots of basic facts.

Bob

For the NIXIE clock use case the jitter on the 1PPS hardly matters
because we have worse problems, like human perception.  When a clock
digit changes there is at least a 50ms time for the human eye/brain to
notice.  I think for a visual clock display a good goals is to make
it ONLY one order of magnitude better then human perception can
detect.  We can accept a few milliseconds.

But of cours if we insist on perfection we will have to phase lock our
own oscillator to UTC and account of the delay in our tube drivers

But do remember that our eyes do not notice the dark screen between
frames at the cinema.  Assuming a film projector, the shutter is
closed 24 times per second but we perceive a bright screen.  If we
watched a movie of a clock, we'd think the second have moves smoothly
even if we knew it was updated 24 times per second.  Errors on the
order of 50ms are not detectable by eye by most people.

On Fri, Jul 15, 2016 at 5:05 AM, Bob Camp kb8tq@n1k.org wrote:

--

Chris Albertson
Redondo Beach, California

Hi

…. we had headed off into the “virtues” of PLL’s locking to 10 KHz ….

=====

To get a time resolution of 10 ms (yes 10X 1 ms), you don’t really need the pps. The timing of
the serial string is probably “good enough”. That assumes you don’t have all sorts of other
messages  turned on as well. In the case of a wall clock, it’s not clear why anything other
than a basic timing message would be enabled.  A sub $10 module likely will do everything
you need to do.

Bob

A visual clock has uses other than to be readable by humans.

I made a GPS clock once with 100 ms display resolution once for the purpose of timestamping photographs accurately. Photographs can have far, far shorter shutter speeds (or the digital equivalent) than human POV flicker rates.

Yo Bob!

On Fri, 15 Jul 2016 12:54:43 -0400
Bob Camp kb8tq@n1k.org wrote:

Very unlikely you can get 10 ms from the serial timing.  And as long
as you are not overflowing your buffer with serial data the number
of sentences does not matter.

You are looking at the time in the first sentence of the second to
grab a time stamp.

In terms of absolute accuracy (offset), a few GPS start the first second
before the end of the second, some as late at 900 ms, or more, into the
second.

In terms of jitter, the first GPS sentence may jitter up to +/- 400 ms
over a few hours.  The GPS has a small CPU and a lot of floating point
math to do.  As sats come and go the time to compute a fix, and output
the first sentence, varies a lot, in unpredictable ways.

My guess is that with most consumer GPS, when you have the average delay
dialed in, you'll have a tough time getting much better than +/- 100 ms.

I have pretty graphs of several weeks of data for several GPS types
if you want to see the actual data.

For example, I have an Uputronics HAT here:
https://pi3.rellim.com/week/

The offset of the GPS time from PPS time is 80 ms.  The jitter is just
under +/- 30 ms.

On an Adafruit HAT the offset about 250 ms and jitter is almost +/- 400 ms:
https://pi2.rellim.com/week/

On an MR-350p the offset is 80 ms and jitter is just under +/- 150 ms:
https://rellim.com/graphs/week/

YMMV.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

Hi

Well, if you actually sit down and measure the serial timing on a modern GPS
module, you will find that it is very consistent. That degrades quickly if you
enable a few dozen sentences. Sub 10 ms accuracy is not a tough target to
hit when standing still.

You will need to work out the delay between your chosen character in the
string and the signal on the clock. If you are talking about a Nixie based device,
there are lots of “many ms” sort of delays to track down and calibrate out. You
measure them, come up with a fudge factor, and stuff that into your code. Once
you have the number, it’s not likely to change.

Bob