[ntp:questions] Thunderbolt at NTP ref clock.
spam.goes at nowhere.com
Wed Jul 31 19:36:05 UTC 2013
In article <XCcKt.293983$0a4.200676 at fx06.iad>, unruh at invalid.ca says...
> On 2013-07-31, Thomas Laus <lausts at acm.org> wrote:
> > On 2013-07-31, Thomas Laus <lausts at acm.org> wrote:
> >> The pulse width wasn't adjustable. It was was just on the ragged edge
> >> of what the Soekris UART DCD was able to see for pps kernel
> >> discipline. It occasonally missed a pulse and that caused some
> >> problems for ntp because it had the time solution from the serial
> >> port data, but not the pps timestamp that matched.
> > From the Thunderbolt book:
> > 1 PPS: BNC Connector TTL levels into 50 ohm 10 microseconds-wide
> > pulse with the leading edge synchronized to GPS or UTC within
> > 20 nanoseconds (one sigma) in static, time-only mode. The rising
> > time is <20 nanoseconds and the pulse shape is affected by the
> > distributed capacitance of the interface cable/circuit.
> > My Soekris board could not handle something that narrow.
> The problem was probably more with the impedence of the Soekris input
> socket. If the time is only 0us and a 20ns the impedence of the end of
> the line will mean that much of the pulse is reflected and is thus
> rounded and much smaller than it should be. Ie, it might not have been
> the time of the pulse, but the height of the pulse, which was causing
> the trouble. (ie, 2Kohm termination impedence rathr than the line
> termination of say 50 ohm meant that the signal was relected down the
> I will admit that 10us is pretty narrow.
> > Tom
I'm an RF engineer by trade, and radio ham by choice (sucker for
A 2k term on the end of a 50r cable, will indeed reflect a lot of
energy, but whatever is inboard of that *Will* still see the pulse, and
so long as the cable is very short (time wise) compared to the pulse
width, the shape will not be too bad.
However, if the cable is long (in relation to the pulse width) then the
reflected pulse will again be reflected back from the source (the
Thunderbolt) two cable times later, and that can result in "trouble".
Irrespective of the driving system source impedance, if the cable is
term'd with a non reactive load close to it's charicteristic impeedance
(z0) then little will be reflected, and all will be nice.
If anyone is interested, get a long length of coax, feed it from a
narrow pulse/function gen (with a fast rise time) in parallel with a
'scope monitoring it, and "play" with the termination at the far end.
Lots of tricks you can do. For instance, short it out, and watch what
happens. (You've just built your first TDR!)
(Such shorted transmission lines were used in the early days of RADAR,
to get narrow predictable pulses.)
I've also reviewed other sites now, and indeed I now plan to "stretch"
the pulse width somewhat. Not decided exactly what with, yet, but there
will be a direct (one gate delay) from input to output, as well as a
monostable to hold it active for "a period of time". Something like 1
milisec' perhaps. I'll probably build something into the case of the
Thunderbolt, and route it out of the serial port connector, for
convenience. But yes, there will be extra delay involved, but I only
need things stable to within a fraction of a milisec'.
The server is using 5 'net based servers at this time (my original GPS
RX died) and is only just stable enough for what I'm doing. Sometimes
due to asymetric ping times, it "wanders a bit" for an hour or three.
I know of the TAPR FatPPS gadget, that's all it is, a monostable. I
forget the cost, but not cheap.
I don't plan on mounting the TB remote from the server, it'll be within
1m at most.
Lots to play with, not least this new install of Gravity news reader,
hence any aparent change of identity.
Oh... Though the time server is FreeBSD based, other boxes in my empire
are a mixture of Windows and Linux, various versions types and
More information about the questions