Re: [questions] RRG

[George R. Kasica]

I’m not David Hart but somehow got this below. Hope he gets it straightened out.

—
===[George Kasica]===

Sent with Spark
On May 26, 2023 at 12:42 -0500, Greystar , wrote:


Hi,



Thanks for reaching out about your proof of insurance. It looks like we weren’t 
able to accept the document
because it was too blurry, or we couldn’t access the attachment.

Please resend a clear, crisp insurance document so we can confirm that you’ve 
met your lease insurance requirement.
Make sure that the document is not password-protected so we can open it on our 
end.

You can send us a copy of your policy by submitting it to 
https://resident.assurant.com/poi using the Resident and
Client ID listed in the email subject line. If your carrier is green, they can 
use the email address we are writing you
from to send it to us directly.

You can also give us a call using the toll-free number below, Monday through 
Friday, 8 a.m-8 p.m. EST.

Assurant Insurance Service Center
On behalf of Greystar
Phone 1.800.249.1104
Email greys...@assurant.com

Need a faster response? Chat with us 8AM – 5PM Monday – Friday at 
https://resident.assurant.com/poi/confirmation.
You will need the three letter Client ID and resident ID listed in the subject 
line above.

You can also self-service your Assurant policy by visiting 
www.MyAssurantPolicy.com.
--- Original Message ---
From: David Hart ;
Received: Wed May 24 2023 14:22:16 GMT-0400 (Eastern Daylight Time)
To: questions@lists.ntp.org;
Subject: Re: [questions] Fwd: Windows port pool IPv6 misbehavior



On Wed, 24 May 2023 at 02:01, Jakob Bohm  wrote:
For more rapid testing, could you describe the particular failing
getaddrinfo() behavior and perhaps provide a sample command line C
program that tests it in isolation instead of forcing each tester to
run through a long ntpd run (usually hours of test time plus difficult
log interpretation versus a quick run that outputs relevant results to
stdout even with a different NTP daemon running).

Actually it doesn't take hours, just seconds.  You just need to see if using 
only 
"pool2.pool.ntp.org"
 you see only IPv4 pool servers or both IPv4 and IPv6 servers in the "ntpq -p" 
billboard right after starting ntpd on a Windows system with a global IPv6 
address.  Nonetheless, a standalone test program is easier to set up and 
doesn't require messing with your existing ntpd, so I wrote one.

getaddrinfo-test optionally takes a hostname and service to look up, defaulting 
to2.pool.ntp.org
 and ntp.  You can download the source and a ready-to-run 32-bit .exe from:

https://people.nwtime.org/hart/getaddrinfo-test.zip

Here's what the output looks like on my Windows 11 22H2 system without IPv6 
connectivity:

Using hostname 
2.pool.ntp.org.
 service ntp
AF_UNSPEC:
128.82.68.1
216.84.68.1
240.84.68.1
160.83.68.1
AF_INET:
56.82.68.1
48.84.68.1
80.82.68.1
104.82.68.1
AF_INET6:
getaddrinfo error: The requested name is valid, but no data of the requested 
type was found.

I'd appreciate testing on systems with both IPv4 and IPv6 internet access with 
as many different versions of Windows as possible.  You'll reproduce what I saw 
if there are IPv6 addresses under AF_INET6 but not under AF_UNSPEC.

Incidentally, you can help me convince Microsoft this should be investigated by 
upvoting the Feedback Hub issue I opened.  I presume this link will work only 
from a Windows 10 or 11 machine:

https://aka.ms/AAkyamq

Re: [ntp:questions] Question on server 127.x.y.z numbers

[George R. Kasica]

Thank you very much!

—
===[George Kasica]===
Owner
Netwrx Consulting
Jackson, WI
e. gkas...@netwrx1.com
On Jun 14, 2021, 09:03 -0500, Martin Burnicki , 
wrote:
George R. Kasica wrote:
I’ve used NTP as a time server since at least 2013 when I set up 3
raspberry pis with go’s antennas - actually Anthony Stirk at Nevis
Corp. Built them and configured them since I had a severe auto crash
and the resulting concussion limited how long I could stare at a
screen - anyway my question is what are the meanings and acceptable
values for the server 127.x.y.z and the various commands. I’ve looked
all over NTP docs and searches and I’m unable to find any good info.
A pointer to the info is fine or a description of what can go there.
The pseudo IP addresses 127.127.y.z are used by ntpd to configure a
hardware reference clock. There are quite a few drivers numbered from 0
to n, and the driver number is used for "y".

Each driver may support several clocks with different protocols, and "z"
refers to an instance number (usually 0..3) to distinguish between
several hardware devices that use the same driver type.

For example, 127.127.8.z refers to the generic parse driver which
supports a couple of different hardware devices, and is described here:
http://doc.ntp.org/current-stable/drivers/driver8.html

Note the number "8" in the page URL refers to the "8" in 127.127.8.z.

An overview can be found here:
http://doc.ntp.org/current-stable/drivers/

Martin

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Question on server 127.x.y.z numbers

[George R. Kasica]

I’ve used NTP as a time server since at least 2013 when I set up 3 raspberry 
pis with go’s antennas - actually Anthony Stirk at Nevis Corp. Built them and 
configured them since I had a severe auto crash and the resulting concussion 
limited how long I could stare at a screen - anyway my question is what are the 
meanings and acceptable values for the server
127.x.y.z and the various commands. I’ve looked all over NTP docs and searches 
and I’m unable to find any good info. A pointer to the info is fine or a 
description of what can go there.

Thank you in advance,
George Kasica

—
===[George Kasica]===
Owner
Netwrx Consulting
Jackson, WI
e. gkas...@netwrx1.com
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Trying to locate a copy of this for PPS on Windows GPS Setup

[George R. Kasica]

I can't seem to locate a copy of this file. Does anyone know where I can locate 
it? The links on the setup page are broken or hacked to malware sites. :

