[ntp:questions] Using Trimble TSIP under Linux
nomail at example.com
Wed Oct 31 17:39:43 UTC 2012
Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> 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. ;-)
The problem is that there is no efficient way to "wait" for a pulse
edge that waits only on a rising or falling edge. There is an ioctl
that waits for any edge, and when it returns gpsd has to read the current
state of the pulse input to see if that was a rising or a falling edge.
(the ioctl returns 2 times per second and we want to look only at one
of those 2)
So, it should be guaranteed that between the edge of the pulse and
the reading of its status (from a user process that competes for CPU
in a multitasking system!) the line does not change again.
This simply cannot be guaranteed for a 10 microsecond pulse, which is
what the Trimble receiver sends.
While 100ms is much longer than what is required, it is what other
makes of GPS receiver often send by default. It is a convenient value
to work with, as there is little chance that the user process handling
the pulse will not be scheduled within 100ms.
The pulse should be stretched, and whether it is stretched to 10 or
100 or 300ms does not really matter. As long as it is not more than
400ms or so, because it would confuse the autodetection of the active
edge that is present in gpsd (which assumes that the mark of the
second occurs at the leading edge of the pulse).
> 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.
USB-to-serial makes it more complicated, but I'm not sure if it works
at all, because gpsd relies on the availability of the TIOCMIWAIT
ioctl for the serial device. I think it is not implemented for all
USB serial drivers.
But anyway, the abovementioned restriction also applies in this case.
>> 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.
At the time I was active in the gpsd project, one of the project goals
was that everything should work without any effort. Configuration
was basically forbidden. It even meant I had to hardcode observed
offsets between realtime and time as received in serial data, something
I would have put in a configuration file when it had been available.
Of course it is convenient when everything just works, and sure it is
a good idea for developers to pay some attention to that, but in the
end I think it was not very realistic. And now there appears to be
a configuration file... :-)
More information about the questions