Re: [time-nuts] Common-View GPS Network
In message A687BF7F4A1642E8BA7EDDA7432A3969@pc52, "Tom Van Baak" writes:
When you look at the actual clock solutions (which are in the @@Hn
message) you will be surprised at the variance.
A lot of that variance is because the position-hold coords are wrong.
I tried using the @@Hn data to "sneak" up on the right coords and got
some pretty good results, but the process too forever (as in: Months)
See:
http://phk.freebsd.dk/raga/sneak/
The improvement in the finished timing solution from the oncore is
quite marginel because on average you have satellites on all
sides of your antenna and the errors mostly cancel out.
The notable exception to that is where I live: at 56N.
56N is at the top of the GPS orbits, so satellites never venture
north of me, and I'm not sufficient north to have any benefits from
the satellites which rise above Canada/Alask on the other side of
the north pole.
--
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.
Count me in as well, if you need another participating station. I have
my Thunderbolt running 24/7 with a solid stationary antenna..
Achim
Hi Poul:
Once you know the rise and set times (where the signal is stable) in sidereal time for each SV# you can simply
enable/disable them based on time.
I think this may be a better approach than having a mask angle based on each degree of azimuth.
Keeping track of a rise and set time for each SV# is an order of magnitude less data than a 1 deg elevation mask.
Remember that each GPS satellite repeats it's ground track, that's to say that from a fixed antenna each satellite will
always follow the same path in the sky.
This was how/why the GPS orbit altitude was chosen.
That's why I asked for a Sidereal time plot for the Thunderbolt. On a standard time position plot the satellites appear
to change paths.
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
Poul-Henning Kamp wrote:
In message A687BF7F4A1642E8BA7EDDA7432A3969@pc52, "Tom Van Baak" writes:
When you look at the actual clock solutions (which are in the @@Hn
message) you will be surprised at the variance.
A lot of that variance is because the position-hold coords are wrong.
I tried using the @@Hn data to "sneak" up on the right coords and got
some pretty good results, but the process too forever (as in: Months)
See:
http://phk.freebsd.dk/raga/sneak/
The improvement in the finished timing solution from the oncore is
quite marginel because on average you have satellites on all
sides of your antenna and the errors mostly cancel out.
The notable exception to that is where I live: at 56N.
56N is at the top of the GPS orbits, so satellites never venture
north of me, and I'm not sufficient north to have any benefits from
the satellites which rise above Canada/Alask on the other side of
the north pole.
Hi
Most modern receivers give you corrections in ps rather than ns. That's not to say they are good to 1 ps. It's not uncommon to see adev (after doing the correction) running sub 1 ns at one second when compared to a 5071.
Most people seem to do this in runs many minutes long. That's a bit away from 1 second, so other things do come into the picture.
Bob
On Apr 16, 2013, at 3:42 AM, "Tom Van Baak" tvb@LeapSecond.com wrote:
I wonder if one should only measure the PPS thought. Looking directly at
the clock could help to separate the clock drift and the time, even if
you get sufficient clues from the PPS and sawtooth correction.
Cheers,
Magnus
I've never tried that. Start with checking the ADEV of the LO. I always assumed the 1PPS was pre-compensated for instantaneous LO offset and rate, as calculated during the previous second(s). If so and ADEV(1 s) is less than 1e-9 then the 1PPS + sawtooth will have sufficient accuracy for your needs. Message @@Ha contains the oscillator and clock parameters.
As you know professional receivers bypass this issue because they take an external LO (e.g., Rb, Cs, HM).
When you look at the actual clock solutions (which are in the @@Hn message) you will be surprised at the variance. At the per-SV per-second level it is not uncommon to see errors of many ns, even tens of ns. But when you average up to 12 SV together every second for 600 seconds then you start to see something trustable. You can see first hand why GPSDO need long time-constants.
Here's a one second sample of a single Hn message:
@@Hn: sigma 36 sawtooth 10 0 0 00000000 mean frac 861564.000 (0.000)
ch 0 sv 6 frac 0.000861576 s = mean + 12 ns
ch 1 sv 5 frac 0.000861586 s = mean + 22 ns
ch 2 sv 10 frac 0.000861581 s = mean + 17 ns
ch 3 sv 19 frac 0.000861573 s = mean + 9 ns
ch 5 sv 13 frac 0.000861571 s = mean + 7 ns
ch 6 sv 26 frac 0.000019831
ch 7 sv 28 frac 0.000861555 s = mean + -8 ns
ch 8 sv 7 frac 0.000861548 s = mean + -15 ns
ch 9 sv 3 frac 0.000861571 s = mean + 7 ns
ch 10 sv 8 frac 0.000861546 s = mean + -17 ns
/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.
Hi Tom,
On 04/16/2013 09:42 AM, Tom Van Baak wrote:
I wonder if one should only measure the PPS thought. Looking directly at
the clock could help to separate the clock drift and the time, even if
you get sufficient clues from the PPS and sawtooth correction.
Cheers,
Magnus
I've never tried that.
Tom, you scare me some times, this is one of them... or the time actually.
Start with checking the ADEV of the LO. I always assumed the 1PPS was
pre-compensated for instantaneous LO offset and rate, as calculated
during the previous second(s).
Well, it is... but it also solves the position-time each second and that
takes over. If you loose signal, that's when the predicted PPSes will
shine through.
If so and ADEV(1 s) is less than 1e-9 then the 1PPS + sawtooth will
have sufficient accuracy for your needs. Message @@Ha contains the
oscillator and clock parameters.
True. That get's you far. Just looking at that and bring it into your
model is also something you can do. It's interesting to notice that the
@@Ha message has a time (to nanosecond), and then clock bias and
oscillator offset and on top of that a delta correction in the @@Hn
message. Would be nice to know exactly how them all fitted together.
BTW. I hooked up my M12M-T to a Novatel 700 pinwheel just to check it
out again.
As you know professional receivers bypass this issue because they take an external LO (e.g., Rb, Cs, HM).
Oh yes.
The TCXO sitting there looks like a RAKON thing, I haven't looked at the
details, but maybe it can be steered? It's interesting that the TCXO
temperature can be read out.
When you look at the actual clock solutions (which are in the @@Hn
message) you will be surprised at the variance. At the per-SV
per-second level it is not uncommon to see errors of many ns, even
tens of ns. But when you average up to 12 SV together every second
for 600 seconds then you start to see something trustable. You can
see first hand why GPSDO need long time-constants.
Here's a one second sample of a single Hn message:
@@Hn: sigma 36 sawtooth 10 0 0 00000000 mean frac 861564.000 (0.000)
ch 0 sv 6 frac 0.000861576 s = mean + 12 ns
ch 1 sv 5 frac 0.000861586 s = mean + 22 ns
ch 2 sv 10 frac 0.000861581 s = mean + 17 ns
ch 3 sv 19 frac 0.000861573 s = mean + 9 ns
ch 5 sv 13 frac 0.000861571 s = mean + 7 ns
ch 6 sv 26 frac 0.000019831
ch 7 sv 28 frac 0.000861555 s = mean + -8 ns
ch 8 sv 7 frac 0.000861548 s = mean + -15 ns
ch 9 sv 3 frac 0.000861571 s = mean + 7 ns
ch 10 sv 8 frac 0.000861546 s = mean + -17 ns
The urge to get into the dirty details got higher by that. Curious at
seeing a log of data.
Let's see if my M12M-T locks up in the current quick-hack setup.
Cheers,
Magnus
On 04/16/2013 09:55 AM, Poul-Henning Kamp wrote:
In messageA687BF7F4A1642E8BA7EDDA7432A3969@pc52, "Tom Van Baak" writes:
When you look at the actual clock solutions (which are in the @@Hn
message) you will be surprised at the variance.
A lot of that variance is because the position-hold coords are wrong.
I tried using the @@Hn data to "sneak" up on the right coords and got
some pretty good results, but the process too forever (as in: Months)
See:
http://phk.freebsd.dk/raga/sneak/
The improvement in the finished timing solution from the oncore is
quite marginel because on average you have satellites on all
sides of your antenna and the errors mostly cancel out.
The notable exception to that is where I live: at 56N.
56N is at the top of the GPS orbits, so satellites never venture
north of me, and I'm not sufficient north to have any benefits from
the satellites which rise above Canada/Alask on the other side of
the north pole.
Did you look at the pseudo-range correction data as an alternative approach?
Cheers,
Magnus
On 4/16/2013 1:55 AM, Jim Lux wrote:
On 4/15/13 10:22 PM, Jim Lux wrote:
On 4/15/13 9:27 PM, Tom Van Baak wrote:
NIST SIM GPS common view pinwheel
described in one of the NIST reports as an aperture coupled slot fed
array that is better than a patch, but not as large and heavy as a choke
ring.
W. Kunysz, 2000, “High Performance GPS Pinwheel Antenna,” in
Proceedings of the 2000 International Technical Meeting of the Satellite
Division of the Institute of Navigation (ION GPS 2000), 19-22 September
2000, Salt Lake City, Utah, USA (ION, Alexandria, Virginia), pp. 2506-251
http://www.novatel.com/assets/Documents/Papers/GPS-704xWhitePaper.pdf
Patented by Novatel & Pinwheel is a trademark
Performance is almost as good as a choke ring but a heck of a lot
smaller and lighter.
of course, cake pans with 2-2.5 inch high walls are readily available.
There's a Wilton cakepan set with 6",8" and 10" diameter pans with 3"
walls.. hmm, an inch between fins..
Oddly, the package shipping size is 12x12x2"... I wonder how they fit a
3" high pan in a 2" thick box..
a real restaurant/pastry supply has a mindboggling variety of pans
http://www.fantes.com/cake-pans-round.html
every integer inch diameter from 4" to 18" and ditto for heights from 2"
to 4"...
People like those machined or cast choke rings because they're easier to
fabricate: Slap a block of aluminum in the lathe or milling machine,
push GO on the CNC, and stand back.
Or for those with a taste for hot metal.. you could cast it with scrap
aluminum you've melted in the forge in your time nuts lab.. Turn those
empty beer cans into something useful.
If you have a fancy multiaxis mill, you could probably do one of those
porcupine looking things.
Or, if you have a swimming pool or pond, and some sheet aluminum, and
some suitable high explosives.. hydroforming is your friend.
If you want true timenuts.. do the explosive hydroforming without a
mold/buck, and instead use precision timing of shaped charges. Finally,
a use for those krytron switches you found at the surplus place.
Thanks for that. The last bit of your post was really cute. I needed a
good laugh :)
I haven't posted much in a while, partly because I've been kinda bummed
out by this list since I got the news about shera... There have been so
many constant reminders of his passing and whatnot (multiple thread
titles mentioning his legacy)
I just have to ask though... cake pans? really? I can't imagine it would
even be possible to modify a cake pan with enough accuracy to get a
usable antenna.
-- Sarah
On 4/16/2013 9:53 AM, Achim Vollhardt wrote:
Count me in as well, if you need another participating station. I have
my Thunderbolt running 24/7 with a solid stationary antenna..
I'm not sure what all I'll need to participate, but I'd like to
volunteer my thunderbolt to this sort of network as well.
I'm wondering though, is there something inherently different about this
proposed network than a network of continually operating reference stations?
or are CORS stations for something else?
--Sarah
On 4/16/13 5:19 PM, Sarah White wrote:
I just have to ask though... cake pans? really? I can't imagine it would
even be possible to modify a cake pan with enough accuracy to get a
usable antenna.
Sure.. cake pans, like other stamped goods, are actually pretty high
precision, because they're all stamped out of the same die. As long as
the dimensions are right (and for choke rings that's not real critical),
it works.
Tom, you scare me some times, this is one of them... or the time actually.
Magnus,
I remember why I didn't measure the M12 oscillators directly -- it's a real challenge to get at the signal on the back side of the PCB and to measure it without loading the crystal. It's not like just connecting a wire to a 50R Timepod input. Here are photos of the oscillator on three different versions of the M12 board:
http://leapsecond.com/pages/m12/m12-osc.htm
Perhaps with some 'scope tracing you can find a buffered clock output on one of the ASIC pins. That way the same probing technique could be used on all 3 boards.
/tvb