[LinuxPPS] another refclock_nmea patch ([Bug 610] Generic NMEA
GPS Receiver driver w/ PPS expects PPS after NMEA data)
Udo van den Heuvel
udovdh at xs4all.nl
Tue Nov 6 17:15:28 CET 2007
Rodolfo Giometti wrote:
>>>> Now some small documentation changes needed?
>>> LinuxPPS's wiki needs updates... :P
>> For what?
>> I sent a patch for driver20.html changes to bugzilla.
>
> I refere to the last discussions about opening the serial port to get
> PPS events and so on...
Well, see below.
>>>> BTW: is pps (atom) driver not opening the device a feature?
>>> I don't know... RFC syas nothing about that but I think this is a
>>> drawback of using a serial port as PPS source. In fact if you can use
>>> a proper device (maybe a CPU GPIOs or similar) you will have no such
>>> problem at all.
>> In that case ntpd should try to open the device anyhow and silently fail.
>> PPS should then work at all times.
>
> No, but maybe we can report this problem to the NTPD folks and propose
> a patch for that driver which allows definition of a "main" and
> "alternate" device too. Of cource the main device (if it's not a PPS
> source) it simply keeped open just to allow the alternate device to
> get PPS events.
atom refclock code: (from atom_start)
sprintf(device, DEVICE, unit);
up->fddev = open(device, O_RDWR, 0777);
if (up->fddev <= 0) {
msyslog(LOG_ERR,
"refclock_atom: %s: %m", device);
return (0);
}
/*
* Light off the PPSAPI interface.
*/
if (time_pps_create(up->fddev, &up->handle) < 0) {
msyslog(LOG_ERR,
"refclock_atom: time_pps_create failed: %m");
return (0);
}
/*
* If the mode is nonzero, use that for the time_pps_setparams()
* mode; otherwise, PPS_CAPTUREASSERT. Enable kernel PPS if
* flag3 is lit.
*/
mode = peer->ttl;
if (mode == 0)
mode = PPS_CAPTUREASSERT;
return (atom_ppsapi(peer, mode));
So a device IS opened?!
What would explain the different behaviour?
More information about the LinuxPPS
mailing list