A conversation with Ron Frazier ...

Introduction

02/02/2012 12:45 EST

Hello all,

My name is Ron Frazier. I live in the USA in the state of Georgia. I have recently developed an interest in, and have been experimenting with GPS time using NTP on Windows. I hope to be experimenting with Linux shortly. I've recently been having a series of email conversations with David J Taylor regarding my experience and various questions that I had. He has been very helpful, and I am very appreciative for that. I wanted to share this information with the public and he said he was willing to post it. This text contains the emails we've been exchanging.

A few things which are not relevant to the public have been deleted. This slightly distorts the spacing in some paragraphs. In a few places, I've inserted editorial content, enclosed in braces {}, for clarity.

The contact data for David and myself is shown below.

I hope this information will be useful to those working with GPS for time purposes.

Sincerely,

Ron Frazier

David's Email Signature

SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: ntp AT david.taylor.name

Ron's Email Signature

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

In the beginning ...

RON said on 01/28/2012 16:32 EST

Hi David,

You don't know me but I've been reading and studying quite a bit regarding NTP and GPS, including your page http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html and others on your site. My name is Ron Frazier, and I live in the USA in the state of Georgia. I have 3 computers that dual boot between Windows and Linux. I ultimately got a USB GPS running on one of my Windows machines. I want to get all the machines set up to be able to run the GPS, depending on which one I plug it into, whether booted into Windows or Linux. I'd like to share my experience with you thus far, and I have a number of random questions. I figured that sharing my experience might help you when helping others.

I got fascinated with accurate time after using some Christmas money to buy an "Atomic" watch and a couple of wall clocks that receive the WWVB radio signal from NIST in Colorado. I really like the fact that they're always right (on the display) to the second. Internal error between refreshes should be less than +/- 500 ms. I wanted nothing less from my PC's. For years, I've had a little program from NIST polling the NIST server every 4 hours. It worked, but didn't give me any statistics (other than daily drift), worked only with one server, and was not adaptive. I had previously also set up NTP using the default configuration on my Linux side of the dual boot fence (on Ubuntu).

After dealing with these atomic clocks, I decided I wanted to take it to the next level. I wanted the same accuracy from my PC's as my wall clocks, ie +/- 500 ms per 24 hr. That didn't seem like too much to ask. How little did I know. After many many hours of Googling around, I found your pages, as well as some others on the topic. In my opinion, credible, clear, concise information on this is very hard to find, particularly about Windows. I also put a query out on a Linux message board that I'm on. The basic reply was "use NTP, problem solved, what's the issue?". They were friendly, and said somewhat more than that, but not a lot. I started investigating the ntp.conf file since I already had NTP running on my Linux side of the dual boot fence. I replaced the default Ubuntu servers with 4 NIST servers, 4 strategically selected Stratum 2 servers, 4 random NTP pool servers, and the Ubuntu time server. I turned the thing on and let it run with a minimum polling interval of 8 minutes (which meets the minimum quota for NIST of 4 minutes) and a maximum polling interval of 2 hours. I have noted that the default configuration of NTP only polls from 60 seconds to 16 minutes. So, even though some of my Linux friends say only poll every 24 hours, the default configuration of NTP polls much more than that. Also, if I let one of my PC clocks run for 24 hours, it will be about 15 seconds off. I have also noted that, even though I'm giving NTP leeway to poll as much as 2 hours apart, on some machines, it rarely exceeds 1 hr. So, it's own algorithm is telling it to poll more frequently. The offset from the preferred NIST server peaks out at around 120 ms in this case, and usually stays within 50 - 80 ms.

Let me share what I've done thus far. For the purposes of this discussion, I'm running Windows 7. I purchased a GlobalSat BU-353 USB GPS receiver from Amazon. This unit is highly regarded and cheap, less than $ 30 USD. It does not have PPS, but I wanted to see what I could get out of it as is. For my purposes, I know I can get 120 ms accuracy from internet polling. This is plenty accurate to know the seconds indicator is right, although, psychologically, I'd like to see it a bit tighter. I'd also like to poll the internet less often. I think I'll be happy if the USB GPS consistently maintains 15 - 20 ms. I'm sort of biased with that number, seeing as I've already seen the offset chart after testing, and I know it won't do 5 ms. GlobalSat also makes some serial GPS's, which I might try later. From my experience thus far, I really like this little GPS. This one is cool since it works with Windows, Mac, or Linux.

