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 pin
On Wed, 31 Dec 2008 12:42:18 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk 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.
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
George R. Kasica geor...@netwrx1.com writes:
On Wed, 31 Dec 2008 17:57:25 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com writes:
On Wed, 31 Dec 2008 00:20:45 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk wrote:
Unruh 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. Here's my conf with the modified gpsd:
#Garmin GPS 18x LVC 0
On Jan 1, 12:38 pm, Evandro Menezes evan...@mailinator.com 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 Jan 1, 12:38 pm, Evandro Menezes evan...@mailinator.com 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
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 NMEA
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
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
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
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 to
David J Taylor wrote:
Steve Kostecke wrote:
On 2008-12-31, David J Taylor david-tay...@blueyonder.co.uk 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
George R. Kasica geor...@netwrx1.com writes:
On Wed, 31 Dec 2008 00:20:45 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk 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
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
On Tue, 30 Dec 2008 00:53:00 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com writes:
On Mon, 29 Dec 2008 12:30:39 +, David Woolley
da...@ex.djwhome.demon.co.uk.invalid wrote:
George R. Kasica wrote:
still seing both of the local GPS/PPS entries as false
On Mon, 29 Dec 2008 23:47:56 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com 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
On Tue, 30 Dec 2008 07:25:55 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk 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:
On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
geor...@netwrx1.com wrote:
On Tue, 30 Dec 2008 07:25:55 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk wrote:
David J Taylor wrote:
Richard B. Gilbert wrote:
[]
I think your best help/advice will come from
On Tue, 30 Dec 2008 09:59:50 -0600, George R. Kasica
geor...@netwrx1.com wrote:
On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
geor...@netwrx1.com wrote:
On Tue, 30 Dec 2008 07:25:55 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk wrote:
David J Taylor
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
On Tue, 30 Dec 2008 16:25:52 +, David Woolley
da...@ex.djwhome.demon.co.uk.invalid 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
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 converter,
George R. Kasica geor...@netwrx1.com writes:
On Tue, 30 Dec 2008 09:59:50 -0600, George R. Kasica
geor...@netwrx1.com wrote:
On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
geor...@netwrx1.com wrote:
On Tue, 30 Dec 2008 07:25:55 GMT, David J Taylor
David J Taylor david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk
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
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
George R. Kasica geor...@netwrx1.com writes:
On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
geor...@netwrx1.com wrote:
On Tue, 30 Dec 2008 07:25:55 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk wrote:
David J Taylor wrote:
Richard B. Gilbert wrote:
[]
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
that? What reads
On Tue, 30 Dec 2008 17:14:52 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk writes:
Richard B. Gilbert wrote:
[]
I think your best help/advice will come from another GPS18LVC user.
I described my own simple setup here:
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 used
David J Taylor david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk
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
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
Steve Kostecke wrote:
On 2008-12-30, Unruh unruh-s...@physics.ubc.ca wrote:
David J Taylor david-tay...@blueyonder.co.uk 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
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't see why
On Tue, 30 Dec 2008 21:40:27 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com 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
On 2008-12-31, David J Taylor david-tay...@blueyonder.co.uk 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
George R. Kasica geor...@netwrx1.com writes:
On Tue, 30 Dec 2008 21:40:27 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com 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
Steve Kostecke wrote:
On 2008-12-31, David J Taylor david-tay...@blueyonder.co.uk 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
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 1415Z
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 to be
On 2008-12-28, Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net 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
George R. Kasica geor...@netwrx1.com 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
On Mon, 29 Dec 2008 12:30:39 +, David Woolley
da...@ex.djwhome.demon.co.uk.invalid 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
On Mon, 29 Dec 2008 09:45:51 -0500, Richard B. Gilbert
rgilber...@comcast.net 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
George R. Kasica wrote:
On Mon, 29 Dec 2008 09:45:51 -0500, Richard B. Gilbert
rgilber...@comcast.net 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
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 4
George R. Kasica wrote:
On Mon, 29 Dec 2008 12:30:39 +, David Woolley
da...@ex.djwhome.demon.co.uk.invalid 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
George R. Kasica geor...@netwrx1.com writes:
On Mon, 29 Dec 2008 12:30:39 +, David Woolley
da...@ex.djwhome.demon.co.uk.invalid 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
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.
That
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 is
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. It seems
Hi there
George R. Kasica wrote:
Cut
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
On Sun, 28 Dec 2008 12:53:47 +0100, Rob van der Putten r...@sput.nl
wrote:
Hi there
George R. Kasica wrote:
Cut
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
On Sat, 27 Dec 2008 23:53:49 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com 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
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
George R. Kasica wrote:
On Sat, 27 Dec 2008 23:53:49 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com 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
On Sun, 28 Dec 2008 09:45:18 -0500, Richard B. Gilbert
rgilber...@comcast.net wrote:
George R. Kasica wrote:
On Sat, 27 Dec 2008 23:53:49 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
George R. Kasica geor...@netwrx1.com writes:
sym links from
/dev/gps0 - /dev/ttyS0
/dev/pps0 - /dev/ttyS0
Richard B. Gilbert rgilber...@comcast.net writes:
George R. Kasica wrote:
On Sat, 27 Dec 2008 23:53:49 GMT, Unruh unruh-s...@physics.ubc.ca
wrote:
...
# ntpq -p
remote refid st t when poll reach delay offset
jitter
George R. Kasica geor...@netwrx1.com writes:
George R. Kasica geor...@netwrx1.com 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
Maarten Wiltink maar...@kittensandcats.net writes:
George R. Kasica geor...@netwrx1.com 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
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 115200
spd_normal skip_test
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),
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 st...@ntp.org
George R. Kasica geor...@netwrx1.com 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 16550A port 0x03f8 irq 4
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?
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
George R. Kasica geor...@netwrx1.com 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
George R. Kasica geor...@netwrx1.com 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
69 matches
Mail list logo
