On 6/17/2013 16:55, Richard Cagley wrote:
Based on poor luck with ntpd/pps, I'm trying to have ntpd use the shared
memory driver provided by gpsd. Do I need to give a special flag to
configure for ntp to tell it to build in support for the shared memory
driver?
Using this for my ntp.conf
---
ser
On Mon, Jun 17, 2013 at 07:02:09PM +0100, David Taylor wrote:
> Thanks, Steve. My knowledge of the source tree is even more limited
> than my knowledge of "C"! In refclock_shm.c, it does say that the
> "peek" routine is called every second, so if the type 28 driver has
> an internal poll of one s
Richard Cagley wrote:
> Based on poor luck with ntpd/pps, I'm trying to have ntpd use the shared
> memory driver provided by gpsd. Do I need to give a special flag to
> configure for ntp to tell it to build in support for the shared memory
> driver?
>
> Using this for my ntp.conf
> ---
> server 12
On 18/06/2013 08:41, Miroslav Lichvar wrote:
[]
IIRC, the one second interval is used only to collect the SHM samples
and store them in a buffer. In the minpoll/maxpoll interval the
collected samples are processed in a median filter and one final
sample is used to update the clock. This improves
On Tue, Jun 18, 2013 at 12:22 AM, A C wrote:
> You need -n (lower case N) to force gpsd to start collecting data
> automatically. It normally waits for something to connect to its TCP port
> and enable data collection (the WATCH command as you discovered). If you
> start with just:
>
> gpsd -bn
On 6/18/2013 08:50, Richard Cagley wrote:
Hmmm, i had tried the -n before. It doesn't seem to help. After several
minutes there is no change to ntpq -p. Any other ideas for something
stupid I'm doing? Do you think it's a ntpd or gpsd issue...or something
else?
After several minutes, no change
Richard Cagley wrote:
> On Tue, Jun 18, 2013 at 12:22 AM, A C wrote:
>
>> You need -n (lower case N) to force gpsd to start collecting data
>> automatically. It normally waits for something to connect to its TCP port
>> and enable data collection (the WATCH command as you discovered). If you
>>
Rob wrote:
>> but gpsd seems to be active...
>
> What you posted here looks OK but is too short to diagnose the
> situation.
I stand corrected, the "no probe matched" is indeed a fatal error.
Try to fix that first.
There should be more logging then, and the next step is to check
if there is a fix
On Tue, Jun 18, 2013 at 9:30 AM, Rob wrote:
> I stand corrected, the "no probe matched" is indeed a fatal error.
> Try to fix that first.
> There should be more logging then, and the next step is to check
> if there is a fix to the satellites.
>
adding the -b flag to gpsd seemed to do the trick.
Richard Cagley wrote:
> On Tue, Jun 18, 2013 at 9:30 AM, Rob wrote:
>
>> I stand corrected, the "no probe matched" is indeed a fatal error.
>> Try to fix that first.
>> There should be more logging then, and the next step is to check
>> if there is a fix to the satellites.
>>
>
> adding the -b fl
On Tue, Jun 18, 2013 at 9:27 AM, Rob wrote:
> As I wrote before, your ntp config is not correct. please copy it
> from the docs. However, that is not the cause of the problem.
> (it would be the cause of severe inaccuracy once you obtain NMEA data
> as you are not using PPS)
>
yeah, figured I'
On Tue, Jun 18, 2013 at 10:16 AM, Rob wrote:
> It now locks to the serial data but not yet to the PPS.
> What happens when you add some external timeserver(s)?
> Are you within a fraction of a second from those?
>
after about 5min...
/ # ntpq -p
remote refid st t when poll re
On 6/18/2013 10:39, Richard Cagley wrote:
On Tue, Jun 18, 2013 at 9:27 AM, Rob wrote:
As I wrote before, your ntp config is not correct. please copy it
from the docs. However, that is not the cause of the problem.
(it would be the cause of severe inaccuracy once you obtain NMEA data
as you a
On Tue, Jun 18, 2013 at 11:06 AM, A C wrote:
> Your "Probe not found" messages are fine since those are for specific
> probes and it's obviously decoding data now using the generic NMEA. The
> fatal error is the other one you had before ("no probe found") which is
> what happens when gpsd gives
On Tue, Jun 18, 2013 at 11:06 AM, A C wrote:
> I suspect you may have a conflict between the kernel attempting to control
> PPS and gpsd attempting to use it. Try adding "disable kernel" to the
> ntp.conf to shut off the kernel's use of PPS and see if that wakes up gpsd.
> If so, your serial dr
Richard Cagley wrote:
> On Tue, Jun 18, 2013 at 10:16 AM, Rob wrote:
>
>> It now locks to the serial data but not yet to the PPS.
>> What happens when you add some external timeserver(s)?
>> Are you within a fraction of a second from those?
>>
>
> after about 5min...
> / # ntpq -p
> remote
Richard Cagley wrote:
> On Tue, Jun 18, 2013 at 9:27 AM, Rob wrote:
>
>> As I wrote before, your ntp config is not correct. please copy it
>> from the docs. However, that is not the cause of the problem.
>> (it would be the cause of severe inaccuracy once you obtain NMEA data
>> as you are not
On 18/06/2013 18:54, Richard Cagley wrote:
[]
after about 5min...
/ # ntpq -p
remote refid st t when poll reach delay offset
jitter
==
*SHM(0) .GPS.0 l4 16 3770.0
On 18/06/2013 19:48, David Taylor wrote:
[]
Progress!
Now you can take the average of the offset values, say -171
(milliseconds) in round numbers, and change the ntp.conf to read:
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.171 refid GPSD
This will make the serial
You also need to wait a bit longer before giving up, especially when
you have been frantically changing things and restarting the different
daemons (but not the entire system).
ntpd does not like that.
> Yeah, I agree. This definitely seems like the problem. I have pps support
> built into the ke
On Tue, Jun 18, 2013 at 11:56 AM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
> If you have PPS support in the kernel you need a type 22 driver as well as
> the type 28.0 driver. Type 28.1 assumes you have some software poking
> timestamps into the second shared memory segment pr
On Tue, Jun 18, 2013 at 11:28 AM, Rob wrote:
> Well, gpsd does not use kernel pps. It puts the pps time into the
> second SHM segment and lets ntpd pick it up there. This was coded
> in the days that Linux kernels often came without pps support and
> additional patches would have to be applied.
On Tue, Jun 18, 2013 at 11:48 AM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
> How are you feeding the PPS data into the system?
DCD pin on /dev/ttyO0
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/qu
On Tue, Jun 18, 2013 at 12:06 PM, Rob wrote:
> You also need to wait a bit longer before giving up, especially when
> you have been frantically changing things and restarting the different
> daemons (but not the entire system).
>
> ntpd does not like that.
>
> I think with kernel pps you somewher
Richard Cagley wrote:
> Does "removing a definition" refer to removing one of the timeservers from
> the ntp.conf file? Presently, I don't have pps support built into my kernel.
I'm sorry, but I am not familiar with it.
I use gpsd+ntpd on a system without pps support.
I think it can be done in t
On Tue, Jun 18, 2013 at 4:46 PM, Rob wrote:
>
> (it seems there is some limited function in one of the ntpd GPS drivers
> to save the position info somewhere where it can be accessed by other
> programs)
Fudge flag4=0 should put location data in clockstats:
http://www.eecis.udel.edu/~mills/ntp/
On 18/06/2013 20:28, Richard Cagley wrote:
[]
I'm having a hard time understanding this. Let's consider two cases:
1.) I have pps support built into my kernel:
In addition to the 127.127.28.0 to grab nmea time data You suggest using
the pps line driver instead of 127.127.28.1? You're saying that
27 matches
Mail list logo
