[ntp:questions] Using Trimble TSIP under Linux
martin.burnicki at meinberg.de
Wed Oct 31 12:13:49 UTC 2012
> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>> Rob wrote:
>>> David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
>>> You need to add a circuit to stretch the narrow pulse into a 100ms
>>> pulse. The exact duration is not important. Just arrange for a
>>> monostable multivibrator that gets triggered by the rising edge
>>> of the pulse and extends the pulse by R/C time. Make sure the pulse
>>> is shorter than 500ms or the autodetection logic will focus on the
>>> wrong edge of the pulse.
>> Do you really believe you get true microsecond accuracy out of a PPS
>> signal if the PPS input circuit detects the PPS slope only if the length
>> of the pulse is 100 ms or more?
> No, I never claimed that. I implemented a solution that can be used
> by existing systems with existing hardware. The solution is to use
> an RS232 status line, a thread that sleeps on a change on that line,
> and code that reads the system clock and puts it in an SHM segment.
> This solution has several limitations, including the delay in the
> level converter, the delay in the chip, the interrupt latency, and
> the process scheduler latency.
> However, it is orders of magnitude better than using the timestamps
> obtained from serial data messages received from the GPS receiver
> via the serial port. And it does not require patching of the kernel,
> re-compilation of the kernel for PPS support (not a standard feature
> when I implemented all this), or tweaking of driver code in ntpd.
> And it allows access to the gps data (position information) from the
> same device that supplies the timing. Useful in some mobile
I basically know how gpsd works, and I find it a really useful tool,
especially since it can make data from a single GPS device available to
several applications, including ntpd.
What you say sounds also reasonable. However, the requirement for the
minimum pulse length should only depend on on the pulse length the UART
requires to detect the slope at the DCD input, which should be *much*
less than 100 ms. So my comment was just a little bit provocative. ;-)
Of course, if you are using an USB-to-serial converter and simply apply
the PPS signal via the USB connection it depends on which time the chip
inside the converter needs to detect the slope and send an appropriate
USB message "DCD changed" to the operating system's driver.
> It is not meant to be competition for the products that your company
> sells. Don't listen to the folks who claim that, or suggest this
> solution as the answer to every question asked on this group.
I didn't just write this because our company sells NTP servers. ;-)
There are many people (including me) who like to play around with
different clocks, PCs and operating systems to fiddle out which
combination and configuration provides the most accurate time. However,
for someone who is new to timekeeping stuff this usually requires quite
some effort (time to spend) to set up everything until it works as expected.
On the other hand there are companies, etc., who don't want to spend
much time on finding a setup which works for them, and then maintain it
continuously. They rather pay a little bit more for a solution they can
simply plug into their network, get alarms if anything starts to go
weird, etc. Those folks often prefer to buy a NTP server appliance.
We at Meinberg have supported open source projects in the past, and will
do so in the future.
More information about the questions