[LinuxPPS] [PATCH]

[Bernhard Schiffner]

On Saturday 02 February 2008 12:20, Cirilo Bernardo wrote:
> > > Maybe first enable some NMEA stuff to see the amount of sats.
> > > Next we'd like to set an absolute minimum for a dependable PPS..
> > >
> > > OK, we're getting offtopic w.r.t. LinuxPPS.
> >
> > Don't think so.
> > This discussion broaden our view and helps design the right interface.
> > PPS is not alone in doing the time-job.
> >
> > Bernhard
>
> I thought about this problem for a few days last year and since I'm
> working with an embedded system which no one else should alter, my
> solution was to write a GPS driver from scratch.  However, I cannot
> recommend this approach for general use; although it works very well,

I remember. It's good to have an other driver written from scratch.
Congrats so far! Good pratice,

> I'm sure no one wants a proliferation of not only GPS-specific but
> board-specific drivers.  If someone wants to, they can post to the
> NTPD list and see what the opinion is on using the NMEA driver to
> determine if the PPS is good.
NTPD is definitely the better place to proceed.

Yes, I digged a little into this NTPD-vendor-specific code. Nothing to say 
against PCI-bus card drivers and so on.
Only parsing a vendor-specific protocol on serial line seems not so good to me 
and should be avoided.

What I'am missing is a "generalised" or documented way of the NTPD-NMEA 
refclock driver to put a receiver into the standard NMEA mode and use it 
afterwards as NMEA +(PPS).
(I do some stty -f /dev/ttyS1 ... && cat ~/.../inicode_nmea.hex > /dev/ttyS1 
to alter the output of my receiver before starting as NMEA refclock.)

> If I remember correctly, gpsd does this 
> by using the satellite tracking message; I think it was Eric S.
> Raymond who commented that the satellite tracking message varies from
> manufacturer to manufacturer so decoding that message is not trivial.
I don't believe this.
IIRC there is a usual NMEA "minimum-standard" output containing the XXX string 
which also reports the SV used. (Will be detailed soon)
Can you point me to this informations please?

>  Maybe this whole thing is not an issue if people can use gpsd and the
> NTP patch for it?  In my case, unfortunately, gpsd was not suitable.
(mostly NAK, because of indirection)
1.) You must be sure to have PPS+NMEA "aligned" to determine something.
2.) It's NTPD job to handle all the subtles (how to start and stop use in 
detail) of a PPS-signal.
3.) Results determining PPS-TAI-locking belong IMHO into NTPD _and_ PPS data. 
(Rodolfo? [TAI_not_proven | TAI_proven_ok | TAI_proven_wrong])

Bernhard