In article <1155106938.437491.99440@b28g2000cwb.googlegroups.c om>,
"Eugen COCA" writes:
>Aug 9 09:51:03 ntp1 ntpd[62681]: kernel time sync disabled 2307
>Aug 9 09:51:57 ntp1 ntpd[62681]: pps sync disabled
>Aug 9 09:52:09 ntp1 ntpd[62681]: kernel time sync enabled 2107

I get this all the time. I attribute it to having the sensor
inside the house, on a window sill. I intend to place it outside
at some point.

>Aug 9 07:13:10 ntp1 ntpd[59412]: pps sync disabled
>Aug 9 07:20:34 ntp1 ntpd[59412]: pps sync disabled
>Aug 9 07:28:50 ntp1 ntpd[59412]: pps sync disabled

Mine comes and goes without having to restart ntpd. It seems to
be unsync'ed at the moment. Its usually under .01 for offset
and jitter. This is off the router that's sync'ing to it.

/usr/local/bin/ntpq -p -n
remote refid st t when poll reach delay offset jitter
================================================== ============================
*192.168.0.3 .PPS. 1 u 338 512 377 0.245 0.626 0.056

>Systems are: FreeBSD 5.4 + Garmin 18LVC

RH9 linux, same GPS.

--
Chris Richmond | I don't speak for Intel & vise versa

Chris Richmond - MD6-FDC ~ wrote:
> In article <1155106938.437491.99440@b28g2000cwb.googlegroups.c om>,
> "Eugen COCA" writes:
> >Aug 9 09:51:03 ntp1 ntpd[62681]: kernel time sync disabled 2307
> >Aug 9 09:51:57 ntp1 ntpd[62681]: pps sync disabled
> >Aug 9 09:52:09 ntp1 ntpd[62681]: kernel time sync enabled 2107
>
> I get this all the time. I attribute it to having the sensor
> inside the house, on a window sill. I intend to place it outside
> at some point.
>

Nope. All my sensors are on the top of the roof, 99% sky view.

> >Aug 9 07:13:10 ntp1 ntpd[59412]: pps sync disabled
> >Aug 9 07:20:34 ntp1 ntpd[59412]: pps sync disabled
> >Aug 9 07:28:50 ntp1 ntpd[59412]: pps sync disabled
>
> Mine comes and goes without having to restart ntpd. It seems to
> be unsync'ed at the moment. Its usually under .01 for offset
> and jitter. This is off the router that's sync'ing to it.
>

When these messages appear, the server will NEVER sync again against
the PPS signal without restarting the service (on FreeBSD of course). I
made this test for three days - no sync on GPS wihtout restarting the
service.

On 2006-08-09, Eugen COCA wrote:
> I have in messages.log a lot of messages from the ntpd service. The
> messages are:
>
> Aug 9 09:51:03 ntp1 ntpd[62681]: kernel time sync disabled 2307
> Aug 9 09:51:57 ntp1 ntpd[62681]: pps sync disabled
> Aug 9 09:52:09 ntp1 ntpd[62681]: kernel time sync enabled 2107
>
> This is a good situation. The server is synced with the GPS signal and
> report stratum 1.
>
>>From time to time (I could not determine if there are any factors that
> could influence this behavior) I have:
>
> Aug 9 07:13:10 ntp1 ntpd[59412]: pps sync disabled
> Aug 9 07:20:34 ntp1 ntpd[59412]: pps sync disabled
> Aug 9 07:28:50 ntp1 ntpd[59412]: pps sync disabled
>
> and the server is not synced with the GPS signal.
>
> To correct this last situation I have to restart the ntpd process.
>
I guess that it is time to enable some of the ntp logging system to rule
out any issues with your serial port DCD pin getting read. There are
some issues with serial port handling code with FreeBSD6 that will be
resolved when FreeBSD7 is promoted to mainstream. FreeBSD5 does not
have this problem.

I am using FreeBSD6-Stable with an Oncore and I get PPS syc enabled and
disabled messages whenever the satellite positions change throughout the
day. I have never observed a pps sync disabled that is permanent unless
the serial cable to the GPS is removed.

Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Thomas Laus wrote:

> I guess that it is time to enable some of the ntp logging system to rule
> out any issues with your serial port DCD pin getting read. There are
> some issues with serial port handling code with FreeBSD6 that will be
> resolved when FreeBSD7 is promoted to mainstream. FreeBSD5 does not
> have this problem.

I'm using 5.4-Stable.

>
> I am using FreeBSD6-Stable with an Oncore and I get PPS syc enabled and
> disabled messages whenever the satellite positions change throughout the
> day.

This might be a good explanation - I'll try to find out is during a
week the time when the messages apear are aprox. the same.

> I have never observed a pps sync disabled that is permanent unless
> the serial cable to the GPS is removed.
>
> Tom
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF

On 2006-08-10, Eugen COCA wrote:
>
> This might be a good explanation - I'll try to find out is during a
> week the time when the messages apear are aprox. the same.
>
It should happen twice a day, nearly 12 hours apart. Each GPS satellite
is in an approx. 12 hour orbit. Your view of the constellation is the
same about every 12 hours.

Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Thomas Laus wrote:

> It should happen twice a day, nearly 12 hours apart. Each GPS satellite
> is in an approx. 12 hour orbit. Your view of the constellation is the
> same about every 12 hours.
>

I don't think so ! Each GPS satellite do 2 Earth rotation every 24
hours. But, in a fixed point on the Earth, a receiver do not see one
satellite for 12 hours ! And, the algorithm implemented in the receiver
select the strongest signal from those received one time. So, the
receiver locks on several satellites over a day.

In article <1155356115.545749.124090@h48g2000cwc.googlegroups. com>,
Eugen COCA wrote:
> Thomas Laus wrote:

> > It should happen twice a day, nearly 12 hours apart. Each GPS satellite
> > is in an approx. 12 hour orbit. Your view of the constellation is the
> > same about every 12 hours.

True statement.

> hours. But, in a fixed point on the Earth, a receiver do not see one
> satellite for 12 hours ! And, the algorithm implemented in the receiver

He never said that one satellite was seen for 12 hours. Or at least
not in the quoted bit.

> select the strongest signal from those received one time. So, the
> receiver locks on several satellites over a day.

A non-site surveyed receiver needs at least four satellite before it can
even solve for time and should use all of those in view to reduce the
uncertainty.

A site surveyed receiver could use one satellite, but ought to use all of
those in view. Signal strength is not a good measure of which is the
best satellite.

(As a pedantic point, for any one satellite there will be points on the
earth that see it for a complete orbit.)