[time-nuts] I've been thinking about a GPS receiver experiment

[Mark Sims]

Well, the X72 uses a DDS instead of a DAC... not much different except you have 
no DAC to freq math to worry about.  The DDS res is  60 MHz / 8192

-

> I've been thinking about a GPS receiver experiment
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob Martin]

Sorry, my mistake, change that to the former!  I have used DACs that 
were monotonic with decent results but prefer analog loops when the 
time constants are short enough.


Bob M

On 10/25/2017 5:46 PM, Bob Martin wrote:
   The holdover state is a DAC set to the last value of the analog 
control voltage that adjusts the oscillator frequency. Some designs

use an analog control loop and switch the DAC into the control loop.
Others use the DAC to set the control voltage at all times. This can 
result in a steps in the control voltage (output frequency).

I've used both methods and prefer the latter.

Bob M

On 10/25/2017 5:30 PM, Mark Sims wrote:

  No, you set up an oscillator so that is why you have that problem.


I hooked the two rubidiums together just to see what would 
happen.   It pretty much did what I expected... chaos...   the 
time-nut equivalent of a naughty schoolboy putting a microphone up 
to the speaker of the public address system.  I't's a tough job, 
but somebody gotta do it  ;-)




  No, not really. The rubidium would be the real hold-over clock.


Symmetricom calls the disciplining state where it can't lock to 
the 1PPS signal the "holdover" state.  It's sort of like a GPSDO 
holdover state.  Their discipline firmware does let you set the 
time constant and damping values.  I tried a little playing around 
with them, but never found any settings that worked consistently 
well with the LEA-5T.

___
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.

Re: [time-nuts] Thunderbolt - Lady Heather altitude does report abt 240m too high

[Dana Whitlow]

Remember that GPS normally displays altitude with respect to the WGS84 datum
geoid, not with respect to MSL.  There can easily be a hundred feet or so of
difference.

Dana


On Wed, Oct 25, 2017 at 9:18 PM, Arnold Tibus  wrote:

> Hello fellow time nuts,
>
> after the thunderbolt roll over problem I run the survey control in Lady
> Heather (48h).
> Since then I am getting always a wrong elevation number for my qth.
> Does anybody know the reason for that behavior?
> Is there a solution to get again the correct value?
>
> Kind regards
>
> Arnold, DK2WT
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/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] Thunderbolt - Lady Heather altitude does report abt 240m too high

[Arnold Tibus]

Hello fellow time nuts,

after the thunderbolt roll over problem I run the survey control in Lady 
Heather (48h).

Since then I am getting always a wrong elevation number for my qth.
Does anybody know the reason for that behavior?
Is there a solution to get again the correct value?

Kind regards

Arnold, DK2WT

___
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.

Re: [time-nuts] Designing an embedded precision GPS time server

[Gary E. Miller]

Yo Nick!

On Wed, 25 Oct 2017 17:53:46 -0700
Nick Sayer via time-nuts  wrote:

> This may be a fool’s errand, certainly, but looking at it from here,
> I would think that such a design might offer accuracy in the
> microsecond range,

I'm looking at 6 Raspberry Pi's right now, each with a different GPS
model.  Running NTPec and kernel PPS.  Adjacent jitter is from 10 to 35
micro seconds over 100 Base-T.

Local PPS jitter, is from 250 ns to up to 3,000 ns.

The biggest issue is the 186 ns granularity in the kernel system
clock.  Then interrupt latency and the usual Linux stuff.

> Anybody have any ideas or suggestions along these lines?

This may be not time-nutty enough for here.  Feel free to contact
me off list.

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

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpp8WRtok0ml.pgp
Description: OpenPGP digital signature
___
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] Designing an embedded precision GPS time server

[Nick Sayer via time-nuts]

I’ve just completed a project (off topic) with the ATSAMS70 chip and learned a 
lot in a relatively short time, and I really like the result.

I am considering a new project based on its cousin, the ATSAME70. The E70 has 
an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
(USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
Start (the software development framework I’ve been using) purports to have a 
ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).

Where I am going with this is I am considering designing a precision embedded 
NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up to 
a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea behind 
making it an embedded system would be to try and make it as accurate as it 
reasonably can be with the hope that (at least on the local segment) it would 
wind up being more accurate than a Pi Zero doing the same thing. At the very 
least, you’d expect such a thing to be a whole lot less hassle to set up, given 
decent firmware.

This may be a fool’s errand, certainly, but looking at it from here, I would 
think that such a design might offer accuracy in the microsecond range, but 
that’s just a tremendously uninformed guess at this point (and what does that 
accuracy mean to a peer that might itself be incapable of better than 2 orders 
of magnitude coarser?).

