[ntp:questions] Fwd: Re: NetBSD GPS/PPS using 4.2.6p3

[A C]

On 8/23/2011 22:26, A C wrote:
> On 8/23/2011 21:26, David Lord wrote:
>> A C wrote:
>>> On 8/23/2011 15:27, unruh wrote:
>>>> On 2011-08-23, Uwe Klein<uwe at klein-habertwedt.de> wrote:
>>>>> unruh wrote:
>>>>>> But from his test, his system is labelling both edges.
>>>>>>
>>>>> so he has bounces on the line?
>>>>>
>>>>> either that or rise/falltime is so low and noise so high
>>>>> that receiver hysteris is not sufficient to supress multiple
>>>>> HL/LH changes?
>>>>
>>>> No, his test shows that the line changes and then 100ms later it
>>>> changes
>>>> back and 900ms later it changes again (ie once per second it rises and
>>>> falls.) Ie, it is behaving exactly as it should if it were detecting a
>>>> pulse 100ms long.It is detecting both the rising and falling edge.
>>>
>>> I just checked and the pulse is almost exactly 100 ms low going and
>>> 900 ms high (within about 1 ms) so it's 90% duty cycle high most of
>>> the time with a swing low. The signal itself is clean down to
>>> microvolt levels. The total voltage swing is about 12 volts (which
>>> would stand to reason since I'm feeding the TTL level PPS output of
>>> the GPS board through one channel of a MAX232 level shifter).
>>>
>>> Therefore the machine is receiving a nice, clean PPS signal on DCD
>>> (DCD pin was also verified yet again and is correct by hardware
>>> specifications).
>>
>> You seem to be saying that the rs232 signal is low going,
>> ie low for 100ms then high for 900ms?
>>
>> Previously I had the impression the pulse was high going
>> and you were using 'flag2 0'.
>>
>> Ntpd requires the prefer peer to be within mindist before
>> even considering the PPS and then the system clock has to
>> be within a millisec of the PPS. Using one of your other
>> sources as prefer peer and having NMEA disabled might give
>> you a better chance of getting the pps working without
>> having to bother about the time2 value.
>
> At first I couldn't remember which way the pulse went. But having
> measured it now the voltage goes low (which would be an assert under
> RS232) for 100ms and then returns to high voltage for 900ms.
>
> Either way, flag2 made no difference (I did try it both ways) but I'll
> try it again using another network clock as the preferred peer and see
> what happens.

I should point out that whenever I add the PPS refclock into the 
configuration ntpd complains that it is not reachable and eventually I 
get the message "clock_event clk_no_reply".  Shortly after that ntpd 
crashes (actually, it get stuck in some kind of loop waiting for 
something but sending a SIGUSR1 several times to pump up the debug level 
shows nothing.)

Any suggestions for the configuration now given the new data?

I've got a set of six network sources to provide basic timing.

The GPS_NEMA refclock is currently configured as:
server          127.127.20.1  minpoll 4 mode 1
fudge           127.127.20.1  time2 0.245 refid GPS

The last PPS_ATOM refclock was configured (but is currently disabled 
because it crashes ntpd) as:
server          127.127.22.1
fudge           127.127.22.1  flag2 1 flag3 1 refid PPS


Can I add both?  Should I add both?  Or should I just enable one?  If I 
enable only GPS with PPS I'd be trying the last configuration I used for 
that (with flag1 set):

server         127.127.20.1  minpoll 4 mode 1
fudge          127.127.20.1  time2 0.245 flag1 1 flag2 1 flag3 1


However, setting flag3 for the GPS_NMEA refclock also crashes ntpd.  It 
simply freezes waiting for something.