George Ross <g...@inf.ed.ac.uk> wrote:
> --===============6692172896629376392==
> Content-Type: multipart/signed; boundary="==_Exmh_1421765608_7720P";
>        micalg=pgp-sha1; protocol="application/pgp-signature"
> Content-Transfer-Encoding: 7bit
>
> --==_Exmh_1421765608_7720P
> Content-Type: text/plain; charset=us-ascii
>
>> It is not the resolution of the time tag that matters, but the accuracy
>> at which it can be received by an asynchronous serial port.
>
> Ah, no, the timeousness of reading the timestamp isn't relevant, provided
> only that the driver doesn't hammer on the clock unit too hard (which it
> doesn't; once a second would be absolutely fine, and polling is less
> frequent than that).  All that matters is that the kernel can toggle the
> leading edge of the timestamp-request data line reliably enough, and that
> the driver's timestamps taken before and after the ioctl() don't have much
> jitter.  We regularly see our unit's jitter around 0.001, and the offsets to
> other timeservers in the low numbers of microseconds.

Ah, you send a line toggle to the unit to be timestamped and the result
to be sent back.  That can be very accurate, yes.  I know this option is
present in some Datum GPSDO units that I use.

My experience with other Trimble models that use the TSIP protocol is that
one requests a time packet and the result reflects the current time and
is valid at some defined point in the message (e.g. the leading edge of
the start bit, I remember the exact detail).  In such a protocol it is
difficult to get it entirely right without tweaking with fixed offsets.
(because there is some delay between the start bit edge and the moment
the UART issues an interrupt)

In itself, PPS interfacing is not that difficult.  Usually it is sufficient
to connect the PPS output BNC directly to the DCD input of the serial port.
The kernel can then lock directly to the PPS, and the serial messages are
only used for date/time and status information.

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to