[ntp:questions] help with setting up NTP on windows with a USB GPS

Dave Baxter g8kbv at nospam.uko2.co.uk
Tue Dec 1 13:58:01 UTC 2009


In article <de5f9a1f-d0bc-4949-980c-76a98680a087
@g4g2000pri.googlegroups.com>, davehart at gmail.com says...
> 
> On Nov 30 22:06 UTC, Dave Baxter wrote:
> > I had (killed it now) a version of the patched serial.sys for PPS
> > support, but it BSOD'd the machine at boot time (black screen) needing a
> > physical removal of the hard drive, and temporary fitment into another
> > PC to put the original file back.
> 
> I'm sorry to hear that.  I note that to me, BSOD/bluescreen means
> something distinct from hanging with a black/blank screen.  The former
> implies a "bugcheck", akin to a kernel panic.
> 
> I managed to develop the two revisions of serialpps.sys without
> experiencing any bluescreens.  In fact, it was about as painless as I
> could have hoped for, but then I haven't actually tried any of the 64-
> bit builds.  Given the tiny changes between serial.sys and
> serialpps.sys, and the fact that the code to implement the new "ioctl"
> interface is cloned from several other examples in serial.sys,
> combined with experience from a number of other users, I will be
> surprised if there turns out to be a bug unique to serialpps.sys
> involved here.
> 
> > At present, I can't find a ready-to-use binary of that file.  Dave
> > Hart's site befuddles me, all I can see there is a *Huge* collection of
> > files, what file do I need and where from, exactly please.?
> 
> To have full PPSAPI capability with ntpd on Windows you need
> serialpps.sys, serialpps-ppsapi-provider.dll, and a recent-enough
> ntpd.exe.  You need a serial port which can be driven by the stock
> serial.sys (which includes a huge variety including some simple
> multiport designs).  serialpps.sys must be "installed" (if you can
> call it that, the file must be in place and pointed to by the
> serial.sys image path registry entry).  serialpps-ppsapi-provider.dll
> must be accessible and pointed to by environment variable PPSAPI_DLLS
> visible to ntpd.exe (typically set systemwide), such as
> 
> C:\>set
> ...
> PPSAPI_DLLS=c:\serialpps\serialpps-ppsapi-provider.dll
> ...
> 
> You can find both serialpps.sys and serialpps-ppsapi-provider.dll in:
> 
> http://davehart.net/ntp/refclock/serialpps-20090606.zip
> 
> There are more releases of serialpps .zip files in that directory than
> there are different versions of serialpps.sys within.  The most recent
> changes, adding serialpps-ppsapi-provider.dll, simply shuffled code
> previously hard-wired into ntpd.exe off into a per-provider DLL, but
> did not change the ioctl interface or serialpps.sys.
> 

Hi David...

Well, my mistake, I had obviously missed a critical stage in the 
serialpps deployment, as I just copied it over the original serial.sys 
(as that name) not doing the registry thing!

The problem that caused, was a looping boot, BLACK screen, boot, black 
screen etc etc, as soon as the GUI part of Windows tried to start.

This is (was) on Windows 2000 Pro, on a compaq small form deskpro 
machine, with two "real" com ports, neither were connected to anything 
at that time..   Absolutely zero chance of getting any memory dump, but 
from your comments about registry settings etc  "I got it wrong Dad!"  
As earlier, I honnestly don't know why I missed that part of the setup.

Is there a blow by blow (with screenshots?) description as to how to put 
all this together anywhere?   David Taylor's site gets close, but I 
suffer "informaion overload" after a while.   (The Grey cell version of 
a buffer overun I think!)

As my ultimate aim, would be to get this working on the same physical 
system that run's Faros (trying to keep the electric bill in check!)  
What colateral effects will the serialpps.sys driver have on the other 
com port, as that will be used for controling the radio (data lines 
only.)   Also, what effect would it have on, or be affected by, the CPU 
loading of the needed DSP routines that kick off once every few seconds.

Currently Faros lives on a P3/666MHz PC, pushing the CPU to about 30% at 
times.  I've been playing with a P3/1GHz machine for NTP.   I could move 
everything over to that, but I'd like to keep that box for some other 
DSP intesive communications apps, unrelated to the propagation monitor.

Comments, suggestions welcome.

Regards.   You can all stop laughing now!

Dave Baxter.




More information about the questions mailing list