[LinuxPPS] still the strangeness

[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.

[...]
> Here we are: 1,2 ms in ntpd operation is also good shape. (2.6.19!)
> With this value you confirmed, that ntp.xs4all.nl does something reliable.

:-)
Sure, but the GPS is way off.

> 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.
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.

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

Stuff worked OK.


>>> 8.) cat /proc/pps/0*/* to see the timing of assert and clear events
>> [root at epia etc]# cat /proc/pps/0*/*
>> 0.000000000 #0
>> 0.000000000 #0
>> 0.000000000 #0
>> 0.000000000 #0
>> 0.000000000 #0
>> 0.000000000 #0
>> 0.000000000 #0
>> 0.000000000 #0
>>
>> No changes there. No output.
> 
> Very bad. Seems something in Hardware.
> First (not meaningfull):
> Do you really have 8 serial devices? (konfig-option kernel)

4. assert and clear files for each port:

[root at epia redhat]# find /proc/pps
/proc/pps
/proc/pps/03
/proc/pps/03/clear
/proc/pps/03/assert
/proc/pps/02
/proc/pps/02/clear
/proc/pps/02/assert
/proc/pps/01
/proc/pps/01/clear
/proc/pps/01/assert
/proc/pps/00
/proc/pps/00/clear
/proc/pps/00/assert
/proc/pps/sources
[root at epia redhat]# cat /proc/pps/sources
id      mode    echo    name                    path
----    ------  ----    ----------------        ----------------
00      1133    no      pps_8250_0              /dev/ttyS0
01      1133    no      pps_8250_1              /dev/ttyS1
02      1133    no      pps_8250_2              /dev/ttyS2
03      1133    no      pps_8250_3              /dev/ttyS3


> 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.

> Check: pin 5-2 (Received Data): more flicker, if your receiver sends datagrams
> This confirms that your receiver sends a pps-signal.

I can also see the data in SNSRCFG (on the windoze PC) or using minicom,
hyperterminal etc.

> With a female SUB-D:
> connect
> 3+1 (TxD DCD)
> 7+8 (RTS CTS)
> 4+6 (DTR DSR)
> put this into your computer.
> Start minicom, type in some charakter. If you cat /proc/pps/0*/* you should 
> see "crazy" values, because every slope of every bit of every charakter you 
> send should be recorded there.
> With this you see that DCD is workable. May be on EPIA boards there is no DCD 
> connected internal.

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

Kind regards,
Udo



PS: progress...

I did fiddle with everything. Upgraded firmware of the GPS18, checked
cabling, rebooted stuff, etc.
Now I see:

[root at epia redhat]# ntpq -pn
     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l   40   64  377    0.000    0.000
 0.001
*127.127.20.0    .GPS.            0 l   12   16  377    0.000    4.886
 0.670
-194.109.22.18   131.188.3.220    2 u  101  512   77    7.606  221.820
 1.413
-213.84.46.114   130.149.17.8     2 u  106  512   77   14.926  220.697
 0.536
-83.161.0.118    193.79.237.14    2 u  100  512   77   28.450  221.123
 0.590
+80.163.145.206  192.38.7.240     2 u   97  512   77   34.037  220.274
 0.940
-82.165.43.21    130.149.17.21    2 u   97  512   77   31.298  222.505
 0.865
+82.96.64.2      .DCFa.           1 u   99  512   77   15.178  241.844
 0.493


So this is a more clear 200 ms offset.
Changing flag2 does not really help.
Next step?