[LinuxPPS] gps_nmea error

[Hal V. Engel]

On Monday 11 August 2008 10:36:43 am Ritter, Nicholas wrote:
> Here is my pps output that Hal and I think is screwy:
> > Here is my ppstest output:
> >
> >
> >
> >
> >
> >
> >
> > ./ppstest /dev/gpspps0
> >
> > trying PPS source "/dev/gpspps0"
> >
> > found PPS source "/dev/gpspps0"
> >
> > ok, found 1 source(s), now start fetching data...
> >
> > source 0 - assert 1218249194.821427087, sequence: 362781 - clear
> >
> > 0.000000000, sequence: 0
> >
> > source 0 - assert 1218249195.821418989, sequence: 362782 - clear
> >
> > 0.000000000, sequence: 0
> >
> > source 0 - assert 1218249196.821427057, sequence: 362783 - clear
> >
> > 0.000000000, sequence: 0
> >
> > source 0 - assert 1218249197.821418825, sequence: 362784 - clear
> >
> > 0.000000000, sequence: 0
>
> I think I have problems with the build and configuration of the box. I
> am going to start over and see where it leads me. I noticed that ntp has
> it's own gps driver, should I still apply a patch?
>
>
>
> BTW - does anyone have suggestions on PC hardware that makes a good NTP
> server? I have budget to buy a computer for this if needed, but I have
> not found a hardware buildout that assurs better clock stability than
> another, yet I have read multiple sources that said that some
> motherboards are good and some are bad, but that is hit or miss. I don't
> have budget for hit/miss and was looking to see if anyone had
> suggestions on a vendor (HP vs. Lenovo vs. Dell, etc.)

Have a look at this:

http://www.febo.com/pages/soekris/

"When fed with a quality reference signal at 10MHz to drive the system clock, 
and a quality PPS signal to provide timetags, it can keep time to within a few 
hundred nanoseconds ."

You may not need this level of accuracy.   It all depends on how accurate you 
need your time server to be.  For many uses sub millisecond times are more 
than good enough and with a correctly setup refclock and ntp on a normal PC 
you should be able to achieve this.  My machine even with widely flutuating 
temperatures and loads will keep the clock to within 200 microseconds at all 
times.  My machine is using an unmodified off the self motherboard.

The hardware from the above web site is not exactly a "PC" but it is x86 
hardware that is intended for building network appliances. It does require 
some customizations to the hardware to get the kind of accuracy he claims (sub 
microsecond at all times).  But it is doable if you are not affraid to do some 
hardware mods.  He is also using a stripped down BSD kernel but you should be 
able to do something like this with Linux using the LinuxPPS patches.  In 
addition the types of mods he has done to that hardware could also be done to 
a normal PC motherboard.

I think what most of us here are seeing is that almost all PCs have very cheap 
crystal occillators that are not temperature corrected (I suspect that 
motherboard vendors pay about $0.50 each for these - very cheap).  Even worse 
are that some PCs have uncompensated occillators with a built in frequency 
radomizer to reduce RF interferance (spread spectrum) that should be avoided 
unless the BIOS allows this to be disabled.  Which means that you are likely 
limited to after market motherboards since most name brand PCs have BIOS that 
will not let you disable spread spectrum.  Uncompensated occillators can 
easilly drift by several parts per million with normal room temperature 
changes even in temperature controlled rooms and in non temperature controlled 
situations can have much larger changes to the occillator frequency (on the 
order of 10 to 20 PPM).  

For example, I typically open my windows at night to allow the house to cool 
down and the temerature can drop by as much as 15C and sometimes more from 
it's peek.  The occillator in my PC likely drifts throught out the day by 
about 15 PPM because if this.   If my machine is temperature stable and is not 
loaded it will keep time to within a few microseconds but if there are 
significant room temperature changes the clock can get off by as much as 200 
microseconds.  So temperature changes along with the uncompensated clock 
occillator of your typical PC are a huge factor in how accurately ntp will 
maintain the time on your box.  The other significant factor is variability in 
the latancy of the PPS interupt handler which you can control to some extent 
by limiting how much your machine is loaded.  This is simply the nature of the 
beast and the only way to get around this is to either find hardware that is 
specifically build for timing which is likely hard to find and expensive or to 
modify existing hardware which requires some techincal experise.   (Not quite 
true there is a web site that talks about using a temperature probe to track 
the temperature near the occillator and using that data to feed a temperature 
compensation correction into ntp and getting significantly improved results.)   

Basically the above system has had the cheap occillator replaced by a highly 
stable one.  I don't know exactly what occillator he used to drive this clock 
but on ebay you can get OCXO occillators that are good for about +- 0.01 PPM 
for as little as $30 plus shipping that should allow you to achive that level 
of performance.  So you could do the whole mod for under $200 including the 
powersupply for the OCXO but not including labor.  Less costly would be to 
find a TCXO in the correct package and frequency to replace the one on the 
motherboard and just replace the uncompensated occillator.  This should cost 
less than $30 for parts.  TCXO's should get the occillator drift down to less 
than 1 PPM which would reduce temperature drift by over 90% compared to an 
uncompensated occillator while being a fairly low cost and simple to do mod. 

>
>
>
> Also, When I attached minicom to the serial port, I see the GPS data
> coming in, should I see something else? I don't know what to look for to
> actually "see" the PPS pulse. I reduced the number of sentences sent by
> my Garmin 18 LVC to to just the three time related sentences, despite
> NTP only paying attention to the one sentence.
>
>
>
> Could the DATUM setting and NMEA version setting of the GPS have an
> impact? In that NTP would not be able to parse a particular datum string
> format?
>
>
>
> Here is what I see via minicom:
>
>
>
> $GPRMC,161840,A,4302.2074,N,08925.2269,W,000.0,291.6,090808,001.8,W*7D
> $GPGGA,161840,4302.2074,N,08925.2269,W,2,07,1.5,281.3,M,-34.4,M,,*71
> $GPGLL,4302.2074,N,08925.2269,W,161840,A*3F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20080811/9816e4f7/attachment-0001.htm