very confusing results though using pps andnmea - NTP

This is a discussion on very confusing results though using pps andnmea - NTP ; Hello! Some might recall I asked some questions here and disappeared before getting my hands dirty. - Sorry for that, I had to go to hospital for a while and didn't touch the ntp-server project since. So now I'm back ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: very confusing results though using pps andnmea

  1. very confusing results though using pps andnmea

    Hello!

    Some might recall I asked some questions here and disappeared before
    getting my hands dirty. - Sorry for that, I had to go to hospital for a
    while and didn't touch the ntp-server project since. So now I'm back and
    everything is fine!

    First of all I am trying to understand what is actually happening inside
    the computer, time-wise.

    So I set up a nmea-driver using a u-blox usb-gps-device with the
    standard nmea driver and I set up a pps-device via the serial port using
    the atom driver and the linuxpps kernel-patch found in the enneenne wiki
    here: http://wiki.enneenne.com/index.php/LinuxPPS_support

    Now using the following ntp.conf I can see that things are working, but
    not as expected. I would expect the pps clock to take over, no matter
    what happens, since I understand it is either there or not and it can't
    be wrong. Instead my system randomly marks either of these a false
    ticker every now and then..

    Here the ntp.conf:
    ----------------------------------------------------
    # PPS
    server 127.127.22.0 minpoll 4 maxpoll 4
    fudge 127.127.22.0 flag2 0

    # NMEA GPS driver for u-blox receiver
    server 127.127.20.0 prefer minpoll 4
    fudge 127.127.20.0 flag3 0 flag2 0 time1 0.0

    server 0.debian.pool.ntp.org iburst
    server 1.debian.pool.ntp.org iburst
    ----------------------------------------------------


    The output of ntpq -p changes offset and jitter values in large ranges
    for every source, also something that I can't believe to be true..


    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    xPPS(0) .PPS. 0 l 6 16 77 0.000 258.904
    30.207
    *GPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 -263.23
    30.743
    xnetzwerkteufel. 192.53.103.108 2 u 7 64 177 23.019 -159.57
    99.817
    xceres.sternbaue 131.188.3.222 2 u 59 64 77 48.554 -133.36
    85.637

    What am I doing so badly wrong? Can anyone help?

    Best regards,
    .../nico berndt

  2. Re: very confusing results though using pps and nmea

    nb@komeda-berlin.de (Nicola Berndt) writes:

    >Hello!


    >Some might recall I asked some questions here and disappeared before
    >getting my hands dirty. - Sorry for that, I had to go to hospital for a
    >while and didn't touch the ntp-server project since. So now I'm back and
    >everything is fine!


    >First of all I am trying to understand what is actually happening inside
    >the computer, time-wise.


    >So I set up a nmea-driver using a u-blox usb-gps-device with the
    >standard nmea driver and I set up a pps-device via the serial port using
    >the atom driver and the linuxpps kernel-patch found in the enneenne wiki
    >here: http://wiki.enneenne.com/index.php/LinuxPPS_support


    >Now using the following ntp.conf I can see that things are working, but
    >not as expected. I would expect the pps clock to take over, no matter
    >what happens, since I understand it is either there or not and it can't
    >be wrong. Instead my system randomly marks either of these a false
    >ticker every now and then..


    Actually the pps CAN have noise on the line. I have found with my Garmin
    18LVM that sometimes the interrupt fires of 6 or 7 hits in a few
    milliseconds,-- some sort of line noise coming in. Now, it is I admit a bit
    of a kludge and I have not bothered to track down the problem-- bad solder
    joint, TV interference,.....-- but it happens.

    What is best if you can record say a days worth of interrupt timings
    without haing the pps discipline your clock, and look at, or rather plot (
    since looking at 86400 entries is liable to fry your brain) to see if you
    are getting glitches-- noise tends to occur randomly so plotting
    t_{i+1}-t_i over the day will show you if glitches have occured. If they
    differ from 1 second according to your computer clock ( and you have left
    your computer clock just rinning and not resetting it suddenly-- even ntp
    running on the outside sources is fine since it shifts the time slowly)
    then you have noise.
    Note that serial port nmea is liable to be out by up to 1/2 sec and to have
    a lot ( 10s of msec) jitter on it, since the end of the string received by
    a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
    characters 1/8 of a second to be delivered and will have a jitter of few
    characters in length-- or about 10ms jitter).


    >Here the ntp.conf:
    >----------------------------------------------------
    ># PPS
    >server 127.127.22.0 minpoll 4 maxpoll 4
    >fudge 127.127.22.0 flag2 0


    ># NMEA GPS driver for u-blox receiver
    >server 127.127.20.0 prefer minpoll 4
    >fudge 127.127.20.0 flag3 0 flag2 0 time1 0.0


    >server 0.debian.pool.ntp.org iburst
    >server 1.debian.pool.ntp.org iburst
    >----------------------------------------------------



    >The output of ntpq -p changes offset and jitter values in large ranges
    >for every source, also something that I can't believe to be true..



    > remote refid st t when poll reach delay offset
    > jitter
    >================================================== ============================
    >xPPS(0) .PPS. 0 l 6 16 77 0.000 258.904
    >30.207
    >*GPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 -263.23
    >30.743
    >xnetzwerkteufel. 192.53.103.108 2 u 7 64 177 23.019 -159.57
    >99.817
    >xceres.sternbaue 131.188.3.222 2 u 59 64 77 48.554 -133.36
    >85.637


    >What am I doing so badly wrong? Can anyone help?


    >Best regards,
    >../nico berndt


  3. Re: very confusing results though using pps and nmea

    Nicola Berndt wrote:
    > Hello!
    >
    > Some might recall I asked some questions here and disappeared before
    > getting my hands dirty. - Sorry for that, I had to go to hospital for
    > a while and didn't touch the ntp-server project since. So now I'm
    > back and everything is fine!

    []
    > What am I doing so badly wrong? Can anyone help?
    >
    > Best regards,
    > ../nico berndt


    Good to hear you are back.

    Is there any chance you are triggering on the wrong edge of the PPS
    signal, i.e. the trailing edge rather than the leading edge?

    Cheers,
    David



  4. Re: very confusing results though using pps andnmea

    >> Now using the following ntp.conf I can see that things are working,
    but not as expected. I would expect the pps clock to take over, no
    matter what happens, since I understand it is either there or not and it
    can't be wrong. Instead my system randomly marks either of these a false
    ticker every now and then..
    >
    > Actually the pps CAN have noise on the line. I have found with my Garmin
    > 18LVM that sometimes the interrupt fires of 6 or 7 hits in a few
    > milliseconds,-- some sort of line noise coming in. Now, it is I admit

    a bit
    > of a kludge and I have not bothered to track down the problem-- bad

    solder
    > joint, TV interference,.....-- but it happens.
    > What is best if you can record say a days worth of interrupt timings
    > without haing the pps discipline your clock, and look at, or rather

    plot (
    > since looking at 86400 entries is liable to fry your brain) to see if you
    > are getting glitches-- noise tends to occur randomly so plotting
    > t_{i+1}-t_i over the day will show you if glitches have occured. If they
    > differ from 1 second according to your computer clock ( and you have left
    > your computer clock just rinning and not resetting it suddenly-- even ntp
    > running on the outside sources is fine since it shifts the time slowly)
    > then you have noise.


    Ok, I will, I am just not sure, how to do so. Here are some assumptions,
    please correct me, where I'm wrong:

    cat /proc/interrupt shows me /counts/ of different interrupts, so I
    assume,that is not what I am looking for. There is a IO-APIC-edge timer
    interrupt (0) and a IO-APIC edge serial interrupt (4). The timer
    interrupt grows constantly and the serial grows a couple of thousands
    every start of a second (looks like) and If then stops until the next
    second. I assume that's the one and that the interrupts are fired, als
    long as the pps-signal is incoming.

    Now I find cat /proc/irq/4/serial to reportI "Is a directory" and I find
    nothing in there, so I am a bit stuck, since I simply don't know what to
    record..


    > Note that serial port nmea is liable to be out by up to 1/2 sec and

    to have
    > a lot ( 10s of msec) jitter on it, since the end of the string

    received by
    > a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
    > characters 1/8 of a second to be delivered and will have a jitter of few
    > characters in length-- or about 10ms jitter)


    I don't understand why you are mentioning this, maybe you got me wrong.
    I run the nmea gps over usb and the pps goes to the serial port. So
    there is no data exept for the pps on my serial line..

  5. Re: very confusing results though using pps and nmea

    nb@komeda-berlin.de (Nicola Berndt) writes:

    > >> Now using the following ntp.conf I can see that things are working,

    >but not as expected. I would expect the pps clock to take over, no
    >matter what happens, since I understand it is either there or not and it
    >can't be wrong. Instead my system randomly marks either of these a false
    >ticker every now and then..
    > >
    > > Actually the pps CAN have noise on the line. I have found with my Garmin
    > > 18LVM that sometimes the interrupt fires of 6 or 7 hits in a few
    > > milliseconds,-- some sort of line noise coming in. Now, it is I admit

    >a bit
    > > of a kludge and I have not bothered to track down the problem-- bad

    >solder
    > > joint, TV interference,.....-- but it happens.
    > > What is best if you can record say a days worth of interrupt timings
    > > without haing the pps discipline your clock, and look at, or rather

    >plot (
    > > since looking at 86400 entries is liable to fry your brain) to see if you
    > > are getting glitches-- noise tends to occur randomly so plotting
    > > t_{i+1}-t_i over the day will show you if glitches have occured. If they
    > > differ from 1 second according to your computer clock ( and you have left
    > > your computer clock just rinning and not resetting it suddenly-- even ntp
    > > running on the outside sources is fine since it shifts the time slowly)
    > > then you have noise.


    >Ok, I will, I am just not sure, how to do so. Here are some assumptions,
    >please correct me, where I'm wrong:


    >cat /proc/interrupt shows me /counts/ of different interrupts, so I
    >assume,that is not what I am looking for. There is a IO-APIC-edge timer
    >interrupt (0) and a IO-APIC edge serial interrupt (4). The timer
    >interrupt grows constantly and the serial grows a couple of thousands


    Uh, you have serious problems withe your PPS. It looks to me like it needs
    to be buffered. It should grow by 1 every second, not thousands. It sounds
    like there is extreme noise on your pps line which when it gets near
    transition causes loads of interrupts. Not good. Find out why the pps
    output is so so so noisy.


    >every start of a second (looks like) and If then stops until the next
    >second. I assume that's the one and that the interrupts are fired, als
    >long as the pps-signal is incoming.


    No, the interrupt is fired ONCE per edge transition. And there should only
    be ONE edge transition.


    >Now I find cat /proc/irq/4/serial to reportI "Is a directory" and I find
    >nothing in there, so I am a bit stuck, since I simply don't know what to
    >record..


    You need to write a little interrupt service routine to timestamp each
    interrupt. But the info you gave already says something is seriously wrong.




    > > Note that serial port nmea is liable to be out by up to 1/2 sec and

    >to have
    > > a lot ( 10s of msec) jitter on it, since the end of the string

    >received by
    > > a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
    > > characters 1/8 of a second to be delivered and will have a jitter of few
    > > characters in length-- or about 10ms jitter)


    >I don't understand why you are mentioning this, maybe you got me wrong.
    >I run the nmea gps over usb and the pps goes to the serial port. So
    >there is no data exept for the pps on my serial line..


    There is data on the usb line, which is a serial type line for which his
    comments apply.


  6. Re: very confusing results though using pps andnmea

    Unruh schrieb:
    > nb@komeda-berlin.de (Nicola Berndt) writes:
    >
    >>>> Now using the following ntp.conf I can see that things are working,

    >> but not as expected. I would expect the pps clock to take over, no
    >> matter what happens, since I understand it is either there or not and it
    >> can't be wrong. Instead my system randomly marks either of these a false
    >> ticker every now and then..
    >>> Actually the pps CAN have noise on the line. I have found with my Garmin
    >>> 18LVM that sometimes the interrupt fires of 6 or 7 hits in a few
    >>> milliseconds,-- some sort of line noise coming in. Now, it is I admit

    >> a bit
    >>> of a kludge and I have not bothered to track down the problem-- bad

    >> solder
    >>> joint, TV interference,.....-- but it happens.
    >>> What is best if you can record say a days worth of interrupt timings
    >>> without haing the pps discipline your clock, and look at, or rather

    >> plot (
    >>> since looking at 86400 entries is liable to fry your brain) to see if you
    >>> are getting glitches-- noise tends to occur randomly so plotting
    >>> t_{i+1}-t_i over the day will show you if glitches have occured. If they
    >>> differ from 1 second according to your computer clock ( and you have left
    >>> your computer clock just rinning and not resetting it suddenly-- even ntp
    >>> running on the outside sources is fine since it shifts the time slowly)
    >>> then you have noise.

    >
    >> Ok, I will, I am just not sure, how to do so. Here are some assumptions,
    >> please correct me, where I'm wrong:

    >
    >> cat /proc/interrupt shows me /counts/ of different interrupts, so I
    >> assume,that is not what I am looking for. There is a IO-APIC-edge timer
    >> interrupt (0) and a IO-APIC edge serial interrupt (4). The timer
    >> interrupt grows constantly and the serial grows a couple of thousands

    >
    > Uh, you have serious problems withe your PPS. It looks to me like it needs
    > to be buffered. It should grow by 1 every second, not thousands. It sounds
    > like there is extreme noise on your pps line which when it gets near
    > transition causes loads of interrupts. Not good. Find out why the pps
    > output is so so so noisy.
    >
    >
    >> every start of a second (looks like) and If then stops until the next
    >> second. I assume that's the one and that the interrupts are fired, als
    >> long as the pps-signal is incoming.

    >
    > No, the interrupt is fired ONCE per edge transition. And there should only
    > be ONE edge transition.
    >

    But buffering would bring new troubles like a delay and / or jitter, no?

    Anyway, I will hook the pps output to a scope and check if I can find
    something strange at the actual transitions. Using a simple analog
    voltmeter just made it "tick" once a second.. Looked ok so far.. Now it
    looks like there are thousands of transitions every second. Any other
    idea how i could figure what is going wrong?

    >
    >> Now I find cat /proc/irq/4/serial to reportI "Is a directory" and I find
    >> nothing in there, so I am a bit stuck, since I simply don't know what to
    >> record..

    >
    > You need to write a little interrupt service routine to timestamp each
    > interrupt. But the info you gave already says something is seriously wrong.
    >
    >
    >
    >
    >>> Note that serial port nmea is liable to be out by up to 1/2 sec and

    >> to have
    >>> a lot ( 10s of msec) jitter on it, since the end of the string

    >> received by
    >>> a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
    >>> characters 1/8 of a second to be delivered and will have a jitter of few
    >>> characters in length-- or about 10ms jitter)

    >
    >> I don't understand why you are mentioning this, maybe you got me wrong.
    >> I run the nmea gps over usb and the pps goes to the serial port. So
    >> there is no data exept for the pps on my serial line..

    >
    > There is data on the usb line, which is a serial type line for which his
    > comments apply.


    Ah, I see. Still the offset should be more or les constant and the
    jitter is not too big. So I could take care of the offset in ntp.conf .
    Then all I'd need is the gps to set the time within 0.4 seconds
    precisely and pps to take over then. Do you see any problems with that?


    The issue is, that the final device will have to function outside, with
    no internet around and - even worse - will not have more then 5 minuites
    or so after startup to have settled. But let's adress these problems,
    when the pps-isue is solved...

  7. Re: very confusing results though using pps and nmea

    nb@komeda-berlin.de (Nicola Berndt) writes:

    >Unruh schrieb:
    >> nb@komeda-berlin.de (Nicola Berndt) writes:
    >>
    >>>>> Now using the following ntp.conf I can see that things are working,
    >>> but not as expected. I would expect the pps clock to take over, no
    >>> matter what happens, since I understand it is either there or not and it
    >>> can't be wrong. Instead my system randomly marks either of these a false
    >>> ticker every now and then..
    >>>> Actually the pps CAN have noise on the line. I have found with my Garmin
    >>>> 18LVM that sometimes the interrupt fires of 6 or 7 hits in a few
    >>>> milliseconds,-- some sort of line noise coming in. Now, it is I admit
    >>> a bit
    >>>> of a kludge and I have not bothered to track down the problem-- bad
    >>> solder
    >>>> joint, TV interference,.....-- but it happens.
    >>>> What is best if you can record say a days worth of interrupt timings
    >>>> without haing the pps discipline your clock, and look at, or rather
    >>> plot (
    >>>> since looking at 86400 entries is liable to fry your brain) to see if you
    >>>> are getting glitches-- noise tends to occur randomly so plotting
    >>>> t_{i+1}-t_i over the day will show you if glitches have occured. If they
    >>>> differ from 1 second according to your computer clock ( and you have left
    >>>> your computer clock just rinning and not resetting it suddenly-- even ntp
    >>>> running on the outside sources is fine since it shifts the time slowly)
    >>>> then you have noise.

    >>
    >>> Ok, I will, I am just not sure, how to do so. Here are some assumptions,
    >>> please correct me, where I'm wrong:

    >>
    >>> cat /proc/interrupt shows me /counts/ of different interrupts, so I
    >>> assume,that is not what I am looking for. There is a IO-APIC-edge timer
    >>> interrupt (0) and a IO-APIC edge serial interrupt (4). The timer
    >>> interrupt grows constantly and the serial grows a couple of thousands

    >>
    >> Uh, you have serious problems withe your PPS. It looks to me like it needs
    >> to be buffered. It should grow by 1 every second, not thousands. It sounds
    >> like there is extreme noise on your pps line which when it gets near
    >> transition causes loads of interrupts. Not good. Find out why the pps
    >> output is so so so noisy.
    >>
    >>
    >>> every start of a second (looks like) and If then stops until the next
    >>> second. I assume that's the one and that the interrupts are fired, als
    >>> long as the pps-signal is incoming.

    >>
    >> No, the interrupt is fired ONCE per edge transition. And there should only
    >> be ONE edge transition.
    >>

    >But buffering would bring new troubles like a delay and / or jitter, no?


    Buffering? What buffering? You have hardware problems not software
    problems. the serial port interrupts are firing many times on an edge
    transition. That is a hardware problem. Either your serial port hardware is
    defective or the signal from the gps is really really noisy.

    >Anyway, I will hook the pps output to a scope and check if I can find
    >something strange at the actual transitions. Using a simple analog
    >voltmeter just made it "tick" once a second.. Looked ok so far.. Now it
    >looks like there are thousands of transitions every second. Any other
    >idea how i could figure what is going wrong?


    Nope. A scope is what I would use. Remember you want one that operates at
    at least 10MHz. How is the pps line connected?



    >>
    >>> Now I find cat /proc/irq/4/serial to reportI "Is a directory" and I find
    >>> nothing in there, so I am a bit stuck, since I simply don't know what to
    >>> record..

    >>
    >> You need to write a little interrupt service routine to timestamp each
    >> interrupt. But the info you gave already says something is seriously wrong.
    >>
    >>
    >>
    >>
    >>>> Note that serial port nmea is liable to be out by up to 1/2 sec and
    >>> to have
    >>>> a lot ( 10s of msec) jitter on it, since the end of the string
    >>> received by
    >>>> a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
    >>>> characters 1/8 of a second to be delivered and will have a jitter of few
    >>>> characters in length-- or about 10ms jitter)

    >>
    >>> I don't understand why you are mentioning this, maybe you got me wrong.
    >>> I run the nmea gps over usb and the pps goes to the serial port. So
    >>> there is no data exept for the pps on my serial line..

    >>
    >> There is data on the usb line, which is a serial type line for which his
    >> comments apply.


    >Ah, I see. Still the offset should be more or les constant and the
    >jitter is not too big. So I could take care of the offset in ntp.conf .
    >Then all I'd need is the gps to set the time within 0.4 seconds
    >precisely and pps to take over then. Do you see any problems with that?


    Nope that is what you are supposed to do. I run mine off the serial port
    and have the interrupt service routine timestamp the interrupt and put it
    into a read buffer on /dev/gpsint.




    >The issue is, that the final device will have to function outside, with
    >no internet around and - even worse - will not have more then 5 minuites
    >or so after startup to have settled. But let's adress these problems,
    >when the pps-isue is solved...


    That should not be too bad. If you choose the start up options for ntp
    correctly it should settle down withing that time.



  8. Re: very confusing results though using pps and nmea


    >Note that serial port nmea is liable to be out by up to 1/2 sec and to have
    >a lot ( 10s of msec) jitter on it, since the end of the string received by
    >a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
    >characters 1/8 of a second to be delivered and will have a jitter of few
    >characters in length-- or about 10ms jitter).


    That sort of jitter can easily be corrected.

    Has anybody looked at a scope to see if the leading edge of a NMEA
    string looks stable?


    --
    These are my opinions, not necessarily my employer's. I hate spam.


+ Reply to Thread