1. Forum
  2. Usenet
  3. SCI.GEO.SATELLITE-NAV

  • precision PPS signal

    From kristoff@21:1/5 to All on Thu Oct 25 08:33:09 2018
    Hi,


    Very simple question:
    I noticed that my ubox8 module can produce a PPS-signal, not only at 1
    pulse per second, but -apparently- up to 10 MHz.

    Has anybody ever measured the quality of that signal (if locked to the GNSS-signal) of a mass-market device like the ubox-8? Precision? Stability?


    For my goal (a reference-signal for amateur-radio) it is probably more
    then good enough, but -as a good technician- I like to be able to put a
    figure on it.
    I did a quick test with the hardware frequency-counter of my rigol, and
    it reports a 3 to4 Hz difference at 10 MHz.



    BTW. Does anybody have an idea how that signal is produced? I guess is somewhere from the CDMA-decoding process.


    Cheerio! Kr. Bonne (ON1ARF)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to kristoff on Thu Oct 25 09:46:56 2018
    kristoff wrote:
    Hi,


    Very simple question: I noticed that my ubox8 module can produce a PPS-signal, not only at 1 pulse per second, but -apparently- up to 10
    MHz.

    Has anybody ever measured the quality of that signal (if locked to
    the GNSS-signal) of a mass-market device like the ubox-8? Precision? Stability?


    For my goal (a reference-signal for amateur-radio) it is probably
    more then good enough, but -as a good technician- I like to be able
    to put a figure on it.

    While running at 1Hz most PPS-equipped modules are capable of 15-35 ns
    RMS, except that many of them are only capable of producing those pulses
    at exact 10 MHz boundaries, i.e. it can be +/- 50 ns off.

    The classic Motorola Oncore timing receiver would tell you, in the
    serial message, exactly how far the last PPS signal was offset.

    I did a quick test with the hardware frequency-counter of my rigol,
    and it reports a 3 to4 Hz difference at 10 MHz.

    Unless they have analog steering of the local 10 MHz osc, they will be
    off a little, 3-4 Hz seems fine. Some timing receivers will have a TCXO
    or a Rb local osc, but not your ublox.



    BTW. Does anybody have an idea how that signal is produced? I guess
    is somewhere from the CDMA-decoding process.

    Yes, probably. You need a local clock source that can generate the base
    for matching the pseudo-random codes of each sat, which uses a 1/10 MHz signalling rate afair.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From kristoff@21:1/5 to Terje Mathisen on Thu Oct 25 20:36:49 2018
    Hi Terje,



    First, thanks for your reply.


    (inline comments)


    On 25/10/18 09:46, Terje Mathisen wrote:
    I did a quick test with the hardware frequency-counter of my rigol,
    and it reports a 3 to4 Hz difference at 10 MHz.

    Unless they have analog steering of the local 10 MHz osc, they will be
    off a little, 3-4 Hz seems fine. Some timing receivers will have a
    TCXO or a Rb local osc, but not your ublox.

    OK. It looks I had a wrong idea about how this receiver works.

    I had the impression that 10 Mhz clock I get on the PPS output pin was GNSS-syncronised, but it is not.
    For that, you need a GNSS-receiver that can feed its frequency-offset
    back to the VCXO. The ubox 8030 I guess does not do that.

    I misinterpreted the "lockGpsFreq" flag in CFG-TP5 thinking it locked
    the frequency of the receiver itself to satellite-signals, but -I guess-
    it actually means that the "beginning of the second" time-pulse to the
    timing received from the satellites, not the clock itself.


    Anycase, I guess this is easy to test. Connect the PPS-pulses of two GNSS-receivers to a scope in a X-Y plot mode.
    It the two clocks drift, this means that are not syncronised.



    (anycase, it means that my project to build a 1 Mhz reference time-clock
    based on DCF77 still is usefull :-) )


    Terje

    Kristoff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From kristoff@21:1/5 to Terje Mathisen on Fri Oct 26 08:51:34 2018
    Terje,


    Just a small update.


    On 25/10/18 09:46, Terje Mathisen wrote:
    While running at 1Hz most PPS-equipped modules are capable of 15-35 ns
    RMS, except that many of them are only capable of producing those pulses
    at exact 10 MHz boundaries, i.e. it can be +/- 50 ns off.
    The classic Motorola Oncore timing receiver would tell you, in the
    serial message, exactly how far the last PPS signal was offset.

    It turns out the ubox8 can also do that.

    That information is in the NAV-TIME{GPS,GAL,GLO,BDS} messages. However,
    the value is a unsigned integer, so I am not really sure how to
    interprete it.

    When I monitored it, the value was on one receiver around 20 ns, on
    another one 10 ns. The good news is that on a second-to-second basis,
    there is hardly any change: +/- 1 ns per second maximum.
    So there is relative little drift on the clock.



    Terje
    Cheerio! Kr. Bonne.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to kristoff on Fri Oct 26 09:32:15 2018
    kristoff wrote:
    Terje,


    Just a small update.


    On 25/10/18 09:46, Terje Mathisen wrote:
    While running at 1Hz most PPS-equipped modules are capable of 15-35 ns
    RMS, except that many of them are only capable of producing those
    pulses at exact 10 MHz boundaries, i.e. it can be +/- 50 ns off.
    The classic Motorola Oncore timing receiver would tell you, in the
    serial message, exactly how far the last PPS signal was offset.

    It turns out the ubox8 can also do that.

    That information is in the NAV-TIME{GPS,GAL,GLO,BDS} messages. However,
    the value is a unsigned integer, so I am not really sure how to
    interprete it.

    When I monitored it, the value was on one receiver around 20 ns, on
    another one 10 ns. The good news is that on a second-to-second basis,
    there is hardly any change: +/- 1 ns per second maximum.
    So there is relative little drift on the clock.

    What you need to do is to monitor/log that offset value over a day or
    so, and plot the results: I expect that you will see a sawtooth pattern
    where it slowly increases (or decreases) to some limit, then makes a
    jump corresponding to the granularity of the pulse positioning (i.e.
    typically 100 ns) before the long slope repeats.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)