Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
> 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 l 5 16 377 0.000 25.349 > 9.221 > *SHM(0) .PPS. 0 l 14 16 377 0.000 2.953 > 0.176 > eagle-local 192.168.1.7 2 u 731 1024 377 0.160 -2.518 > 0.152 > apollo-local .STEP. 16 u 725 1024 376 0.236 -8.591 > 0.809 > -clock.trit.net 164.67.62.194 2 u 40 128 377 154.590 44.455 > 215.345 > +64.247.17.255 129.6.15.28 2 u 4 128 377 45.530 -13.520 > 252.661 > -kiri.nonexiste. 69.10.36.2 3 u 11 128 377 9.470 -12.775 > 1.132 > > -- > ===[George R. Kasica]=== +1 262 677 0766 > President +1 206 374 6482FAX > Netwrx Consulting Inc. Jackson, WI USAhttp://www.netwrx1.com > geor...@netwrx1.com > ICQ #12862186 George, understandable. To be honest, the only benefit gpsd brings is the ability to keep the clock synced if internet is lost and the clock drifts too far away from the pps driver's liking. Even though I have gpsd running, I quite possibly will switch back to shmpps. It seemed to be a little better at keeping time anyway. I'd really like to get LinuxPPS working though, because I can see it being slightly better at time keeping than the others. Chris ___ 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
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. 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 > > How is this different from leaving the source code intact and fudging > the reference by +0.580? > > TIA Sorry for the double post, but it's easier to prove via logs too. ntpd.conf: #Garmin GPS 18x LVC 0.520 worked tried up to 0.800 server 127.127.28.0 minpoll 4 noselect #Local GPS serial #fudge 127.127.28.0 time1 -0.420 refid GPSa #to prove positive adjustment doesn't work fudge 127.127.28.0 time1 0.580 refid GPSa #PPS pin server 127.127.28.1 minpoll 4 prefer fudge 127.127.28.1 refid PPSa ntpq -p response: == SHM(0) .GPSa. 0 l 13 16 770.000 -79.107 20.795 SHM(1) .PPSa. 0 l- 1600.000 0.000 0.001 navobs1.gatech. .GPS.1 u 32 643 62.163 3.120 0.211 ntp-s1.cise.ufl .GPS.1 u 28 643 67.988 1.296 18.917 See, no PPS output but SHM(0) is about on target. and gpsd (non-modified version) output log --SNIP-- gpsd: pps-detect (DCD) on /dev/ttyS0 changed to 1 gpsd: ntpshm_pps: not in locking range: 627236 gpsd: PPS pulse. cycle: 106, duration: 79 gpsd: pps-detect (DCD) on /dev/ttyS0 changed to 0 gpsd: ntpshm_pps: not in locking range: 627236 gpsd: PPS pulse. cycle: 88, duration: 199989 --SNIP-- ___ 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
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. 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 > > How is this different from leaving the source code intact and fudging > the reference by +0.580? > > TIA Evandro, because gpsd (and apparently LinuxPPS) have checks that lock it in to what it thinks is the 0 second boundary. I've tried to fudge it forward to the correct 0 second, but gpsd gives the error "not in locking range: 660123." So, it thinks it's 600ms away from the correct locking area, when it's actually ~0ms away. It's calculated the wrong second. There was a long thread in the gpsd mailing list where 2 developers were arguing on how to avoid this, and I think they either took it out completely or made some fix because the code didn't have the offset anymore. If you are using gpsd, and you set the clock exactly 1 second ahead while fudging nmea 1 second ahead with it, gpsd *shouldn't* send the pulse data because it will claim it's out of locking range. ___ 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
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 > server 127.127.28.0 minpoll 4 noselect #Local GPS serial > fudge 127.127.28.0 time1 -0.420 refid GPSa How is this different from leaving the source code intact and fudging the reference by +0.580? TIA ___ 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 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. >> 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 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 want to. Thanks. Yes, I had to recompile the FreeBSD kernel to include this patch. I must have thought at the time that it was mandatory, or was advised to do this. >> >>>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'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 think it will gain you nothing over the shm option, except you will be >>sitting there worrying and watching your computer compiling a kernel. >> >>However, has anyone done tests on the serial port interrupt to see how much >>latency there is in that? Ie, If I use, say, shmpps and I trigger the serial >>control line at time t, what is the time t+dt that shmpps reports as the >>time of the trigger? And what is the fluctuation in dt? On the parallel >>port interrupt service routine I have done that and the result was about >>0-2usec. (in fact I suspect most of the noise in at least the short term >>fluctuation of ntpd is from that source). But shmpps and gpsd have a whole >>layer of serial port driver interposed between the interrupt and the >>report. Does that made a difference? >I likely have nowhere near the level of hardware/software knowledge or >likely test gear to accomplish this. TEst gear not needed. You just need to put out and time a signal onto the parallel port and feed it into the serial port, timing the reception of the signal. But that does require a lot of hacking. I was able to do it on the parallel port because the program had already been written in Alessandro Rubini and Jonathan Corbet's boot Linux Device Drivers I just made minor adaptation ( or major ones when I used it as the basis for my parallel port gps device driver) However, I was wondering if anyone had done the same thing for the standard serial port ioctl ___ 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 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 EUMETCast service: http://www.eumetsat.int/HOME/Main/What_We_Do/EUMETCast/index.htm I write software for decoding and displaying the data, hence I get all the transmitted data. It's not sent on anywhere, though. Cheers, David Web site: www.satsignal.eu ___ 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
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 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 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 want to.
>>>
>>>Thanks. Yes, I had to recompile the FreeBSD kernel to include this patch.
>>>I must have thought at the time that it was mandatory, or was advised to
>>>do this.
>
>>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'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 think it will gain you nothing over the shm option, except you will be
>sitting there worrying and watching your computer compiling a kernel.
>
>However, has anyone done tests on the serial port interrupt to see how much
>latency there is in that? Ie, If I use, say, shmpps and I trigger the serial
>control line at time t, what is the time t+dt that shmpps reports as the
>time of the trigger? And what is the fluctuation in dt? On the parallel
>port interrupt service routine I have done that and the result was about
>0-2usec. (in fact I suspect most of the noise in at least the short term
>fluctuation of ntpd is from that source). But shmpps and gpsd have a whole
>layer of serial port driver interposed between the interrupt and the
>report. Does that made a difference?
I likely have nowhere near the level of hardware/software knowledge or
likely test gear to accomplish this.
--
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
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 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] Garmin GPS 18LVC Setup but questions on best way
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, 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 ___ 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 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 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 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 want to. >> >>Thanks. Yes, I had to recompile the FreeBSD kernel to include this patch. >>I must have thought at the time that it was mandatory, or was advised to >>do this. >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'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 think it will gain you nothing over the shm option, except you will be sitting there worrying and watching your computer compiling a kernel. However, has anyone done tests on the serial port interrupt to see how much latency there is in that? Ie, If I use, say, shmpps and I trigger the serial control line at time t, what is the time t+dt that shmpps reports as the time of the trigger? And what is the fluctuation in dt? On the parallel port interrupt service routine I have done that and the result was about 0-2usec. (in fact I suspect most of the noise in at least the short term fluctuation of ntpd is from that source). But shmpps and gpsd have a whole layer of serial port driver interposed between the interrupt and the report. Does that made a difference? >If someone can detail what needs to happen I'd be happy to run it that >way, though as of right now I'm not sure what it would gain me over >the shm driver option. FYI the kernel I'm running is: >2.6.27.7-53.fc9.i686 #1 SMP >and loaded rpms are: >kernel-devel-2.6.27.7-53.fc9.i686 >kernel-headers-2.6.27.7-53.fc9.i386 >kernel-firmware-2.6.27.7-53.fc9.noarch >kernel-2.6.27.7-53.fc9.i686 >kernel-doc-2.6.27.7-53.fc9.noarch >-- >===[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
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's presumably >>> why I needed to (or was advised to) re-compile the kernel. >> >> There is a difference between applying a third party patch to the >> kernel and specifying a compile time option which activates built in >> code. >> >> I use a FreeBSD 5.3 Kernel in my Soekris NET4801 and also had to >> specify the PPS option to get that feature. > > Thanks for that clarification, Steve. Let's hope tonight's leap second > goes well. > > Cheers, > David Last time, virtually the entire world screwed it up somehow. It took the better part of twenty-four hours before everyone agreed once again on more or less the same time! I will be amazed if it's any better this time. ___ 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
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 be able to achieve this. > Totem poll TTL high is 2.4V at 400 micro Amps. LS TTL is 2.7V. > (National Semiconductors Data Book, 1976) > > CMOS is 4.95V minimum into infinity, at 5V Vdd, or 4.6 volts at 300 > micro amps. The CMOS case corresponds to a load resistance that is a > little higher than that of an RS232 C receiver, so one would expect > somewhat lower an output voltage into the real load. Figures for 4000 > series CMOS, from 1975 RCA COS/MOS Integrated Circuits Data Book. Regards, Rob ___ 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
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 high is actually Ca 3.5 V. CMOS high is 5 V (when supplied > with 5 V power). Totem poll TTL high is 2.4V at 400 micro Amps. LS TTL is 2.7V. (National Semiconductors Data Book, 1976) CMOS is 4.95V minimum into infinity, at 5V Vdd, or 4.6 volts at 300 micro amps. The CMOS case corresponds to a load resistance that is a little higher than that of an RS232 C receiver, so one would expect somewhat lower an output voltage into the real load. Figures for 4000 series CMOS, from 1975 RCA COS/MOS Integrated Circuits Data Book. ___ 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 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. Cheers, David ___ 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
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 actually delivers. There is > absolutely no reason why it should. That signal is completely out of spec. > If yours does work, it is because your serial port manufacturer severely > bent the rules. But many (most?) do. But it could well be that the serial > port is flakey on especially the 0V instead of -5 to -12 V end. In V24 it's -25 ... 25 V [1]. -3 ... 3 V isn't defined. Most level translators however are completely happy with 'TTL' [2] signals. This is not bending the specs, it's within the specs. Not being happy with 'TTL' is also within the specs. If you want to make sure have a look at the data sheets of your level translators. Most consider < 0.8 V low and > 2 V high. > The parallel port specs state that the signal levels are 0V and 5 V which > is exactly what the garmin delivers. An alternative is converting the Garmin signals to RS232. [1] Most level translators can cope with -15 ... 15 V [2] TTL high is actually Ca 3.5 V. CMOS high is 5 V (when supplied with 5 V power). Regards, Rob -- Anglo-Saxon management is a memetic virus ___ 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
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 need the SHM >>> driver, but as I said before, 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 want to. > >Thanks. Yes, I had to recompile the FreeBSD kernel to include this patch. >I must have thought at the time that it was mandatory, or was advised to >do this. 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'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 :). If someone can detail what needs to happen I'd be happy to run it that way, though as of right now I'm not sure what it would gain me over the shm driver option. FYI the kernel I'm running is: 2.6.27.7-53.fc9.i686 #1 SMP and loaded rpms are: kernel-devel-2.6.27.7-53.fc9.i686 kernel-headers-2.6.27.7-53.fc9.i386 kernel-firmware-2.6.27.7-53.fc9.noarch kernel-2.6.27.7-53.fc9.i686 kernel-doc-2.6.27.7-53.fc9.noarch -- ===[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
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 (or was advised to) re-compile the kernel. > > There is a difference between applying a third party patch to the > kernel and specifying a compile time option which activates built in > code. > > I use a FreeBSD 5.3 Kernel in my Soekris NET4801 and also had to > specify the PPS option to get that feature. Thanks for that clarification, Steve. Let's hope tonight's leap second goes well. Cheers, David ___ 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 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 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,,2 >>(all MUST end with carriage return line feed) will disable all sentences. >>That doing >>PGRMO,GPRMC,1 >>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 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. OK, I give up. I have no idea why your are getting a 700ms 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
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 the kernel. There is a difference between applying a third party patch to the kernel and specifying a compile time option which activates built in code. I use a FreeBSD 5.3 Kernel in my Soekris NET4801 and also had to specify the PPS option to get that feature. -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ 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
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 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,,2 >(all MUST end with carriage return line feed) will disable all sentences. >That doing >PGRMO,GPRMC,1 >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 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
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 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 want to. Thanks. Yes, I had to recompile the FreeBSD kernel to include this patch. I must have thought at the time that it was mandatory, or was advised to do this. Cheers, David ___ 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
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? The OP does not and does not want to. > > The FreeBSD kernel does not need a "PPS patch". One merely has to > specify the PPS option at compile time. Thanks, Steve. 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 the kernel. Correct? The out-of-the-box FreeBSD would not have used the PPS data? Cheers, David ___ 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
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 want to. The FreeBSD kernel does not need a "PPS patch". One merely has to specify the PPS option at compile time. -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ 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
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 is no need to bend the requirements in order to produce a receiver that is TTL compatible. > respond to the 0,5 level that the PPS output actually delivers. There is > absolutely no reason why it should. That signal is completely out of spec. > If yours does work, it is because your serial port manufacturer severely > bent the rules. But many (most?) do. But it could well be that the serial > port is flakey on especially the 0V instead of -5 to -12 V end. > > The parallel port specs state that the signal levels are 0V and 5 V which > is exactly what the garmin delivers. They don't. On the driver side, they will have a 0 level that is at least 200mV. The 1 level will depend on whether the drivers are open collector or totem poll (which I'd have to look up). They will be based on TTL levels, even though modern drivers are CMOS. The receivers will have the standard TTL receiver performance. ___ 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 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,,2 (all MUST end with carriage return line feed) will disable all sentences. That doing PGRMO,GPRMC,1 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 at the end of the file, and then cutting and pasting into the minicom terminal program. ___ 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 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/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. 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 actually delivers. There is absolutely no reason why it should. That signal is completely out of spec. If yours does work, it is because your serial port manufacturer severely bent the rules. But many (most?) do. But it could well be that the serial port is flakey on especially the 0V instead of -5 to -12 V end. The parallel port specs state that the signal levels are 0V and 5 V which is exactly what the garmin delivers. ___ 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
"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 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 >George, >On my FreeBSD system, the ntpq -p output looks like this (some servers >omitted): > remote refid st t when poll reach delay offset >jitter >== >-utserv.mcc.ac.u 193.62.22.98 2 u 58 64 377 25.5483.732 >2.715 >*GPS_NMEA(1) .PPS.0 l 52 64 3770.0000.002 >0.008 >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 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 want to. ___ 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 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, and had to re-compile the kernel. driftfile /etc/ntp.drift # server 0.uk.pool.ntp.org iburst server 1.uk.pool.ntp.org iburst server 2.uk.pool.ntp.org iburst # # The GPS receiver on COM1 at 4800 baud # # mode 1 = use $GPRMC statements # time1 = trimming offset # flag3 1 = enable Kernel PPS discipline # server 127.127.20.1 mode 1 prefer fudge 127.127.20.1 time1 0.000 flag3 1 refid PPS Cheers, David ___ 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 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 in my Windows program:
// Switch off all output with by sending it the following string.
ComPort.WriteStr ('$PGRMO,,2' + #13 + #10);
// Now switch only $GPRMC on by sending it the following string.
ComPort.WriteStr ('$PGRMO,GPRMC,1' + #13 + #10);
Cheers,
David
___
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
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 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 > >George, > >On my FreeBSD system, the ntpq -p output looks like this (some servers >omitted): > > remote refid st t when poll reach delay offset >jitter >== >-utserv.mcc.ac.u 193.62.22.98 2 u 58 64 377 25.5483.732 >2.715 >*GPS_NMEA(1) .PPS.0 l 52 64 3770.0000.002 >0.008 > >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 my system picks up the PPS from >just the type 20 driver, and yours does not. > 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 ___ 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
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 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
>>>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 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. 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: The other possibility is that shmpps and gpsd are fighting over the serial port. Both are trying to read the lines and to grab the interrupt. It may be that gpsd is messing it up for shmpps. ># 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??? No idea, but I have offered a couple of possiblities. ___ 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 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 > == > 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 George, On my FreeBSD system, the ntpq -p output looks like this (some servers omitted): remote refid st t when poll reach delay offset jitter == -utserv.mcc.ac.u 193.62.22.98 2 u 58 64 377 25.5483.732 2.715 *GPS_NMEA(1) .PPS.0 l 52 64 3770.0000.002 0.008 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 my system picks up the PPS from just the type 20 driver, and yours does not. Cheers, David ___ 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
"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". >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. ___ 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 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: > [] >> 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) 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. >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 Looks to me like you could get rid of that offset with a fudge. >*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?? 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. >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
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, or you need to use the > parallel port instead, which takes 0-5V. You are technically correct, but I haven't found a serial port yet which doesn't work correctly when fed with 0..5V. Cheers, David ___ 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
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 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 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. ___ 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
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 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
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 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
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 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
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 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
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 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
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. Cheers, David ___ 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
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 ___ 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
>>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 could easily happen if the default edge to use is different in gpsd and ntpd. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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 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?? >> >>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. ___ 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 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 inserting an inverter into the hardware chain, or by setting the right fudge parameter (which, I think, has just been given in one of the other current threads). > > 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
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 that give the best solution on one axis may give an poor solution on another. ___ 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 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 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. Last I heard there were some 27 GPS satellites aloft! There are usually seven or eight above the horizon though some may not be very far above 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. I know the Garmin GPS18LVC only by reputation. I'm using a a Motorola receiver whose model designation I have forgotten. I think your best help/advice will come from another GPS18LVC user. ___ 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
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 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
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 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 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? >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
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 reach bit mask good enough > for that? The Generic NMEA ATOM driver silently uses the PPS signal. The reach bit mask is populated regardless of whether or not the PPS signal is present or used. And the ntpq peer billboard does not tell the user if the NMEA driver is using PPS or just the NMEA sentences. -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ 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 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! 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. ___ 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 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. ___ 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
>>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
"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 >> == >> 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! >I question the selection of servers! Round trip delays of 63, 72, 83, >and 105 milliseconds seem unreasonable to me! The uncertainty in the I believe he used the pool.ntp.org servers, so he has no choice. And besides if the PPS is working then the fact that those servers at 40ms away is really irrelevant (By the way, the accuracy I get from a server 40ms away as measured by the offset it 10 times better than that from one 5ms away. ) >time reported by a server may be as great as one half of the round trip It MAY be. But usually is not. >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! >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 have a GPS receiver, three internet servers should be >sufficient as backup and a sanity check for the GPS. Agreed. ___ 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
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 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
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
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 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! 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! 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 have a GPS receiver, three internet servers should be sufficient as backup and a sanity check for the GPS. ___ questions mailing list questions@lists.ntp.org http
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
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@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
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 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
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 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
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 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. Regards, Rob ___ 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
>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? Actually, there is a little more information. It checks each second, collects a batch of samples, and processes the batch when the poll routine is called. It would be slightly better to log a line in clockstats with a count of the batch size and/or maybe some quality indications. But that only matters if your setup is marginal. For anything simple/clean, it should be all or none. The reach bitmask will tell you if somebody has tripped over a cable. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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
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 PPS signal. -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ 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 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. >> >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 >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
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
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.isc.org - be a member! ___ 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
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), please do so. -- Harlan Stenn http://ntpforum.isc.org - be a member! ___ 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
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
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
"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 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 PPS signal is a simple wire driven by one end and only read in the >most rudimentary way by the other. You can easily wire it to another >detector. Configure the other NTP to accept a PPS signal just like the >first and it'll work. Well, not really. Each of the computers loads the signal line with about a 2K impendance, and the driver on the gps will run out of juice to deliver a sharp signal. Ie, the front edge will start to smear out. Now I have not done the tests to see how many could be run off the one PPS signal without distortion, so you might be right that it could handle one more. >As for the NMEA data, I'd be inclined to distribute it in standard >NTP format - just configure the stratum 1 server as a server in that >other NTP server. It needs to be certain about its second boundaries >to use its PPS source, but that doesn't need to come (directly) from >a hardware reference clock. >Groetjes, >Maarten Wiltink ___ 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 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, 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 Ah, you are NOT running the kernel PPS. You are running the shm refclock using the timing of the serial port driver. >> >>>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. >>> >>>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. >> >> >>>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. Your offset should settle down to about plus or minus .005 The offsets from the external sources are irrelevant ( as long as they are not greater than 500 or so-- 1/2 sec) >> >>># 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 t
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
"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 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 PPS signal is a simple wire driven by one end and only read in the most rudimentary way by the other. You can easily wire it to another detector. Configure the other NTP to accept a PPS signal just like the first and it'll work. As for the NMEA data, I'd be inclined to distribute it in standard NTP format - just configure the stratum 1 server as a server in that other NTP server. It needs to be certain about its second boundaries to use its PPS source, but that doesn't need to come (directly) from a hardware reference clock. Groetjes, Maarten Wiltink ___ 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 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
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
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 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. >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. 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. >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. >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
