[LinuxPPS] state of PPS

[Bernhard Schiffner]

Am Montag, 22. Oktober 2007 02:03 schrieb Cirilo Bernardo:
> While people are talking about the state of PPS, I can't help thinking
> that the PPS mechanism is inherently faulty.
Big words: let's read further.

> In the NTP implementation 
> the serial message is parsed and then a call is made to obtain the
> timestamp.  There is no guarantee that the timestamp belongs to that
> ASCII message - there is a race here which may result in the timestamp
> being for the future ASCII message.
That's right. 
It's my opinion that PPS-signal and message form a unit, but don't to be 
mixed up. Rodolfo tried to bring this to a high level. In my understanding 
NTPD does the same. The problem is that both signals (commonly) share the 
same (serial) interface.
> For this race condition to cause 
> problems of course, the CPU has to be loaded (or the receiver has to be
> encumbered with output messages) - admittedly none of the systems I have
> worked with will meet that condition, but assuming that such a condition
> will not be met is unecessary and sloppy. One solution which doesn't
> really work is to check the timestamp associated with the incoming
> message and ensure that it was more recent than the PPS value - if it is
> earlier than the PPS value, then the message is obsolete - we cannot
> retrieve the actual timestamp for that message, so we have no option but
> to drop the message and hope that the next one comes through OK.
Please try to find ideas, where the two parts stand on their own feets als 
long as they can. Message and PPS are highly predictable in contents and 
timing. There is IMHO nothing lost with a couple of lost or "raced" 
signals. There is no need to hurry up too.
In my sets there is PPS->330ms delay->Message->???ms delay -> next PPS.
Any mismatch is detecable easily (and is done in the NTPD)

> Another problem of course is that we are forever patching various
> routines to do things they were not originally meant for - everything is
> being shoehorned into the default kernel serial comms system which sits
> on top of the TTY layer, and the TTY layer really doesn't fit neatly
> into the scheme of things.
Once more: In the case of serial connection the PPS source (unfortunately) 
shares the interface with something else. That's why the place for getting 
timestamps is inside the serial handler.
(Rodolfo uses GPIO's of embeded controllers.)

> I have a WinSystems PCM-GPS board which uses a Trimble LassenSQ receiver
> and (fortuitously) uses a separate interrupt for PPS rather than any of
> the various serial line status signals.  Since I had to write a driver
> to make NMEA and TSIP messages as well as position etc available to a
> number of processes, I just implemented yet another pseudo-device which
> provides  the NMEA message with a PPS timestamp
Did you have a look at GPSD?
http://gpsd.berlios.de/

> - I don't guarantee that 
> the PPS value represets the NMEA message either, but with this
> specialized driver implementing such a guarantee should be trivial.  I
> think for attaining the ultimate precision that a particular NMEA
> message source can provide, we simply have to write specialized drivers
> and do away with the usual TTY and serial layer.  I really don't believe
> the PPS system as it exists is a system for the future - it is a
> technical kludge which may have worked fine for devices 10 years ago and
> was relatively easy to implement, but I believe that the system needs to
> be rethought and the old PPS ultimately dumped.
I've had a similar belive 2 years ago. But I changed my opinion.
Rodolfo did a good job to find solutions.
Now it's very simple to organize something with its own interrupt as PPS 
source and handle the signal all the way down.
The additions in the serial driver are only a "proof of pudding" and the 
most common used and easily testable case.

> The great challenge of 
> course is that any one person would only be familiar with a very small
> number of gadgets, but a sensible proposal will need input from a large
> number of people and (unfortunately) a very long discussion phase and
> also a very long implementation and testing phase.
>
> Any comments/suggestions/abuse?
You are free to do what you want. I dont see a need for rethink and 
reorganisation now.
My favorite problem today: try to find ways how independent PPS sources 
don't confuse each other.

> - Cirilo
Bernhard