On Wed, Mar 14, 2007 at 10:31:46AM +0100, Rodolfo Giometti wrote:
I will grab the last couple of commits and try although they didn't
sound like they really make much difference.
I couldn't find any way to do that with setserial (at least not the
version I have), and I would rather not have to install setserial just
to do that. Which version of setserial is needed and what arguments
does it need to do it?
If it is NOT connected to the same device, then how would you specify
it? The ntp configuration is rather sparse when it comes to specifying
anything and seems to rely in symlinks to hardcoded device names for
finding everything. I suppose one could have gps# for the nmea messages
and pps# for the associated pps device name symlink (which may point
to something that doesn't even exist if there is an internal source of
that name with no associated device). Does that seem reasonable? I can
certainly change it to do that. Certainly refclock_atom already uses
/dev/pps# as it's device, so using that again may be reasonable.
Oops. Missed that one. I was changing it to the below line to reuse
the same serial device already specified for the NMEA messages.
I actually find the way it determines the pps device a bit annoying.
Right now I have to do this:
cd /dev
ln -s ttyn0 jsm0
ln -s jsm0 gps0
This way gps0 is the symlink the ntp refclock looks for when asked for
device 0, and readlink turns that into jsm0 (since the internal driver
name for ttyn0 is jsm, that is what the pps code insists it must be
named), which then is another symlink to the real device name. Same for
ttyS3 <- serial3 <- gps0. Now it would be nice if the internal driver
name matched the device name, but apparently that really never seems to
happen. Is all this symlink spagheti really necesary?
OK, I will do that too. Apparently the current refclock_nmea patch
fails that too then.
Will do.
--
Len Sorensen
-