Empathy List Archives

PK

Poul-Henning Kamp

Fri, Feb 28, 2014 9:51 PM

A long time ago, I found out that the HP5370 is quite sensitive to
qualities of the external reference signal and after playing around
with it a bit, I decided to run my HP5370 from its own OCXO since
that was both reproducible and eliminated what I suspected was the
root cause.

While playing around with John's new CPU board, and now having a bit
more kit in my lab, I decided to revisit this detail.

The setup I created is the following:

10 MHz GPS locked "lab-standard" feeds ext-ref on the HP3336.

The HP3336 generates 10MHz/0dBm which feeds ext-ref on the HP5370

The same lab-standard also feeds the start input of the HP5370
which is setup to start-common, TI, 1k samples, output stddev.

And then I step the phase of the HP3336 generated 10MHz through
0...360 degrees relative to the lab-standard.

The result is the attached plot, where for every 18 degrees
the stddev increases by 8-10ps, roughly 40%.

This is evidently because the ext-ref on the HP5370 is multiplied
to 200MHz, which is what drives the counter circuits.

Another way to run this experiment, is to set the HP3336 to
10.0000001 MHz and log the stddev's over time while the
two clocks sweep each other by in phase. Doing it this way
can give you a plot of much higher resolution.

And that scenario is where the trouble starts:

If the HP5370 ref-in clock synchronous to the experimental
signals, you will most likely be lucky, but sometimes you will not
and the noise will be much larger.

If the HP5370 ref is not synchronous, for instance running of its
own OCXO, the two phases will sometimes conspire briefly and you
get a few noisy samples, but the average will almost always be good.

I have not tried to calibrate/trim the HP5370 to see what that
does to these spikes, but it would be an interesting experiment.

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

A long time ago, I found out that the HP5370 is quite sensitive to qualities of the external reference signal and after playing around with it a bit, I decided to run my HP5370 from its own OCXO since that was both reproducible and eliminated what I suspected was the root cause. While playing around with John's new CPU board, and now having a bit more kit in my lab, I decided to revisit this detail. The setup I created is the following: 10 MHz GPS locked "lab-standard" feeds ext-ref on the HP3336. The HP3336 generates 10MHz/0dBm which feeds ext-ref on the HP5370 The same lab-standard also feeds the start input of the HP5370 which is setup to start-common, TI, 1k samples, output stddev. And then I step the phase of the HP3336 generated 10MHz through 0...360 degrees relative to the lab-standard. The result is the attached plot, where for every 18 degrees the stddev increases by 8-10ps, roughly 40%. This is evidently because the ext-ref on the HP5370 is multiplied to 200MHz, which is what drives the counter circuits. Another way to run this experiment, is to set the HP3336 to 10.0000001 MHz and log the stddev's over time while the two clocks sweep each other by in phase. Doing it this way can give you a plot of much higher resolution. And that scenario is where the trouble starts: If the HP5370 ref-in clock synchronous to the experimental signals, you will most likely be lucky, but sometimes you will not and the noise will be much larger. If the HP5370 ref is not synchronous, for instance running of its own OCXO, the two phases will sometimes conspire briefly and you get a few noisy samples, but the average will almost always be good. I have not tried to calibrate/trim the HP5370 to see what that does to these spikes, but it would be an interesting experiment. -- 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.

MD

Magnus Danielson

Fri, Feb 28, 2014 10:20 PM

On 28/02/14 22:51, Poul-Henning Kamp wrote:

A long time ago, I found out that the HP5370 is quite sensitive to
qualities of the external reference signal and after playing around
with it a bit, I decided to run my HP5370 from its own OCXO since
that was both reproducible and eliminated what I suspected was the
root cause.

While playing around with John's new CPU board, and now having a bit
more kit in my lab, I decided to revisit this detail.

The setup I created is the following:

10 MHz GPS locked "lab-standard" feeds ext-ref on the HP3336.

The HP3336 generates 10MHz/0dBm which feeds ext-ref on the HP5370

The same lab-standard also feeds the start input of the HP5370
which is setup to start-common, TI, 1k samples, output stddev.

And then I step the phase of the HP3336 generated 10MHz through
0...360 degrees relative to the lab-standard.

The result is the attached plot, where for every 18 degrees
the stddev increases by 8-10ps, roughly 40%.

This is evidently because the ext-ref on the HP5370 is multiplied
to 200MHz, which is what drives the counter circuits.

Another way to run this experiment, is to set the HP3336 to
10.0000001 MHz and log the stddev's over time while the
two clocks sweep each other by in phase. Doing it this way
can give you a plot of much higher resolution.

And that scenario is where the trouble starts:

If the HP5370 ref-in clock synchronous to the experimental
signals, you will most likely be lucky, but sometimes you will not
and the noise will be much larger.