http://blogs.cae.tntech.edu/jwlangston21/tag/time/

serialpps-20090606.zip


George R. Kasica
Jackson, WI USA
gkas...@netwrx1.com
http://www.netwrx1.com<http://www.netwrx1.com/>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Garmin GPS 18x LVC no soldering required

[George R . Kasica]

On Fri, 23 Jan 2009 16:31:08 -0800 (PST), Dave Hart
daveh...@gmail.com wrote:

I came across a guy selling GPS 18x LVC with a DB-9 cable soldered on
by him for use with some data collection device I know nothing about
[1].  He's connected the power as well as the serial data lines to the
DB-9, which is not what we want for refclock use.

I dropped him an email asking if he'd be willing to wire one up with
both USB for power and DB-9 to connect to a PC for NTP use.
Apparently I wasn't the first to ask, as he responded he's been doing
those for $100 plus shipping (and sales tax in California).

Now I'm sure some will laugh, but this appeals to me despite the 50%
premium over the basic cost of the unit.  First off, you need to
include the cost of the USB cable and DB-9 connector, then give
yourself some budget for your time.  I've done my share of soldering
over the years and I suck at it, it takes me far too long.  I don't
trust the hideous-looking results.  Put it all together and I'm happy
to pay an expert to do it right.

[1] http://psn.quake.net/gps/gps18.html

Cheers,
Dave Hart
Dave:

This is where I got mine from a couple months back. Came made
correctly and well done and plug in ready to go. I'd highly recommend
him, he does high quality work and sells good product. As someone who
can't do that type of work and is also a consultant (ie time and my
skills are what I sell basically) I have no problem paying someone for
theirs.

-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] ntp in VM cannot synchronize

[George R . Kasica]

On 01 Jan 2009 17:26:02 GMT, Steve Kostecke koste...@ntp.org wrote:

On 2009-01-01, George R  Kasica geor...@netwrx1.com wrote:

 WE run over 150 VMs under unix/linux where I work and about 20 ESX
 servers (its actually my day job) so I might be able to help you.

[snip: ESX configuration example]

I've added this to http://support.ntp.org/bin/view/Support/VMWareNTP

Steve:

Thanks alot for adding that but leave the DISABLE step out at the
endYou want it ON. I just gave him both options so that he could
see that it really made a difference. You can run it TWICE and the
second time should produce an error in either case which prove its
really in the correct state.
-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] My extra second ...

[George R . Kasica]

On Fri, 2 Jan 2009 01:07:35 -0800 (PST), francesco.messi...@gmail.com
wrote:

On 2 Gen, 06:47, Steve Kostecke koste...@ntp.org wrote:
 On 2009-01-01, Laws, Peter C. pl...@ou.edu wrote:

  I enjoyed my extra second, how about you?

 All my Linux systems had a fine time. None of them locked up / crashed /
 rebooted / etc.

Same here,
in the server farm I work for there're about one hundred linux server
of all flavours and vintage, all running ntp. None of them has been
reported down by our monitoring software.

No problems here:

OLD Calders Linux with 2.6.23.12 and ntp ntp-4.2.4p5 was find

Fedora Core 9 running 2.6.27.7-53.fc9.i686 and ntp-4.2.4p5-2.fc9.i386
was fine

about 150 VMware guests running Red Hat ES4U5 with ntp-4.2.4p5 are
also just fine

Also about 30 Solaris 9 boxes with ntp-4.2.4p5 are also working well 

in other words no problems here with anything that I'm responsible
for.

-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] My extra second ...

[George R . Kasica]

On Fri, 02 Jan 2009 14:31:34 +0100, Rob van der Putten r...@sput.nl
wrote:

Hi there


Steve Kostecke wrote:

 All my Linux systems had a fine time. None of them locked up / crashed /
 rebooted / etc.
 
 The kernels involved included: 
 
 2.6.24-etchnhalf.1-amd64
 2.6.18-5-486
 2.6.16-2-486
 2.6.18-5-k7
 2.6.18-4-powerpc
 2.4.16-k7

What about the hardware (Intel /AMD)?

Rob:

Everything in my post above was Intel based, no AMD or otherwise.

George

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 are locking our GPS units in one second behind the actual
time.
I purchased my 18xLVC pretty recently, did you as well?

I've patched my kernel with LinuxPPS and used gpsd, and both had about
-600ms offset in ntpd. gpsd would not function correctly when the time
was fudged as others are suggesting, it would instead give the error
not in locking range:600123. This was especially frustrating because
the local time servers proved I was right on the money. After a lot of
fiddling, I figured out that the PPS correctly aligned in gpsd when I
set it 1000ms behind the remote timeservers.

My fix, although this is in no way a viable long-term solution, was to
open ntpshm.c and add this fix:

(void)gettimeofday(tv,NULL);
microseconds = 100.0 * modf(fixtime,seconds);

//Added this to fix the off by 1 second bug with my garmin gps
seconds++;

shmTime-count++;
shmTime-clockTimeStampSec = (time_t)seconds;
shmTime-clockTimeStampUSec = (int)microseconds;

So, basically I'm manually adjusting the nmea second reading forward
by 1.  I recompiled, and am now running purely GPSD with pps pin
support (no shmpps driver needed) with the following values:
 remote   refid  st t when poll reach   delay
offset  jitter
==
 SHM(0)  .GPSa.   0 l4   16  3770.000
-19.092  36.507
*SHM(1)  .PPSa.   0 l6   16  3770.000
-0.053   0.004
+csnserver.com   216.110.36.245   6 u   63   64  377   90.410
27.036   9.775
+ntp-s1.cise.ufl .GPS.1 u   64   64  377   67.281
0.203   4.258

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
server 127.127.28.0 minpoll 4 noselect  #Local GPS serial
fudge 127.127.28.0 time1 -0.420 refid GPSa
#PPS pin
server 127.127.28.1 minpoll 4 prefer
fudge 127.127.28.1 refid PPSa

