Some thoughts.. 1) Can you really even expect 1uS timing with a BlueTooth GPS that lacks a direct, wired 1PPS interface? My guess is "no".
2) Next, add some pool servers to the ntp.conf file and let ntp get your computer clock's rate of advance "in the ball park" As is "drift" and "offset" are being compared to what? Let it run with pool servers for an hour or more 3) A "few minutes" is not enough time to know what the final steady state result will be. Try 1/2 hour or over night. I'd like it if someone could prove me wrong, but I think 1uS or better timing will require different hardware and a more "direct" connection to the GPS' PPS. As a basic check, can you see how the location reported by the GPS moves around. Ideally it would never move by even an inch but the system is not perfect and there will be a spread in reported lat. long. Just write down the low order digits every couple minutes for an hour or so. the spread will change as the sats geometry changes. At this point a rough estimate is good enough, is the GPS bouncing around at the 100 meter level or the 1m level? I tried using an old Garmin 12 GPS with NMEA only NTP driver and got about 10X worse then your result. Basically the "12" was useless. That was with good reception too as a put the GPS in the roof and ran a long RS232 cable back to the computer. On the other hand my Oncore UT+ GPS gives results on order of 1000X or 500x better then you report. Not all GPS units are good for timing On Tue, Jan 18, 2011 at 12:21 PM, Mark Ngbapai <[email protected]> wrote: > Hi all. I've grown interested in precise timekeeping so I decided to > buy an inexpensive Transystem iBlue 737 GPSr clone with MTK 3301 + > 3179 chipset (32-channel, -158dBm tracking sensitivity, Silicon Wave > Bluetooth 1.2 chipset) for use with my Fedora 12 Linux Netbook (An > Acer Aspire One D150). Having lock indoors of 5/9 satellites I've > succeeded connecting the device via rfcomm to my netbook and using > gpsd for parsing the data. I restart the nptd server in the machine > and after a few minutes I get: > > > [root@PHOENIX Streamer]# ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > *SHM(0) .GPS. 0 l - 16 377 0.000 24.511 42.977 > > > If I execute ntpstat, it shows: > > [root@PHOENIX Streamer]# ntpstat > synchronised to modem at stratum 1 > time correct to within 67 ms > polling server every 16 s > > > In /var/log/mesages I see the lines: > > Jan 18 20:38:39 PHOENIX ntpd[6898]: ntpd [email protected] Wed Dec 9 > 11:49:22 UTC 2009 (1) > Jan 18 20:38:39 PHOENIX ntpd[6899]: precision = 5.448 usec > Jan 18 20:39:28 PHOENIX ntpd[6899]: synchronized to SHM(0), stratum 0 > > > So why my system is telling me the time is correct within 67 ms and > not 5.44 usec? My GPSr is located at 1-1.5 meters from my netbook > (GPSr battery lasts around 40 hours, low power is not an issue). Does > my Linux installation need special Kernel patching or I'm missing > something? > > > Thanks in advance, > > Mark > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- ===== Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