This GPS uses a SiRF III (I think) chipset and uses a built in Prolific serial - USB converter. If anyone asks me, I'd suggest downloading the drivers from the GlobalSat factory website rather than using the CD that comes with the unit. Download the GPS driver, the GPS Info program, and the SiRF Demo Program.

Web links

Drivers

The GPS driver installs the Prolific serial - USB driver so you can connect the GPS and it appears as a COM port.

GPS Info can be use to test any NMEA GPS on a COM port.  http://www.usglobalsat.com/store/downloads/GPSInfo.zip

SiRF Demo is used to program the features of the GPS.  http://usglobalsat.com/store/downloads/SiRFDemo387.zip
 

Installation

First, install the GPS driver, which is really the Prolific serial - USB driver. Then, install GPS Info and SiRF Demo.

I had read somewhere that the serial driver needs hardware flow control to avoid Blue Screen of Death (BSOD). So, I plugged the GPS, in turn, into each USB port on my computer. It will assign a new COM port to it each time. Then, once it's plugged in, I go to Device Manager under System under Control Panel, select LPT and COM ports, and select the port settings for the port that just activated. In my case, the first one was COM3. I set the parameters to 115200 baud, 8 data, no parity, 1 stop bit, hardware flow control. Then I save those settings. I then plug the GPS into the next port, it assigns another COM port, in my case, COM4. Then I set it's settings. Then, I do the next one, etc. The next time you plug the GPS into one of those ports, the settings should already be there. I ended up using the USB port associated with COM5 for my purposes.

I have no idea what this actually means in conjunction with what is actually a USB connection, but the system seems to like it. Also, just because these settings are this way, doesn't mean that the GPS has to communicate at this rate.

Next, I wanted to reprogram the GPS. For one thing, I think running it 4800 baud introduces way too much latency. So I wanted to ramp that up. Also, I read somewhere, I think on one of your pages about the Sure Electronics GPS board, that using the GPGGA sentence works better than the GPRMC sentence, so I wanted to set it to that. I have verified, using an older Garmin Etrex Legend GPS, which I cannot program, that the NTPD program from Dave Hart will work with a standard NMEA output at 4800 baud outputting ALL the sentences. However, latency and jitter is horrible, on the order of 200 ms.

To program this GPS plug it in, run SiRF Demo, set it's data device settings to COM5 (in my case) and 4800 baud. Click the icon to attach to the data source and you should see the NMEA sentences in the debug window. If you have any doubts as to the status of the unit, use the menu option to send a factory reset. In this case, you may have to reattach. Use the menu option to switch to SiRF protocol mode. Then, the debug window will stop and the response window will activate. Now, you can use the menu option to switch back to NMEA mode. Once you do that, you will get a popup which asks how often you want each sentence to occur per N seconds. You select the N from a drop down box. The most often a sentence can occur is once per one seconds. If you say once per zero seconds, it turns the sentence off. I set everything to zero and set the GPGGA sentence to ONE, for once every second. In the same dialog box, you can set the baud rate. I set it to 57600, the highest it would go.

Once you send the command, the debug window should start up again, and the GPGGA sentences should be appearing and nothing else. The status line at the top of the screen should show COM5 (or whatever) at 57600 baud. Click the toolbar icon to detach SiRF Demo from the GPS. The GPS is now ready to be used with NTP. Note that this GPS, according to my reading on the GlobalSat site, stores it's configuration in volatile memory powered by an internal super capacitor. If you leave it unplugged too long, it will revert to factory default settings. I have no idea how long this time period is.

After reading around on the net, the Meinberg NTP port seemed to be the preferred choice, so I installed it. Then, based on your website, I substituted the main programs with the following from the Dave Hart site:

ntp-4.2.7p249-win-x86-bin

