>>Since you have a GPS receiver, three internet servers should be
>>sufficient as backup and a sanity check for the GPS.
>See below, now set up as recommended with three us.pool.ntp.org
>servers but as you say it will take some time to be useful, but I
>don't seem to be getting the NEMA data as of
George R. Kasica wrote:
> still seing both of the local GPS/PPS entries as false tickers but I
> also see the offsets are huge compared to other clocks...where do I go
> from here to correct this??
You are probably detecting the wrong edge (wrong polarity) of the second
pulse.
_
George R. Kasica wrote:
>>> Since you have a GPS receiver, three internet servers should be
>>> sufficient as backup and a sanity check for the GPS.
>> See below, now set up as recommended with three us.pool.ntp.org
>> servers but as you say it will take some time to be useful, but I
>> don't seem
On 2008-12-28, Hal Murray wrote:
>
>>Another problem with PPS, specifically in the ATOM drivers is that the
>>driver provides no information about whether or not it is using the PPS
>>signal.
>
> The ATOM driver can't use anything else so all you can get is
> 1 bit for working or not. Isn't the r
Garmin specs say: The rising edge of the signal is aligned to the
start of each GPS second. This means edge on assert right? So flag2
should be 0?
What is going on here?
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman
On Dec 24, 8:09 am, k...@uiowa.edu (David R. Andersen) wrote:
> I have a Garmin 18LVC GPS set up at 9600 baud and emitting the GPGGA
> sentence. PPS is connected to pin 1 of the DB9 (DCD pin). I typically
> get 1-2 microsecond jitter with this setup and FreeBSD O/S. ntp.conf
> statements to enab
On Dec 23, 12:42 pm, David Woolley
wrote:
> dhavey wrote:
> > The performance is still really bad:
>
> You still don't have PPS.
>
> One of your other servers is in severe distress (stepping). Three of
> the servers for the first machine, including GPS and the other statum 1
> have been declared
>And if it is the frequency that is out ( as it always will be these days of
>linux because of the bugs in the kernel frequency standardisation) then
>that one step will not kick in until about an hour later ( and the system
>could die a horrible death, because the phase offset intially is correct
Hal Murray wrote:
>> And if it is the frequency that is out ( as it always will be these days of
>> linux because of the bugs in the kernel frequency standardisation) then
>> that one step will not kick in until about an hour later ( and the system
>> could die a horrible death, because the phase o
>> I'm missing something. My setup doesn't die. It just steps the clock,
>> and repeats the drift-off then step dance several times until the drift
>> gets close enough.
>Maybe you aren't running Linux?
That's what I'm running.
--
These are my opinions, not necessarily my employer's. I hate
George R. Kasica writes:
>>>Since you have a GPS receiver, three internet servers should be
>>>sufficient as backup and a sanity check for the GPS.
>>See below, now set up as recommended with three us.pool.ntp.org
>>servers but as you say it will take some time to be useful, but I
>>don't seem t
On Mon, 29 Dec 2008 12:30:39 +, David Woolley
wrote:
>George R. Kasica wrote:
>
>> still seing both of the local GPS/PPS entries as false tickers but I
>> also see the offsets are huge compared to other clocks...where do I go
>> from here to correct this??
>
>You are probably detecting the wr
On Mon, 29 Dec 2008 09:45:51 -0500, "Richard B. Gilbert"
wrote:
>George R. Kasica wrote:
Since you have a GPS receiver, three internet servers should be
sufficient as backup and a sanity check for the GPS.
>>> See below, now set up as recommended with three us.pool.ntp.org
>>> servers
George R. Kasica wrote:
> On Mon, 29 Dec 2008 09:45:51 -0500, "Richard B. Gilbert"
> wrote:
>
>> George R. Kasica wrote:
> Since you have a GPS receiver, three internet servers should be
> sufficient as backup and a sanity check for the GPS.
See below, now set up as recommended with
Richard B. Gilbert wrote:
> the horizon. Your GPS should select four of the available satellites
> and use their signals to compute a 4-D fix, latitude, longitude,
> elevation and time.
It should select at least four and compute a best fit 4D solution based
on all of them. In particular, the
George R. Kasica wrote:
> On Mon, 29 Dec 2008 12:30:39 +, David Woolley
> wrote:
>> You are probably detecting the wrong edge (wrong polarity) of the second
>> pulse.
> So how in the world do I fix this?
I suspect Unruh may be right in this case, but you fix a wrong edge
problem either by
George R. Kasica writes:
>On Mon, 29 Dec 2008 12:30:39 +, David Woolley
> wrote:
>>George R. Kasica wrote:
>>
>>> still seing both of the local GPS/PPS entries as false tickers but I
>>> also see the offsets are huge compared to other clocks...where do I go
>>> from here to correct this??
>>
>Garmin specs say: The rising edge of the signal is aligned to the
>start of each GPS second. This means edge on assert right? So flag2
>should be 0?
Try it the other way and see what happens.
RS-232 signals are active-low so "assert" may mean low.
--
These are my opinions, not necessarily m
>NTP doesn't seem to like 9600 baud with GPGGA. Reach is still zero.
Why are you surprised? NMEA says 4800 so that's what the NMEA driver in
ntpd uses.
I think there may be an option to use 9600. Check the documentation
and make sure it corresponds to the version of ntpd you are running.
--
>>You are probably detecting the wrong edge (wrong polarity) of the second
>>pulse.
>So how in the world do I fix this?
There is a fudge parameter to use the other polarity.
>Prior to having both NEMA and PPS running at the same time all was
>working well with just PPS and the shm driver.
Tha
Antonio,
If you are really from nic.br please use your email address from that
domain. It is unacceptable to use a gmail account for such notifications.
Danny
Antonio M. Moreiras wrote:
> Aiming to collect and analyze data from NTP network, a survey will be
> held at all hosts available for publ
> From: dhavey
> Date: Mon, 29 Dec 2008 12:07:25 -0800 (PST)
> Sender: questions-bounces+oberman=es@lists.ntp.org
>
> Garmin specs say: The rising edge of the signal is aligned to the
> start of each GPS second. This means edge on assert right? So flag2
> should be 0?
>
> What is going on
Richard B. Gilbert wrote:
[]
> I think your best help/advice will come from another GPS18LVC user.
I described my own simple setup here:
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
but it's not Linux, and I don't feel competent enough to give "advice".
It seems likely that the wrong edge
David J Taylor wrote:
> Richard B. Gilbert wrote:
> []
>> I think your best help/advice will come from another GPS18LVC user.
>
> I described my own simple setup here:
>
> http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
>
> but it's not Linux, and I don't feel competent enough to give
> "advice".
24 matches
Mail list logo