If the HP5370 ref is not synchronous, for instance running of its
own OCXO, the two phases will sometimes conspire briefly and you
get a few noisy samples, but the average will almost always be good.

I have not tried to calibrate/trim the HP5370 to see what that
does to these spikes, but it would be an interesting experiment.

I'm not a bit surprised. I tried using the normal HP5370 trimming
routines, but I found that using my SIA3000 helped a lot on the 200 MHz
synthesis chain.

Also, as I have told before the board doing the 10 MHz logic spews out a
lot of 5 MHz with overtones, which is a simple mod away.

Would be interesting to see if you could trim these systematics down by
tweaking the syntesis chain. Maybe some peaks is good indicators for a
particular stage offset, which would be expected from the x5 followed by
x4 multipliers with tons of filters. The 50 MHz tank would be a good
prime suspect I would think.

Cheers,
Magnus

On 28/02/14 22:51, Poul-Henning Kamp wrote: > > A long time ago, I found out that the HP5370 is quite sensitive to > qualities of the external reference signal and after playing around > with it a bit, I decided to run my HP5370 from its own OCXO since > that was both reproducible and eliminated what I suspected was the > root cause. > > While playing around with John's new CPU board, and now having a bit > more kit in my lab, I decided to revisit this detail. > > The setup I created is the following: > > 10 MHz GPS locked "lab-standard" feeds ext-ref on the HP3336. > > The HP3336 generates 10MHz/0dBm which feeds ext-ref on the HP5370 > > The same lab-standard also feeds the start input of the HP5370 > which is setup to start-common, TI, 1k samples, output stddev. > > And then I step the phase of the HP3336 generated 10MHz through > 0...360 degrees relative to the lab-standard. > > The result is the attached plot, where for every 18 degrees > the stddev increases by 8-10ps, roughly 40%. > > This is evidently because the ext-ref on the HP5370 is multiplied > to 200MHz, which is what drives the counter circuits. > > Another way to run this experiment, is to set the HP3336 to > 10.0000001 MHz and log the stddev's over time while the > two clocks sweep each other by in phase. Doing it this way > can give you a plot of much higher resolution. > > And that scenario is where the trouble starts: > > If the HP5370 ref-in clock synchronous to the experimental > signals, you will most likely be lucky, but sometimes you will not > and the noise will be much larger. > > If the HP5370 ref is not synchronous, for instance running of its > own OCXO, the two phases will sometimes conspire briefly and you > get a few noisy samples, but the average will almost always be good. > > I have not tried to calibrate/trim the HP5370 to see what that > does to these spikes, but it would be an interesting experiment. I'm not a bit surprised. I tried using the normal HP5370 trimming routines, but I found that using my SIA3000 helped a lot on the 200 MHz synthesis chain. Also, as I have told before the board doing the 10 MHz logic spews out a lot of 5 MHz with overtones, which is a simple mod away. Would be interesting to see if you could trim these systematics down by tweaking the syntesis chain. Maybe some peaks is good indicators for a particular stage offset, which would be expected from the x5 followed by x4 multipliers with tons of filters. The 50 MHz tank would be a good prime suspect I would think. Cheers, Magnus

PK

Poul-Henning Kamp

Fri, Feb 28, 2014 11:06 PM

In message 53110BC6.6010109@rubidium.dyndns.org, Magnus Danielson writes:

Also, as I have told before the board doing the 10 MHz logic spews out a
lot of 5 MHz with overtones, which is a simple mod away.

I remember you mentioning this, but I never did the mod on my counter,
got anything I can search for in the mail-archive ?

Would be interesting to see if you could trim these systematics down by
tweaking the syntesis chain.

It is not obvious to me that the 200MHz multiplier is involved in
its own capacity, it may simply be that the 200MHz is slewed across
the input signal and that the zero-crossing jitter therefore moves
into the window where it matters ?

--
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 <53110BC6.6010109@rubidium.dyndns.org>, Magnus Danielson writes: >Also, as I have told before the board doing the 10 MHz logic spews out a >lot of 5 MHz with overtones, which is a simple mod away. I remember you mentioning this, but I never did the mod on my counter, got anything I can search for in the mail-archive ? >Would be interesting to see if you could trim these systematics down by >tweaking the syntesis chain. It is not obvious to me that the 200MHz multiplier is involved in its own capacity, it may simply be that the 200MHz is slewed across the input signal and that the zero-crossing jitter therefore moves into the window where it matters ? -- 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.

MD

Magnus Danielson

Sat, Mar 1, 2014 12:07 AM

On 01/03/14 00:06, Poul-Henning Kamp wrote:

In message 53110BC6.6010109@rubidium.dyndns.org, Magnus Danielson writes:

Also, as I have told before the board doing the 10 MHz logic spews out a
lot of 5 MHz with overtones, which is a simple mod away.

