[LinuxPPS] refclock_nmea patch

[Rodolfo Giometti]

On Tue, Oct 23, 2007 at 06:11:45PM +0200, Udo van den Heuvel wrote:
> Rodolfo Giometti wrote:
> >> Yes, but now what if we have a device with one /dev/bla giving NMEA and
> >> another /dev/duh giving PPS?
> >> How is the first /dev/bla passed on to ntpd?
> >> I don't get this yet.
> >>
> >> In my own situation we have NMEA and PPS on teh same RS232 port.
> >> I then expect the first link that I apss to LinuxPPS to be used, which
> >> isn't.
> > 
> > The first (or main) device is the GPS data source (/dev/ttyS0 in your
> > case) which __could__ be also a PPS data source. 
> 
> In my case it is, but PPS is not taken from there.

No, /dev/ttyS0 is just a serial line, not a PPS source. From
/dev/ttyS0 you should get _only_ NMEA serial data. No PPS.

You should consider your antenna as a black box which holds two
devices: a GPS/NMEA serial data source and a PPS source.

The GPS/NMEA serial data source is connected with the /dev/ttyS0
serial port (pins TX and RX) while the PPS source (named /dev/pps0 in
LinuxPPS) is connected with the DCD pin of the same serial port, but
it's _another_ device even if they share the same serial port.

> >>>> Maybe this can help:
> >>>> When is the /dev entry (pps0) created?
> >>>> Based on what input?
> >>> If you have udev when the pps device is created, otherwise you have to
> >>> create it by yourself by using mknod.
> >> It was there, so udev works I guess.
> >> How is decided what port is to be created?
> > 
> > The system decides the PPS id just the ethernet devices.
> 
> But why not for /dev/ttyS1? S2? etc?

Thease are serial lines not PPS sources.

> >> I once had a /dev/gps0 and /dev/pps0 pointing to /dev/ttyS0.
> >> /dev/pps0 was replaced by the new device entry.
> >> Why?
> > 
> > No you should have:
> > 
> > 	/dev/gps0 -->	/dev/ttyS0
> > 	/dev/pps0
> 
> I have this.

Good.

> 
> >> /*
> >>  * nmea_start - open the GPS devices and initialize data for processing
> >>  */
> >> static int
> >> nmea_start(
> >>         int unit,
> >>         struct peer *peer
> >>         )
> >> {
> >>         register struct nmeaunit *up;
> >>         struct refclockproc *pp;
> >>         int fd;
> >>         char device[20];
> >>
> >>         /*
> >>          * Open serial port. Use CLK line discipline, if available.
> >>          */
> >>         (void)sprintf(device, DEVICE, unit);
> >>
> >>         fd = refclock_open(device, SPEED232, LDISC_CLK);
> >>         if (fd <= 0) {
> >> #ifdef HAVE_READLINK
> >> (nmead stuff cut)
> >> #endif
> >>         }
> >>
> >>         /*
> >>          * Allocate and initialize unit structure
> >>          */
> >>         up = (struct nmeaunit *)emalloc(sizeof(struct nmeaunit));
> >>         if (up == NULL) {
> >>                 (void) close(fd);
> >>                 return (0);
> >>         }
> >>         memset((char *)up, 0, sizeof(struct nmeaunit));
> >>         pp = peer->procptr;
> >>         pp->io.clock_recv = nmea_receive;
> >>         pp->io.srcclock = (caddr_t)peer;
> >>         pp->io.datalen = 0;
> >>         pp->io.fd = fd;
> > 
> > Here the fs is saved, so everything is ok.
> 
> So maybe we should make the msyslog messages more clear that the open of
> the NMEA source went OK?

Maybe you can add a system log like: GPS data device "/dev/gps0"
found, after the first open(), and then modify the last log like: PPS
data device "/dev/pps0" found, in the end of the function.

In LinuxPPS the PPS device is _always_ different from GPS data one,
but in other system they can be the same, so the above logs will
became:

	GPS data device "/dev/gps0" found
	PPS data device "/dev/gps0" found

However this is _not_ our case.

> > 
> > Good! It's ok.
> > 
> 
> But not clear enough.
> 
> BIG issue:
> 
> Also it is strange that PPS is not taken from /dev/gps0.

There is nothing strange since in LinuxPPS a PPS source _cannot_ be
also a GPS data source.

This was the trick which allows us to be RFC compliant! ;)

> The time_pps_create fails, why?

Because /dev/gps0 is _not_ a PPS source. In LinuxPPS this check will
fail _each_ time, on other systems it could return ok.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127