On 8/24/2011 02:36, Dave Hart wrote:
On Wed, Aug 24, 2011 at 07:52, A C<[email protected]> wrote:
So it seems like a port contention issue though I don't understand why
It may be specific to NetBSD. The Windows port of ntpd has special
code in refclock_open() and tty_open() to duplicate rather than
re-open multiple references to the same underlying COMx device. Given
the POSIX platform code doesn't do anything of the kind, I assume most
POSIX systems allow multiple opens by ntpd to operate correctly.
Any thoughts about all of this? I certainly have a little less hair than I
did when I started. However, I'd still like to get GPS_NMEA working or at
least understand why GPS_NMEA and PPS_ATOM kill each other.
I don't see code that's writing to the PPS tty in refclock_atom.c, so
I'm curious what you find about that. You might try using the NMEA
driver's built-in PPSAPI support (flag 1 1 flag2 1) without the atom
driver. refclock_nmea.c can either use /dev/gpsppsX for the PPSAPI,
or it can reuse the same descriptor opened on /dev/gpsX, if
/dev/gpsppsX can't be opened. Given your experiences with atom and
NMEA both opening the GPS tty, you should ensure /dev/gpsppsX does not
exist.
Congratulations and good luck,
Dave Hart
I will try to capture the outgoing serial data sometime either this
weekend or the next when I have a bit more time. I'll send it along to
the list as soon as I do. For now I'll leave things using PPS only and
see how it works. But I still want to eventually get the GPS refclock
working along with PPS just to have a backup clock for network outages.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