I remember you mentioning this, but I never did the mod on my counter,
got anything I can search for in the mail-archive ?

Not from the top of my head. What I did was that I soldered one of the
transistors base to ground (if I recall correctly) so that the
comparator got stuck in the state. Fairly straight-forward. Look at the
A8 board and the Q8 and Q6. That ECL loop requires the 10 MHz to be
reasonably running for the LED to go on. Don't need that when not
looking or suspecting problems. ECL having good rise-time creates
shit-load of overtones.

Would be interesting to see if you could trim these systematics down by
tweaking the syntesis chain.

It is not obvious to me that the 200MHz multiplier is involved in
its own capacity, it may simply be that the 200MHz is slewed across
the input signal and that the zero-crossing jitter therefore moves
into the window where it matters ?

It does not have to be the 200 MHz syntesis, but it can be. The 10 MHz
banks at the 50 MHz resonator tank every 50 ns through the transistor,
and if de-tuned will the transitions be of the mark the further you go.
The same thing for the 200 MHz resonator tank. The filters helps to
other frequencies out.

The resonator tanks is just re-triggered oscillators which have
saw-tooth time-error phase which you can trim down by moving them more
onto frequency.

Then again, 200 MHz may cross-talk into the signal path and modulate the
trigger point. My guess is both happen to a degree.

Cheers,
Magnus

On 01/03/14 00:06, Poul-Henning Kamp wrote: > In message <53110BC6.6010109@rubidium.dyndns.org>, Magnus Danielson writes: > >> Also, as I have told before the board doing the 10 MHz logic spews out a >> lot of 5 MHz with overtones, which is a simple mod away. > > I remember you mentioning this, but I never did the mod on my counter, > got anything I can search for in the mail-archive ? Not from the top of my head. What I did was that I soldered one of the transistors base to ground (if I recall correctly) so that the comparator got stuck in the state. Fairly straight-forward. Look at the A8 board and the Q8 and Q6. That ECL loop requires the 10 MHz to be reasonably running for the LED to go on. Don't need that when not looking or suspecting problems. ECL having good rise-time creates shit-load of overtones. >> Would be interesting to see if you could trim these systematics down by >> tweaking the syntesis chain. > > It is not obvious to me that the 200MHz multiplier is involved in > its own capacity, it may simply be that the 200MHz is slewed across > the input signal and that the zero-crossing jitter therefore moves > into the window where it matters ? It does not have to be the 200 MHz syntesis, but it can be. The 10 MHz banks at the 50 MHz resonator tank every 50 ns through the transistor, and if de-tuned will the transitions be of the mark the further you go. The same thing for the 200 MHz resonator tank. The filters helps to other frequencies out. The resonator tanks is just re-triggered oscillators which have saw-tooth time-error phase which you can trim down by moving them more onto frequency. Then again, 200 MHz may cross-talk into the signal path and modulate the trigger point. My guess is both happen to a degree. Cheers, Magnus

BC

Bob Camp

Sat, Mar 1, 2014 12:47 AM

Hi

There is a fairly involved alignment process for the multiplier chain. My guess is that small tweaks to the alignment could impact these timing spikes. Sub harmonics tend to produce multiple zero crossings that show up as periodic jitter in the output. The offset input peaks may be a better thing to look at as you tweak the multiplier than the “official” adjustment procedure.

Bob

On Feb 28, 2014, at 7:07 PM, Magnus Danielson magnus@rubidium.dyndns.org wrote:

On 01/03/14 00:06, Poul-Henning Kamp wrote:

In message 53110BC6.6010109@rubidium.dyndns.org, Magnus Danielson writes:

Also, as I have told before the board doing the 10 MHz logic spews out a
lot of 5 MHz with overtones, which is a simple mod away.

I remember you mentioning this, but I never did the mod on my counter,
got anything I can search for in the mail-archive ?

Not from the top of my head. What I did was that I soldered one of the transistors base to ground (if I recall correctly) so that the comparator got stuck in the state. Fairly straight-forward. Look at the A8 board and the Q8 and Q6. That ECL loop requires the 10 MHz to be reasonably running for the LED to go on. Don't need that when not looking or suspecting problems. ECL having good rise-time creates shit-load of overtones.

Would be interesting to see if you could trim these systematics down by
tweaking the syntesis chain.

It is not obvious to me that the 200MHz multiplier is involved in
its own capacity, it may simply be that the 200MHz is slewed across
the input signal and that the zero-crossing jitter therefore moves
into the window where it matters ?

It does not have to be the 200 MHz syntesis, but it can be. The 10 MHz banks at the 50 MHz resonator tank every 50 ns through the transistor, and if de-tuned will the transitions be of the mark the further you go.
The same thing for the 200 MHz resonator tank. The filters helps to other frequencies out.

