> Chris:
>
> Does indeed sound familiar to me here.
>
> I'm working also but with a slightly different fix.
>
> Not using PPS kernel patch as its difficult to add in to the RPM based
> kernels here on Fedora Core 9 so I'm just using the shm driver and
> plain old ntpd. My solution was to fudge the
On Jan 1, 12:38 pm, Evandro Menezes wrote:
> On Dec 31 2008, 8:49 pm, givemeafckingacctyoudou...@gmail.com wrote:
>
>
>
> > So, basically I'm manually adjusting the nmea second reading forward
> > by 1.
>
> > The SHM(0) gps is still fudged to account for normal lag w/ the time
> > given on qnan. H
On Jan 1, 12:38 pm, Evandro Menezes wrote:
> On Dec 31 2008, 8:49 pm, givemeafckingacctyoudou...@gmail.com wrote:
>
>
>
> > So, basically I'm manually adjusting the nmea second reading forward
> > by 1.
>
> > The SHM(0) gps is still fudged to account for normal lag w/ the time
> > given on qnan. H
On Dec 31 2008, 8:49 pm, givemeafckingacctyoudou...@gmail.com wrote:
>
> So, basically I'm manually adjusting the nmea second reading forward
> by 1.
>
> The SHM(0) gps is still fudged to account for normal lag w/ the time
> given on qnan. Here's my conf with the modified gpsd:
> #Garmin GPS 18x LV
George R. Kasica writes:
>On Wed, 31 Dec 2008 17:57:25 GMT, Unruh
>wrote:
>>George R. Kasica writes:
>>
>>>On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor"
>>> wrote:
>>
Unruh wrote:
> "David J Taylor"
[]
>> With just the reference clock type 20, I get the accuracy needed.
>>
George R. Kasica wrote:
[]
> What sort of weather info do you process? Here is map and forecast
> generation and storage, serving out over web, data collection locally,
> EMWIN data collection and retransmission, and a couple bigger web
> sites.
Essentially - anything which is sent out over the EU
On Wed, 31 Dec 2008 17:57:25 GMT, Unruh
wrote:
>George R. Kasica writes:
>
>>On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor"
>> wrote:
>
>>>Unruh wrote:
"David J Taylor"
>>>[]
> With just the reference clock type 20, I get the accuracy needed.
> The PPS line from the GBS-18 LVC i
On Wed, 31 Dec 2008 12:42:18 GMT, "David J Taylor"
wrote:
>George R. Kasica wrote:
>[]
>> I'd be happy to put it in here, but doing so with the Fedora Core 9
>> RPM based code is not something I'm familiar with.
>
>I understand that perfectly.
>
>> I'm used to working
>> with straight source code
On Wed, 31 Dec 2008 18:49:22 -0800 (PST),
givemeafckingacctyoudou...@gmail.com wrote:
>George, You're experiencing the exact same problem as I am. I'll
>probably make a more detailed thread in this group describing it
>later, but basically the programs trying to match the NMEA data with
>the PPS p
George, You're experiencing the exact same problem as I am. I'll
probably make a more detailed thread in this group describing it
later, but basically the programs trying to match the NMEA data with
the PPS pin are locking our GPS units in one second behind the actual
time.
I purchased my 18xLVC pr
George R. Kasica writes:
>On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor"
> wrote:
>>Unruh wrote:
>>> "David J Taylor"
>>[]
With just the reference clock type 20, I get the accuracy needed.
The PPS line from the GBS-18 LVC is wired to the DCD line of the
serial port. In my ign
David J Taylor wrote:
> Steve Kostecke wrote:
>> On 2008-12-31, David J Taylor wrote:
>>
>>> Steve Kostecke wrote:
>>>
The FreeBSD kernel does not need a "PPS patch". One merely has to
specify the PPS option at compile time.
>>>
>>> But the FreeBSD 5.3 I had did not include PPS, so that'
Hi there
David Woolley wrote:
> V.24 doesn't specify electrical characteristics. I suspect you mean
> V.28.
The standard was 'split' at some point (I haven't looked into this stuff
for years).
> RS232 C is also 25 volts, open circuit, although drivers for both
> standards are not required
Rob van der Putten wrote:
>
> In V24 it's -25 ... 25 V [1]. -3 ... 3 V isn't defined.
V.24 doesn't specify electrical characteristics. I suspect you mean
V.28. RS232 C is also 25 volts, open circuit, although drivers for both
standards are not required to be able to achieve this.
> [2] TTL
George R. Kasica wrote:
[]
> I'd be happy to put it in here, but doing so with the Fedora Core 9
> RPM based code is not something I'm familiar with.
I understand that perfectly.
> I'm used to working
> with straight source code for kernels ie make make install type steps
> (don't take those lite
Hi there
Unruh wrote:
> Yes, well... The RS232 standard says that teh signal levels are -12V and
> +12V and that the absolute minimum be -5V and +5V. However, many serial
> chip makers have bent those standards and the serial port may or may not
> respond to the 0,5 level that the PPS output act
On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor"
wrote:
>Unruh wrote:
>> "David J Taylor"
>[]
>>> With just the reference clock type 20, I get the accuracy needed.
>>> The PPS line from the GBS-18 LVC is wired to the DCD line of the
>>> serial port. In my ignorance, I don't see why you even ne
Steve Kostecke wrote:
> On 2008-12-31, David J Taylor wrote:
>
>> Steve Kostecke wrote:
>>
>>> The FreeBSD kernel does not need a "PPS patch". One merely has to
>>> specify the PPS option at compile time.
>>
>> But the FreeBSD 5.3 I had did not include PPS, so that's presumably
>> why I needed to
George R. Kasica writes:
>On Tue, 30 Dec 2008 21:40:27 GMT, Unruh
>wrote:
>>George R. Kasica writes:
>>
>>What am I doing wrong here when I add back GPS data to break this
>>thing???
>Next stepI added back GPS NEMA data without the gpsd daemon (I
>don't pass the d
On 2008-12-31, David J Taylor wrote:
> Steve Kostecke wrote:
>
>> The FreeBSD kernel does not need a "PPS patch". One merely has to
>> specify the PPS option at compile time.
>
> But the FreeBSD 5.3 I had did not include PPS, so that's presumably
> why I needed to (or was advised to) re-compile t
On Tue, 30 Dec 2008 21:40:27 GMT, Unruh
wrote:
>George R. Kasica writes:
>
>What am I doing wrong here when I add back GPS data to break this
>thing???
>>>
>>>
Next stepI added back GPS NEMA data without the gpsd daemon (I
don't pass the data out to anywhere so there's no rea
Unruh wrote:
> "David J Taylor"
[]
>> With just the reference clock type 20, I get the accuracy needed.
>> The PPS line from the GBS-18 LVC is wired to the DCD line of the
>> serial port. In my ignorance, I don't see why you even need the SHM
>> driver, but as I said before, I'm no expert! I don'
Steve Kostecke wrote:
> On 2008-12-30, Unruh wrote:
>
>> "David J Taylor" writes:
>>
>>> I'm no expert! I don't see why my system picks up the PPS from just
>>> the type 20 driver, and yours does not.
>>
>> Because you have the PPS kernel patch installed or it was
>> automatically instaled in BSD
On 2008-12-30, Unruh wrote:
> "David J Taylor" writes:
>
>>I'm no expert! I don't see why my system picks up the PPS from just
>>the type 20 driver, and yours does not.
>
> Because you have the PPS kernel patch installed or it was
> automatically instaled in BSD? The OP does not and does not wan
Unruh wrote:
> Yes, well... The RS232 standard says that teh signal levels are -12V and
> +12V and that the absolute minimum be -5V and +5V. However, many serial
These are requirements on drivers, not on receivers.
> chip makers have bent those standards and the serial port may or may not
There
George R. Kasica writes:
What am I doing wrong here when I add back GPS data to break this
thing???
>>
>>
>>>Next stepI added back GPS NEMA data without the gpsd daemon (I
>>>don't pass the data out to anywhere so there's no real need for it)
>>
>>What does "I added back GPS NMEA" mea
George R. Kasica writes:
>On Tue, 30 Dec 2008 17:14:52 GMT, Unruh
>wrote:
>>"David J Taylor"
>> writes:
>>
>>>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
"David J Taylor"
writes:
>George R. Kasica wrote:
>[]
>> Next stepI added back GPS NEMA data without the gpsd daemon (I
>> don't pass the data out to anywhere so there's no real need for it)
>>
>> and I see
>>
>> # ntpq -p
>> remote refid st t when poll reach delay off
George R. Kasica wrote:
[]
> Do you have the PPS kernel hack compiled in? That may be doing it for
> you. I can't easily add that here with the Fedora Core 9 RPM kernel I
> have. What are you using in your ntp.conf settings for the clock setup
> lines and fudge?
>
> George
Yes, I'm using FreeBSD,
George R. Kasica wrote:
[]
>> And it does not report on the resulting time until the sentences
>> finish. Having just the one standard sentence would reduce that time.
> How would I get that to occur? I don't see a way to cut down on the
> data sent by the unit
Here's a snippet of the code I
On Tue, 30 Dec 2008 17:24:36 GMT, "David J Taylor"
wrote:
>George R. Kasica wrote:
>[]
>> Next stepI added back GPS NEMA data without the gpsd daemon (I
>> don't pass the data out to anywhere so there's no real need for it)
>>
>> and I see
>>
>> # ntpq -p
>> remote refid st
On Tue, 30 Dec 2008 17:14:52 GMT, Unruh
wrote:
>"David J Taylor"
> writes:
>
>>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 L
>>>What am I doing wrong here when I add back GPS data to break this
>>>thing???
>
>
>>Next stepI added back GPS NEMA data without the gpsd daemon (I
>>don't pass the data out to anywhere so there's no real need for it)
>
>What does "I added back GPS NMEA" mean? What program did you use to do
>
George R. Kasica writes:
>On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
> wrote:
>>On Tue, 30 Dec 2008 07:25:55 GMT, "David J Taylor"
>> wrote:
>>
>>>David J Taylor wrote:
Richard B. Gilbert wrote:
[]
> I think your best help/advice will come from another GPS18LVC user.
George R. Kasica wrote:
[]
> Next stepI added back GPS NEMA data without the gpsd daemon (I
> don't pass the data out to anywhere so there's no real need for it)
>
> and I see
>
> # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==
"David J Taylor"
writes:
>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".
>I
George R. Kasica writes:
>On Tue, 30 Dec 2008 09:59:50 -0600, George R. Kasica
> wrote:
>>On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
>> wrote:
>>
>>>On Tue, 30 Dec 2008 07:25:55 GMT, "David J Taylor"
>>> wrote:
>>>
David J Taylor wrote:
> Richard B. Gilbert wrote:
> []
Unruh wrote:
[]
> The other problem is that the the voltage levels might be wrong. A
> serial
> port is supposed to be -12V to 12V, not the 0-5V that the PPS line on
> the garmin delivers. Now some serial ports are OK with the 0-5V but
> that is pretty
> unusual. YOu either need a voltage convert
On Tue, 30 Dec 2008 16:25:52 +, David Woolley
wrote:
>George R. Kasica wrote:
>
>> I have good PPS and am getting GPS NEMA in as well but the offset for
>> the NEMA data seems quite largewhat would I do to fix that??
>
>Nothing. It's normal.
>
>NMEA feeds from GPS receivers have rather l
George R. Kasica wrote:
> I have good PPS and am getting GPS NEMA in as well but the offset for
> the NEMA data seems quite largewhat would I do to fix that??
Nothing. It's normal.
NMEA feeds from GPS receivers have rather low priority for timing data
and can easily err by this sort of amo
On Tue, 30 Dec 2008 09:59:50 -0600, George R. Kasica
wrote:
>On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
> wrote:
>
>>On Tue, 30 Dec 2008 07:25:55 GMT, "David J Taylor"
>> wrote:
>>
>>>David J Taylor wrote:
Richard B. Gilbert wrote:
[]
> I think your best help/advice will c
On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
wrote:
>On Tue, 30 Dec 2008 07:25:55 GMT, "David J Taylor"
> wrote:
>
>>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
On Tue, 30 Dec 2008 07:25:55 GMT, "David J Taylor"
wrote:
>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
On Mon, 29 Dec 2008 23:47:56 GMT, Unruh
wrote:
>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
On Tue, 30 Dec 2008 00:53:00 GMT, Unruh
wrote:
>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
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".
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
>>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
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??
>>
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
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 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
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
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
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 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
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
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.
_
>>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
"Richard B. Gilbert" writes:
>George R. Kasica wrote:
>> On Sat, 27 Dec 2008 23:53:49 GMT, Unruh
>> wrote:
>>
...
>> # ntpq -p
>> remote refid st t when poll reach delay offset
>> jitter
>> ==
>>
On Sun, 28 Dec 2008 09:45:18 -0500, "Richard B. Gilbert"
wrote:
>George R. Kasica wrote:
>> On Sat, 27 Dec 2008 23:53:49 GMT, Unruh
>> wrote:
>>
>>> George R. Kasica writes:
>>>
sym links from
/dev/gps0 -> /dev/ttyS0
/dev/pps0 -> /dev/ttyS0
running the gpsd
George R. Kasica wrote:
> On Sat, 27 Dec 2008 23:53:49 GMT, Unruh
> wrote:
>
>> George R. Kasica writes:
>>
>>> sym links from
>>> /dev/gps0 -> /dev/ttyS0
>>> /dev/pps0 -> /dev/ttyS0
>>> running the gpsd and the 18LVC off ttyS0 at 4800 baud settings on
>>> 18LVC done as per q
Hi there
George R. Kasica wrote:
> Did you need to use two physical serial plugs or a splitter or just do
> this with symlinks in the OS?
Two plugs.
Regards,
Rob
--
Anglo-Saxon management is a memetic virus
___
questions mailing list
questions@lis
On Sat, 27 Dec 2008 23:53:49 GMT, Unruh
wrote:
>George R. Kasica writes:
>
>>sym links from
>
>>/dev/gps0 -> /dev/ttyS0
>>/dev/pps0 -> /dev/ttyS0
>
>>running the gpsd and the 18LVC off ttyS0 at 4800 baud settings on
>>18LVC done as per quan web page docs to set NEMA a
On Sun, 28 Dec 2008 12:53:47 +0100, Rob van der Putten
wrote:
>Hi there
>
>
>George R. Kasica wrote:
>
>
>
>> If I switch to the following settings I can seem to get NEMA data but
>> then I lose the PPS function which hurts the accuracy far more. Do you
>> know if shm can somehow allow both with
Hi there
George R. Kasica wrote:
> If I switch to the following settings I can seem to get NEMA data but
> then I lose the PPS function which hurts the accuracy far more. Do you
> know if shm can somehow allow both with some type of setting - ideally
> that is what I'm trying to accomplish thr
>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 reach bit mask good enough
for that?
Actual
On 2008-12-27, Harlan Stenn wrote:
> Another problem with PPS signals is that some devices will emit a PPS signal
> even if the (GPS) device is not sync'd.
Another problem with PPS, specifically in the ATOM drivers is that the
driver provides no information about whether or not it is using the P
George R. Kasica writes:
>sym links from
>/dev/gps0 -> /dev/ttyS0
>/dev/pps0 -> /dev/ttyS0
>running the gpsd and the 18LVC off ttyS0 at 4800 baud settings on
>18LVC done as per quan web page docs to set NEMA and PPS auto Off etc.
>setserial /dev/ttyS0 uart 1
Another problem with PPS signals is that some devices will emit a PPS signal
even if the (GPS) device is not sync'd.
See https://support.ntp.org/bugs/show_bug.cgi?id=557 for more discussion,
including a link to http://support.ntp.org/Dev/LoseThePerDriverPPSCode .
--
Harlan Stenn
http://ntpforum.
I still recommend:
http://support.ntp.org/bin/view/Support/ConfiguringGarminRefclocks
http://support.ntp.org/bin/view/Support/GarminRefclockUsers
and if you want to add a column to the table in the GarminRefclockUsers page
where folks can add their expected offset and jittter (or whatever), pl
sym links from
>>>
/dev/gps0 -> /dev/ttyS0
/dev/pps0 -> /dev/ttyS0
>>>
running the gpsd and the 18LVC off ttyS0 at 4800 baud settings on
18LVC done as per quan web page docs to set NEMA and PPS auto Off etc.
>>>
setserial /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 1
"Maarten Wiltink" writes:
>"George R. Kasica" wrote in message
>news:refbl4deg778k7rtgdnqcbjhajpuf32...@4ax.com...
>[...]
3) I'd like to share the GPS/PPS signals via gpsd with another Linux
system if possible would that be usable or accurate enough or should
I just synch off this
George R. Kasica writes:
>>George R. Kasica writes:
>>
>>>I have one of these units running here under Red Hat Fedora Core 9 as
>>>follows based on a collection of a number of the on-line docs I've
>>>looked at. What I'd like to know is as follows:
>>
>>>1) Is this working well or poorly?
>Again
"George R. Kasica" wrote in message
news:refbl4deg778k7rtgdnqcbjhajpuf32...@4ax.com...
[...]
>>> 3) I'd like to share the GPS/PPS signals via gpsd with another Linux
>>> system if possible would that be usable or accurate enough or should
>>> I just synch off this one at stratum 2?
>> The gps/pps
>George R. Kasica writes:
>
>>I have one of these units running here under Red Hat Fedora Core 9 as
>>follows based on a collection of a number of the on-line docs I've
>>looked at. What I'd like to know is as follows:
>
>>1) Is this working well or poorly?
Again, having no base of experience here
George R. Kasica writes:
>I have one of these units running here under Red Hat Fedora Core 9 as
>follows based on a collection of a number of the on-line docs I've
>looked at. What I'd like to know is as follows:
>1) Is this working well or poorly?
>2) Is there any way I can use both the GPS ti
I have one of these units running here under Red Hat Fedora Core 9 as
follows based on a collection of a number of the on-line docs I've
looked at. What I'd like to know is as follows:
1) Is this working well or poorly?
2) Is there any way I can use both the GPS time data AND the PPS
signal witho
78 matches
Mail list logo
