[ntp:hackers] Re: refclock_palisade (driver29)

David L. Mills mills at udel.edu
Wed Feb 16 09:38:21 PST 2005


Mark,

Gotcha. You don't need the atom. Be a little careful; there can be none, 
one or two timer calls during a real one-second interval. The original 
code in the atom driver was defective and has been fixed. You might need 
to do the same kind of thing, which amounts to a range gate as used in 
radar systems.

The poll interval cannot be reduced below 16 s using the daemon 
discipline, which updates at one second intervals. For poll intervals 
below 16 s the 1-s delay is too high and would result in overshoot and 
ringing. In principle you can do that with the kernel discipline, but 
not with the current parameters. The kernel PPS computes the frequency 
correction over 128- or 256-second intervals on the assumption the Allan 
intercept is in the order of those values. Looking at the Allan variance 
characteristic for typical ugly computer oscillators, accuracy is not 
much improved with time constants less than this.

Having said that, the residual jitter with a PPS connected via serial 
port to a low-end Pentium is typically only a few microseconds and the 
residual offset is typically about 10-20 microseconds. I don't think it 
worth much bother to want better than that, unless the clock uses a TCXO 
or hot rock.

Dave

Mark Martinec wrote:

>(I changes the subject line to reflect the new topic)
>
>>From Dave:
>  
>
>>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
>  and specs;
>
>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
>support.
>
>- 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?
>
>Mark
>  
>




More information about the hackers mailing list