The resonator tanks is just re-triggered oscillators which have saw-tooth time-error phase which you can trim down by moving them more onto frequency.

Then again, 200 MHz may cross-talk into the signal path and modulate the trigger point. My guess is both happen to a degree.

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.

Hi There is a fairly involved alignment process for the multiplier chain. My *guess* is that small tweaks to the alignment could impact these timing spikes. Sub harmonics tend to produce multiple zero crossings that show up as periodic jitter in the output. The offset input peaks may be a better thing to look at as you tweak the multiplier than the “official” adjustment procedure. Bob On Feb 28, 2014, at 7:07 PM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote: > On 01/03/14 00:06, Poul-Henning Kamp wrote: >> In message <53110BC6.6010109@rubidium.dyndns.org>, Magnus Danielson writes: >> >>> Also, as I have told before the board doing the 10 MHz logic spews out a >>> lot of 5 MHz with overtones, which is a simple mod away. >> >> I remember you mentioning this, but I never did the mod on my counter, >> got anything I can search for in the mail-archive ? > > Not from the top of my head. What I did was that I soldered one of the transistors base to ground (if I recall correctly) so that the comparator got stuck in the state. Fairly straight-forward. Look at the A8 board and the Q8 and Q6. That ECL loop requires the 10 MHz to be reasonably running for the LED to go on. Don't need that when not looking or suspecting problems. ECL having good rise-time creates shit-load of overtones. > >>> Would be interesting to see if you could trim these systematics down by >>> tweaking the syntesis chain. >> >> It is not obvious to me that the 200MHz multiplier is involved in >> its own capacity, it may simply be that the 200MHz is slewed across >> the input signal and that the zero-crossing jitter therefore moves >> into the window where it matters ? > > It does not have to be the 200 MHz syntesis, but it can be. The 10 MHz banks at the 50 MHz resonator tank every 50 ns through the transistor, and if de-tuned will the transitions be of the mark the further you go. > The same thing for the 200 MHz resonator tank. The filters helps to other frequencies out. > > The resonator tanks is just re-triggered oscillators which have saw-tooth time-error phase which you can trim down by moving them more onto frequency. > > Then again, 200 MHz may cross-talk into the signal path and modulate the trigger point. My guess is both happen to a degree. > > 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.

MD

Magnus Danielson

Sat, Mar 1, 2014 10:39 AM

On 01/03/14 01:47, Bob Camp wrote:

Hi

There is a fairly involved alignment process for the multiplier chain. My guess is that small tweaks to the alignment could impact these timing spikes. Sub harmonics tend to produce multiple zero crossings that show up as periodic jitter in the output. The offset input peaks may be a better thing to look at as you tweak the multiplier than the “official” adjustment procedure.

It was exactly what I was hinting about, it may be a better procedure as
it addresses the actual precision rather than indirect phase noise
measures. Just doing phase-noise measures rather than spectrum analysis
helped to illustrate the problem.

Cheers,
Magnus

On 01/03/14 01:47, Bob Camp wrote: > Hi > > There is a fairly involved alignment process for the multiplier chain. My *guess* is that small tweaks to the alignment could impact these timing spikes. Sub harmonics tend to produce multiple zero crossings that show up as periodic jitter in the output. The offset input peaks may be a better thing to look at as you tweak the multiplier than the “official” adjustment procedure. It was exactly what I was hinting about, it may be a better procedure as it addresses the actual precision rather than indirect phase noise measures. Just doing phase-noise measures rather than spectrum analysis helped to illustrate the problem. Cheers, Magnus

BL

Brian Lloyd

Sat, Mar 1, 2014 5:20 PM

Instead of using the external reference input, any thoughts on actually
disciplining the internal OCXO to bypass the problem?

--
Brian Lloyd, WB6RQN/J79BPL
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.com
+1.916.877.5067

Instead of using the external reference input, any thoughts on actually disciplining the internal OCXO to bypass the problem? -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 brian@lloyd.com +1.916.877.5067

JS

John Seamons

Sat, Mar 1, 2014 5:39 PM

On Mar 2, 2014, at 6:20 AM, Brian Lloyd brian@lloyd.com wrote:

Instead of using the external reference input, any thoughts on actually
disciplining the internal OCXO to bypass the problem?

I almost put a GPS front-end chip and small FPGA on the 5370 board. You can imagine where that idea was going. I mean, you've got that whole BeagleBone just sitting there with some spare cycles now that I use the PRU. But it would have doubled the BOM cost. Probably more depending on the choice of DAC solution.

On Mar 2, 2014, at 6:20 AM, Brian Lloyd <brian@lloyd.com> wrote: > Instead of using the external reference input, any thoughts on actually > disciplining the internal OCXO to bypass the problem? I almost put a GPS front-end chip and small FPGA on the 5370 board. You can imagine where that idea was going. I mean, you've got that whole BeagleBone just sitting there with some spare cycles now that I use the PRU. But it would have doubled the BOM cost. Probably more depending on the choice of DAC solution.

