Re: [time-nuts] Lady heather plus NTP server?

[Scott Mace]

Try this:

http://www.febo.com/pipermail/time-nuts/2010-February/044476.html

It uses the NTP SHM reference clock.

Scott

On 01/20/2014 09:01 PM, ken johnson wrote:

I currently have my router/firewall acting as both an NTP client, getting
it's time from the net, and an NTP server serving my home network. Now I
have my thunderbolt and Lady heather working nicely, I would like to have
that machine act as the ntp server for my network, but it appears ntp can't
understand tsip, and also with LH taking the com port, I can't see a way of
ntp getting the data anyway.

Is this possible to do, and if so,  can anyone give me some clues as to how?

Thanks, Ken.
___
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] NTP REFCLOCK for a Jackson Fury??

[Scott Mace]

Yes, the GPGGA method works.

Scott

On 10/17/2013 01:35 PM, Paul wrote:

On Thu, Oct 17, 2013 at 2:00 PM, Scott Mace  wrote:


Try setting your Fury hpgps driver fudge flag4 to 1




He said he thought he was using 20+22 (NMEA+PPS).  Of course the ntpq
output suggests GPSD or other shared memory driver.

--
Paul

___
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] NTP REFCLOCK for a Jackson Fury??

[Scott Mace]

I think the Fury does not guarantee that the PTIME:TCODE will be near 
the 1-PPS leading edge.  When I tried it with the HPGPS driver and a 
net4501, ntpd wasn't happy with it.  I also needed leap second 
processing to work, holdover notification, and to collect other data 
from it.  The GPGGA sentence is on-time even if you are asking the Fury 
to do other things with SCPI commands.  Try setting your Fury hpgps 
driver fudge flag4 to 1 and I bet it will stop working well.  This flag 
logs the system:print output.


Scott

On 10/17/2013 10:24 AM, Bill Dailey wrote:

Interesting.. I see something completely different with my Fury.

My hard-coded fudge factor is 0.077 yielding:

Every 2.0s: ntpq -p Thu Oct 17 10:20:00
2013

  remote   refid  st t when poll reach   delay   offset
jitter
==
-four2.fairy.mat 64.250.177.145   2 u   12   64  377   72.493   17.784
0.524
-66-162-15-65.li 64.236.96.53 2 u   33   64  377   50.226   15.291
1.181
+barricade.rack9 209.51.161.238   2 u   10   64  377   22.9081.075
0.362
-ccadmin.cycores 130.207.244.240  2 u   38   64  377   39.2183.972
1.241
  192.168.1.171   .INIT.  16 u- 102400.0000.000
0.000
+SHM(0)  .FURY.   0 l6   16  3770.0000.526
0.034
*SHM(1)  .PPSF.   0 l5   64  3770.0000.008
0.001
-europium.canoni 193.79.237.142 u   32   64  377  116.177   -1.573
0.992

So... i could fine tune my fudge some but the point is the jitter is fairly
low.  (fury is from the sentences and ppsf is pps from fury).

My soekris (soekris is the .171) numbers were much better but it is
inoperable for some reason.

Doc


On Thu, Oct 17, 2013 at 9:59 AM, Tim Shoppa  wrote:


Back in 2003 or so, in the Z3801A with hpgps ntpd refclock driver, I had to
add a negative offset of -0.98 seconds to the driver's decoding of
PTIME:TCODE? to get it to be right in combination with PPS refclock.

The documentation in the Z3801A manual correctly described the actual
behavior "PTIME:TCODE? Provides timecode message 980 to 20 ms prior to
1 PPS of indicated time".



On Thu, Oct 17, 2013 at 9:40 AM, Scott Mace  wrote:


I posted a patch for the Fury to work with ntpd in Oct 2008.  It uses the
GPGGA output.  The PTIME:TCODE? command is not "on-time" with the 1-PPS
output on the Fury, so the HPGPS driver does not work.

http://www.febo.com/pipermail/**time-nuts/2008-October/033901.**html<

http://www.febo.com/pipermail/time-nuts/2008-October/033901.html>


the ntp-fury.diff:
http://www.febo.com/pipermail/**time-nuts/attachments/**
20081020/846021fe/attachment-**0001.bin<

http://www.febo.com/pipermail/time-nuts/attachments/20081020/846021fe/attachment-0001.bin




 Scott



On 10/16/2013 04:44 PM, Frank Hughes wrote:


Hi,

What NTP REFCLOCK can be used for a Jackson Fury?

I know that the Jackson Fury docs suggest using:
http://www.realhamradio.com/**gpscon-info.htm<

http://www.realhamradio.com/gpscon-info.htm>


But that means I would have to put up a windows server
to replace the FreeBSD ntpd server I built for use w/ the Trimble TB.

Looking for open source options, if possible.

