[ntp:questions] Trimble Resolution T
Hi! Anyone here used a Trimble Resolution T with NTP? Which driver should be used? I believe driver #29 (Trimble Palisade and Thunderbolt Receivers) should work but any previous experience from other would be appreciated. Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trimble Resolution T
On Sun, 16 Oct 2011, Miguel Gonçalves wrote: On 16 October 2011 19:10, unruh un...@physics.ubc.ca wrote: In comp.protocols.time.ntp, you wrote: Hi! Anyone here used a Trimble Resolution T with NTP? From the pictures (all of the data sheets give a java error-- why in the world they couldn't just deliver a pdf file I do not know) it would seem that all it has is a PPS output on a coax cable. Thus you would want to hook that up to your parallel or serial port and use on the PPS devices to deliver the second mark to your computer. (gpsd, shmpps, kernel PPS) Thanks! I just opened the PDF data sheet in my safari browser in Mac OS X 10.7... I guess they had problems today. A short while later I got a page not available response instead of a java error. Anyway... PPS is easy... what about second numbering? From some of the other documentation I could read, it appears that it does deliver the seconds numbering over a usb connection. While usb is terrible for accurate timing, since the timing requirement of the seconds numbering is only about 1 second precision, usb should be fine. Now, I do not know what the format is. If it is nmea then something like gpsd should be fine, and be able to read both. If it is a proprietary protocol, then I have no idea. If you want to make use of the sawtooth correction (to get the time down to a few nsec) then that will almost certainly be proprietary. However, if you are feeding the timing into a computer, which you almost certainly are, it cannot handle anything near ns anyway, and for usec, the uncorrected pulse should be fine. Just remember to terminate the line to your input with the termination impedance of the cable you are using to get rid of ringing. While that ringing should not cause troubles better to be safe. Cheers, Miguel -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS time1 and reported offset
On 10/13/2011 17:38, Dave Hart wrote: On Thu, Oct 13, 2011 at 22:57, A Cagcarver+...@acarver.net wrote: I already had a GPS setup as PPS(1) and system offset was mostly zero +/- a few microseconds. Right, I get the same thing if I don't set time1 at all. When I do set time1 I get the value of time1 plus or minus some microseconds as an offset that is always displayed in the peer list. It never settles out to zero like all the other clock drivers do even when they have a time offset set on the fudge line. I am pretty sure you can fix this by disabling kernel PPS sync, that is, by not using flag3 1. PPSAPI provides a way to pass a fudge (offset) to be applied to PPS timestamps, but the common PPSAPI code in ntpd used by the PPS and NMEA drivers (among others) does not use it. As a result, when you enable so-called hardpps, where the kernel disciplines its clock directly to the PPS, the time1 fudge is not used by the kernel hardpps. Once you verify things behave as expected without flag3 1, please file a bug report at http://bugs.ntp.org/ noting the incompatibility of flag3 1 and time1. This test without flag3 will have to wait a little bit. I'm still trying to debug a system lockup that may be related to ntpd when it is being polled for peer status by ntpq from a remote host. I'll probably be posting about that in a few days though the short summary is that polling ntpd once every five seconds from a remote machine (using ntpq) caused the ntpd system to completely freeze after about 20 hours. I stopped the ntpq polling and so far the machine has been up for a week without a problem. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trimble Resolution T
OK, can now get the datasheets, and it apparently does have a serial port The pulse is 3.3V so should be ok to run most serial port interrupts. It gets nmea but the control of the nmea seems to be via their proprietary language. So If you could switch the receiver into nmea befor it is grabbed by the program, like gpsd or shmpps, then using them to control ntp should be fine. Otherwise I have never used trimble proprietary language so have no idea what driver to use. On Sun, 16 Oct 2011, Miguel Gonçalves wrote: On 16 October 2011 19:10, unruh un...@physics.ubc.ca wrote: In comp.protocols.time.ntp, you wrote: Hi! Anyone here used a Trimble Resolution T with NTP? From the pictures (all of the data sheets give a java error-- why in the world they couldn't just deliver a pdf file I do not know) it would seem that all it has is a PPS output on a coax cable. Thus you would want to hook that up to your parallel or serial port and use on the PPS devices to deliver the second mark to your computer. (gpsd, shmpps, kernel PPS) Thanks! I just opened the PDF data sheet in my safari browser in Mac OS X 10.7... Anyway... PPS is easy... what about second numbering? Cheers, Miguel -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS time1 and reported offset
On Sun, Oct 16, 2011 at 19:30, A C agcarver+...@acarver.net wrote: I'm still trying to debug a system lockup that may be related to ntpd when it is being polled for peer status by ntpq from a remote host. I'll probably be posting about that in a few days though the short summary is that polling ntpd once every five seconds from a remote machine (using ntpq) caused the ntpd system to completely freeze after about 20 hours. I stopped the ntpq polling and so far the machine has been up for a week without a problem. In that situation, I'd ensure ntpd is not running with elevated priority. It's conceivable ntpd could be to blame for locking up a system when it is run at higher priority than something the system needs, if it were to go nuts and consume a CPU/core. That would be unusual and a bug. If, on the other hand, you reproduce the system lockup with ntpd operating at default priority, you can safely point the finger away from ntpd, IMO. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS time1 and reported offset
On 10/16/2011 12:56, Dave Hart wrote: On Sun, Oct 16, 2011 at 19:30, A Cagcarver+...@acarver.net wrote: I'm still trying to debug a system lockup that may be related to ntpd when it is being polled for peer status by ntpq from a remote host. I'll probably be posting about that in a few days though the short summary is that polling ntpd once every five seconds from a remote machine (using ntpq) caused the ntpd system to completely freeze after about 20 hours. I stopped the ntpq polling and so far the machine has been up for a week without a problem. In that situation, I'd ensure ntpd is not running with elevated priority. It's conceivable ntpd could be to blame for locking up a system when it is run at higher priority than something the system needs, if it were to go nuts and consume a CPU/core. That would be unusual and a bug. If, on the other hand, you reproduce the system lockup with ntpd operating at default priority, you can safely point the finger away from ntpd, IMO. It is currently using the high priority -N flag when starting up. I'm going to let it sit for some time before restarting (for flag3 testing) at which point I'll remove the -N flag from startup and see if polling kills it. The last backtrace that I did when the system locked up showed the processor was inside ntpd at the time of the lockup. Where exactly I couldn't tell you but it was in there and the system was servicing a serial port interrupt at that same moment (probably for the PPS driver). If it stays up through Wednesday I'll know it was the polling that eventually tripped up the system so I'll have to test again without priority. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