PL

Pete Lancashire

Sat, Mar 1, 2014 6:05 PM

Idea. On the next go around for the board put the copper down and holes for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.

-pete

On Sat, Mar 1, 2014 at 9:39 AM, John Seamons jks@jks.com wrote:

On Mar 2, 2014, at 6:20 AM, Brian Lloyd brian@lloyd.com wrote:

Instead of using the external reference input, any thoughts on actually
disciplining the internal OCXO to bypass the problem?

I almost put a GPS front-end chip and small FPGA on the 5370 board. You
can imagine where that idea was going. I mean, you've got that whole
BeagleBone just sitting there with some spare cycles now that I use the
PRU. But it would have doubled the BOM cost. Probably more depending on the
choice of DAC solution.

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.

Idea. On the next go around for the board put the copper down and holes for a couple small daughter cards and any support logic needed to interface with the BBB. The the only additional cost would be limited to the daughter board I/O since my guess it would be SMT hence a bit hard to leave it unpopulated. -pete On Sat, Mar 1, 2014 at 9:39 AM, John Seamons <jks@jks.com> wrote: > On Mar 2, 2014, at 6:20 AM, Brian Lloyd <brian@lloyd.com> wrote: > > > Instead of using the external reference input, any thoughts on actually > > disciplining the internal OCXO to bypass the problem? > > I almost put a GPS front-end chip and small FPGA on the 5370 board. You > can imagine where that idea was going. I mean, you've got that whole > BeagleBone just sitting there with some spare cycles now that I use the > PRU. But it would have doubled the BOM cost. Probably more depending on the > choice of DAC solution. > > _______________________________________________ > 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. >

MD

Magnus Danielson

Sat, Mar 1, 2014 6:54 PM

On 01/03/14 18:20, Brian Lloyd wrote:

Instead of using the external reference input, any thoughts on actually
disciplining the internal OCXO to bypass the problem?

Considering that it's a HP10811A, it shouln't be too hard.
In general, doing a new A8 board might be an option.

Cheers,
Magnus

On 01/03/14 18:20, Brian Lloyd wrote: > Instead of using the external reference input, any thoughts on actually > disciplining the internal OCXO to bypass the problem? > Considering that it's a HP10811A, it shouln't be too hard. In general, doing a new A8 board might be an option. Cheers, Magnus

JS

John Seamons

Sat, Mar 1, 2014 7:02 PM

On Mar 2, 2014, at 7:05 AM, Pete Lancashire pete@petelancashire.com wrote:

Idea. On the next go around for the board put the copper down and holes for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.

Good idea. Also the Beagle spec allows for multiple, stacked interface boards ('capes' they call them). So for a backwards compatible solution an experimental GPSDO + backup power cape could be interposed between the Beagle and 5370 board. I say experimental because I have no idea if any of the SDGPS projects out there would be ultimately suitable for a DO.

This brings up a question I have about how the PPS edge is actually derived by a GPS receiver. Does it originally come from the NAV data stream and then get corrected by the (fixed-mode) positioning solution to account for transmission/system delays? I know about the issue of alignment with the VCTCXO clock, but I'm talking about upstream of that.

On Mar 2, 2014, at 7:05 AM, Pete Lancashire <pete@petelancashire.com> wrote: > Idea. On the next go around for the board put the copper down and holes for > a couple small daughter cards and any support logic needed to interface > with the BBB. > The the only additional cost would be limited to the daughter board I/O > since my guess it would be SMT hence a bit hard to leave it unpopulated. Good idea. Also the Beagle spec allows for multiple, stacked interface boards ('capes' they call them). So for a backwards compatible solution an experimental GPSDO + backup power cape could be interposed between the Beagle and 5370 board. I say experimental because I have no idea if any of the SDGPS projects out there would be ultimately suitable for a DO. This brings up a question I have about how the PPS edge is actually derived by a GPS receiver. Does it originally come from the NAV data stream and then get corrected by the (fixed-mode) positioning solution to account for transmission/system delays? I know about the issue of alignment with the VCTCXO clock, but I'm talking about upstream of that.

BC

Bob Camp

Sat, Mar 1, 2014 7:06 PM

Hi

They run an NCO (drop / add pulses) to generate the PPS off of the TCXO. The amount of adjustment is a function of the solution they derive from the GPS messages. In some cases they do a solution, and correct the next edge to that solution. In other chip sets the solution and the edge come out at the same time.

Bob

On Mar 1, 2014, at 2:02 PM, John Seamons jks@jks.com wrote:

On Mar 2, 2014, at 7:05 AM, Pete Lancashire pete@petelancashire.com wrote:

