[LinuxPPS] Re: state of PPS

[Cirilo Bernardo]

Thanks for all comments from Reg and Bernhard.

> 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.

Just to clarify that - do you mean that in some cases DeviceA may be generating the time message while DeviceB generates a PPS and they are both connected to the same serial port, but DeviceB is not really synchronised with DeviceA?

> 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)

I absolutely agree here - NTP is quite happy if some time messages are not delivered.  In fact my own driver will not issue a time message unless the time can be guaranteed (that is, derived from radio signals and not the onboard real-time-clock).  As Reg pointed out, I'm probably worrying too much about something which really isn't a problem - but this is a habit from producing very reliable instruments.

>> 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.)

OK, this question is just slightly different from the first one above:
Does this mean a PPS device may be using one of the Modem Status lines (DCD, RTS, CTS) while another device such as a printer is connected to the same serial line?  If that is the case then my original idea of completely separating the serial drivers from the TTY layer for exclusive use by time sources will not work for the general case.

> Did you have a look at GPSD?
> http://gpsd.berlios.de/

Yes, but the system didn't quite work the way I wanted to work (not the fault of gpsd, but due to the serial drivers being tied to TTY).  I didn't have time to analyse the code and answer the list of questions I had come up with; I could write a complete driver in less time than that, so I wrote a driver.

> 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.

OK, I think I see the point now - some people use all the resources available by using the serial line simultaneously for several purposes.  Reality can be such a nuisance at times.

> 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.

How can they confuse eachother?  Are you thinking of the situation when 3 PPS devices are connected to the modem status lines of a single serial line ?

Is there a "to do" list I can have a look at while I still remember the horrible details of the serial drivers and ntpd?  I may as well see if I can make some contribution while I can remember things. :)

- Cirilo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20071023/0d8512e8/attachment.html