Re: [time-nuts] weird Raspberry PPS+GPS NTP server behaviour
On Mon, Mar 2, 2020 at 7:58 PM David J Taylor via time-nuts < time-nuts@lists.febo.com> wrote: > It's ~65°C on purpose. I'm using ntpheat ( > https://blog.ntpsec.org/2017/02/01/heat-it-up.html) to keep stable > temperature no matter what it does. It turns my raspberry into kind of OCXO > :) > Anyway, ntpheat runs there for months, so I guess it's not the culprit. > > Cheers, > Adam > > > Agreed, if it was running before then it's not the culprit this time. > > I didn't know about that program and I'd like to try it here. A neat > idea. > Is it available stand-alone - ready to run? I could compile it here given > the source, but not if it has dozens of dependencies on NTPsec, which I > don't use. > > Temperature is certainly the prime contributor to instability here (or > temperature variations produced by CPU load variations). > > Cheers, > David The source code is here: https://github.com/ntpsec/ntpsec/blob/master/contrib/ntpheat It imports ntp.util. But from my rudimentary knowledge of Python I see that it only uses it to get version number. So I think removing lines 24-29 and 51-53 should make it work without ntpsec. Cheers, Adam ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] weird Raspberry PPS+GPS NTP server behaviour
> I didn't know about that program and I'd like to try it here. A neat idea. > Is it available stand-alone - ready to run? I could compile it here given > the source, but not if it has dozens of dependencies on NTPsec, which I > don't use. It's stand alone python code. There is nothing ntpsec specific in it. It does use a Linux hook to read the CPU temperature. If you can read the temperature on your system, that should be simple to fix. There are 2 versions. ntpheat uses the CPU to generate heat. ntpheatusb toggles a relay so you can use a light bulb under the CPU. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Newbie question about GPS
On Montag, 2. März 2020 22:37:02 CET Björn wrote: > Hi Mattias, > > Then if you lock and control the 48MHz. You can also control the 1PPS edge > to the accuracy of the computed time... add 1s drift and lock uncertainty. > > Read the beginning of the Tbolt manual. The Tbolt lets it’s locked 10MHz > tick the whole receiver. Yep, you can do that. Any chance for getting that scheme to work with one of the stand-alone timing receivers? > > /Björn > > Sent from my iPhone > > > On 2 Mar 2020, at 22:14, Matthias Welwarsky > > wrote: > > > > On Montag, 2. März 2020 13:14:55 CET Anton Moehammad via time-nuts wrote: > >> 2. In the UCenter or almost any software > >> control for GPS module/receiver we can find data for next pps, why if the > >> software can calculate the PPS should be they do not use it to adjust the > >> PPS output so the PPS jitter is minimal ? > > > > There are no clocks in a GPS receiver with picoseconds resolution and > > everything the GPS outputs will be naturally restricted to its internal > > clock granularity. The time pulse signal from a Ublox module can > > therefore only be accurate to tens of nanoseconds (around 20ns assuming > > an internal 48MHz clock). However, the time solution calculated by the > > receiver will be much better. The quantization error reported in the TP5 > > message can simply be added to the timestamp of the received pulse to > > calculate its true arrival. > > > > BR, > > Matthias > > > >> ___ > >> time-nuts mailing list -- time-nuts@lists.febo.com > >> To unsubscribe, go to > >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and > >> follow > >> the instructions there. > > > > ___ > > time-nuts mailing list -- time-nuts@lists.febo.com > > To unsubscribe, go to > > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and > > follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow > the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Newbie question about GPS
Hi Mattias, Then if you lock and control the 48MHz. You can also control the 1PPS edge to the accuracy of the computed time... add 1s drift and lock uncertainty. Read the beginning of the Tbolt manual. The Tbolt lets it’s locked 10MHz tick the whole receiver. /Björn Sent from my iPhone > On 2 Mar 2020, at 22:14, Matthias Welwarsky wrote: > > On Montag, 2. März 2020 13:14:55 CET Anton Moehammad via time-nuts wrote: >> 2. In the UCenter or almost any software >> control for GPS module/receiver we can find data for next pps, why if the >> software can calculate the PPS should be they do not use it to adjust the >> PPS output so the PPS jitter is minimal ? > > There are no clocks in a GPS receiver with picoseconds resolution and > everything the GPS outputs will be naturally restricted to its internal clock > granularity. The time pulse signal from a Ublox module can therefore only be > accurate to tens of nanoseconds (around 20ns assuming an internal 48MHz > clock). However, the time solution calculated by the receiver will be much > better. The quantization error reported in the TP5 message can simply be > added > to the timestamp of the received pulse to calculate its true arrival. > > BR, > Matthias > >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow >> the instructions there. > > > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Time-Nutters-- Adding Rubidium to a Thunderbolt...?
On Montag, 2. März 2020 18:32:44 CET Skip Withrow wrote: [...] > The Thunderbolt DAC steps in 10uV steps IIRC. And it steps its DAC > voltage every second. With GPS signals jumping around you can still > (will) end up with poorer short term performance than if the Rb was > left to its own devices. Hint, let the Thunderbolt do its thing with > the Rb, but use Lady Heather and disable disciplining when making > measurements/comparisons. The LPRO has a pulling range of just 4ppm at the external C-Field input (0-5V swing). 10µV steps over 6V should be, like 19 bits or so? That should give at least 7e-15 resolution for the DAC. With a reasonably stable PPS from a timing receiver, just looking at the DAC movements, it should not be a problem to have a MDEV of 1e-14'ish for tau=1s. The LPRO itself probably has a MDEV of somewhere between 1e-11 to 1e-10 at tau=1s, so the GPSDO is not going to cause a lot of disturbance. Some, yes. The undisturbed Rb will always be better short-term than the disciplined one. But not an awful lot. BR, Matthias > > Regards, > Skip Withrow > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow > the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Newbie question about GPS
On Montag, 2. März 2020 13:14:55 CET Anton Moehammad via time-nuts wrote: >2. In the UCenter or almost any software > control for GPS module/receiver we can find data for next pps, why if the > software can calculate the PPS should be they do not use it to adjust the > PPS output so the PPS jitter is minimal ? There are no clocks in a GPS receiver with picoseconds resolution and everything the GPS outputs will be naturally restricted to its internal clock granularity. The time pulse signal from a Ublox module can therefore only be accurate to tens of nanoseconds (around 20ns assuming an internal 48MHz clock). However, the time solution calculated by the receiver will be much better. The quantization error reported in the TP5 message can simply be added to the timestamp of the received pulse to calculate its true arrival. BR, Matthias > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow > the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] weird Raspberry PPS+GPS NTP server behaviour
It's ~65°C on purpose. I'm using ntpheat ( https://blog.ntpsec.org/2017/02/01/heat-it-up.html) to keep stable temperature no matter what it does. It turns my raspberry into kind of OCXO :) Anyway, ntpheat runs there for months, so I guess it's not the culprit. Cheers, Adam Agreed, if it was running before then it's not the culprit this time. I didn't know about that program and I'd like to try it here. A neat idea. Is it available stand-alone - ready to run? I could compile it here given the source, but not if it has dozens of dependencies on NTPsec, which I don't use. Temperature is certainly the prime contributor to instability here (or temperature variations produced by CPU load variations). Cheers, David -- SatSignal Software - Quality software for you Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] weird Raspberry PPS+GPS NTP server behaviour
On Mon, Mar 2, 2020 at 5:23 PM David J Taylor via time-nuts < time-nuts@lists.febo.com> wrote: > Hi! > > For several weeks I'm seeing strange behavior of my Raspberry Pi based NTP > server with Uputronics GPS PPS expansion board (Ublox MAX-M8Q chip). > Several weeks ago the mean daily jitter was below 300 ns, offset didn't > exceed ±1 µs, provided no restart or configuration change was made. Now the > offset often wanders even below 5 µs, steady change, and then comes back. > You can see it at the screenshot from my Grafana server (attached). As you > can see, the number of satellites visible and TDOP value should not be the > cause of it. > > My current ntp.conf is as follows (I use ntpsec and gpsd): > > driftfile /var/lib/ntp/ntp.drift > leapfile /var/lib/ntp/leap-seconds.list > > statsdir /var/log/ntpstats/ > statistics loopstats peerstats > filegen loopstats file loopstats type day enable > filegen peerstats file peerstats type day enable > > restrict default limited kod nomodify nopeer noquery > restrict source nomodify noquery > restrict 127.0.0.1 > restrict 192.168.0.0 mask 255.255.0.0 > > tos mindist 0.002 > > refclock shm unit 1 minpoll 4 maxpoll 4 flag4 1 prefer refid PPS > refclock shm unit 0 minpoll 4 maxpoll 4 time1 0.057984 refid GPS > > #server nts.time.nl nts > #server nts.ntp.se:4443 nts > > server tempus1.gum.gov.pl prefer > server tempus2.gum.gov.pl > server ntp.task.gda.pl > server ntp.nask.pl > > server MY_GPSDO iburst > > Before that I thought it was because I used NTP pool, as some time ago > similar behavior was mentioned here on the list, but, as you can see, I do > not use it anymore and the same strange behavior remained. > > Any idea what could be the cause of this? Thanks in advance. > > Adam > > > What are you doing to that poor RPi to drive its CPU up to 66 C! Rather > hot! > > That's the first thing I would investigate if the CPU load is really so > low > (9%). Comparing, my oldest RPi server is a lowly RasPi 1B, and it runs at > 2% CPU, ~43 C CPU (averaged over a day). It lives in an unheated cupboard > on an outside wall. > > Cheers, > David > It's ~65°C on purpose. I'm using ntpheat ( https://blog.ntpsec.org/2017/02/01/heat-it-up.html) to keep stable temperature no matter what it does. It turns my raspberry into kind of OCXO :) Anyway, ntpheat runs there for months, so I guess it's not the culprit. Cheers, Adam ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Time-Nutters-- Adding Rubidium to a Thunderbolt...?
Hi So backing up a bit: What are you trying to do? GPS signals by their nature are noisy short term. They get better the longer you stretch out the observation time. If you are running a single band / uncorrected GPS ( = most GPSDO’s and most GPS modules) you will hit a bunch of issues related to day / night sorts of things. Rb’s have pretty good stability and it also improves as you stretch out the observation time. If you have a stable environment, they may keep getting better for quite a ways. How much better for how long depends very much on the exact unit you have and how you treat it. If the objective is simply to get the Rb close to frequency and then shut down the GPS stuff, that is a pretty simple thing to do. If you want to run GPS + Rb and not significantly degrade a fairly good Rb, things get a bit complicated. Bob > On Mar 2, 2020, at 12:32 PM, Skip Withrow wrote: > > Hello Mike, > Replacing the OCXO in a Thunderbolt (or one of the many telecom > cousins) is very easy to do. Just yank out the OCXO, hook the > Thunderbolt EFC to the Rubidium EFC (the Thunderbolt range is 0-6V), > and hook the Rb 10MHz where the OCXO 10MHz went. > > That is the easy part. Understanding how to tune the Thunderbolt, and > what kind of performance to expect is a little harder. Rubidiums need > a much longer time constant and the Thunderbolt only goes to 1000s. > This can be circumvented by doing some math and 'fudging' the > Thunderbolt gain and damping numbers. There was a discussion on how > to do this in time-nuts many years ago. Also, a word of warning, some > of the telecom cousins do strange things when this technique is used > (and some don't). > > The other thing to consider is the Thunderbolt DAC and Rb resolution. > A PRS-10 takes the EFC and runs it into an A/D such that the minimum > step in frequency is about 1x10E-12. You will never get an ADEV below > this value. Many of the other rubidiums (X72, SA22c, FE5680A, > FE5650A) use DDS in their loops and have similar resolutions. The > LPRO is one unit that is around has an analog EFC. > > The Thunderbolt DAC steps in 10uV steps IIRC. And it steps its DAC > voltage every second. With GPS signals jumping around you can still > (will) end up with poorer short term performance than if the Rb was > left to its own devices. Hint, let the Thunderbolt do its thing with > the Rb, but use Lady Heather and disable disciplining when making > measurements/comparisons. > > Regards, > Skip Withrow > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Time-Nutters-- Adding Rubidium to a Thunderbolt...?
Hello Mike, Replacing the OCXO in a Thunderbolt (or one of the many telecom cousins) is very easy to do. Just yank out the OCXO, hook the Thunderbolt EFC to the Rubidium EFC (the Thunderbolt range is 0-6V), and hook the Rb 10MHz where the OCXO 10MHz went. That is the easy part. Understanding how to tune the Thunderbolt, and what kind of performance to expect is a little harder. Rubidiums need a much longer time constant and the Thunderbolt only goes to 1000s. This can be circumvented by doing some math and 'fudging' the Thunderbolt gain and damping numbers. There was a discussion on how to do this in time-nuts many years ago. Also, a word of warning, some of the telecom cousins do strange things when this technique is used (and some don't). The other thing to consider is the Thunderbolt DAC and Rb resolution. A PRS-10 takes the EFC and runs it into an A/D such that the minimum step in frequency is about 1x10E-12. You will never get an ADEV below this value. Many of the other rubidiums (X72, SA22c, FE5680A, FE5650A) use DDS in their loops and have similar resolutions. The LPRO is one unit that is around has an analog EFC. The Thunderbolt DAC steps in 10uV steps IIRC. And it steps its DAC voltage every second. With GPS signals jumping around you can still (will) end up with poorer short term performance than if the Rb was left to its own devices. Hint, let the Thunderbolt do its thing with the Rb, but use Lady Heather and disable disciplining when making measurements/comparisons. Regards, Skip Withrow ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] weird Raspberry PPS+GPS NTP server behaviour
Hi! For several weeks I'm seeing strange behavior of my Raspberry Pi based NTP server with Uputronics GPS PPS expansion board (Ublox MAX-M8Q chip). Several weeks ago the mean daily jitter was below 300 ns, offset didn't exceed ±1 µs, provided no restart or configuration change was made. Now the offset often wanders even below 5 µs, steady change, and then comes back. You can see it at the screenshot from my Grafana server (attached). As you can see, the number of satellites visible and TDOP value should not be the cause of it. My current ntp.conf is as follows (I use ntpsec and gpsd): driftfile /var/lib/ntp/ntp.drift leapfile /var/lib/ntp/leap-seconds.list statsdir /var/log/ntpstats/ statistics loopstats peerstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable restrict default limited kod nomodify nopeer noquery restrict source nomodify noquery restrict 127.0.0.1 restrict 192.168.0.0 mask 255.255.0.0 tos mindist 0.002 refclock shm unit 1 minpoll 4 maxpoll 4 flag4 1 prefer refid PPS refclock shm unit 0 minpoll 4 maxpoll 4 time1 0.057984 refid GPS #server nts.time.nl nts #server nts.ntp.se:4443 nts server tempus1.gum.gov.pl prefer server tempus2.gum.gov.pl server ntp.task.gda.pl server ntp.nask.pl server MY_GPSDO iburst Before that I thought it was because I used NTP pool, as some time ago similar behavior was mentioned here on the list, but, as you can see, I do not use it anymore and the same strange behavior remained. Any idea what could be the cause of this? Thanks in advance. Adam What are you doing to that poor RPi to drive its CPU up to 66 C! Rather hot! That's the first thing I would investigate if the CPU load is really so low (9%). Comparing, my oldest RPi server is a lowly RasPi 1B, and it runs at 2% CPU, ~43 C CPU (averaged over a day). It lives in an unheated cupboard on an outside wall. Cheers, David -- SatSignal Software - Quality software for you Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Time-Nutters-- Adding Rubidium to a Thunderbolt...?
You should log the PRS10's PPS timestamps with a computer, I'm sure you will be surprised by what you see. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Time-Nutters-- Adding Rubidium to a Thunderbolt...?
Hi I'm doing it. I've taken PRS-10 which has PPS IN feature and fed it with PPS from Trimble. It is still work in progress but the mechanism works. Time constant of the PRS-10 is set to very long time (8 hours?) from factory when signal is present on PPS-10. Problem I'm encountering is that I get precise time by the nature of Trimble but Adev worsens. This is because PPS of T-bolt has more jitter than stability of PRS-10 itself. While PRS-10 is still providing stable signal, T-bolt pushes and pulls. Also, lock is achieved in few minutes but to truly synchronize, it takes weeks. It contradicts what I just said but push and pull is more like a nudge, so initial synchronization takes forever. PPS IN pin on PRS-10 is dual purpose. You must make sure a jumper is set correctly, or it won't work. My finding is that PPS from GPSDO works much better than just GPS, and this is because raw PPS from JUST GPS does not enjoy pre-processing. GPSDO's PPS is regenerated by steered signal, and not direct from satellites. It is an interesting experiment. Getting it to work was easy. Getting it to work well, I'm still working on it. --- (Mr.) Taka Kamiya KB4EMF / ex JF2DKG On Monday, March 2, 2020, 1:21:16 AM EST, mp...@clanbaker.org wrote: Hello, Time-Nutters-- Is it possible to add/combine/mate a rubidium osc to a Trimble Thunderbolt GPSDO? Have there been any examples of this that I could use as a guide? Thanks for any info/feedback on this!! Mike Baker Gainesville/Micanopy Florida USA *** ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Newbie question about GPS
Hi > On Mar 2, 2020, at 7:14 AM, Anton Moehammad via time-nuts > wrote: > > Hi All,I hope some one can help me to find the answer.1. Let say some one can > extract the L1 carrier frequency 15xx MHz and convert it down to let say 1MHz > and put it to phase comparator and made the PLL to generated the LO to > convert and extract the carrier. Is this possible ? Have some has do it ? Can > share any thoughts ? The carrier is significantly doppler shifted due to the way the satellites orbit the earth. Without correcting for that, the carrier makes a poor reference. This is only the first of *many* corrections applied….. > 2. In the UCenter or almost any software control for GPS module/receiver we > can find data for next pps, why if the software can calculate the PPS should > be they do not use it to adjust the PPS output so the PPS jitter is minimal ? The correction information can get the PPS to error levels dimensioned in picoseconds. Doing that with some sort of external corrector is complex and expensive (if it can be done at all). The way they do it is quite adequate for a GPSDO application. It costs them next to nothing to do. > 3. Why if we use real time RTK for better accuracy in term of position the > PPS is not changed ? ( At least in my setup) ?Are the RTK software only > process data and show the result in the screen without change anything in > module/receiver ?Any software can do a real change to receiver for better PPS > out based from any corrections available (ionosphere, Tidal etc) ? It depends on which RTK streams you are using. Are you bringing in a clock correction stream? In any case, the change in the PPS is going to be very small. You would need a very good reference to compare to to see it happen. Bob > Thank YouAnton > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Newbie question about GPS
Hi All,I hope some one can help me to find the answer.1. Let say some one can extract the L1 carrier frequency 15xx MHz and convert it down to let say 1MHz and put it to phase comparator and made the PLL to generated the LO to convert and extract the carrier. Is this possible ? Have some has do it ? Can share any thoughts ?2. In the UCenter or almost any software control for GPS module/receiver we can find data for next pps, why if the software can calculate the PPS should be they do not use it to adjust the PPS output so the PPS jitter is minimal ?3. Why if we use real time RTK for better accuracy in term of position the PPS is not changed ? ( At least in my setup) ?Are the RTK software only process data and show the result in the screen without change anything in module/receiver ?Any software can do a real change to receiver for better PPS out based from any corrections available (ionosphere, Tidal etc) ? Thank YouAnton ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Newbie Question about GPS
Hi All,I hope some one can help me to find the answer.1. Let say some one can extract the L1 carrier frequency 15xx MHz and convert it down to let say 1MHz and put it to phase comparator and made the PLL to generated the LO to convert and extract the carrier. Is this possible ? Have some has do it ? Can share any thoughts ?2. In the UCenter or almost any software control for GPS module/receiver we can find data for next pps, why if the software can calculate the PPS should be they do not use it to adjust the PPS output so the PPS jitter is minimal ?3. Why if we use real time RTK for better accuracy in term of position the PPS is not changed ? ( At least in my setup) ?Are the RTK software only process data and show the result in the screen without change anything in module/receiver ?Any software can do a real change to receiver for better PPS out based from any corrections available ? Thank YouAnton ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Time-Nutters-- Adding Rubidium to a Thunderbolt...?
In message , Dana Whitlow writes: >Probably the easiest solution would be to feed 1 PPS from the T'bolt into a >full-featured >PRS-10 Rb, then fiddle with the loop parameters in the PRS-10 to best suit >your needs. Been there, tried that, not a good idea. The PPS input of the PRS-10 is OK for "coarse" PPS signals like those you get out of a GPS, because the sawtooth noise dithers over the unlinearity and "missing codes" of the PRS-10 timestamping circuit. When you feed a PRS-10 a "perfect" PPS signal, you get really erratic behaviour. Only way to slave a PRS-10 from a "good" source, is to do phase-comparison on the 10MHz signal, and after suitable filtering and integration, use that to set the PRS-10 frequency via the serial port. That, on the other hand can give amazing results because of the relatively good X-tals they put in the PRS-10. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Time-Nutters-- Adding Rubidium to a Thunderbolt...?
It is very simple to do. Warren did it I think seven years ago and we have done it repeatedly in the last 4 years. Take the EFC that goes to the OCXO to the C field control and Tbolt can determine and automatically adjust to frequency per Volt. You can also adjust the time constant. Tbolt is ideal for that application. We do not use it because in all cases Tbolt uses 0.1 sec 1E-10 frequency jumps to adjust for time. At the kind of work we do it causes some problems. Bert Kehren In a message dated 3/2/2020 1:21:22 AM Eastern Standard Time, mp...@clanbaker.org writes: Hello, Time-Nutters-- Is it possible to add/combine/mate a rubidium osc to a TrimbleThunderbolt GPSDO? Have there been any examples of this that I could use as a guide? Thanks for any info/feedback on this!! Mike BakerGainesville/MicanopyFlorida USA*** ___time-nuts mailing list -- time-n...@lists.febo.comTo unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.comand follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