Idea. On the next go around for the board put the copper down and holes for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.

Good idea. Also the Beagle spec allows for multiple, stacked interface boards ('capes' they call them). So for a backwards compatible solution an experimental GPSDO + backup power cape could be interposed between the Beagle and 5370 board. I say experimental because I have no idea if any of the SDGPS projects out there would be ultimately suitable for a DO.

This brings up a question I have about how the PPS edge is actually derived by a GPS receiver. Does it originally come from the NAV data stream and then get corrected by the (fixed-mode) positioning solution to account for transmission/system delays? I know about the issue of alignment with the VCTCXO clock, but I'm talking about upstream of that.

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 They run an NCO (drop / add pulses) to generate the PPS off of the TCXO. The amount of adjustment is a function of the solution they derive from the GPS messages. In some cases they do a solution, and correct the *next* edge to that solution. In other chip sets the solution and the edge come out at the same time. Bob On Mar 1, 2014, at 2:02 PM, John Seamons <jks@jks.com> wrote: > > On Mar 2, 2014, at 7:05 AM, Pete Lancashire <pete@petelancashire.com> wrote: > >> Idea. On the next go around for the board put the copper down and holes for >> a couple small daughter cards and any support logic needed to interface >> with the BBB. >> The the only additional cost would be limited to the daughter board I/O >> since my guess it would be SMT hence a bit hard to leave it unpopulated. > > Good idea. Also the Beagle spec allows for multiple, stacked interface boards ('capes' they call them). So for a backwards compatible solution an experimental GPSDO + backup power cape could be interposed between the Beagle and 5370 board. I say experimental because I have no idea if any of the SDGPS projects out there would be ultimately suitable for a DO. > > This brings up a question I have about how the PPS edge is actually derived by a GPS receiver. Does it originally come from the NAV data stream and then get corrected by the (fixed-mode) positioning solution to account for transmission/system delays? I know about the issue of alignment with the VCTCXO clock, but I'm talking about upstream of that. > > _______________________________________________ > 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.

PK

Poul-Henning Kamp

Sat, Mar 1, 2014 9:38 PM

In message CAE3hgTd5UDz_-T5mvgBarYYyuLwn=+00p1Fho2Fs+T1p1xdGLQ@mail.gmail.com
, Brian Lloyd writes:

Instead of using the external reference input, any thoughts on actually
disciplining the internal OCXO to bypass the problem?

The end result would be no different than using ext-ref.

Right now I think the best approach to "smear" the error out, is
to run ext-ref from a frequency which is well-known, but not
synchronous with the input signals, for instance from a synth like
the 3336 or a carefully mis-tuned GPSDO

The EFC pin on the OCXO in the 5370 is grounded in a way that makes it
quite hard to unground.

--
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 <CAE3hgTd5UDz_-T5mvgBarYYyuLwn=+00p1Fho2Fs+T1p1xdGLQ@mail.gmail.com> , Brian Lloyd writes: >Instead of using the external reference input, any thoughts on actually >disciplining the internal OCXO to bypass the problem? The end result would be no different than using ext-ref. Right now I think the best approach to "smear" the error out, is to run ext-ref from a frequency which is well-known, but not synchronous with the input signals, for instance from a synth like the 3336 or a carefully mis-tuned GPSDO The EFC pin on the OCXO in the 5370 is grounded in a way that makes it quite hard to unground. -- 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.

PL

Pete Lancashire

Sat, Mar 1, 2014 10:35 PM

not being able to get to my two dead 5370Bs is there enough clearance to
allow for stacking capes ? If not the interface could be a 'horizontal'
implementation. Another one that just came to mind is have holes that
would allow one to put a metal can over the digital blocks / capes /
boards. Holes would go to ground.

On Sat, Mar 1, 2014 at 11:02 AM, John Seamons jks@jks.com wrote:

On Mar 2, 2014, at 7:05 AM, Pete Lancashire pete@petelancashire.com
wrote:

Idea. On the next go around for the board put the copper down and holes

for

a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.

Good idea. Also the Beagle spec allows for multiple, stacked interface
boards ('capes' they call them). So for a backwards compatible solution an
experimental GPSDO + backup power cape could be interposed between the
Beagle and 5370 board. I say experimental because I have no idea if any of
the SDGPS projects out there would be ultimately suitable for a DO.

This brings up a question I have about how the PPS edge is actually
derived by a GPS receiver. Does it originally come from the NAV data stream
and then get corrected by the (fixed-mode) positioning solution to account
for transmission/system delays? I know about the issue of alignment with
the VCTCXO clock, but I'm talking about upstream of that.

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.