At this point, I was stymied by the need to set the COM port in ntp.conf to COM5 and to set the baud rate to 57600. These little details were very hard to find. Anyway, I finally concluded that if you put mode 16 on the server line in ntp.conf, it will go to 9600 baud. Mode 32 is 19200, mode 48 is 38400, mode 64 is 57600, and mode 80 should be 115200. I don't actually know if 115200 will work. These represent the decimal equivalent of the binary numbers 001, 010, 011, 100, and 101 in the 2nd byte of a 2 byte number. I also found, somewhere, that if you add 2 to the mode line, it will select the GPGGA sentence. So, I'm using mode 66. Finally, I had to deduce that using the address 127.127.20.5 would activate COM5 based on reading elsewhere about someone using COM2 or something.

{ editorial insertion

Here are the parts of my ntp.conf file which relate to the GPS.

# ---------- GPS ---------- GPS ---------- GPS ---------- GPS ---------- GPS -----

# Uncomment this if GPS is available, Tweak com no. Unprefer NIST.
# GPS on COM5 - xxx.xxx.xxx.5 - Mode 16 = 9600 baud Mode 64 = 57600
# Add 1 to mode to use GPRMC sentence - same as default
# Add 2 to mode to use GPGGA sentence - may have better timing
# Mode 66 = 57600 baud and use GPGGA sentence
# Fudge - Tweak the GPS input for less offset from nist

# GlobalSat BU-353 USB GPS - 57600 baud COM 5

server 127.127.20.5 prefer minpoll 3 maxpoll 3 mode 66
fudge 127.127.20.5 time2 0.3550 refid GPS1

# Garmin Etrex Legend Serial GPS via serial to USB - 4800 baud - COM 3

#server 127.127.20.3 minpoll 3 maxpoll 3 mode 2
#fudge 127.127.20.3 time2 0.6000 refid GPS2

# --------------------------------------------------------------------------------

} end editorial insertion

I am happy to say that, when I cranked it up, it started reading the GPS properly on COM5, at 57600 baud, and interpreting the GPGGA sentences. Then, I had to deal with the fact that the offset was about 400 ms off from the other internet servers and NTP really got freaked out by that. I read and read and couldn't figure out how to program the offset to match the internet servers. I tried to fudge time0 and time1 and that didn't work. I've seen some ntp.conf files with these parameters in them (at least time1). I finally fudged time2 by 355 ms. Then, I had a problem where NTP would choose internet servers rather than my GPS. I read somewhere on another page that you should turn off iburst or it screws things up. I saw at least one page with iburst on the GPS, but that didn't make any sense to me, so even though I was using iburst before installing the GPS for the internet servers, I no longer am using it on any server.

I am happy to say that I now have the GPS running on my USB port, emulating COM5, on Windows 7, and achieving a consistent offset between the GPS and the computer clock of less than +/- 15 ms. This is acceptable to me, although I was hoping to get it under +/- 10 ms. The jitter is generally under 3 ms. As I understand it, NTP should poll the internet servers if my GPS is unavailable or fails. I've included a copy of ntp.conf attached. { see above } I'd like your opinion on the settings I'm using. Not only is the PC synchronizing nicely with the GPS, it's in pretty close agreement with the Internet time servers. 

IMPORTANT NOTE: I have noted before using other programs, that when I run something other than the OS at realtime priority, it can destabilize the system. This version of NTPD starts itself at realtime priority, which I don't want. I am changing the priority of the NPTD to above normal by hand using task manager. I would REALLY like to know how to start this thing at above normal rather than having to do the change by hand. I had to go searching the registry to find where the service's start up settings are stored. I tried using the -P switch to change the NPTD priority, but it didn't work.

I would like to know what experience you and others have had running a USB GPS without PPS and whether mine is similar. I'd also like to know whether mine is performing about as well as it can under these conditions. I have also noticed that the polling interval for the external servers never really extends above 512 s. I was hoping it would extend out to the maxpoll limit of 2 hours (in my case) and was wondering why it didn't. Actually, I don't care if it polls the internet more than once per day if the GPS is working. However, if the GPS fails, I don't want it to wait a day to figure itself out. I'd also like to know what the frequency graph means, which I've never quite understood.