Anybody have any ideas or suggestions along these lines?
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob Martin]

  The holdover state is a DAC set to the last value of the analog 
control voltage that adjusts the oscillator frequency. Some designs

use an analog control loop and switch the DAC into the control loop.
Others use the DAC to set the control voltage at all times. This can 
result in a steps in the control voltage (output frequency).

I've used both methods and prefer the latter.

Bob M

On 10/25/2017 5:30 PM, Mark Sims wrote:

  No, you set up an oscillator so that is why you have that problem.


I hooked the two rubidiums together just to see what would happen.   It pretty 
much did what I expected... chaos...   the time-nut equivalent of a naughty 
schoolboy putting a microphone up to the speaker of the public address system.  
I't's a tough job, but somebody gotta do it  ;-)



  No, not really. The rubidium would be the real hold-over clock.


Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the 
"holdover" state.  It's sort of like a GPSDO holdover state.  Their discipline 
firmware does let you set the time constant and damping values.  I tried a little playing 
around with them, but never found any settings that worked consistently well with the 
LEA-5T.
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Dana Whitlow]

What "naughty schoolboy"?  How else is one supposed to learn feedback
theory?

Dana

On Wed, Oct 25, 2017 at 6:30 PM, Mark Sims  wrote:

> >  No, you set up an oscillator so that is why you have that problem.
>
> I hooked the two rubidiums together just to see what would happen.   It
> pretty much did what I expected... chaos...   the time-nut equivalent of a
> naughty schoolboy putting a microphone up to the speaker of the public
> address system.  I't's a tough job, but somebody gotta do it  ;-)
>
>
> >  No, not really. The rubidium would be the real hold-over clock.
>
> Symmetricom calls the disciplining state where it can't lock to the 1PPS
> signal the "holdover" state.  It's sort of like a GPSDO holdover state.
> Their discipline firmware does let you set the time constant and damping
> values.  I tried a little playing around with them, but never found any
> settings that worked consistently well with the LEA-5T.
> ___
> 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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

Hi naugthy schoolboy Mark,

On 10/26/2017 01:30 AM, Mark Sims wrote:

  No, you set up an oscillator so that is why you have that problem.


I hooked the two rubidiums together just to see what would happen.   It pretty 
much did what I expected... chaos...   the time-nut equivalent of a naughty 
schoolboy putting a microphone up to the speaker of the public address system.  
I't's a tough job, but somebody gotta do it  ;-)


In the music world, some really like caotic oscillators.
You just built a very expensive one. :)0


  No, not really. The rubidium would be the real hold-over clock.


Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the 
"holdover" state.  It's sort of like a GPSDO holdover state.  Their discipline 
firmware does let you set the time constant and damping values.  I tried a little playing 
around with them, but never found any settings that worked consistently well with the 
LEA-5T.


Well, holdover is the behavior, but a typical design can have several 
states which is deemed as hold-over. Everything else than tracking is 
holdover.


Cheers,
Magnus
___
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] I've been thinking about a GPS receiver experiment

[Mark Sims]

>  No, you set up an oscillator so that is why you have that problem.

I hooked the two rubidiums together just to see what would happen.   It pretty 
much did what I expected... chaos...   the time-nut equivalent of a naughty 
schoolboy putting a microphone up to the speaker of the public address system.  
I't's a tough job, but somebody gotta do it  ;-)


>  No, not really. The rubidium would be the real hold-over clock.

Symmetricom calls the disciplining state where it can't lock to the 1PPS signal 
the "holdover" state.  It's sort of like a GPSDO holdover state.  Their 
discipline firmware does let you set the time constant and damping values.  I 
tried a little playing around with them, but never found any settings that 
worked consistently well with the LEA-5T.   
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

Hi Bob,

Well, the PRC-10 actually have additional provisions to help it do well 
on GPS as signal, and is used by severals to do exactly that.


Cheers,
Magnus

On 10/25/2017 09:26 PM, Bob kb8tq wrote:

Hi

Everybody I have ever talked to about the internal disciplining on Rb’s comes
up with “it’s not for a GPSDO” somewhere in the first minute of the 
conversation.
The objective seems to be to tune the unit to a perfect source to speed up the
calibration process. The idea never appears to include noise on the reference
signal or odd perturbations in the reference.

Bob


On Oct 24, 2017, at 6:42 PM, Mark Sims  wrote:

I did a quick silly experiment where I took a PRS-10 disciplined by an X72 
which was disciplined by the PRS-10.  The result seemed to have created a 
rupture in the space-time continuum.  Nobody was happy...  they didn't seem to 
agree on who was in charge.I need to try it again now that I have my X72 
interface boards back from China and can properly connect to the X72.

BTW, the firmware based disciplining on the X72 seems to be rather crappy.  It 
has lots of trouble locking to less than perfect 1PPS inputs.   For instance it 
goes into holdover mode over half the time when driven by a Ublox LEA-5T (which 
seems to have like +/- 60 ns jitter on the 1PPS.   It does lock fine with a 
Tbolt...  but needing a GPSDO to discipline a rubidium sort of defeats the 
purpose of disciplining a rubidium.

Lady Heather now has an X72/SA22 disciplining routine built in that works 
fairly well using the LEA-5T.  Adevs are in the mid E-13 range at 10,000 
seconds and the 1PPS output is in the +/- 50 ns range.
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

Hei Ole Petter,

You don't want to look at the PPS in that case.
You want to look at how the receivers clock solution pans out.
Since the receivers clock is set but then ticks to the speed of the 
rubidium, you now got a high resolution frequency and phase comparison.


Depending on the clock-mode, you might or might not experience 
clock-reset events. Typically 1 ms shifts of clock time. One needs to 
handle that in case you are not able to drive the clock quick enough 
towards on average be where the GPS/UTC average solution drives it to.


Anyway, so there is a different clock message, just don't recall it from 
the top of my head. I just recall that the Novatels is fairly generous 
with this data


Cheers,
Magnus

On 10/25/2017 06:14 AM, Ole Petter Ronningen wrote:
I did log the #TIME message for several weeks on an OEMV-3 a while back. 
The results were a bit suspicious, so I checked with Novatel support - 
turns out the PPS on the OEMV (and I presume that also holds for OEM4) 
is derived from L1 only - and the jitter is nothing to brag about. So 
for disciplining with PPS, something like a UBlox would be better as far 
as I can tell.


The other option is to log the #RANGE-message from the Novatel, convert 
to RINEX and solve with PPP, and use the output of that to adjust the 
rubidium. The added benefit is that you'll have an excellent log of what 
your reference is doing if you get odd results in some measurements.


Ole

On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson 
mailto:mag...@rubidium.dyndns.org>> wrote:


Skip,

I would rather use the rich Novatel reports and read out the time
error and use that as your phase detector, then the normal PI-loop
stuff with an optional low-pass to add and then use that to steer
the rubidium.

It's one of those, when I get time, projects.

Cheers,
Magnus


On 10/25/2017 12:17 AM, Skip Withrow wrote:

Hello time-nuts,

I've been thinking about a GPS receiver experiment and just
wondering
if there are any opinions or prior experience that might save me
a lot
of time.

What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS
even has
settings for OCXO/rubidium/cesium dynamics.

Then, (and here is the unknown part) what if the GPS receiver
1pps is
used to discipline the rubidium?  This basically forms a feedback
loop, so could either hurt or help - depending.  Supposedly the
better
oscillator would give a better GPS solution.  And the better
solution
(1pps) should provide a better oscillator frequency.

We know that GPS receivers using asynchronous clocks have 1pps
errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the
oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?

Comments appreciated.

Regards,
Skip Withrow
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

Hi Mark,

On 10/25/2017 12:42 AM, Mark Sims wrote:

I did a quick silly experiment where I took a PRS-10 disciplined by an X72 
which was disciplined by the PRS-10.  The result seemed to have created a 
rupture in the space-time continuum.  Nobody was happy...  they didn't seem to 
agree on who was in charge.I need to try it again now that I have my X72 
interface boards back from China and can properly connect to the X72.


No, you set up an oscillator so that is why you have that problem.

Each rubidium has an integrator and each PI loop adds another, and now 
that you wire the feedback over them you have an unbalanced 4 pole 
system. Already a third degree system is somewhat of a challenge to keep 
stable, so fourth degree... sure, it can be done, but not that way.


I have been looking at mutual synchronization and there is some 
classical articles on it and recently some work have been done too.


A good mutual synchronization means that you find your aggregate clock 
to be at the middle frequency and phase of the two separate clocks. This 
also means that you want to drive your clocks towards each other, so one 
is to raise frequency and the other lower frequenncy. For un-equal clock 
EFCs, you need to scale the driving force accordingly. For more fancy 
setups of weighted clocks, you need to apply correct weights so that the 
better clock moves less than the clock being worse.


Another factor of the control is that delay needs to be compensated for, 
and this have already been analyzed in the classical mutual clock setup, 
but also exists in modern setups, and I happen to touch on that subject 
in an article, since the delay margin, which is just a different version 
of phase margin, needs to be adapted in accordance with the control loop 
bandwidth. With the right key-words you can find out more. I did that 
work on automatic power-grid stabilization and it was kind of 
interesting to forge an analysis out of three independent 
research-fields, so I found myself instructing a PhD student how she 
would drive here simulations into self-oscillation... and they sure did 
and we learned stuff. Ah well.


Anyway, mutual synchronization require some thought, but ends up not 
being all that different in the end.



BTW, the firmware based disciplining on the X72 seems to be rather crappy.  It 
has lots of trouble locking to less than perfect 1PPS inputs.   For instance it 
goes into holdover mode over half the time when driven by a Ublox LEA-5T (which 
seems to have like +/- 60 ns jitter on the 1PPS.   It does lock fine with a 
Tbolt...  but needing a GPSDO to discipline a rubidium sort of defeats the 
purpose of disciplining a rubidium.


No, not really. The rubidium would be the real hold-over clock.


Lady Heather now has an X72/SA22 disciplining routine built in that works 
fairly well using the LEA-5T.  Adevs are in the mid E-13 range at 10,000 
seconds and the 1PPS output is in the +/- 50 ns range.


Cool.

Cheers,
Magnusu
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

Hi

Everybody I have ever talked to about the internal disciplining on Rb’s comes 
up with “it’s not for a GPSDO” somewhere in the first minute of the 
conversation.
The objective seems to be to tune the unit to a perfect source to speed up the
calibration process. The idea never appears to include noise on the reference
signal or odd perturbations in the reference. 

Bob

> On Oct 24, 2017, at 6:42 PM, Mark Sims  wrote:
> 
> I did a quick silly experiment where I took a PRS-10 disciplined by an X72 
> which was disciplined by the PRS-10.  The result seemed to have created a 
> rupture in the space-time continuum.  Nobody was happy...  they didn't seem 
> to agree on who was in charge.I need to try it again now that I have my 
> X72 interface boards back from China and can properly connect to the X72.
> 
> BTW, the firmware based disciplining on the X72 seems to be rather crappy.  
> It has lots of trouble locking to less than perfect 1PPS inputs.   For 
> instance it goes into holdover mode over half the time when driven by a Ublox 
> LEA-5T (which seems to have like +/- 60 ns jitter on the 1PPS.   It does lock 
> fine with a Tbolt...  but needing a GPSDO to discipline a rubidium sort of 
> defeats the purpose of disciplining a rubidium.
> 
> Lady Heather now has an X72/SA22 disciplining routine built in that works 
> fairly well using the LEA-5T.  Adevs are in the mid E-13 range at 10,000 
> seconds and the 1PPS output is in the +/- 50 ns range.  
> ___
> 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] I've been thinking about a GPS receiver experiment

[Mark Sims]

I did a quick silly experiment where I took a PRS-10 disciplined by an X72 
which was disciplined by the PRS-10.  The result seemed to have created a 
rupture in the space-time continuum.  Nobody was happy...  they didn't seem to 
agree on who was in charge.I need to try it again now that I have my X72 
interface boards back from China and can properly connect to the X72.

BTW, the firmware based disciplining on the X72 seems to be rather crappy.  It 
has lots of trouble locking to less than perfect 1PPS inputs.   For instance it 
goes into holdover mode over half the time when driven by a Ublox LEA-5T (which 
seems to have like +/- 60 ns jitter on the 1PPS.   It does lock fine with a 
Tbolt...  but needing a GPSDO to discipline a rubidium sort of defeats the 
purpose of disciplining a rubidium.

Lady Heather now has an X72/SA22 disciplining routine built in that works 
fairly well using the LEA-5T.  Adevs are in the mid E-13 range at 10,000 
seconds and the 1PPS output is in the +/- 50 ns range.  
___
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.

Re: [time-nuts] inexpensive, black box, GPS or NTP based TTL time capture?

[jimlux]

On 10/24/17 11:27 PM, Michael Wouters wrote:

Hello Jim

We are using BeagleBone Black + GPS 1 pps etc in our time-transfer system

You can see the overlays in
https://github.com/openttp/openttp/tree/develop/software/system/device-tree-overlays

Best regards
Michael



Tnx, I think my signal is coming through ok - if I look at 
/sys/class/gpio/gpio66, I can see the value changing when I connect the 
pin to +3 or 0V.

It's just not getting to the pps kernel driver -
No "assert" timestamp from /sys/class/pps/pps0/assert  (or ppstest)
___
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.

Re: [time-nuts] inexpensive, black box, GPS or NTP based TTL time capture?

[Edesio Costa e Silva]

Hi!

You could also look at NavSpark
(http://navspark.mybigcommerce.com/navspark-arduino-compatible-development-board-with-gps/).
 It
has a serial NMEA output, a PPS digital output AND a trigger pin for
timestamp capture.

Regards,

Edésio

On Wed, Oct 25, 2017 at 07:45:49AM +0100, Iain Young wrote:
> Hi Michael,
>
> You Wrote:
>
> >We are using BeagleBone Black + GPS 1 pps etc in our time-transfer system
> >
> >You can see the overlays in
> >https://github.com/openttp/openttp/tree/develop/software/system/device-tree-overlays
>
> Very interesting, I will have to clone the git repo, and have a closer
> look.
>
> I have my own 'fleet' of Beaglebone Blacks and Greens monitoring LORAN and
> GPS. Working to add my small rubidiums and some LF and HF Clocks as
> well. One day I will get the time to document the entire thing!
>
> I am using the PRUSS to do Time Interval Measurements (details can be
> found in the list archive), and feeding a PPS via TIMER4, and the highly
> accurate timer that the Beaglebones have onboard.
>
> Is there a particular reason you used the GPIO rather than TIMER4 ?
> (If your google for Dan Drown DMTIMER, you will find the Linux Driver)
>
> He also has coded up the TCLKIN pin, so that you can clock the
> Beaglebone from an external reference, which also may be of interest.
> (That bit I still need to do - I have the code enabled, just need to
> plug a reference in to the Beaglebones!)
>
> FreeBSD also has a driver for the TIMER4 input
>
>
> Iain
> ___
> 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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

Hi

Since you are doing a loop design that involves “months long” data runs, having
good logging and monitoring is a key part of the process. Without the testing 
side
of the process you are pretty much guaranteed to go astray in one way or the 
other.
That’s not to say you have to have a giant lab full of millions of dollars of 
gear. You
will need something to compare to and good logs of what goes in, what comes out,
and as much of the intermediates as you can stand to look at.

Bob

> On Oct 25, 2017, at 12:14 AM, Ole Petter Ronningen  
> wrote:
> 
> I did log the #TIME message for several weeks on an OEMV-3 a while back.
> The results were a bit suspicious, so I checked with Novatel support -
> turns out the PPS on the OEMV (and I presume that also holds for OEM4) is
> derived from L1 only - and the jitter is nothing to brag about. So for
> disciplining with PPS, something like a UBlox would be better as far as I
> can tell.
> 
> The other option is to log the #RANGE-message from the Novatel, convert to
> RINEX and solve with PPP, and use the output of that to adjust the
> rubidium. The added benefit is that you'll have an excellent log of what
> your reference is doing if you get odd results in some measurements.
> 
> Ole
> 
> On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson <
> mag...@rubidium.dyndns.org> wrote:
> 
>> Skip,
>> 
>> I would rather use the rich Novatel reports and read out the time error
>> and use that as your phase detector, then the normal PI-loop stuff with an
>> optional low-pass to add and then use that to steer the rubidium.
>> 
>> It's one of those, when I get time, projects.
>> 
>> Cheers,
>> Magnus
>> 
>> 
>> On 10/25/2017 12:17 AM, Skip Withrow wrote:
>> 
>>> Hello time-nuts,
>>> 
>>> I've been thinking about a GPS receiver experiment and just wondering
>>> if there are any opinions or prior experience that might save me a lot
>>> of time.
>>> 
>>> What I have been thinking about doing is taking a GPS receiver
>>> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10
>>> MHz) and driving it with a rubidium oscillator (that has 1pps
>>> disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS even has
>>> settings for OCXO/rubidium/cesium dynamics.
>>> 
>>> Then, (and here is the unknown part) what if the GPS receiver 1pps is
>>> used to discipline the rubidium?  This basically forms a feedback
>>> loop, so could either hurt or help - depending.  Supposedly the better
>>> oscillator would give a better GPS solution.  And the better solution
>>> (1pps) should provide a better oscillator frequency.
>>> 
>>> We know that GPS receivers using asynchronous clocks have 1pps errors
>>> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
>>> on 10MHz and disciplined will the 1pps error be reduced such as the
>>> Thunderbolt?
>>> 
>>> Comments appreciated.
>>> 
>>> Regards,
>>> Skip Withrow
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>>> ailman/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/m
>> ailman/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.