A decent USB GPS for NTP FYI

102 views
Skip to first unread message

Jim Pennino

unread,
Jul 31, 2021, 11:16:07 AM7/31/21
to
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.

chris

unread,
Aug 3, 2021, 7:22:17 AM8/3/21
to
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.

Jim Pennino

unread,
Aug 3, 2021, 10:46:05 AM8/3/21
to
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.


David Taylor

unread,
Aug 3, 2021, 10:54:26 AM8/3/21
to
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.
--
Cheers,
David
Web: http://www.satsignal.eu

chris

unread,
Aug 3, 2021, 11:02:12 AM8/3/21
to
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 ?.

Jim Pennino

unread,
Aug 3, 2021, 11:46:06 AM8/3/21
to
David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
> 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.

How is that cheaper than $15?

Have you priced connectors and wire lately?

Did you read the part where I said "and do not have RS-232 connectors or
any other way to get a PPS signal"?

> 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.

Yeah, so what?

Did you read the title?

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?

> Of course, there will be different requirements for different folk.

Which is why I posted this.

Jim Pennino

unread,
Aug 3, 2021, 12:01:06 PM8/3/21
to
Do you know how many clocks are in each satellite?

I didn't think so.

Typically you are comparing time to about 40 clocks with a single USB
GPS.

The accuracy without PPS is shown by the above numbers.

Arm wave all you want about the definition of "approximation".


> 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...

Try reading the documentation at npt.org before pulling crap out of
your butt and trying to sharpshoot what I write.

Have you read up on what loopstats contains yet?

I did not post this to start a tutorial session on how GPS and ntpd
work.

>>>> 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 ?.

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.


Miroslav Lichvar

unread,
Aug 3, 2021, 12:29:26 PM8/3/21
to
On 2021-08-03, Jim Pennino <ji...@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.

--
Miroslav Lichvar

chris

unread,
Aug 3, 2021, 12:31:50 PM8/3/21
to
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 ?...

Jim Pennino

unread,
Aug 3, 2021, 1:01:05 PM8/3/21
to
Miroslav Lichvar <mlic...@redhat.com> wrote:
> On 2021-08-03, Jim Pennino <ji...@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.

I never said anything about multiple computers.

It take more than just wifi dongles to set up a network.

The best seller WiFi dongle on amazon is $16 while the GPS is $15.

> 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.

The kind of computer has nothing to do with the quality of the GPS
signal.

Putting a USB GNSS on a window sill is generally more than adequate.

If you do have multiple computers and a local network, only one machine
running as a ntp server is required.

> 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?

How about when you want better accuracy than provided by pools on the
cheap?

In case you missed that part, I have been doing a study of inexpensive
GPS solutions complete with graphs.

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.

Jim Pennino

unread,
Aug 3, 2021, 1:31:07 PM8/3/21
to
chris <chris-...@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.

chris

unread,
Aug 3, 2021, 1:50:45 PM8/3/21
to
On 08/03/21 18:17, Jim Pennino wrote:
> chris<chris-...@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 ?...

Jim Pennino

unread,
Aug 3, 2021, 2:31:05 PM8/3/21
to
chris <chris-...@tridac.net> wrote:
> On 08/03/21 18:17, Jim Pennino wrote:
>> chris<chris-...@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 :-).

Just another example of how clueless you actually are.

Your whole paragraph was so blazingly wrong that I did not want to even
attempt to spend the hours it would take to correct every sentence.

And as I am sure a whole lot of readers of the group already know this
stuff, I just provided links to where YOU might get educated.

>>
>> 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 ?...

Not ever until someone comes up with a GPS specification that says
otherwise.

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.

Miroslav Lichvar

unread,
Aug 3, 2021, 2:38:56 PM8/3/21
to
On 2021-08-03, Jim Pennino <ji...@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.

--
Miroslav Lichvar

Jim Pennino

unread,
Aug 3, 2021, 3:31:06 PM8/3/21
to
Miroslav Lichvar <mlic...@redhat.com> wrote:
> On 2021-08-03, Jim Pennino <ji...@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.

NTP works whether you have an Internet connection or not if you have a
reference clock, which is the subject of the post.

When people suggest something other than what I am talking about, they
are making the supercilious assumption that I don't know about the other
things, which I find highly insulting.

I made a post that was informational only about a COTS product and
nothing more.

I did not ask any questions nor request suggestions on DIY projects
or anything else.

>> 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.

You didn't read what I wrote below before writting that, did you?

>
> 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.

Instantaneous numbers are useless for analysis of ntpd performance other
than a quick look to see if it appears to be working and offset alone is
also useless.

Median or average numbers are useless for analysis of ntpd performance
without standard deviations.

If you really want to know what ntpd is doing, you need to do averages
of several things with standard deviations and graphing of those things.

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.

That sounds great until you look at the standard deviation which is
2003.41 microseconds. So now your 95% confidence level is about 4000
microseconds.

It becomes even worse when you look at the offset plot that shows random
instantaneous peaks of around 8000 microseconds.

And yes, I did all that for network servers.

>> 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.

I already know about the effects of asymmetric delay on ntpd.

I have actually read all the documents on ntp.org that apply to anything
I am acutally doing, i.e. I couldn't care less about WWV receivers in
2021, though I did read it circa 1979 when I built one.

FYI I have one test machine that generates a nice plot that shows when
the air conditions cycles on and off to the microsecond level.


Miroslav Lichvar

unread,
Aug 3, 2021, 3:48:08 PM8/3/21
to
On 2021-08-03, Jim Pennino <ji...@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).

--
Miroslav Lichvar

Jim Pennino

unread,
Aug 3, 2021, 4:31:06 PM8/3/21
to
Miroslav Lichvar <mlic...@redhat.com> wrote:
> On 2021-08-03, Jim Pennino <ji...@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.

Sigh.

The ntpd program works ON A GIVEN SYSTEM whether you have an Internet...

Happy now?

BTW, a reference clock in terms of ntpd and NTP means a local device
capable of feeding accurate time to ntpd.

But I realize you are just nitpicking over my use of NTP vs NTPD.


>> 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.

The reference is about 10,000 samples from the ntpstats directory files.

> 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).

No shit?

Gee, I never would have guessed there might be loopstats, clockstats,
peerstats, etc. files in /var/log/ntpstats/ nor that the recommendation
from ntp.org is to set minpoll to 4 for reference clocks.

And golly gosh, I would never have guessed that all those files had all
sorts of fields in them.


chris

unread,
Aug 3, 2021, 6:26:55 PM8/3/21
to
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...








Jim Pennino

unread,
Aug 3, 2021, 7:01:08 PM8/3/21
to
chris <chris-...@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.

chris

unread,
Aug 3, 2021, 7:28:41 PM8/3/21
to
On 08/03/21 23:47, Jim Pennino wrote:
> chris<chris-...@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...




Jim Pennino

unread,
Aug 3, 2021, 8:16:07 PM8/3/21
to
A response which your nonsense deserved.

>
>>
>> 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.
>
A> Can't comment on much of that, but usb sure is a second rate solution.

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...


chris

unread,
Aug 4, 2021, 6:13:05 AM8/4/21
to
Keep wriggling Jim, you are good at it :-)...

Jim Pennino

unread,
Aug 4, 2021, 11:16:12 AM8/4/21
to
Keep arm waving about random crap, you are good at it.


Terje Mathisen

unread,
Aug 5, 2021, 9:21:57 AM8/5/21
to
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

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Jim Pennino

unread,
Aug 5, 2021, 11:16:11 AM8/5/21
to
Shudder.

How times have changed.


Reply all
Reply to author
Forward
0 new messages