[LinuxPPS] still the strangeness

[Bernhard Schiffner]

Am Mittwoch, 20. Dezember 2006 11:46 schrieb Udo van den Heuvel:
> Bernhard Schiffner wrote:
> > Am Dienstag, 19. Dezember 2006 19:30 schrieb Udo van den Heuvel:
> >
> > Can you forward this mail to the ml please? (I'll forward this too.)
>
> I did CC you; it was sent to the list. Just as this one.
Excause me please, I didn't receive it by any reason from ml.

> > Your NMEA receiver needs fudge offset 172.000 until it fits to the
> > others. This is ok for pure NMEA-messages.
>
> I use a Garmin GPS-18 LVC. It has PPS and also sends the NMEA messages.
> Manual for the GPS-18 says in 4.4.1:
> The rising edge of the signal is aligned to the start of each GPS second
> within 1 us for all conditions in which the receiver has reported a
> valid and accurate position for at least the previous 4 seconds.
This reflects to the pps-signal.
Maximum accuracy of the pps-signal is one clock-cycle of the crystal used in 
the receiver.

Do you have a "vaild and accurate position"?
What does the pps-signal do if this is not given (free running, not sent...?)

How many satellites does your receiver see?
Must be more then 4!. Until this is not given, there is (in normal 
environment) no valid pps-signal.
What are the values of VDOP HDOP?

> The NMEA 0183 sentences that follow each rising edge of the PPS signal
> tell when you were and where you were at that previous rising edge of
> the PPS signal, beginning with the GPRMC sentence as the lead sentence
> in any particular NMEA 0183 record.
> Regardless of selected baud rate, the information transmitted by the GPS
> 18 series products is referenced to teh pulse immediately preceding the
> NMEA 0183 RMC sentence.
Ok. These messages are normal serial input.
The statement doesn't say anything about the time difference between the 
pps-signal and the start of the messages. This can be anything between 0 and 
999 ms.
(One thing more is the delay in the 8259 circuit (12 charakter times at 9600 
bd))
In your special case all together 172 ms.

> The ntpd NMEA driver uses PPS pulses.
>
> Now it depends of your 8250-setting when interrupt occurs.
>
> I have:
> /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4, Flags: low_latency
May be this answer is independent from my remark.
(What does low_latency say ? interrupt at the beginning of each received 
charakter?)

> > Very bad. Seems something in Hardware.
> > Second:
> > You must ensure, that the DCD-pin is working and read out by
> > pps-software. This becomes hardware resarch:
> >
> > With a meter:
> > measure on the receivers side of the cable between pin 5 (ground) and pin
> > 1 (DCD), while the receiver is running. If everything works you must
> > notice a "flicker" every second.
>
> With the digital multimeter I have it is hard to see. AC volts gives a
> solid 2.4something and DC volts gives a fluctuating 0.0something.

DC on a real serial interface is defined or >+5 VDC (on) or <-5,0VDC (off)
PPS is 0.8 sec. off and 0.2 on.
(In this example  average -3VDC.)

Try to organize a scope...

>
> Why does the ntpd reach status become 377 then?
> Does the NMEA driver this on NMEA data only?

!!! YES !!!

> Kind regards,
> Udo
>
>
>
> PS: progress...
>
> I did fiddle with everything. Upgraded firmware of the GPS18, checked
> Next step?

Offset your local NMEA-receiver until it's in shape with the others.
Forget about a lot of peers in ntp.conf in this state of affairs.

Do the hardware check (SUB-D) as I mentioned in the mail earlier. 

Also possible: open the device with minicom and short pin 1 sometime with an 
other source of + and - voltage.

cat /proc/pps/0*/* must react!

Bernhard