[ntp:hackers] refclock_palisade (driver29)
Mark.Martinec at ijs.si
Wed Feb 16 08:27:33 PST 2005
(I changes the subject line to reflect the new topic)
> As long as you are noodling the driver, may I request that you
> temporarily disable the driver PPS, crank up the atom driver and say
> "tos mindist .01"? That assumes the jitter is less than 10 ms. That
> works with some noisy clocks here and preserves the mitigation dances.
> If it does work, the individual driver PPS support can be discarded.
The refclock_palisade does not use an internal PPS hack of feeding
samples to the atom driver. The GPS receiver is capable of timestamping
events, so the driver pulses a modem line (RTS) and reads back the timestamp
at leisure. It avoids interrupt latencies entirely. This now (with Dave's
new timer interface hook and my modifications to the driver) happens cleanly
once per second, thanks to the new timer calls from the transmit procedure.
The effect is the same as if the PPS events were captured by the atom driver.
Btw, a much faster loop response (e.g. minpoll below 4) and perhaps
a 5 or 10 calls per second interface would make me very happy - the main
instability is coming from temperature-induced clock frequency variations
and a cca 15-minute response at minpoll 4 is too slow to cope with that,
leading to 2 or 3 microsecond offsets.
If one wants, the PPS output from this GPS receiver can also be tied
to the machine (e.g. on the printer port, which uses TTL levels)
and the atom driver can deal with these events independently.
Both sources of timestamps can nicely and independently coexist.
The "tos mindist" will come handy, thanks for the new feature,
but first I'm concentrating on calibrating both paths, which is
a tricky business, even with a scope and fiddling with the kernel
ppsapi routines (placement of echo pps pulse). One wishes there was
an external timer2-chip lead available, like with the Soekris board.
Here is the quick list of changes to refclock_palisade:
- general cleanup, get rid of old K&R compatibility stuff;
- fixes some remaining bugs left over from the transition
from micro to nanoseconds;
- take advantage of the new one-second timer calls;
- narrow down the uncertainty interval around pulsing RTS
by taking a systime reading before and after the edge;
- adds some more debug logging;
- make sure it works with the new Trimble receiver Acutime2000
(replacement for Palisade) as well, document new constraints
One problem that I have is: since the last time I looked at it,
the driver has been enhanced to work with the Praecis receivers,
which also speak TSIP protocol (compatible to Trimble), but
have some of their own specifics. I can do testing with Trimble
receivers, but can not test if I broke something in the Praecis
- Do we still have contact with the original author of this driver,
or is there anyone else claiming maintainership of this driver?
- Do we have a contact with the author of Praecis changes?
- Does anyone have a Praecis receiver (it is only useful in the USA,
not in Europe) and would be willing to test the new code?
More information about the hackers