I'm going to probably post the gpsd list too, since it appears they've
had arguments before on the difficulties of syncing every units nmea
data to the pps pin. The nmea data offsets apparently vary widely
between models.

Hopefully we can find a solution to this together, since it appears
like we're in the same boat.
Chris
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 data time about 700
ms here and now I'm also working with just ntpd and the shm driver
running and no gpsd. Running gpsd at all totally messes this thing up.
I don't have the time or energy to keep hacking at why, or the need to
be running gpsd actually it turns out-nothing else needs the data so
why run it-just another daemon to need to make sure its running.

Relevant ntp.conf beloe and output:

# LinuxPPS: GPS 
server 127.127.20.0 minpoll 4 mode 1 
fudge 127.127.20.0 time1 0.700 flag2 0 flag3 1 
 
# SHM: PPS filtered mean 
server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag2 0 flag3 1 

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
+GPS_NMEA(0) .GPS.0 l5   16  3770.000   25.349
9.221
*SHM(0)  .PPS.0 l   14   16  3770.0002.953
0.176
 eagle-local 192.168.1.7  2 u  731 1024  3770.160   -2.518
0.152
 apollo-local.STEP.  16 u  725 1024  3760.236   -8.591
0.809
-clock.trit.net  164.67.62.1942 u   40  128  377  154.590   44.455
215.345
+64.247.17.255   129.6.15.28  2 u4  128  377   45.530  -13.520
252.661
-kiri.nonexiste. 69.10.36.2   3 u   11  128  3779.470  -12.775
1.132

-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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.

 I'm used to working
 with straight source code for kernels ie make make install type steps
 (don't take those literally please I know the steps) or just leaving
 the RPMs alone. I just am not sure how or if the PPS patches I've seen
 will apply to the kernel version here on the FC9 box or how it will
 affect the system-obviously breaking it is not an option - well, it
 always is but not a good one since it archives a ton of weather data
 :).

I do all my weather stuff under Windows - I have four systems here 
receiving and processing between 20GB and 40GB a day each.

  http://www.satsignal.eu/mrtg/performance_dvb.php

I hope someone can help with your Linux issue.
Cool :)

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.

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] My extra second ...

[George R . Kasica]

On Thu, 01 Jan 2009 07:43:13 GMT, David J Taylor
david-tay...@blueyonder.neither-this-part.nor-this-bit.co.uk wrote:

Laws, Peter C. wrote:
 I enjoyed my extra second, how about you?

 I was amused that WWV announced that it was *going to* happen in the
 4th minute ... after the insertion.  :-)

Well, thankfully it was a complete non-event here:

  http://www.satsignal.eu/ntp/ntp-events.htm#2008-12-31

My thanks to those who wrote the GPS  PPS code, made the Windows 
leap-second code, and made the Windows port available.  It all went 
without a hitch.

I see from another list that even Apple.com had a server which missed the 
leap-second

Thanks, and a Very Happy New Year!
Maybe thats' what started killing the Microsloth Zunes earlier in the
day ?? LOL (Just kidding - very glad I don't work for MS right now)
-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] ntp in VM cannot synchronize

[George R . Kasica]

On Wed, 31 Dec 2008 21:21:33 +, David Woolley
da...@ex.djwhome.demon.co.uk.invalid wrote:

TopCut GmbH / Ludwig Öfele wrote:
 Hello everybody!
 
 I am using a debian (testing) linux on a virtual machine of VMWare (in a
 linux host).
 I found, that the time in the VM was awfully wrong and hoped to fix this
 with ntp.

No.  Assuming VMWare, you fix the host machine with NTP, then use VMWare 
tools, with the right options, to control the time on the guest.  Note 
that, even then, there will be a large amount of jitter in the software 
clock time on the guest, as time is virtualised.

WE run over 150 VMs under unix/linux where I work and about 20 ESX
servers (its actually my day job) so I might be able to help you.

1) Turn off ntpd on the VM TURN OFF NTPD. You don't want it running.
But make sure the ntp.conf is valid you will need it.

2) Make sure ntpd is working on the ESX Server itself.

3) put a short shell script in /etc/cron.hourly called say timefix
with the following in it and make it chmod 755 owned by root:

ntpd -q

That's it.

Then make sure vmware tools is installed and timesynch = true is On
the VM guest there's a command you can run to do this so no hacking of
configs needed: (You want to turn it ON so the first option)

GNU/Linux:
turn it on...
vmware-guestd --cmd vmx.set_option synctime 0 1

...and turn it back off:
vmware-guestd --cmd vmx.set_option synctime 1 0 


WE do this process here under 3.0.3 latest patches and are seeing sync
routinely  0.05 seconds on amost if not all boxes.

YEll if you need more help in email.

George

-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 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.
So how in the world do I fix this? 

Prior to having both NEMA and PPS running at the same time all was
working well with just PPS and the shm driver.

What are you using to drive the shm refclock? 
Of course you can continue to use just pps-- obvioulsy something has gotten
messed up.

I'm sorry I don't know how to answer that more than  to say the shm
program mentioned in the various docs on line and then the GPS itself
on ttyS0

Here is the script run to set that up and the ntp.conf files with
flags. What changes would I need to make - I'm getting pretty lost
here.:

ntp.conf

# LinuxPPS: GPS
server 127.127.20.0 minpoll 4
fudge 127.127.20.0 flag3 1 flag2 0
 
# SHM: PPS filtered mean
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid PPS flag3 1

from a small shell script
=
# Start shmpps and gpsd daemon
cd /dev
ln -s ttyS0 pps0
ln -s ttyS0 gps0
sleep 2
# Set up shmpps
cd /Linux-Software/shmpps
./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c
#
# Start up gpsd
/usr/sbin/gpsd -b -n /dev/ttyS0

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 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 28-dec-2008.

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
 GPS_NMEA(0) .GPS.0 l  273   1600.000  -664.93