Thanks,
Frank
KJ4OLL
__**_
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/**
mailman/listinfo/time-nuts<

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<

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] NTP REFCLOCK for a Jackson Fury??

[Scott Mace]

The GPGGA sentence is on-time enough so that ntpd will work.  You still 
have to set 'mindist' to something like 0.050.  The driver will also 
query other interesting things from the Fury.


The response from PTIME:TCODE? varied too much for ntpd to use it even 
with a large mindist.


Scott

On 10/17/2013 09:14 AM, Paul wrote:

On Thu, Oct 17, 2013 at 9:40 AM, Scott Mace  wrote:


The PTIME:TCODE? command is not "on-time" with the 1-PPS output on the Fury




Is it consistently before or after the pulse?  I.e. can it be fixed with
time1?  Is there the same problem with the NMEA sentences?

In any case these sorts of issues are why I prefer to number seconds with a
known-to-work system.

--
Paul
___
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] NTP REFCLOCK for a Jackson Fury??

[Scott Mace]

I posted a patch for the Fury to work with ntpd in Oct 2008.  It uses 
the GPGGA output.  The PTIME:TCODE? command is not "on-time" with the 
1-PPS output on the Fury, so the HPGPS driver does not work.


http://www.febo.com/pipermail/time-nuts/2008-October/033901.html

the ntp-fury.diff:
http://www.febo.com/pipermail/time-nuts/attachments/20081020/846021fe/attachment-0001.bin


Scott


On 10/16/2013 04:44 PM, Frank Hughes wrote:

Hi,

What NTP REFCLOCK can be used for a Jackson Fury?

I know that the Jackson Fury docs suggest using:
http://www.realhamradio.com/gpscon-info.htm

But that means I would have to put up a windows server
to replace the FreeBSD ntpd server I built for use w/ the Trimble TB.

Looking for open source options, if possible.

Thanks,
Frank
KJ4OLL
___
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] X72 Rb units, any experience ?

[Scott Mace]

I experimented with one of the older, used Datum X72 units.  It's nice,
low power, but was unusable with the Jackson Labs Fury I was using to
discipline it.  The EFC was very sensitive as compared to the LPRO, and
it would jump 10-20ns randomly (both directions).  I'm not sure if the
unit was just defective, or there were other issues at hand.
This unit did not include the firmware bits to enable the 1-PPS input.
Newer Datum and Symmetricom units apparently do.

Scott

On 08/22/2011 08:35 AM, Poul-Henning Kamp wrote:


I'm in the market for a new Rb for general use, and noticed that we have
heard surprising little about the X72 on the list ?

Anybody got any experience to share ?



___
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] basic question on GPS satellites

[Scott Mace]

What type of coax are you using and how long is the run?

I live in the woods and my antenna is partially blocked by
trees to the north and east and have never had problems.  I have about
130ft of LMR-400 between my antenna and splitter.

Scott

On 05/15/2011 05:30 PM, W2HX wrote:

Hi there. Recently acquired my first GPSDO. It is a datum 9390 (thank you,
Norm!).  One aspect of its behavior seems strange to me.  Within a matter of
a few minutes, it seems that satellites are appearing and disappearing.  Are
the satellites moving that quickly?  I might go from 1SV to 3SV or 4SV and
then a minute later go to 1SV or none.  The antenna isn't moving and the
trees aren't moving too much today.  I have not done anything with regard to
setting minimum elevation or any other parameters.  I did go through the
COLD RESTART procedure to clear out everything and let it start from
scratch.



Do other GPSDO users experience something like this?

73 Eugene W2HX



___
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] Oncore VP 1PPS change

[Scott Mace]

Has anyone noticed an improvement in the 1-PPS output from their
oncore VP receivers since about Jan9 2011?  I have a couple of Z3801A
that both are now seeing +-15ns with a few outliers.  Previously,
they were mostly +-50ns (as collected with gpscon).

I see no changes with my Fury that is connected to the same 
antenna/splitter.  It is always reporting within max +-10ns,

usually within +-5ns.

This seems to coincide with the GPS ground segment upgrade that was
reported to be completed in early Jan?

Scott

___
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] What's the lifetime for a HP Z3801a?

[Scott Mace]

I've got one that's at 16061, and runs very well, Predict values hover 
in the 300-800ns range.


On my other z3801a, it's a bit longer and 19034, but Predict values are 
usually 5-10us.


Scott

On 08/28/2010 06:31 PM, Bill Hawkins wrote:

Have a pair of Z3801a receivers and GPSCon. The running time
readout for both is greater than 16,000. They were around 5,000
when I got them from somewhere south of here.

What kind of numbers do you have?

Bill Hawkins


___
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] Fury - Rubidium

[Scott Mace]

Recovery from holdover was fine as well.

Scott

On 07/28/2010 11:21 PM, saidj...@aol.com wrote:

That's an average accuracy of 6.6E-013 over 19 hours.

Impressive.

bye,
Said


In a message dated 7/28/2010 18:21:12 Pacific Daylight Time, sm...@intt.net
  writes:

After  about 19hours of holdover, only ~45ns.  Now let's see how well it
recovers.

Scott

On 07/28/2010 01:02 AM,  saidj...@aol.com wrote:

Hi Scott,

a cool thing to try  is to put the unit into manual holdover by issuing

the

  command

 sync:holdover:init

  The unit will act as if the GPS antenna has been removed, but GPSCon

will

continue to show the 1PPS phase drift against GPS. Thus you can  see how
stable  your LPRO is over time when the unit is in  holdover.

You can restart normal locking with the  command

  sync:holdover:rec:init

On a good DOCXO, we would see less than  2000ns drift over a day when the
unit has been stable for a week or  so. I believe the limits of the time
interval  display are about  +/- 2000ns.

bye,
  Said


___
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] Fury - Rubidium

[Scott Mace]

After about 19hours of holdover, only ~45ns.  Now let's see how well it 
recovers.


Scott

On 07/28/2010 01:02 AM, saidj...@aol.com wrote:

Hi Scott,

a cool thing to try is to put the unit into manual holdover by issuing  the
command

sync:holdover:init

The unit will act as if the GPS antenna has been removed, but GPSCon will
continue to show the 1PPS phase drift against GPS. Thus you can see how
stable  your LPRO is over time when the unit is in holdover.

You can restart normal locking with the command

sync:holdover:rec:init

On a good DOCXO, we would see less than 2000ns drift over a day when the
unit has been stable for a week or so. I believe the limits of the time
interval  display are about +/- 2000ns.

bye,
Said


In a message dated 7/27/2010 08:42:01 Pacific Daylight Time, sm...@intt.net
  writes:

I test  it by changing the antenna delay.  It should recover within a
reasonable time.  Bumping the coarsedac is typically too much change  and
takes longer to recover.  I run it with a 20ns offset to my  z3801a, and
they always stay within 20ns of other.

I've had the  Fury running for about 5400 hours since the last reboot,
running v1.21  firmware.  It stays within +-10ns,  usually it's between
+-5ns.  Over 24hrs, gpscon reports TI average 0.15 or so and stddev
around 2.5ns.
___
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] Fury - Rubidium - PIS

[Scott Mace]

I found that on the FRS-C and the X72 the frequency output was not at 
all linear with respect to EFC, which made things worse with large 
dacgains.  After _MANY_ hours of watching and playing with different 
settings, I came to the conclusion that you just need to be patient when 
using Fury+Rb, don't expect it to converge like an OCXO, but it will 
over a few hours and give you a good result as long as you have stable 
power and shield it from air streams.  High dacgain and efcs give you 
the false hope that it will converge fast, but as the unit settles the 
loop will fail, and it will start fighting with itself.


The SYNC:IMME can be useful when trying different loop settings.


I found some of my notes for various things I ran with the Fury.

LPRO-101 currently running
COARSE DAC: 55
DAC GAIN: 1000
EFC SCALE: 1.30
OCXO SLOPE: POSITIVE
temp co: 0.00
aging co: -0.00558
phase co: 35

lpro orig
lpro cd 92
dac gain 1000
efc scale 1.30
efc damping 2
efc slope pos
phase co 30

lpro 2
coarse dac 95
dac gain 1300
efcs 1.30
efcdamping 5
ocxo slope pos
agin comp 0.05333
phaseco 35


datum ocxo #1 (From RFG-XO)
coarse dac 64
dac gain 80
efcs 4
efcdamping 10
ocxo slope pos
agin comp 0.27086
phaseco 35

datum ocxo #2
coarse dac 64
dac gain 100
efcs 2.8
efcdamping 10
ocxo slope pos
agin comp 0.14901
phaseco 35

datum ocxo #2 from RFG-XO In an RFG chassis
cd 69
dg 30.00
efcs 12.00
efcd 5
ocxo slope pos
aging comp -0.06559
phaseco 40
tempco was a major issue with the datum ocxo
keeping it in the RFG-XO chassis helped


Efratom FRS-A
DAC GAIN: 5000.00
EFC SCALE: 0.50
EFC DAMPING: 25
OCXO SLOPE: POSITIVE
PHASE CORRECTION: 0.50
TTL output, pad to below +13dBm, FRS-A needs to settle, open bench
air current problems.

FRS-A #2
dac gain: 4000
efcs: 1.2
efcdamping: 25
phaseco: 15
hard time recovering, from coarsedac bumps

X72
dac gain: 2000
efcs 1.2
efcdamping 25
phaseco: 15
jumps, tempco issues.

Scott

On 07/27/2010 09:16 PM, saidj...@aol.com wrote:

Hi John, Brian,

actually we set D to 0, and use P and I gains.

Yes, the DACGAIN is an overall gain of the loop output - to normalize for
different oscillator voltage/frequency sensitivities.

I forgot that the DACGAIN is limited to 10,000, so instead of setting it to
  20,000 one can set it to 10,000 and multiply the P and I parts both by 2x,
that  gives pretty much the same effect as setting DACGAIN to 20,000.

Please note that aging and tempco compensation may then take a couple of
days to fully settle again.

I have not tried such high gains since we don't have any oscillators  here
with such small F/V range, please advise what you find out.

bye,
Said


In a message dated 7/27/2010 19:04:36 Pacific Daylight Time, j...@quik.com
writes:


  That part I understand (your drawing), its a basic phase lock loop.
  What I am having trouble with is the Fury's commands relationship.


OK.  Sorry for the BW.

Basically you tune a loop by starting with the P, I,  and D set to zero.
You slowly crank up the P until it starts to become  unstable. (Put in a
small step perturbation and look at the response for  ringing) Then crank
up the D until it stabilizes, then crank up the P  again. When you have got
a stable fairly well performing loop, you  introduce some I. You may have
to tweek P and D to keep  stability.

It looks like your system has an overall gain (DACG) and a P  and D
controller gain. This is not uncommon to avoid switching a bunch of  caps.

___
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] Fury - Rubidium

[Scott Mace]

Any particular thermistor you would recommend?

Scott

On 07/27/2010 09:07 PM, saidj...@aol.com wrote:

Hi Scott,

yes the pads are there, you can use the through-hole pad right next to C67
and a standard ground pad for the Thermistor. There will be 10.5V across
the thermistor. Connect the thermistor to your Rb case.

You should be able to connect two 10K Thermistors in parallel to get a good
  reading without excessive self-heating of the thermistors, while
generating  enough current through them that can be measured by the ADC.

You can check the thermistor current using the meas? command. If the
thermistor is not drawing enough current for the ADC, then simply place a 2.2K
resistor in parallel to it.

The software needs to be enabled to support measuring and applying a tempco
  correction, by default I think the boards were shipped with only aging
compensation enabled.

Us the following command to enable tempco correction:

serv:tas 2,288,600,50,0.05

Check the settings with:

serv:tas?

The first number is the mode (0 is all off, 1 is aging only, 2 is aging and
  tempco correction). The second number is the memory usage, 288 points in
this  case. The third number is the sensing frequency in seconds, so 10
minute  intervals in this example. 288 points * 10 minutes is 48 hours of 
memory.
The  fourth number is the maximum phase offset allowed for a sense point,
in this  case +/-50ns. The last item is the required frequency error
estimate for a sense point, in this case +/-0.05ppb.

bye,
Said




In a message dated 7/27/2010 17:07:31 Pacific Daylight Time, sm...@intt.net
  writes:

Said,  Did the OEM units (from way back) ship with an open pad for  the
thermistor?  I thought that wouldn't work unless it was drawing  oven
current from the Fury.  It would be neat to add some tempco into  the mix
instead of just trying to shield it from HVAC cycling.  The  particular
LPRO-101 that I'm using now, doesn't seem to be as sensitive as  others
to temp.  I was using a different LPRO originally and when I  plotted the
Fury board temp sensor with GPSCON you could see the impact of  the
cycling, now with this one you would be hard pressed to pick it out.
The X72 was very sensitive to temp changes, EFC tracked the temp quite
well.


Scott
___
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] Fury - Rubidium

[Scott Mace]

Said,  Did the OEM units (from way back) ship with an open pad for the 
thermistor?  I thought that wouldn't work unless it was drawing oven 
current from the Fury.  It would be neat to add some tempco into the mix 
instead of just trying to shield it from HVAC cycling.  The particular 
LPRO-101 that I'm using now, doesn't seem to be as sensitive as others 
to temp.  I was using a different LPRO originally and when I plotted the 
Fury board temp sensor with GPSCON you could see the impact of the 
cycling, now with this one you would be hard pressed to pick it out. 
The X72 was very sensitive to temp changes, EFC tracked the temp quite well.



Scott

On 07/27/2010 02:57 PM, saidj...@aol.com wrote:

Hi guys,

it may help to increase DAC gain to get faster recovery times from "bumps"
etc.

On an OCXO, the frequency recovery from an upset should happen within a
couple of minutes, definitely less than 15 minutes to achieve frequency  lock.

The phase recovery (to 0ns offset) may take a couple of hours to do.

If it takes a very long time to recover, then I think increasing the DAC
gain, or alternatively the EFCS and PHASECO together may help.

Wikipedia has some good instructions on how to optimize PID type controller
  gains to get the fastest response with minimal noise...

Also, please make sure to disable temperature compensation when using the
external source, unless a thermistor is connected to the board, sensing the
Rb  temperature. Otherwise the temperature compensation may add noise due to
it  scaling the gain to huge values due to the missing thermistor.

bye,
Said


In a message dated 7/27/2010 09:58:41 Pacific Daylight Time,
true-...@swbell.net writes:

My  experience is very similar to Scott's. I ran many hours with both an
LPRO-101
and FE-5680A. The disciplining behavior and Fury settings  were the same
for
either Rb. My biggest disappointment was the  recovery time due to various
common
or intentional bumps or especially,  after power loss. I also had to let
the
"system" settle in for a week  before acceptable tracking smoothed out. Any
long
term slope to  the EFC trace (gpscon) caused excessive hunting and this
didn't
settle down until the Rb was VERY stable. My gpscon TI and stddev  was
virtually
the same as Scott's if I had EFCS set to 1.0 to 1.5 but  recovery was
unacceptable (maybe 24-hours) so I usually ran at 2.0 or 3.0  with
slight degrading of stddev to around 3.2. This EFCS setting  allowed a much
better settling time around 3-hours.

DACG=  1000
EFCS = 2 to 3
EFCD = 50 (25 allows little better settling  time)
PHASECO = 15 (I favor 10 Mhz over  PPS)
Regards...
Don


___
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] Fury - Rubidium

[Scott Mace]

I have done this with several LPRO-101, X72, and a FRS-C.  The FRS-C 
that I used was out of a Lucent RFG-RB box.  It had a hot TTL output 
that was causing issues with the Fury,  The level was the problem, not 
the ttl.  The EFC was hypersensitive, and it took a long time for the 
unit to settle down before the Fury would handle it.  Same thing with 
the LPRO, and X72, you have to wait for it settle for a week or so 
before it starts to work well if it's been off for a long time.  The X72 
was by far the worst, and it would jump from time to time, which would 
make the fury unhappy.  I didn't have a chassis that would fit the FRS-C 
and the fury, so I just went back to the LPRO.  The lpro-101 has been 
the best so far.  I put everything in a 1U chassis and placed it in the 
bottom of my rack away from the AC vent.


This is what I use with the LPRO-101.

dac gain: 1000
efc scale: 1.30
efc damping: 35
ocxo slope: positive
phaseco: 35

I test it by changing the antenna delay.  It should recover within a 
reasonable time.  Bumping the coarsedac is typically too much change and 
takes longer to recover.  I run it with a 20ns offset to my z3801a, and 
they always stay within 20ns of other.


I've had the Fury running for about 5400 hours since the last reboot, 
running v1.21 firmware.  It stays within +-10ns,  usually it's between 
+-5ns.  Over 24hrs, gpscon reports TI average 0.15 or so and stddev 
around 2.5ns.


Scott

On 7/27/2010 9:07 AM, Brian Kirby wrote:

Has anybody on the list interfaced a Fury GPS controller to a rubidium ?

If you have, please advise the rubidium are using and your SERV:DACG ,
SERV:EFCS , and SERV:EFCD settings.

I am working with a FRS-C at the moment and I have not found the right
combination to get a stable lock.

Thanks - Brian KD4FM

___
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] Training period for a Rb clock using GPS

[Scott Mace]

I should have said, we give it a 24hr time period to settle regardless 
of the time constant.


Scott

On 06/03/2010 12:23 PM, Scott Mace wrote:

We have noticed two things with the PRS10s and other Rbs.  They need
about 24hrs to settle before they really start to perform well and if
there are any significant temperature swings, expect them to react to
it. We have a PRS10 in a Meinberg M900 that takes about 1 day to recover
from 2-3C temp swing in a datacenter. It will be off (as compared to the
other 1-PPS that are not in that room) by about 50-100ns. Normally it's
within +-10ns when compared to the other GPSDOs. We noticed this
happened when the air-handlers would alternate on about a 2-week cycle.

Scott

On 06/03/2010 12:09 PM, Abhay Parekh wrote:

Awesome. Thanks so much!
=Abhay


On Thu, Jun 3, 2010 at 10:07 AM, Bob Camp wrote:


Hi

Your loop for 10 hours would be around 1 or 2 hours. That's 60 X 60 X
(1 or
2) seconds = 3,600 to 7,200 seconds. If GPS is "good" to +/- 20 ns
out of
your receiver in your location then you would get 20 x 10^-9 / (3600 or
7200) = 2.7 to 5.5 X 10^-12 inside the loop. The Rb should be below that
level over the same time period.

Simple answer - yes it should be good enough.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Abhay Parekh
Sent: Thursday, June 03, 2010 12:46 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Training period for a Rb clock using GPS

Yes, that makes sense.
I think that we can arrange things so that we train for 10-12 hours.
Do you not think that that is a long enough time for
a single loop to be effective?
Thanks again!
=Abhay


On Thu, Jun 3, 2010 at 9:37 AM, Bob Camp wrote:


Hi

That will give you the "best" answer with a simple loop. The problem is
that
"best" may not be good enough to actually get your Rb on time / on
frequency. Something more sophisticated than a simple loop may be
needed.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Abhay Parekh
Sent: Thursday, June 03, 2010 12:28 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Training period for a Rb clock using GPS

Ok, great. So if we can train for h hours we should set the time
constant
somewhere between
h/10 and h/5. It would be safer to pick something closer to h/10 since

when

the clock powers up
it might "start" in the wrong place so a smaller value helps the clock

move

quickly into
the right area, but h/5 will act as a better buffer against hanging
bridges.
Is my reasoning correct?
Thanks
=Abhay


On Thu, Jun 3, 2010 at 9:07 AM, Bob Camp wrote:


Hi

If you have an 18 hour time constant you would need a training period

of

5

to 10 X 18 hours to get the system to settle.

For a one hour training period the time constant should be in the 5 to

10

minute range.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com]

On

Behalf Of Abhay Parekh
Sent: Thursday, June 03, 2010 12:02 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Training period for a Rb clock using GPS

Hi Hal,
Thanks so much for the detailed post. I have a follow up question:
What

is

the relationship between
the training time and the appropriate value of the time constant

(currently

set at 18 hours)? The time constant isn't the size of
a moving average window is it?
Thanks again for your help. We are a bit clueless here but trying to
learn...
=Abhay


On Wed, Jun 2, 2010 at 2:02 AM, Hal Murray
wrote:



par...@berkeley.edu said:

I am a newbie at this, but have been playing around with 2 prs10s.

For

our

application we need to run the clocks without gps, but we do get to

sync

it

to gps *initially* for as long as we want. However, what we've

noticed

is

that when we train it for short periods of time (< 1 hour a day)

the

clock

drifts for a few microseconds a day once we've disconnected gps,

but

when

we

train it for say 12 hours, its drift seems to be much less (sub sub
microsecond/day). We were wondering why this should be so!


Look at it the other way. How long should it take to train it?

Let's use rough numbers.
There are 1E5 seconds per day.
Your "few" microseconds is 1E-6 seconds.
That's an accuracy of 1 part in 1E11.
Your "sub-sub" is 1/10 microsecond or 1E-7 seconds.
So that's an accuracy of 1 part in 1E12.

The data sheet says:
Aging (after 30 days)<5E-11 (monthly)
5E-11 is 50E-12, so that's 2E-12 per day which is what you saw.

The data sheet also says:
The PRS10 can time-tag an external 1 pps input
with 1 ns resolution. These values may be reported
back via RS-232, or used to phase-lock the unit to an
external reference (such as GPS) with time constants
of several hours.

There a

Re: [time-nuts] Training period for a Rb clock using GPS

[Scott Mace]

We have noticed two things with the PRS10s and other Rbs.  They need 
about 24hrs to settle before they really start to perform well and if 
there are any significant temperature swings, expect them to react to 
it.  We have a PRS10 in a Meinberg M900 that takes about 1 day to 
recover from 2-3C temp swing in a datacenter.  It will be off (as 
compared to the other 1-PPS that are not in that room) by about 
50-100ns.  Normally it's within +-10ns when compared to the other 
GPSDOs.  We noticed this happened when the air-handlers would alternate 
on about a 2-week cycle.


Scott

On 06/03/2010 12:09 PM, Abhay Parekh wrote:

Awesome. Thanks so much!
=Abhay


On Thu, Jun 3, 2010 at 10:07 AM, Bob Camp  wrote:


Hi

Your loop for 10 hours would be around 1 or 2 hours. That's 60 X 60 X (1 or
2) seconds = 3,600 to 7,200 seconds. If GPS is "good" to +/- 20 ns out of
your receiver in your location then you would get 20 x 10^-9 / (3600 or
7200) = 2.7 to 5.5 X 10^-12 inside the loop. The Rb should be below that
level over the same time period.

Simple answer - yes it should be good enough.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Abhay Parekh
Sent: Thursday, June 03, 2010 12:46 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Training period for a Rb clock using GPS

Yes, that makes sense.
I think that we can arrange things so that we train for 10-12 hours.
Do you not think that that is a long enough time for
a single loop to be effective?
Thanks again!
=Abhay


On Thu, Jun 3, 2010 at 9:37 AM, Bob Camp  wrote:


Hi

That will give you the "best" answer with a simple loop. The problem is
that
"best" may not be good enough to actually get your Rb on time / on
frequency. Something more sophisticated than a simple loop may be needed.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Abhay Parekh
Sent: Thursday, June 03, 2010 12:28 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Training period for a Rb clock using GPS

Ok, great. So if we can train for h hours we should set the time constant
somewhere between
h/10 and h/5. It would be safer to pick something closer to h/10 since

when

the clock powers up
it might "start" in the wrong place so a smaller value helps the clock

move

quickly into
the right area, but h/5 will act as a better buffer against hanging
bridges.
Is my reasoning correct?
Thanks
=Abhay


On Thu, Jun 3, 2010 at 9:07 AM, Bob Camp  wrote:


Hi

If you have an 18 hour time constant you would need a training period

of

5

to 10 X 18 hours to get the system to settle.

For a one hour training period the time constant should be in the 5 to

10

minute range.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com]

On

Behalf Of Abhay Parekh
Sent: Thursday, June 03, 2010 12:02 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Training period for a Rb clock using GPS

Hi Hal,
Thanks so much for the detailed post. I have a follow up question: What

is

the relationship between
the training time and the appropriate value of the time constant

(currently

set at 18 hours)? The time constant isn't the size of
a moving average window is it?
Thanks again for your help. We are a bit clueless here but trying to
learn...
=Abhay


On Wed, Jun 2, 2010 at 2:02 AM, Hal Murray
wrote:



par...@berkeley.edu said:

I am a newbie at this, but have been playing around with 2 prs10s.

For

our

application we need to run the clocks without gps, but we do get to

sync

it

to gps *initially* for as long as we want. However, what we've

noticed

is

that when we train it for short periods of time (<  1 hour a day)

the

clock

drifts for a few microseconds a day once we've disconnected gps,

but

when

we

train it for say 12 hours, its drift seems to be much less (sub sub
microsecond/day). We were wondering why this should be so!


Look at it the other way.  How long should it take to train it?

Let's use rough numbers.
  There are 1E5 seconds per day.
  Your "few" microseconds is 1E-6 seconds.
That's an accuracy of 1 part in 1E11.
  Your "sub-sub" is 1/10 microsecond or 1E-7 seconds.
So that's an accuracy of 1 part in 1E12.

The data sheet says:
  Aging (after 30 days)<5E-11 (monthly)
5E-11 is 50E-12, so that's 2E-12 per day which is what you saw.

The data sheet also says:
  The PRS10 can time-tag an external 1 pps input
  with 1 ns resolution. These values may be reported
  back via RS-232, or used to phase-lock the unit to an
  external reference (such as GPS) with time constants
  of several hours.

There are 4E3 seconds in an hour and 1E9 nanoseconds per second.  So

in

an

hour, you can get close to 1 part in 1E12.  But that's assuming that

the

input PPS signal is right-on.

There are two types of GPS receivers.  

Re: [time-nuts] Rack-mounting an LPRO?

[Scott Mace]

I have a Datum Rubidium Frequency Standard, which is a 1U aluminum 
chassis that is about 2mm thick.  It contains a LPRO and a 24V/5V power 
supply with room to spare.  I installed a Fury GPSDO and a small DC-DC 
converter in the same enclosure.  The top cover is vented.  The chassis 
stays slightly warm and the LPRO appears to work well even with moderate 
HVAC cycling (as long as the chassis is in the rack with the door closed).


Scott

On 02/27/2010 04:30 PM, Paul Boven wrote:

Dear time-nuts,

I've just bought a used LPRO-101 which should get a permanent home
inside an instrument rack. I've also found a very nice 1U high metal
case, and a fitting 24V 1U power supply - leaving plenty of room for a
distribution amp and a microcontroller to log things like lamp and Xtal
voltage.

The rackmount enclosure is 1U high, and seems to be made of 1mm thick
galvanized steel. Would that make a good enough baseplate for the LPRO?
Would I need to do anything to improve the thermal contact between the
rubidium oscillator and the baseplate, and if so, any recommendations on
what to use there? The LPRO "User's guide and integration guidelines"
recommend 2degC/W thermal resistance (for up to 50degC ambient), and
using some special thermal tape that will probably be very hard to get
at these days. If any of you has already put something like this
together, I'd be very interested in your suggestions.

Regards, Paul Boven - PE1NUT

___
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] Chooses for a desktop/server NTP external 1PPS reference

[Scott Mace]

On 12/07/2009 04:13 PM, Alexander Sack wrote:

Hi Everybody:

First post, be gentle.  I did some mail-list archive searching and it seems
that a lot of folks have used the Garmin 18x LVC as their 1PPS sync for the
desktop with varied success (5V via USB port and RS-232 for 1PPS?).  At
work, I have experience with an Endrun Cf/Ct receiver connected to a small
CDMA antennae (as well as GPS receiver) which works pretty well (I suppose
its more relative to my crappy motherboard oscillator than anything).  I
have no idea how much they run (I think the CDMA one was like $200 and
something).

What are my options in this realm?  Surprisingly enough, Googling for over
an hour didn't yield much results.  There are tons of companies that offer
various solutions but with little pricing information.  I'd be happy to hear
some suggestions OTHER THAN the Garmin 18x LVC?

(btw is there such a thing as a desktop rubidium atomic clock with 1 PPS?)

Thanks!

-aps
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.




I'm using soekris net4501s that I modified with phk's TMR1IN hack and 
running nanobsd 7.2.  One is fed with a trimble thunderbolt,  one with a 
z3801a, and another with either a Fury (which is usually running with a 
LPRO-101 Rb unit) or whatever I happen to be experimenting with at the time.


There is a write up here:

http://www.febo.com/pages/soekris/

I did mine similar to this except, I used a mini-din for the second 
serial instead of the d-sub, external sma connectors for 10MHz and 1-PPS 
inputs, and built the clock synthesizer and pulse stretcher on 'surf 
board' prototype PCBs.


Scott

___
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] Oncore glitch?

[Scott Mace]

I noticed a glitch at about 0100Z on 11/5/09 with a Fury.  Unit has been 
tracking within +-10ns for many months, and then suddenly jumped to 
-40ns or so and recovered.  Not sure if it lost lock or was in holdover. 
 I wasn't monitoring it with GPScon prior to the event (I had rebooted 
the vm that it was running on and forgot to restart GPScon).  By 
happenstance I restart it and noticed the large TI error.  There was 
also some noise on outa...@outages.org about GPS errors around the same 
time.


Scott

On 11/10/2009 1:28 PM, Tom Van Baak wrote:

I've been asked if anyone noticed an iLotus / Motorola Oncore
or M12 GPS receiver glitch a week ago (Wednesday 5 Nov at
about 1900Z)?

(no need to reply if your GPS receivers kept ticking; I'm just
looking here for reports of any signal or tracking anomaly at
the time in question)

Thanks,
/tvb


___
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] Stable Z38XX

[Scott Mace]

Ulrich,  I'm trying to run this against a Fury and z38xx doesn't seem to 
keep the 115200 baud setting,  it just changes back to 57600.


Scott


On 07/11/2009 02:47 AM, Ulrich Bangert wrote:

Hi Said,

not necessary to supply you with a list: Just start the software and open
the debug window. You will see all serial communication action. With no
device connected just the commands will appeear one below the other. You can
use the "window hold" option of the debug window to defeat the scrolling.

There is also a second option: If you supply ME a list of commands that your
devices understand then I can detect the device type by the answer to *IDN?
and ask the devices just what they understand and leave everything else out.
That is the stategy that the software already uses to cover the Z3801/5/15
and the GCRU.

Best regards
Ulrich


-Ursprungliche Nachricht-
Von: time-nuts-boun...@febo.com
[mailto:time-nuts-boun...@febo.com] Im Auftrag von saidj...@aol.com
Gesendet: Freitag, 10. Juli 2009 20:23
An: time-nuts@febo.com
Betreff: Re: [time-nuts] Stable Z38XX


Hi Ulrich,

any chance you could send me a list of commands you utility
uses as a
minimum command-set so I can cross-check against our
Fury/FireFly  GPSDO's?

There are lots of folks on this list that have our units, and
it would be
great if we could get it up and running for our interface as
an alternative
to  GPSCon.

Thanks,
Said


In a message dated 7/10/2009 07:17:31 Pacific Daylight Time,
df...@ulrich-bangert.de writes:

Guys,

after a lot of help coming from Australia (thank you Hal  and
Kit) there is
a
stable version of my Z38XX utility available. It  handles the
Z3801, the Z3805, the Z3815 and the GCRU.

It is  available from the usual place. Enjoy!

Ulrich  Bangert
www.ulrich-bangert.de
Ortholzer Weg 1
27243 Gross Ippener


___
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 gpsd > ntpd failure.

[Scott Mace]

I think it's 4.2.4p6 or somewhere around that.  I'll have to check that 
out.  All my ntp servers use the PPS refclock, so as long as SHM, HPGPS, 
and Fury are reasonable, then no clock hopping.  I haven't made any 
progress merging the HPGPS and Fury drivers, but I am working on getting 
machine readable clockstats instead of the status? output for the HPGPS 
driver.  Also, I'm working on getting the time-nut data out of the 
thunderbolt through gpsd to ntpd and log in clockstats (dac voltage, 
temp, offsets, etc).  Hopefully sometime this summer.


Scott



On 04/30/2009 09:54 PM, Hal Murray wrote:

server 127.127.22.0 minpoll 4 maxpoll 4


How old is your ntpd?

The old SHM driver used to grab one sample each polling period.  I fixed it
to grab 1 per second.  I also added some statistics.In my testing, it
helped a lot.

It went into ntp-dev last Nov.  Harlan is close to releasing an updated
version of ntp-stable.  If that's what you use, best to wait a few days.



___
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 gpsd > ntpd failure.

[Scott Mace]

Here's the patch to make the thunderbolt work with gpsd and ntpd and 
support leap seconds.  The diff is based on the gpsd trunk from around 
8/08 (after my initial patch was already committed by Chris).


http://www.intt.net/time-nuts/gpsd_tbolt.diff

Scott




___
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 gpsd > ntpd failure.

[Scott Mace]

Here is what I did to get it to work:

http://www.febo.com/pipermail/time-nuts/2008-August/032726.html
http://www.febo.com/pipermail/time-nuts/2008-August/033106.html
http://www.febo.com/pipermail/time-nuts/2008-August/032803.html

I have a better patch for leap seconds that actually works correctly but 
have not had a chance to post it yet.


You need to make sure your kernel has the sysvshm option:
options SYSVSHM # SYSV-style shared memory

then finally make sure that ntpd was compiled to support the SHM refclock.

I have a couple of thunderbolts working with net4501s using the TMR1IN
mod:  http://www.febo.com/pages/soekris/

I used a TAPR fatpps to stretch the pulse so the net4501 would be happy.

I start gpsd before ntpd

ntp.conf has:
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 -0.017 refid GPS

server 127.127.22.0 minpoll 4 maxpoll 4

tos mindist 0.050


Scott

On 04/30/2009 08:50 PM, John Murphy wrote:

I'm trying to configure ntpd (4.2.4p5-a FreeBSD-7.1) to use the
shared memory driver to which gpsd should be writing timestamps.
All looks good on the gpsd side, after building it for 8N1, as
I can see what looks like ntpshm writing to shared memory:

gpsd: TSIP pkt_id = 0x41, packetlen= 14
gpsd: TSIP packet id 0x41 length 10: 48cf974905f94170
gpsd: ntpshm_put: Clock: 1241129131 @ 1241129132.166348
gpsd: GPS Time 425146.281250 1529 15.00

But, with ntp.conf entries like:

tos mindist 0.010
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.420 refid GPS
server 127.127.22.0 minpoll 4 maxpoll 4

The log shows:

ntpd 4.2.4p5-a Thu Jan  1 09:59:32 UTC 2009 (1)
refclock_newpeer: clock type 28 invalid
configuration of 127.127.28.0 failed

I'm also using the PPS output of the Thunderbolt, hence the
127.127.22.0 entry, and the 10MHz up converted to 33.33MHz
for the soekris net4501 CPU clock. Both of those working well.

Do I need to initiate the shared memory some how? I feel I may
have missed something vital, which may be obvious to someone.



___
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] LPRO-101

[Scott Mace]

I've seen Datum clocks of various sorts with these just mounted to the 
chassis, no special heatsink, especially the 1RU units.

Scott

On 01/11/2009 10:13 PM, Glenn Little WB4UIV wrote:
> I have a LPRO-101. Before I power it up, I have been advised to use a 
> heatsink.
> How large of a heatsink do I need?
> I found an extruded heatsink in the junk box.
> This heatsink has fins about 0.50 inches high.
> The width is 2.375 inches wide.
> It is 8.125 inches long.
> I plan to cut this heatsink in half giving me two 4.0 inch pieced.
> I plan to bolt each piece to the bottom of the LPRO-101, using the
> six mounting holes, three per heatsink.
> Would this be sufficient heatsink?
>
> Thanks in advance.
> 73
> Glenn
> WB4UIV
>
>
>
> ___
> 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] Early leap second data

[Scott Mace]

Both my Fury (time-a) and z3801a (time-b) handled it correctly


  remote   refid  st t when poll reach   delay   offset 
  jitter
==
  clepsydra.dec.c .GPS.1 u  248 1024  377   48.794  1000.24 
1000.04
+time-a.intt.org .PPS.1 u  195 1024  3779.0080.161 
  0.009
*time-b.intt.org .PPS.1 u  298 1024  3772.6810.790 
  0.697
*tick.uh.edu .GPS.1 u  869 1024  3771.268   -2.133 
  0.033
  tock.usno.navy. 85.83.78.79  2 u  699 1024  377   54.801  1003.98 
999.849
+time.nist.gov   .ACTS.   1 u  326 1024  263   47.1222.865 
  0.391

Scott

___
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] 10 MHz over optical fiber?

[Scott Mace]

 From the corning leaf spec:

Environmental Test Induced Attenuation
Condition (dB/km)
1550 nm /1625 nm
Temperature Dependence
-60°C to +85°C* ? 0.05
Temperature – Humidity Cycling
-10°C to +85°C* and up to
98% RH ? 0.05
Water Immersion, +23°C ? 0.05
Heat Aging, +85°C* ? 0.05
*Reference Temperature = +23°C
Operating Temperature Range: -60°C to +85°

I just checked the daily variation of optical loss, and it seems to be about 
+-0.15dB
over a 90km DWDM system that operates in the NY,NJ metro area.  It's slightly 
larger
from summer to winter.  Clearly measuring delay through a loop would be a more 
accurate
metric, but this should give you a ballpark of real-world environmental 
influence.  All
of the electronics are in cooled rooms (typical CO or datacenter), all the 
fiber was
buried and in building risers.

And don't forget about back-hoe induced phase shifts.

Scott


Bruce Griffiths wrote:
> Scott Mace wrote:
>> I think for singlemode LEAF fiber you see something around 100ps/km per 
>> degree C.
>> Hopefully the fiber is buried and the temperature changes are more gradual.
>>
>>  Scott
>>   
> Most of it may be buried, however the ends of the fiber run may not be.
> There are expensive fibers available with much smaller tempcos, at least
> over limited temperature ranges.
> The thermal expansion tempco of fused silica fibers is relatively low
> (0.5ppm/C or so depending on exact composition) so most of the
> propagation delay tempco is due to the refractive index tempco.
> 
> Bruce
> 
> ___
> 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] 10 MHz over optical fiber?

[Scott Mace]

I think for singlemode LEAF fiber you see something around 100ps/km per degree 
C.
Hopefully the fiber is buried and the temperature changes are more gradual.

Scott




Bruce Griffiths wrote:
> Didier wrote:
>> If your concern is simply a stable frequency reference, that's true, even
>> though I am not sure what kind of cleanup oscillator would match the short
>> term stability of a maser. But also if you want to use it as a time
>> standard, the phase shift in the fiber has to be compensated, and it's
>> variations over temperature/humidity/gravity and whatnot must be accounted
>> for.
>>
>> This is time-nuts, we don't simply want to make things work, we want to make
>> them work good :-)
>>
>> Didier
>>
>>   
> Didier
> 
> A linear temperature ramp will create a linear ramp (equivalent to a
> frequency shift) in the fiber delay.
> Such temperature ramps may be expected at least twice a day. In other
> words the the rate of change of temperature needs to be low to preserve
> the frequency accuracy at the receive end of the fiber.
> 
> Bruce
> 
> ___
> 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] 10 MHz over optical fiber?

[Scott Mace]

In looking at the off-the-shelf boxes, jitter seemed to vary from ps range
to tens of ns.  Also, how stable is the 34km of fiber...  One of the
manufacturers I looked at had a 1550nm option, so it's probably not a stretch
to get it on a 100GHz ITU grid channel or other CWDM channel.

Scott

Paul Boven wrote:
> Hi everyone,
> 
> In message <[EMAIL PROTECTED]>, Marco IK1ODO -2
> writes:
>> Hi all,
>>
>> I have to carry a 10 MHz standard frequency signal inside an EMC 
>> screened room via fiber optic cable.
>>
>> Not willing to re-invent the wheel, do something like an optical 
>> standard frequency link exist on the market?
>> I think it is possible to use standard 100MB LAN transceivers, and 
>> POF. Phase noise requirements
>> are not very stringent, and the distance is in the order of some tens 
>> of meters.
> 
> I'm looking into something similar: transmitting an H-Maser signal
> (probably 10MHz) over some 34km using CWDM SFPs. At first glance this
> seems fairly uncomplicated: get some SFPs, and SFP connector + cage. Use
> a fast opamp/differential driver to drive the transmitting SFP, and use
> a similar setup at the other end to transform the received data back to
> 50 ohm unbalanced. How feasible would such a setup be?
> Possible problems might be that a 10MHz squarewave is simply too 'slow'
> to be transmitted by an SFP, which expects 1.25Gb/s 8/10 encoded data.
> Another interesting question would be how much jitter/noise such a setup
> would add?
> 
> Regards, Paul Boven.
> 
> ___
> 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] 10 MHz over optical fiber?

[Scott Mace]

I've used the ortel/emcore 5100 series for L-band IF links in places where the
distances and costs of running coax were too high.  Some of the products
launch hot as they were designed for passive/splitter based distribution
so you have to pad the optical rx.

Scott

Lux, James P wrote:
> We do lots of this sort of thing at JPL. But the high precision does come at 
> a cost..
> Here's a paper from Bob Tjoelker and colleagues..
> http://ipnpr.jpl.nasa.gov/progress_report/42-167/167C.pdf
> 
> There are various off the shelf products too, (you could buy a receiver and 
> transmitter module from Ortel, for instance)
> 
> James Lux, P.E.
> Task Manager, SOMD Software Defined Radios
> Flight Communications Systems Section
> Jet Propulsion Laboratory
> 4800 Oak Grove Drive, Mail Stop 161-213
> Pasadena, CA, 91109
> +1(818)354-2075 phone
> +1(818)393-6875 fax
> 
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Mace
>> Sent: Monday, November 24, 2008 8:37 AM
>> To: Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] 10 MHz over optical fiber?
>>
>> I'm looking for the same thing, but between buildings over
>> singlemode fiber.  I have not evaluated any of these but I've
>> been looking at:
>>
>> http://www.terahertztechnologies.com
>> http://www.highlandtechnology.com/
>> http://www.luxlink.com/
>>
>> Scott
>>
>> Marco IK1ODO -2 wrote:
> 
> ___
> 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] 10 MHz over optical fiber?

[Scott Mace]

I'm looking for the same thing, but between buildings over singlemode
fiber.  I have not evaluated any of these but I've been looking at:

http://www.terahertztechnologies.com
http://www.highlandtechnology.com/
http://www.luxlink.com/

Scott

Marco IK1ODO -2 wrote:
> Hi all,
> 
> I have to carry a 10 MHz standard frequency signal inside an EMC 
> screened room via fiber optic cable.
> 
> Not willing to re-invent the wheel, do something like an optical 
> standard frequency link exist on the market?
> I think it is possible to use standard 100MB LAN transceivers, and 
> POF. Phase noise requirements
> are not very stringent, and the distance is in the order of some tens 
> of meters.
> 
> Marco IK1ODO / AI4YF
> 
> 
> ___
> 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] The Trimble NTPX26AB-06 / Z3801A

[Scott Mace]

On the Z3801a, if you want to use the 1-PPS or 10MHz signals that are on the 
DB-25 you will need
to convert the PECL outputs.  I build a little converter based on the on-semi 
MC100ELT23 dual PECL
to TTL translator.  I also built a simple RS422 to RS232 converter using a 
DS275 and 75179
All of these were done on 16SOIC surfboards that fit inside a DB25-DB25 shell.

I wanted to keep my z3801a boxes completely unmodified.

Scott

Roy Phillips wrote:
> Dear Members
> 
> I have the Trimble NTPX26AB-06 and I have established that the I/O port (25 
> way D connector) has the same pin-outs as the Z3801A. Can any owners/users of 
> these units advise me on a suitable (proved to work) interface adaptor from 
> the RS-422  to RS-232. The unit works fine and is producing its 10 MHz output 
> with very good accuracy, but I am looking forward to "seeing it" through its 
> interface with TBolt Mon. 
> Thanks
> 
> Roy Phillips
> ___
> 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] Leap second glitches on NTP using Z3801A

[Scott Mace]

Here's the diff based on 4.2.4p4

--- ntp-4.2.4p4.orig/ntpd/refclock_hpgps.c  2006-06-06 15:16:51.0 
-0500
+++ ntp-4.2.4p4/ntpd/refclock_hpgps.c   2008-08-25 09:56:29.0 -0500
@@ -535,7 +535,8 @@
 switch (leapchar) {

 case '+':
-   pp->leap = LEAP_ADDSECOND;
+   if ((month == 6) || (month == 12))
+   pp->leap = LEAP_ADDSECOND;
 break;

 case '0':
@@ -543,7 +544,8 @@
 break;

 case '-':
-   pp->leap = LEAP_DELSECOND;
+   if ((month == 6) || (month == 12))
+   pp->leap = LEAP_DELSECOND;
 break;

 default:




Scott Mace wrote:
> Yes, I noticed this as well and modified the refclock driver to filter
> it as it does in the oncore refclock.
> 
>   Scott
> 
> Hal Murray wrote:
>> Is anybody running ntpd with their Z3801A?
>>
>> If so, please check your log files and tell me if you see a bogus leap 
>> second 
>> at the end of the past several months.  I've seen them for Aug, Sep, and 
>> Oct. 
>>  I think they are coming from my Z3801A, but it might be something else.
>>
>> The GPS satellites are now announcing a leap second that will happen at the 
>> end of the year.   The refclock driver passes that to ntpd and ntpd passes 
>> it 
>> to the kernel and magic happens.
>>
>> I think the refclock-ntpd interface assumes the leap second will happen at 
>> the end of the current month.  NIST only announces leap seconds a month 
>> ahead 
>> on WWVB and ACTS.
>>
>> The Oncore refclock driver has a filter to wait until the current month to 
>> pass the info to ntpd.  I'm working on something similar for the HP driver.
>>
> 
> ___
> 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] Leap second glitches on NTP using Z3801A

[Scott Mace]

Yes, I noticed this as well and modified the refclock driver to filter
it as it does in the oncore refclock.

Scott

Hal Murray wrote:
> Is anybody running ntpd with their Z3801A?
> 
> If so, please check your log files and tell me if you see a bogus leap second 
> at the end of the past several months.  I've seen them for Aug, Sep, and Oct. 
>  I think they are coming from my Z3801A, but it might be something else.
> 
> The GPS satellites are now announcing a leap second that will happen at the 
> end of the year.   The refclock driver passes that to ntpd and ntpd passes it 
> to the kernel and magic happens.
> 
> I think the refclock-ntpd interface assumes the leap second will happen at 
> the end of the current month.  NIST only announces leap seconds a month ahead 
> on WWVB and ACTS.
> 
> The Oncore refclock driver has a filter to wait until the current month to 
> pass the info to ntpd.  I'm working on something similar for the HP driver.
> 

___
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] Do any regulations or laws require t ime to be accurate within ‘x’ seconds?

[Scott Mace]

Google  "CALEA millisecond".

Scott

Gretchen Baxter wrote:
> Greetings,
> 
> There are a lot of regulations that mandate synchronized time.
> 
> But do any of these regulations or laws require time to be accurate within
> 'x' seconds?  Such as, 'time much be synchronized within 5 seconds of GPS
> time.
> 
> Thanx,
> 
> Gretchen
> ___
> 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] Getting NTP/Linux to work with GPS-DO?

[Scott Mace]

 	refclock_pcf.c refclock_pst.c refclock_ripencc.c refclock_shm.c \
--- ntp-4.2.4p4.orig/ntpd/ntp_control.c	2006-12-28 06:03:27.0 -0600
+++ ntp-4.2.4p4/ntpd/ntp_control.c	2008-07-06 17:33:28.0 -0500
@@ -406,6 +406,7 @@
 	CTL_SST_TS_UHF,		/* REFCLK_ZYFER (42) */
 	CTL_SST_TS_UHF,		/* REFCLK_RIPENCC (43) */
 	CTL_SST_TS_UHF,		/* REFCLK_NEOCLOCK4X (44) */