not being able to get to my two dead 5370Bs is there enough clearance to allow for stacking capes ? If not the interface could be a 'horizontal' implementation. Another one that just came to mind is have holes that would allow one to put a metal can over the digital blocks / capes / boards. Holes would go to ground. On Sat, Mar 1, 2014 at 11:02 AM, John Seamons <jks@jks.com> wrote: > > On Mar 2, 2014, at 7:05 AM, Pete Lancashire <pete@petelancashire.com> > wrote: > > > Idea. On the next go around for the board put the copper down and holes > for > > a couple small daughter cards and any support logic needed to interface > > with the BBB. > > The the only additional cost would be limited to the daughter board I/O > > since my guess it would be SMT hence a bit hard to leave it unpopulated. > > Good idea. Also the Beagle spec allows for multiple, stacked interface > boards ('capes' they call them). So for a backwards compatible solution an > experimental GPSDO + backup power cape could be interposed between the > Beagle and 5370 board. I say experimental because I have no idea if any of > the SDGPS projects out there would be ultimately suitable for a DO. > > This brings up a question I have about how the PPS edge is actually > derived by a GPS receiver. Does it originally come from the NAV data stream > and then get corrected by the (fixed-mode) positioning solution to account > for transmission/system delays? I know about the issue of alignment with > the VCTCXO clock, but I'm talking about upstream of that. > > _______________________________________________ > 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. >

MD

Magnus Danielson

Sun, Mar 2, 2014 12:20 AM

Hi,

Internally you typically run a 1 ms frame on everything. You integrate a
cycle of C/A code on each channel, sample state on all channels with the
1 ms clock and the solution will disclose the time-error of that 1 ms
clock so knowing how a 1 PPS relates to the 1 ms clock is fairly
trivial. The resolution will naturally be that of the core-clock, and
ones the delay for the right 1 ms frame has been setup, the PPS error
compared to the solution is known and you can calculate the "sawtooth"
if you care about it.

PPS as such is not in the GPS signal, rather all the time-info you need
to create it.

Cheers,
Magnus

On 01/03/14 20:06, Bob Camp wrote:

Hi

They run an NCO (drop / add pulses) to generate the PPS off of the TCXO. The amount of adjustment is a function of the solution they derive from the GPS messages. In some cases they do a solution, and correct the next edge to that solution. In other chip sets the solution and the edge come out at the same time.

Bob

On Mar 1, 2014, at 2:02 PM, John Seamons jks@jks.com wrote:

On Mar 2, 2014, at 7:05 AM, Pete Lancashire pete@petelancashire.com wrote:

Idea. On the next go around for the board put the copper down and holes for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.

Good idea. Also the Beagle spec allows for multiple, stacked interface boards ('capes' they call them). So for a backwards compatible solution an experimental GPSDO + backup power cape could be interposed between the Beagle and 5370 board. I say experimental because I have no idea if any of the SDGPS projects out there would be ultimately suitable for a DO.

This brings up a question I have about how the PPS edge is actually derived by a GPS receiver. Does it originally come from the NAV data stream and then get corrected by the (fixed-mode) positioning solution to account for transmission/system delays? I know about the issue of alignment with the VCTCXO clock, but I'm talking about upstream of that.

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, Internally you typically run a 1 ms frame on everything. You integrate a cycle of C/A code on each channel, sample state on all channels with the 1 ms clock and the solution will disclose the time-error of that 1 ms clock so knowing how a 1 PPS relates to the 1 ms clock is fairly trivial. The resolution will naturally be that of the core-clock, and ones the delay for the right 1 ms frame has been setup, the PPS error compared to the solution is known and you can calculate the "sawtooth" if you care about it. PPS as such is not in the GPS signal, rather all the time-info you need to create it. Cheers, Magnus On 01/03/14 20:06, Bob Camp wrote: > Hi > > They run an NCO (drop / add pulses) to generate the PPS off of the TCXO. The amount of adjustment is a function of the solution they derive from the GPS messages. In some cases they do a solution, and correct the *next* edge to that solution. In other chip sets the solution and the edge come out at the same time. > > Bob > > On Mar 1, 2014, at 2:02 PM, John Seamons <jks@jks.com> wrote: > >> >> On Mar 2, 2014, at 7:05 AM, Pete Lancashire <pete@petelancashire.com> wrote: >> >>> Idea. On the next go around for the board put the copper down and holes for >>> a couple small daughter cards and any support logic needed to interface >>> with the BBB. >>> The the only additional cost would be limited to the daughter board I/O >>> since my guess it would be SMT hence a bit hard to leave it unpopulated. >> >> Good idea. Also the Beagle spec allows for multiple, stacked interface boards ('capes' they call them). So for a backwards compatible solution an experimental GPSDO + backup power cape could be interposed between the Beagle and 5370 board. I say experimental because I have no idea if any of the SDGPS projects out there would be ultimately suitable for a DO. >> >> This brings up a question I have about how the PPS edge is actually derived by a GPS receiver. Does it originally come from the NAV data stream and then get corrected by the (fixed-mode) positioning solution to account for transmission/system delays? I know about the issue of alignment with the VCTCXO clock, but I'm talking about upstream of that. >> >> _______________________________________________ >> 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. >