0.002
xSHM(0)  .PPS.0 l7   16  2270.000  -634.51
349.893
 eagle-local 192.168.1.7  4 u   11   64   370.120  -11.083
0.523
 apollo-local192.168.1.7  3 u   18   64   370.2246.685
0.765
x64.247.17.251   129.6.15.28  2 u   12   64   37   34.158  -18.850
6.764
+ip-72-167-54-20 204.123.2.72 2 u   13   64   37   82.7221.031
1.821
*caspak.cerias.p .GPS.1 u   10   64   37   22.8677.745
10.934


OK here is about 21 hours later 11Z 29 Dec-2008:

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l2   16  3750.000  -722.08
9.115
xSHM(0)  .PPS.0 l6   16  3770.000  -722.20
7.892
 eagle-local 192.168.1.7  4 u  390 1024  3770.181   -5.629
4.389
 apollo-local192.168.1.7  4 u  410 1024  3770.311   -2.394
0.299
*got.my.mojo.net 192.5.41.41  2 u  966 1024  377   30.157   -5.166
0.361
+kiri.nonexiste. 64.202.112.752 u  644 1024  3779.423   -5.517
203.143
+host2.kingrst.c 99.150.184.201   2 u  944 1024  377   16.221  -11.608
16.695


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??

OK, it is really really suspicious that both nmea and shm are equal amounts
off. That should not be. It is as if your shm is actually reporting the
nmea time rathr than the pps time. 

What are you running to deliver the shm signals to the system?
As stated earlier, reposted for convenience the standalone shmpps
driver program and the GPS:

ntp.conf

# LinuxPPS: GPS
server 127.127.20.0 minpoll 4
fudge 127.127.20.0 flag3 1 flag2 0
 
# SHM: PPS filtered mean
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid PPS flag3 1

from a small shell script
=
# Start shmpps and gpsd daemon
cd /dev
ln -s ttyS0 pps0
ln -s ttyS0 gps0
sleep 2
# Set up shmpps
cd /Linux-Software/shmpps
./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c
#
# Start up gpsd
/usr/sbin/gpsd -b -n /dev/ttyS0

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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:

  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 being detected, so
 why not try reversing the polarity?  I only use the:  127.127.20.1 
 reference clock, with GPS configured in the kernel.

 Cheers,
 David

That should read:  with PPS configured in the kernel.

The polarity switch is listed here:

  http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html

as:

flag2 0 | 1
  Specifies the PPS signal on-time edge: 0 for assert (default), 1 for 
clear.

OK I've added the 

flag2 1

to both the GPS and PPS fudge lines and restarted hereso far not
much change.

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l   18   16  3760.000  -635.06
10.323
xSHM(0)  .PPS.0 l6   16  3770.000  -628.03
108.161


George

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 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 being detected, so
 why not try reversing the polarity?  I only use the:  127.127.20.1 
 reference clock, with GPS configured in the kernel.

 Cheers,
 David

That should read:  with PPS configured in the kernel.

The polarity switch is listed here:

  http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html

as:

flag2 0 | 1
  Specifies the PPS signal on-time edge: 0 for assert (default), 1 for 
clear.

OK I've added the 

flag2 1

to both the GPS and PPS fudge lines and restarted hereso far not
much change.

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l   18   16  3760.000  -635.06
10.323
xSHM(0)  .PPS.0 l6   16  3770.000  -628.03
108.161


George


Removing the GPS entry from the ntp.conf and taking out the flag2 1
items so I'm back to just PPS with shm driver and no gpsd running I
get almost immediately:

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
*SHM(0)  .PPS.0 l6   16   170.0001.283
1.803
 eagle-local 192.168.1.7  4 u8   6430.122  -32.943
0.865
 apollo-local192.168.1.7  4 u6   6430.240  -12.200
0.630
-220962.ds.nac.n 129.6.15.28  2 u4   643   37.344   32.745
97.004
+mighty.poclabs. 64.202.112.752 u3   643   11.679   15.479
186.690
+splenda.rustyte 192.43.244.182 u2   643   47.7555.733
86.910


What am I doing wrong here when I add back GPS data to break this
thing???

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 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 likely that the wrong edge is being detected, so
 why not try reversing the polarity?  I only use the:  127.127.20.1 
 reference clock, with GPS configured in the kernel.

 Cheers,
 David

That should read:  with PPS configured in the kernel.

The polarity switch is listed here:

  http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html

as:

flag2 0 | 1
  Specifies the PPS signal on-time edge: 0 for assert (default), 1 for 
clear.

OK I've added the 

flag2 1

to both the GPS and PPS fudge lines and restarted hereso far not
much change.

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l   18   16  3760.000  -635.06
10.323
xSHM(0)  .PPS.0 l6   16  3770.000  -628.03
108.161


George


Removing the GPS entry from the ntp.conf and taking out the flag2 1
items so I'm back to just PPS with shm driver and no gpsd running I
get almost immediately:

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
*SHM(0)  .PPS.0 l6   16   170.0001.283
1.803
 eagle-local 192.168.1.7  4 u8   6430.122  -32.943
0.865
 apollo-local192.168.1.7  4 u6   6430.240  -12.200
0.630
-220962.ds.nac.n 129.6.15.28  2 u4   643   37.344   32.745
97.004
+mighty.poclabs. 64.202.112.752 u3   643   11.679   15.479
186.690
+splenda.rustyte 192.43.244.182 u2   643   47.7555.733
86.910


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)

and I see

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l   13   16  3770.000  -616.37
10.466
*SHM(0)  .PPS.0 l   14   16  3770.000   -0.557
0.712
 eagle-local 192.168.1.7  2 u   36   64  3770.153  -44.398
0.607
 apollo-local192.168.1.7  3 u   24   64  3770.250  -16.713