+	CTL_SST_TS_UHF,		/* REFCLK_FURY (45) */
 };
 
 
--- ntp-4.2.4p4.orig/ntpd/refclock_conf.c	2006-12-28 06:03:44.0 -0600
+++ ntp-4.2.4p4/ntpd/refclock_conf.c	2008-07-06 17:33:28.0 -0500
@@ -258,6 +258,12 @@
 #define	refclock_neoclock4x	refclock_none
 #endif
 
+#ifdef CLOCK_FURY
+extern	struct refclock	refclock_fury;
+#else
+#define	refclock_fury	refclock_none
+#endif
+
 /*
  * Order is clock_start(), clock_shutdown(), clock_poll(),
  * clock_control(), clock_init(), clock_buginfo, clock_flags;
@@ -309,7 +315,8 @@
 	&refclock_tt560,	/* 41 REFCLK_TT560 */
 	&refclock_zyfer,	/* 42 REFCLK_ZYFER */
 	&refclock_ripencc,	/* 43 REFCLK_RIPENCC */
-	&refclock_neoclock4x/* 44 REFCLK_NEOCLOCK4X */
+	&refclock_neoclock4x,   /* 44 REFCLK_NEOCLOCK4X */
+	&refclock_fury  /* 45 REFCLK_FURY */
 };
 
 u_char num_refclock_conf = sizeof(refclock_conf)/sizeof(struct refclock *);
--- ntp-4.2.4p4.orig/ntpd/refclock_fury.c	1969-12-31 18:00:00.0 -0600
+++ ntp-4.2.4p4/ntpd/refclock_fury.c	2008-08-23 20:46:08.0 -0500
@@ -0,0 +1,603 @@
+/*
+ * refclock_fury.c - clock driver for an FURY GPS CLOCK
+ *		Scott Mace 6/20/2008
+ *		 based on refclock_nmea.c
+ */
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#if defined(SYS_WINNT)
+#undef close
+#define close closesocket
+#endif
+
+#if defined(REFCLOCK) && defined(CLOCK_FURY)
+
+
+#include 
+#include 
+
+#include "ntpd.h"
+#include "ntp_io.h"
+#include "ntp_unixtime.h"
+#include "ntp_refclock.h"
+#include "ntp_stdlib.h"
+
+/*
+ * This driver supports the FURY GPS Receiver with
+ *
+ * Based on refclock_nmea.c, some code from reflock_hpgps.c
+ *
+ * The Fury supports a partial SCPI command set, which is useful
+ * for gather various health and performance stats
+ * The only on-time marker is the NMEA GPGGA sentence that is generated
+ * once per second when the Fury is placed in NMEA mode
+ *
+ * Other interesting data is collected from GPS?,SYNC?,DIAG?,and MEAS?
+ *
+ */
+
+/*
+ * Definitions
+ */
+#ifdef SYS_WINNT
+# define DEVICE "COM%d:" 	/* COM 1 - 3 supported */
+#else
+# define DEVICE	"/dev/gps%d"	/* name of radio device */
+#endif
+#define	SPEED232	B115200	/* uart speed (115200 bps) */
+#define	PRECISION	(-9)	/* precision assumed (about 2 ms) */
+#define	PPS_PRECISION	(-20)	/* precision assumed (about 1 us) */
+#define	REFID		"GPS\0"	/* reference id */
+#define	DESCRIPTION	"FURY GPS Clock" /* who we are */
+#define NANOSECOND	10 /* one second (ns) */
+#define RANGEGATE	50	/* range gate (ns) */
+
+#define LENNMEA		75	/* min timecode length */
+
+/*
+ * Tables to compute the ddd of year form icky dd/mm timecode. Viva la
+ * leap.
+ */
+static int day1tab[] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
+static int day2tab[] = {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
+
+/*
+ * Unit control structure
+ */
+struct furyunit {
+	int	pollcnt;	/* poll message counter */
+	int	polled;		/* Hand in a sample? */
+	l_fp	tstamp;		/* timestamp of last poll */
+	int	tscnt;
+	float	stat_efc;
+	unsigned long	stat_life;
+	int	stat_ppslock;
+	unsigned long	stat_holddur;
+	int	stat_holdover;
+	float	stat_fee;
+	float	stat_tint;
+	float	stat_temp;
+	float	stat_amp;
+	float	stat_volt;	
+	int	stat_track;
+	int	stat_vis;
+	int	stat_pulsestat;
+	int	stat_pulseacc;
+	int	stat_pulsesaw;
+	int	stat_leap;
+};
+
+/*
+ * Function prototypes
+ */
+static	int	fury_start	P((int, struct peer *));
+static	void	fury_shutdown	P((int, struct peer *));
+static	void	fury_receive	P((struct recvbuf *));
+static	void	fury_poll	P((int, struct peer *));
+static	void	gps_send	P((int, const char *, struct peer *));
+static	char	*field_parse	P((char *, int));
+
+/*
+ * Transfer vector
+ */
+struct	refclock refclock_fury = {
+	fury_start,		/* start up driver */
+	fury_shutdown,	/* shut down driver */
+	fury_poll,		/* transmit poll message */
+	noentry,		/* fudge control */
+	noentry,		/* initialize driver */
+	noentry,		/* buginfo */
+	NOFLAGS			/* not used */
+};
+
+/*
+ * fury_start - open the GPS devices and initialize data for processing
+ */
+static int
+fury_start(
+	int unit,
+	struct peer *peer
+	)
+{
+	register struct furyunit *up;
+	struct refclockproc *pp;
+	int fd;
+	char device[20];
+
+	/*
+	 * Open serial port. Use CLK line discipline, if available.
+	 */
+	(void)sprintf(device, DEVICE, unit);
+
+	fd = refclock_open(device, SPEED232, LDISC_CLK);
+	if (fd <= 0) {
+return (0);
+}
+
+	/*
+	 * Allocate and initialize unit structure
+	 */
+	up = (str

Re: [time-nuts] problem with Efratom FRS-C from eBay

[Scott Mace]

I have a FRS-A which is very similar to your unit, but with a LPRO compatible
pin-out.  This came out of a Lucent RFTG box.  It would take a long time to 
power
up, and I found that the power supply was no good.  I removed the unit and kept
it on a piece of the chassis as a heatsink and used a new 24v switcher.
This unit still takes longer than the 10min to lock, but once it locks it's 
solid.
The lock indication goes low when locked, high when unlocked.  It has a strong 
10mhz
TTL output.  You should attach some sort of heatsink to the baseplate.  The 
FRS-A
runs hotter than any of the LPRO units I have.  I've had good luck with the
Datum labeled LPRO-101 units.  What are you using the measure the frequency?
Sounds like your unit is locking if the BITE is low.  The usual thing that
kills these units isn't the lamp itself but noise from some other source in
the physics package.

I've purchased from this seller several times before and he replaced a bad
LPRO unit (powered up and locked for 1 hour then unlocked and never locked
again).  Usually, it is not practical to repair these units as most of the parts
cannot be swapped from unit to unit without changing some undocumented 
adjustments.

Scott


Robert Darlington wrote:
> Hello all,
> 
> My FRS-C showed up today.  I carefully wired it up and powered it on.  I got
> a nearly 10MHz signal out.  The frequency counter is dancing around a bit
> and I get a 0.02 V on the lock indicator line after about an hour warm up.
> Specs show this should happen in under 10 minutes and it looks like it is
> not locking.   Dead unit?
> 
> I obtained it from this ad:
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=290262243079
> 
> The unit that I received does not show TTL after the frequency and the scope
> output looks like a cross between a sinewave and a ringing square wave.  I
> have about 13 feet of RG174 between the FRS and the measurement equipment so
> who knows.   This is the "*Rubidium and GPS DO From
> China"
> *eBay store, which I thought was pretty reputable so I want to make sure I'm
> not doing anything wrong before I contact the seller, PayPal, etc.*  *There
> was also a big white sticker covering the whole top of the unit.  I had to
> remove it to verify the pinouts and the model information.  Hoepfully that
> didn't void my warranty on the $100 paperweight.  Should I let it sit
> overnight?  Any suggestions would greatly be appreciated.
> 
> Thanks,
> Bob, N3XKB
> ___
> 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] BC637PCI

[Scott Mace]

Nigel, thanks for the detailed response.  I noticed the password option in
the advanced menu as well.  I ran it overnight locked to a 1-PPS feed
and it seemed to stay witin +-200ns.  Not spectacular, but within
spec according to the older datasheets.  I am mainly interested in the card
as a timecode generator.  However it looks like it might be more convenient
to just feed the card an external 10mhz and not use the internal oscillator.
Also, the RTC battery is toast, so it looks like I'll be replacing that at
some point.

Scott

[EMAIL PROTECTED] wrote:
>  
> In a message dated 11/10/2008 05:12:11 GMT Daylight Time, [EMAIL PROTECTED]  
> writes:
> 
> Has  anyone "upgraded" the oscillator on an older Datum BC637PCI card to
> the MTI  crystal?  Is it as simple as changing the crystal and adjusting  the
> osc gain?
> 
> 
> 
> -
> PS
>  
> Should have added to my previous waffle, I think the answer to this is  
> yes:-)
> given the need to reset any changed values every time you power down and up  
> again.
>  
> regards
>  
> Nigel
> GM8PZR
> 
> 
> 
> **   
> ___
> 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] BC637PCI

[Scott Mace]

Has anyone "upgraded" the oscillator on an older Datum BC637PCI card to
the MTI crystal?  Is it as simple as changing the crystal and adjusting the
osc gain?

Scott

___
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] GPS, NTP, and Cisco routers...

[Scott Mace]

This runs on the aux port, and the sup720 doesn't have an aux port...
There are always obscure features that slip into the production releases
that aren't tested and they just forget to exclude them during builds.
TAC will probably have no clue about this...
You could try the cisco-nsp mailling list for support, but beware, it's
frequented by cisco developers that will just as soon open a bug-id to
drop 'feature' from the production release if it was never supposed to
be there in the first place.

I wonder if this was originally used as an alternative method to time
the MIX midplane in the VXR chassis and the NTP feature was side
benefit?  Most telecom gear that needs synchronization will take a
BITS input or some other frequency reference.  I've used that extensively
with SONET gear and the good old Datum OT-21.  I never used the
7200 MIX, so I'm not sure if it could take an external reference or
just recover clock from a DS1 port.

Seems like a good use for an AUX port if you don't need a modem or
reverse telnet!

Scott

Scott McGrath wrote:
> Actually you might get pretty good results if you have a 6509 as any
> activity on the serial port triggers a CPU interrupt which is why on a
> overloaded 6509 the first thing to try is "no logging console" to get
> the cpu down from 100% - usually in the context of DDoS and the
> control plane is slammed as the EOBC is only a 1 megabit channel even
> on the 3BXL's.This is one of the advantages of the annual trek out
> to Bldg 14 in San Jose - one gets to meet the guys who developed the
> code for the routers.
> 
> This has more than passing interest for me as one could take a NovaTel
> GPSCard which has a 1PPS output and runs on a single 12-36V supply and
> has a dedicated 1PPS output at serial levels and install one at each
> router location.Still have not disassembled the 2501 and 2611 to
> see which cheapo TCXO Cisco has installed.
> 
> 
> What do you have available at your shop - we are running SUP720-3BXL's
> running 12.2 SXF
> 
> On Sun, Oct 5, 2008 at 1:00 AM, Dave hartzell <[EMAIL PROTECTED]> wrote:
>> Looks like Trimble and Cisco got together on a PPS implementation for
>> the 7200, starting with 12.0T trainwreck:
>>
>> http://www.cisco.com/en/US/docs/ios/12_1t/12_1t1/feature/guide/dtrimble.html
>>
>> Since I don't have any 7200s any longer (thank goodness), I checked
>> and it seems that the 6500s support this as well on the console serial
>> port:
>>
>> 6509-rtr(config-line)#ntp ?
>>  pps-discipline  Use PPS pulse to discipline system clock
>>  refclockNTP Reference Clock
>>
>> and
>>
>> 6509-rtr(config-line)#ntp refclock ?
>>  telecom-solutions  Telecom Solutions GPS
>>  trimbleTrimble Navigation TSIP Protocol
>>
>> It looks interesting, and if the code is just looking for a PPS
>> transition on the CTS or RI, you might be in luck with any external
>> PPS...
>>
>> BUT be forewarned, IOS is a cooperative multitasking operating system
>> (at least prior to the new "modular" stuff), so your accuracy is going
>> to vary depending on loads, processes, etc.  I wouldn't count on this
>> being to spectacular...  probably no better than an external NTP
>> source.
>>
>> And of course, you can always call the TAC for more assistance!  ;-)
>>
>> 73,
>> Dave
>> AF6KD
>>
>>
>> On Fri, Oct 3, 2008 at 2:39 PM, Robert Vassar <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> I've been fiddling around with an old Cisco router here at the house
>>> to brush up.  We have an IPv6 project going at work, and our WAN
>>> provider provides no native transit, so I'm looking at doing some
>>> tunneling.  Anyhow... I discovered IOS 12.1 and above have native NTP
>>> capability.  I don't have the exhaustive IOS command reference, and I
>>> suspect it's a limited NTP implementation. I'm wondering if it's
>>> possible to tie a GPS unit to a router serial port and gain a stratum
>>> 0 refclock.
>>>
>>>
>>> Any Cisco guru's on the list?  :-)
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Rob
>>>
>>>
>>> ___
>>> 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.
> 
> 

___
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] Trimble Thunderbolt 1PPS TTL level?

[Scott Mace]

Have you tried terminating it with 50ohms?  That was the trick for mine.

Scott

Pieter Ibelings wrote:
> Hi All,
> 
> I got a Trimble Thunderbold from Ebay and I am having trouble triggering the 
> HP 53131A. The 1PPS output shows a 10us  pulse of 1 Volt into a high 
> impedance probe. This seems low to me. Should it be 5 volts? Maybe the 
> output 74AC04 is toast?
> 
> Pieter, N4IP
> 
> 
> 
> ___
> 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] Trimble Thunderbolt - Receive Sensistivity

[Scott Mace]

Both of the thunderbolts I have usually see 7-8 satellites, SNRs from 35-50,
antenna is on the roof with about 150ft of LMR-400 and going through 2 4-port
distribution splitter/amps.  I use the belden equiv of LMR-195 for all
connections between the receivers and the amps.  Both thunderbolts seem to
compare well to the M12+ based Fury, and do usually better than the 6-channel 
VP z3801a.

Scott

Mark Sims wrote:
> The Thunderbolt does not seem to be the most sensitive receiver around,  but 
> it does not seem particularly bad.  Sensitivity in a time receiver can be a 
> bad thing...  more sensitivity tends to make it more susceptible to 
> multipath, etc.  These things were meant to be mounted on cell towers, etc 
> where they have a pretty clear view of the sky.  Once you have that,  you 
> don't need high sensitivity.  Also their proximity to high power RF 
> transmitters makes overly sensitive front ends a problem.
> 
> On the subject of GPS amplifiers...  adding external amplification to a GPS 
> may not improve its performance and can actually degrade it.  All amplifiers 
> amplify signal and noise,  plus distort everything in the process. 
> (fundamental laws of the universe: 1) You can't get something for nothing,  
> 2) You can't break even,  3) You'll die trying)   Ideally,  you want the 
> amplifier at  the antenna and you want the amplification to match the cable 
> loss and no more.  Generally GPS receivers with poor sensitivity have poorly 
> designed front ends or signal processing.  Yelling in their ears won't make 
> them work any better.
> 
> 
> _
> Get ideas on sharing photos from people like you.  Find new ways to share.
> http://www.windowslive.com/explore/photogallery/posts?ocid=TXT_TAGLM_WL_Photo_Gallery_082008
> ___
> 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 for ntpd or gpsd

[Scott Mace]

Here's another patch that attempts to add leap second parsing to gpsd for
the thunderbolt.  I used the 0X58 UTC_INFO packet and calculated a
the leap second adjustment from delta t LS and delta T LSF store in the
current almanac.  Then use the presence of the leap second pending
alarm and the delta to send ntp a leap second warning.

Ignore the parity none stuff unless you own a thunderbolt.

The 0x58 trick will probably work with devices that use the 0x41 timing packet,
but I don't have a device to test that with.  There are other ways to get
leap second information that may be more straight forward on these devices, but
not on the thunderbolt.  You just get a leap second alarm and then have to
poll the UTC_INFO out of the almanac to get the leap second delta.

The 0x38 poll every 5 seconds is probably overkill, I was just
too impatient to wait to see if the receiver automatically sent a 0x58
packet after an almanac change.  Probably, the 0x38 needs to run
exactly once at startup and then future 0x58 packets will be sent automatically
given the 0x8E-A5 mask, but it doesn't seem to hurt anything.

This was tested with ntp-4.2.4p4 refclock_shm (no changes needed to ntpd).

Scott



Chris Kuethe wrote:

On Sun, Aug 10, 2008 at 1:42 PM, Scott Mace <[EMAIL PROTECTED]> wrote:

ntpshm_put() needs to be called in the 0xab case as well for ntp to work.


done.


--- gpsd/trunk/tsip.c   2008-08-08 23:38:27.0 -0500
+++ ../gpsd/trunk/tsip.c2008-08-09 04:14:09.0 -0500
@@ -65,7 +65,7 @@
   /* XXX clever heuristic to decide if the parity change is required.
*/
   session->driver.tsip.parity = session->gpsdata.parity;
   session->driver.tsip.stopbits = session->gpsdata.stopbits;
-   gpsd_set_speed(session, session->gpsdata.baudrate, 'O', 1);
+   gpsd_set_speed(session, session->gpsdata.baudrate, 'N', 1);
   break;

case 1:


not committing this - i'd prefer a heuristic to autodetect the parity.
i'm open to suggestions on how to do that.


@@ -674,6 +674,10 @@

   session->gpsdata.fix.time =  session->gpsdata.sentence_time =
 gpstime_to_unix((int)s1, f1) - (double)u1;
+#ifdef NTPSHM_ENABLE
+   if (session->context->enable_ntpshm)
+
(void)ntpshm_put(session,session->gpsdata.sentence_time+0.075);
+#endif
   mask |= TIME_SET;
 }


just committed this part...


diff -ru gpsd.orig/trunk/drivers.c gpsd/trunk/drivers.c
--- gpsd.orig/trunk/drivers.c	2008-08-08 23:38:27.0 -0500
+++ gpsd/trunk/drivers.c	2008-08-26 22:33:26.0 -0500
@@ -108,7 +108,7 @@
 	if (session->context->enable_ntpshm &&
 	(st & TIME_SET) != 0 &&
 	(session->gpsdata.fix.time!=session->last_fixtime)) {
-	(void)ntpshm_put(session, session->gpsdata.fix.time);
+	(void)ntpshm_put(session, session->gpsdata.fix.time, LEAP_NOWARNING);
 	session->last_fixtime = session->gpsdata.fix.time;
 	}
 #endif /* NTPSHM_ENABLE */
diff -ru gpsd.orig/trunk/garmin.c gpsd/trunk/garmin.c
--- gpsd.orig/trunk/garmin.c	2008-08-08 23:38:27.0 -0500
+++ gpsd/trunk/garmin.c	2008-08-26 22:33:00.0 -0500
@@ -403,7 +403,7 @@
 	}
 #ifdef NTPSHM_ENABLE
 	if (session->context->enable_ntpshm && session->gpsdata.fix.mode > MODE_NO_FIX)
-	(void) ntpshm_put(session, session->gpsdata.fix.time);
+	(void) ntpshm_put(session, session->gpsdata.fix.time, LEAP_NOWARNING);
 #endif /* NTPSHM_ENABLE */
 
 	gpsd_report(LOG_PROG, "Appl, mode %d, status %d\n"
diff -ru gpsd.orig/trunk/gpsd.h gpsd/trunk/gpsd.h
--- gpsd.orig/trunk/gpsd.h	2008-08-26 22:39:01.0 -0500
+++ gpsd/trunk/gpsd.h	2008-08-26 23:01:06.0 -0500
@@ -173,6 +173,11 @@
 
 #define NTPSHMSEGS	4		/* number of NTP SHM segments */
 
+#defineLEAP_NOWARNING  0x0 /* normal, no leap second warning */
+#defineLEAP_ADDSECOND  0x1 /* last minute of day has 61 seconds */
+#defineLEAP_DELSECOND  0x2 /* last minute of day has 59 seconds */
+#defineLEAP_NOTINSYNC  0x3 /* overload, clock is free running */
+
 /* Some internal capabilities depend on which drivers we're compiling. */
 #ifdef EARTHMATE_ENABLE
 #define ZODIAC_ENABLE	
@@ -199,6 +204,8 @@
 double rtcmtime;			/* timestamp of last RTCM104 report */ 
 /* timekeeping */
 int leap_seconds;			/* Unix seconds to UTC */
+u_char leap_warn;			/* Leap Second Warning for NTP */
+int leap_delta;			/* Leap Second Delta */
 int century;			/* for NMEA-only devices without ZDA */
 #ifdef NTPSHM_ENABLE
 bool enable_ntpshm;
@@ -324,6 +331,7 @@
 	time_t last_5c;
 	time_t last_6d;
 	time_t last_46;
+	time_t last_58;
 	unsigned int parity, stopbits; /* saved RS232 link parameters */
 	} tsip;
 #endif /* TSIP_ENABLE */
@@ -446,7 +454,7 @@
 extern void ntpshm_init(struct gps_context_t *, bool)

Re: [time-nuts] hpgps ntp refclock driver and leap second

[Scott Mace]

With the oncore VP in the z3801a isn't this a bug/feature of the Bj command
to announce it as soon as it is available, while other/newer receivers
wait till the month prior?  There is even a workaround for this in the
oncore refclock driver.

Scott

Greg Dowd wrote:
> In NTPv4, the warning is propagated as soon as it is available.  If it
> were more than 6 months in advance, this could be an issue but that
> hasn't happened yet.  NTP also ignores the alternate (Mar/Sept) leap
> windows by design.
> 
> 
>   
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>  
> 
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Mace
>> Sent: Monday, August 25, 2008 8:21 AM
>> To: Discussion of precise time and frequency measurement
>> Subject: [time-nuts] hpgps ntp refclock driver and leap second
>>
>> Shouldn't the hpgps ntp driver wait to raise the leap second 
>> flag until a month before the leap second and not whenever 
>> the satellite happens
>> to first transmit it?   See attached patch.
>>
>> diff -u refclock_hpgps.c.orig refclock_hpgps.c
>> --- refclock_hpgps.c.orig   2008-08-25 09:49:59.0 -0500
>> +++ refclock_hpgps.c2008-08-25 09:56:29.0 -0500
>> @@ -535,7 +535,8 @@
>>  switch (leapchar) {
>>
>>  case '+':
>> -   pp->leap = LEAP_ADDSECOND;
>> +   if ((month == 6) || (month == 12))
>> +   pp->leap = LEAP_ADDSECOND;
>>  break;
>>
>>  case '0':
>> @@ -543,7 +544,8 @@
>>  break;
>>
>>  case '-':
>> -   pp->leap = LEAP_DELSECOND;
>> +   if ((month == 6) || (month == 12))
>> +   pp->leap = LEAP_DELSECOND;
>>  break;
>>
>>  default:
>>
>> ___
>> 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.

[time-nuts] hpgps ntp refclock driver and leap second

[Scott Mace]

Shouldn't the hpgps ntp driver wait to raise the leap second flag until
a month before the leap second and not whenever the satellite happens
to first transmit it?   See attached patch.

diff -u refclock_hpgps.c.orig refclock_hpgps.c
--- refclock_hpgps.c.orig   2008-08-25 09:49:59.0 -0500
+++ refclock_hpgps.c2008-08-25 09:56:29.0 -0500
@@ -535,7 +535,8 @@
 switch (leapchar) {

 case '+':
-   pp->leap = LEAP_ADDSECOND;
+   if ((month == 6) || (month == 12))
+   pp->leap = LEAP_ADDSECOND;
 break;

 case '0':
@@ -543,7 +544,8 @@
 break;

 case '-':
-   pp->leap = LEAP_DELSECOND;
+   if ((month == 6) || (month == 12))
+   pp->leap = LEAP_DELSECOND;
 break;

 default:

___
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] Olympic time standard?

[Scott Mace]

I found this link:

http://www.goodgearguide.com.au/videoview/257930

In the video they talk about it being a quartz standard that is
synced to GPS.

Scott

Peter Vince wrote:
> Hi Mitch,
> 
>   Not a direct answer to your question, but Omega have a PDF on their web 
> site
> that might be of interest:
> 
> http://www.omegawatches.com/uploads/media/olympic_press_kit_en.pdf
> 
>   Regards,
> 
>   Peter
> 
> 
> Is there a common time standard that all of the timed
> Olympic events are referenced to? I know that Omega
> provides the timing, their logo is on every computer
> that you see. If there is a common reference, how is
> it distributed to all of the events?
> 
> Mitch
> 
> 
> ___
> 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 for ntpd or gpsd

[Scott Mace]

I found that on the two FatPPS units I have, pin 2 on the female DE-9 connector
is tied to the DC-IN. This was causing noise from the thunderbolt RS-232
TX to get into the PPS output.  It basically made it totally unusable.
I removed R4 since I use DTR for power and it works perfectly.

Scott

Tim Cwik wrote:
> Wayne Knowles wrote:
>> Tim, Chris,
>>
>> Over a month ago I experimented with getting GPSD and the Tunderbolt working 
>> together.
>> I quickly added support for the missing TSIP packet types, and was able to 
>> get 
>> xgps to display lat, long, time  and constellation status.   I did manage to 
>> get NTP to work, have not invested the time into getting the 1PPS signal 
>> working under FreeBSD yet.
>>
>> I have attached my patches against the gpsd source repository.   Note that I 
>> did not invest much time understanding the internals of gpsd beforehand so 
>> some aspects may not be fully implemented.
>>
>>   
> Thanks Wayne and Chris and Chris.
> 
> I have discovered the even though cgps does not report position or time 
> using the Thunderbolt, the stock gpsd is getting enough timing data to 
> update ntp. Gpsd is selected as the sys.peer with a jitter of about .8. 
> It looks like the PPS pulse is too narrow to be detected on DCD, I am 
> going to investigate a pulse stretcher available from TAPR 
> http://tapr.org/kits_fatpps.html and will see if that helps. FWIW, 
> Centos 5.1 selinux allows gpsd to update the ntp shared memory segment 
> out of the box.
> 
> 
> 73,
> 
> 
> ___
> 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 for ntpd or gpsd

[Scott Mace]

ntpshm_put() needs to be called in the 0xab case as well for ntp to work.

Scott

--- gpsd/trunk/tsip.c   2008-08-08 23:38:27.0 -0500
+++ ../gpsd/trunk/tsip.c2008-08-09 04:14:09.0 -0500
@@ -65,7 +65,7 @@
 /* XXX clever heuristic to decide if the parity change is required. */
 session->driver.tsip.parity = session->gpsdata.parity;
 session->driver.tsip.stopbits = session->gpsdata.stopbits;
-   gpsd_set_speed(session, session->gpsdata.baudrate, 'O', 1);
+   gpsd_set_speed(session, session->gpsdata.baudrate, 'N', 1);
 break;

  case 1:
@@ -674,6 +674,10 @@

 session->gpsdata.fix.time =  session->gpsdata.sentence_time =
   gpstime_to_unix((int)s1, f1) - (double)u1;
+#ifdef NTPSHM_ENABLE
+   if (session->context->enable_ntpshm)
+   (void)ntpshm_put(session,session->gpsdata.sentence_time+0.075);
+#endif
 mask |= TIME_SET;
   }


Wayne Knowles wrote:
> Tim, Chris,
> 
> Over a month ago I experimented with getting GPSD and the Tunderbolt working 
> together.
> I quickly added support for the missing TSIP packet types, and was able to 
> get 
> xgps to display lat, long, time  and constellation status.   I did manage to 
> get NTP to work, have not invested the time into getting the 1PPS signal 
> working under FreeBSD yet.
> 
> I have attached my patches against the gpsd source repository.   Note that I 
> did not invest much time understanding the internals of gpsd beforehand so 
> some aspects may not be fully implemented.
> 
> --
> Wayne ZL2BKC
> 
> 
> On Fri, Jun 13, 2008 at 8:58 AM, Christian Vogel  wrote:
>> gpsd: GPS Time 485697.25 1483 14.00
> that's encouraging
> 
>> gpsd: Sat info: mode 1, satellites used 5:  18 9 28 15 26
> As is this.
> 
>> gpsd: Unhandled TSIP superpacket type 0xab
> 
> "thar's yer problem"...  kinda.
> 
> yes, we don't handle 0xAB, but that's just timing information. I see
> no indication that the receiver is outputting position reports. I
> should have this sorted a few hours after my Thunderbolt arrives.
> Guess I need to prod the receiver into telling me where it thinks it
> is.
> 
>> Unfortunately, it does not show any information about time or position on
>> a connected cgps/xgps client.
>>
>>Chris
>>
>> ___
>> time-nuts mailing list -- time-nuts at 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] GPS shielding by power lines?

[Scott Mace]

Around here they place cell antennas on a monopole down the center
of power transmission line towers.  The GPS antennas are invariably
directly below the 100-200kv lines.   The GPS signal must be reliable
enough or the cell sites wouldn't be there.

Scott

Alan Melia wrote:
> Hi all,  in the process of setting up a GPS time standard for a Radio
> Astronomy facility (amateur) we installed a GPS receiver in a small cabin
> with a translucent roof, thinking that would not impede the GPS signal.
> After a lot of head scratching as to why we were not getting the performane
> we got at another site, we realised that the "convenient position" for the
> cabin was directly below a three phase 11kV power distribution line ( common
> UK rural electricity distribution system). We extended the cable and moved
> the antenna about 20 - 30 feet to the side of the line run, which was
> mounted on wooden poles at about 25 feet. In this position we immediately
> got a reliable fix. The fix and number of usable satellites degrades as we
> move nearer the lines.
> 
> The thought was that there as interference arcing or corona noise from the
> line insulators, and a receiver (AM) was deployed to listen for what was
> expected to be a substantial wide band noise signalwe didnt hear one! We
> are now confused about what the effect is. The signal could not be
> "screened" by the wires which are about 3 feet apart, but they definite
> provide a cone of interference directly under the run. The experiment was
> later repeated with two further different GPS receivers and produced the
> same result.
> 
> Has anyone seen this before? have you any idea of what level noise we should
> be looking for? I believe this is a wide signal so maybe an AM receiver is
> not the best choice The area is a rural, horticultural area (called market
> garden in the UK) We are obviouslt concerned to trace any noise sources in
> the vicinity of the Hydrogen line frequency at 1420MHz.
> 
> Alan G3NYK
> 
> 
> ___
> 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] Thunderbolt PPS output

[Scott Mace]

Has anyone used the thunderbolt PPS output with a N8UR FatPPS?  I'm seeing
a large (+-100-300us) amount of jitter on the output of the FatPPS.  This same
setup works fine with the input from z3801a (using a PECL/TTL converter)
or the Fury (even though the Fury's pulse is wide enough to begin with).
Is there something special about the thunderbolt PPS output?  I noticed it
seemed to require 50ohm termination to get a clean signal when I connected
it to a counter (5334a) with a 3 foot cable.

I'm using the FatPPS in conjunction with a soekris 4501 with the tmrin mod.

Scott

___
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] LPRO 101 ADJUSTMENT

[Scott Mace]

Here's an idea of what the DAC on my system is doing:

timestamp   freq_err  time_int efc_voltage
54672 85907.015 2.18e-12 -5.00e-10 1.976955
54672 85917.015 1.87e-12 -4.10e-10 1.976116
54672 85927.015 1.96e-12 -3.00e-10 1.975772
54672 85937.016 1.49e-12 -1.90e-10 1.975664
54672 85947.017 1.52e-12 -1.50e-10 1.975790
54672 85957.017 8.29e-13 -1.60e-10 1.976403
54672 85967.018 8.95e-13 -9.10e-11 1.976403
54672 85977.009 2.52e-14 -9.20e-11 1.976634
54672 85987.009 -1.16e-13 -2.30e-10 1.977615
54672 85997.010 -5.73e-13 -2.30e-10 1.977615
54672 86007.011 -6.71e-13 -3.40e-10 1.977129
54672 86017.011 -1.10e-12 -4.70e-10 1.977208
54672 86027.013 -1.31e-12 -6.70e-10 1.977122
54672 86037.013 -1.79e-12 -9.90e-10 1.977883
54672 86047.013 -2.16e-12 -1.40e-09 1.978333
54672 86057.015 -2.59e-12 -1.70e-09 1.978397
54672 86067.015 -2.94e-12 -2.10e-09 1.978397
54672 86077.015 -3.12e-12 -2.50e-09 1.978521
54672 86087.017 -3.36e-12 -2.80e-09 1.978479
54672 86097.010 -3.20e-12 -3.00e-09 1.978253
54672 86107.018 -3.33e-12 -3.20e-09 1.977620
54672 86117.018 -3.05e-12 -3.30e-09 1.977035
54672 86127.010 -3.09e-12 -3.40e-09 1.976963
54672 86137.010 -2.83e-12 -3.30e-09 1.976998
54672 86147.011 -2.68e-12 -3.20e-09 1.976998
54672 86157.010 -2.20e-12 -3.00e-09 1.976787
54672 86167.010 -1.93e-12 -2.70e-09 1.976953
54672 86177.012 -1.81e-12 -2.50e-09 1.977248
54672 86187.014 -1.51e-12 -2.20e-09 1.977218
54672 86197.015 -1.52e-12 -2.00e-09 1.976899
54672 86207.015 -1.27e-12 -1.80e-09 1.976659
54672 86217.017 -1.09e-12 -1.60e-09 1.976506
54672 86227.016 -8.53e-13 -1.40e-09 1.976144
54672 86237.017 -7.64e-13 -1.20e-09 1.976058
54672 86247.018 -6.27e-13 -1.10e-09 1.976518
54672 86257.018 -8.53e-13 -9.90e-10 1.976634
54672 86267.010 -8.15e-13 -9.60e-10 1.977167
54672 86277.010 -1.24e-12 -1.00e-09 1.978143
54672 86287.010 -1.27e-12 -1.00e-09 1.977806
54672 86297.012 -1.72e-12 -1.10e-09 1.977363
54672 86307.010 -1.79e-12 -1.20e-09 1.977358
54672 86317.009 -2.10e-12 -1.30e-09 1.977070
54672 86327.013 -2.27e-12 -1.50e-09 1.977347
54672 86337.014 -2.35e-12 -1.80e-09 1.978016
54672 86347.014 -2.63e-12 -2.10e-09 1.978357
54672 86357.016 -2.57e-12 -2.40e-09 1.978433
54672 86367.010 -2.87e-12 -2.70e-09 1.978821
54672 86377.014 -2.50e-12 -2.90e-09 1.978657
54672 86387.013 -2.64e-12 -3.00e-09 1.978657
54672 86397.010 -2.00e-12 -3.10e-09 1.977049

Scott

jshank wrote:
> If I choose to control the frequency via External C-field control I guess it 
> would take a very precise and stable voltage source.  Any thoughts or 
> suggestions?
> 
> - Original Message ----- 
> From: "Scott Mace" <[EMAIL PROTECTED]>
> To: "jshank" <[EMAIL PROTECTED]>; "Discussion of precise time and 
> frequency measurement" 
> Sent: Friday, July 25, 2008 7:15 PM
> Subject: Re: [time-nuts] LPRO 101 ADJUSTMENT
> 
> 
>> Both methods work well.  Be sure the unit is mounted to some sort of 
>> heatsink,chassis, etc.
>> I'm using a Fury GPS receiver to drive the EFC on an LPRO-101.
>> You won't get much range out of either adjustment.  Leave it powered
>> on for a couple of hours before trying to adjust it.  I usually set the 
>> trim pot in the
>> middle of it's range and use the EFC pin.  I think it's a 28 or 30 turn 
>> pot.  EFC
>> is 0-5v.  The unit will self-bias to around 2.5v if the EFC pin is open.
>>
>> Scott
>>
>> jshank wrote:
>>> Hi,
>>>
>>> I recently acquired a LPRO 101 Rubidium Oscillator.  After reading the 
>>> manual I see that there are two ways to adjust the frequency 1) using and 
>>> adjusting screw on the unit and 2) using the External C-field control 
>>> signal at pin J1-7.  Has anyone experimented with either method and if so 
>>> what method was preferred?
>>>
>>> Jeff
>>>
>>>
>>> ___
>>> 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] LPRO 101 ADJUSTMENT

[Scott Mace]

Both methods work well.  Be sure the unit is mounted to some sort of 
heatsink,chassis, etc.
I'm using a Fury GPS receiver to drive the EFC on an LPRO-101.
You won't get much range out of either adjustment.  Leave it powered
on for a couple of hours before trying to adjust it.  I usually set the trim 
pot in the
middle of it's range and use the EFC pin.  I think it's a 28 or 30 turn pot.  
EFC
is 0-5v.  The unit will self-bias to around 2.5v if the EFC pin is open.

Scott

jshank wrote:
> Hi,
> 
> I recently acquired a LPRO 101 Rubidium Oscillator.  After reading the 
> manual I see that there are two ways to adjust the frequency 1) using and 
> adjusting screw on the unit and 2) using the External C-field control signal 
> at pin J1-7.  Has anyone experimented with either method and if so what 
> method was preferred?
> 
> Jeff
> 
> 
> ___
> 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] Lucent RFTG-m-RB

[Scott Mace]

When you have a RFTG-m-XO and Rb pair, do you connect both
J5 and J6 on each unit or just J5?

Scott

Scott Mace wrote:
> Has anyone tried to discipline the RFTG-m-RB without the -XO unit from
> a house PPS feed?
> 
> I think pins 4 and 8 on J6 are the PPS input.
> 
>   Scott
> 
> ___
> 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] Lucent RFTG-m-RB

[Scott Mace]

Has anyone tried to discipline the RFTG-m-RB without the -XO unit from
a house PPS feed?

I think pins 4 and 8 on J6 are the PPS input.

Scott

___
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] Fury ntp refclock

[Scott Mace]

This is on a net4501 with the TMRIN mod running FreeBSD 7.0 (nanobsd).
Fury 1.18 firmware with a surplus LPRO-101 packaged up in an old 1U Datum
670x rubidium reference chassis.

 > ntptime
ntp_gettime() returns code 0 (OK)
   time cc1d84fd.0fbd3800  Tue, Jul  8 2008  6:17:33.061, (.061481758),
   maximum error 1480 us, estimated error 15 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
   modes 0x0 (),
   offset -0.014 us, frequency -0.040 ppm, interval 1 s,
   maximum error 1480 us, estimated error 15 us,
   status 0x2001 (PLL,NANO),
   time constant 4, precision 0.001 us, tolerance 496 ppm,
 >

 > ntpq -c peers
  remote   refid  st t when poll reach   delay   offset  jitter
==
+REFCLK(45,0).GPS.0 l   13   16  3770.000   -1.152   3.108
oPPS(0)  .PPS.0 l4   16  3770.0000.000   0.015
 >


clockstats:
54655 22687.015 127.127.45.0 94 1 0 0 5.09e-12 -1.10e-09 46.10 1.994153 
0.04 10.53 8 9 1 38 10
54655 22697.016 127.127.45.0 94 1 0 0 4.59e-12 -1.40e-09 46.00 1.994255 
0.04 10.53 8 9 1 38 10
54655 22707.017 127.127.45.0 94 1 0 0 4.29e-12 -1.60e-09 46.10 1.994454 
0.04 10.53 8 9 1 38 -11
54655 22717.017 127.127.45.0 94 1 0 0 3.56e-12 -1.90e-09 46.10 1.994834 
0.04 10.53 9 9 1 38 4
54655 22727.018 127.127.45.0 94 1 0 0 3.29e-12 -2.10e-09 46.10 1.994912 
0.04 10.53 9 9 1 36 -6
54655 22737.010 127.127.45.0 94 1 0 0 2.35e-12 -2.30e-09 46.10 1.994695 
0.04 10.53 9 9 1 36 -14
54655 22747.010 127.127.45.0 94 1 0 0 2.08e-12 -2.60e-09 46.10 1.994872 
0.04 10.53 9 9 1 36 -13
54655 22757.011 127.127.45.0 94 1 0 0 1.43e-12 -2.80e-09 46.10 1.995252 
0.04 10.53 9 9 1 36 0
54655 22767.012 127.127.45.0 94 1 0 0 1.16e-12 -3.00e-09 46.10 1.995357 
0.04 10.53 9 9 1 36 -5
54655 22777.012 127.127.45.0 94 1 0 0 8.07e-13 -3.20e-09 46.10 1.995337 
0.04 10.53 9 9 1 36 3
54655 22787.014 127.127.45.0 94 1 0 0 5.83e-13 -3.40e-09 46.10 1.995080 
0.04 10.53 9 9 1 36 -8



Scott

[EMAIL PROTECTED] wrote:
> Hi guys,
>  
> We formatted the syst:stat? command on the Fury GPSDO so as to be  compatible 
> to GPSCon, that meant following a very rigorous syntax (including the  exact 
> number of spaces etc), it's not pretty - but works perfectly with  GPSCon.
> 
> One note of interest to the group in general: some of our future  products 
> have a new, very high performance mobile GPS on them that will actually  
> track 
> and output 16 Sats and more simultaneously (well, if it could see the Sats  
> it 
> would receive more than 30 channels) to GPSCon. A far cry from the 8-sat  
> Oncore days, and this is causing some grief for GPSCon (not the entire list 
> of  
> Sat's can be shown by GPSCon without overflowing the page etc). We can't 
> reveal  
> the GPS details just yet though, please don't ask :)
>  
> Seems the web interface of GPSCon works well with any number of Sats  though, 
> see for example:
>  
>_http://www.jackson-labs.com/images/gpsstat.htm_ 
> (http://www.jackson-labs.com/images/gpsstat.htm) 
>  
>  
> We are working hard on a set of new products right now, so the ptime  command 
> changes will have to be put on a slightly lower priority for now  
> unfortunately. Seems your driver is working well right now though from what I 
>  can gather 
> in the email thread.
>  
> Thanks for your hard work on this,
> bye,
> Said
>  
> 
>  
>  
> In a message dated 7/8/2008 02:09:12 W. Europe Daylight Time,  [EMAIL 
> PROTECTED] 
> writes:
> 
> 
> The  gps?,sync?,diag?,meas? results were easier to parse than the  
> system:status?
> since everything has a prefix.
> 
> I'm not a fan of a the  system:status? command, but it would be nice to get
> sat signal strength  from the gps? command tree.
> 
> My driver is not ideal, but it works with  what the Fury can do with the 
> current
> firmware.  More to  come.
> 
> Scott
> 
> 
> 
> 
> 
> **Gas prices getting you down? Search AOL Autos for 
> fuel-efficient used cars.  
> (http://autos.aol.com/used?ncid=aolaut000507)
> ___
> 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] Fury ntp refclock

[Scott Mace]

Maybe just build it into the generic parse refclock?  I just needed
to get it up and running and a standalone driver was the path of least 
resistance.

The neat thing about the gpgga string is that it happens every second and 
doesn't
rely on ntpd to send a command for it. It gives you a nice trigger to do all the
stats gathering after the timecode has been processed.  As long as you do the 
stats
collection in less than a second...  Jitter will never be low enough for it
to be useful without an external pps reference.

It would be nice to have a fully functioning short timecode that was emitted 
every
second (instead of polled) that contained all the useful bits that NTP needs,
time,sync/lock status, leap status, holdover status. Then add a new command to 
get
a one-line result for all the interesting non-timecode related info that
could be polled at whatever interval the user wanted.

The gps?,sync?,diag?,meas? results were easier to parse than the system:status?
since everything has a prefix.

I'm not a fan of a the system:status? command, but it would be nice to get
sat signal strength from the gps? command tree.

My driver is not ideal, but it works with what the Fury can do with the current
firmware.  More to come.

Scott



Hal Murray wrote:
> [EMAIL PROTECTED] said:
>> I've created a ntpd refclock driver for the Fury GPS receiver. The
>> refclock is based on the NMEA driver. 
> 
> Neat/thanks.
> 
> There is currently a major reluctance to add new drivers to the main ntpd 
> source pool.
> 
> I think we should add this logic to the hpgps driver.
> 
> 
>> The driver was created because the Fury does not fully implement the
>> ptime:tcode? T2 string.  The output is not on-time and the status
>> fields are always 0.  So, it is not going to work with the hpgps
>> refclock. As it turns out the T2 string is rather limiting anyways. 
> 
> Said: Can you make the T2 string be "on time" and/or fix the status fields?
> 
> Would it be better to invent a T3 string that had everything needed to tell 
> time and also everything people are likely to want logged?
> 
> Is "everything" a sensible concept?  Would that be too much for most people 
> and still not enough for a few?  Maybe a mode in the Fury would solve that?  
> Or bit mask?  The driver would just log everything after the date/time/status 
> so it doesn't care.  (as long as it isn't too long)
> 
> 
> 
> There is currently a bug/oversight in the hpgps driver.  It only gets one 
> sample per poll interval rather than 1 per second.  (The refclock interface 
> has a FIFO and code to discard outliers and average the rest.)  Fixing this 
> is high on my list.
> 
> The hpgps driver currently logs a 24x80 status screen if you ask for clock 
> statistics.  I'd like an option to record just the interesting parameters.  
> Of course, I have to do this without breaking anything for people who use the 
> current setup.
> 
> 

___
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] Fury ntp refclock

[Scott Mace]

I've created a ntpd refclock driver for the Fury GPS receiver.
The refclock is based on the NMEA driver.

http://www.intt.net/time-nuts/ntp-fury.diff

The driver was created because the Fury does not fully
implement the ptime:tcode? T2 string.  The output is
not on-time and the status fields are always 0.  So,
it is not going to work with the hpgps refclock.
As it turns out the T2 string is rather limiting anyways.

Fortunately, the Fury supports a partial NMEA mode, where
it will emit on-time $GPGGA sentences.  The driver then
probes the Fury for other statistics using the GPS? SYNC?
DIAG? and MEAS? commands.  Also the driver will check
for leap second warnings.  The stats are concisely output
to clockstats.  Some logic for handling holdover thresholds
and to detect if the Fury is unlocked has been added.

flag3 logs the stats, flag4 logs the gpgga sentences

output from Fury OEM SMA connector version w/ LPRO-101
54654 13857.011 127.127.45.0 68 1 0 0 2.65e-12 2.10e-09 44.50 1.992863 0.04 
10.53 7 7 1 41 -1
54654 13867.010 127.127.45.0 68 1 0 0 2.67e-12 2.20e-09 44.50 1.993594 0.04 
10.53 7 7 1 41 10
54654 13877.011 127.127.45.0 68 1 0 0 2.99e-12 2.20e-09 44.50 1.993680 0.04 
10.53 7 7 1 41 -13
54654 13887.013 127.127.45.0 68 1 0 0 2.83e-12 2.10e-09 44.50 1.993442 0.04 
10.53 7 7 1 41 -4


lifetime ppslock holdduration holdover fee tint temp efc ocxocurrent ocxovolt 
sat_vis sat_track pulsestat pulseacc pulsesaw



sample ntp.conf:



server 127.127.45.0 prefer minpoll 4 maxpoll 4
fudge 127.127.45.0 time1 0.012 #115200
#fudge 127.127.45.0 time1 0.024 #57600
fudge 127.127.45.0 flag3 1
#fudge 127.127.45.0 flag4 1

server 127.127.22.0 minpoll 4 maxpoll 4

tos mindist 0.010

statsdir /var/log/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable




Scott

___
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] GPS receivers and poor sky visibility.....

[Scott Mace]

I'm using a HP58504a antenna that's mounted just at the roof line in a _heavily_
wooded lot (two story house).  The feed line is about 120ft of LMR-400
connected to a symmetricom 4port splitter.  I use belden 7806R for the short
runs from the splitter to the receivers.  I see 4-6 satellites on the
Z3801A and anything from 6-12 on the Fury.  Trees have never been a problem.
I even had the antenna at ground level for a while in the back yard with
much of the western and northern view blocked by the house and trees and
was able to track at least 3-4 satellites on the z3801a.  Isn't the southern
view the most important if you are in the northern hemisphere at higher 
latitudes?

Scott

Michael Baker wrote:
> Hello, All--
> 
> Jim Robbins reported poor GPS performance because his GPS 
> antenna has a limited clear view of the sky.  
> 
> Hmm  Jim-- might you have some sort of antenna or
> feed line problem?  My house is in the middle of a relatively
> small yard in the center of a VERY HEAVILY wooded 6 acre
> lot.   My Thunderbolt antenna has an extremely limited
> clear view of the open sky and at no direction is it better than
> 40 degrees above the horizon. My T-bolt typically indicates good
> signals from at least 6 or 7 birds with signal levels of
> 8.0 to over 12.0.  As an experiment, I switched it over to
> an antenna INSIDE my house and while the signal levels all
> dropped to between 5.0 to 8.0, indicated performance as reported
> by T-bolt Mon is still solid.
> 
> Mike Baker
> 
> 
> 
> 
> 
> 
> ___
> 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] HP 5334B rackmount ears

[Scott Mace]

Didier, this is exactly what I need.  I'll contact you off-list.

Scott

Didier Juges wrote:
> I have a pair which came from a 5334B and which I would gladly trade for the
> feet :-)
>  
> Didier KO4BB
> 
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Mace
>> Sent: Wednesday, June 04, 2008 5:48 PM
>> To: Discussion of precise time and frequency measurement
>> Subject: [time-nuts] HP 5334B rackmount ears
>>
>> Does anyone know where I can get a set of rackmount ears for 
>> the 5334B?
>> I need to rack this unit and take off the feet.
>>
>>  Scott
>>
> 
> 
> ___
> 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] HP 5334B rackmount ears

[Scott Mace]

Yes, it's a 2U.  I think it's option 908, option 909 or something.

Scott

[EMAIL PROTECTED] wrote:
> I think I have some; what is the height?  2RU?
> 
> -Dave
> 
> -- Original message -- 
> From: Scott Mace <[EMAIL PROTECTED]> 
> 
>> Does anyone know where I can get a set of rackmount ears for the 5334B? 
>> I need to rack this unit and take off the feet. 
>>
>> Scott 
>>
>> ___ 
>> 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.

[time-nuts] HP 5334B rackmount ears

[Scott Mace]

Does anyone know where I can get a set of rackmount ears for the 5334B?
I need to rack this unit and take off the feet.

Scott

___
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] sub cables

[Scott Mace]

I've heard that sharks seem to prefer biting fiber cables as opposed to
the old ones.

How else will they get their lasers? :)

Scott

Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Scott Mace writes:
> 
>> A repeater or regen goes optical-electrical-optical.  I think you are
>> talking about an EDFA.  While it may pass light when it's down, one
>> has to take into account the optical budget of the span.
> 
> Sorry for sloppy terminology here :-)
> 

___
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] sub cables

[Scott Mace]

A repeater or regen goes optical-electrical-optical.  I think you are
talking about an EDFA.  While it may pass light when it's down, one
has to take into account the optical budget of the span.

Scott

Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Neon John writes:
> 
>> Now I'm curious how power is tapped off at each repeater point.  I understand
>> the daisychain architecture but I'm wondering about the details, what
>> components can withstand the intial high voltage surge as the cable is
>> charging and how the voltage drop at each repeater is maintained relatively
>> constant, even if the repeater fails and quits consuming power.
> 
> It may be different these modern days, but it used to be that each
> repeater had a (power)resistor connected in series with the supply
> wires and the amplifier was connected across the resistor.
> 
> If the amplifier disconnected, the resistor kept continuity, if the
> amplifier shorted, there would be continuity as well.
> 
> In addition the resistor kept the electronics from getting too cold.
> 
>> Also, is it true that an optical cable will keep working with a single
>> repeater failure, that the laser light will pass through unamplified?  Seems
>> like I read that somewhere but I'm not sure.
> 
> Yes, that's the major benefit from the "erbium doped fiber repeater"
> design.  Google it for details.
> 

___
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] Disciplining Rubidium

[Scott Mace]

I ended up doing this with a LPRO-101 that I am using with the Fury a few days 
ago.
The unit did not loose lock, however it did cause it to drift very slowly for a 
few
hours.  This was a 90degree turn.  It also changed the airflow over the 
heatsink,
so I'm sure that had something to do with it as well.

This resulted in peak of +30ns of phase error over a 4 hour period.

Scott

[EMAIL PROTECTED] wrote:
> Hi Antonio, Tom,
>  
> recently I had to unplug my PRS10 Rb from GPS for about 3 days. It drifted  a 
> couple 100ns in that time frame.
> 
> When I plugged the GPS 1PPS back in, I saw a significant  frequency error of 
> a couple of parts to the E-10 while the PRS10 was shifting  the 1PPS back 
> onto 
> UTC.
>  
> Pretty bad for a Rubidium I thought.
>  
> For such a large phase error I would have expected the PRS10 to just reset  
> the 1PPS rather than drift it.
>  
> I may have to adjust the loop time constants to be more than 7 hours.
>  
> To address your question: I would expect the PRS10 to behave in a  similar 
> manner when turning it upside down. It would probably take some  minutes or 
> longer to re-lock the OCXO to Rb, then correct the OCXO to  1PPS phase error 
> that 
> acrued.
>  
> Typical OCXO errors for a turn-over test are parts in E-09, that causes a  
> very significant immediate phase drift.
>  
> Can't try it in my setup unfortunately.
>  
> bye,
> Said 
>  
>  
> In a message dated 4/24/2008 15:28:55 Pacific Daylight Time,  
> [EMAIL PROTECTED] writes:
> 
> Why the  XO in a GPS-Rb-XO version should not bear this problem?
> I understand that  Rb itself shouldn't, but what about the controlled XO?
> (I have an interest  in orientation sensitivity of measuring  instruments).
> Thanks,
> 
> 
> 
> 
> **Need a new ride? Check out the largest site for U.S. used car 
> listings at AOL Autos.  
> (http://autos.aol.com/used?NCID=aolcmp0030002851)
> ___
> 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] using Fury GPSDO with Rb

[Scott Mace]

Here's what I ended up with:

COARSE DAC : 105
DAC GAIN: 1200.00
EFC SCALE : 1.40
EFC DAMPING: 2
OCXO SLOPE : POSITIVE
TEMPERATURE COMPENSATION : 0.00
AGING COMPENSATION : 0.02744
PHASE CORRECTION : 35.00

Here are some plots:
http://www.intt.net/time-nuts/export.png
http://www.intt.net/time-nuts/export_temp_spike.png

Everything is on an open work table right now, with the LPRO mounted on a
heatsink.  The baseplate of the LPRO is about 38C.  I have not tried too
much to adjust EFC damping either, it seemed that if it had more than 10 it
would become unstable.

Scott


[EMAIL PROTECTED] wrote:
> Hi Scott,
>  
> that's a great success story!
>  
> What final Loop settings do you use on the Fury with LPRO-101?


>  
> It would be interesting to see if the +-10ns temperature related deviations  
> are coming from the LPRO or maybe the GPS, DAC etc? What is the EFC change  
> over these temp changes?
>  
> With the external clock source, it is not easy to use the temperature  
> compensation of the Fury, but it could be done - need a current sink that is  
> sensitive to temperature and uses about 50 - 200mA, that can be used as a 
> highly  
> accurate temperature sensor for the compensation routines.
> 
> The digital temperature sensor on the Fury has only 1/16 Deg C  resolution, 
> not nearly enough to do accurate temperature compensation.
>  
> bye,
> Said
>  
>  
> In a message dated 4/18/2008 09:21:01 Pacific Daylight Time, [EMAIL 
> PROTECTED]  
> writes:
> 
> It's  working well with the LPRO-101.  It stays typically within +-3ns
> with  excursions to +-10ns based on temp changes (hvac cycling, etc.)
> It is very  apparent when you plot the temp sensor on the fury.
> 
> Scott
> 
> 
> 
> 
> 
> **Need a new ride? Check out the largest site for U.S. used car 
> listings at AOL Autos.  
> (http://autos.aol.com/used?NCID=aolcmp0030002851)
> ___
> 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] using Fury GPSDO with Rb

[Scott Mace]

It's working well with the LPRO-101.  It stays typically within +-3ns
with excursions to +-10ns based on temp changes (hvac cycling, etc.)
It is very apparent when you plot the temp sensor on the fury.

Scott

[EMAIL PROTECTED] wrote:
> Hi Scott,
>  
> be careful, 5.5V at 50% duty cycle is about 21.5dBm into 50 Ohms.
>  
> The Fury will probably not be damaged, but it is outside of it's spec,  so 
> you are overdriving it.
>  
> 3.3V CMOS outputs are much preferred if a sine output is not  available.
>  
> A simple solution could be a resistive, or capacitive divider, say two  220pF 
> caps in series with the center tap going into the Fury GPSDO.
>  
> bye,
> Said
>  
>  
> In a message dated 4/11/2008 12:43:09 Pacific Daylight Time, [EMAIL 
> PROTECTED]  
> writes:
> 
> I think  the max for the FRS is 5.5v into 50ohms.
> 
> Scott
> 
> 
> 
> 
> 
> **It's Tax Time! Get tips, forms and advice on AOL Money & 
> Finance.  (http://money.aol.com/tax?NCID=aolcmp0030002850)
> ___
> 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] using Fury GPSDO with Rb

[Scott Mace]

I think the max for the FRS is 5.5v into 50ohms.

Scott

[EMAIL PROTECTED] wrote:
> Hi Scott,
>  
> I don't have access to the Fury schematics right now, but I believe the  Fury 
> 10MHz input is 50 Ohms terminated, so the TTL output would have to be able  
> to supply that load.
>  
> No other side effect, just make sure to adhere to the maximum input power  
> level (+13dBm I believe), even for TTL.
>  
> Hope that helps,
> bye,
> Said
>  
>  
> In a message dated 4/11/2008 11:20:25 Pacific Daylight Time, [EMAIL 
> PROTECTED]  
> writes:
> 
> The  output of the Rb was TTL also.  What are the side effects
> of using  that with the Fury (other than not getting a sine  output)?
> 
> 
> 
> 
> **Planning your summer road trip? Check out AOL Travel Guides.
>   (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
> ___
> 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] using Fury GPSDO with Rb

[Scott Mace]

cy  counter
>>>>
>>>>   
>>>> 3) Determine maximum  frequency   deviation at EFC = 5V  (serv:coarsedac  
>   
>> 255)
>>>>   
>>>> 4) Set   Dacgain  according to table in user manual depending on the
>>>  frequency  
>>>> difference between 2)  and  3)
>>>>   
>>>>  5) Set  Integral part of loop to  zero: serv:phaseco 0.0, this  helps  
> for  
>>  
>>>  now
>>>>   
>>>> 6) Set Proportional part  of loop to a  number  that  makes the unit lock 
>> as  
>>>>  quickly  as  desired without oscillation  and overshoot (for  example:   
>  
>>> serv:efcs 1.0 
>>>> to  serv:efcs  6.0
>>>>   
>>>> 7)  Set  the integral part of the loop so that the   phase is driven to 
> 0ns  
>>  
>>> UTC  
>>>> offset as quickly   as desired without   overshoot/oscillation, for 
>>  example:   
>>>> serv:phaseco20.
>>>>  
>>>>  Repeat 6) and 7) after  some  hours.
>>>>   
>>>>  Hope that  helps,
>>>> bye,
>>>>   Said
>>>>   
>>>>>  -Original  Message-
>>>>>  From:  Scott  Mace
>>>>>  Sent:  Saturday, April 05,  2008   17:51
>>>>> To: Said   Jackson
>>>>> Subject:  Re:   FuryGPSDO
>>>>>
>>>>>
>>>>> Said,   I finally  got  my fury up  and  running, I'm using a  efratom  
>>>>> FRS-A and  also a   LPRO-101.
>>>>> Do  you  have any recommending  starting  points for  tuning the  servo 
>>>>>  for a  rubidium unit?
>>>>>
>>>>>   Scott
>>>>>   
>>>>   
>>>>  
>>>>
>>>>
>>>>   **Planning your summer  road trip? Check  out AOL  Travel  
>>> Guides. 
>>>
>>>> 
>>>  
>>  
> (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
>>>>   ___
>>>>  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.
>>>
>>>
>>>
>>>   
>>>
>>> **Planning  your summer road trip?  Check  out AOL Travel 
>> Guides.   
>>>   
>>>  
>>  
> (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
>>>   ___
>>>  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.
>>>
>>>
>>>
>>>
>>>   
>>> **Planning your summer road trip? Check out AOL  Travel  
> Guides. 
>>
>>>
>>  
> (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
>>>   ___
>>> 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.
>>
>>
>>
>>  
>>
>> **Planning your summer road trip? Check out AOL  Travel Guides. 
>
>>
> (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
>>  ___
>> time-nuts mailing list  -- time-nuts@febo.com
>> To unsubscribe, go to  https://www.febo.com/cgi-bin/mailman/li
> stinfo/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.
> 
> 
> 
> 
> 
> **Planning your summer road trip? Check out AOL Travel Guides.
>   (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
> ___
> 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] using Fury GPSDO with Rb

[Scott Mace]

Turns out this unit has been set so that the EFC was only useful from within a 
.5v range
centered around 2.5v, also the output was TTL.  Trying with a different Rb...

Scott

[EMAIL PROTECTED] wrote:
> Hi Scott,
>  
> a good setting is when the unit recovers in minimal time and with  only minor 
> overshoot from a manual coarsedac change.
>  
> Try dacgain 1000 - 2000.
>  
> TI of 1.2ns / SD 2.2ns is not bad. The M12 errors can be expected to be  
> larger than this over 8 hours.
>  
> bye,
> Said
>  
>  
> In a message dated 4/9/2008 07:06:45 Pacific Daylight Time, [EMAIL PROTECTED] 
>  
> writes:
> 
> I've  been running with dacgain 4000, efcscale 1.2, efcdamping 25, 
> phaseco  15.  It has been locked for about 8 hours (since I started the  
> test).  average TI 1.2ns sd 2.2ns.
> 
> I tried bumping the  coarsedac by 2 increments to see what happens.
> It tries to recover, but  will oscillate wildly after about 45min or so.
> I wonder what will happen  after an extended holdover period.
> 
> It looks like the EFC on this this  FRS-A is more than twice as sensitive 
> as the LPRO.
> 
> Scott
> 
> 
> 
> [EMAIL PROTECTED] wrote:
>> Hello  Scott,
>>  
>> forgot to mention: also try setting the  serv:efcdamping lower. It's an IIR 
>  
>> low pass filter, and will  introduce phase-shift that can cause instability 
> if 
>> it  is set  too high.
>>  
>> bye,
>> Said
>>   
>>  
>> In a message dated 4/8/2008 22:59:22 Pacific Daylight  Time,  
> [EMAIL PROTECTED] 
>> writes:
>>
>> Hello   Scott,
>>
>> this means the gain is set too high so that there is  not enough  phase  
>> margin.
>>
>> You can try to  set the serv:dacgain lower, and  serv:efcs / serv:phaseco  
>>  lower.
>>
>> Contrary to OCXO's, Rb's are  quite stable so  they don't need strong  
>> control, 
>> they just need a   gentle nudge, so you can try starting with low  numbers.
>>
>>  Let me  know if that works,
>> bye,
>> Said
>>
>>  
>>
>>
>> In a message dated  4/8/2008 21:31:50 Pacific  Daylight Time, 
> [EMAIL PROTECTED]   
>> writes:
>>
>>  I've  found that once the units gets into an  overshoot/oscillation  cycle
>> it never  recovers and I have to manually  adjust the  dac to break the 
> cycle.
>> Is the  notion that you use   conservative enough settings so that this
>> neverhappens?
>>
>> Scott
>>
>> [EMAIL PROTECTED]  wrote:
>>> Hi   Scott,
>>>  
>>> let me  reply on this list since other users  are  also using  Rb's.
>>>  
>>> Here is a quick   pointer:
>>>   
>>> 1) determine EFC slope of Rb  (pos =  frequency goes higher with  higher  
>> EFC  
>>> voltage). Set the  slope with serv:efc:slop   [positive/negative]
>>>  
>>> 2)  Determine maximum  frequency  deviation at EFC = 0V (serv:coarsedac  
> 0)   
>>> using a frequency  counter
>>>   
>>>   
>>> 3) Determine maximum frequency   deviation at EFC = 5V  (serv:coarsedac   
> 255)
>>>   
>>> 4) Set  Dacgain  according to table in user manual depending on the   
>>  frequency  
>>> difference between 2) and  3)
>>>   
>>>  5) Set Integral part of loop to  zero: serv:phaseco 0.0, this  helps for  
>  
>>  now
>>>  
>>> 6) Set Proportional part  of loop to a  number that  makes the unit lock 
> as  
>>> quickly  as  desired without oscillation  and overshoot (for example:
>> serv:efcs 1.0 
>>> to serv:efcs  6.0
>>>   
>>> 7)  Set the integral part of the loop so that the   phase is driven to 0ns 
>  
>> UTC  
>>> offset as quickly  as desired without   overshoot/oscillation, for 
> example:   
>>> serv:phaseco   20.
>>>  
>>>  Repeat 6) and 7) after some  hours.
>>>   
>>>  Hope that helps,
>>> bye,
>>>  Said
>>>   
>>>>  -Original Message-
>>>>  From:  Scott Mace
>>>>  Sent:  Saturday, April 05, 2008   17:51
>>>> To: Said  Jackson
>>>> Subject:  Re:   Fury   GPSDO
>>>>
>>>>
>>>> Said,  I finally  got  my fury up  and  running, I'm using a efratom  
>>>> FRS-A and  also a  LPRO-101.
>>>> Do  you  have any recommending starting  points for  tuning the  servo 
>>>> for a  rubidiumunit?
>>>>
>>>>  Scott
>>>>   
>>>  
>>> 

Re: [time-nuts] using Fury GPSDO with Rb

[Scott Mace]

I've been running with dacgain 4000, efcscale 1.2, efcdamping 25, 
phaseco 15.  It has been locked for about 8 hours (since I started the 
test).  average TI 1.2ns sd 2.2ns.

I tried bumping the coarsedac by 2 increments to see what happens.
It tries to recover, but will oscillate wildly after about 45min or so.
I wonder what will happen after an extended holdover period.

It looks like the EFC on this this FRS-A is more than twice as sensitive 
as the LPRO.

Scott



[EMAIL PROTECTED] wrote:
> Hello Scott,
>  
> forgot to mention: also try setting the serv:efcdamping lower. It's an IIR  
> low pass filter, and will introduce phase-shift that can cause instability if 
> it  is set too high.
>  
> bye,
> Said
>  
>  
> In a message dated 4/8/2008 22:59:22 Pacific Daylight Time,  [EMAIL 
> PROTECTED] 
> writes:
> 
> Hello  Scott,
> 
> this means the gain is set too high so that there is not enough  phase  
> margin.
> 
> You can try to set the serv:dacgain lower, and  serv:efcs / serv:phaseco  
> lower.
> 
> Contrary to OCXO's, Rb's are  quite stable so they don't need strong  
> control, 
> they just need a  gentle nudge, so you can try starting with low  numbers.
> 
> Let me  know if that works,
> bye,
> Said
> 
> 
> 
> 
> In a message dated  4/8/2008 21:31:50 Pacific Daylight Time, [EMAIL 
> PROTECTED]   
> writes:
> 
> I've  found that once the units gets into an  overshoot/oscillation cycle
> it never  recovers and I have to manually  adjust the dac to break the cycle.
> Is the  notion that you use  conservative enough settings so that this
> never   happens?
> 
> Scott
> 
> [EMAIL PROTECTED] wrote:
>> Hi   Scott,
>>  
>> let me reply on this list since other users  are  also using Rb's.
>>  
>> Here is a quick  pointer:
>>   
>> 1) determine EFC slope of Rb (pos =  frequency goes higher with  higher  
> EFC 
>> voltage). Set the  slope with serv:efc:slop  [positive/negative]
>>  
>> 2)  Determine maximum frequency  deviation at EFC = 0V (serv:coarsedac  0)  
>> using a frequency  counter
>>  
>>   
>> 3) Determine maximum frequency  deviation at EFC = 5V  (serv:coarsedac  255)
>>
>>   
>> 4) Set  Dacgain according to table in user manual depending on the   
> frequency  
>> difference between 2) and 3)
>>   
>>  5) Set Integral part of loop to zero: serv:phaseco 0.0, this  helps for   
> now
>>  
>> 6) Set Proportional part  of loop to a number that  makes the unit lock as  
>> quickly  as desired without oscillation  and overshoot (for example:   
> serv:efcs 1.0 
>> to serv:efcs  6.0
>>  
>> 7)  Set the integral part of the loop so that the  phase is driven to 0ns  
> UTC  
>> offset as quickly as desired without   overshoot/oscillation, for example:  
>> serv:phaseco   20.
>>  
>> Repeat 6) and 7) after some  hours.
>>   
>> Hope that helps,
>> bye,
>>  Said
>>  
>>>  -Original Message-
>>>  From: Scott Mace
>>>  Sent:  Saturday, April 05, 2008  17:51
>>> To: Said  Jackson
>>> Subject: Re:   Fury  GPSDO
>>>
>>>
>>> Said,  I finally got  my fury up  and  running, I'm using a efratom 
>>> FRS-A and  also a  LPRO-101.
>>> Do you  have any recommending starting  points for  tuning the servo 
>>> for a  rubidium   unit?
>>>
>>>  Scott
>>>  
>>  
>>  
>>
>>
>> **Planning your summer  road trip? Check  out AOL Travel 
> Guides. 
> 
>>
> (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
>>   ___
>> 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.
> 
> 
> 
> 
> 
> **Planning  your summer road trip? Check out AOL Travel Guides.   
>  
> (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
> ___
> 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.
> 
> 
> 
> 
> 
> **Planning your summer road trip? Check out AOL Travel Guides.
>   (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
> ___
> 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] using Fury GPSDO with Rb

[Scott Mace]

I've found that once the units gets into an overshoot/oscillation cycle
it never recovers and I have to manually adjust the dac to break the cycle.
Is the notion that you use conservative enough settings so that this
never happens?

Scott

[EMAIL PROTECTED] wrote:
> Hi Scott,
>  
> let me reply on this list since other users are also using Rb's.
>  
> Here is a quick pointer:
>  
> 1) determine EFC slope of Rb (pos = frequency goes higher with higher  EFC 
> voltage). Set the slope with serv:efc:slop [positive/negative]
>  
> 2) Determine maximum frequency deviation at EFC = 0V (serv:coarsedac 0)  
> using a frequency counter
>  
>  
> 3) Determine maximum frequency deviation at EFC = 5V (serv:coarsedac  255)
> 
>  
> 4) Set Dacgain according to table in user manual depending on the frequency  
> difference between 2) and 3)
>  
> 5) Set Integral part of loop to zero: serv:phaseco 0.0, this helps for  now
>  
> 6) Set Proportional part of loop to a number that makes the unit lock as  
> quickly as desired without oscillation and overshoot (for example:  serv:efcs 
> 1.0 
> to serv:efcs 6.0
>  
> 7) Set the integral part of the loop so that the phase is driven to 0ns UTC  
> offset as quickly as desired without overshoot/oscillation, for example:  
> serv:phaseco 20.
>  
> Repeat 6) and 7) after some hours.
>  
> Hope that helps,
> bye,
> Said
>  
>> -Original Message-
>> From: Scott Mace
>> Sent:  Saturday, April 05, 2008 17:51
>> To: Said Jackson
>> Subject: Re:  Fury GPSDO
>>
>>
>> Said,  I finally got my fury up and  running, I'm using a efratom 
>> FRS-A and also a LPRO-101.
>> Do you  have any recommending starting points for tuning the servo 
>> for a  rubidium unit?
>>
>>  Scott
>>  
> 
> 
> 
> 
> **Planning your summer road trip? Check out AOL Travel Guides.
>   (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
> ___
> 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] using Fury GPSDO with Rb

[Scott Mace]

Here's what I've been using over the weekend:

Efratom FRS-A

DAC GAIN: 5000.00
EFC SCALE: 0.50
EFC DAMPING: 25
OCXO SLOPE: POSITIVE
PHASE CORRECTION: 0.50

I think the FRS-A is adjustable from +-1.2e-9.

So far it seems to keep it within +-3ns from GPS.

Scott


[EMAIL PROTECTED] wrote:
> Hi Scott,
>  
> let me reply on this list since other users are also using Rb's.
>  
> Here is a quick pointer:
>  
> 1) determine EFC slope of Rb (pos = frequency goes higher with higher  EFC 
> voltage). Set the slope with serv:efc:slop [positive/negative]
>  
> 2) Determine maximum frequency deviation at EFC = 0V (serv:coarsedac 0)  
> using a frequency counter
>  
>  
> 3) Determine maximum frequency deviation at EFC = 5V (serv:coarsedac  255)
> 
>  
> 4) Set Dacgain according to table in user manual depending on the frequency  
> difference between 2) and 3)
>  
> 5) Set Integral part of loop to zero: serv:phaseco 0.0, this helps for  now
>  
> 6) Set Proportional part of loop to a number that makes the unit lock as  
> quickly as desired without oscillation and overshoot (for example:  serv:efcs 
> 1.0 
> to serv:efcs 6.0
>  
> 7) Set the integral part of the loop so that the phase is driven to 0ns UTC  
> offset as quickly as desired without overshoot/oscillation, for example:  
> serv:phaseco 20.
>  
> Repeat 6) and 7) after some hours.
>  
> Hope that helps,
> bye,
> Said
>  
>> -Original Message-
>> From: Scott Mace
>> Sent:  Saturday, April 05, 2008 17:51
>> To: Said Jackson
>> Subject: Re:  Fury GPSDO
>>
>>
>> Said,  I finally got my fury up and  running, I'm using a efratom 
>> FRS-A and also a LPRO-101.
>> Do you  have any recommending starting points for tuning the servo 
>> for a  rubidium unit?
>>
>>  Scott
>>  
> 
> 
> 
> 
> **Planning your summer road trip? Check out AOL Travel Guides.
>   (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316)
> ___
> 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] Wanted to buy or borrow -- RFTG-m-XO L106A

[Scott Mace]

I have experimented with several of the RFG units and found that
the XOs will not clear the fault light if the OCXO has drifted
too far.  I was able to manually trim them and they worked well
again.  Perhaps a similar problem with your RFTG.


Scott

John Ackermann N8UR wrote:
> I'm not sure what's going on.  I ran my XO/RB pair for 30 days, using
> the "official" interconnect cable with the monitoring software
> indicating no problems.  I took phase data from the RB output via the
> TSC and fed it into Stable32 (by the way, with a 20 second timeout, the
> 30 day TSC data capture worked fine).
> 
> The results show a reasonably constant +1.5 microsecond slope over 30
> days, about 6x10e-13 offset.  There's no characteristic cliff in the
> ADEV where the GPS kicks in, but yet the offset is better than I would
> expect from the LPRO running in standalone mode.  Plots are at
> http://www.febo.com/pages/oscillators/rftg/
> 
> I then pulled power on the RB unit and instead of going into proper XO
> operation, I got "NO GPS" and "FAULT" on the XO.  In separate
> experiments, pulling the interface cable or the 10 MHz cable result in
> the same faults -- the XO doesn't seem to take over as it should.
> 
> And, when I measure the XO output, it is just horrible -- ADEV in the 9s
> from 0.1 second out past 10,000 seconds.
> 
> I wonder -- has ANYONE gotten the -XO module to work in GPS-disciplined
> mode???
> 
> John
> 
> Tom Van Baak said the following on 03/15/2008 03:25 PM:
>>> I suspect the XO module in my RFTG setup is defective, so I'd like to
>>> find another one.  It needs to be the "L106A" (not "B") version to mate
>>> with my -RB (L105A) unit.
>>>
>>> Anyone have one they'd like to sell?  Or, failing that, one I could
>>> borrow to test in my system?
>> John,
>>
>> Interesting, my RFTG pair won't lock right either; I'm thinking
>> my XO module has a problem too. Do you think we're making
>> the same mistake or are both of our XO modules faulty?
>>
>> /tvb
>>
>>
>> ___
>> 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] Setting Rubidium to match GPS source

[Scott Mace]

); SAEximRunCond expanded to false
Errors-To: [EMAIL PROTECTED] RETRY

Put me on the list.  I'm interested in using it with LPRO-101 units.

Scott

[EMAIL PROTECTED] wrote:
> ); SAEximRunCond expanded to false
> Errors-To: [EMAIL PROTECTED] RETRY
> 
>  
> In a message dated 9/28/2007 02:07:08 Pacific Daylight Time,  
> [EMAIL PROTECTED] writes:
> 
>> In  this context, how stable is a GPSDO?  If I used a Cesium for the sync  
>> input, how much fuzz would I see on a GPSDO output if I watched it  wander 
>> back and forth for a day?
> 
> 
> 
> 
> Hi guys,
>  
> forgot to mention: the Fury GPSDO is now available as an OEM PCB with  SMA 
> connectors to connect an external OCXO, rather than have one on-board. Any  
> steerable 10MHz Oscillator will work, such as Rb's, and even Cesiums with EFC 
>  
> input.
>  
> Would anyone be interested in these PCB's as a building block for a "home  
> made" GPSDO? All that needs to be done is connect an OCXO you may  have 
> laying 
> around using the SMA connections, add power and antenna, and  the hardware is 
> done. The software can be adjusted to match and  fine-tune different OCXO 
> parameters via an RS-232 terminal, and SCPI  (English language) commands.
>  
> We are planning to offer these for slightly less than $600 each, and if  
> enough interest is here then we may be able to offer a discount for  
> time-nuts.
>  
> Let me know,
> thanks,
> Said
> 
> 
> 
> 
> ** See what's new at http://www.aol.com
> ___
> 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] time-nuts, frequency counters

[Scott Mace]

); SAEximRunCond expanded to false
Errors-To: [EMAIL PROTECTED] RETRY

I picked up one of the Lucent RFG-RB units on ebay and sure enough it was
off, but not by much.  It was manufactured mid 2001.  I adjusted the
C-field pot while comparing it to my best z3801a.  I'm waiting on a
new GPIB interface to see just how well I did.  The LPRO-101 in the
RFG-RB makes about 15W of heat.  I gently clamped it to the back heatsink
of the RFG unit and left it on for an hour or two before adjusting with
my counter in TI mode. I thought about drilling a small hole in the top
of the RFG chassis so I could access the C-field pot, but decided I just
liked taking the thing apart...

Scott

David Forbes wrote:
> CHazlitt wrote:
>> So, here is my question, do Rubidium standards drift that much over a period 
>> of years to where they have to be brought back on frequency? If so, what is 
>> tuned on the Rubidium to do so, C-field? 
> 
> Yes, they do drift over time. There is a spec provided on the data 
> sheet; you can expect the unit to drift at perhaps half of that 
> specified maximum rate. You can adjust the magnetic field to bring it 
> back to center frequency, but sometimes they drift so much (over >10 
> years) that you have to replace a factory-selected resistor to get the 
> trimmer into range.
> 
> The only type of commercially available frequency standard that doesn't 
> drift is a cesium beam clock; their frequency of operation doesn't 
> depend on magnetic fields or buffer gas pressure or anything like that. 
> That's why they're used for GPS etc.
> 
> ___
> 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] Symmetricom splitter delay

[Scott Mace]

Has anyone measured the delay through a symmetricom 090-58537-01 4-port 
splitter?
The spec sheet says ~40ns, which seems kind of high.

Scott

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