[ntp:questions] Result of Earth Quake speeds up earth?
Hello, Firstly may I just say, my thoughts are with members of this list who are in Japan. Just a bit of an odd question... I hear in the Media that the earth quake sped the rotation of the earth up.. Can anyone confirm this? Does this mean that we will not need to 'insert leap seconds' for a while, or does it mean that we will need to retract leap seconds that have been added? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] LTC Timecode Generator
Hello, Does anyone have any info on how if possible to make a Linux computer, synced to GPS become an LTC (Broadcast EBU SMTPE) master clock generator? I have a bunch of LTC equipment, time code master, and slave clocks around the house, and would like to get my NTP GPS machine, output the LTC audio to put into the master. Anyone done something similar or is this not really possible? Thanks in advance... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS
With Selective Availability enabled would that cause time accuracy issues with the signals from the satellite? Or are they independent of each other? On Mon, 2010-10-04 at 18:40 +0100, David Woolley wrote: > binh tran thanh wrote: > > Hello,i'm from Viet Nam > > Now i'm using GPS et333 > > do u can explain for me the meaning (in GPGGA): > > - position fix indicator > > - hdop > > -checksum > > -how to know the acurate of GPS's signal > > None of the above. Generally, for the purposes of ntpd, the GPS time > transfer error is dominated by errors outside of the GPS system and you > need to analyse your own system to determine them. > > Even for position purposes, if the US were ever to turn on selective > availability again, the error would increase without any of the error > indicators increasing. > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] My Palisade Issues resolved + Checking Stability and accuracy :)
Hello, For anyone who has been following my questions, my palisade issues seem to have been corrected now. Just had to make a bit of a patch to the refclock_palisade.c driver, and send a character to the device, for hardware polling.. We suspect that perhaps my RS422 to RS232 adaptors might not set RTS or CTS high without data being present... Here is my ntpq info -=- could anyone please have a bit of a look at the following and tell me if my ref_clock is working, and how accurate it it.. and now how I can tell how 'stable' the clock is. If I have not given you enough info please just let me know what you need, and I will be more than happy to supply :) ntpq> cv assID=0 status= clk_okay, last_clk_okay, device="Trimble Palisade GPS", timecode="2010 270 21:51:59.428172", poll=2787, noreply=0, badformat=0, baddata=0, fudgetime1=0.000, stratum=0, refid=GPS, flags=0 ntpq> ntpq> rl assID=0 status=0444 leap_none, sync_uhf_clock, 4 events, event_peer/strat_chg, version="ntpd 4.2@1.1612-o Sat Sep 25 09:09:32 UTC 2010 (5)", processor="i686", system="Linux/2.6.35-19-generic", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdispersion=1.304, peer=22353, refid=GPS, reftime=d04b90c2.78d743cb Tue, Sep 28 2010 10:53:06.472, poll=5, clock=d04b90c4.a6ec8d02 Tue, Sep 28 2010 10:53:08.652, state=4, offset=-0.084, frequency=15.280, jitter=0.729, noise=0.489, stability=0.022, tai=0 ntpq> ntpq> rv assID=0 status=0444 leap_none, sync_uhf_clock, 4 events, event_peer/strat_chg, version="ntpd 4.2@1.1612-o Sat Sep 25 09:09:32 UTC 2010 (5)", processor="i686", system="Linux/2.6.35-19-generic", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdispersion=1.514, peer=22353, refid=GPS, reftime=d04b90c2.78d743cb Tue, Sep 28 2010 10:53:06.472, poll=5, clock=d04b90d2.b5417013 Tue, Sep 28 2010 10:53:22.708, state=4, offset=-0.084, frequency=15.280, jitter=0.729, noise=0.489, stability=0.022, tai=0 ntpq> ntpq> peers remote refid st t when poll reach delay offset jitter == -warrane.connect 192.94.41.1303 u 35 64 377 34.5111.586 0.602 -caffeine.cc.com 203.209.212.98 3 u 30 64 377 64.355 -7.665 4.964 -pond.thecave.ws 18.26.4.105 2 u 27 64 377 85.675 -2.443 0.314 xns.creativecont 121.0.0.41 3 u 39 64 377 51.255 -23.593 13.578 -tur-dmz2.massey 131.203.16.102 u 28 64 377 15.2980.769 0.500 +msltime.irl.cri .ATOM. 1 u 43 64 377 18.728 -1.113 0.389 +msltime2.irl.cr .ATOM. 1 u5 64 377 18.158 -0.950 0.599 *GPS_PALISADE(0) .GPS.0 l 13 16 3770.0000.306 0.056 ntpq> ind assID status conf reach auth condition last_event cnt === 1 22346 9314 yes yes none outlyer reachable 1 2 22347 9314 yes yes none outlyer reachable 1 3 22348 9314 yes yes none outlyer reachable 1 4 22349 9114 yes yes none falsetick reachable 1 5 22350 9314 yes yes none outlyer reachable 1 6 22351 9414 yes yes none candidat reachable 1 7 22352 9414 yes yes none candidat reachable 1 8 22353 9614 yes yes none sys.peer reachable 1 ntpq> ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Palisade Reference Clock
If I do this while running ntpd while true = '1'; do echo " " > /dev/ttyS0 sleep 10; done I get: addto_syslog: select(): nfound=-1, error: Interrupted system call addto_syslog: select(): nfound=-1, error: Interrupted system call addto_syslog: select(): nfound=-1, error: Interrupted system call addto_syslog: select(): nfound=-1, error: Interrupted system call refclock_transmit: at 31241 127.127.29.0 palisade_poll: unit 0: polling event poll_update: at 31241 127.127.29.0 flags 1061 poll 4 burst 0 last 31241 next 31256 TSIP_decode: unit 0: AD #46172 21:42:23.744922011 09/01/2010 UTC 01 Overdet Clock palisade_receive: unit 0: 2010 244 21:42:23.744922011 palisade_receive: unit 0: d029473f.bfa906dc Wed, Sep 1 2010 17:42:23.748 refclock_receive: at 31241 127.127.29.0 refclock_sample: n 1 offset -0.003751 disp 0.00 jitter 0.01 clock_filter: n 8 off -0.003751 del 0.00 dsp 0.000239 jit 0.011053, age 0 select: endpoint -1 -0.017543 select: endpoint 0 -0.003751 select: endpoint 1 0.010041 cluster: survivor 127.127.29.0 metric 0.013792 select: combine offset -0.003751 poll_update: at 31241 127.127.29.0 flags 1061 poll 4 burst 0 last 31241 next 31257 clock_update: at 31241 assoc 1 local_clock: assocID 30926 offset -0.003750883 freq -19.662 state 4 local_clock: time 31241 offset -0.003751 freq -19.662 state 4 local_clock: mu 17 jitr 0.019875 freq -19.905 stab 0.754067 poll 5 count 30 addto_syslog: select(): nfound=-1, error: Interrupted system call addto_syslog: select(): nfound=-1, error: Interrupted system call addto_syslog: select(): nfound=-1, error: Interrupted system call And from what ntp says, its now the sys.peer and reachable. event is clk_ok Without the echo into /dev/ttyS0 I get the following: ddto_syslog: select(): nfound=-1, error: Interrupted system call refclock_transmit: at 367 127.127.29.0 palisade_poll: unit 0: polling event poll_update: at 367 127.127.29.0 flags 1061 poll 4 burst 0 last 367 next 382 addto_syslog: select(): nfound=-1, error: Interrupted system call addto_syslog: select(): nfound=-1, error: Interrupted system call and it never either brings the RTS or CTS line up, and so the packet is never sent back to the ntp server. I am not the worlds best coder, so I am not really sure what I am doing to the driver. Another machine is syncing to this server, and I notice I am getting 'falsetick' is reported in ntpq associations on the remote computer. Thanks in advance :) On Wed, 2010-09-01 at 12:54 -0400, Marc Leclerc wrote: > Have you looked at both firmware docs to insure that there is no > changes in the packet data. > > I had to play with this driver to talk to a resolution SMT and just a > few changes in bits definition gave me > the same error. the driver will fail even if the error is from another > packet (secondary time or such) > > hth > > > > On 2010-08-31 06:17, Chris H wrote: > >> We have an Acutime 2000, which has pretty much just worked since we bought > >> it in 2005. We haven't felt the urge to do anything to the firmware, and > >> I've no idea what it's running -- whatever was current at the time. > > Just looking at the bug fixes between 7.02 and 7.12, I thought it was a > > good idea to upgrade... now I regret it :( hence my request from anyone > > to get 7.10 firmware again. > > > > > >> Have you tried running the (Windows-only?) configuration tool? What does > >> it > >> say about the acutime? Remember to run it on the *other* RS232 port on the > >> bottom-end converter box from the one you normally connect ntpd to. > > Yeha -- everything is working correctly, both ports are giving data. > > > >> Have you tried running the daemon in debugging mode, per the driver29.html > >> page? What does that say? We found that quite useful on the one occasion > >> where we had any problem with our unit. > > I still get clk_noreply... :( > > > >> The only occasion that I recall having any problems at all was when we > >> replaced the linux host with a faster machine, and we came to the > >> conclusion that either the serial hardware was "different" or the new box > >> was simply now pulsing the timestamp-me line too quickly. As a quick hack > >> workaround I simply duplicated the two ioctl()s in the driver which toggled > >> the relevant control line. It might be worth checking whether there's > >> anything in the code like that... > > > > I have been leant a Serial Port Analyser.. > > HP4925A > > > > I can see the pulse per second coming into the unit, and I can see the > > data on the screen. > > > > When I run palisade_monitor or tsipchat or anything, the whole thing > > comes to li
Re: [ntp:questions] Palisade Reference Clock
I think I was too excited too soon. First packet appeared, subsequent packets failed :) On Wed, 2010-09-01 at 19:14 +1200, Chris H wrote: > https://support.ntp.org/bugs/show_bug.cgi?id=1075 > > Appears to have fixed the problem.. > > The PPS Width is too small, and this patch / bug report, fixes the > issue :) > > > > On Tue, 2010-08-31 at 11:34 +0100, George Ross wrote: > > > > Have you tried running the daemon in debugging mode, per the > > > > driver29.html > > > > page? What does that say? We found that quite useful on the one > > > > occasion > > > > where we had any problem with our unit. > > > > > > I still get clk_noreply... :( > > > > You should see the driver logging what it's doing though, which might help > > narrow down where the problem is. (You might have to rebuild the daemon > > with DEBUG turned on, if it isn't already.) As I said, we found this > > pretty useful. refclock_palisade.c is the place to look to see what it all > > means. > > > > > I have been leant a Serial Port Analyser.. > > > HP4925A > > > > > > I can see the pulse per second coming into the unit, and I can see the > > > data on the screen. > > > > You should see the daemon toggling RTS, and you should see the clock > > sending back its timestamp in response. > > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Palisade Reference Clock
https://support.ntp.org/bugs/show_bug.cgi?id=1075 Appears to have fixed the problem.. The PPS Width is too small, and this patch / bug report, fixes the issue :) On Tue, 2010-08-31 at 11:34 +0100, George Ross wrote: > > > Have you tried running the daemon in debugging mode, per the > > > driver29.html > > > page? What does that say? We found that quite useful on the one > > > occasion > > > where we had any problem with our unit. > > > > I still get clk_noreply... :( > > You should see the driver logging what it's doing though, which might help > narrow down where the problem is. (You might have to rebuild the daemon > with DEBUG turned on, if it isn't already.) As I said, we found this > pretty useful. refclock_palisade.c is the place to look to see what it all > means. > > > I have been leant a Serial Port Analyser.. > > HP4925A > > > > I can see the pulse per second coming into the unit, and I can see the > > data on the screen. > > You should see the daemon toggling RTS, and you should see the clock > sending back its timestamp in response. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Palisade Reference Clock
> We have an Acutime 2000, which has pretty much just worked since we bought > it in 2005. We haven't felt the urge to do anything to the firmware, and > I've no idea what it's running -- whatever was current at the time. Just looking at the bug fixes between 7.02 and 7.12, I thought it was a good idea to upgrade... now I regret it :( hence my request from anyone to get 7.10 firmware again. > Have you tried running the (Windows-only?) configuration tool? What does it > say about the acutime? Remember to run it on the *other* RS232 port on the > bottom-end converter box from the one you normally connect ntpd to. Yeha -- everything is working correctly, both ports are giving data. > Have you tried running the daemon in debugging mode, per the driver29.html > page? What does that say? We found that quite useful on the one occasion > where we had any problem with our unit. I still get clk_noreply... :( > The only occasion that I recall having any problems at all was when we > replaced the linux host with a faster machine, and we came to the > conclusion that either the serial hardware was "different" or the new box > was simply now pulsing the timestamp-me line too quickly. As a quick hack > workaround I simply duplicated the two ioctl()s in the driver which toggled > the relevant control line. It might be worth checking whether there's > anything in the code like that... I have been leant a Serial Port Analyser.. HP4925A I can see the pulse per second coming into the unit, and I can see the data on the screen. When I run palisade_monitor or tsipchat or anything, the whole thing comes to life, both DTE and DCE all go green, and I can see packet flow in both directions... however when ntp is running, it appears the comm port does not 'become active' like it does when running tsipchat or palisade_monitor, or anything like that.. And all I can see in inbound RD light blink green. When I run palisade_monitor.exe and select Port A and select View/Diagnostics and click Update, I can see RTS (on DTE side) and CTS (On DCE side) go from green to red. When I click up the update button, I can see the green link blink, but cant see the output packets on the analyser.. I will keep looking, but if anyone else has experience with the HP analyser, and used one to diagnose problems, please let me know too :) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Palisade Reference Clock
Hello group. I am new to Reference Clocks, and I am just simply stumped now. I have a Palisade smart antenna, with firmware version 7.12 (I did an upgrade from the Trimble website). Previous to this I had 7.10, and it worked correctly, my model number is 26664-10 so I am able to have event trigger. Now I am just getting ckl_noreply My /etc/ntpd.conf is as follows: server 127.127.29.0 prefer# Trimble acutime 2000 fudge 127.127.29.0 stratum 1 fudge 127.127.29.0 time1 0.020 #fudge 127.127.29.0 flag2 1 No matter what if I have fag2 on or off, I still get clk_noreply. If I look at /dev/palisade0 in minicom, I can see data being displayed every second, so the unit is pushing out data but either ntpd cant see it, or it does not like it. I have noticed that sometimes after being in minicom, and relooking at ntpq and going 'cv' I see 'clk_baddata' or 'clk_badformat' but then after a few seconds, it goes back to 'clk_noreply'. In minicom when I press 'space' or any other character, I get extra data displayed, or repeated data - so assume that my RS232 to RS422 adaptor is working correctly. IE: when I have set it to output NMEA I get repeated NMEA messages and see the second change... I also notice it seems to change to 8-n-1 from 8-odd-1 so thought I would change to 'mode 2' on the server line, but still no go. Can anyone please point me in the right direction. I really want to be included in the ntp pool, but just cant for the life of me get this to work :( Thanks in advance.. Chris. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
