[LinuxPPS] Fwd: Re: gps_nmea error

[Hal V. Engel]

I suggested that Nicholas try running ppstest to see what was happening with 
his PPS signal.  He wrote to me off list and I replied off list.  Since his 
refclock is different than mine I am not sure if his results from ppstest are 
OK or not.  But they do indicate that either he is using the wrong edge of the 
signal or the signal is inverted.  See below:

Hal
 
----------  Forwarded Message  ----------

Subject: Re: [LinuxPPS] gps_nmea error
Date: Friday 08 August 2008
From: "Hal V. Engel" <hvengel at astound.net>
To: "Ritter, Nicholas" <Nicholas.Ritter at americantv.com>

On Friday 08 August 2008 07:49:05 pm you wrote:
> I am working checking the kernel and ntp build issues. Thanks for
> providing me with background on what you see wrong with this setup, I am
> able to actually learn as we go along. Listed below is some PPS output,
> I am not sure how to read it, despite understanding what you were
> saying.
>
>
>
>
>
> Here is my ppstest output:
>
>
>
>  ./ppstest /dev/gpspps0
> trying PPS source "/dev/gpspps0"
> found PPS source "/dev/gpspps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1218249194.821427087, sequence: 362781 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1218249195.821418989, sequence: 362782 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1218249196.821427057, sequence: 362783 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1218249197.821418825, sequence: 362784 - clear
> 0.000000000, sequence: 0


This looks strange to me.  On my machine there are sequence numbers and time 
stamps for both the assert and the clear.  But you are getting zeros for both 
on the clear.

Here is what I see on my machine when I run ppstest:

# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1218250739.000109403, sequence: 25 - clear  
1218250738.198647285, sequence: 24
source 0 - assert 1218250739.000109403, sequence: 25 - clear  
1218250739.198703124, sequence: 25
source 0 - assert 1218250740.000109093, sequence: 26 - clear  
1218250739.198703124, sequence: 25
source 0 - assert 1218250740.000109093, sequence: 26 - clear  
1218250740.198762039, sequence: 26

Notice how on the first line of data the clear is sequence #24 and the assert 
is #25 meaning the the assert came after the clear.  If I subtract the clear 
time stamp from the assert time stamp I get 0.801462118 seconds.  So sequence 
#24 happened close to 800 milliseconds before the assert #25 which is exactly 
what I would expect since my GPS has about a 200 millisecond PPS pulse.  The 
second data line starts off with assert #25 (same one as the first line with 
the same time stamp) and then also includes clear #25 which occured 
0.198593721 seconds after assert #25.  Again exactly what I would expect with 
a 200ms PPS pulse.

In addition notice how my assert time stamps are almost exactly on the second 
(IE. xxxx.00010xxx) but yours are happening either about 180 milliseconds 
before or 820 milliseconds after the top of the second (IE. xxxx.8214xxx).  I 
am not sure what this tells us but it appears that either your PPS pulse is 
inverted or you are triggering on the wrong edge.  

A normal pulse would look like this:

----________----________----________
^                ^                 ^

If the pulse is inverted you would get this this:

__--------------__-------------__--------------
   ^                ^               ^

If you are triggering on the wrong edge you would get this:

----_______----________----________
    ^               ^                 ^

With ^ indicating when the assert is triggered.  Both of those wrong cases 
result in an offset = pulse width or = 1 - pulse width.  But your ppstest data 
is not complete enough to know which case it is.

I think you should post your ppstest results to the email list so that those 
more familiar with your driver can have a look.  Someone who knows your driver 
better may be able to give more useful advice than I can since all I can say 
is that it does not look right.

Hal


-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20080809/3f513931/attachment.htm