[time-nuts] Cheap jitter measurements

Gabs Ricalde gsricalde at gmail.com
Thu Apr 12 04:59:02 EDT 2018


On Mon, Apr 9, 2018 at 3:36 AM, Tom Van Baak <tvb at leapsecond.com> wrote:
>
> My mental model of a black box computer running NTP is that I should be able to give it a pulse (e.g., via parallel, serial, GPIO) and it tells me what time it was. Use a GPSDO / Rb / picDIV to generate precise pulses. Compare the known time of the pulse with the time the box says it was. Repeat many times, collect data, look at the statistics; just as we would for any clock.
>
> Similarly, the box should be able to give me a pulse at a known time. In this case it records the time it thinks the pulse went out, and your GPSDO / Rb / TIC makes the actual measurement. Again, collect data and look at the statistics; just as we would for any clock.

On Wed, Apr 11, 2018 at 2:59 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
> I think that should be a reasonable project.
>
> 1) Write some code to grab the time, send a pulse, grab the time.  Log that.
> 2) Use a time-stamp counter to log the time of the pulse.
> 3) Write the software to merge the two log files.
>

Hal, tvb,

I have a Linux PPS driver that does the following:
(1) Wait for the PPS rising edge
(2) Get the time
(3) Assert a GPIO output
(4) Set a timer that runs the following after 500 ms:
(5)     Get the time
(6)     Clear the GPIO output
(7)     Get the time

The timestamps from (2) are the ones read by ntpd and it looks like this:
1523452407.999999977
1523452408.999999994
1523452410.000000021
1523452410.999999977
1523452412.000000028
PPS is from a u-blox LEA-6T.

(3) is the PPS echo and we will use that to measure the PPS latency.

The timestamps from (5) and (7) look like this:
1523452408.500016042 1523452408.500016467
1523452409.500007535 1523452409.500007955
1523452410.500007246 1523452410.500007666
1523452411.500008362 1523452411.500008782
1523452412.500009269 1523452412.500010034

I don't have a TIC so I'm using the LEA-6T external interrupt for
measuring the edges from (3) and (6). The edges are timestamped with a
23 ns accuracy and reported in the TIM-TM2 (time mark) message. The
rising/falling edge values look like this:
306808.000000845 306808.500016630
306809.000000957 306809.500008118
306810.000000904 306810.500007835
306811.000000850 306811.500008948
306812.000000963 306812.500010207

The integer part is the UTC TOW.
The fractional part of the rising edge is the upper bound of the PPS latency.

Now we can subtract the (5)/(7) timestamps and the u-blox TIM-TM2
falling edge values:
1523452408 -0.000000588 -0.000000163
1523452409 -0.000000583 -0.000000163
1523452410 -0.000000589 -0.000000169
1523452411 -0.000000586 -0.000000166
1523452412 -0.000000938 -0.000000173

I've attached some plots:
"pps offset.png" is (2) minus round( (2) )
"before gpio clear.png" is (5) minus TIM-TM2 falling edge
"after gpio clear.png" is (7) minus TIM-TM2 falling edge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pps offset.png
Type: image/png
Size: 14508 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20180412/85a1ff83/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: before gpio clear.png
Type: image/png
Size: 16259 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20180412/85a1ff83/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after gpio clear.png
Type: image/png
Size: 18501 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20180412/85a1ff83/attachment-0002.png>


More information about the time-nuts mailing list