MD

Magnus Danielson

Sun, Mar 2, 2014 12:25 AM

On 01/03/14 22:38, Poul-Henning Kamp wrote:

In message CAE3hgTd5UDz_-T5mvgBarYYyuLwn=+00p1Fho2Fs+T1p1xdGLQ@mail.gmail.com
, Brian Lloyd writes:

Instead of using the external reference input, any thoughts on actually
disciplining the internal OCXO to bypass the problem?

The end result would be no different than using ext-ref.

Right now I think the best approach to "smear" the error out, is
to run ext-ref from a frequency which is well-known, but not
synchronous with the input signals, for instance from a synth like
the 3336 or a carefully mis-tuned GPSDO

Would work if integer cycles is covered over the measurement time such
that samples is taken spread over the 100 ns reference cycle.

The EFC pin on the OCXO in the 5370 is grounded in a way that makes it
quite hard to unground.

Kapton tape into the connector, a wire soldered to EFC on the 10811?

Cheers,
Magnus

On 01/03/14 22:38, Poul-Henning Kamp wrote: > In message <CAE3hgTd5UDz_-T5mvgBarYYyuLwn=+00p1Fho2Fs+T1p1xdGLQ@mail.gmail.com> > , Brian Lloyd writes: > >> Instead of using the external reference input, any thoughts on actually >> disciplining the internal OCXO to bypass the problem? > > The end result would be no different than using ext-ref. > > Right now I think the best approach to "smear" the error out, is > to run ext-ref from a frequency which is well-known, but not > synchronous with the input signals, for instance from a synth like > the 3336 or a carefully mis-tuned GPSDO Would work if integer cycles is covered over the measurement time such that samples is taken spread over the 100 ns reference cycle. > The EFC pin on the OCXO in the 5370 is grounded in a way that makes it > quite hard to unground. > Kapton tape into the connector, a wire soldered to EFC on the 10811? Cheers, Magnus

PK

Poul-Henning Kamp

Sun, Mar 2, 2014 10:29 PM

I have spent another evening playing around with the 5370 and the
conclusion is pretty ironclad now:

Running a 5370 with ext-ref locked to input frequencies is simply
a bad idea and should not be done.

Running it on the internal OCXO works fine.

Running it on another frequency not locked to the input frequenc
also works fine.

In both cases the errors are statistically well-behaved, and can
be treated with normal statistical methods, including the built-in
STD-DEV function.

But feeding ext-ref a frequency which is locked to the input frequencies
causes the errors to become systematic, and they can no longer be
treated as statistically well-behaved.

For instance: The length of the coax to ext-ref suddenly affect
your TI measurements, because it shifts the phase between the 200MHz
and the input signal.

I tried tuning up the A21 200MHz synthesizer to the best of my
ability, and it clearly made a difference, the phase pattern
of errors shifted around, but the errors did not get any smaller,
they just moved.

I also tried disconnecting the "10 MHz present" circuit, that
didn't change the magnitude of the errors either, but did shift
the phase of the peak noise a couple of degrees.

Looking at some old notes from years past which just didn't make
sense, does now.

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

I have spent another evening playing around with the 5370 and the conclusion is pretty ironclad now: Running a 5370 with ext-ref locked to input frequencies is simply a bad idea and should not be done. Running it on the internal OCXO works fine. Running it on another frequency *not* locked to the input frequenc also works fine. In both cases the errors are statistically well-behaved, and can be treated with normal statistical methods, including the built-in STD-DEV function. But feeding ext-ref a frequency which is locked to the input frequencies causes the errors to become systematic, and they can no longer be treated as statistically well-behaved. For instance: The length of the coax to ext-ref suddenly affect your TI measurements, because it shifts the phase between the 200MHz and the input signal. I tried tuning up the A21 200MHz synthesizer to the best of my ability, and it clearly made a difference, the phase pattern of errors shifted around, but the errors did not get any smaller, they just moved. I also tried disconnecting the "10 MHz present" circuit, that didn't change the magnitude of the errors either, but did shift the phase of the peak noise a couple of degrees. Looking at some old notes from years past which just didn't make sense, does now. -- 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.

BC

Bob Camp

Sun, Mar 2, 2014 11:24 PM

Hi

Do you have any idea how “clean” your 200 MHz signal is? The manual suggests getting it to -65 dbc for subs using a spectrum analyzer. That’s pretty far down. I seem to recall the adjustment process being a bit tedious (lots of back and forth).

Bob

On Mar 2, 2014, at 5:29 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote: