Looking for 468-DC GOES receiver info
I was just fiddling with a 468-DC GOES receiver that had been knocked
out of alignment by last summer's hurricanes. Thanks to TVB for
http://www.leapsecond.com/museum/468-dc/theory.htm
which helped immensely (particularly the bit about TP2 and the unlock LED).
I know GOES time is now in legacy mode with only +/-1 ms accuracy,
but I thought it would be fun to hook it up to an NTP server anyway.
I have satellite lock, time displayed, and 1 PPS and 1 kHz coming out the
back. However, I don't see anything on the IRIG output or the serial port.
(And the EXT OSC input is a mystery.)
Looking at the NTP driver, I tried connecting at 9600 8N1 and sending
various letters, but no response. (The port probed as DTE, so I used
a crossover cable.)
Does anyone have any use or debugging information or manuals?
Thanks!
Hi Kevin,
I can send you a 468-DC manual but you may have
missed the announcement that after 30 years the
GOES timecode was turned off. So you can still get
RF lock and the 100 Hz subcode is there there but
the NIST timecode portion of the timecode is no
longer present.
http://www.boulder.nist.gov/timefreq/service/goesnotice.htm
If you're getting a UTC time out of yours let me know
(and East or West?); mine went off the air on Jan 1
and they're still dead.
/tvb
----- Original Message -----
From: kevin-usenet@horizon.com
To: time-nuts@febo.com
Sent: Wednesday, February 16, 2005 21:53
Subject: [time-nuts] Looking for 468-DC GOES receiver info
I was just fiddling with a 468-DC GOES receiver that had been knocked
out of alignment by last summer's hurricanes. Thanks to TVB for
http://www.leapsecond.com/museum/468-dc/theory.htm
which helped immensely (particularly the bit about TP2 and the unlock
LED).
I know GOES time is now in legacy mode with only +/-1 ms accuracy,
but I thought it would be fun to hook it up to an NTP server anyway.
I have satellite lock, time displayed, and 1 PPS and 1 kHz coming out the
back. However, I don't see anything on the IRIG output or the serial
port.
(And the EXT OSC input is a mystery.)
Looking at the NTP driver, I tried connecting at 9600 8N1 and sending
various letters, but no response. (The port probed as DTE, so I used
a crossover cable.)
Does anyone have any use or debugging information or manuals?
Thanks!
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Tom -
If you remember I wrote to you about problems with my GOES 468DC problems
some months ago stating I lost lock. Well, after a few days it came back on.
Since then it has still been intermittent on the East bird. At one point
about a week ago I totally lost it long enough that the display went blank.
So, for a few days all there was were the blinking LEDs. Then, it
re-acquired, came up with the proper day and time and has been running ever
since. So, for now at least, it still seems to be working for me. Regards -
Mike
Mike B. Feher, N4FS
89 Arnold Blvd.
Howell, NJ, 07731
732-886-5960
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Tom Van Baak
Sent: Thursday, February 17, 2005 8:42 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Looking for 468-DC GOES receiver info
Hi Kevin,
I can send you a 468-DC manual but you may have
missed the announcement that after 30 years the
GOES timecode was turned off. So you can still get
RF lock and the 100 Hz subcode is there there but
the NIST timecode portion of the timecode is no
longer present.
http://www.boulder.nist.gov/timefreq/service/goesnotice.htm
If you're getting a UTC time out of yours let me know
(and East or West?); mine went off the air on Jan 1
and they're still dead.
/tvb
----- Original Message -----
From: kevin-usenet@horizon.com
To: time-nuts@febo.com
Sent: Wednesday, February 16, 2005 21:53
Subject: [time-nuts] Looking for 468-DC GOES receiver info
I was just fiddling with a 468-DC GOES receiver that had been knocked
out of alignment by last summer's hurricanes. Thanks to TVB for
http://www.leapsecond.com/museum/468-dc/theory.htm
which helped immensely (particularly the bit about TP2 and the unlock
LED).
I know GOES time is now in legacy mode with only +/-1 ms accuracy,
but I thought it would be fun to hook it up to an NTP server anyway.
I have satellite lock, time displayed, and 1 PPS and 1 kHz coming out the
back. However, I don't see anything on the IRIG output or the serial
port.
(And the EXT OSC input is a mystery.)
Looking at the NTP driver, I tried connecting at 9600 8N1 and sending
various letters, but no response. (The port probed as DTE, so I used
a crossover cable.)
Does anyone have any use or debugging information or manuals?
Thanks!
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Hi:
In still in the process of setting the C field on my FTS-4060 and have an interesting observation. After a cockpit error where I made a change in the wrong direction the time interval plot was going up steeply. In line with my latest theory of how to make the adjustment (which is to do a binary search rather than try and compute the required adjustment) I then set in a new value. I thought I saw a time constant of about 3 hours (i.e. it took about 3 hours to get to 63% of what I thought was the final value).
The next day (24 hours later) for about 8 hours the time interval was constant to within 10 nano seconds, phenomenally stable operation.
Now 3 days after that I can see that the time interval has a down slope. So the very stable operation 24 hours after the C field change was during the time when the frequency was changing and was at the level part of the curve.
This indicates that for a C field change on the FTS4060 you need to wait at least 2 or 3 days before making any measurements!
This also may explain why trying to compute the amount of a change does not seem to work. This would be the case if the effect of the prior change had not yet settled in.
Have Fun,
Brooke Clarke, N6GCE
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com
Brooke, I've been seeing something similar myself. Last weekend I
posted a message with an attached plot vs GPS that showed similar
behaviour with a significant change in slope a couple of days after
changing the C field. And, I lost the green "continuous operation"
light at the time of the change (I was running with the long 60 second
time constant, which will knock out of lock very easily).
A new plot (check
http://www.febo.com/time-freq/plots/hp5061a-n8ur_1.html) against the
quieter of my two Z3801As is showing better behaviour now that the last
C field adjustment is over a week ago, but even there it appears there's
an initial downward slope that levels out.
John
Brooke Clarke wrote:
Hi:
In still in the process of setting the C field on my FTS-4060 and have
an interesting observation. After a cockpit error where I made a change
in the wrong direction the time interval plot was going up steeply. In
line with my latest theory of how to make the adjustment (which is to do
a binary search rather than try and compute the required adjustment) I
then set in a new value. I thought I saw a time constant of about 3
hours (i.e. it took about 3 hours to get to 63% of what I thought was
the final value).
The next day (24 hours later) for about 8 hours the time interval was
constant to within 10 nano seconds, phenomenally stable operation.
Now 3 days after that I can see that the time interval has a down
slope. So the very stable operation 24 hours after the C field change
was during the time when the frequency was changing and was at the level
part of the curve.
This indicates that for a C field change on the FTS4060 you need to wait
at least 2 or 3 days before making any measurements!
This also may explain why trying to compute the amount of a change does
not seem to work. This would be the case if the effect of the prior
change had not yet settled in.
Have Fun,
Brooke Clarke, N6GCE
Hi John:
The only reason I saw this was because the plot had a steep positive
slope, then 24 hours later appeared to be perfect, now a few days after
that obviously has a negative slope. My initial estimate of the time
constant, based on the perfect performance, of 1 tau = 3 hours, was way
off. The real tau is more like 1 day. So I'll wait another day before
making the next adjustment.
Do you have plots that cover longer time periods?
Have Fun,
Brooke
John Ackermann N8UR wrote:
Brooke, I've been seeing something similar myself. Last weekend I
posted a message with an attached plot vs GPS that showed similar
behaviour with a significant change in slope a couple of days after
changing the C field. And, I lost the green "continuous operation"
light at the time of the change (I was running with the long 60 second
time constant, which will knock out of lock very easily).
A new plot (check
http://www.febo.com/time-freq/plots/hp5061a-n8ur_1.html) against the
quieter of my two Z3801As is showing better behaviour now that the
last C field adjustment is over a week ago, but even there it appears
there's an initial downward slope that levels out.
John
Brooke Clarke wrote:
Hi:
In still in the process of setting the C field on my FTS-4060 and
have an interesting observation. After a cockpit error where I made
a change in the wrong direction the time interval plot was going up
steeply. In line with my latest theory of how to make the adjustment
(which is to do a binary search rather than try and compute the
required adjustment) I then set in a new value. I thought I saw a
time constant of about 3 hours (i.e. it took about 3 hours to get to
63% of what I thought was the final value). The next day (24 hours
later) for about 8 hours the time interval was constant to within 10
nano seconds, phenomenally stable operation.
Now 3 days after that I can see that the time interval has a down
slope. So the very stable operation 24 hours after the C field
change was during the time when the frequency was changing and was at
the level part of the curve.
This indicates that for a C field change on the FTS4060 you need to
wait at least 2 or 3 days before making any measurements! This also
may explain why trying to compute the amount of a change does not
seem to work. This would be the case if the effect of the prior
change had not yet settled in.
Have Fun,
Brooke Clarke, N6GCE
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Brooke Clarke wrote:
Hi John:
The only reason I saw this was because the plot had a steep positive
slope, then 24 hours later appeared to be perfect, now a few days after
that obviously has a negative slope. My initial estimate of the time
constant, based on the perfect performance, of 1 tau = 3 hours, was way
off. The real tau is more like 1 day. So I'll wait another day before
making the next adjustment.
Do you have plots that cover longer time periods?
I've done lots of short runs while tweaking this thing... I plan to let
the current run go until at least early next week, when I want to do
some equipment reconfiguration that will require shutting the counter
(but not the Cs) off.
I just acquired three HP 5334A counters (great TICs with 2ns resolution,
1U rack height, and no fan -- and in the $125 range on eBay) to use for
long-term monitoring. I plan to monitor the 5061A continuously vs. GPS,
and the 5065A Rb vs. the 5061A. That'll free the 5370B up from one-off
measurements where I can use the better resolution to get results more
quickly.
John
Hi:
The C field has been set at 570 since the night of 20 Feb. and I haven't seen any drift, but the average of 1,000 time interval measurements from the GPS 1 PPS to the 1 MHz output has quite a bit of wandering which I'm convinced is caused by something related to the GPS. One way to see that is to also look at the LORAN-C data which is on the bottom of the plot. The gap in the LORAN-C data was caused by the Middletown station shutting down while they switched over to the solid state power amplifier.
Another clue that it's GPS based is to notice that the time of day when the big changes occur are about the same. The major lines are each at midnight. Maybe it's related to which GPS satellites are being used?
I have the receiver set for the 4 highest and a 30 degree elevation mask, but maybe should increase the elevation mask even higher?
http://www.pacificsites.com/~brooke/pdf/sn1227_CF570.pdf
Have Fun,
Brooke Clarke, N6GCE
--
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com
In message 4223C82C.4030108@pacific.net, Brooke Clarke writes:
Another clue that it's GPS based is to notice that the time of day
when the big changes occur are about the same. The major lines are
each at midnight. Maybe it's related to which GPS satellites are
being used?
Have you tried setting a mask-angle in your GPS ?
Try 10 or 15 degree depending on how cluttered your horizon is.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Its possible, its multipath. Depending on your receiver, you can shut
off reception from individual GPS PRNs. Check to see which ones are in
use at the time, and then turn one off. 12 Hours later, turn it back on
and turn off another, etc.
Also, if you can turn off GPS PRNs, you can pick at time common with
NIST and use the GPS archive at
http://www.boulder.nist.gov/timefreq/service/gpstrace.htm to compare
time (use view track to see one satellite by itself).
Poul-Henning Kamp wrote:
In message 4223C82C.4030108@pacific.net, Brooke Clarke writes:
Another clue that it's GPS based is to notice that the time of day
when the big changes occur are about the same. The major lines are
each at midnight. Maybe it's related to which GPS satellites are
being used?
Have you tried setting a mask-angle in your GPS ?
Try 10 or 15 degree depending on how cluttered your horizon is.