I'm hoping to do some experiments with PPS over USB using an external serial - USB converter. I looked long and hard to find such a converter which supports all the RS-232 handshaking signals. I found the Trendnet TU-S9. It turns out, coincidentally, that it uses the Prolific chipset also. So, when I plug in the serial - USB converter to the USB port, it automatically initializes using the same driver that I installed for the GPS device. It should, in theory, feed the handshake signals to the virtual COM port driver, and I'm hoping that NTP can read that PPS output, as though it were connected to a real serial port. I'm hoping to get +/- 1 ms accuracy this way between the computer's clock and the GPS clock. +/- 5 ms would be OK. I don't currently have a PPS GPS to play with. I might try one of GlobalSat's serial models or maybe the Sure Electronics board. I'm wondering if you've had any experience with using PPS over USB with handshaking. I'd like to know what other people have done in this regard.

I'm hoping you can help me take this to the next level. I intend to configure all my Windows PC's to accept the GPS signal for NTP if it's plugged in. I want to set one PC to provide time service to the others on the LAN, where they poll it, just as they would the internet. I don't normally have any communications between my PC's, and have software firewalls running in each. I would also like to do all this same setup when I boot into Ubuntu Linux, and have each PC capable of reading the GPS, and one of them capable of being a time server. If the GPS is unavailable, I want each one to hit the internet servers. I don't understand how the server related parts of ntp.conf work, including the peering and restrict elements. I read somewhere that the meaning of restrict has changed in different versions of NTP. I also don't understand what the difference in functionality is between the Windows port of NTP and the standard Linux versions in Ubuntu, for example. I don't really know what the next step to take is, other than configuring each Window PC to accept the GPS in stand alone mode.

I hope this information is helpful to you and others, and I hope you can help me move my project forward. And help and advice you can give me would be greatly appreciated. I'm looking forward to hearing from you.

Sincerely,

Ron

DAVID said on 01/29/2012 07:29 EST

Ron,

Thanks for your e-mail, and I'm glad you're enjoying NTP. Quite a lot of experimenting!

There's a lot of information there. You have done well to get a GPS working that well over USB, and that's perhaps approaching the best which can be done. If you have a Web page with this information, I can link to it. Otherwise, I could add a page to my NTP set describing your experiences, if you would like to provide the text.

