Starlink is a low-orbit-satellite-constellation system too. They're going to be using an omnidirectional-or-close-to-it antenna, which should be plenty serviceable for GPS. If they were using geosynchronous satellites I'd agree with you, not gonna be the right antenna configuration.

FWIW, StarLink is a LEO constellation at around 500km, however the GNSS systems are MEO constellations. The lowest GNSS constellation (GLONAS) is around 19,000km, and the highest (Galileo) is around 23,000km. In addition to the MEO satellites, a few of them, BeiDou (China), QZSS (Japan) and NavIC (India) also have GEO components at 35,000km.

A bit of quick research suggests that the StarLink units do indeed have a low end GPS receiver, but that GPS is only used for initial satellite acquisition. After that, they use their own position and timing capabilities. There is a lot of research speculation that if SpaceX would just "tighten up" their implementation, StarLink could be used as an alternative to existing GNSS systems.

Your Research Results May Vary.

They're going to be using an omnidirectional-or-close-to-it antenna

Correct... it's phased array.

Gross positioning for pointing a dish (very narrow band, narrow target area) is easy. Accurate timing isn't. Different kind of antenna to begin with... It's rather difficult in many situations.

But IIUC, Starlink is a low-orbit-satellite-constellation system too. They're going to be using an omnidirectional-or-close-to-it antenna, which should be plenty serviceable for GPS. If they were using geosynchronous satellites I'd agree with you, not gonna be the right antenna configuration.

Starlink device knows where it is using GPS as the default locating technology, but there is a configuration item to use its own positioning system instead

Gross positioning for pointing a dish (very narrow band, narrow target area) is easy. Accurate timing isn't. Different kind of antenna to begin with... It's rather difficult in many situations.

If they included ntp in the oven you wouldn't have these issues

A dream of mine...

I believe the ntpd issue has to do with nuances of newer versions of the NTP protocol rather than GPS.

FWIW, the Galleon test app looks to be pretty broken. A precision of 2.26156424291633E+74 is clearly wrong.

Absolutely. Galleon is just an easy utility to check GPS function... it's old and there is probably an update I just haven't gone looking for. It was posted for function and NOT usability.

Interesting -- what is the source?

oh my bad that was my ntp server reporting on one of the ntp servers I use as alternate source to pps

When I look on one of my clients I get what my ntp server 192.168.3.32 reports

Remote address  : 192.168.3.32 (C0A80320)
Remote port     : 123
Local address   : 192.168.3.10 (C0A8030A)
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 1
Poll interval   : 8 (256 seconds)
Precision       : -24 (0.000000060 seconds)
Root delay      : 0.000015 seconds
Root dispersion : 0.000015 seconds
Reference ID    : 50505300 (PPS)
Reference time  : Sat Oct 03 22:56:58 2026
Offset          : +0.000042164 seconds
Peer delay      : 0.000732688 seconds
Peer dispersion : 0.000000112 seconds
Response time   : 0.000168404 seconds
Jitter asymmetry: +0.00
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX        : 2121
Total RX        : 2121
Total valid RX  : 2121
Total good RX   : 2121
root@pihole:/home/pi# 

Remote address  : 192.168.100.1 (C0A86401)
Remote port     : 123
Local address   : 100.[redacted]
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 1
Poll interval   : 0 (1 seconds)
Precision       : -9 (0.001953125 seconds)
Root delay      : 0.000000 seconds
Root dispersion : 0.000000 seconds
Reference ID    : 00000000 ()
Reference time  : Sat Oct 03 22:35:19 2026
Offset          : -0.000059627 seconds
Peer delay      : 0.001953174 seconds
Peer dispersion : 0.001953174 seconds
Response time   : 0.000061035 seconds
Jitter asymmetry: -0.50
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Daemon
RX timestamping : Kernel
Total TX        : 1735
Total RX        : 1735
Total valid RX  : 1735
Total good RX   : 1546
Total kernel TX : 0
Total kernel RX : 1735
Total HW TX     : 0
Total HW RX     : 0

Starlink used to furnish access to the GPS location data, but they shut that feature down for reasons.

I'm not a time wonk like johnpoz or Jeff Geerling, but accurate time is fascinating and the Starlink GPS clock is good enough for my network.

