Is it a good idea to use a usb-serial adapter for PPS? Yes, it is.

[Ross Alexander]

On Sun, 18 Aug 2019, Ian Lepore wrote:

> On Thu, 2019-08-15 at 16:02 -0600, Ross Alexander wrote:
>> In <24b0eaf25b64d6098b390df092866c69e352d859.camel at freebsd.org>,
>> Ian Lepore writes:
>>
>>> [... ed.] I arranged to use a very stable nearly-drift-free
>>> frequency source instead of a cheap crystal for counting time in the
>>> kernel.
>>
>> You have my complete and focussed attention.  Say on.
>
> I detailed the design of the measurement system in the original
> message.  Basically it involves feeding a very stable external clock
> signal to a block of timer hardware within the imx6 SoC and using that
> timer hardware as the kernel clock.  The source of the stable external
> clock has these specs:
>
> https://www.microsemi.com/product-directory/gps-instruments/4152-syncsystem-4380a
>
> I'm a software engineer for the division of Microsemi that makes those
> devices.  If it wasn't the clock source you wanted to hear more about,
> then let me know in more detail what you'd like to know.

No, the clock source is the ticket.  I've got a TAPR clockblock lying
around somewhere, and have been meaning to pick up a precision 10 MHz
source from eBay (or equiv.) for some time.  In the meantime I've just
ovenized the whole Pi, all you need is a shoebox and an old towel :).

> [...]

I said:

>> 125 microseconds is a lot of jitter. [...]

> It's negligible jitter for everyday computer use.  It's a lot if you're
> doing something like timestamping financial transactions, or recording
> radio-astronomy observations, but the people doing that sort of thing
> usually aren't using ntpd to sync their clocks (they're using ieee-
> 1588, or custom solutions such as PCI irig input cards).

I'm measuring packet roundtrip times to regional campii and that sort
of thing.  We're linked to various tier-3 carriers via a provincial
gov't MPLS network that makes QOS questions rather opaque, and this is
one of the things I do to probe it.

I wrote:

>> [...]
>> The jitter is expressed in units of 1 millisecond, unless I am badly
>> mistaken; for which possibility I apologize in advance.
>
> Yes, it's reported in milliseconds.  The jitter number is the RMS of
> the differences between the offset from the measurement with the lowest
> delay for that peer and the other 7 offsets for that peer in the 8-step
> filter.  That is, it finds the lowest delay, then it does, roughly:
>
>   jitter = 0;
>   for offset in {the other 7 samples that aren't the lowest delay}
>      jitter += SQUARE(offset - lowest_delay_offset)
>
> then the final number is
>
>   jitter = SQRT(jitter / 7)

That is a fine thing to have clarified.  I've dug into the code,
but only because I wanted to run multiple sound card radio modems
(two WWV and two CHU) to deal with varying HF propagation and path
dropouts.  Obviously those patches were a long way from the actual
PLL logic at the core of the protocol.

regards,
Ross

============================================================================
Ross Alexander, (780) 675-6823 desk / (780) 689-0749 cell, rwa at athabascau.ca
                 54.71593 N 113.30835 W, ve6pdq

     Order is simply a thin, perilous condition
     we try to impose on the basic reality of chaos.

        -- William Gaddis, _J R_
--
This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed.
---