1.912
-mirror  209.132.176.42 u   29   64  377   10.2726.391
135.974
+tesla.fireduck. 198.82.1.202 3 u   28   64  377   36.1232.841
115.565
+rikku.vrillusio 209.51.161.238   2 u   21   64  377   38.531   -3.260
156.267


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??

George

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 GPS receivers have rather low priority for timing data 
and can easily err by this sort of amount.

Actually, you may be able to fudge the NMEA (note spelling) time to 
compensate for the systematic part of the error, but there is no 
guarantee that there won't be a large random component.
OK. Sorry about the bad typing...clumsy brain/finger connectionso
what would cause the gpsd daemon to mess this up so badly then? I
don't need it here, but it would be nice to know for future reference
as I've beat my head on the wall for near on two weeks now.

Would it be worth a fudge correction and if so by how much? Half the
average error about all the average error or just leave it alone?

George

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 teh NMEA data and passes it on to ntp.
Put the config lines back in ntp.conf so it would read the NMEA data.

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l   13   16  3770.000  -616.37
10.466

Looks to me like you could get rid of that offset with a fudge.
What would be a good amount to use half the avg. erorr or ??

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??

Use the fudge to get rid of that offset. nmea is very very slow. And I
suspect that you are having the Garmin report a huge number of nmea
sentences. That takes along time to parse. 

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

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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:

  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 being detected, so why not try 
reversing the polarity?  I only use the:  127.127.20.1  reference clock, 
with GPS configured in the kernel.


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, or you need to use the
parallel port instead, which takes 0-5V.
What you are proposing is contrary to almost everything I've read
about hooking up this unit.
-- 
George, Ginger/The Beast Kasica(8/1/88-3/19/01, 1/17/02- ), Rosie(9/1/07- ), 
Merlin/MR. Tibbs(8/1/90-5/24/06, 2/10/08- ), Nazarene(6/1/99-1/28/08)
Jackson, WI USA
geor...@netwrx1.com
http://www.netwrx1.com/georgek
ICQ #12862186

