Re: Sun IPX and PPS via serial port

[AGC <agcarver+netbsd%acarver.net@localhost>]

On 8/19/2011 10:20, Erik Fair wrote:
> First, confirm that PPS signals are being received by your system. A little 
> test program written by our own Jonathan Stone will help:
>
> http://www.clock.org/~fair/ppstest.c
>
> Second ... oh, dear. This is where things get messy, and you have to understand 
> some of how the guts of ntpd work. Also, understand the limitations of GPS 
> (where is your unit's antenna? how much sky can it see?). I have an old unit 
> (should really replace it), with a fair bit of wander in it (wander? Yeah, it's 
> a fixed mount, and the lat/long coordinates change) ... and not every NMEA 
> sentence has a checksum on it as required by standard, and as now required by 
> the ntpd refclock drivers.
>
> If you read the refclock documentation carefully, you will see that ntpd won't 
> actually select the PPS clock - it will select the GPS (if ntpd thinks it's 
> good enough compared to your network servers/peers) and use PPS to discipline 
> it. At least, that's what I read in the docs.
>
> It would be good to just run your system without the GPS reference initially (just leave it unconfigured, or 
> configured for a high stratum (say, 5), but using a set of close-by (minimum network delay) stratum 1 servers 
> for about a week so that ntpd can figure out how badly your IPX system clock drifts (recorded in 
> /var/db/ntp.drift, also reported in the output of ntptime(8) as "frequency", or "ntpdc -c 
> loopi [host]" also as "frequency"). The worse that is, the harder everything else is.
>
> My GPS receiver is currently attached to accurate.clock.org, if you'd like to 
> take a look with ntpq(8), and ntpdc(8). I don't recommend anyone sync from it 
> for now.
>
>         Erik<fair%netbsd.org@localhost>

Ok, so PPS is being received by the system.  The antenna is on the roof 
and has mostly clear sky (minus what the mountains obscure).  The 
receiver has a PPS indicator and I do have a signal at the DCD pin of 
the port.

I just compiled ppstest.c and I get a positive result:


Clear timestamp: 0.000000000, sequence: 0
Assert timestamp: 1313774705.152970999, sequence: 1
Clear timestamp: 1313774706.033038999, sequence: 1
Assert timestamp: 1313774706.113036999, sequence: 2
Clear timestamp: 1313774706.993123999, sequence: 2
Assert timestamp: 1313774707.073103999, sequence: 3
Clear timestamp: 1313774707.953183999, sequence: 3
Assert timestamp: 1313774708.033175999, sequence: 4
Clear timestamp: 1313774708.913256999, sequence: 4
Assert timestamp: 1313774708.993249999, sequence: 5
Clear timestamp: 1313774709.873332999, sequence: 5
Assert timestamp: 1313774709.953321999, sequence: 6
^C


So, so far the system can see and read the DCD pin.

In the file z8530tty.c I made the following addition (which I hope is 
the right spot):


        if (ISSET(delta, cs->cs_rr0_mask)) {
                SET(cs->cs_rr0_delta, delta);

                /*
                 * Pulse-per-second clock signal on edge of DCD?
                 */
                if (ISSET(delta, zst->zst_ppsmask)) {
                        if (zst->zst_pps_state.ppsparam.mode &
                            PPS_CAPTUREBOTH) {
                                mutex_spin_enter(&timecounter_lock);
                                pps_capture(&zst->zst_pps_state);
                                pps_event(&zst->zst_pps_state,
                                    (ISSET(cs->cs_rr0, zst->zst_ppsmask))
                                    ? PPS_CAPTUREASSERT
                                    : PPS_CAPTURECLEAR);
/* this printf added */
                                printf("PPS on DCD event detected\n");
                                mutex_spin_exit(&timecounter_lock);
                        }
                }


No messages in /var/log/messages at all.


As for ntpd selecting PPS versus GPS, I do know it would select the GPS 
and be disciplined by PPS but the output of ntpq will also show that. 
For the line that has the GPS refclock, it will show a '*' in the first 
column when synced to NMEA only.  If it then becomes disciplined by PPS, 
the symbol will change to 'o'.  But that never happens and ntpd's debug 
output says it can't find a PPS signal from the kernel.  So disciplining 
never happens.