For personal reasons I have been testing various cheap USB GPS pucks and their utility as a reference clock for ntp.
I have found the VK-162 G-Mouse to be the best of the bunch so far.
This is available on Amazon from various vendors for about $15.
It appears to be a generic device containing a u-blox chipset and
branded with a sticker by the vendor much like supermarket branded
can goods.
The claims to fame for this device are:
A current GNSS chipset with lots of channels so it sees and processes
lots of sattelites.
Fast processing of data that minimizes jitter to about the best one
could expect from a USB interface.
It is recognized by Windows which assigns a vertual COM port for it when
it is plugged in, meaning it is trivial to use with Meinberg ntp.
Analyzing the data from loopstats for two different Linux machines shows:
loopstats
Count:30356
Avg offset: 5.69703e-06 milliseconds
Std dev: 1.59061 milliseconds
Avg error: 1.42265 milliseconds
Std dev: 0.514422 milliseconds
loopstats
Count:30357
Avg offset: -6.1664e-05 milliseconds
Std dev: 1.57205 milliseconds
Avg error: 1.41154 milliseconds
Std dev: 0.482011 milliseconds
These numbers are about an order of magnitude better than when the
machines were using network ntp servers as time sources.
And yes, I do graphing but this is an ASCII group.
On 07/31/21 16:16, Jim Pennino wrote:
For personal reasons I have been testing various cheap USB GPS pucks and
their utility as a reference clock for ntp.
I have found the VK-162 G-Mouse to be the best of the bunch so far.
This is available on Amazon from various vendors for about $15.
It appears to be a generic device containing a u-blox chipset and
branded with a sticker by the vendor much like supermarket branded
can goods.
The claims to fame for this device are:
A current GNSS chipset with lots of channels so it sees and processes
lots of sattelites.
Fast processing of data that minimizes jitter to about the best one
could expect from a USB interface.
It is recognized by Windows which assigns a vertual COM port for it when
it is plugged in, meaning it is trivial to use with Meinberg ntp.
Analyzing the data from loopstats for two different Linux machines shows:
loopstats
Count:30356
Avg offset: 5.69703e-06 milliseconds
Std dev: 1.59061 milliseconds
Avg error: 1.42265 milliseconds
Std dev: 0.514422 milliseconds
loopstats
Count:30357
Avg offset: -6.1664e-05 milliseconds
Std dev: 1.57205 milliseconds
Avg error: 1.41154 milliseconds
Std dev: 0.482011 milliseconds
Average error and offset in relation to what ?. Meaningless
otherwise.
These numbers are about an order of magnitude better than when the
machines were using network ntp servers as time sources.
Perhaps, but at least 2 orders of magnitude worse than could be attained
by using a cheap gps engine with pps output to the dcd line and
ntpd.
The cheapest, current, commercial GPS with a RS-232 connector and PPS
that I can find is over $100.
I do in fact know that there are thousands of people who have a requirment for "accurate" time where the required accuracy is no more than about 100 milliseconds and do not have RS-232 connectors or any other way to get a
PPS signal.
chris<chris-nospam@tridac.net> wrote:
On 07/31/21 16:16, Jim Pennino wrote:
For personal reasons I have been testing various cheap USB GPS pucks and >>> their utility as a reference clock for ntp.
I have found the VK-162 G-Mouse to be the best of the bunch so far.
This is available on Amazon from various vendors for about $15.
It appears to be a generic device containing a u-blox chipset and
branded with a sticker by the vendor much like supermarket branded
can goods.
The claims to fame for this device are:
A current GNSS chipset with lots of channels so it sees and processes
lots of sattelites.
Fast processing of data that minimizes jitter to about the best one
could expect from a USB interface.
It is recognized by Windows which assigns a vertual COM port for it when >>> it is plugged in, meaning it is trivial to use with Meinberg ntp.
Analyzing the data from loopstats for two different Linux machines shows: >>>
loopstats
Count:30356
Avg offset: 5.69703e-06 milliseconds
Std dev: 1.59061 milliseconds
Avg error: 1.42265 milliseconds
Std dev: 0.514422 milliseconds
loopstats
Count:30357
Avg offset: -6.1664e-05 milliseconds
Std dev: 1.57205 milliseconds
Avg error: 1.41154 milliseconds
Std dev: 0.482011 milliseconds
Average error and offset in relation to what ?. Meaningless
otherwise.
What part of "Analyzing the data from loopstats" did you not understand?
If you do not know what is in loopstats, you can find that information
in the ntp.org website documentation.
These numbers are about an order of magnitude better than when the
machines were using network ntp servers as time sources.
Perhaps, but at least 2 orders of magnitude worse than could be attained
by using a cheap gps engine with pps output to the dcd line and
ntpd.
Yeah, so?
Did you read the title of the post?
The cheapest, current, commercial GPS with a RS-232 connector and PPS
that I can find is over $100.
I do in fact know that there are thousands of people who have a requirment for "accurate" time where the required accuracy is no more than about 100 milliseconds and do not have RS-232 connectors or any other way to get a
PPS signal.
On 03/08/2021 15:33, Jim Pennino wrote:
The cheapest, current, commercial GPS with a RS-232 connector and PPS
that I can find is over $100.
I do in fact know that there are thousands of people who have a requirment >> for "accurate" time where the required accuracy is no more than about 100
milliseconds and do not have RS-232 connectors or any other way to get a
PPS signal.
A cheaper approach would be a Chinese GPS board with a TTL-to-RS232 converter.
In my experience, you will get much better timekeeping using a Raspberry Pi with a GPS/PPS hat as a central stratum-1 server and accessing that over the local network.
Of course, there will be different requirements for different folk.
On 08/03/21 15:33, Jim Pennino wrote:
chris<chris-nospam@tridac.net> wrote:
On 07/31/21 16:16, Jim Pennino wrote:
For personal reasons I have been testing various cheap USB GPS pucks and >>>> their utility as a reference clock for ntp.
I have found the VK-162 G-Mouse to be the best of the bunch so far.
This is available on Amazon from various vendors for about $15.
It appears to be a generic device containing a u-blox chipset and
branded with a sticker by the vendor much like supermarket branded
can goods.
The claims to fame for this device are:
A current GNSS chipset with lots of channels so it sees and processes
lots of sattelites.
Fast processing of data that minimizes jitter to about the best one
could expect from a USB interface.
It is recognized by Windows which assigns a vertual COM port for it when >>>> it is plugged in, meaning it is trivial to use with Meinberg ntp.
Analyzing the data from loopstats for two different Linux machines shows: >>>>
loopstats
Count:30356
Avg offset: 5.69703e-06 milliseconds
Std dev: 1.59061 milliseconds
Avg error: 1.42265 milliseconds
Std dev: 0.514422 milliseconds
loopstats
Count:30357
Avg offset: -6.1664e-05 milliseconds
Std dev: 1.57205 milliseconds
Avg error: 1.41154 milliseconds
Std dev: 0.482011 milliseconds
Average error and offset in relation to what ?. Meaningless
otherwise.
What part of "Analyzing the data from loopstats" did you not understand?
If you do not know what is in loopstats, you can find that information
in the ntp.org website documentation.
If you only have one clock, you have nothing to compare it to,
making your number potentially meaningless. If you are not using pps,
then the delays an jitter in the usb interface will only ever be an approximation of utc time.
If you are so insecure thet you can't at least try to be a little
more gracious and provide a bit more explanation, rather than the
anger that usually suggests deep seated insecurity. People in this
group have decades of professional experience in the subject, but many
of your posts suggest a complete lack of understanding of how such
systems work, which is why some of the responses may seem a little patronising...
These numbers are about an order of magnitude better than when the
machines were using network ntp servers as time sources.
Perhaps, but at least 2 orders of magnitude worse than could be attained >>> by using a cheap gps engine with pps output to the dcd line and
ntpd.
Yeah, so?
Did you read the title of the post?
The cheapest, current, commercial GPS with a RS-232 connector and PPS
that I can find is over $100.
I do in fact know that there are thousands of people who have a requirment >> for "accurate" time where the required accuracy is no more than about 100
milliseconds and do not have RS-232 connectors or any other way to get a
PPS signal.
So, buy a watch from walmart ?.
In what way is a Raspberry Pi with a GPS/PPS hat AND a local network
simpler or cheaper than just plugging in a $15 USB device when the requirement is 100 milliseconds?
If you only have one clock, you have nothing to compare it to,
making your number potentially meaningless. If you are not using pps,
then the delays an jitter in the usb interface will only ever be an
approximation of utc time.
Do you know how many clocks are in each satellite?
Have you ever tried to set computer time to within 100 milliseconds
by hand?
While it is doable with a little practice, the drift will soon be
greater than 100 milliseconds and you must keep doing it over and over.
On 2021-08-03, Jim Pennino <jimp@gonzo.specsol.net> wrote:
In what way is a Raspberry Pi with a GPS/PPS hat AND a local network
simpler or cheaper than just plugging in a $15 USB device when the
requirement is 100 milliseconds?
Try that with multiple computers and you will quickly see what is
simpler and cheaper. A single RPi can serve time to all computers in
a local network. If you don't have ethernet around, you can buy wifi
dongles for less than that GPS receiver.
What kind of computers are you working with that they have good GPS
signal, anyway? I'd certainly not want to be pulling antenna or serial
cables around the house or some server room just to connect each
computer with a GPS.
In any case, you don't need a local GPS to get a 100ms accuracy. You
just point an NTP client to pool.ntp.org and you are done.
On 08/03/21 16:50, Jim Pennino wrote:
If you only have one clock, you have nothing to compare it to,
making your number potentially meaningless. If you are not using pps,
then the delays an jitter in the usb interface will only ever be an
approximation of utc time.
Do you know how many clocks are in each satellite?
From what i've read, there is only one system clock and one backup in
each satellite. They used to be caesium frequency standards as they
are the most accurate. Not sure if they get corrections from ground
stations. Would not be surprised, but they are already accurate
to within seconds in billions of years. That is not needed so much
for utc time, but for sub meter navigation accuracy.
There are other corrections from ground stations on an
ongoing basis, but again, primarily for navigation accuracy.
The algorithims that determine utc on the surface are
pretty complex, but you can delve into that as well. The caesium
master clocks typically run at 10 MHz, so not a clock in hours,
minutes and seconds as we know it...
Have you ever tried to set computer time to within 100 milliseconds
by hand?
Never had the requirement to, but again, who are the thousands who do
need that ?...
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 16:50, Jim Pennino wrote:
If you only have one clock, you have nothing to compare it to,
making your number potentially meaningless. If you are not using pps,
then the delays an jitter in the usb interface will only ever be an
approximation of utc time.
Do you know how many clocks are in each satellite?
From what i've read, there is only one system clock and one backup in
each satellite. They used to be caesium frequency standards as they
are the most accurate. Not sure if they get corrections from ground
stations. Would not be surprised, but they are already accurate
to within seconds in billions of years. That is not needed so much
for utc time, but for sub meter navigation accuracy.
There are other corrections from ground stations on an
ongoing basis, but again, primarily for navigation accuracy.
Oh my god.
http://www.nasonline.org/publications/beyond-discovery/the-global-positioning-system.pdf
For starters, there are 4 "atomic clocks" in each satellite.
The types have changed with the later block satellites, but the number hasn't.
https://www.gps.gov/systems/gps/space/ https://www.gps.gov/systems/gps/control/ https://www.gps.gov/systems/gps/performance/accuracy/ https://www.gps.gov/systems/gps/modernization/
The algorithims that determine utc on the surface are
pretty complex, but you can delve into that as well. The caesium
master clocks typically run at 10 MHz, so not a clock in hours,
minutes and seconds as we know it...
Arm waving.
I have delved into it, but apparently you have glossed over it.
http://www.ntp.org/documentation.html
Have you ever tried to set computer time to within 100 milliseconds
by hand?
Never had the requirement to, but again, who are the thousands who do
need that ?...
And again, a significant percentage of the 3 million amateur radio
operators worldwide.
On 08/03/21 18:17, Jim Pennino wrote:
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 16:50, Jim Pennino wrote:
If you only have one clock, you have nothing to compare it to,
making your number potentially meaningless. If you are not using pps, >>>>> then the delays an jitter in the usb interface will only ever be an
approximation of utc time.
Do you know how many clocks are in each satellite?
From what i've read, there is only one system clock and one backup in
each satellite. They used to be caesium frequency standards as they
are the most accurate. Not sure if they get corrections from ground
stations. Would not be surprised, but they are already accurate
to within seconds in billions of years. That is not needed so much
for utc time, but for sub meter navigation accuracy.
There are other corrections from ground stations on an
ongoing basis, but again, primarily for navigation accuracy.
Oh my god.
http://www.nasonline.org/publications/beyond-discovery/the-global-positioning-system.pdf
For starters, there are 4 "atomic clocks" in each satellite.
So ?, nitpicking pedant much :-).
The types have changed with the later block satellites, but the number
hasn't.
https://www.gps.gov/systems/gps/space/
https://www.gps.gov/systems/gps/control/
https://www.gps.gov/systems/gps/performance/accuracy/
https://www.gps.gov/systems/gps/modernization/
The algorithims that determine utc on the surface are
pretty complex, but you can delve into that as well. The caesium
master clocks typically run at 10 MHz, so not a clock in hours,
minutes and seconds as we know it...
Arm waving.
I have delved into it, but apparently you have glossed over it.
http://www.ntp.org/documentation.html
Good for you. I'm quite happy in having just an overview, don't need the
in depth. Anyway, are you convinced about pps's relationship with
UTC yet, or do we need to go round the loop again ?...
In any case, you don't need a local GPS to get a 100ms accuracy. You
just point an NTP client to pool.ntp.org and you are done.
How about when you are at some remote location with no Internet or
cell service?
FYI the GNSS receiver that is the actual topic of this post provides CONSISTENTLY better performance by an order of magnitude than any pool.
The GNSS receiver that is the actual topic of this post provides
slightly better performance than my ISP ntp servers which are only a
couple of hops away.
NTP works whether you have an Internet connection or not if you have a reference clock, which is the subject of the post.
Right now, one of the GNSS receivers I am testing shows an average
offset of -0.85731 microseconds for a bit under 10,000 samples.
On 2021-08-03, Jim Pennino <jimp@gonzo.specsol.net> wrote:
In any case, you don't need a local GPS to get a 100ms accuracy. You
just point an NTP client to pool.ntp.org and you are done.
How about when you are at some remote location with no Internet or
cell service?
You didn't say this was a requirement. The vast majority of computers
have Internet access and this is the NTP group, so you shouldn't be
surprised when people suggest to use that instead.
FYI the GNSS receiver that is the actual topic of this post provides
CONSISTENTLY better performance by an order of magnitude than any pool.
No, that certainly is not always true. It depends on your Internet connection. The typical accuracy of NTP over Internet is few
milliseconds, i.e. better than a typical PPS-less USB GPS.
In my monitoring of the pool servers (from a single location) the median absolute offset is about 1.5 milliseconds. That includes all servers
from the pool around the world, not just servers in the country I live
in (which would be used by the NTP client).
At home, the offset to the nearest server from the pool I see is below
100 microseconds.
The GNSS receiver that is the actual topic of this post provides
slightly better performance than my ISP ntp servers which are only a
couple of hops away.
That suggests your Internet connection has an asymmetric delay. That is typical for DSL and cable.
On 2021-08-03, Jim Pennino <jimp@gonzo.specsol.net> wrote:
NTP works whether you have an Internet connection or not if you have a
reference clock, which is the subject of the post.
No, NTP is a network protocol. ntpd supports reference clocks, but it
doesn't use NTP to synchronize to them.
Right now, one of the GNSS receivers I am testing shows an average
offset of -0.85731 microseconds for a bit under 10,000 samples.
Offset relative to what? What is your reference? We know it is not the
GPS with PPS that you were not able to get working.
Your original post talked about values from loopstats. That is not the
raw offset of a time source. Loopstats is what the PLL gets, i.e. after
the refclock samples are filtered. If you see a 2ms stddev of the
loopstats offset, the actual GPS jitter will be an order of magnitude
higher (depending on your polling interval).
Unlike you, I do not just pull things out of my ass then arm wave in a
futile attempt at justification.
From my perspective you are the one making the wild claim and it is up
to you to back up that claim.
ACE III GPSTM
System Designer Reference Manual
4.9.2
Timing Pulse Output (PPS)
A pulse-per-second (PPS), ten microsecond wide pulse is available on the ACE III GPS 8-
pin interface connector. The pulse is sent once per second and the rising edge of the pulse
is synchronized with UTC.
On 08/03/21 19:27, Jim Pennino wrote:
Unlike you, I do not just pull things out of my ass then arm wave in a
futile attempt at justification.
From my perspective you are the one making the wild claim and it is up
to you to back up that claim.
This might help to get you started:
https://en.wikipedia.org/wiki/Pulse-per-second_signal
The pps signal is typically a gps receiver function, but you can check
a gps rx user manual to see what it says about the pps signal and how
ot's synchronised to UTC. For example, the Trimble ACE III manual
says this about the pps signal:
ACE III GPSTM
System Designer Reference Manual
4.9.2
Timing Pulse Output (PPS)
A pulse-per-second (PPS), ten microsecond wide pulse is available on the ACE III GPS 8-
pin interface connector. The pulse is sent once per second and the rising edge of the pulse
is synchronized with UTC.
This is quite an old gps module, but current ones will all sync
pps to UTC, as the systems would not work properly without that.
You
can find the full manual for Trimble Ace III online. Of course, you
could have found that in minutes if you had taken the trouble...
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 19:27, Jim Pennino wrote:
Unlike you, I do not just pull things out of my ass then arm wave in a
futile attempt at justification.
From my perspective you are the one making the wild claim and it is up >>> to you to back up that claim.
This might help to get you started:
https://en.wikipedia.org/wiki/Pulse-per-second_signal
The pps signal is typically a gps receiver function, but you can check
a gps rx user manual to see what it says about the pps signal and how
ot's synchronised to UTC. For example, the Trimble ACE III manual
says this about the pps signal:
ACE III GPSTM
System Designer Reference Manual
4.9.2
Timing Pulse Output (PPS)
A pulse-per-second (PPS), ten microsecond wide pulse is available on the ACE III GPS 8-
pin interface connector. The pulse is sent once per second and the rising edge of the pulse
is synchronized with UTC.
This is quite an old gps module, but current ones will all sync
pps to UTC, as the systems would not work properly without that.
Utter nonsense.
It is impossible to have a PPS signal from a USB GPS as manufactured and
they do in fact work properly. They are just not as accurate for timing applications as ones with PPS and are by far the most common type of GPS.
PPS makes no difference for anything else.
You
can find the full manual for Trimble Ace III online. Of course, you
could have found that in minutes if you had taken the trouble...
Or in other words, a GPS satellite does NOT sync the PPS pulse to UTC.
That is what I have been saying over and over and over.
On 08/03/21 23:47, Jim Pennino wrote:
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 19:27, Jim Pennino wrote:
Unlike you, I do not just pull things out of my ass then arm wave in a >>>> futile attempt at justification.
From my perspective you are the one making the wild claim and it is up >>>> to you to back up that claim.
This might help to get you started:
https://en.wikipedia.org/wiki/Pulse-per-second_signal
The pps signal is typically a gps receiver function, but you can check
a gps rx user manual to see what it says about the pps signal and how
ot's synchronised to UTC. For example, the Trimble ACE III manual
says this about the pps signal:
ACE III GPSTM
System Designer Reference Manual
4.9.2
Timing Pulse Output (PPS)
A pulse-per-second (PPS), ten microsecond wide pulse is available on the ACE III GPS 8-
pin interface connector. The pulse is sent once per second and the rising edge of the pulse
is synchronized with UTC.
This is quite an old gps module, but current ones will all sync
pps to UTC, as the systems would not work properly without that.
Utter nonsense.
Classic emo response, try using critical facilities for a change :-).
It is impossible to have a PPS signal from a USB GPS as manufactured and
they do in fact work properly. They are just not as accurate for timing
applications as ones with PPS and are by far the most common type of GPS.
Can't comment on much of that, but usb sure is a second rate solution.
PPS makes no difference for anything else.
You
can find the full manual for Trimble Ace III online. Of course, you
could have found that in minutes if you had taken the trouble...
Or in other words, a GPS satellite does NOT sync the PPS pulse to UTC.
That is what I have been saying over and over and over.
Good at switching the goal posts, that's for sure, but is guess you
must at least be convinced of the relationship between pps and utc ?.
Would be good if we have at agreed about that at least...
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 23:47, Jim Pennino wrote:
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 19:27, Jim Pennino wrote:
Unlike you, I do not just pull things out of my ass then arm wave in a >>>>> futile attempt at justification.
From my perspective you are the one making the wild claim and it is up >>>>> to you to back up that claim.
This might help to get you started:
https://en.wikipedia.org/wiki/Pulse-per-second_signal
The pps signal is typically a gps receiver function, but you can check >>>> a gps rx user manual to see what it says about the pps signal and how
ot's synchronised to UTC. For example, the Trimble ACE III manual
says this about the pps signal:
ACE III GPSTM
System Designer Reference Manual
4.9.2
Timing Pulse Output (PPS)
A pulse-per-second (PPS), ten microsecond wide pulse is available on the ACE III GPS 8-
pin interface connector. The pulse is sent once per second and the rising edge of the pulse
is synchronized with UTC.
This is quite an old gps module, but current ones will all sync
pps to UTC, as the systems would not work properly without that.
Utter nonsense.
Classic emo response, try using critical facilities for a change :-).
A response which your nonsense deserved.
Can't comment on much of that, but usb sure is a second rate solution.
It is impossible to have a PPS signal from a USB GPS as manufactured and >>> they do in fact work properly. They are just not as accurate for timing
applications as ones with PPS and are by far the most common type of GPS. >>
To what problem other than perhaps keeping a computer clock to better
than a few milliseconds of accuracy?
Most of the world couldn't give a rat's ass about accurate time.
Even in critical navigation applications no one cares about accurate,
i.e. subsecond, time. What they care about is position, speed, heading, altitude for aircraft, and such.
PPS makes no difference for anything else.
You
can find the full manual for Trimble Ace III online. Of course, you
could have found that in minutes if you had taken the trouble...
Or in other words, a GPS satellite does NOT sync the PPS pulse to UTC.
That is what I have been saying over and over and over.
Good at switching the goal posts, that's for sure, but is guess you
must at least be convinced of the relationship between pps and utc ?.
Would be good if we have at agreed about that at least...
Nope, I never switched any goal post.
I said over and over that GPS does not synchronize the PPS signal to
anything and with your latest foray into 20+ year old product manuals
you appear to have proven me correct.
Now you can proceed to learn how a GPS receiver works in general and
perhaps then you can prove the PPS signal is synced to GPS UTC time and
to what accuracy, but I wouldn't bet on it.
I'm waiting...
On 08/04/21 01:15, Jim Pennino wrote:
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 23:47, Jim Pennino wrote:
chris<chris-nospam@tridac.net> wrote:
On 08/03/21 19:27, Jim Pennino wrote:
Unlike you, I do not just pull things out of my ass then arm wave in a >>>>>> futile attempt at justification.
From my perspective you are the one making the wild claim and it is up
to you to back up that claim.
This might help to get you started:
https://en.wikipedia.org/wiki/Pulse-per-second_signal
The pps signal is typically a gps receiver function, but you can check >>>>> a gps rx user manual to see what it says about the pps signal and how >>>>> ot's synchronised to UTC. For example, the Trimble ACE III manual
says this about the pps signal:
ACE III GPSTM
System Designer Reference Manual
4.9.2
Timing Pulse Output (PPS)
A pulse-per-second (PPS), ten microsecond wide pulse is available on the ACE III GPS 8-
pin interface connector. The pulse is sent once per second and the rising edge of the pulse
is synchronized with UTC.
This is quite an old gps module, but current ones will all sync
pps to UTC, as the systems would not work properly without that.
Utter nonsense.
Classic emo response, try using critical facilities for a change :-).
A response which your nonsense deserved.
To what problem other than perhaps keeping a computer clock to better
Can't comment on much of that, but usb sure is a second rate solution. >>
It is impossible to have a PPS signal from a USB GPS as manufactured and >>>> they do in fact work properly. They are just not as accurate for timing >>>> applications as ones with PPS and are by far the most common type of GPS. >>>
than a few milliseconds of accuracy?
Most of the world couldn't give a rat's ass about accurate time.
Even in critical navigation applications no one cares about accurate,
i.e. subsecond, time. What they care about is position, speed, heading,
altitude for aircraft, and such.
PPS makes no difference for anything else.
You
can find the full manual for Trimble Ace III online. Of course, you
could have found that in minutes if you had taken the trouble...
Or in other words, a GPS satellite does NOT sync the PPS pulse to UTC. >>>>
That is what I have been saying over and over and over.
Good at switching the goal posts, that's for sure, but is guess you
must at least be convinced of the relationship between pps and utc ?.
Would be good if we have at agreed about that at least...
Nope, I never switched any goal post.
I said over and over that GPS does not synchronize the PPS signal to
anything and with your latest foray into 20+ year old product manuals
you appear to have proven me correct.
Now you can proceed to learn how a GPS receiver works in general and
perhaps then you can prove the PPS signal is synced to GPS UTC time and
to what accuracy, but I wouldn't bet on it.
I'm waiting...
Keep wriggling Jim, you are good at it :-)...
Have you ever tried to set computer time to within 100 milliseconds
by hand?
While it is doable with a little practice, the drift will soon be
greater than 100 milliseconds and you must keep doing it over and over.
Jim Pennino wrote:
Have you ever tried to set computer time to within 100 milliseconds
by hand?
Yes.
While it is doable with a little practice, the drift will soon be
greater than 100 milliseconds and you must keep doing it over and over.
I did this way back in 1986 or 87, by writing a replacement timer tick interrupt handler (for MS DOS): I had a standalone program which
compared the system time with a (good) external reference, and
optionally adjusted the system time to be the same.
Next I waited about 24 hours then I reran the program and determined how
much the system clock had speeded up/slowed down over that time period.
This provided the average drift rate of this particular machine, so at
this point the INT 9 IRQ driver was updated by inserting the drift rate
in the handler loop: From then on instead of incrementing the system
every timer tick, I instead added a fractional tick interval to an
internal counter (I think I used 32 bits) and when that overflowed I
updated the system tick value. This kept the system clock around the
sub-100 ms accuracy level over the next week.
Terje
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 112 |
| Nodes: | 8 (1 / 7) |
| Uptime: | 207:03:27 |
| Calls: | 2,465 |
| Files: | 8,603 |
| Messages: | 1,878,442 |