GPS clock for Linux - NTP

This is a discussion on GPS clock for Linux - NTP ; Hal Murray wrote: >>>I assume it's a software bug/feature. The problem is drift/wander >>>in the offset. The offset changes too slowly for normal >>>jitter filters to work on it. >>> http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif > > >>connected via serial/nmea or pps? > > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: GPS clock for Linux

  1. Re: GPS clock for Linux

    Hal Murray wrote:
    >>>I assume it's a software bug/feature. The problem is drift/wander
    >>>in the offset. The offset changes too slowly for normal
    >>>jitter filters to work on it.
    >>> http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif

    >
    >
    >>connected via serial/nmea or pps?

    >
    >
    > Direct USB.
    >
    > I have another one (using the SiRF chips) that is serial
    > via a serial-USB adapter. Same thing.

    There is a good chance that the direct USB thingy
    has the serial2USB converter just integrated
    ( replacing the rs232 levelshifter ).
    >
    >
    >
    >>that looks like some beat frequency effect.
    >>But it is much too slow/time too big
    >> to be sender and/or receiver uart clocking.

    >
    >
    > Yes. But I don't think it's a USB problem. I get much better
    > results with a Garmin GPS 18 USB. (Of course, what I don't know
    > about USB could fill ...)

    I had my fingers in USB recently, but ..

    >

    Hmm, you get one sentence per second?

    I will have to read up if the usb2serial ics have some kind of fifo
    included ( and enabled or not ). This could be an explanation.

    uwe


  2. Re: GPS clock for Linux

    Uwe Klein wrote:
    > I will have to read up if the usb2serial ics have some kind of fifo
    > included ( and enabled or not ). This could be an explanation.


    The basic problem with serial to USB converters is that the serial lines
    basically use transmission of characters whereas USB transmission is
    block-oriented.

    If a converter receives one character from the serial side it either can put
    that single character into an USB block and send that block immediately,
    which generates much overhead but low latency, or it could wait for a
    certain interval whether additional characters arrive, which could be
    packed together and sent in a single USB block. A new USB block is sent if
    either enough serial characters have arrived, or no characters are arriving
    anymore and a timeout occurs.

    The latter is good for USB throughput but generates a latency up to the
    timeout limit.

    So the behaviour should depend on the implementation of an individual
    converter type. BTW, similar problems arise with serial-to-LAN converters
    which redirect a serial data stream using IP packets.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: GPS clock for Linux

    Richard B. Gilbert wrote:
    > Terje Mathisen wrote:
    >> Using a USB port for the +5V line is the canonical solution: Very
    >> cheap, dependable, and no extra wall warts.
    >>
    >> Terje
    >>

    >
    > I have read claims here that the high and unpredictable latencies in USB
    > render it useless for time keeping!


    So, apparently not entirely useless. Using USB as a power source is
    getting to be highly popular. Witness the number of cup warmers, fan,
    etc. on the market. As long as you don't try to read the signal via
    USB, it should be okay.

    One thought occurs to me. Would it work to have the PPS signal go to a
    serial port but the actual NMEA sentences be read via USB? It seems to
    me if the total jitter of the USB still kept the snetences timing
    within half a second it would work.

    Brian Utterback

  4. Re: GPS clock for Linux

    Martin Burnicki wrote:

    > So the behaviour should depend on the implementation of an individual
    > converter type. BTW, similar problems arise with serial-to-LAN converters
    > which redirect a serial data stream using IP packets.


    I have used the standard pl2303 type converters
    and their bastard brethren ( to make an
    existing RS485 based daisychained system "USB ready" )

    communication to this system was a fast chitchat @38400 Baud:

    every second {
    foreach slot_used {
    send ,
    wait for response including linefeed,
    send // to deselect the current slot
    }
    }

    ~30 slots used.
    I never had any latency problems.

    Thus my guess is that these latency may lie in the firmware running
    on the sirf chipset.

    the gpsd people seem to have delved into this too:
    http://gpsd.berlios.de/performance.html

    Q: does the sirf chipset talk on its own or do you have to request
    sentences?
    ( the gpsd article gives the impression that its query .. response )


    uwe

  5. Re: GPS clock for Linux

    Once upon a time, Brian Utterback said:
    >So, apparently not entirely useless. Using USB as a power source is
    >getting to be highly popular. Witness the number of cup warmers, fan,
    >etc. on the market. As long as you don't try to read the signal via
    >USB, it should be okay.


    Another power source solution (especially for those like me that don't
    have an open RS232 port anyway) is the SIIG series of PCI/PCI-E RS232
    cards; they can optionally provide +5V or +12V on a pin.

    >One thought occurs to me. Would it work to have the PPS signal go to a
    >serial port but the actual NMEA sentences be read via USB? It seems to
    >me if the total jitter of the USB still kept the snetences timing
    >within half a second it would work.


    I am actually doing that right now (using the parallel port instead of
    the serial port in my case); it works fine.

    Has anyone tried isochronous mode USB to see if that helps with the
    latency? I have an FTDI USB-to-RS232 interface that supports
    isochronous mode, but I haven't had a chance to try it.

    --
    Chris Adams
    Systems and Network Administrator - HiWAAY Internet Services
    I don't speak for anybody but myself - that's enough trouble.

  6. Re: GPS clock for Linux

    Uwe Klein wrote:
    > Martin Burnicki wrote:
    >
    >> So the behaviour should depend on the implementation of an individual
    >> converter type. BTW, similar problems arise with serial-to-LAN converters
    >> which redirect a serial data stream using IP packets.

    >
    > I have used the standard pl2303 type converters
    > and their bastard brethren ( to make an
    > existing RS485 based daisychained system "USB ready" )
    >
    > communication to this system was a fast chitchat @38400 Baud:
    >
    > every second {
    > foreach slot_used {
    > send ,
    > wait for response including linefeed,
    > send // to deselect the current slot
    > }
    > }
    >
    > ~30 slots used.
    > I never had any latency problems.


    Some times ago we had made some tests with some serial-to-USB converters
    which are connected to the PC via USB and provide a serial port to which
    serial devices can be connected. We have been using our GPS receivers which
    send a serial time string once per second as soon as possible after a
    second changeover. The jitter of the serial output is 1 bit time depending
    on the baud rate, i.e. ~52 microseconds @ 19200.

    Some of the tested devices introduced a very low latency whereas others
    indroduced a much higher latency. So this depends in fact on the maybe the
    chip set and in any case the driver/firmware used for the converter.

    > Thus my guess is that these latency may lie in the firmware running
    > on the sirf chipset.


    Of course, if the firmware already inserts some latency then the
    serial-to-USB converter is not to blame and can not eliminate it.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  7. Re: GPS clock for Linux

    Hi Martin,

    Martin Burnicki wrote:

    > Some times ago we had made some tests with some serial-to-USB converters
    > which are connected to the PC via USB and provide a serial port to which
    > serial devices can be connected. We have been using our GPS receivers which
    > send a serial time string once per second as soon as possible after a
    > second changeover. The jitter of the serial output is 1 bit time depending
    > on the baud rate, i.e. ~52 microseconds @ 19200.

    Yes, if one needs further improvements one would try to sync the baudrate
    generator to the pps clock. with some tricks in the sending routine
    one then could transmit in a coherent fashion.
    Though you still retain the receiver uncertainty ( 1/16.. 1/64 of a baud cycle
    depending on async receiver used )
    >
    > Some of the tested devices introduced a very low latency whereas others
    > indroduced a much higher latency. So this depends in fact on the maybe the
    > chip set and in any case the driver/firmware used for the converter.

    Have you got vendor/product Id pairs for those? on windows/linux/bsd/* ?
    I'd be interested in related information.
    >
    >
    >>Thus my guess is that these latency may lie in the firmware running
    >>on the sirf chipset.

    >
    >
    > Of course, if the firmware already inserts some latency then the
    > serial-to-USB converter is not to blame and can not eliminate it.
    >
    > Martin

    uwe

  8. Re: GPS clock for Linux

    Brian Utterback wrote:
    > So, apparently not entirely useless. Using USB as a power source is
    > getting to be highly popular. Witness the number of cup warmers, fan,
    > etc. on the market. As long as you don't try to read the signal via USB,
    > it should be okay.
    >
    > One thought occurs to me. Would it work to have the PPS signal go to a
    > serial port but the actual NMEA sentences be read via USB? It seems to
    > me if the total jitter of the USB still kept the snetences timing within
    > half a second it would work.


    Sure, that should work, except that if you do have a serial port to
    receive the PPS signal on, using the same port for the rest of the
    signal simply makes sense.

    The USB-based GPSes all seem to be missing a dedicated PPS signal.

    Terje

    --
    -
    "almost all programming can be viewed as an exercise in caching"

  9. Re: GPS clock for Linux


    >Thus my guess is that these latency may lie in the firmware running
    >on the sirf chipset.


    That is my assumption.


    >Q: does the sirf chipset talk on its own or do you have to request
    >sentences?
    >( the gpsd article gives the impression that its query .. response )


    I'm running them in NMEA mode. They send a sentence every second.

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


  10. Re: GPS clock for Linux

    Uwe,

    sorry for the delay.

    Uwe Klein wrote:
    > Hi Martin,
    >
    > Martin Burnicki wrote:
    >
    >> Some times ago we had made some tests with some serial-to-USB converters
    >> which are connected to the PC via USB and provide a serial port to which
    >> serial devices can be connected. We have been using our GPS receivers
    >> which send a serial time string once per second as soon as possible after
    >> a second changeover. The jitter of the serial output is 1 bit time
    >> depending on the baud rate, i.e. ~52 microseconds @ 19200.

    > Yes, if one needs further improvements one would try to sync the baudrate
    > generator to the pps clock. with some tricks in the sending routine
    > one then could transmit in a coherent fashion.
    > Though you still retain the receiver uncertainty ( 1/16.. 1/64 of a baud
    > cycle depending on async receiver used )
    >>
    >> Some of the tested devices introduced a very low latency whereas others
    >> indroduced a much higher latency. So this depends in fact on the maybe
    >> the chip set and in any case the driver/firmware used for the converter.

    > Have you got vendor/product Id pairs for those? on windows/linux/bsd/* ?
    > I'd be interested in related information.


    Unfortunately not. We have just made some quick tests under windows, using
    some devices which you could buy at that time.

    This has been some time ago, and I don't have those devices available
    anymore.

    >>>Thus my guess is that these latency may lie in the firmware running
    >>>on the sirf chipset.

    >>
    >>
    >> Of course, if the firmware already inserts some latency then the
    >> serial-to-USB converter is not to blame and can not eliminate it.


    Yes, but what I meant is that the driver for the converter can insert some
    latency which degrades accuracy even if the sending device behaves good.

    We had tested some of our serial devices connected directly to a serial
    port, and then connected to a serial-to-USB converter which implements an
    additional COM port on the PC, which inserted several milliseconds of
    jitter.

    We have now some own USB devices which have USB support in the
    microcontroller. They can be connected directly to an USB slot, so we have
    more control on timing issues. However, there are still latencies in a
    millisecond range due to the USB low level drivers which come with the
    operating systems.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2