If you've come here to find another (?) exciting, sexy weblog full of observations both witty and meaningful, you've come to the wrong place. I don't have any reason to believe that you'd find anything in my life very interesting.
This blog has one simple purpose: to be my on-line logbook for data from my experiments in ham radio and time/frequency measurement. If you want to know when I last adjusted the frequency of my Rubidium standard, then this is the place to be. Otherwise, forget it.
jra on 08.03.03 @ 10:11 AM EDT [link]
John's Geekblog
Sunday, October 26th
jra on 10.26.08 @ 12:01 PM EDT [link]
jra on 10.26.08 @ 12:37 AM EDT [link]
HP 5065A C-Field Sensitivity
| C Field | Frequency | Offset |
| HP 5065A #1 (SN 2816A01640) | ||
| 0.00 | 4.999 999 998 030 | -3.94e-10 |
| 4.00 | 5.000 000 002 226 | +4.45e-10 |
| 5.00 | 5.000 000 003 279 | +6.56e-10 |
| 6.00 | 5.000 000 004 334 | +8.66e-10 |
| 9.99 | 5.000 000 008 199 | +1.64e-9 |
jra on 10.26.08 @ 12:01 PM EDT [link]
HP 5061A C-Field Sensitivity
While trying to get the atomics trimmed, I decided to do an experiment. Using a Z3801A 10 MHz output as reference, and the TSC-5120 in frequency counter mode, I get the following frequency offsets for a 1000 second average:
| C Field | Frequency | Offset | ||
| HP 5061A #1 (SN 2428A02300) | ||||
| 0.00 | 4.999 999 999 916 | -1.7e-11 | ||
| 4.00 | 4.999 999 999 992 | -1.6e-12 | 5.004.999 999 999 997 | -6.0e-13 |
| 6.005.000 000 000 025 | +5.0e-12 | |||
| 9.99 | 5.000 000 000 102 | +2.0e-11 | ||
| HP 5061A #2 (SN 1248A00857) | ||||
| 0.00 | 4.999 999 999 945 | -1.1e-11 | ||
| 4.00 | 4.999 999 999 973 | -5.4e-12 | ||
| 5.00 | 5.000 000 000 003 | +6.0e-13 | ||
| 6.00 | 5.000 000 000 015 | +3.0e-12 | ||
| 9.99 | 5.000 000 000 051 | +1.0e-11 |
jra on 10.26.08 @ 12:37 AM EDT [link]
Saturday, October 25th
Resetting the Clocks
We had a lengthy power outage in Sepember, 2008, due to the remnants of Hurricane Ike passing through Ohio with 70+ MHP winds. The 7+ day outage outran the new, improved UPS, so all the clocks cooled down. It seemed wise to use the opportunity for some maintenance, so thanks to instructions from Corby Dawson, I've re-aligned CS1, CS2, and RB1. They are now back on-line.
The nominal PPS time (early from GPS PPS, via CNS II clock with 100 second average) is:
CS1: 11.119us (note: CS1 is now running in short time-constant mode)
CS2: 20.501us
RB1: 499.686us
jra on 10.25.08 @ 07:23 PM EDT [link]
Sunday, December 9th
Another clock reset
We had another power outage that let the clocks cool. (I now have two 100 AH gel cells ready to power tCS1, CS2, and RB1 in case this happens again, but they're not online yet.)
Clocks reset to:
RB1 460 us early
CS1 10 us early
CS2 20 us early
I'm also trying to run CS2 in long time constant mode again; not sure if it will work out as last time I couldn't trim the frequency in LTC.
jra on 12.09.07 @ 04:11 PM EDT [link]
Friday, November 2nd
Clocks Reset
On November 1, we had a power outage that was a little more than my current UPS system (scheduled for improvement!) could handle. The HP 5065A and two HP 5061As lost power and as a result my current comparisons against GPS had to end. I've now reset the three clocks.
CS1 is running about 10.3 uS early.
CS2 is running about 19.7 uS early.
RB1 is running about 500.2 uS early.
jra on 11.02.07 @ 08:40 PM EDT [link]
GPIB Coax Switch Positions
In the clock rack, I have an HP 59503 GPIB-controlled coax switch that routes the various PPS sources to the HP 5334A counter. Here are the switch positions:
Bank A and Bank B
1 CS1
2 CS2
3 RB1
4 PPS from CNS II
jra on 11.02.07 @ 08:11 PM EDT [link]
Saturday, April 21st
New UPS(s)
I've had several small UPS units behind my standards and my servers for several years, but the batteries were becoming questionable and I wanted to consolidate things a bit.
So, I acquired two APC SmartNet line interactive UPS units (model SU1200RMLXNet to be exact). They each have three external rack-mount battery packs, so there are a total of 28 12 volt, 17 amp-hour gel-cells in each.
Unit #1, which runs my two main T&F racks with GPS, WWVB and Loran receivers; several OCXOs; counters, synthesizers, and other gadgets; and several computers (mainly low-power single board timeservers), has a standby power load of about 40% of capacity; if I turn all the synths and counters on, that rises to nearly 80% (the HP 5370B and 5369A are by far the biggest power hogs).
After running the calibrate command on #1, which runs the batteries down to about 25% to measure their true capacity, the UPS shows that at 39.5% capacity it has a run-time of 1105 minutes (18 hours, 25 minutes). Its fully-charged battery voltage is 54.55 volts.
jra on 04.21.07 @ 08:14 AM EDT [link]
Friday, April 13th
LORAN-C Timing
I'm gradually getting the racks back together and today got the LORAN-C system running again. My new Austron 2010B disciplined oscillator is paired with the Austron 2100T receiver. I am tracking LORSTA Dana, Indiana (Master, GRI 89700). I established PPS sync and a initial measurement of the Fixed PPS output versus GPS (CNS-II, hardware sawtooth correction) is that PPS(LORAN Fixed) is 999.500 039 microseconds behind PPS(GPS) (1000 second average). I'll need to revisit this once everything is stabilized.
jra on 04.13.07 @ 05:55 PM EDT [link]
Sunday, April 8th
Loran Station Bearings and Distances
Distance from my location (39 42 48.805N, 84 10 20.384W) to some LORAN-C stations, calculated via Great Circle method at http://www.fcc.gov/mb/audio/bickel/distance.html:
Dana, Indiana (39 57 07.658N, 87 29 11.586W): 276.42 degrees, 284.182KM, 176.583M
Seneca, NY (42 42 50.716N, 76 49 33.308W): 59.11 degrees, 698.780KM, 434.202M
Baudette, MN (48 36 49.947N, 94 33 17.915W): 323.60 degrees, 1287.899KM, 800.263M
Carolina Beach, NC (34 03 46.17N, 77 54 46.21W): 136.54 degrees, 838.883KM, 521.258M
jra on 04.08.07 @ 02:40 PM EDT [link]
LORAN-C Timing
I'm gradually getting the racks back together and today got the LORAN-C system running again. My new Austron 2010B disciplined oscillator is paired with the Austron 2100T receiver. I am tracking LORSTA Dana, Indiana (Master, GRI 89700). I established PPS sync and a initial measurement of the Fixed PPS output versus GPS (CNS-II, hardware sawtooth correction) is that PPS(LORAN Fixed) is 999.500 039 microseconds behind PPS(GPS) (1000 second average). I'll need to revisit this once everything is stabilized.
jra on 04.08.07 @ 01:56 PM EDT [link]
Sunday, April 1st
TADD distribution amps on line
Thanks to nice metalwork by Bruce, KA8EDE, I have two TADD-1s mounted in a 1U chassis to serve as primary distribution in my measurement rack. They are both adjusted for 0 dB gain at 5 MHz (using a reference signal at about +11 dBm). At 10MHz with a +12dBm reference signal, they appear to have perhaps 0.2 dB gain.
jra on 04.01.07 @ 09:19 AM EDT [link]
Wednesday, March 14th
GPS antenna system total delay
Having done all the measurements shown in the previous entries, the total delay of the GPS antenna system should be:
LMR -400 antenna feedline to 2-port splitter: 56.06 ns
2 port splitter: 23 ns
LMR-400 jumper from 2-port splitter to 8 port splitter: 9.4 ns
8 port splitter: 15 ns
10 foot LMR-240 jumper from splitter to receiver: 12.55 nanoseconds.
Total: 116.01 ns.
This doesn't include any delay due to filtering in the antenna itself. The Motorola 2000 Timing antenna has a dual filter. It's only an assumption, but if the filter elements are similar to those in the GPS splitters, we can assume 15 to 25 nanoseconds of delay in each stage. Again, this is only a guess at this point, but I am adding ~30 nanoseconds to compensate for this, and forgetting about any precision past a few nanoseconds!
So, the "antenna delay" value I enter into the GPS receivers will be 145 nanoseconds.
jra on 03.14.07 @ 02:12 PM EDT [link]
Monday, March 12th
GPS cables
I made up six nominally 10 foot cables to feed from the 8-way antenna splitter to the various receivers. All are LMR-240 and have an N connector on the splitter end. The other ends are two each N, BNC, and TNC.
I tested using the HP 5370, feeding a 1ms pulse to a tee at the start input, then through a 4 foot cable with appropriate adapters to the cable under test, and another 4 foot cable to the stop input. I measured 100K samples and used the mean value.
The baseline (4 foot cables with BNCs, each with a BNC female to N female adapter, and an N female barrel) measured 12.759 ns. The N barrel was about 1 inch long, so let's subtract 0.1ns to get to 12.659 ns (our first note of imprecision!).
The two N cables should have the best accuracy, since they simply substituted for the barrel. Cable 1 measured 25.204 ns and cable 2 was 25.219 ns. Subtracting the baseline:
#1 is 12.545 ns
#2 is 12.560 ns
The two TNC cables were the toughest because I didn't have a BNC female to TNC female tweenie. Instead, I had to use a BNC female to TNC male, plus the ends of a TNC tee. As a result, the test fixture was about 1 inch longer than for the N cables. So, we need to subtract about 0.1 ns to compensate for that. Cable 3 measured 25.348 ns and cable 4 measured 25.339 ns. After subtracting 0.1ns and subtracting the baseline:.
#3 is 12.589 ns
#4 is 12.580 ns
For the final BNC cables, the BNC-N adapter was replaced with a BNC female barrel. The fixture length is about the same, so I'll make no correction for it. Cable 5 measured 25.187 ns and cable 6 was 25.207 ns. Subtracting the baseline:
#5 is 12.528 ns
#6 is 12.548 ns
So, across 6 cables the spread is 12.528 to 12.589 ns -- 61 picoseconds. The fact that the two longest cables are the TNC lead me to suspect that my guess of the fixture length is a bit off there, and that the spread is thus somewhat less, but I'm not going to worry about that. Officially, all six cables will be tagged as 12.55 nanoseconds.
Thanks to spousal unit Jody (KC8KDC) for help in getting the cables measured so closely!
jra on 03.12.07 @ 07:52 PM EDT [link]
Sunday, March 4th
GPS Antenna Delay
Time from GPS Antenna to N connector through LMR-400 is 56.06 nanoseconds, according to Tom the RF applications engineer. That translates to physical length of 45.973 feet (based on measured velocity factor).
Delay from antenna port to port 1 of HP 58517A 8 port splitter is 14.7 ns in center of passband, about 20 ns at the edges. Other ports very similar, but port 5 has weird peak outside the passband.
HP 58535A 2 port splitter, antenna to port 1 is 22.8 ns at center and about 26 ns at edges, gain about 1.1dB. Port 2 basically the same.
jra on 03.04.07 @ 04:28 PM EDT [link]
Monday, February 26th
CNS Clock II data
I recently acquired a CNS Clock II GPS with the high-performance PPS output that corrects the GPS sawtooth in hardware. Before implementing it, I thought I would measure the delay of its three PPS outputs, and also measure the added delay when running the PPS through a TADD-3 distribution board.
The front panel 1/100 PPS output seems to fire earliest. The rear panel 1/100 PPS output is about 1.4 nanoseconds slow, and the rear panel 1 PPS output is about 2.2 nanoseconds slow.
When routing the rear 1/100 PPS output to a TADD-1 through about 12 inches of cable, the TADD outputs are 26 to 27 nanoseconds slow compared to the front panel 1/100 PPS output.
jra on 02.26.07 @ 07:15 PM EDT [link]
Long-term data gathering experiment
I just finished a long run measuring CS1, CS2, and RB1 against GPS and each other. All the analysis is at www.febo.com/time-freq/three-standards.
jra on 02.26.07 @ 07:12 PM EDT [link]
Sunday, July 23rd
Tweaking RB1
I haven't touched the 5065A since February, and it's now about 4x10-12 low. So I'm moving it from 1.84 to 1.88 (two minor divisions). That might be a slight overcompensation, but I'll let things run for a while and then recheck.
UPDATE: That was a bit too much so I moved back 1/2 minor division, to 1.87.
jra on 07.23.06 @ 12:08 PM EDT [link]
Saturday, July 22nd
Timing Updates
After almost 90 days of data collection from the three standards versus GPS and each other, I reset things today, mainly because RB1 had drifted behind GPS and that caused the counter triggering to be goofed up. I also tweaked CS1 very slightly.
After setting the C field to 4.98, CS1 had been running about -7x10-13. I nudged that up a tiny bit to 5.05 (which was a bit high before, but seems like it should be about right based on current data).
In order to provide more adjustment range, I changed GPSDO2 (one of the Z3801As) to run 500us early (it had been 10us early); that combined with the 5359 time synthesizer will give me plenty of range to set the various clocks to the proper relative delays.
I've reset RB1 to be the full 500us early. CS1 is set to be 10.2us early, and CS2 is about 19.2us early. That should leave plenty of room for drift before stop precedes start.
I'm now resuming data collection with these adjustments.
Oh, and a note for future reference -- I wasted a lot of time trying to figure out what was wrong with the 5359A time synthesizer when it didn't seem to recognize an external trigger -- or at least, the output wasn't triggering the 5370B counter. Turns out I had the output pulse width set too short. Setting it to 1us or longer solved the problem.
jra on 07.22.06 @ 03:36 PM EDT [link]
Sunday, April 30th
Clock Setting
I've just set the PPS offsets for CS1, CS2 and RB1 to make it easier to do clock comparisons. The idea is for them to fire in this order: RB1, CS2, CS1, GPS.
To accomplish this, I used GPSDO2 as the starting point. It's set in software to run 10us early versus GPS. Its 1pps went into the HP 5359A time synthesizer, which adds an additional adjustable delay.
The result is that as of right now, CS1 is nominally 5us early vs. GPS; CS2 is nominally 7.5us early; and RB1 is nominally 10us early (RB1 is set directly from GPSD02). And, for what it's worth, GPSDO1 is nominally set as close to GPS time as I can get it, taking into account cable delays.
So much for the nominal delays; the synchronization process introduces some uncertainties of its own. In particular, CS1 has the original HP clock with adjustable divider, while CS2 and RB1 have aftermarket clocks. The measured delays versus GPS (100 second averages via M12+T and HP 5370B) as of right now are:
CS1 -- 5.030us
CS2 -- 6.635us
RB1 -- 10.228us
jra on 04.30.06 @ 04:15 PM EDT [link]
Sunday, March 12th
Last (?) tweak to CS1
After getting home from my trip, I checked the offset and CS1 is still about 3.8x10-13 high. I dropped the C field down to 4.98 (i.e., 1 minor division below 5.00) which should bring it to just about dead on.
jra on 03.12.06 @ 06:08 PM EDT [link]
Thursday, March 9th
Tweak to CS1
After more than two weeks, it's solidly clear that CS1 is still about 8.5x10-12 high. While I'm on a business trip in India, my lovely assistant Jody went down to the basement to adjust the C field from 5.20 down to 5.05.
jra on 03.09.06 @ 10:57 AM EDT [link]
Sunday, February 19th
Minor tweaks to CS1 and RB1
I'm now logging the performance of CS1, CS2, and RB1 using an HP5334A counter and 59307A coax switch. I read a 100 second average of 1pps vs GPS from each source, then move to the next. The plots are at www.febo.com/time-freq/plots.
After about 18 hours, it was clear that both CS1 and RB1 were more than 1x10-12 high, so I tweaked them down a little bit. CS1 went from 5.30 to 5.20, and RB1 from 1.85 to 1.84. CS2 is very close to correct; I can't even make a good estimate of the offset with this little data. So I'm leaving it alone.
I'm leaving for a multi-week trip shortly, so will restart the data capture just before I leave. That'll give the changes a couple of days to settle in before starting a long-term run.
jra on 02.19.06 @ 11:16 AM EDT [link]
Saturday, February 18th
Cs back on line
I've finished moving CS1 and CS2 into their new rack, and have written software to use an HP 5334A counter and 59307A GPIB coax switch to monitor up to four PPS signals vs. GPS. I'm now plotting CS1, CS2, and RB1 with the results at http://www.febo.com/time-freq/plots.
CS1 and CS2 have been powered up for about a month, though I only turned on the Cs tubes about 48 hours ago. RB1 has been running for maybe six months.
Current C-field settings:
RB1: 1.85
CS1 (LTC): 5.30
CS2: 4.60
There's a definite frequency offset when switching the Cs from normal to long time constant (LTC) mode.
Here are current meter readings:
RB1: PHOTO I -- 25
2ND HARM -- 45
CS1: MULT -- 36
BEAM I -- 21
2ND HARM -- 30
CS2: MULT -- 40
BEAM I -- 19
2ND HARM -- 38
jra on 02.18.06 @ 09:29 AM EDT [link]
Sunday, February 5th
Details of new cable runs
I am moving the Cs standards (and maybe the Rb) to a new rack that is located at the opposite end of my basement from the other gear. This is because (a) the temperature stability might be better there, and (b) there isn't room for another rack in my main lab space.
To bring the signals back to the lab, I am running 8 pieces of LMR-240 coax, each about 55 feet long. After building the cables, I measured the delay using HP5370 counter. Here are the results:
1 -- 66.872ns 2 -- 66.606ns 3 -- 66.749ns 4 -- 66.827ns
5 -- 66.749ns 6 -- 66.779ns 7 -- 66.841ns 8 -- 66.679ns
jra on 02.05.06 @ 07:57 PM EDT [link]
Friday, June 24th
New GPS Antenna and Delay Measurements
With help from Daun Yeagley, N8ASB, I replaced my old GPS antenna and feedline which I suspect have been failing. In its place is a new Motorola Timing 2000 antenna with about 70 feet of LMR-400 cable going into my splitter system (one 2-way HP splitter, with one port feeding about 8 feet of LMR-400 into a 4-way HP splitter which drives the two Z3801A GPSDO and the M12+ TAC-2).
With Daun's network analyzer we measured the time delay through the cable as 69.95 nanoseconds. We also measured the delay through the splitters as 47.6ns, though that measurement is a little suspect because the (relatively) narrow filters in the splitters smeared the response. So for the moment I'm assuming 118ns total delay (plus another few nanoseconds for the cable from the splitter to the receiver).
The good news is that the new antenna seems to be doing a much better job, with signal strength readings averaging at least ten units higher than before, and no signs of any signal dropouts. Thanks, Daun!
jra on 06.24.05 @ 04:38 PM EDT [link]
Thursday, May 5th
Cs Tweaking, continued
The change to CS1 appears to have brought it slightly low in frequency, so I nudged it up 1 minor division.
The 5 minor division change to CS2 doesn't seem to have made much difference. Not sure what that's about, but I'm going to take it down another 5 divisions now.
jra on 05.05.05 @ 08:01 PM EDT [link]
Wednesday, April 27th
Cs Tweaks
I adjusted both CS1 and CS2 today.
CS1 started the 17 day run at about +4x10-13 but then flattened out for a couple of days, and returned to about +8x10-13. I adjusted it minus 10 minor divisions to 508.
CS2 was a very stable +4.7x10-13 over the whole run, so I adjusted it minus 5 minor divisions to 472.
jra on 04.27.05 @ 03:01 PM EDT [link]
Saturday, March 26th
HP 5061A C Field Settings
I've run a series of tests on the 5061A to try to nail down the C field behaviour. I plotted the offset versus GPS, with one hour averaging, for 72 hours at three different settings. In each case, I waited at least 48 hours to let the unit stablize after making the change. Here are the results:
4.50 -7.8x10
5.00 +1.3x10
5.50 +3.3x10
That comes out to just about 8x10
Based on this, I should set the C field to 4.60, which I'm doing now.
jra on 03.26.05 @ 05:43 PM EDT [link]
Sunday, March 6th
2nd Cesium Standard On Line
I've added a second HP 5061A. It's somewhat older than the other one, but has a fairly new FTS tube and a replacement late-model 10811A oscillator. Here are the pertinent details:
HP 5061A SN 1248A00857
FTS Tube Model 1-105, SN 1098
Placed in service 6 March 2005.
This unit looks like it might have come out of Loran or some other positioning service as it has a sticker telling which direction to adjust the C field if range between base and mobile increases or decreases. It also has some interesting extra connectors, but I'm not sure if they still do anything.
jra on 03.06.05 @ 02:31 PM EDT [link]
Saturday, January 29th
HP 5061A on-line
I now have a Cesium standard (yay!). Recording pertinent details here for posterity:
HP 5061A SN 2428A02300 with FTS 7015 tube, SN 2445. Unit has 10811A OCXO. Put in service on 12 January 2005.
jra on 01.29.05 @ 10:21 AM EDT [link]
Tuesday, January 4th
New page for plots
I used the holiday break to write some software that will automatically do some phase data analysis and create a web page. This will let me check on the status of my data logging via the web without having to go into Stable32 (although Stable32 will remain the tool of choice for any sophisticated analysis).
The plots are at www.febo.com/time-freq/plots and if you're interested in the software, it can be dowloaded from www.febo.com/time-freq/tools.
jra on 01.04.05 @ 09:04 AM EDT [link]
Friday, November 5th
Longer-term HP 5065A offset
After solving (I hope) some problems with the GPIB interface between my instruments and data collection PC, I was able to do a long (86 hour) run comparing the HP 5065A to raw GPS 1pps from a Motorola Oncore M12+ Timing receiver.
The offset is, measured three different ways:
Linear -1.42x10-12
Avg of 1st diff: -1.45x10-12
Endpoints: -1.45x10-12
jra on 11.05.04 @ 12:34 PM EDT [link]
Saturday, October 23rd
More on HP 5065A Offset
After 20 hours of data collection, the HP 5065A offset is about -1.12x10-12, so I overcorrected a bit. I'll make a slight upward nudge and then leave things alone.
jra on 10.23.04 @ 08:37 AM EDT [link]
Thursday, October 21st
HP5065A Offset
After a several-day run against LORAN-C, the HP 5065A offset is measured at 2.8x10-12. The Austron frequency error currently shows 3x10-12, so the earlier measurement showing a negative offset corrected itself -- I probably hadn't let things settle long enough.
I've changed the C field setting of the standard from 2.84 down to 2.82 (one minor division) and will restart the run with this setting.
jra on 10.21.04 @ 05:25 PM EDT [link]
Sunday, October 17th
Austron 2100F data resolution
I've now interfaced my Austron 2100F LORAN-C monitor's chart output to an HP 3421A data acquisition unit (basically, a 5 1/2 digit DVM with multiplexed inputs and a GPIB interface). The Austron puts out nominally 0 to 1 volt over either a 1 microsecond or 10 microsecond full-scale range. In actuality, the output voltage is more like 0.010 to 0.995 volts.
It also looks like the output is quantized in about 8mv steps -- here's an example. I'm average the 5 1/2 digits from the 3421A down to 1 millivolt (or 1 ns on the 1us range). The question is whether that's worthwhile, or whether I'd be better off averaging to 10mv.
jra on 10.17.04 @ 09:42 AM EDT [link]
Saturday, October 16th
HP5065A Offset
After a long downtime, I got the Austron 2100F LORAN-C receiver fired up last night. After running overnight, the frequency error meter shows the HP 5065A is about -3.0x10-12. That's not bad considering that the 5065A hasn't been adjusted in over a year and has been power cycled at least once since the last check (at that time, it was -1.27x10-12).
I don't really trust the frequency error meter in the Austron, so will start a phase measurement as soon as I get my newly acquired HP 3421A data acquisition box wired up to the Austron's meter outputs.
jra on 10.16.04 @ 09:35 AM EDT [link]
Saturday, October 9th
Continuing 8164 tweaks
A delay setting of 23.7ms seems to provide best alignment of the Spectracom 8164 1pps output versus the Z3801A GPS 1pps. There's about a 2ms delay between the 1pps signal and the time stamp that ntp gets from the ASCII stream.
jra on 10.09.04 @ 09:29 PM EDT [link]
Saturday, October 2nd
Tweaking the Spectracom 8164
I'm feeding the Spectracom 8164 WWVB receiver into my main ntp time server, which also gets time information from the Z3801A GPSDO. The Z3801A provides the PPS signal, while the Spectracom uses its ASCII time code. There is an offset between the Spectracom's 1pps signal and the ASCII time mark, at least as ntpd interprets it. I'm trying to figure out what that offset is.
The distance between WWVB and my site is 1100.25 miles (1770.67km) and the calculated path delay, based on the formula in the Spectracom manual, is 5.90ms. The receiver's internal delay is nominally 17ms. So, the receiver's delay should be set to 22.9ms.
With that setting, the 1pps output from the Spectracom currently lags the 1pps output from the Z3801A by about 600us. According to my current ntp stats plot (www.febo.com/stats/ntp/), ntpd thinks the Spectracom is about 2.4ms slow.
The Spectracom adjusts its time sync in 100us increments, and unless it loses lock it stays within 1ms but seems to sometimes ramp through the +/-500us range. I think the only way to determine the true offset is to log the maximum and minimum offsets of the Spectracom 1pps against the Z3801A 1pps long enough to see the full range, and then pick the value in the middle. I'll start that experiment today.
jra on 10.02.04 @ 09:58 AM EDT [link]
Tuesday, September 28th
WWVB morning phase jump
Boy, it's been a while since there've been any updates here. Been busy on other stuff for the last few months...
Anyway, I have been using my Spectracom 8164 WWVB clock and two Z3801A GPSDOs as NTP reference clocks and logging the data. I generate graphs every 15 minutes showing the offset and jitter values for all three devices -- see www.febo.com/stats/ntp.
For the last few days, the WWVB clock has shown a regular spike of -100uS every morning at around 0712 local time. This has to be a momentary loss of lock at local sunrise; we've already seen that there's a very short, very deep fade in signal strength that occurs at local sunrise -- see www.febo.com/time-freq/wwvb/sig-strength, and in particular www.febo.com/time-freq/wwvb/sig-strength/wwvb-spectracom.html.
What's surprising is that I didn't notice this pattern before today. I should put together a composite log of the WWVB data to see whether it truly is an every-day occurrence.
jra on 09.28.04 @ 09:06 AM EDT [link]
Saturday, February 21st
WWVB Signal Strength
I'm doing an experiment to measure the received signal strength of WWVB here. If you're using WWVB, you might want to take a look, as the results (particularly the daytime strength) weren't what I expected to see. Check out www.febo.com/time-freq/wwvb/sig-strength/index.html if you're interested.
jra on 02.21.04 @ 04:12 PM EDT [link]
Sunday, December 28th
FMT
For the last two years, I've participated in the ARRL's annual Frequency Measuring Test, which calls for amateurs to measure the frequency of transmissions from W1AW and report the results for comparison against the official reading. I've finally gotten around to putting up a web page about this activity -- check out www.febo.com/time-freq/fmt/index.html if you're interested.
jra on 12.28.03 @ 09:10 PM EDT [link]
Thursday, December 25th
New HP5065A Run
We had a power failure last weekend, and it outlasted the UPS so the frequency standards cooled down a bit. They've been running again for several days so I started a new LORAN-C run today against the HP5065A -- the start time for offset calculation is 25 Dec. 2003 1540 UTC. I'm seeing a higher noise number (200 - 300) on the LORAN receiver than in the past, though the signal strength is still good. The noise may be from new gear running in the rack. The receiver time constant is set to 0 (3200 GRI). I'm going to let the receiver settle down for a bit and will then start logging data.
I'll be shutting things down again in a week or so to rewire the power distribution in the rack, so this run will be useful to see what frequency shift the restart causes.
jra on 12.25.03 @ 10:42 AM EDT [link]
Monday, November 10th
Spectracom 8164 Update
I recently ran some stability tests of my Spectracom 8164 WWVB-disciplined oscillator. While I was at it, I decided to update my web page about this beast. The results are at www.febo.com/time-freq/wwvb/spectracom/index.html.
jra on 11.10.03 @ 04:07 PM EDT [link]
Wednesday, October 8th
Z3801A results
I finished the data collection runs on my Z3801A units. The results are at http://www.febo.com/time-freq/gps/z3801a/stability. N8UR-1 seems to be quite a bit better than N8UR-2. Unfortunately, attempts to do a three-cornered hat analysis in Stable32 fail with a "negative variance" error, so I haven't been able to fully separate the three units.
jra on 10.08.03 @ 10:29 AM EDT [link]
Friday, October 3rd
Z3801A Stability Experiment
I just made a nice acquisition off of eBay -- it's a box with 4 independent dividers that will each take a 1, 5, or 10MHz input signal and bring it down to a nice sharp 1pps output. It can also generate a thumbwheel-set LORAN GRI pulse, which could be interesting.
That gave me the excuse to start my long-planned experiment to compare the stability of my two Z3801A GPS-disciplined oscillators. I'm doing a 48 hour run of each against the HP 5065A, and then will do a 48 hour run of each against the other. From that, I can do a "three cornered hat" analysis that will break out the stability of each standard individually.
I've finished the comparison of N8UR-1 vs. 5065A and am one day into N8UR-2 vs. 5065A (I guess I need to name the 5065A -- from now on, it's N8UR-3). I've started a web page to hold the results -- check http://www.febo.com/time-freq/gps/z3801a/stability/index.html. I'll update it with the charts for N8UR-2 and the two units against each other when those runs are complete.
jra on 10.03.03 @ 05:36 PM EDT [link]
Monday, September 29th
Loran results with LPF installed
Over the weekend, I built a low pass filter for the Loran receiver. Details are at http://www.febo.com/geekworks/antennas/amrad-lpf.html.
It seems to have solved the dirurnal phase jump problem once and for all, and although I only have about 12 hours of data so far to go on, it looks like the trace is generally cleaner now -- which makes sense since I've now removed the 30dB attenuator that I had in place before. The net result is that the interfering signal is much reduced, but the desired signal is 30dB stronger than it was.
jra on 09.29.03 @ 01:35 PM EDT [link]
Sunday, September 14th
Temperature plotting
By the way -- I now have my indoor/outdoor temperature plotting up and running. The graphs are updated every 15 minutes and uploaded to http://www.febo.com/geekworks/therm.html.
jra on 09.14.03 @ 03:38 PM EDT [link]
HP5065A Offset
Here's a plot of the HP5065A with the current C-field setting. The offset is 1.27x10-12. I believe the near-sine-wave phase variation in this plot is related to outside temperature variations, possibly due to phase shift in the active antenna. It doesn't correlate to the temperature in the basement where the equipment is.
jra on 09.14.03 @ 03:17 PM EDT [link]
Wideband power measurement
Yet more on the Loran phaseshift issue. Yesterday I fired up my HP3586C selective voltmeter and wrote a GPIB program to log data from it. The 3586C can measure wideband power between 20Hz and 32MHz with a resolution of 0.01dB. I logged data for 24 hours at 1 minute intervals, and here is the result.
It shows that the daytime power ievel is about -6dBm, which is tough enough for any front-end to deal with; when the local AM stations shift to night-time operation, the power level increases abruptly to about -3dBm. Then at daylight, the power level drops back down again. This means that the Austron receiver front-end has to deal with suddenly seeing twice as much power, and this is almost certainly the cause of the phase shift. (And actually, the situation is worse than this because I'm measuring power off a simple transformer splitter; when the meter is disconnected, the power level at the receiver will go up by 3dB.)
I have the parts for a 500kHz low pass filter ordered, and will get that built soon. It should solve the problem nicely.
I've continued to run the Austron receiver with a 30dB attenuator in front of it, and although this solves the sudden phase jump problem, I still have a diurnal phase change of about +/-50 nanoseconds. I suspect this is temperature related due to the sine-wave shape of the plot, which looks a lot like the outside temperature plot. More on this later.
jra on 09.14.03 @ 12:31 PM EDT [link]
Saturday, September 6th
HP5065 Offset update
I just did a check of the offset on a fairly linear piece of data at the end of the run, and came up with an offset of -4.5x10-12. That's substantially more, and in the opposite direction, than the measurements I made last week. This sample covered only about 12 hours. Because I'm still seeing the diurnal effect, I'm not sure if these measurements are what they should be. I really need to get a comparison against GPS to validate.
In any event, I'm adjusting the frequency up one minor division, to 1.84, and will start a new run with that setting.
jra on 09.06.03 @ 11:22 AM EDT [link]
Saturday, August 30th
HP5065 Aging Experiment
I've completed a long run of phase data showing the HP 5065A versus Loran-C. I took ~3 day samples from the beginning and near the end, and compared the frequency offsets.
The offset was -2.79x10-12 at the beginning, and -2.52x10-12 at the end, of the run. Here's the full 17 day run, showing the rollovers when the signal hit the rails of the 1us recorder range.
The difference in offset is 2.7x10-13 over 10.4 days, or 2.6x10-14/day. That's 7.7x10-13/month (assuming a 30-day month). That's significantly better than the quoted spec of 1x10-11/month. Is something wrong with this analysis?
jra on 08.30.03 @ 10:42 AM EDT [link]
Thursday, August 21st
More on phase jump
Following up on the earlier entries about the diurnal step change I'm seeing in my Loran-C phase plots... here are two spectrum analyzer shots showing the AM broadcast band as received by the Loran antenna.
Here is a shot taken at 2000 local time and here is one taken at 2100 local time. When these were taken (August 11/12) the phase jump occurred between these two times. There are two significant differences between the two plots: first, the two strongest signals increased in strength at sunset, with the strongest going up by about 3dB. Second, two of the local stations went away completely. So, the total power seen by the receiver doubled at night, and the absence of a few signals possibly changed the number and nature of any IMD products being generated in the receiver front end.
As noted earlier, putting a 30dB attenuator in the antenna line greatly reduced the amount of the phase shift, though the most recent phase plots still show a diurnal effect that may or may not result from this.
I suspect that the high power being presented to the Austron receiver causes it to overload, and the changes at night alter the overloading, resulting in a phase shift.
If this is the case, the right way to fix the problem is to put a low-pass filter in front of the receiver to block the AM broadcast signals while leaving the Loran signal strength alone. My next project is to build one of those.
jra on 08.21.03 @ 08:57 PM EDT [link]
Wednesday, August 20th
5065A longer term plots
While away for a few days vacation, I kept the HP5065A via Loran-C data collection running, and just analyzed the results. I have about 3.5 days of data between phase rollovers (ie, where the 1 microsecond recorder output hits the rail and wraps to the other end.
The frequency offset is currently -3.49x10-12 (with the C-field set at 1.82).
Here is the raw phase plot.
Here is the phase plot with offset removed. You can see that there is a diurnal effect; I haven't determined yet what is causing this.
Here is the Allen Variance.
jra on 08.20.03 @ 08:05 PM EDT [link]
Tuesday, August 12th
Frequency adjust
I just reset the C-field on the 5065A to 1.82 -- 2 minor divisions lower than the prior setting, which should reduce the frequency by about 8x10e-12. That should put the thing just about on frequency vs. LORSTA Dana.
jra on 08.12.03 @ 06:15 PM EDT [link]
Sunday, August 10th
Success???
The 30dB attenuator seems to have made the difference... it's now 30 minutes past the time where I normally see the evening phase shift, and no sign of it.
jra on 08.10.03 @ 08:57 PM EDT [link]
AM Broadcast overload?
One possible cause of the diurnal phase shift is overload from nearby AM broadcast stations. The new antenna results in some strong signals coming down the line -- about -9dBm for the strongest station. All the local stations either change power or antenna patterns (or both) at sunset, so it's possible that a change in the broadband power level seen by the Austron LORAN receiver could cause a phase shift. It's also possible that the directional antenna arrays could be a source of re-radiation, although the nearest station is about 2.5 miles away.
As a quick experiment, I inserted 30dB of attenuation in the antenna line. The Austron still locks up nicely on LORSTA Dana, though the gain figure (Status 3) is showing about 30dB higher. The noise value (Status 2) is about the same as without the attenuator -- in the 2 to 5 range. I'll log data for a day or so to see if this attenuation changes (or eliminates) the phase shift. If so, the longer term solution is to build a low pass filter that will knock down the AM stations while keeping the LORAN signals at nearly the same level.
jra on 08.10.03 @ 08:44 AM EDT [link]
Friday, August 8th
New GRI, Same Story
This afternoon I switched the Loran receiver to monitoring the GRI 9960 master station at Seneca, NY. That's a bit further away from me than the Dana station, but it seems to come in with good signal strength and low noise.
It's now 0035 and, lo and behold, the same ~120ns phase shift just occurred. So, whatever is going on is local and not at the LORSTA.
jra on 08.08.03 @ 08:41 PM EDT [link]
Thursday, August 7th
LORAN phase jumps -- antenna related?
Just found an interesting article on some LORAN stability testing in the Netherlands where an E-field antenna showed significantly greater effects from a change in near-field signal re-radiation than did an H-field antenna -- 100ns vs 50ns. I am using a voltage-probe (E-field) antenna, so this may be a factor -- now I just need to figure out what might be changing locally to cause the change.
Check:
http://www.eu-gloria.org/2003/GNSS2003%20Loran-C%20Challenges%20GNSS.pdf for the article.
jra on 08.07.03 @ 11:12 AM EDT [link]
What's 100ns among friends?
A quick look at the current data file shows that the ~120ns daily phase shift continues -- same time and same duration each day. Next step is to see if I can copy a different LORSTA to see if the same results obtain.
jra on 08.07.03 @ 10:43 AM EDT [link]
Wednesday, August 6th
More on LORAN phase jumps
I've captured a nice plot covering about 50 hours of the HP5065A tracking against LORAN-C (GRI 8970, Dana, IN). This plot captures two of the reciprocal phase changes noted above.
Here's the raw phase plot.
Here's the phase with offset removed.
Here is some data about those plots:
First phase increase: #23492 0027, 4 August
First phase decrease: #60192 1045, 4 August
Second phase increase: #109020 0026, 5 August
Second phase decrease: #145572 1042, 5 August
Note that for all practical purposes (there is some ambiguity because of the receiver time constant) the two phase changes are exactly 24 hours apart, and each period of increased phase lasted about 10 1/4 hours. (The times are shown in UTC; 0027 is 2027 local time (EDT).
These are the average phase values for each segment, linear offset removed:
Segment1: -48ns average
Segment2: +64ns average -- +112ns
Segment3: -58ns average -- -122ns
Segment4: +77ns average -- +135ns
Segment5: -29ns average -- -106ns
From this, I don't think this jump is the result of a 10MHz divider hiccuping; all the changes are noticeably greater than 100ns.
So, now I know what the phase shift looks like, but I still have no idea what's causing it. I'm continuing to monitor to see whether this is truly a daily event.
By the way, the 5065A C-field setting is 1.86 yielding a current frequency offset versus LORAN Dana of 4.92x10-12.
jra on 08.06.03 @ 08:09 PM EDT [link]
Monday, August 4th
HP5065A via LORAN-C
I finally got a nice run of the HP5065 via the Austron 2100F LORAN-C receiver. The plot clearly shows a pair of sudden phase jumps, one up and one down. The linear frequency offset is about 4.4x10e-12, but I'm continuing the run to get better frequency offset and drift data.
Here's the raw phase data.
And the phase data with frequency offset removed.
And the Allan Variance.
jra on 08.04.03 @ 07:31 PM EDT [link]
