[LinuxPPS] Re: state of PPS

[Bernhard Schiffner]

...
> > 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?
Absolutly.
I did some testing with a home brewn 8MHz TCXO and a 24-bit 74193 cascade 
as PPS-Source. I synched this manually to GPS delivered PPS at start. 
Later I checked the stepping of the internal software of the GPS-receiver. 
(Some bad receiver "jump" their PPS-signal ???µs for adjusting once upon a 
time.)

In the case of a GPS receiver with serial output _and_ PPS-pulse, there is 
a typical delay between PPS slope and first charakters of the message. 
This can vary to a high degree.
The UART generates interrupts at various (adjustable) points too:
CD : direktly
RD : after n (1, ~12, 4096) char, 3 char-times after the last received but 
not read char.
TD : buffer overflow, ...
RTS : ...

> > 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.
Full ACK. My way to discuss this topic:
It's my time. I set it as I do it. It's UTC. There are absolutly no errors 
comparing it to other reference clocks. And if _you_ don't belive this, 
tell me about _your_ level of paranioa and we'll get a solution.

This means: there is no guarantee at all _possible_!!! You'll find 
everytime points to discuss. And it is a PC not a clock to work with.
(And even with A-clocks it's at least interesting: 10^9 Hz, 10^-15 accuracy 
means 10^6 seconds wating until you possibly register one wrong event. 
There is no phase adjustment like lasers can do.)

...
> 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.
Radio Jerevan: yes, in principle.
You can do normal read() and write() on this ttyS? and receiving a PPS.

> > 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.
Give it a second try. It's a deamon already. A couple of applications use 
it. Try to contakt the GPSD-guys about PPS: IIRC there was support, but is 
not now.
It will help Rodolfo to make his PPS accepted more widely.

...
> > 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 ?
More or less.
Some points:
In an ideal world the PPS's happen within ns.
It takes a PC 30--300µs to process an interrupt.
What's on if they share the same medium (PCI-Bus for serial adaptors), if 
the share the same interrupt (only one is runable).
How to detect, if one is unreliable (because of satellits in scope).
Some receivers have settings for antenna-delay (phase center of antenna - 
receiver), some receivers have settings cable-delay (receiver-PC).
Can the PC make use of such accuracy? 
(HRT, output at PPS+500000µs at RTS, compare this with the last 7447-stage 
of the home-brewn clock. (Not yet done.))

> 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
Ask Rodolfo, Udo and Clemens please.

And: try to find good interfaces in your software: I belive it's up to the 
driver to do things about _hardware_ (initialisation, congestion, 
readout, ...), but to the application about interpretation (reliablility, 
statistics, comparisations).

Bernhard