And to be honest, I expect 2ms is sufficient for 99% of home users.

LOL.. most home user oven clocks are >5 minutes off..

@dennypage
Not that amazing here; from my Starlink I get, via chronyc ntpdata using the command page on pfSense:

Precision       : -9 (0.001953125 seconds)

Interesting. I wonder why it's so different that what you expect or what Johnpoz reported.

To me that indicates unexpected honesty on the part of StarLink. Based on the number I'm guessing that they are using their carrier signal to communicate time rather than some form of embedded GNSS.

And to be honest, I expect 2ms is sufficient for 99% of home users.

Precision : -25 (0.000000030 seconds)

Interesting -- what is the source?

Some people (companies) use -25 and justify it because the GNSS chip they are using says <= 30ns. However, the precision statement should be about the entire system rather than just the GNSS. To really be -25, you really need to have <= 20ns on the GNSS chip itself, and a very deterministic microcode implementation or high resolution hardware timestamping on each step of the process.

I have a few real -24s and -25s, and one -26. I'd really like to have a -27, but am not sure I'll get there. I have a reference timing chip that is reliable <= 5ns, but don't have the hardware to put with it. Sad, sad, sad.

Not that amazing here; from my Starlink I get, via chronyc ntpdata using the command page on pfSense:

Precision       : -9 (0.001953125 seconds)

Interesting. I wonder why it's so different that what you expect or what Johnpoz reported.

Precision : -25 (0.000000030 seconds)

Well shoot clearly my clocks are going to be way out ;)

operating in "the new world of GPS time"

I believe the ntpd issue has to do with nuances of newer versions of the NTP protocol rather than GPS.

FWIW, the Galleon test app looks to be pretty broken. A precision of 2.26156424291633E+74 is clearly wrong.

If you are running chrony, you can ask it directly what the advertised precision of a source is. Try chronyc ntpdata 192.168.100.1 and look for Precision. I would expect to see something in the range of -14 (61us) to -24 (61ns).

The Starlink dish itself a Stratum 1 time source. But it's operating in "the new world of GPS time" and pfSense is yet to catch up. I'm sure they will. The gent from NTP posted the issue if you read enough of this thread.

Here is the output when using the local dish through the Galleon utility.

The issue is the NTP client in pfsense doesn’t work properly to read that time. Chronyd does work but it’s an unsupported add-on at this point. I’m getting my network time from my Starlink dish gps receiver right now and it’s very accurate as expected.

Not this morning.

StarLink as source for NTP

By definition, a starlink 'disk' points to the open sky.
So, it should be able / must 'see' many satellites ...
For me, that means is also sees GPS satellites.

Knowing that every two digit dollar hand hold device has a GPS receiver built in today, I asked myself : why doesn't the starlink disk include a sub one dollar GPS receiver chip ??
It would make the starlink disk a stratum 2 (1 ?) GSP device right out of the box - no more NTP traffic needed.
Afaik, these starlink satellites all have an atomic clock(or comparable) build in, needed for their exact positing and all that, so that would be a second totally free source of time.

Anyway, that's how I see the title "StarLink as source for NTP".
It could be "Starlink == real time" thus a very accurate time source.

edit : this thread is pretty long. Maybe this was already suggested.

Rick

@cmcdonald said in StarLink as source for NTP:

pfSense expects refid to not be empty, so it ends up shifting all other columns over.

Is there ever a legit condition where refid is indeed empty?

ntpd displays text refids bracketed by periods. It seems reasonable to do that for refids with only unprintable/invisible characters. Stratum 1 sources have text refids like .GPS.

Feel free to file a bug report at https://bugs.ntp.org/

It's actually ntpq which brackets text refids with periods. Refids are always 32 bits, either up to 4 characters or a dotted-quad a la IPv4. However, an empty refid is displayed as an empty string. To give screen-scrapers a better chance, ".." would be preferable.

I've filed https://bugs.ntp.org/4019 to track that change. For those interested, there are two lines in doprintpeers under the line:

	} else if (!strcmp("refid", name)) {

to update from:

				dstadr_refid = "";

to:

				dstadr_refid = "..";