Re: [time-nuts] LTE-Lite module
Bill wrote:
How tough would it be to mate the 10Mhz version up to a really good 10811?
-
-
- I was thinking of throwing the LTE-Lite and the 10811 in a box.
-
Unfortunately, to get the best out of the local oscillator, the
control PLL must be carefully adjusted so that the oscillator itself
controls the stability at averaging times (tau) where it is better
than the GPS (generally, up to tau of several hundred to maybe
several thousand seconds), and the GPS controls the stability at
longer tau. The LTE-Lite has fixed (non-adjustable) loop parameters
that cross over to the GPS at much lower tau than is appropriate for
a good OCXO (but well suited to the installed TXCO).
The other day Said (I think) mentioned some hacks that may sort-of
improve the ability of an LTE-Lite to discipline an OCXO, but that's
all they are -- very approximate hacks. There is really no way to
properly mate an OCXO to the LTE-Lite control loop, which would
require adjusting the PLL loop gain and the location of the loop's
poles and zeroes (and possibly even adding new poles and
zeroes). That would need to be done by changing the PLL parameters
internal to the LTE-Lite, which are inaccessible. Without such
reprogramming, the LTE-Light can never get the best out of an OCXO.
Best regards,
Charles
In message 20141019155055.osMiKB63@smtp11.mail.yandex.net, Charles Steinmetz
writes:
zeroes). That would need to be done by changing the PLL parameters
internal to the LTE-Lite, which are inaccessible. Without such
reprogramming, the LTE-Light can never get the best out of an OCXO.
It certainly can and it's not even hard:
Configure the LTE to emit a suitable frequency relative to the
OCXO and use an analog PLL to steer the OCXO's EFC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Poul-Henning wrote:
zeroes). That would need to be done by changing the PLL parameters
internal to the LTE-Lite, which are inaccessible. Without such
reprogramming, the LTE-Light can never get the best out of an OCXO.
It certainly can and it's not even hard:
Configure the LTE to emit a suitable frequency relative to the
OCXO and use an analog PLL to steer the OCXO's EFC.
Any worthwhile OCXO will need a loop with a time constant on the
order of hundreds of seconds (a corner frequency on the order of uHz)
to get the most out of it as a GPSDO. As has been discussed on the
list many times, there is simply no practicable way to design an
analog loop with such a long time constant. So the person designing
the PLL must be able to design and build an all-digital PLL, or
settle for a loop that crosses over to the GPS several decades too
early (which is certainly not getting the most out of the OCXO).
Best regards,
Charles
In message 20141019183956.dt4Ss5gj@smtp2o.mail.yandex.net, Charles Steinmetz
writes:
Configure the LTE to emit a suitable frequency relative to the
OCXO and use an analog PLL to steer the OCXO's EFC.
Then do it digital, it's not like it's rocket science...
Take the analog phase detector output, read it with ADC pin,
do loop in software, drive efc with DAC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Hi
The phase comparison part of the PLL is pretty straightforward if you are looking at two RF frequencies. An XOR gate is one solution, there are many others. Getting something like 100 to 200 ns full scale on the phase comparator makes the rest of the gizmo much easier. A 12 bit ADC on a MCU will get you to 100’s of ps per bit., That is more resolution (it’s < 1 ns) than you need for this. Controlling the OCXO is either an outboard ADC ($2 or so) or a PWM (free with the MCU). There will be a few regulators, resistors, caps, and maybe a pot or two involved as well.
Total parts cost on the digital loop done with an appropriate MCU is probably less than $10. Custom code wise, it’s a few hundred lines of C on a 32 bit ARM. Pre built (wizard driven) device init stuff will be way more than that, but you don’t write any of that. Since it’s just a PLL and not a full GPSDO, there’s not a whole lot to it. If building up the MCU board is the issue, there are many eval boards out there for < $15 that will do the trick.
Debug, optimization and tweaking are where the major effort is (like 80 to 90%). That will take at least few months of work and require some test gear. Any time you plug in a significantly different oscillator, you will have to put in this part of the effort. Getting the long run ADEV data, making sure it’s right, and then analyzing the result is something there is no magic shortcut around. If you are set up for it (you are a TIme Nut right?) , there’s no cost other than your time. If it’s a hobby - your time is free (or is it …).
No it’s not a “plug in a pre-made gizmo and forget about it” sort of thing. There is real work, lots of time, mental effort, working gear, and patience involved. You will get it wrong more often than you get it right as you go through the process. Stuff happens, runs crash, gear fails, it’s the real world. That’s the learning part of the project. If its a hobby that’s what you are doing this for.
Bob
On Oct 19, 2014, at 10:39 AM, Charles Steinmetz csteinmetz@yandex.com wrote:
Poul-Henning wrote:
zeroes). That would need to be done by changing the PLL parameters
internal to the LTE-Lite, which are inaccessible. Without such
reprogramming, the LTE-Light can never get the best out of an OCXO.
It certainly can and it's not even hard:
Configure the LTE to emit a suitable frequency relative to the
OCXO and use an analog PLL to steer the OCXO's EFC.
Any worthwhile OCXO will need a loop with a time constant on the order of hundreds of seconds (a corner frequency on the order of uHz) to get the most out of it as a GPSDO. As has been discussed on the list many times, there is simply no practicable way to design an analog loop with such a long time constant. So the person designing the PLL must be able to design and build an all-digital PLL, or settle for a loop that crosses over to the GPS several decades too early (which is certainly not getting the most out of the OCXO).
Best regards,
Charles
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.
Bob wrote (alluding also to something Poul-Henning wrote):
The phase comparison part of the PLL is pretty
straightforward if you are looking at two RF
frequencies. An XOR gate is one solution, there
are many others. Getting something like 100 to
200 ns full scale on the phase comparator makes
the rest of the gizmo much easier.
All true. However...
A 12 bit ADC on a MCU will get you to 100's of
ps per bit. That is more resolution (it's < 1 ns) than you need for this.
Getting an ADC to sample fast and accurately
enough to provide that honest resolution is not
trivial. And if you have that, you'll almost
certainly have the resources to do the phase
comparator digitally, too, which brings many
advantages -- so I see no reason to use an analog PC.
Custom code wise, it's a few hundred lines of C
on a 32 bit ARM. Pre built (wizard driven)
device init stuff will be way more than that, but you don't write any of that.
A proper digital filter that computes a new
running value at least every second will be more
complex than that, but you're right, it's not an unfathomable task.
Then comes the real work, well summarized by Bob:
Debug, optimization and tweaking are where the
major effort is (like 80 to 90%). That will take
at least few months of work and require some
test gear. Any time you plug in a significantly
different oscillator, you will have to put in
this part of the effort. Getting the long run
ADEV data, making sure it's right, and then
analyzing the result is something there is no magic shortcut around. * * *
No it's not a "plug in a pre-made gizmo and
forget about it" sort of thing. There is real
work, lots of time, mental effort, working
gear, and patience involved. You will get it
wrong more often than you get it right as you go through the process.
All of this explains why the woods are not full
of state-of-the-art GPSDO controllers just
waiting for people to couple them with whatever OCXO they bought on ebay.
BTW, I mean no slight to the LTE-Light. Judging
from the JL products I've used, I expect that it
is a fine product well-designed for its
task. But that task is controlling a TCXO, not
controlling an OCXO that is stable to 10e-12 or
better at tau from 1 to 100 seconds (unless one
goes to the trouble described above).
For a general look at the magnitude of the
stability difference between a TCXO and a number
of OCXOs and other frequency standards, see
attached (if the pic doesn't make it through the
listserv, see http://leapsecond.com/museum/manyadev.gif).
Best regards,
Charles
Hi
On Oct 19, 2014, at 3:35 PM, Charles Steinmetz csteinmetz@yandex.com wrote:
Bob wrote (alluding also to something Poul-Henning wrote):
The phase comparison part of the PLL is pretty straightforward if you are looking at two RF frequencies. An XOR gate is one solution, there are many others. Getting something like 100 to 200 ns full scale on the phase comparator makes the rest of the gizmo much easier.
All true. However...
A 12 bit ADC on a MCU will get you to 100's of ps per bit. That is more resolution (it's < 1 ns) than you need for this.
Getting an ADC to sample fast and accurately enough to provide that honest resolution is not trivial. And if you have that, you'll almost certainly have the resources to do the phase comparator digitally, too, which brings many advantages -- so I see no reason to use an analog PC.
If you take a look at some of the newer ARM MCU’s they are getting 13+ solid bits out of their ADC’s at a > 10 KHz rate. That’s more than good enough for anything you are trying to do with this design. There’s no need to make it any more complex.
A single gate XOR plus the eval board is just a about all you need. One dead bug part on the eval board and the assembly process is pretty much done. Maybe 45 minutes of work if you need to go find all the bits and pieces around your bench. Since almost nothing in the design is running at high speed, layout issues should not be a big deal. You could also do it on a fragment of board like the divider from earlier in this thread.
Custom code wise, it's a few hundred lines of C on a 32 bit ARM. Pre built (wizard driven) device init stuff will be way more than that, but you don't write any of that.
A proper digital filter that computes a new running value at least every second will be more complex than that, but you're right, it's not an unfathomable task.
Then comes the real work, well summarized by Bob:
Debug, optimization and tweaking are where the major effort is (like 80 to 90%). That will take at least few months of work and require some test gear. Any time you plug in a significantly different oscillator, you will have to put in this part of the effort. Getting the long run ADEV data, making sure it's right, and then analyzing the result is something there is no magic shortcut around. * * *
No it's not a "plug in a pre-made gizmo and forget about it" sort of thing. There is real work, lots of time, mental effort, working gear, and patience involved. You will get it wrong more often than you get it right as you go through the process.
All of this explains why the woods are not full of state-of-the-art GPSDO controllers just waiting for people to couple them with whatever OCXO they bought on ebay.
The optimization process is at least 90% perspiration and preparation. Neither of those are outside the range of what an average Joe can handle. The other (at most) 10% is very much a “that depends” sort of thing. You can head down all sorts of rabbit holes as you dig into this or that. For that, the list archives have tons of information to work from.
There is way more in a GPSDO than what we are talking about here. TimeNuts may or may not care much about that extra stuff, but it’s in there.
BTW, I mean no slight to the LTE-Light. Judging from the JL products I've used, I expect that it is a fine product well-designed for its task. But that task is controlling a TCXO, not controlling an OCXO that is stable to 10e-12 or better at tau from 1 to 100 seconds (unless one goes to the trouble described above).
For a general look at the magnitude of the stability difference between a TCXO and a number of OCXOs and other frequency standards, see attached (if the pic doesn't make it through the listserv, see http://leapsecond.com/museum/manyadev.gif).
Best regards,
Charles
<Oscillator_comparison_tvb.jpg>_______________________________________________
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.
The idea is not to make it as complex as you possibly could, but to make it as simple as possible and still have it work fine. There are a lot of shortcuts you can take with a one off unit that a commercial design would never use.
Bob
On 10/19/14, 1:08 PM, Bob Camp wrote:
Hi
On Oct 19, 2014, at 3:35 PM, Charles Steinmetz
csteinmetz@yandex.com wrote:
Bob wrote (alluding also to something Poul-Henning wrote):
The phase comparison part of the PLL is pretty straightforward if
you are looking at two RF frequencies. An XOR gate is one
solution, there are many others. Getting something like 100 to
200 ns full scale on the phase comparator makes the rest of the
gizmo much easier.
All true. However...
A 12 bit ADC on a MCU will get you to 100's of ps per bit. That
is more resolution (it's < 1 ns) than you need for this.
Getting an ADC to sample fast and accurately enough to provide that
honest resolution is not trivial. And if you have that, you'll
almost certainly have the resources to do the phase comparator
digitally, too, which brings many advantages -- so I see no reason
to use an analog PC.
If you take a look at some of the newer ARM MCU’s they are getting
13+ solid bits out of their ADC’s at a > 10 KHz rate. That’s more
than good enough for anything you are trying to do with this design.
There’s no need to make it any more complex.
I'm using the Freescale Kinetix K20 parts, which have 16 bit
differential input ADCs, and built in averaging. The raw ADC can sample
at about 400kHz.
You can easily get 14 bit performance from these at tens of kHz rates.
I need I/Q, so I sample two inputs at 50 kHz (read one, then the other)
without averaging (so they're about 2.5 microseconds apart), and then
decimate them through a 2 stage CIC and a 13 tap FIR filter down to 200
Hz. This takes about 60% of the processor running at 48MHz.
Hi
On Oct 19, 2014, at 5:00 PM, Jim Lux jimlux@earthlink.net wrote:
On 10/19/14, 1:08 PM, Bob Camp wrote:
Hi
On Oct 19, 2014, at 3:35 PM, Charles Steinmetz
csteinmetz@yandex.com wrote:
Bob wrote (alluding also to something Poul-Henning wrote):
The phase comparison part of the PLL is pretty straightforward if
you are looking at two RF frequencies. An XOR gate is one
solution, there are many others. Getting something like 100 to
200 ns full scale on the phase comparator makes the rest of the
gizmo much easier.
All true. However...
A 12 bit ADC on a MCU will get you to 100's of ps per bit. That
is more resolution (it's < 1 ns) than you need for this.
Getting an ADC to sample fast and accurately enough to provide that
honest resolution is not trivial. And if you have that, you'll
almost certainly have the resources to do the phase comparator
digitally, too, which brings many advantages -- so I see no reason
to use an analog PC.
If you take a look at some of the newer ARM MCU’s they are getting
13+ solid bits out of their ADC’s at a > 10 KHz rate. That’s more
than good enough for anything you are trying to do with this design.
There’s no need to make it any more complex.
I'm using the Freescale Kinetix K20 parts, which have 16 bit differential input ADCs, and built in averaging. The raw ADC can sample at about 400kHz.
You can easily get 14 bit performance from these at tens of kHz rates.
I need I/Q, so I sample two inputs at 50 kHz (read one, then the other) without averaging (so they're about 2.5 microseconds apart), and then decimate them through a 2 stage CIC and a 13 tap FIR filter down to 200 Hz. This takes about 60% of the processor running at 48MHz.
I’m using parts from the same family, but not doing the whole DDS thing. Single input and control loop - the part sleeps about 98% of the time. The demo boards (Freedom boards) are all below $15 and free if you go to one of their (often free) classes.
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.
At the low end of the spectrum, I tried to make the simplest possible
GPSDO what would still work. Assuming you have a GPS with 1PPS
output, an OCXO and a small DC power supply I was able to get the
entire parts for the controller, board, hookup wire and all for under
$5. I purposely took the lowest cost solution at each decision point
just to see what you'd end up with. Part were from eBay.
The result is not bad. but I don't have a really good way to test it.
I'm using a Thunderbolt for the 1PPS and a pretty decent OXCO part.
Why build a low-end GPSDO when yo have a Thunderbolt? It's and
experiment. The way I test is to place the sine output from the TB
and from my GPSDO both on a dual channel scope and adjust it so the
two sine waves are superimposed. Then I wait for them not to be
superimposed. What I see is that over 1/2 hour or so they get
slightly out of phase but then drift back in phase, This happens
cyclically. It is because of the VERY simply controller. I tried to
minimize lines of C++ code. It's running about 16 lines of code, more
or less. Using my counter I think the GPSDO is good to 1E-10.
Rather than using a $15 ARM MCU board I used a $3 AVR board and used
100% 16-bit integer math in a very simple control loop. There is one
external chip because the little AVR could not deal with the 10MHz
signal from the OCXO so I used a divider chip. I use two 8-bit DACs
to control the EFC on the OCXO. One is curse adjustment, one fine.
Added with a resister network and an RC filter with almost a 1 second
time constant.
If you can spend $35 you can build a very sophisticated controller
that logs internal diagnostic data to a computer over USB and displays
it's internal status on a graphic LCD panel. Well, actually my
controller has an LCD status display and logs data to a PC. But with
those parts plugged in the cost is closer to $10.
On Sun, Oct 19, 2014 at 2:13 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
On Oct 19, 2014, at 5:00 PM, Jim Lux jimlux@earthlink.net wrote:
On 10/19/14, 1:08 PM, Bob Camp wrote:
Hi
On Oct 19, 2014, at 3:35 PM, Charles Steinmetz
csteinmetz@yandex.com wrote:
Bob wrote (alluding also to something Poul-Henning wrote):
The phase comparison part of the PLL is pretty straightforward if
you are looking at two RF frequencies. An XOR gate is one
solution, there are many others. Getting something like 100 to
200 ns full scale on the phase comparator makes the rest of the
gizmo much easier.
All true. However...
A 12 bit ADC on a MCU will get you to 100's of ps per bit. That
is more resolution (it's < 1 ns) than you need for this.
Getting an ADC to sample fast and accurately enough to provide that
honest resolution is not trivial. And if you have that, you'll
almost certainly have the resources to do the phase comparator
digitally, too, which brings many advantages -- so I see no reason
to use an analog PC.
If you take a look at some of the newer ARM MCU’s they are getting
13+ solid bits out of their ADC’s at a > 10 KHz rate. That’s more
than good enough for anything you are trying to do with this design.
There’s no need to make it any more complex.
I'm using the Freescale Kinetix K20 parts, which have 16 bit differential input ADCs, and built in averaging. The raw ADC can sample at about 400kHz.
You can easily get 14 bit performance from these at tens of kHz rates.
I need I/Q, so I sample two inputs at 50 kHz (read one, then the other) without averaging (so they're about 2.5 microseconds apart), and then decimate them through a 2 stage CIC and a 13 tap FIR filter down to 200 Hz. This takes about 60% of the processor running at 48MHz.
I’m using parts from the same family, but not doing the whole DDS thing. Single input and control loop - the part sleeps about 98% of the time. The demo boards (Freedom boards) are all below $15 and free if you go to one of their (often free) classes.
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.
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
We seem to have swung from “it’s impossible, don’t even try” to “it’s trivial, you should have it done in a few minutes” :) (Yes I know that’s not at all what was said in either case. We have swung a ways though)
Yes, I can do it for less than $1 in parts. That’s not to say it’s the right way to do it. Yes, I can have it “done" (locked up) in a few hours (from scratch, including the parts). That’s not to say you should do it that way. My way most certainly should not be your way. The stuff I have sitting around is not the stuff you have lying around. What I paid may not be what you pay.
We spend a lot of time playing “I can do it cheaper”. Unless a few months of your time really is worth $10, the “cheaper” part simply does not count past some point. The cost of even one meal out over several months will wipe out that advantage. Doing it with a part that is running a 10 bit ADC that really gives you 8 bit performance will indeed impact the result. It’s cheaper, but how much struggle will there be to make it work well? Will it add a month or three to the project? Will you start over from scratch? Who knows. Are we comparing a board anybody can get for < $15 to just the cpu on another board .. maybe we are. If what counts is a price that somebody got once, I have boards that I got for free. Do they count as $0 in a project? There’s really no value even going down that road.
Each time this comes up on the list, we typically spend a month with everybody tossing up their favorite board. We each post several messages talking about the great deal we got. We never seem to get around to actually doing much with those cheap boards compared to the time everybody spends extolling their virtues (and ignoring their drawbacks). A $50 board is no different than a $1 board in this case. They both have near zero impact on the total investment in the project. If they did / do - buy a $135 OCXO based GPSDO rather than the $185 LTE board. That puts you $50 and months of your time ahead.
If you want to start from scratch and get a result that is “OCXO” caliber, it will take a while. 1x10^-10 is not your target. The LTE part pretty much does that. Your target is at least 1x10^-11 short term and much better a you go to a few hundred seconds. In order to say you have hit it, you need to test it and verify that you have hit it. No I can’t do a run that takes a month to verify a part I build in a short time.Nobody can do that, it takes time. No I don’t have a gizmo that’ stable to 1x10^-13 over a month sitting in the basement. If I already had that, why would I need to put an OCXO on a LTE board? I have to do some work simply to do the test (like build several and cross check them).
How much time does the testing take? You want something around 100 samples for a good ADEV number. You need data out to 1,000 seconds (and more likely 10,000 seconds) to check the loop out. Each run will be in the 1 to 10 days range. Once you have it “right” you really need to check it over a month or two to watch for GPS “once a day” issues. If you have a really good setup, you will get good data 4 runs out of 5. With a basement setup, that may drop to 2 in 5.
The job is not done once the first one is locked. That’s the quick and easy part. The full job is only done once you have it optimized and know you have done so from measured data. That’s true if you are making one, or making a few hundred thousand of them.
Bob
On Oct 19, 2014, at 6:14 PM, Chris Albertson albertson.chris@gmail.com wrote:
At the low end of the spectrum, I tried to make the simplest possible
GPSDO what would still work. Assuming you have a GPS with 1PPS
output, an OCXO and a small DC power supply I was able to get the
entire parts for the controller, board, hookup wire and all for under
$5. I purposely took the lowest cost solution at each decision point
just to see what you'd end up with. Part were from eBay.
The result is not bad. but I don't have a really good way to test it.
I'm using a Thunderbolt for the 1PPS and a pretty decent OXCO part.
Why build a low-end GPSDO when yo have a Thunderbolt? It's and
experiment. The way I test is to place the sine output from the TB
and from my GPSDO both on a dual channel scope and adjust it so the
two sine waves are superimposed. Then I wait for them not to be
superimposed. What I see is that over 1/2 hour or so they get
slightly out of phase but then drift back in phase, This happens
cyclically. It is because of the VERY simply controller. I tried to
minimize lines of C++ code. It's running about 16 lines of code, more
or less. Using my counter I think the GPSDO is good to 1E-10.
Rather than using a $15 ARM MCU board I used a $3 AVR board and used
100% 16-bit integer math in a very simple control loop. There is one
external chip because the little AVR could not deal with the 10MHz
signal from the OCXO so I used a divider chip. I use two 8-bit DACs
to control the EFC on the OCXO. One is curse adjustment, one fine.
Added with a resister network and an RC filter with almost a 1 second
time constant.
If you can spend $35 you can build a very sophisticated controller
that logs internal diagnostic data to a computer over USB and displays
it's internal status on a graphic LCD panel. Well, actually my
controller has an LCD status display and logs data to a PC. But with
those parts plugged in the cost is closer to $10.
On Sun, Oct 19, 2014 at 2:13 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
On Oct 19, 2014, at 5:00 PM, Jim Lux jimlux@earthlink.net wrote:
On 10/19/14, 1:08 PM, Bob Camp wrote:
Hi
On Oct 19, 2014, at 3:35 PM, Charles Steinmetz
csteinmetz@yandex.com wrote:
Bob wrote (alluding also to something Poul-Henning wrote):
The phase comparison part of the PLL is pretty straightforward if
you are looking at two RF frequencies. An XOR gate is one
solution, there are many others. Getting something like 100 to
200 ns full scale on the phase comparator makes the rest of the
gizmo much easier.
All true. However...
A 12 bit ADC on a MCU will get you to 100's of ps per bit. That
is more resolution (it's < 1 ns) than you need for this.
Getting an ADC to sample fast and accurately enough to provide that
honest resolution is not trivial. And if you have that, you'll
almost certainly have the resources to do the phase comparator
digitally, too, which brings many advantages -- so I see no reason
to use an analog PC.
If you take a look at some of the newer ARM MCU’s they are getting
13+ solid bits out of their ADC’s at a > 10 KHz rate. That’s more
than good enough for anything you are trying to do with this design.
There’s no need to make it any more complex.
I'm using the Freescale Kinetix K20 parts, which have 16 bit differential input ADCs, and built in averaging. The raw ADC can sample at about 400kHz.
You can easily get 14 bit performance from these at tens of kHz rates.
I need I/Q, so I sample two inputs at 50 kHz (read one, then the other) without averaging (so they're about 2.5 microseconds apart), and then decimate them through a 2 stage CIC and a 13 tap FIR filter down to 200 Hz. This takes about 60% of the processor running at 48MHz.
I’m using parts from the same family, but not doing the whole DDS thing. Single input and control loop - the part sleeps about 98% of the time. The demo boards (Freedom boards) are all below $15 and free if you go to one of their (often free) classes.
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.
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.
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you really need to check it over a month or two to watch for GPS “once a day” issues. "
Could I ask you what you meant by these "once a day issues"? Was this a general comment, or was it about something specific? As you know I'm working on a GPSDO and am doing a lot of testing, so if there's something else I should be looking for, please let me know.
Bob - AE6RV
Hi
The GPS constellation repeats roughly once a day. It is not at all uncommon to have a “worst case” sattelite geometry for a given antenna location. If you have one, it will repeat once a day and show up as a bump in the timing out of your GPS module. If you track long term data, it will / may / can keep you from getting to the sort of stability you would expect in the 100,000 second range. It’s one of the main reasons that things like GPSD-Rb’s lock up with time constants much longer than 100K seconds. Yes having a Cs or something similar helps a lot looking for this sort of thing.
Bob
On Oct 19, 2014, at 9:26 PM, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you really need to check it over a month or two to watch for GPS “once a day” issues. "
Could I ask you what you meant by these "once a day issues"? Was this a general comment, or was it about something specific? As you know I'm working on a GPSDO and am doing a lot of testing, so if there's something else I should be looking for, please let me know.
Bob - AE6RV
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 Bob, (Yahoo let me down again and I responded only to you. Here is my reply again.)
OK, it sounds like something that would not be clearly noticeable with the
equipment I have. I haven't run many multi-day tests, so that's another handicap on this end. Still developing and testing, but things are
looking better than the last time I spoke about my unit.
thanks,
Bob
From: Bob Camp kb8tq@n1k.org
To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Sunday, October 19, 2014 8:50 PM
Subject: Re: [time-nuts] "GPS once a day issues" ?
Hi
The GPS constellation repeats roughly once a day. It is not at all uncommon to have a “worst case” sattelite geometry for a given antenna location. If you have one, it will repeat once a day and show up as a bump in the timing out of your GPS module. If you track long term data, it will / may / can keep you from getting to the sort of stability you would expect in the 100,000 second range. It’s one of the main reasons that things like GPSD-Rb’s lock up with time constants much longer than 100K seconds. Yes having a Cs or something similar helps a lot looking for this sort of thing.
Bob
On Oct 19, 2014, at 9:26 PM, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you really need to check it over a month or two to watch for GPS “once a day” issues. "
Could I ask you what you meant by these "once a day issues"? Was this a general comment, or was it about something specific? As you know I'm working on a GPSDO and am doing a lot of testing, so if there's something else I should be looking for, please let me know.
Bob - AE6RV
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.
In message 20141019233526.ZNMKxMfK@smtp11.mail.yandex.net, Charles Steinmetz
writes:
A proper digital filter that computes a new
running value at least every second will be more
complex than that, but you're right, it's not an unfathomable task.
No, it will not, a simple running average will do just fine.
PLLs are really not that hard, and as it happens I wrote this a
couple of days ago about it:
http://phk.freebsd.dk/time/20141018.html
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Bob,
Since the satellite orbit the earth with a period of 11 hours and 58
minutes, it is actually twice a day.
Cheers,
Magnus
On 10/20/2014 03:50 AM, Bob Camp wrote:
Hi
The GPS constellation repeats roughly once a day. It is not at all uncommon to have a “worst case” sattelite geometry for a given antenna location. If you have one, it will repeat once a day and show up as a bump in the timing out of your GPS module. If you track long term data, it will / may / can keep you from getting to the sort of stability you would expect in the 100,000 second range. It’s one of the main reasons that things like GPSD-Rb’s lock up with time constants much longer than 100K seconds. Yes having a Cs or something similar helps a lot looking for this sort of thing.
Bob
On Oct 19, 2014, at 9:26 PM, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you really need to check it over a month or two to watch for GPS “once a day” issues. "
Could I ask you what you meant by these "once a day issues"? Was this a general comment, or was it about something specific? As you know I'm working on a GPSDO and am doing a lot of testing, so if there's something else I should be looking for, please let me know.
Bob - AE6RV
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.
From: Dave Cawley
Dartmouth United Kingdom
Femtosecond Systems FSS 600 phase noise detector
Guys
Just won this on eBay. Try as I might, I can't find any details especially a circuit/schematic diagram. Can anyone help please ?
Thanks
Dave
The constellation may repeat at 12hr intervals , but at any static position you will only see one per day , no? , the other being 180 degrees way. I only get one regular bump.
Le 20 oct. 2014 à 09:43, Magnus Danielson a écrit :
Bob,
Since the satellite orbit the earth with a period of 11 hours and 58 minutes, it is actually twice a day.
Cheers,
Magnus
On 10/20/2014 03:50 AM, Bob Camp wrote:
Hi
The GPS constellation repeats roughly once a day. It is not at all uncommon to have a “worst case” sattelite geometry for a given antenna location. If you have one, it will repeat once a day and show up as a bump in the timing out of your GPS module. If you track long term data, it will / may / can keep you from getting to the sort of stability you would expect in the 100,000 second range. It’s one of the main reasons that things like GPSD-Rb’s lock up with time constants much longer than 100K seconds. Yes having a Cs or something similar helps a lot looking for this sort of thing.
Bob
On Oct 19, 2014, at 9:26 PM, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you really need to check it over a month or two to watch for GPS “once a day” issues. "
Could I ask you what you meant by these "once a day issues"? Was this a general comment, or was it about something specific? As you know I'm working on a GPSDO and am doing a lot of testing, so if there's something else I should be looking for, please let me know.
Bob - AE6RV
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.
Bob,
Since the satellite orbit the earth with a period of 11 hours and 58
minutes, it is actually twice a day.
Cheers,
Magnus
I've been reminded of that before, but the fact remains that here the
interruptions when they happen are at 24-hour intervals, not 12-hour
intervals, and precess at a few minutes per day. Perhaps the low signal
coincides with greater background noise/interference at certain times of the
day? Although I've not plotted them, I do get the impression that
07:00-09:00 local is worse than other times....
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Poul-Henning wrote:
PLLs are really not that hard [context: we have been discussing
all-digital PLLs ("ADPLLs")]
Yes, I know -- I have designed more than a few. I have also reviewed
more than a dozen hobbyist designs and modeled some of them, and
found that few hobbyists seem to have mastered the art. Judging also
by on-list responses over the years, it does not appear that many
time nuts are interested in designing and building their own
ADPLLs. So, I conclude that disciplining a good OCXO with GPS and
getting the best stability the OCXO can deliver is not practicable
for most hobbyists.
The OP in this sub-thread indicated that he was considering using an
LTE-Lite to discipline a "really good" 10811, and it appeared that
his expectation was to end up with a GPSDO more or less as good as
his 10811. My point was simply to put realistic bounds on the expectation.
Said posted that a quick lash-up with an OCXO produced stability
about 10x better than with the on-board TCXO. That is a useful
improvement, but a good OCXO (certainly, a "really good" 10811) will
have stability about 3 orders of magnitude better than a TCXO
(1000x), so two decades of possible improvement were not realized.
Said's experiment was a proof-of-concept exercise and not a careful
optimization, so it is almost certain one could do better than 10x
with some further work. But I very much doubt that optimization can
gain the entire two decades of potential improvement (short of
designing a full ADPLL, in which case you don't need the LTE-Lite at
all -- all you need is a source of PPS), and I doubt it is possible
to gain even one whole decade.
So, I am inclined to think that there are better (and easier) ways to
discipline a 10811 to reach its ful potential, that's all.
Best regards,
Charles
Hi
Yes, but there’s this large object in the sky that modifies the ionosphere as it travels in a “about one a day” track. It appears to be coming up just about now, but I do need more coffee to be sure …
The combination of the constellation and the ionosphere are what I believe give you the once a day (rather than once per 12 hours) bump.
Bob
On Oct 20, 2014, at 3:43 AM, Magnus Danielson magnus@rubidium.dyndns.org wrote:
Bob,
Since the satellite orbit the earth with a period of 11 hours and 58 minutes, it is actually twice a day.
Cheers,
Magnus
On 10/20/2014 03:50 AM, Bob Camp wrote:
Hi
The GPS constellation repeats roughly once a day. It is not at all uncommon to have a “worst case” sattelite geometry for a given antenna location. If you have one, it will repeat once a day and show up as a bump in the timing out of your GPS module. If you track long term data, it will / may / can keep you from getting to the sort of stability you would expect in the 100,000 second range. It’s one of the main reasons that things like GPSD-Rb’s lock up with time constants much longer than 100K seconds. Yes having a Cs or something similar helps a lot looking for this sort of thing.
Bob
On Oct 19, 2014, at 9:26 PM, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you really need to check it over a month or two to watch for GPS “once a day” issues. "
Could I ask you what you meant by these "once a day issues"? Was this a general comment, or was it about something specific? As you know I'm working on a GPSDO and am doing a lot of testing, so if there's something else I should be looking for, please let me know.
Bob - AE6RV
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.
having kept watch over oscillators for about half a century now... My first
assumption would be that a once-a-day bump in time offset or tuning word,
is due to earthside changes especially temperature of the earthside
oscillator environment.
Tim N3QE
On Sunday, October 19, 2014, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you really
need to check it over a month or two to watch for GPS “once a day” issues. "
Could I ask you what you meant by these "once a day issues"? Was this a
general comment, or was it about something specific? As you know I'm
working on a GPSDO and am doing a lot of testing, so if there's something
else I should be looking for, please let me know.
Bob - AE6RV
time-nuts mailing list -- time-nuts@febo.com javascript:;
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob,
You mean the Sun, correct?
Regards,
John
On Oct 20, 2014 4:16 AM, "Bob Camp" kb8tq@n1k.org wrote:
Hi
Yes, but there’s this large object in the sky that modifies the ionosphere
as it travels in a “about one a day” track. It appears to be coming up just
about now, but I do need more coffee to be sure …
The combination of the constellation and the ionosphere are what I believe
give you the once a day (rather than once per 12 hours) bump.
Bob
On Oct 20, 2014, at 3:43 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Bob,
Since the satellite orbit the earth with a period of 11 hours and 58
minutes, it is actually twice a day.
Cheers,
Magnus
On 10/20/2014 03:50 AM, Bob Camp wrote:
Hi
The GPS constellation repeats roughly once a day. It is not at all
uncommon to have a “worst case” sattelite geometry for a given antenna
location. If you have one, it will repeat once a day and show up as a bump
in the timing out of your GPS module. If you track long term data, it will
/ may / can keep you from getting to the sort of stability you would expect
in the 100,000 second range. It’s one of the main reasons that things like
GPSD-Rb’s lock up with time constants much longer than 100K seconds. Yes
having a Cs or something similar helps a lot looking for this sort of thing.
Bob
On Oct 19, 2014, at 9:26 PM, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you
really need to check it over a month or two to watch for GPS “once a day”
issues. "
Could I ask you what you meant by these "once a day issues"? Was this
a general comment, or was it about something specific? As you know I'm
working on a GPSDO and am doing a lot of testing, so if there's something
else I should be looking for, please let me know.
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
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
Gee, now after a few cups of coffee … yes that does appear to be the sun.
————
The GPS system does it’s best to model the ionosphere and transmit that data. Unfortunately the model / model resolution is not as good as it could be. That lets the ionosphere creep into the solution more than it might with a perfect model. My guess (as in I have no data) is that constellations with a significant number of low(er) angle sats and a sun rise / sun set over one end of the constellation are the worst ones. That could easily be pure bunk.
Bob
On Oct 20, 2014, at 7:31 AM, John C. Westmoreland, P.E. john@westmorelandengineering.com wrote:
Bob,
You mean the Sun, correct?
Regards,
John
On Oct 20, 2014 4:16 AM, "Bob Camp" kb8tq@n1k.org wrote:
Hi
Yes, but there’s this large object in the sky that modifies the ionosphere
as it travels in a “about one a day” track. It appears to be coming up just
about now, but I do need more coffee to be sure …
The combination of the constellation and the ionosphere are what I believe
give you the once a day (rather than once per 12 hours) bump.
Bob
On Oct 20, 2014, at 3:43 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Bob,
Since the satellite orbit the earth with a period of 11 hours and 58
minutes, it is actually twice a day.
Cheers,
Magnus
On 10/20/2014 03:50 AM, Bob Camp wrote:
Hi
The GPS constellation repeats roughly once a day. It is not at all
uncommon to have a “worst case” sattelite geometry for a given antenna
location. If you have one, it will repeat once a day and show up as a bump
in the timing out of your GPS module. If you track long term data, it will
/ may / can keep you from getting to the sort of stability you would expect
in the 100,000 second range. It’s one of the main reasons that things like
GPSD-Rb’s lock up with time constants much longer than 100K seconds. Yes
having a Cs or something similar helps a lot looking for this sort of thing.
Bob
On Oct 19, 2014, at 9:26 PM, Bob Stewart bob@evoria.net wrote:
Hi Bob Camp,
In your response to Chris, you said: "Once you have it “right” you
really need to check it over a month or two to watch for GPS “once a day”
issues. "
Could I ask you what you meant by these "once a day issues"? Was this
a general comment, or was it about something specific? As you know I'm
working on a GPSDO and am doing a lot of testing, so if there's something
else I should be looking for, please let me know.
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
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.
Hi
We tend to focus on this or that enhanced feature in a piece of code. It’s fun to talk about. That’s not what keeps most designs from doing what they should. By focusing on this rather than the testing required, we set people up to fail. If you start off the project believing you mostly need fancy code when you mostly need long term testing instead, you hit a wall pretty fast. Setting up for one is not at all the same as setting up for the other.
Bob
On Oct 20, 2014, at 5:51 AM, Charles Steinmetz csteinmetz@yandex.com wrote:
Poul-Henning wrote:
PLLs are really not that hard [context: we have been discussing all-digital PLLs ("ADPLLs")]
Yes, I know -- I have designed more than a few. I have also reviewed more than a dozen hobbyist designs and modeled some of them, and found that few hobbyists seem to have mastered the art. Judging also by on-list responses over the years, it does not appear that many time nuts are interested in designing and building their own ADPLLs. So, I conclude that disciplining a good OCXO with GPS and getting the best stability the OCXO can deliver is not practicable for most hobbyists.
The OP in this sub-thread indicated that he was considering using an LTE-Lite to discipline a "really good" 10811, and it appeared that his expectation was to end up with a GPSDO more or less as good as his 10811. My point was simply to put realistic bounds on the expectation.
Said posted that a quick lash-up with an OCXO produced stability about 10x better than with the on-board TCXO. That is a useful improvement, but a good OCXO (certainly, a "really good" 10811) will have stability about 3 orders of magnitude better than a TCXO (1000x), so two decades of possible improvement were not realized.
Said's experiment was a proof-of-concept exercise and not a careful optimization, so it is almost certain one could do better than 10x with some further work. But I very much doubt that optimization can gain the entire two decades of potential improvement (short of designing a full ADPLL, in which case you don't need the LTE-Lite at all -- all you need is a source of PPS), and I doubt it is possible to gain even one whole decade.
So, I am inclined to think that there are better (and easier) ways to discipline a 10811 to reach its ful potential, that's all.
Best regards,
Charles
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.
On Mon, Oct 20, 2014 at 2:43 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Bob,
Since the satellite orbit the earth with a period of 11 hours and 58
minutes, it is actually twice a day.
But then your house has only completed half an orbit.
--
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
Bob wrote:
We tend to focus on this or that enhanced feature in a piece of
code. It's fun to talk about. That's not what keeps most designs
from doing what they should. By focusing on this rather than the
testing required, we set people up to fail. If you start off the
project believing you mostly need fancy code when you mostly need
long term testing instead, you hit a wall pretty fast. Setting up
for one is not at all the same as setting up for the other.
Not really sure what this has to do with my post to which you
replied?? I assure you, I do not find code to be a fun, or even very
interesting, topic of conversation, and I did not mention it at all
in that post. Really, the only thing I've said about code is that
I've found it takes more than 100 lines to do a proper ADPLL. When I
have some time, I have to sit down and study Poul-Henning's code to
see what I can learn from it about parsimony.
Best regards,
Charles
The GPS satellites are at an altitude that gives them an orbit of 12* hours. But during that time the earth has made half a rotation. Thus it takes -two- SV orbits and -one- earth rotation to get back to the same geometry. It is this 24* hour ground-track repeat time that is of interest in high-precision work.
That's why you often see GPS time-transfer data based on days*, rather than just a few thousand seconds or 12 hours. This is not likely to affect any of you working on home GPSDO projects. But it is a concern for the folks that do positioning at mm levels.
- Fun facts:
- Right, it's not actually 24 hours (solar day); instead it's closer to 23h 56m (sidereal day).
- However, if you look closely you find it's not precisely a sidereal day (86164 s) either; instead the repeat time is closer to 86155 s, due to gravitational effects (inclined orbits, non-spherical earth).
- If you look even closer you find each SV has its own repeat time; 86155 is merely the constellation average.
- Also the per-SV repeat times are not constant; they slowly drift by about 10 seconds a year. As the orbit decays and the repeat time gets out of spec, an orbital maneuver puts the SV back.
For a nice description of this effect, here's a short 2-page summary:
http://www.insidegnss.com/pdf/ig0806_gnss-solutions.pdf
For deeper technical details, start with these papers:
http://spot.colorado.edu/~kristine/gpsrep.pdf
http://www.isprs.org/proceedings/XXXVII/congress/4_pdf/162.pdf
http://web.gps.caltech.edu/classes/ge167/file/Ragheb2007.pdf
And finally, to see the effect on a GPSDO, I have some ADEV plots at:
http://leapsecond.com/pages/sidereal/
http://leapsecond.com/pages/sidereal/14years.htm
/tvb
PHK,
This is the best news I've heard in a long time; an overhaul of NTP!
One suggestion I'd like to make. You've seen the GPSDO simulator code I started:
http://leapsecond.com/tools/gpsim1.c
And you've seen the growing collection of GPS receiver and OCXO oscillator raw data:
http://leapsecond.com/pages/gpsdo-sim/
Instead of tweaking GPSDO algorithms or tuning parameters and having to wait days to see if it works or not, the idea was to "replay" pre-recorded 1PPS data and pre-recorded oscillator data into the PLL. This means one can test any new design change in a GPSDO in a matter of seconds instead of days.
So the question is -- could you do the same for NTP? On your own, or with world-wide contributions, you could collect long data sets (phase or frequency) of free-running PC clock oscillators, every shape and size and environment. And then also collect high-precision real-life NTP packet timings, warts and all (especially outlier examples).
Then instead of testing iterations of your new code on live NTP servers you merely apply previously collected packet data and previously collected clock data. With a little scripting you'd get performance plots within seconds instead of waiting hours or days. Moreover, the plots you generate would cover tens or hundreds of historical scenarios instead of just the few you could find in real time.
/tvb
On Mon, Oct 20, 2014 at 6:48 AM, Bob Camp kb8tq@n1k.org wrote:
Hi
We tend to focus on this or that enhanced feature in a piece of code. It’s
fun to talk about. That’s not what keeps most designs from doing what they
should. By focusing on this rather than the testing required, we set people
up to fail. If you start off the project believing you mostly need fancy
code when you mostly need long term testing instead, you hit a wall pretty
fast. Setting up for one is not at all the same as setting up for the other.
Sounds to me like the hardware and code are pretty straight-forward. The
difference comes from the terms and coefficients in the PLL loop filter and
those need to be optimized for each OCXO. There appear to be here a handful
of people who have a pretty good idea of what those coefficients should be
for various well-known OCXOs out there.
So why not do the GPSD hardware, software, and then provide the
coefficients that will get a handful of the more popular OCXOs available
out there to within a decade of optimum, certainly closer than what one
would be talking about by just bolting x-random OCXO onto an LTE-lite? I
suspect there would be a market in the time-nut world for such a critter.
--
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
In message 60CC0E0EEEE34928B664249EAC88407F@pc52, "Tom Van Baak" writes:
PHK,
This is the best news I've heard in a long time; an overhaul of NTP!
Indeed :-)
Instead of tweaking GPSDO algorithms or tuning parameters and
having to wait days to see if it works or not, the idea was to
"replay" pre-recorded 1PPS data and pre-recorded oscillator data
into the PLL. This means one can test any new design change in a
GPSDO in a matter of seconds instead of days.
So the question is -- could you do the same for NTP?
Well, first of all it's not days any longer. My proto-PLL wrangles
the clock phase in a matter of seconds and frequency in a few
minutes. Some of the (really) old NTP assumptions and metrics no
longer hold, revisiting them opens up a lot of parameter space.
Second, I'm already doing such simulations, and the ability to
do that is part of the design basis of what I'm doing.
I spent a month of my NTP-time trying to resurrect the "SIM" code in
ntpd, in order to get some kind of reproducible test-bench going and
in the end I concluded that 100k lines of code is not the way forward.
My current plan is to release a brand new client-only NTP daemon
with a decent PLL and high attack resistance before X-mas and then
work from there to one or two other programs: NTP-slave server (ie:
stratum 2..14) and a NTP-master/stratum 1 server.
All along the way, the intent is to try to pull PTP into this also,
since there is no material (ie: only protocol) difference between
a NTP and PTP timekeeping program, and the user shouldn't need to
notice the difference.
More as it happens.
The "mini-blog" entries I've started will happen every so often
when there is some progress to report or interesting data to
present.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message CAGVVbuGv_-cFDAA=T6hGE1ey32=oMxXcg-cxUb5sCusAo_T5eA@mail.gmail.com
, Brian Lloyd writes:
So why not do the GPSD hardware, software, [...]
It would be a really worthwhile project in general, and it could be
made very general with very little trouble.
I would find a cheap ARM board (Olimex ?) that can support ChibiOS:
http://www.chibios.org/dokuwiki/doku.php?id=news
and add a "cape" PCB with a high resolution DAC for EFC control
and two phase detectors, one for 100kHz-20MHz frequencies and one
for 1-100Hz frequencies. (The latter could have a TVB PIC divider
as an option on the reference input).
Maybe add a couple of isolated distribution amp outputs also ?
That would make for a really experimenter-friendly computer PLL
platform.
People who want to code can do so, people less ambitious could
tweak PLL params in the default firmware using the ChibiOS command
line interface...
Count me in...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Hi
PHK has a roughly 6 line code snippet that does a basic PLL. Add two more lines to check / clamp the integrator if you wish. That’s 8 lines. If you want a D term (to give it an FLL component) add 2 more lines. We’re up to 10 lines.
It’s just a control loop, not a full GPSDO. There’s not a lot to it.
The code and some magic hardware to run it on is not the key to all this. Setting up and spending the time testing and optimizing is.
Bob
On Oct 20, 2014, at 8:54 AM, Charles Steinmetz csteinmetz@yandex.com wrote:
Bob wrote:
We tend to focus on this or that enhanced feature in a piece of code. It's fun to talk about. That's not what keeps most designs from doing what they should. By focusing on this rather than the testing required, we set people up to fail. If you start off the project believing you mostly need fancy code when you mostly need long term testing instead, you hit a wall pretty fast. Setting up for one is not at all the same as setting up for the other.
Not really sure what this has to do with my post to which you replied?? I assure you, I do not find code to be a fun, or even very interesting, topic of conversation, and I did not mention it at all in that post. Really, the only thing I've said about code is that I've found it takes more than 100 lines to do a proper ADPLL. When I have some time, I have to sit down and study Poul-Henning's code to see what I can learn from it about parsimony.
Best regards,
Charles
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
The problem is that there are no “magic coefficients”. What you run depends very much on the exact OCXO you have, the environment you run it in, and the result you are after.
For instance, Bert is after frequency stability. Tom is after the right time. Each of them will have very different coefficients for the same oscillator.
My Morion OCXO has a floor of 2x10^-12, Bert has some that are 10X better than that (maybe). His coefficients and mine will be very different.
I had an antenna outdoors. It got many sat’s all the time. Now I have one indoors. It’s not getting lots of sats all the time. My old coefficients are not going to be my new coefficients.
No magic bullet, you have to do the work.
Bob
On Oct 20, 2014, at 1:20 PM, Brian Lloyd brian@lloyd.aero wrote:
On Mon, Oct 20, 2014 at 6:48 AM, Bob Camp kb8tq@n1k.org wrote:
Hi
We tend to focus on this or that enhanced feature in a piece of code. It’s
fun to talk about. That’s not what keeps most designs from doing what they
should. By focusing on this rather than the testing required, we set people
up to fail. If you start off the project believing you mostly need fancy
code when you mostly need long term testing instead, you hit a wall pretty
fast. Setting up for one is not at all the same as setting up for the other.
Sounds to me like the hardware and code are pretty straight-forward. The
difference comes from the terms and coefficients in the PLL loop filter and
those need to be optimized for each OCXO. There appear to be here a handful
of people who have a pretty good idea of what those coefficients should be
for various well-known OCXOs out there.
So why not do the GPSD hardware, software, and then provide the
coefficients that will get a handful of the more popular OCXOs available
out there to within a decade of optimum, certainly closer than what one
would be talking about by just bolting x-random OCXO onto an LTE-lite? I
suspect there would be a market in the time-nut world for such a critter.
--
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
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
The top of my list for “new NTP” would be to bring the 1588 hardware packet time tagging into the NTP code base. There’s a pretty good base of hardware out there that tags. It should help things on a loaded system.
Bob
On Oct 20, 2014, at 3:41 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message 60CC0E0EEEE34928B664249EAC88407F@pc52, "Tom Van Baak" writes:
PHK,
This is the best news I've heard in a long time; an overhaul of NTP!
Indeed :-)
Instead of tweaking GPSDO algorithms or tuning parameters and
having to wait days to see if it works or not, the idea was to
"replay" pre-recorded 1PPS data and pre-recorded oscillator data
into the PLL. This means one can test any new design change in a
GPSDO in a matter of seconds instead of days.
So the question is -- could you do the same for NTP?
Well, first of all it's not days any longer. My proto-PLL wrangles
the clock phase in a matter of seconds and frequency in a few
minutes. Some of the (really) old NTP assumptions and metrics no
longer hold, revisiting them opens up a lot of parameter space.
Second, I'm already doing such simulations, and the ability to
do that is part of the design basis of what I'm doing.
I spent a month of my NTP-time trying to resurrect the "SIM" code in
ntpd, in order to get some kind of reproducible test-bench going and
in the end I concluded that 100k lines of code is not the way forward.
My current plan is to release a brand new client-only NTP daemon
with a decent PLL and high attack resistance before X-mas and then
work from there to one or two other programs: NTP-slave server (ie:
stratum 2..14) and a NTP-master/stratum 1 server.
All along the way, the intent is to try to pull PTP into this also,
since there is no material (ie: only protocol) difference between
a NTP and PTP timekeeping program, and the user shouldn't need to
notice the difference.
More as it happens.
The "mini-blog" entries I've started will happen every so often
when there is some progress to report or interesting data to
present.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
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.
Bob wrote:
PHK has a roughly 6 line code snippet that does a basic PLL. Add two
more lines to check / clamp the integrator if you wish. That's 8
lines. If you want a D term (to give it an FLL component) add 2 more
lines. We're up to 10 lines.
It's just a control loop, not a full GPSDO. There's not a lot to it.
There's a bit more to it than that. For any loop slow (narrowband)
enough to be useful disciplining a good OCXO, I consider a dual- or
triple-rate loop filter to be essential. There is also always a fair
amount of error-trapping, and other overhead. These can add lines
fairly quickly.
I'm sure I have lots more to learn about writing efficient
code. (But note that there is a difference between coding one's
chosen algorithm more efficiently and choosing a different algorithm
that is not really what you want, just because it is more efficient.)
Best regards,
Charles
Hi
We are not talking about a system (like GPS) that has junk data coming in. In this case, the phase detector gives you a very good estimate of the delta between input and output in real time. The error trapping / shifting / multi this and that simply isn’t needed in this case. The solution is much easier than the GPSDO.
Let the OCXO warm up for a day or two. Yes it could be a week.
Adjust it with a pot to be close to frequency. (This is a basement project).
Fire up the loop.
Let it settle.
Come back in an hour or two and all is well. Confirm this by watching a (good) DVM on the EFC line.
It’s a low gain / long time constant loop. It will take a bit to settle. Yes, if code is what gets you excited, put in an array for the coefficients. Then add a timer to step the index. The timer will add about 4 lines. The step process will be on auto-pilot, but that makes it easy. You will settle faster, the net result after settling will be about the same.
If a year from now it’s unlocked, re-adjust the pot. Maybe check it with a DVM every so often and adjust it before it unlocks.
Not a lot to it. Simple code to write Easy board to build. Does just what it needs to do. Not a commercial system at all. It does not need to be. It’s going to do everything you need to do and be much easier to get running than something far more complex. The idea is to make the simplest system that will do the trick, not make it so hard that nobody ever tries. The target audience is a basement experimenter not NIST. It’s ok in this case to replace a bunch of code with an inquiring mind.
Bob
On Oct 25, 2014, at 11:23 AM, Charles Steinmetz csteinmetz@yandex.com wrote:
Bob wrote:
PHK has a roughly 6 line code snippet that does a basic PLL. Add two more lines to check / clamp the integrator if you wish. That's 8 lines. If you want a D term (to give it an FLL component) add 2 more lines. We're up to 10 lines.
It's just a control loop, not a full GPSDO. There's not a lot to it.
There's a bit more to it than that. For any loop slow (narrowband) enough to be useful disciplining a good OCXO, I consider a dual- or triple-rate loop filter to be essential. There is also always a fair amount of error-trapping, and other overhead. These can add lines fairly quickly.
I'm sure I have lots more to learn about writing efficient code. (But note that there is a difference between coding one's chosen algorithm more efficiently and choosing a different algorithm that is not really what you want, just because it is more efficient.)
Best regards,
Charles
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.
Mostly we don't even write the guts of those algorithms. For example,
you'd use a PID library. One line to create a PID controller object
then one line to call the PID for each phase measurement.
This goes double for, say, drawing a graph of the phase over time to
an LCD display, you'd use a graphic library for that. And for
communicating over USB to a computer. Who would want to take time to
learn the details of USB and LCD graphic controllers? Most code we
write is just "glue" that connects functions.
After a a few decades doing this I'd have to say that reinventing
well-tested wheels is the certain mark of a beginner/amateur. Either
they don't understand how to use these libraries or they don't know
they exist or think they can do it better. They spend 4X longer to
get something working and then it still does not cover all the "corner
cases and exceptions" those libraries might cover.
Ages ago CPU performance or space might mean you HAD to tightly code,
but now even a $1.79 8-bit AVR chip can hold well over the
equivalent of 1,000 lines of C++ code. OK there is the case a
manufactures who wants to be able to use the $1.69 chip and save 10
cents but most projects are not going to be built in high qualities.
Back on-tpic. Now that we have many low cast ($10 and under) uP
development boards building a GPSDO is simple. You don't even need a
custom PCB or many chips. And the simple $10 controller can have a
fancy LCD screen and connect to a computer and log stats and it can
all be up and running in a day or two.
If someone today wanted a harder challenge type project that would
push the state of that art out a little, why not build an "ensemble"
type device? One that accepts PPS timing from several sources,
figures out in realtime which of them to accept then runs several
local oscillators, perhaps an Rb and a couple OCXOs and compares their
outputs. So now you use both Rb and GPS, maybe a few of each to
track timing.
A while back I tried to prove to myself how easy it is now to build a
GPSDO that was good enough to drive typical lab equipment. Something
like a dozen lines of C code and $8 did it. It's no longer "cutting
edge to built these. Time to think about the next generation kind of
low-cost device. So maybe one could combine the best properties of
several different kinds of devices? Has this been done yet?
On Sat, Oct 25, 2014 at 8:23 AM, Charles Steinmetz
csteinmetz@yandex.com wrote:
Bob wrote:
PHK has a roughly 6 line code snippet that does a basic PLL. Add two more
lines to check / clamp the integrator if you wish. That's 8 lines. If you
want a D term (to give it an FLL component) add 2 more lines. We're up to 10
lines.
It's just a control loop, not a full GPSDO. There's not a lot to it.
There's a bit more to it than that. For any loop slow (narrowband) enough
to be useful disciplining a good OCXO, I consider a dual- or triple-rate
loop filter to be essential. There is also always a fair amount of
error-trapping, and other overhead. These can add lines fairly quickly.
I'm sure I have lots more to learn about writing efficient code. (But note
that there is a difference between coding one's chosen algorithm more
efficiently and choosing a different algorithm that is not really what you
want, just because it is more efficient.)
Best regards,
Charles
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