Because of the lack of PPS, uncertainty in the serial timing, and working over USB, I would normally not recommend such a GPS device, but you do seem to have addressed at least some of those issues, and possibly have been lucky in your choice of device. Your performance (from the loopstats) is perhaps similar to a Wi-Fi connected PC looking at one of my stratum-1 servers. Using the higher baud rate almost certainly helps (although whether it means anything at all when over USB I don't know).

To try and answer your questions:

  • NTP poll interval. I see no reason to change the defaults for an Internet-connected NTP. If you want to set the Internet servers to be 20 minutes minimum (sensible if you are relying on the GPS/USB device), you could put:
        server 0.uk.pool.ntp.org minpoll 10
        server 1.uk.pool.ntp.org minpoll 10

Oh, I see you already sussed this!

  • iburst on ref-clock. I don't have iburst on my GPS device, but I do on all other servers.
  • offset & jitter values. I can't really say how well a current NTP with Internet-only servers might perform, as I don't have that configuration. Nor could I say whether Windows would perform as well as Linux on an Internet-only configuration. Gut feeling is that it might not, but I have nothing to back that up.
  • "I had read somewhere that the serial driver needs hardware flow control to avoid Blue Screen of Death (BSOD)." - I've never seen that here.
  • The drivers emulate a COM port, so that program can use just the same system calls, but specify COM5, or whatever. One issue is that some drivers do a better emulation job than others! FTDI chip-sets and drivers are reliable, though.
  • The Sure Electronics board happens to send the $GPGGA sentence first, that why I use that setting.
  • I don't know how many bits there are for baud rate selection, but I can't get to Dr. Mills pages to check this. The Linux folk may say check the source.
  • Only comment on ntp.conf is that you have too many servers (in my view). Seven in addition to your GPS should be fine. Remove the ones with greatest delay and/or jitter, or the ones in red on the Time Server Monitor display.
  • I've seen no problems with NTPD at realtime priority on several systems, some handling time-critical satellite data. Leave it, I suggest.
  • The frequency graph shows what NTP believes to be the clock frequency. It possibly matters most if the offset becomes 300-400 ppm, as that is getting near the hard-coded 500 ppm at which NTP gives up!
  • All my GPS serial connections have been three wire + ground only. TX, RX, ground + PPS signal over the DCD line.
  • I've never touched "restrict" lines.

Your next step could be a Garmin GPS 18x LVC or Sure Electronics board, and equipping one of your PCs with a real serial port (likely the headers are already on the motherboard). Then get the other PCs syncing to that in addition to the Internet servers.

Cheers,
David

RON said on 01/29/2012 19:17 EST

Hi David,

Thanks for your reply email. I appreciate you taking the time to answer my questions. It was only after I wrote the email that I found the NTP questions forum and found out how active you are on it, so you must be pretty busy. By the way, if I click on your name on a question in the forum, it says your email address is invalid for some reason. I got the address I used from your website.

I'm writing you today to share a couple of loopstats files I thought you might like to see. By the way, my time zone is UTC-5 if you're inclined to convert to local time.

{ editorial note - the loopstats files are not attached to this text }

The first file is: loopstats.20120129p08-2-above-priority. This file shows a time interval when I'm polling the GPS every 8 seconds and I manually set the process priority at Above Normal.

The offset is pretty much staying within +/- 11ms except for two discrepancies. There is one spike at ~ 06:45 (which is 01:45 my time). I'm 99% certain this is when my anti virus scanner started up. If you look, there is a huge disruption in frequency at the same time. I don't know exactly why this occurs, but find it interesting, as well as frustrating. There is also an offset spike around 16:08, but I cannot explain that. Jitter is generally around 2.6 ms with spikes up to 6 ms. Overall, though, I would consider almost all of this graph normal and consistent pretty good performance for my equipment.

The next file is: loopstats.20120129p08-3-real-priority. The only difference in this file and the previous is that I left the NTPD process on RealTime priority as you suggested. The performance in this case is much worse, although it started out fine. But, during the course of the graph, there are excursions to the 32 ms range. There is a huge discrepancy at ~ 18:00, and other smaller discrepancies at ~ 19:30, ~19:57, ~ 20:55, ~ 21:15, ~ 2135, and ~ 21:40. Jitter averages about 2.8 ms but has spikes up to 16 ms.

So, it looks like RealTime Priority is performing much worse than Above Normal priority for me, although that sounds counter intuitive. Of course, this is not totally conclusive, so I'm going to be doing further testing. I just thought you'd like to see it. I have a hunch that the NTPD process is occasionally fighting with the OS for system resources. I've have occurrences before where I put Firefox on RealTime priority, to watch videos or watch trading charts, etc., and it destabilized or even locked up the system. I find the behaviour shown in these graphs quite fascinating.

I'll be in touch about some of the other things you said in your reply later.

Again, thanks for your help.

Sincerely,

Ron

DAVID said on 01/30/2012 04:44 EST

{ editorial note - Quoted parts are Ron, plain parts are David. }

> Hi David,
>
> Thanks for your reply email. I appreciate you taking the time to answer
> my questions. It was only after I wrote the email that I found the NTP
> questions forum and found out how active you are on it, so you must be
> pretty busy. By the way, if I click on your name on a question in the
> forum, it says your email address is invalid for some reason.

The e-mail address I use for USENET ends in .invalid to try and reduce spam.

> I'm writing you today to share a couple of loopstats files I thought you
> might like to see. By the way, my time zone is UTC-5 if you're inclined
> to convert to local time.

Maybe!

Ron,

To me, the performance with either "above normal" or "real-time" is essentially the same - about 3 ms RMS offset, and 2.4 - 2.6 ms jitter. I think you will only see the difference when you start to use a PPS signal, and every becomes an order of magnitude or two better. To be fair, you really need to run for a day, or several, with each setting, as if there's something which is being caused by scheduled jobs it would show up at the same time. The "above.." plot has no concerns for me. Yes, there are spikes in the real-time plot, and I don't understand why there are two almost straight line rises (~17:52 and ~19:55).

I would never put "user" programs such as Firefox on real-time priority - that is living dangerously! Only use "Above...", and only if absolutely necessary. Only put programs designed to work in real-time at that level, programs such as ntpd.exe.

Cheers,
David

DAVID said on 01/30/2012 09:55 EST

Ron, please see:

  http://www.satsignal.eu/software/net.htm#NTPplotter

I added the local time display update for you. Please test and report back.

Cheers,
David


RON said on 01/30/2012 14:42 EST

Hi David,

WOW! I didn't expect you to modify the plotter program. I just thought you might want to do the conversion in your head while looking at the chart. I like the new feature. It's very handy. I've tested it briefly and will be working with it more thoroughly in the next few days. At first, I didn't know how you were accounting for different time zones, then I realized you're pulling that data from the computer's time settings. Very clever - as opposed to just asking the user the offset from UTC. I switched my PC briefly to Central Time and it picked that right up. Then I put it back to normal. I'm wondering if it will work properly when the computer switches to daylight savings time. Hopefully, these issues related to local time won't add too much complication to your program. Note that at least one area in the US does not observe DST, although I assume their computers know that. The feature seems to work fine with a single chart. I noticed that it does rewind properly if the time range crosses a date boundary. Very cool. However, if I drag multiple charts onto it, the time scale doesn't change when I click the local time check box.

{ editorial note - He fixed the time scale problem. }

I'm not trying to pick your plotter program apart, but I noticed one other minor anomaly. When you switch from the offset to the jitter tab and back, the "weighted" and "hours to average" fields vanish and are no longer visible.

{ editorial note - This is fixed in the most recent version. }

I have a few of questions about the usage of the NTP Plotter program.

I have noticed that by clicking and dragging on the chart, it seems possible to change the scales. However, I cannot determine what the pattern or method is. The usual result is that my chart vanishes because I don't know exactly how to control it. I was wondering how that works.

I was also wondering what the weighted, and hours to average, and jitter first controls do.

Finally, what is the significance of the RMS value of the offset?

For your amusement, I have attached another loopstats file. This one is: loopstats.20120130p08-1-real-priority.

{ The loopstats file is not attached to this text. }

I was discouraged to find, this morning, at around 13:00 UTC, that my offset and jitter measurements were going off the chart, so to speak. I restarted the NTPD process and set it to Above Normal instead of Realtime priority. No help. I went to the time setting screen and turned off the Windows "internet time" function. No help. (Actually, I thought the Meinburg installer had already turned that off, but I guess not.) I then shut down the NTPD service, unplugged the GPS for 30 sec and plugged it back in. Boom! I'm back to my normal operation of +/- 10 ms or so offset and ~ 3 ms jitter. This is very frustrating. Perhaps I spoke too soon in raving on about this GPS. It looks like either it has a firmware flaw or the serial - USB driver has a problem. I have also noticed from the NTP Monitor screen that the offset between most of the internet servers I have configured and my GPS clock seems to increase over time. I'm going to be doing further testing, but, if this GPS is not stable over time, I may have to exchange it for another.

Finally, I've noticed a couple of times looking at the advanced statistics in the Meinburg NTP Monitor, that sometimes NTP changes from looking at the GPS to polling some of the internet servers. Then, a while later, it goes back to polling the GPS. Although it's not a big deal, I'd like to force the system to never use the internet time as long as the GPS is working, if you know how to do that.

Thanks for your help.

Sincerely,

Ron

DAVID said on 01/31/2012 07:36 EST

Ron,

Thanks for checking the program, and I'm glad you find the Local Time feature useful. Yes, it should work in DST as well, and just uses the local computer settings when reading in the data, adding or subtracting the appropriate value from UTC. There was one issue with multiple charts - pressing the Refresh F5 button twice lost all but one of data sets, so I've uploaded a new version (with a new minor release number) so perhaps you could see whether the problem is cured.  I couldn't reproduce the problem exactly as you described it.

The controls which disappear are not available on other than the Jitter tab.

{ editorial note - This is fixed in the newest version of the NTP Plotter program. }

The graph magnifies if you mouse stroke south-west to north-east, and reverts to normal size on a south-east to north-west stroke (possibly even just a right-left stroke). Hover over the controls to see what they do. RMS offset is simply a guide number as to how good the performance is. The right-click histogram (first chart only) is perhaps more useful.

Yes, the W32time service (or whatever it's called) will have been disabled, and if it was not, you did the right thing in turning it off. I already suggested some GPS receivers you might like to investigate.

If NTP is dropping to the Internet servers it is because it thinks they are better. All points to getting a real serial port and PPS-enabled GPS. If you really want to not use the Internet at all, mark the servers NOSELECT (IIRC), but that's permanent. Useful for monitoring the offsets while not allowing the servers to influence NTP.

Cheers,
David

RON said on 02/01/2012 12:14 EST

{ editorial note - Quoted parts are David, plain parts are Ron. }

See comments inline.

> Ron,
>
> Thanks for checking the program, and I'm glad you find the Local Time feature useful. Yes, it should work in DST as well, and just uses the local computer settings when reading in the data, adding or subtracting the appropriate value from UTC. There was one issue with multiple charts - pressing the Refresh F5 button twice lost all but one of data sets, so I've uploaded a new version (with a new minor release number) so perhaps you could see whether the problem is cured. I couldn't reproduce the problem exactly as you described it.
>

That's cool. I thought that (time zone stuff) was probably the case. I've had to divert my attention to some other things than GPS for a day or two, not for lack of interest though. I've tested your new plotter version which I downloaded when I got this message, very briefly. At first glance, the time scales seem to be working properly, even with multiple files being plotted. Very nice. Overall, I really like the program and find it quite useful.

> The controls which disappear are not available on other than the Jitter tab. The graph magnifies if you mouse stroke south-west to north-east, and reverts to normal size on a south-east to north-west stroke (possibly even just a right-left stroke). Hover over the controls to see what they do. RMS offset is simply a guide number as to how good the performance is. The right-click histogram (first chart only) is perhaps more useful.
>

I really like the zoom feature, now that I know how to use it. There seems to be a discrepancy between your wording above and the wording in the readme.txt file regarding how to zoom. (OK, I admit to only briefly skimming the readme the first time.) I think both work. It might be simpler to say click and drag the mouse diagonally to the right to zoom and diagonally to the left to restore, or something like that. As long as the dragging is diagonal (has a vertical component), either direction up or down to the right seems to work to zoom and either direction up or down to the left seems to work to restore.

{ editorial note - Documentation is updated in the latest version of NTP Plotter. }

> Yes, the W32time service (or whatever it's called) will have been disabled, and if it was not, you did the right thing in turning it off. I already suggested some GPS receivers you might like to investigate.
>
> If NTP is dropping to the Internet servers it is because it thinks they are better. All points to getting a real serial port and PPS-enabled GPS. If you really want to not use the Internet at all, mark the servers NOSELECT (IIRC), but that's permanent. Useful for monitoring the offsets while not allowing the servers to influence NTP.
>
> Cheers,
> David

I'm still testing my USB GPS. I don't know what caused the horrendous offset and jitter excursions I emailed you about. It's possible that the satellites were not visible or strong enough. I verified that my serial - USB driver was up to date and also that the two firmware sets in the GPS receiver (SiRF and GlobalSat) were up to date. I did a factory reset, then a cold restart and let it reacquire all the satellite data. I then reprogrammed it for the baud rate and sentence I wanted. Since then, running NTPD on Above Normal priority, I have about 40 hours of very consistent behaviour with offsets almost always in the +/- 15 ms range, which I'm happy with. I was appalled at several references on the forums saying that you can only get 250 ms from a USB GPS. I'm obviously getting an order of magnitude better than that. I'm going to continue testing this to see if it stays stable. I'm testing with the internet servers NOSELECT ed for the time being. The average offset between my GPS and them seems to be slowly increasing for some reason, although I need more data. I started with mostly single digit offsets, now they're mostly in the 30 - 40 ms range, although they seem to fluctuate down some times. Not sure why that would happen.

I do want to try a GPS system with PPS as you suggest.

Sincerely,

Ron

DAVID said on 02/02/2012 05:52 EST

Ron,

Thanks for your notes. I've updated the read-me with better information on the zoom and scroll feature. I lifted this from the documentation I found on Google, but even that was wrong or out-of-date!

Yes, you will need to select a good location for the receiver (or rather, its antenna) so that it sees a clear view of at least half the sky. You may find that putting it outside helps. Photo here:

  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm

There is widespread mis-information about USB, unless the people making the statements actually did the measurements for themselves. But unless you take care with baud rate and polling - as you have done, of course - the results may be little better than an Internet connection.

Cheers,
David



 
Copyright © David Taylor, Edinburgh   Last modified: 2016 Mar 10 at 07:37