Re: [time-nuts] GPS for Nixie Clock
I don't know what you'd do with 10KHz except divide it by 10,000 to create
your own 1PPS but how to get it to "tick" on the exact UTC second?
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:
If you are building a PLL, it's a lot easier to filter a 10KHz signal than a
1 Hz signal.
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:
On Thu, Jul 14, 2016 at 1:34 AM, Hal Murray hmurray@megapathdsl.net wrote:
If you are building a PLL, it's a lot easier to filter a 10KHz signal than a
1 Hz signal.
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.
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
On Jul 15, 2016, at 1:19 AM, John Swenson johnswenson1@comcast.net wrote:
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:
On Thu, Jul 14, 2016 at 1:34 AM, Hal Murray hmurray@megapathdsl.net wrote:
If you are building a PLL, it's a lot easier to filter a 10KHz signal than a
1 Hz signal.
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.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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
That seems a somewhat negative assessment, Bob. For time purposes (even to
within a microsecond), the PPS output from the ublox etc. modules is more
than good enough (for a Nixie clock and many more needs). Couple the PPS
with the time from the serial output in your micro and that's completely
adequate. TCXO not even needed.
Yes, frequency is a different matter.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
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:
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
On Jul 15, 2016, at 1:19 AM, John Swenson johnswenson1@comcast.net wrote:
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:
On Thu, Jul 14, 2016 at 1:34 AM, Hal Murray hmurray@megapathdsl.net wrote:
If you are building a PLL, it's a lot easier to filter a 10KHz signal than a
1 Hz signal.
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.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Hi
On Jul 15, 2016, at 9:44 AM, David J Taylor david-taylor@blueyonder.co.uk 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
That seems a somewhat negative assessment, Bob. For time purposes (even to within a microsecond), the PPS output from the ublox etc. modules is more than good enough (for a Nixie clock and many more needs). Couple the PPS with the time from the serial output in your micro and that's completely adequate. TCXO not even needed.
Yes, frequency is a different matter.
…. 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
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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.
On Jul 15, 2016, at 8:19 AM, Chris Albertson albertson.chris@gmail.com wrote:
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:
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
On Jul 15, 2016, at 1:19 AM, John Swenson johnswenson1@comcast.net wrote:
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:
On Thu, Jul 14, 2016 at 1:34 AM, Hal Murray hmurray@megapathdsl.net wrote:
If you are building a PLL, it's a lot easier to filter a 10KHz signal than a
1 Hz signal.
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.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Yo Bob!
On Fri, 15 Jul 2016 12:54:43 -0400
Bob Camp kb8tq@n1k.org wrote:
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”.
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
On Jul 15, 2016, at 2:23 PM, Gary E. Miller gem@rellim.com wrote:
Yo Bob!
On Fri, 15 Jul 2016 12:54:43 -0400
Bob Camp kb8tq@n1k.org wrote:
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”.
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
As I mentioned in a previous post, this Nixie retrofit is not about
"good enough", it is a learning experience for me to understand the ins
and outs of GPS based time, so it is going to do all kinds of things
that are not NEEDED but that is the fun of the project.
I'm also looking into designing my own patch antennas to get the best
sensitivity in the restricted confines of the block of wood, yet
something else to learn about.
That's what this is all about.
I yes I probably will do an FPGA controlled PLL for the fun of it (I
have done that before).
John S.
On 7/15/2016 9:54 AM, Bob Camp wrote:
Hi
On Jul 15, 2016, at 9:44 AM, David J Taylor david-taylor@blueyonder.co.uk 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
That seems a somewhat negative assessment, Bob. For time purposes (even to within a microsecond), the PPS output from the ublox etc. modules is more than good enough (for a Nixie clock and many more needs). Couple the PPS with the time from the serial output in your micro and that's completely adequate. TCXO not even needed.
Yes, frequency is a different matter.
…. 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
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
If you are going to go “full boat” then you probably should get the sawtooth correction out of
the GPS and feed that into your control loop. You will need something you can run out at the
“few hundred seconds” sort of time constant.
Bob
On Jul 15, 2016, at 5:25 PM, John Swenson johnswenson1@comcast.net wrote:
As I mentioned in a previous post, this Nixie retrofit is not about "good enough", it is a learning experience for me to understand the ins and outs of GPS based time, so it is going to do all kinds of things that are not NEEDED but that is the fun of the project.
I'm also looking into designing my own patch antennas to get the best sensitivity in the restricted confines of the block of wood, yet something else to learn about.
That's what this is all about.
I yes I probably will do an FPGA controlled PLL for the fun of it (I have done that before).
John S.
On 7/15/2016 9:54 AM, Bob Camp wrote:
Hi
On Jul 15, 2016, at 9:44 AM, David J Taylor david-taylor@blueyonder.co.uk 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
That seems a somewhat negative assessment, Bob. For time purposes (even to within a microsecond), the PPS output from the ublox etc. modules is more than good enough (for a Nixie clock and many more needs). Couple the PPS with the time from the serial output in your micro and that's completely adequate. TCXO not even needed.
Yes, frequency is a different matter.
…. 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
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Yep, that is theory. The fun part is going to be getting the right edge
for the new PPS. Half the time it will the one before the PPS from the
GPS and half the time it will be the one after. From the sawtooth data I
should be able to figure out which is which to align it to the new LO.
John S.
On 7/15/2016 3:17 PM, Bob Camp wrote:
Hi
If you are going to go “full boat” then you probably should get the sawtooth correction out of
the GPS and feed that into your control loop. You will need something you can run out at the
“few hundred seconds” sort of time constant.
Bob
HI
The only practical way to do a “filter” is with a flywheel oscillator. You will need at least a TCXO to hold the ADEV
somewhere reasonable while the system it doing its thing. Something VCO based will not do the job.
Bob
On Jul 15, 2016, at 6:53 PM, John Swenson johnswenson1@comcast.net wrote:
Yep, that is theory. The fun part is going to be getting the right edge for the new PPS. Half the time it will the one before the PPS from the GPS and half the time it will be the one after. From the sawtooth data I should be able to figure out which is which to align it to the new LO.
John S.
On 7/15/2016 3:17 PM, Bob Camp wrote:
Hi
If you are going to go “full boat” then you probably should get the sawtooth correction out of
the GPS and feed that into your control loop. You will need something you can run out at the
“few hundred seconds” sort of time constant.
Bob
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
If you are going for the sawtooth correction then you also might want
to add some kind of forward correction for the delay in the tubes and
the drivers. Your MOSFET gates the nixie tube itself have capacitance
and switch times that will delay the switch of the display and of
course the digital processing in the FPGA takes some number of
nanoseconds. I think you might need some way to actually measure all
of these as any estimate might be your single largest source of error.
I don't know how to measure it. Perhaps a pair of phototransistors
one aimed at a PPS LED and one at the nixie tube. This unknown delay
is likely larger than the sawtooth correction. at this level you
might have to define when a digital is actually "on" as there is
likely some thermal constant and the numbers don't light up instantly.
I'd bet the turn on time is larger than the sawtooth correction.
What is "on"? 50% brightness?
It gets hard when you start caring about tiny increments of time. I
have a mechanical clock, about 14 inches in diameter that is slaved to
NTP. The designer took a big short cut. Time is kept internally at
the hundreds of microseconds level and the pulse goes off to the
stepper motor at the correct time well at least at the 100+
microsecond level but the hands don't move instantly because (1)
slight gear backlash and (2) they have mass. I can actually SEE the
delay with my eyes. The designer must have forgotten that a "move"
command requires some milliseconds to execute (I'm thinking about
100ms or more). I don't care but it's fun to think the actual display
is 10,000 times less accurate then the internal timekeeping. You
don't want this to happen to happen nixie clock
BTW I did not build my mechanical NTP clock. I got a free broken
clock and had to fix it, cut and soldered a few traces, fixed some
cracked parts and learned how it works in the process.
Finding which PPS to use is easy, you can do that by eye. Compare the
serial data stream to the time on your NTP sync'd computer. A full
second off problem is easy to see.
On Fri, Jul 15, 2016 at 3:53 PM, John Swenson johnswenson1@comcast.net wrote:
Yep, that is theory. The fun part is going to be getting the right edge for
the new PPS. Half the time it will the one before the PPS from the GPS and
half the time it will be the one after. From the sawtooth data I should be
able to figure out which is which to align it to the new LO.
John S.
On 7/15/2016 3:17 PM, Bob Camp wrote:
Hi
If you are going to go “full boat” then you probably should get the
sawtooth correction out of
the GPS and feed that into your control loop. You will need something you
can run out at the
“few hundred seconds” sort of time constant.
Bob
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Hi
You can do a pretty good job with a high speed photo diode. They are not cheap, but
you can get fast ones if your Visa card is up to it.
The next layer will be that at the relatively low strike voltages normally used, Nixie’s don’t
light up consistently. You either need to compensate for temperature and ambient light / then
calibrate each segment or sense each one as it turns on. Either way … it’s a major learning
experience just to get it into the microseconds range. You can get to nanoseconds, but that
may or may not be possible with conventional Nixie’s.
Once you have them turned on, you go back through something similar when you turn them
off. It takes a bit of time for all the little gas molecules to go back to rest state. The data I have seen
on that sort of thing suggests a “many microseconds” to millisecond decay process depending
on the gas and how it was driven.
Bob
On Jul 15, 2016, at 7:57 PM, Chris Albertson albertson.chris@gmail.com wrote:
If you are going for the sawtooth correction then you also might want
to add some kind of forward correction for the delay in the tubes and
the drivers. Your MOSFET gates the nixie tube itself have capacitance
and switch times that will delay the switch of the display and of
course the digital processing in the FPGA takes some number of
nanoseconds. I think you might need some way to actually measure all
of these as any estimate might be your single largest source of error.
I don't know how to measure it. Perhaps a pair of phototransistors
one aimed at a PPS LED and one at the nixie tube. This unknown delay
is likely larger than the sawtooth correction. at this level you
might have to define when a digital is actually "on" as there is
likely some thermal constant and the numbers don't light up instantly.
I'd bet the turn on time is larger than the sawtooth correction.
What is "on"? 50% brightness?
It gets hard when you start caring about tiny increments of time. I
have a mechanical clock, about 14 inches in diameter that is slaved to
NTP. The designer took a big short cut. Time is kept internally at
the hundreds of microseconds level and the pulse goes off to the
stepper motor at the correct time well at least at the 100+
microsecond level but the hands don't move instantly because (1)
slight gear backlash and (2) they have mass. I can actually SEE the
delay with my eyes. The designer must have forgotten that a "move"
command requires some milliseconds to execute (I'm thinking about
100ms or more). I don't care but it's fun to think the actual display
is 10,000 times less accurate then the internal timekeeping. You
don't want this to happen to happen nixie clock
BTW I did not build my mechanical NTP clock. I got a free broken
clock and had to fix it, cut and soldered a few traces, fixed some
cracked parts and learned how it works in the process.
Finding which PPS to use is easy, you can do that by eye. Compare the
serial data stream to the time on your NTP sync'd computer. A full
second off problem is easy to see.
On Fri, Jul 15, 2016 at 3:53 PM, John Swenson johnswenson1@comcast.net wrote:
Yep, that is theory. The fun part is going to be getting the right edge for
the new PPS. Half the time it will the one before the PPS from the GPS and
half the time it will be the one after. From the sawtooth data I should be
able to figure out which is which to align it to the new LO.
John S.
On 7/15/2016 3:17 PM, Bob Camp wrote:
Hi
If you are going to go “full boat” then you probably should get the
sawtooth correction out of
the GPS and feed that into your control loop. You will need something you
can run out at the
“few hundred seconds” sort of time constant.
Bob
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
It does not matter how slowly a nixie tube and it's driver operate,
you can still get them to light up exactly one time. I've been
playing with robots lately and if you think tubes take time to light
up, you should try moving a few kilograms around with a battery
powered motor. But even the motors can be made to move on time. The
key in both cases is feedback. The motor have shaft encoders, your
"microsecond level nixie tube" will need photo sensors. Then in both
cases you apply a forward correction so as to start the process going
early enough that it finishes on time. A servo controller algorithm
adjusts the correction based on measured error. Of course I could
just estimate everything and run open loop but you don't get to
microseconds that way.
I said "photosensor" for feedback but maybe something else will work,
perhaps yu measure current on the common anode or do both. I think
you may be inventing new engineering as I doubt anyone else has tried
to get a nixie tube to change at timing accuracy under a few
milliseconds.
I did write that it's useless to have a visual display that is three
orders of magnitude better than the human perceptional system and was
corrected that such a display could be used for film based
photography. That is true. But that just adds even more problems
like making certain the display never changes while the camera shutter
is open. These old camera time loggers were hooked up to the shutter
release. I think they captured the time of day when the shutter opens
and hold it for the duration of the exposure. I have some old ones
that I can check, but I'm certain they did not change while the
shutter was open. They did not light up at all when the shutter was
closed. If they did change without regard to the camera shutter then
on order 1% of the shots would capture the increment and with a
7-segment number it would be unreadable. But this never happened.
On Fri, Jul 15, 2016 at 5:25 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
You can do a pretty good job with a high speed photo diode. They are not cheap, but
you can get fast ones if your Visa card is up to it.
The next layer will be that at the relatively low strike voltages normally used, Nixie’s don’t
light up consistently. You either need to compensate for temperature and ambient light / then
calibrate each segment or sense each one as it turns on. Either way … it’s a major learning
experience just to get it into the microseconds range. You can get to nanoseconds, but that
may or may not be possible with conventional Nixie’s.
Once you have them turned on, you go back through something similar when you turn them
off. It takes a bit of time for all the little gas molecules to go back to rest state. The data I have seen
on that sort of thing suggests a “many microseconds” to millisecond decay process depending
on the gas and how it was driven.
Bob
On Jul 15, 2016, at 7:57 PM, Chris Albertson albertson.chris@gmail.com wrote:
If you are going for the sawtooth correction then you also might want
to add some kind of forward correction for the delay in the tubes and
the drivers. Your MOSFET gates the nixie tube itself have capacitance
and switch times that will delay the switch of the display and of
course the digital processing in the FPGA takes some number of
nanoseconds. I think you might need some way to actually measure all
of these as any estimate might be your single largest source of error.
I don't know how to measure it. Perhaps a pair of phototransistors
one aimed at a PPS LED and one at the nixie tube. This unknown delay
is likely larger than the sawtooth correction. at this level you
might have to define when a digital is actually "on" as there is
likely some thermal constant and the numbers don't light up instantly.
I'd bet the turn on time is larger than the sawtooth correction.
What is "on"? 50% brightness?
It gets hard when you start caring about tiny increments of time. I
have a mechanical clock, about 14 inches in diameter that is slaved to
NTP. The designer took a big short cut. Time is kept internally at
the hundreds of microseconds level and the pulse goes off to the
stepper motor at the correct time well at least at the 100+
microsecond level but the hands don't move instantly because (1)
slight gear backlash and (2) they have mass. I can actually SEE the
delay with my eyes. The designer must have forgotten that a "move"
command requires some milliseconds to execute (I'm thinking about
100ms or more). I don't care but it's fun to think the actual display
is 10,000 times less accurate then the internal timekeeping. You
don't want this to happen to happen nixie clock
BTW I did not build my mechanical NTP clock. I got a free broken
clock and had to fix it, cut and soldered a few traces, fixed some
cracked parts and learned how it works in the process.
Finding which PPS to use is easy, you can do that by eye. Compare the
serial data stream to the time on your NTP sync'd computer. A full
second off problem is easy to see.
On Fri, Jul 15, 2016 at 3:53 PM, John Swenson johnswenson1@comcast.net wrote:
Yep, that is theory. The fun part is going to be getting the right edge for
the new PPS. Half the time it will the one before the PPS from the GPS and
half the time it will be the one after. From the sawtooth data I should be
able to figure out which is which to align it to the new LO.
John S.
On 7/15/2016 3:17 PM, Bob Camp wrote:
Hi
If you are going to go “full boat” then you probably should get the
sawtooth correction out of
the GPS and feed that into your control loop. You will need something you
can run out at the
“few hundred seconds” sort of time constant.
Bob
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
I, for one, will be following your progress...
I think it would be cool as heck having an ultra-accurate clock with a
Nixie display... It'd be cool to make it flexible enough to output the
time sync to other equipment...
Clay Autery, KY5G
MONTAC Enterprises
(318) 518-1389
On 7/15/2016 4:25 PM, John Swenson wrote:
As I mentioned in a previous post, this Nixie retrofit is not about
"good enough", it is a learning experience for me to understand the
ins and outs of GPS based time, so it is going to do all kinds of
things that are not NEEDED but that is the fun of the project.
I'm also looking into designing my own patch antennas to get the best
sensitivity in the restricted confines of the block of wood, yet
something else to learn about.
That's what this is all about.
I yes I probably will do an FPGA controlled PLL for the fun of it (I
have done that before).
John S.
Hi
As this is going, it’s not a clock at all. It’s a GPSDO with a Nixie display on it
and now with IRIG timing output.
Do we put an Rb in it or go straight to a Cesium?
Bob
On Jul 15, 2016, at 9:38 PM, Clay Autery cautery@montac.com wrote:
I, for one, will be following your progress...
I think it would be cool as heck having an ultra-accurate clock with a
Nixie display... It'd be cool to make it flexible enough to output the
time sync to other equipment...
Clay Autery, KY5G
MONTAC Enterprises
(318) 518-1389
On 7/15/2016 4:25 PM, John Swenson wrote:
As I mentioned in a previous post, this Nixie retrofit is not about
"good enough", it is a learning experience for me to understand the
ins and outs of GPS based time, so it is going to do all kinds of
things that are not NEEDED but that is the fun of the project.
I'm also looking into designing my own patch antennas to get the best
sensitivity in the restricted confines of the block of wood, yet
something else to learn about.
That's what this is all about.
I yes I probably will do an FPGA controlled PLL for the fun of it (I
have done that before).
John S.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I think it would be cool as heck having an ultra-accurate clock with a Nixie display...
http://leapsecond.com/pages/atomic-nixie/
/tvb
----- Original Message -----
From: "Clay Autery" cautery@montac.com
To: time-nuts@febo.com
Sent: Friday, July 15, 2016 6:38 PM
Subject: Re: [time-nuts] GPS for Nixie Clock
I, for one, will be following your progress...
I think it would be cool as heck having an ultra-accurate clock with a
Nixie display... It'd be cool to make it flexible enough to output the
time sync to other equipment...
Clay Autery, KY5G
MONTAC Enterprises
(318) 518-1389
On 7/15/2016 4:25 PM, John Swenson wrote:
As I mentioned in a previous post, this Nixie retrofit is not about
"good enough", it is a learning experience for me to understand the
ins and outs of GPS based time, so it is going to do all kinds of
things that are not NEEDED but that is the fun of the project.
I'm also looking into designing my own patch antennas to get the best
sensitivity in the restricted confines of the block of wood, yet
something else to learn about.
That's what this is all about.
I yes I probably will do an FPGA controlled PLL for the fun of it (I
have done that before).
John S.