Why not use the signal from one of the LF time clocks, and
correct by offsetting the distance. Since this is being used
for LF transmission, the communications system must be
propagation phase change resistant, and timing from an
LF source will make the phase error order of 2 worse
that it might otherwise have been.

This would seem to need much less engineering than
processing the output of a GPS.

Stewart G3YSX


Walter Blanchard wrote:

At 21:17 11/02/01 Sunday, VE2IQ wrote:

>...............I propose to use GPS ..........:
>The only real requirement is a GPS receiver with a 1-PPS output good to
>within a few microseconds of UTC.

Be careful - don't confuse relative with absolute time. The 1 pps output
from cheapo GPS sets is only relative time, not absolute.  If you like, it
gives frequency not phase and phase is essential to your
application.  Recovering absolute time from GPS to microsec accuracy is not
easy and you won't do it with an ordinary positioning receiver.  My company
used to make a lot of money out of selling specialist GPS timing receivers
designed purely to recover absolute time - they cost about ten times as
much as ordinary sets! Your basic idea is right  but do you really need
microsecs?  Would millisecs do?  If so it becomes a lot easier although I
still wouldn't advise using the 1 pps.  BTW you don't have to work out how
many seconds from the start of week - the GPS message has what's called a
Z-count which is exactly that - the number of seconds into the week
starting at midnight Sunday UTC.
If you can get the right data outputs from the receiver (some of the
slightly more expensive receivers give them) what about this :
Using only one satellite - pull out the Z-count (in the message); the delay
between satellite and you (from measured pseudo-range); the UTC offset for
that satellite (in the message).  Apply the transit delay to the UTC offset
and label it with the Z-count. This will be a near approximation to
absolute UTC that might do for your purpose. It only relies on the
receiver's internal timing for a few millisecs while it gets the
pseudorange although unavoidably it is still contaminated with software
functions and timing. Can't be done with a cheapo because it won't let you
into the fundamental GPS data message. NMEA data outputs are irrelevant and
unusable for this purpose. Of course, there's a bit of external programming
involved to manipulate the numbers.  I haven't looked at this method in any
detail to see where the snags are but if it looks a runner I'll do a bit
more work on it.

Walter G3JKV.