Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
"Kelsey Cummings" <> wrote in message news:4b8c2822$0$1641$742ec...@news.sonic.net... David J Taylor wrote: As Bill comments, I hope your milliseconds are actually microseconds! Yes! == oGPS_NMEA(1) .GPS. 0 l 21 64 377 0.000 0.002 0.004 ... Thanks to everyone for helping me work through this. -K Phew, that's a relief, Kelsey! Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
David J Taylor wrote: As Bill comments, I hope your milliseconds are actually microseconds! Yes! == oGPS_NMEA(1) .GPS. 0 l 21 64 377 0.000 0.002 0.004 ... Thanks to everyone for helping me work through this. -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
David J Taylor wrote: ... > I would knock something up if there were enough interest, but it would > be a Windows program so of limited interest to the OP. That's the idea anyway. At the time, I was convinced the PPS signal was showing clearly and it was but with the led transistor in backwards the PPS line was getting pulled down to 1.4v or thereabouts. Not enough for the serial port to register it. It would have been useful to have something that just watched for the DCD pulse rather than trying to figure out what nptd was or was not seeing. With that fixed, everything synced right up. Seems reasonably stable with jitter at 4ms and offset fluctuating from -4ms to 4ms. More than good enough for our needs. -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
"Kelsey Cummings" wrote in message news:4b8b4844$0$1956$742ec...@news.sonic.net... David J Taylor wrote: ... I would knock something up if there were enough interest, but it would be a Windows program so of limited interest to the OP. That's the idea anyway. At the time, I was convinced the PPS signal was showing clearly and it was but with the led transistor in backwards the PPS line was getting pulled down to 1.4v or thereabouts. Not enough for the serial port to register it. It would have been useful to have something that just watched for the DCD pulse rather than trying to figure out what nptd was or was not seeing. With that fixed, everything synced right up. Seems reasonably stable with jitter at 4ms and offset fluctuating from -4ms to 4ms. More than good enough for our needs. -K In case it's some help, there's a simple serial port LED monitor program now available here: http://www.satsignal.eu/software/net.htm#SerialPortLEDs It works on my Windows XP system when run as Administrator - no other testing done, but reports are welcome. NTP must be stopped (and any other COM port program) while the tester is used. The DCD LED flashes white when a working GPS is connected. As Bill comments, I hope your milliseconds are actually microseconds! Even with Windows, I see well under 250 microseconds offset (depends on temperature, typically less then 50 microseconds) and less than 10 microseconds jitter (average 3 microseconds) on the XP stratum-1 server. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
In article <7v1k7ffip...@mid.individual.net>, David Lord wrote: > unruh wrote: > > On 2010-03-01, Kelsey Cummings wrote: > >> David J Taylor wrote: > >> ... > >>> I would knock something up if there were enough interest, but it would > >>> be a Windows program so of limited interest to the OP. > >> That's the idea anyway. At the time, I was convinced the PPS signal was > >> showing clearly and it was but with the led transistor in backwards the > >> PPS line was getting pulled down to 1.4v or thereabouts. Not enough for > > > > Hard to know how it would do that. > > Transistor inserted with reversed C/E have low Vce breakdown, > very low gain and possibly higher Vce_sat. They still operate > as transistors and long time ago I've used in that mode but I > can't remember what that was for (not so long after red spot > or white spot transistors were sold in a box of one which cost > a quid = eight weeks pocket money). Inverted bipolar transistors were widely used as choppers (in synchronous detectors), as the offset is lower in that configuration. Joe Gwinn ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
On 2010-03-01, Kelsey Cummings wrote: > David J Taylor wrote: > ... >> I would knock something up if there were enough interest, but it would >> be a Windows program so of limited interest to the OP. > > That's the idea anyway. At the time, I was convinced the PPS signal was > showing clearly and it was but with the led transistor in backwards the > PPS line was getting pulled down to 1.4v or thereabouts. Not enough for Hard to know how it would do that. > the serial port to register it. It would have been useful to have > something that just watched for the DCD pulse rather than trying to > figure out what nptd was or was not seeing. > > With that fixed, everything synced right up. Seems reasonably stable > with jitter at 4ms and offset fluctuating from -4ms to 4ms. More than > good enough for our needs. 4ms??? PPS from GPS should be 4usec, a thousand times better! (Or was that what you meant). You could set up whatever was reading the pps to record to syslog every time it received a pulse. > > -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
unruh wrote: On 2010-03-01, Kelsey Cummings wrote: David J Taylor wrote: ... I would knock something up if there were enough interest, but it would be a Windows program so of limited interest to the OP. That's the idea anyway. At the time, I was convinced the PPS signal was showing clearly and it was but with the led transistor in backwards the PPS line was getting pulled down to 1.4v or thereabouts. Not enough for Hard to know how it would do that. Transistor inserted with reversed C/E have low Vce breakdown, very low gain and possibly higher Vce_sat. They still operate as transistors and long time ago I've used in that mode but I can't remember what that was for (not so long after red spot or white spot transistors were sold in a box of one which cost a quid = eight weeks pocket money). David the serial port to register it. It would have been useful to have something that just watched for the DCD pulse rather than trying to figure out what nptd was or was not seeing. With that fixed, everything synced right up. Seems reasonably stable with jitter at 4ms and offset fluctuating from -4ms to 4ms. More than good enough for our needs. 4ms??? PPS from GPS should be 4usec, a thousand times better! (Or was that what you meant). You could set up whatever was reading the pps to record to syslog every time it received a pulse. -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
"David Lord" wrote in message news:7usc5dfhg...@mid.individual.net... [] I mentioned radioclkd(2) both of which in debug mode display state of selected pin (dcd cts dsr or rng). radioclkd -s poll -d -v ttyS00:dcd This gives time at each pulse edge. I'm sure there are other programs that do a better job for debugging serial data. For serial data on Windows, I've captured serial output by using second serial port and a two headed (9pin + 25pin at both ends) modem cable that splits the cable for you. David Thanks for that, David. I've used a similar cable that came with, IIRC, LapLink. I was really thinking of a program with an LED-style display, emulating a breakout box, but showing what was on the serial port (control) pins, sampling at 50Hz or so. It sounds as if something like this would be useful to answer the questions: - is my DCD connection showing a PPS signal? - does my USB connection, emulating a serial port over USB, also honour the DCD line? I would knock something up if there were enough interest, but it would be a Windows program so of limited interest to the OP. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
David J Taylor wrote: "David Lord" wrote in message news:7ur6r2fac...@mid.individual.net... [] Thing is there appears to be a problem with the PPS so I was suggesting a more sensitive circuit should a scope or moving coil meter not be available. David Isn't there software for the OS which emulates a breakout box and would give a simple indication of the DCD line or parallel port bit used? Obviously you may not be able to use such software at the same time as NTP, but it might be enough as a a test tool. For Windows, I could find: http://www.windmill.co.uk/serial.html http://www.taltech.com/freesoftware/breakout.htm http://www.sinnovations.com/htdocs/siscope_rs232_analyzer.htm although I've not used any of these, and some require two serial ports. I mentioned radioclkd(2) both of which in debug mode display state of selected pin (dcd cts dsr or rng). radioclkd -s poll -d -v ttyS00:dcd This gives time at each pulse edge. I'm sure there are other programs that do a better job for debugging serial data. For serial data on Windows, I've captured serial output by using second serial port and a two headed (9pin + 25pin at both ends) modem cable that splits the cable for you. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
"David Lord" wrote in message news:7ur6r2fac...@mid.individual.net... [] Thing is there appears to be a problem with the PPS so I was suggesting a more sensitive circuit should a scope or moving coil meter not be available. David Isn't there software for the OS which emulates a breakout box and would give a simple indication of the DCD line or parallel port bit used? Obviously you may not be able to use such software at the same time as NTP, but it might be enough as a a test tool. For Windows, I could find: http://www.windmill.co.uk/serial.html http://www.taltech.com/freesoftware/breakout.htm http://www.sinnovations.com/htdocs/siscope_rs232_analyzer.htm although I've not used any of these, and some require two serial ports. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
unruh wrote: On 2010-02-26, David Lord wrote: David J Taylor wrote: Is there any other way to watch the signal to see if it's reaching the serial port correctly? I would use my 'scope, but even an analogue voltmeter might work - see a regular flick of the needle. I built the equivalent of a simple break-out box into my two connections, one in the RS232 DB-9 plug itself: I checked pps from MSF rx with digital meter and that showed a signal but not very well. That has a 50ms pulse so 100ms from Garmin should be as easy to spot. Analogue meters I have around would give a much better indication. Another alternative is a transistor + three resistors and LED. A pot could be used for R2 to confirm voltage swing of PPS output. +5V -- R3 --- LED ---+ | c pps --- R1 ---+--- b | e R2 | | | 0V --+--+ No need for any of the resistors except R3. but you do not really need the transistor, since the PPS line should source enough current to run the led. Ie, just PPS -- R3 ---LED-- | | Gnd--- should do it, with R3 being about 1K I would not advise this as a permanant setup but for testing it should be fine. In my universe ttl could sink about 4mA but only source about 1.6mA vs 8mA/0.4mA for LS-ttl so more appropriate circuit would be to have pps output sinking current from the LED with resistor from +5V. Thing is there appears to be a problem with the PPS so I was suggesting a more sensitive circuit should a scope or moving coil meter not be available. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
On 2010-02-26, David Lord wrote: > David J Taylor wrote: >>> Is there any other way to watch the signal to see if it's reaching the >>> serial port correctly? >> >> I would use my 'scope, but even an analogue voltmeter might work - see a >> regular flick of the needle. I built the equivalent of a simple >> break-out box into my two connections, one in the RS232 DB-9 plug itself: >> > > I checked pps from MSF rx with digital meter and that showed a > signal but not very well. That has a 50ms pulse so 100ms from > Garmin should be as easy to spot. Analogue meters I have around > would give a much better indication. > > Another alternative is a transistor + three resistors and > LED. A pot could be used for R2 to confirm voltage swing > of PPS output. > > +5V -- R3 --- LED ---+ > | > c > pps --- R1 ---+--- b >| e >R2 | >| | > 0V --+--+ > No need for any of the resistors except R3. but you do not really need the transistor, since the PPS line should source enough current to run the led. Ie, just PPS -- R3 ---LED-- | | Gnd--- should do it, with R3 being about 1K I would not advise this as a permanant setup but for testing it should be fine. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Terje Mathisen wrote: Kelsey Cummings wrote: Rob wrote: This is normal with NMEA. You never will get stable time when using an NMEA time source. For that, you need PPS. Your PPS is apparently not working. It feels like I must be missing something here, running with -d I can confirm that PPS doesn't appear to be working - after enabling flag3 as well. 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 041d 0d kern PPS enabled 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 042d 0d kern PPS no signal ... Which flags are you using? I had to change my setup after compiling the latest ntp-dev code base. Terje I can't help thinking that it's a poor policy to allow upgrades to break something that works! OTOH, there usually are "release notes" for a new release to tell you what's new, what's changed/broken, etc. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
David J Taylor wrote: "David Lord" wrote in message news:7upjodf9s...@mid.individual.net... [] I checked pps from MSF rx with digital meter and that showed a signal but not very well. That has a 50ms pulse so 100ms from Garmin should be as easy to spot. Analogue meters I have around would give a much better indication. Another alternative is a transistor + three resistors and LED. A pot could be used for R2 to confirm voltage swing of PPS output. +5V -- R3 --- LED ---+ | c pps --- R1 ---+--- b | e R2 | | | 0V --+--+ David On the GPS-18 devices here, I found that an LED and 1K5 resistor alone were adequate to indicate the PPS signal, and it pulled down the voltage hardly at all. You could even hand hold the resistor and LED across the relevant RS232 pins (PPS/DCD and ground). I used a low-current LED for a brighter display. Yours is the better way, as it loads the GPS a little less, and I know we have had discussions about exact signal levels before. When I had very good results from MSF + PPS in June last year I used an isolated power supply and had output GND offset slightly positive to circuit 0V so the pulldown was to below 0V. I can't remember how much offset, I doubt any more than 1V. It's possible I used same for the Garmin when that gave good results with pps to serial DCD. Currently with output GND = GPS 0V, I've been unable to get same useful low offsets from serial connected pps but parallel connection gives 2 day average for offset 0.000ms and jitter 0.002ms. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
"David Lord" wrote in message news:7upjodf9s...@mid.individual.net... [] I checked pps from MSF rx with digital meter and that showed a signal but not very well. That has a 50ms pulse so 100ms from Garmin should be as easy to spot. Analogue meters I have around would give a much better indication. Another alternative is a transistor + three resistors and LED. A pot could be used for R2 to confirm voltage swing of PPS output. +5V -- R3 --- LED ---+ | c pps --- R1 ---+--- b | e R2 | | | 0V --+--+ David On the GPS-18 devices here, I found that an LED and 1K5 resistor alone were adequate to indicate the PPS signal, and it pulled down the voltage hardly at all. You could even hand hold the resistor and LED across the relevant RS232 pins (PPS/DCD and ground). I used a low-current LED for a brighter display. Yours is the better way, as it loads the GPS a little less, and I know we have had discussions about exact signal levels before. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
David J Taylor wrote: Is there any other way to watch the signal to see if it's reaching the serial port correctly? I would use my 'scope, but even an analogue voltmeter might work - see a regular flick of the needle. I built the equivalent of a simple break-out box into my two connections, one in the RS232 DB-9 plug itself: I checked pps from MSF rx with digital meter and that showed a signal but not very well. That has a 50ms pulse so 100ms from Garmin should be as easy to spot. Analogue meters I have around would give a much better indication. Another alternative is a transistor + three resistors and LED. A pot could be used for R2 to confirm voltage swing of PPS output. +5V -- R3 --- LED ---+ | c pps --- R1 ---+--- b | e R2 | | | 0V --+--+ David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: Rob wrote: This is normal with NMEA. You never will get stable time when using an NMEA time source. For that, you need PPS. Your PPS is apparently not working. It feels like I must be missing something here, running with -d I can confirm that PPS doesn't appear to be working - after enabling flag3 as well. 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 041d 0d kern PPS enabled 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 042d 0d kern PPS no signal ... Which flags are you using? I had to change my setup after compiling the latest ntp-dev code base. Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Is there any other way to watch the signal to see if it's reaching the serial port correctly? I would use my 'scope, but even an analogue voltmeter might work - see a regular flick of the needle. I built the equivalent of a simple break-out box into my two connections, one in the RS232 DB-9 plug itself: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#connect Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: Rob wrote: This is normal with NMEA. You never will get stable time when using an NMEA time source. For that, you need PPS. Your PPS is apparently not working. It feels like I must be missing something here, running with -d I can confirm that PPS doesn't appear to be working - after enabling flag3 as well. 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 041d 0d kern PPS enabled 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 042d 0d kern PPS no signal .. Is there any other way to watch the signal to see if it's reaching the serial port correctly? -K There is a device called a "breakout box" that can be connected to a serial device and a serial port. It will make all twenty-five pins available for testing. If you have only nine pins you'll need an adapter. The more expensive devices will use bipolar LEDs to display the status of each pin. Some will allow you to drive pins high or low. You can probably pick one up on e-Bay for a not TOO outrageous price. Don't pay big bucks for one, 99% of the time you'll use it as a paper weight or some such humble task. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: Rob wrote: This is normal with NMEA. You never will get stable time when using an NMEA time source. For that, you need PPS. Your PPS is apparently not working. It feels like I must be missing something here, running with -d I can confirm that PPS doesn't appear to be working - after enabling flag3 as well. 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 041d 0d kern PPS enabled 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 042d 0d kern PPS no signal .. Is there any other way to watch the signal to see if it's reaching the serial port correctly? I've used radioclkd2 to setup my pulse stretcher and pps ouput pulse length from MSF. I wasn't able to do this with any accuracy using a scope. Intended purpose is decode of DCF77 and MSF which it does very well here from both Linux or NetBSD. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
On 2010-02-25, Kelsey Cummings wrote: > Rob wrote: >> This is normal with NMEA. You never will get stable time when using >> an NMEA time source. For that, you need PPS. Your PPS is apparently >> not working. > > It feels like I must be missing something here, running with -d I can > confirm that PPS doesn't appear to be working - after enabling flag3 as > well. > > 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 041d 0d kern PPS enabled > 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 042d 0d kern PPS no signal > .. > > Is there any other way to watch the signal to see if it's reaching the > serial port correctly? gpsd watches the serial interrupt. If you also have the kernel watching the interrupt, things might get confused. > > -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: > Rob wrote: >> This is normal with NMEA. You never will get stable time when using >> an NMEA time source. For that, you need PPS. Your PPS is apparently >> not working. > > It feels like I must be missing something here, running with -d I can > confirm that PPS doesn't appear to be working - after enabling flag3 as > well. > > 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 041d 0d kern PPS enabled > 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 042d 0d kern PPS no signal > .. > > Is there any other way to watch the signal to see if it's reaching the > serial port correctly? Sure, just use an RS232 LED box. They used to be very commonly available when RS232 was widely used. Probably a bit harder to get today. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Rob wrote: This is normal with NMEA. You never will get stable time when using an NMEA time source. For that, you need PPS. Your PPS is apparently not working. It feels like I must be missing something here, running with -d I can confirm that PPS doesn't appear to be working - after enabling flag3 as well. 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 041d 0d kern PPS enabled 25 Feb 13:53:21 ntpd[75656]: 0.0.0.0 042d 0d kern PPS no signal .. Is there any other way to watch the signal to see if it's reaching the serial port correctly? -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: > Hal Murray wrote: >> How about turning off the PPS fudge flag so you know you are >> using the text mode. Then watch it for a while and add a >> fudge time2 to get it reasonably close. When that works, >> turn the PPS back on. > > I added time2 to zero out the offset and things looked good for about an > hour. Then the offset jumps 55ms and the GPS deselected. This is normal with NMEA. You never will get stable time when using an NMEA time source. For that, you need PPS. Your PPS is apparently not working. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Hal Murray wrote: How about turning off the PPS fudge flag so you know you are using the text mode. Then watch it for a while and add a fudge time2 to get it reasonably close. When that works, turn the PPS back on. I added time2 to zero out the offset and things looked good for about an hour. Then the offset jumps 55ms and the GPS deselected. An updated graph http://kgc.users.sonic.net/ntp_127_127_20_1-day.png -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: David J Taylor wrote: The reach = 0 suggests that the signals from the GPS are not being seen. I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm guessing you aren't seeing pps. My notes from last year might have been understandable then but best I can decode from them is # ntp.conf # gps0 -> /dev/tty00 # pps0 -> /dev/tty00 server 127.127.20.0 mode 1 prefer # NMEA $GPRMC That was giving offset of about 70us. ATOM driver and pps to serial DCD gave offset < 10us I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. I'm not sure that's a good idea since rs232 is current driven/voltage triggered with a relative low input resistance depending on spec of interface. Having an LED+series resistor load might give a better pullup. Having said that, I can't remember what interface circuit if any I was using last year. Last check was with pps of my 18x-LVC direct to NACK of parallel port without any extra components. #ntp.conf # mknod pps0 164 0 /dev/pps0 tos mindist 0.4 # I could reduce this now server 127.127.20.0 mode 1 prefer fudge 127.127.20.0 time1 0.651 refid GPSb server 127.127.22.0 minpoll 4 maxpoll 6 fudge 127.127.22.0 refid PPSb flag3 1 server serv1 server serv2 server serv3 On a good day above cfg was giving offset = 0.000, jitter = 0.002. NMEA offset/jitter are then very erratic in order of 10s of ms. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: David J Taylor wrote: The reach = 0 suggests that the signals from the GPS are not being seen. I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. -K I'm guessing you aren't seeing pps. My notes from last year might have been understandable then but best I can decode from them now is: # ntp.conf gps-18x-LVC # gps0 -> /dev/tty00 # pps0 -> /dev/tty00 server 127.127.20.0 mode 1 prefer # NMEA $GPRMC That was giving offset of about 70us. No LED, just using pps direct to serial DCD. I'm still suspicious cmos ttl out from the 18x-LVC might not be good at driving rs232 as it requires at least 3mA/0.7V pulldown. ATOM driver and pps to serial DCD gave offset < 10us Last check was with pps of my 18x-LVC direct to NACK of parallel port without any extra components. #ntp.conf # mknod pps0 164 0 /dev/pps0 tos mindist 0.4 # I could reduce this now server 127.127.20.0 mode 1 prefer fudge 127.127.20.0 time1 0.651 refid GPSb server 127.127.22.0 minpoll 4 maxpoll 6 fudge 127.127.22.0 refid PPSb flag3 1 server serv1 server serv2 server serv3 On a good day above cfg was giving offset = 0.000, jitter = 0.002. NMEA offset/jitter are then very erratic in order of 10s of ms. Note for above I needed "fudge time1" and/or "tos mindist" otherwise NMEA was deselected. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
In article <4b8580e5$0$1616$742ec...@news.sonic.net>, Kelsey Cummings writes: >I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 >from the ntp-dev port. > >I'm still seeing high offset and variable jitter. > >== >xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 >-time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 >*clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 The NMEA driver is a bit strange. It processes two sources of time. One is the text on the serial port. The other is the PPS signal. I think it has to get close enough on the text mode before the PPS processing kicks in. How about turning off the PPS fudge flag so you know you are using the text mode. Then watch it for a while and add a fudge time2 to get it reasonably close. When that works, turn the PPS back on. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
"Kelsey Cummings" wrote in message news:4b8580e5$0$1616$742ec...@news.sonic.net... [] I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. -K Kelsey, at least you now have a reach of 377 for the GPS! The offset of -300ms suggests to me that you could be syncing on the wrong edge of the PPS signal. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
David J Taylor wrote: The reach = 0 suggests that the signals from the GPS are not being seen. I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
On 2010-02-22, Kelsey Cummings wrote: > FreeBSD 8.0, with built in ntpd (4.2.4p5) and PPS_SYNC enabled with a > Garmic 18LVC. > > Using the following options: > > server 127.127.20.1mode 0 minpoll 4 maxpoll 4 prefer > fudge 127.127.20.1flag1 1 flag3 1 refid GPS > server 0.pool.ntp.org iburst maxpoll 9 > server 1.pool.ntp.org iburst maxpoll 9 > server 2.pool.ntp.org iburst maxpoll 9 > server 3.pool.ntp.org iburst maxpoll 9 > > Is resulting in: > > remote refid st t when poll reach delay offset > jitter >== > GPS_NMEA(1) .GPS.0 l 66h 1600.000 -192.53 > 27.455 > *216.45.57.38209.81.9.7 2 u 469 512 377 11.9902.871 > 0.449 > -tantalum.srvcs. 192.43.244.182 u 336 512 377 76.924 -29.311 > 2.300 > +208.96.18.74.se 199.212.17.353 u 339 512 3774.7924.906 > 1.466 > +mirror 204.9.54.119 2 u 283 512 377 86.5629.086 > 2.488 > > The -192.52 and 27.455 stats for the GPS have been constant for 72+ > hours now. Any suggestions as to what the problem could be? Your system is not receiving any timing data from the GPS (reach 0). It is relying on the other sources. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
"Kelsey Cummings" wrote in message news:4b82dea9$0$1636$742ec...@news.sonic.net... [] remote refid st t when poll reach delay offset jitter == GPS_NMEA(1) .GPS.0 l 66h 1600.000 -192.53 27.455 The reach = 0 suggests that the signals from the GPS are not being seen. Check the logs. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: FreeBSD 8.0, with built in ntpd (4.2.4p5) and PPS_SYNC enabled with a Garmic 18LVC. I'm going to go install the devel version to see if this issue persists. Serves me right not to notice the most recent thread. ;) -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
