Hello everyone

I've installed gpsd and to the best of my ability can confirm that it is on the hard drive, I'm still trying to figure out the version but I think it is v3.xx.

I'm have a USB GPS antenna plugged into an Intel NUC with Debian 12 and according to the terminal it can see numerous satellites, the longitude and latitude are showing the right location but the GPS time and date at first was off by about 16 hours but seems to be getting closer to local time after about 3 days.

I set the BIOS time to match my phone but Debian time is 2 hours off.

The only purpose of this computer is to provide time to a private network with a domain controller.

I have a feeling that more software is needed but according to gpsd.io trouble shooting the fact that I can see satellites data means everything works.

If any more information is needed I will try and find it. I sure would appreciate some help with this.

cary

Have you set the correct timezone? If yes, continue here https://gpsd.io/gpsd-time-service-howto.html

The BIOS should be set to UTC time as well configuring debian so it knows the hardware clock is set to utc. Did you install ntp?

The output of cgps or xgps should show the correct UTC time when the receiver is synced. As posted ntp needs to be configured to use the receiver as a time source. ntp works using UTC so setting timezone on the server is not required. When ntp is started time should be forced to match the receiver but otherwise slowly keep in sync with small changes.

The receiver/ antenna should be positioned in location with a fairly unobstructed view of the sky.

The "time" of a GPS signal – which is in UTC – by definition cannot be "wrong." Because the entire GPS system is based on very-tiny differences in precisely-synchronized and precisely-correct "time signals." But your time zone interpretation can be incorrect. And, if so, it will always be "off" by a precise number of whole hours.

Incidentally, you can now buy "atomic clocks" which are designed to use GPS signals, not the radio station "WWV."

You can also purchase a standalone GPS network time server. Plug in an antenna, configure DHCP and your done.

Exception, in some part of the world the TIME ZONES are some portion of an hour different than what one would expect from your statement.
In IST (India) the factor is CUT +5:30

Personally I use NTP using multiple reference servers and correct my hardware (CUT) clock, and set local time zone the usual way so my machines all display correct local time. This works well as my machines are often shielded from the sky and would rarely get satellite.

All these suggestions have some merit.

Starting point.
Hardware clock set to UTC.
Time zone set as appropriate for the local time.
These 2 should display local time correctly.
the ntpd service should be keeping system time in sync with UTC.

When all this is correct then the gpsd service should be able to properly display local time properly for the current physical location.
Note that the above is only a starting point since if the gps location moves into a different time zone then the gps time may no longer match local time as set by the user time zone. UTC however never changes and is the basis for the gps time so it is mandatory that the system have UTC time set properly for the hardware clock and maintained by ntp to keep everything in sync. If the hardware clock is set to local time it will cause errors (unless local time also happens to be UTC).

Hello

Crafting questions about something one has no knowledge about can be difficult . . . so thank you

hi sundialsvcs "The "time" of a GPS signal – which is in UTC – by definition cannot be "wrong." That was my first thought - how could it be wrong!

michaelk "Did you install ntp?" After hour or so of googling and spelling mistakes I can attest that embarrassment really does make you face red.

Thank you computersavvy for the suggestions

cary

Youy may also need to address your ntp drift which is a factor deals with the percentage drift or difference between your local ntp server and the gpsd synchronization protocols. I'd assume that when you installed the gpsd and ntp software packages you where provided with a example configuration file.

The drift or difference between your local nto server and Greenwich mean time should only be of concern if the drift becomes noticeably larger than when you originally configured your local ntp server.I'd also strongly recommenced that you invest in a highly rated uninterruptible power supply in order to allow you to shave graceful shut down of all of your critical machines.

GPS and location are needed to find time isn't it?
From the location one gets local time if within a few hundred feet unless you are getting differential signals spoofing.

Sort of. A receiver needs to lock onto at least 1 satellite for itself to get accurate time and then it can download information on where to find the others. With 3 you get position and 4 altitude. 4 also corrects for receiver time errors which provides the most accuracy something like 150ns.

I once read about the format of the "li'l ol' tzinfo file," and I had no idea how much information it actually contains. About how time-zones are, and, how they used to be.

Usually, you just run "ntp" and it keeps your clock very-well synchronized and that is that.

(P.S.: The "messy details" of how ntp actually "does its thing" are also quite fascinating. ... There are some serious engineers in this world!)

1 members found this post helpful.

On the ship I think we needed 3 to get a valid read.

Being a ntp server is slightly different from being a ntp client. GPS nor the system clock (except if your hardware clock is set to local but that is another matter) cares about time zones.

Actually GPS and UTC are different time references.. GPS time is not adjusted for leap seconds while UTC is.