(`-''-/).___..--''`-._
`6_ 6  )   `-.  ( ).`-.__.`)
(_Y_.)'  ._   )  `._ `. ``-..-'
_..`--'_..-_/  /--'_.' ,'
(il),-''  (li),'  ((!.-'

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 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 teh NMEA data and passes it on to ntp.
Put the config lines back in ntp.conf so it would read the NMEA data.

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l   13   16  3770.000  -616.37
10.466

Looks to me like you could get rid of that offset with a fudge.
What would be a good amount to use half the avg. erorr or ??

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??

Use the fudge to get rid of that offset. nmea is very very slow. And I
suspect that you are having the Garmin report a huge number of nmea
sentences. That takes along time to parse. 

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


Yousend it an NMEA sentence telling it to not report those sentences you do
not need. 

Setup minicom to listen to the serial port and display the output to your
screen so you can see which sentences are actually being reported. Then 
send it the sentences to tell it to switch off the ones you do not need.

The PGRMO NMEA sentence tells teh garmin to switch off or on the sentence.
EG sending
PGRMO,,2CRLF
(all MUST end with carriage return line feed) will disable all sentences. 
That doing
PGRMO,GPRMC,1CRLF
will enable just the GPRMC sentence.
 
(The first argument is teh sentence to affect, the second is
0=disable,1=enable, 2=disable all, 3=enable all)

I found that the easiest way was to construct the sentence in a file,
putting the CRLF at the end of the file, and then cutting and pasting
into the minicom terminal program.
OK I set that up to just send the GPRMC data  here but it seems to
have made little difference in the GPS offset.

(left some servers out)

]# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l6   16  3770.000  -667.14
11.102
*SHM(0)  .PPS.0 l   14   16  3770.0004.673
0.908
+eagle-local 192.168.1.2  3 u   43   6470.112   33.566
0.633
+apollo-local192.168.1.1  3 u   42   6470.248   -4.073
0.729

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 28-dec-2008.

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
 GPS_NMEA(0) .GPS.0 l  273   1600.000  -664.93
0.002
xSHM(0)  .PPS.0 l7   16  2270.000  -634.51
349.893
 eagle-local 192.168.1.7  4 u   11   64   370.120  -11.083
0.523
 apollo-local192.168.1.7  3 u   18   64   370.2246.685
0.765
x64.247.17.251   129.6.15.28  2 u   12   64   37   34.158  -18.850
6.764
+ip-72-167-54-20 204.123.2.72 2 u   13   64   37   82.7221.031
1.821
*caspak.cerias.p .GPS.1 u   10   64   37   22.8677.745
10.934


OK here is about 21 hours later 11Z 29 Dec-2008:

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l2   16  3750.000  -722.08
9.115
xSHM(0)  .PPS.0 l6   16  3770.000  -722.20
7.892
 eagle-local 192.168.1.7  4 u  390 1024  3770.181   -5.629
4.389
 apollo-local192.168.1.7  4 u  410 1024  3770.311   -2.394
0.299
*got.my.mojo.net 192.5.41.41  2 u  966 1024  377   30.157   -5.166
0.361
+kiri.nonexiste. 64.202.112.752 u  644 1024  3779.423   -5.517
203.143
+host2.kingrst.c 99.150.184.201   2 u  944 1024  377   16.221  -11.608
16.695


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??

ntp.conf is below:

# LinuxPPS: GPS 
server 127.127.20.0 minpoll 4 
fudge 127.127.20.0 flag3 1 flag2 0
 
# SHM: PPS filtered mean 
server 127.127.28.0 minpoll 4 
fudge 127.127.28.0 refid PPS flag3 1
 
server eagle.netwrx1.com iburst
server apollo.netwrx1.com iburst
server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 are probably detecting the wrong edge (wrong polarity) of the second 
pulse.
So how in the world do I fix this? 

Prior to having both NEMA and PPS running at the same time all was
working well with just PPS and the shm driver.

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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
 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 28-dec-2008.

 # ntpq -p
 remote   refid  st t when poll reach   delay   offset
 jitter
 ==
 GPS_NMEA(0) .GPS.0 l  273   1600.000  -664.93
 0.002
 xSHM(0)  .PPS.0 l7   16  2270.000  -634.51
 349.893
 eagle-local 192.168.1.7  4 u   11   64   370.120  -11.083
 0.523
 apollo-local192.168.1.7  3 u   18   64   370.2246.685
 0.765
 x64.247.17.251   129.6.15.28  2 u   12   64   37   34.158  -18.850
 6.764
 +ip-72-167-54-20 204.123.2.72 2 u   13   64   37   82.7221.031
 1.821
 *caspak.cerias.p .GPS.1 u   10   64   37   22.8677.745
 10.934

 
 OK here is about 21 hours later 11Z 29 Dec-2008:
 
 # ntpq -p
  remote   refid  st t when poll reach   delay   offset
 jitter
 ==
 xGPS_NMEA(0) .GPS.0 l2   16  3750.000  -722.08
 9.115
 xSHM(0)  .PPS.0 l6   16  3770.000  -722.20
 7.892
  eagle-local 192.168.1.7  4 u  390 1024  3770.181   -5.629
 4.389
  apollo-local192.168.1.7  4 u  410 1024  3770.311   -2.394
 0.299
 *got.my.mojo.net 192.5.41.41  2 u  966 1024  377   30.157   -5.166
 0.361
 +kiri.nonexiste. 64.202.112.752 u  644 1024  3779.423   -5.517
 203.143
 +host2.kingrst.c 99.150.184.201   2 u  944 1024  377   16.221  -11.608
 16.695
 
 
 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??
 
 ntp.conf is below:
 
 # LinuxPPS: GPS 
 server 127.127.20.0 minpoll 4 
 fudge 127.127.20.0 flag3 1 flag2 0
  
 # SHM: PPS filtered mean 
 server 127.127.28.0 minpoll 4 
 fudge 127.127.28.0 refid PPS flag3 1
  
 server eagle.netwrx1.com iburst
 server apollo.netwrx1.com iburst
 server 0.us.pool.ntp.org iburst
 server 1.us.pool.ntp.org iburst
 server 2.us.pool.ntp.org iburst

Without actually being there it's difficult to say.  Clearly something 
is very wrong but exactly what is not immediately obvious, at least to 
me!  Your GPS receiver is being rejected as a falseticker!
So what do I need to do here? It was working well with just shm and
the PPS signal, once I added both NEMA and PPS things went
southwhat do I need to be looking at here, I'm by far not an
expert at this.

I can't say it's because it's presenting an in correct time; that's most 
  unlikely assuming it's installed correctly and can see at least four 
satellites.
When I look at the GPS unit with the Garmin utility in Windows it has
a fix and altitude in it so I'm assuming its seeing a sufficient
number and also gpsd is griping about too many satellites at times in
/var/log/messages so I'm guessing there are far more than 4.

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 with some type of setting - ideally
 that is what I'm trying to accomplish through the shm driver or
 something else without hacking the kernel, etc??

I used to use a two serial port setup; ttyS0 for PPS using SHM and ttyS1 
for NMEA. This requires a gps0 - ttyS1 symlink;
server 127.127.20.0
fudge  127.127.20.0 time1 0.172
server 127.127.28.0 minpoll 4 prefer
fudge  127.127.28.0 refid PPS

ttyS1 gets all the signals, ttyS0 just the PPS.

This worked better then GPSD, so I think I will return to this setup.

Did you need to use two physical serial plugs or a splitter or just do
this with symlinks in the OS?
-- 
George, Ginger/The Beast Kasica(8/1/88-3/19/01, 1/17/02- ), Rosie(9/1/07- ), 
Merlin/MR. Tibbs(8/1/90-5/24/06, 2/10/08- ), Nazarene(6/1/99-1/28/08)
Jackson, WI USA
geor...@netwrx1.com
http://www.netwrx1.com/georgek
ICQ #12862186

(`-''-/).___..--''`-._
`6_ 6  )   `-.  ( ).`-.__.`)
(_Y_.)'  ._   )  `._ `. ``-..-'
_..`--'_..-_/  /--'_.' ,'
(il),-''  (li),'  ((!.-'

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 and PPS auto Off etc.

setserial /dev/ttyS0 uart 16550A port 0x03f8 irq  4 baud_base 115200
spd_normal skip_test low_latency

/usr/sbin/gpsd -b -n /dev/ttyS0

./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c

Ah, you are NOT running the kernel PPS. You are running the shm refclock
using the timing of the serial port driver. 
Correct. Getting the pps patch to work here with the rpm based kernels
for Fedora Core 9 has proven to be problematic. Has anyone got any
pointers or managed to get this working?

Why do it? There is nothing wrong with the shm driver. It will discipline
the clock as well as (better than?) the kernel patch.
OK. That is the type of experience information I need to know. I have
no idea what is good or bad here with this device. Thank you.

my ntpd.conf looks like:

server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag3 1
That is solely the shm refclock driver which is coming off your serial port
interrupt. You do not have the serial nmea data coming in at all to your
system it looks to me.
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 through the shm driver or
something else without hacking the kernel, etc??

Have both!. Nothing says you need to use only one or the other. Use the
shm pps as the preferred but the nmea to get the seconds right. 
The pool servers are then simply as a backup.
Ie also use 127.127.28.0 as a server.


server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 flag3 1 flag2 0
OK. I've added back the GPS NEMA lines as well as the PPS lines and
thing seem to be working here. Will see how it goes over the next day
or so. This is exactly what I was looking to try to do. 

Again, thank you very much.

Right now ntpq looks like this (after just a few min restarted @ 1200Z
12/28/08)  I'm assuming things will settle back down over time and I
will once again start to use the local time sources instead of marking
them as false tickers?:

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
xGPS_NMEA(0) .GPS.0 l   16   16  3770.000   12.677
5.862
xSHM(0)  .PPS.0 l   12   16  3770.0008.410
93.475
-eagle-local 192.43.244.182 u   99  128   370.166  724.868
0.714
-apollo-local128.233.154.245  2 u   98  128   370.215  706.214
0.787
 mumnunah.csse.u .INIT.  16 u-   6400.0000.000
