gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-users] Trouble Receiving Time from Delorme EarthMate USB (LT-20)


From: Jeff Morris
Subject: [gpsd-users] Trouble Receiving Time from Delorme EarthMate USB (LT-20)
Date: Wed, 13 Mar 2019 08:47:20 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1


Hi all,

I recently came across a Delorme EarthMate USB (LT-20) at a thrift shop for a couple of bucks, and picked it up with the hope of being able to use it as an NTP stratum-0 time source for an NTP server on my home network.

I've managed to get gpsd installed and running, and it sees the EarthMate. The EarthMate acquires satellites and gets a fix and shows my correct position, so it seems to be working properly. However gpsd is reporting a date from the EarthMate far in the future. For example for today, 2019-03-13, it's reporting the date as 2099-07-28. The time is correct, but the date is way off. If I look at the raw time in seconds-since-the-epoch format, I see numbers like 134439.000. (These numbers are both from the output of gpsmon.)

I'm also having no luck getting ntpd to receive messages from gpsd. I've added the following lines to /etc/ntp.conf (and removed all other servers):

server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 0.0 refid GPS

However, ntpq -p reports that it has never successfully polled this source:

     remote           refid      st t when poll reach   delay offset  jitter
==============================================================================
 SHM(0)          .GPS.            0 l    -   16    0 0.000    0.000   0.000

I'm aware of the GPS week rollover issue, and given that this is an old receiver that I picked up at a thrift shop it may very well be susceptible to that. However, the numbers I'm seeing don't make any sense to me. The 10-bit week rollover issue should result in a rollover every 20 years? The date I'm seeing is 80 years in the future however, and the seconds since epoch number works out to only a day and a half (134439.000/60/60 = 37.34 hours), even though the next rollover isn't due for a few more weeks.

Can someone explain these numbers I'm seeing, and does anyone have any suggestions as to why ntpd isn't able to poll the gpsd time source?

Thanks in advance.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]