0.000
+tick.usask.ca   .GPS.1 u   97  128   37  105.157  702.859
0.756
*clock.isc.org   .GPS.1 u   95  128   37   63.669  702.671
3.087
-time.nist.gov   .ACTS.   1 u   94  128   37   72.814  691.122
24.052
-server.donkeyfl 18.26.4.105  2 u   93  128   37   30.919  706.994
22.203
+ip-72-167-54-20 164.67.62.1942 u   93  128   37   83.165  702.973
137.172
-ns1.bluebottle. 64.202.112.752 u   88  128   37   25.726  712.661
3.246

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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
 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 low_latency
 /usr/sbin/gpsd -b -n /dev/ttyS0
 ./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c
 Ah, you are NOT running the kernel PPS. You are running the shm refclock
 using the timing of the serial port driver. 
 Correct. Getting the pps patch to work here with the rpm based kernels
 for Fedora Core 9 has proven to be problematic. Has anyone got any
 pointers or managed to get this working?
 Why do it? There is nothing wrong with the shm driver. It will discipline
 the clock as well as (better than?) the kernel patch.
 OK. That is the type of experience information I need to know. I have
 no idea what is good or bad here with this device. Thank you.
 
 my ntpd.conf looks like:
 server 127.127.28.0 minpoll 4 prefer
 fudge 127.127.28.0 refid PPS flag3 1
 That is solely the shm refclock driver which is coming off your serial 
 port
 interrupt. You do not have the serial nmea data coming in at all to your
 system it looks to me.
 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 through the shm driver or
 something else without hacking the kernel, etc??
 Have both!. Nothing says you need to use only one or the other. Use the
 shm pps as the preferred but the nmea to get the seconds right. 
 The pool servers are then simply as a backup.
 Ie also use 127.127.28.0 as a server.


 server 127.127.20.0 minpoll 4 prefer
 fudge 127.127.20.0 flag3 1 flag2 0
 OK. I've added back the GPS NEMA lines as well as the PPS lines and
 thing seem to be working here. Will see how it goes over the next day
 or so. This is exactly what I was looking to try to do. 
 
 Again, thank you very much.
 
 Right now ntpq looks like this (after just a few min restarted @ 1200Z
 12/28/08)  I'm assuming things will settle back down over time and I
 will once again start to use the local time sources instead of marking
 them as false tickers?:
 
 # ntpq -p
  remote   refid  st t when poll reach   delay   offset
 jitter
 ==
 xGPS_NMEA(0) .GPS.0 l   16   16  3770.000   12.677
 5.862
 xSHM(0)  .PPS.0 l   12   16  3770.0008.410
 93.475
 -eagle-local 192.43.244.182 u   99  128   370.166  724.868
 0.714
 -apollo-local128.233.154.245  2 u   98  128   370.215  706.214
 0.787
  mumnunah.csse.u .INIT.  16 u-   6400.0000.000
 0.000
 +tick.usask.ca   .GPS.1 u   97  128   37  105.157  702.859
 0.756
 *clock.isc.org   .GPS.1 u   95  128   37   63.669  702.671
 3.087
 -time.nist.gov   .ACTS.   1 u   94  128   37   72.814  691.122
 24.052
 -server.donkeyfl 18.26.4.105  2 u   93  128   37   30.919  706.994
 22.203
 +ip-72-167-54-20 164.67.62.1942 u   93  128   37   83.165  702.973
 137.172
 -ns1.bluebottle. 64.202.112.752 u   88  128   37   25.726  712.661
 3.246

An ntpq banner is not much use until at least thirty minutes have 
elapsed since startup!
OK. Noted.

I question the selection of servers!  Round trip delays of 63, 72, 83, 
and 105 milliseconds seem unreasonable to me!  The uncertainty in the 
time reported by a server may be as great as one half of the round trip 
delay.  This suggests that you should strive to have the lowest possible 
round trip delays.  If the nearest servers are 1000 miles, or more, away 
from your site, there's not much  you can do but not many places are 
that far away from any NTP server.  Note that network distance rather 
than physical distance is what counts here; e.g. if you are in New York, 
a server in New Jersey that can only be reached by relaying through Los 
Angeles is, effectively 3000 miles away!
I was just going on what I had seen used elsewhere and ntp pool;
servers as suggested. Have modified accordingly to just use the GPS
locally, two local servers on the same net and 3 NTP us pool servers -
can't really control the locations of those though that I know of.

The use of ten servers also seems a little extreme.  Four, five, and 
seven are the magic numbers that protect you from the failure of one, 
two, or three servers; e.g. given seven servers, of which three are 
bad (wrong time or not responding) the remaining four are sufficient 
to outvote the bad servers.

Since you

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 low_latency

/usr/sbin/gpsd -b -n /dev/ttyS0

./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c

Ah, you are NOT running the kernel PPS. You are running the shm refclock
using the timing of the serial port driver. 
Correct. Getting the pps patch to work here with the rpm based kernels
for Fedora Core 9 has proven to be problematic. Has anyone got any
pointers or managed to get this working?



my ntpd.conf looks like:

server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag3 1
That is solely the shm refclock driver which is coming off your serial port
interrupt. You do not have the serial nmea data coming in at all to your
system it looks to me.
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 through the shm driver or
something else without hacking the kernel, etc??

server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 flag3 1 flag2 0


server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
You are geting the information of the correct seconds from these external
servers. 
Correct.

And looking at ntpq stats shows me:
You do not say when these were taken. ntp takes about 10 hours to settle
down to its ultimate accuracy. If this was less than 10 hours, the figures
mean nothing. 
That was about 12 hours after setup. Here are stats from 12/27 @ 1440Z
which is about 40 hours of running on the ntpd config here (restarted
on 12/25 @ 2200Z approx).

# ntpq -p  
 remote   refid  st t when poll reach   delay   offset
jitter
==
*SHM(0)  .PPS.0 l   15   16  3770.0000.004
0.002
-mighty.poclabs. 64.202.112.752 u  696 1024  377   11.718   -1.234
150.234
-clock3.redhat.c .CDMA.   1 u  688 1024   57   59.8271.536
93.244
+192.157.38.60   192.36.143.151   2 u  691 1024  377  118.7061.052
74.929

# ntpdc -c kern
pll offset:   2e-06 s
pll frequency:111.093 ppm
maximum error:0.006033 s
estimated error:  2e-06 s
status:   0001  pll
pll time constant:5
precision:1e-06 s
frequency tolerance:  500 ppm

Your offset should settle down to about plus or minus .005 
Looks lie its OK at .004 if I read this correctly.

The offsets from the external sources are irrelevant ( as long as they are
not greater than 500 or so-- 1/2 sec)
Again seem to look OK at around +/- 1.x


Thank you very much for the help.

George

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 without having to recompile the kernel as on FC9 its not that
easy to do as it comes down as an RPM and I don't think the patches
are built for it...

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?

3) Any other suggestions that anyone would care to make, I don't claim
to be an expert here:

Thank you very much.

George



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 low_latency

/usr/sbin/gpsd -b -n /dev/ttyS0

./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c

my ntpd.conf looks like:

server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag3 1
 
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org


And looking at ntpq stats shows me:

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
*SHM(0)  .PPS.0 l   13   16  3770.000   -0.056
0.013
-mighty.poclabs. 64.202.112.752 u  800 1024  377   12.2432.336
0.316
-clock3.redhat.c 66.187.233.4 2 u  946 1024  257   59.1262.760
42.876
-192.157.38.60   192.36.143.150   2 u  807 1024  377  119.1111.110
0.037

# ntpdc -c kern
pll offset:   -5.7e-05 s
pll frequency:111.071 ppm
maximum error:0.009019 s
estimated error:  1.3e-05 s
status:   0001  pll
pll time constant:10
precision:1e-06 s
frequency tolerance:  500 ppm
-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way

[George R . Kasica]

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 experience here, are what I'm seeing for
numbers below good bad or ?? based on how I'm set up and is there
anything I should be correcting?

2) Is there any way I can use both the GPS time data AND the PPS
signal without having to recompile the kernel as on FC9 its not that
easy to do as it comes down as an RPM and I don't think the patches
are built for it...

You can, but not with the standard ntp drivers. I run the gps nmea into the
serial port and the PPS into the parallel port, and use a program I wrote
to time the parallel interrupt and deliver the result to the shm driver.
But that might be a bit too complex for you.
As you state, too much work to do here, I don't really want to rewire
the cable any more than it is already if I don't need to. It seems to
be working well providing the PPS signal via DCD and getting powered
by USB. Again, getting anything really odd compiled here (see #2
above) isn't that simple for this box.

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 signals are hardware signals. What do you mean share them? If
you mean installing a splitter so that the same PPS signal is delivered to
the two machines, yes you can do that. If you mean something else you need
to say what.
I was hoping that gpsd would be able to simulate or transmit the pps
similar to how it does with NEMA data but as you day they are hardware
signals so apparently it cannot do that. Again, I don't really want to
make the hardware any more convoluted than necessary here.

The standard ntp network route will mean that the second clock will have
its time disciplined to about 20usec, instead of the 2usec that a direct
PPS signal would deliver. 
That's more than sufficient for what I'm doing here.

3) Any other suggestions that anyone would care to make, I don't claim
to be an expert here:
You need to say what you want. I could suggest that you give money to
Oxfam, but that might not accord with what you wanted to do. Ie, what are
you trying to do. 
I thought the question was fairly obvious and I'm going to take it in
the spirit of humor I'm assuming that you meant it. I was hoping
someone would take a look at the info provided below and let me know
if they see any obvious ways to improve on what I'm doing here or
things I may be doing that are incorrect.

Thanks,
George

Thank you very much.

George



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 low_latency

/usr/sbin/gpsd -b -n /dev/ttyS0

./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c

my ntpd.conf looks like:

server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag3 1
 
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org


And looking at ntpq stats shows me:

# ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
*SHM(0)  .PPS.0 l   13   16  3770.000   -0.056
0.013
-mighty.poclabs. 64.202.112.752 u  800 1024  377   12.2432.336
0.316
-clock3.redhat.c 66.187.233.4 2 u  946 1024  257   59.1262.760
42.876
-192.157.38.60   192.36.143.150   2 u  807 1024  377  119.1111.110
0.037

# ntpdc -c kern
pll offset:   -5.7e-05 s
pll frequency:111.071 ppm
maximum error:0.009019 s
estimated error:  1.3e-05 s
status:   0001  pll
pll time constant:10
precision:1e-06 s
frequency tolerance:  500 ppm
-- 
===[George R. Kasica]===+1 262 677 0766
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Jackson, WI USA 
http://www.netwrx1.com
geor...@netwrx1.com
ICQ #12862186
-- 
George, Ginger/The Beast Kasica(8/1/88-3/19/01, 1/17/02- ), Rosie(9/1/07- ), 
Merlin/MR. Tibbs(8/1/90-5/24/06, 2/10/08- ), Nazarene(6/1/99-1/28/08)
Jackson, WI USA
geor...@netwrx1.com
http://www.netwrx1.com/georgek
ICQ #12862186

(`-''-/).___..--''`-._
`6_ 6  )   `-.  ( ).`-.__.`)
(_Y_.)'  ._   )  `._ `. ``-..-'
_..`--'_..-_/  /--'_.' ,'
(il),-''  (li),'  ((!.-'

___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions