Re: [ntp:questions] Adjusting PPS offset
Maarten Wiltink wrote: In general PPS will be off by anything up to half a second in either direction, distributed uniformly. The sort of PPS source that ntpd normally uses is synchronised to the UTC second. A GPS source showing an apparent offset of 2ms is much more likely to be doing that than just randomly being that close. Your Caesium example is a pure frequency standard, but GPS needs an accurate common time across the satellites to provide a proper spatial solution. It needs very good relative time between satellites to work at all, and it needs quite good absolute time in order to exactly locate the fast moving satellites. In practice, it is marketed as a time standard as well as a position one. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Sat, Sep 03, 2011 at 08:05:21AM -0500, steven Sommars wrote: I monitored Garmin LVC (corrected firmware) NMEA time and saw variance of up to 50msec. I wonder if the variation in NMEA time depends on GPS signal quality. I'm wondering what is the cause of the variance too. With 18x LVC (firmware 3.70) I see errors up to 150 ms. That wouldn't be that bad if it was randomly distributed. A capture over 30 hours: http://mlichvar.fedorapeople.org/tmp/18x_nmea.png -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: On Sat, Sep 03, 2011 at 08:05:21AM -0500, steven Sommars wrote: I monitored Garmin LVC (corrected firmware) NMEA time and saw variance of up to 50msec. I wonder if the variation in NMEA time depends on GPS signal quality. I'm wondering what is the cause of the variance too. With 18x LVC (firmware 3.70) I see errors up to 150 ms. That wouldn't be that bad if it was randomly distributed. A capture over 30 hours: http://mlichvar.fedorapeople.org/tmp/18x_nmea.png This was captured how? Is that the beginning or the end of the nmea sentence? You have some where the offset is negative. Does this really mean that the nmea came in before the beginning of the second it referred to? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Adjusting PPS offset
On 2011-09-05, Maarten Wiltink maar...@kittensandcats.net wrote: unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnj67c9d.rn0.un...@wormhole.physics.ubc.ca... [...] If your PPS is off by 2ms, throw it away immediately. It is completely useless. In general PPS is off by less than 1 us and probably 100ns or so. In general PPS will be off by anything up to half a second in either direction, distributed uniformly. We are talking about PPS from a GPS receiver, not from a caesium oscillator. A Caesium oscillator is the steadiest frequency source known to man, but the phase is completely random. That does not make it useless. You simply have to determine the phase, and can then trust it will remain constant to a quite unreasonable degree (1e-13, this week?). [...] And 2ms for a bunch of network servers is bad. It seems that there is something along the route out of your system which is delaying the packets packets really badly but consistantly. Two milliseconds is bad? I live in the real world, with outbound links that are saturated for most of the day, and jitter five times that, and two milliseconds is a _good_ day on my network. It's also plenty good _enough_ for me, thank you very much, so I won't be digging into traffic prioritisation and all that to make it better. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote: On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: With 18x LVC (firmware 3.70) I see errors up to 150 ms. That wouldn't be that bad if it was randomly distributed. A capture over 30 hours: http://mlichvar.fedorapeople.org/tmp/18x_nmea.png This was captured how? Is that the beginning or the end of the nmea sentence? You have some where the offset is negative. Does this really mean that the nmea came in before the beginning of the second it referred to? No, I forgot to mention that was already with 0.5s correction applied. It's from gpsd which seems to make the NMEA receive timestamp after the message is processed. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Mon, Sep 5, 2011 at 8:04 AM, unruh un...@wormhole.physics.ubc.ca wrote: On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: On Sat, Sep 03, 2011 at 08:05:21AM -0500, steven Sommars wrote: I monitored Garmin LVC (corrected firmware) NMEA time and saw variance of up to 50msec. I wonder if the variation in NMEA time depends on GPS signal quality. I'm wondering what is the cause of the variance too. With 18x LVC (firmware 3.70) I see errors up to 150 ms. That wouldn't be that bad if it was randomly distributed. A capture over 30 hours: http://mlichvar.fedorapeople.org/tmp/18x_nmea.png This was captured how? Is that the beginning or the end of the nmea sentence? You have some where the offset is negative. Does this really mean that the nmea came in before the beginning of the second it referred to? These plots are made with an arbitrary zero point. The offsets is relative. By looking at the plot we don't know the true offset. That data is simply not provided. But it shows what we care about, the dispersion. We can always correct a fixed bias on the time using a Fudge in the ntp.conf but we can't do anything at all about the dispersion. The cause? My theory is that it can't be in the GPS data. It is where then the computed location would Bounce over a two kilometer circle. I think the error is in the conversion of internal data to ASCII. This requires many conversions of floating point internal numbers to ASCII and in a low-powered micro controller the time to convert one number depends on the value of the number. For example let's look at small integers. To convert 7 to ASCII we first load the hex value of ascii zero into a register. then we scan the bits in the number to be converted and add in a power of two (or not) based on if the bit is a one or zero. In the case of 7 we add 4, 2 and 1. If we convert a 4 we would only add 4. The variability is much, much more with floating point. Remember the little processor in the Garmin is tiny and runs slow. The thing is designed to run on battery power. When Processing NMEA on the computer, you can't do anything until you get the terminating end of line character. The PC then has to convert back to floating point. This can take a varying about of time too. But the computer is MUCH faster and so has much less variability Also remember that the NMEA spec only required the all NMEA sentences be output within the second and if the GPS stutters badly it is still in-spec. The PPS signal solves all this. The GPS 18 has one of the poorest timing spec, but even this unit's PPS is spec'd for only 1uS error (that would be one sigma about the mean) 1uS is usable to NTP. Better GPS have a single digit nanosecond error. And cheap eBay GPS will have two digit nanosecond error. I think only with timing equipment will you see specs that differ by a factor of 10,000. Look at any other gadget, the watts in a stereo, GHz clock on a computer. MPG on a car, You don't see one brand being 10,000X different like you do in GPSes. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote: On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: With 18x LVC (firmware 3.70) I see errors up to 150 ms. That wouldn't be that bad if it was randomly distributed. A capture over 30 hours: http://mlichvar.fedorapeople.org/tmp/18x_nmea.png This was captured how? Is that the beginning or the end of the nmea sentence? You have some where the offset is negative. Does this really mean that the nmea came in before the beginning of the second it referred to? No, I forgot to mention that was already with 0.5s correction applied. It's from gpsd which seems to make the NMEA receive timestamp after the message is processed. Never did understand that. Timestamping the beginning of the sentences is cheap enough and easy enough. Mind you, your fluctuations are far more than I would expect simply from variations in the length of the sentences. Are there more sentences delivered than just the one gpsd uses? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: On Sat, Sep 03, 2011 at 08:05:21AM -0500, steven Sommars wrote: I monitored Garmin LVC (corrected firmware) NMEA time and saw variance of up to 50msec. I wonder if the variation in NMEA time depends on GPS signal quality. I'm wondering what is the cause of the variance too. NMEA sentences are emitted when the GPS receiver is not busy with other things. So observed jitter is not suprising. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
Chris Albertson albertson.ch...@gmail.com wrote: The cause? My theory is that it can't be in the GPS data. It is where then the computed location would Bounce over a two kilometer circle. I think the error is in the conversion of internal data to ASCII. This requires many conversions of floating point internal numbers to ASCII and in a low-powered micro controller the time to convert one number depends on the value of the number. For example let's look at small integers. To convert 7 to ASCII we first load the hex value of ascii zero into a register. then we scan the bits in the number to be converted and add in a power of two (or not) based on if the bit is a one or zero. In the case of 7 we add 4, 2 and 1. If we convert a 4 we would only add 4. The variability is much, much more with floating point. Remember the little processor in the Garmin is tiny and runs slow. The thing is designed to run on battery power. I don't think this is the reason. I think it is this: the processor on the GPS receiver runs a multitasking operating system. It runs several tasks to control the hardware, to extract data from the receiver, to calculate a GPS fix based on that data, to calculate NMEA messages, and to send them to the serial line. There is no hard synchronization between those tasks, each task just sees what work it can do and then sleeps for some time. The rate at which the tasks sleep and wakeup determines a jitter that occurs between the calculated fix and the emitted messages. (emitting the messages probably also isn't the highest priority for the receiver's operating system) The processor in a GPS receiver usually is a quite powerful 32-bit embedded processor, that could do binary-ascii conversions much quicker than the datarate of the serial port. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-05, Chris Albertson albertson.ch...@gmail.com wrote: On Mon, Sep 5, 2011 at 8:04 AM, unruh un...@wormhole.physics.ubc.ca wrote: On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: On Sat, Sep 03, 2011 at 08:05:21AM -0500, steven Sommars wrote: I monitored Garmin LVC (corrected firmware) NMEA time and saw variance of up to 50msec. ?I wonder if the variation in NMEA time depends on GPS signal quality. I'm wondering what is the cause of the variance too. With 18x LVC (firmware 3.70) I see errors up to 150 ms. That wouldn't be that bad if it was randomly distributed. A capture over 30 hours: http://mlichvar.fedorapeople.org/tmp/18x_nmea.png This was captured how? Is that the beginning or the end of the nmea sentence? You have some where the offset is negative. Does this really mean that the nmea came in before the beginning of the second it referred to? These plots are made with an arbitrary zero point. The offsets is relative. By looking at the plot we don't know the true offset. That data is simply not provided. But it shows what we care about, the dispersion. We can always correct a fixed bias on the time using a Fudge in the ntp.conf but we can't do anything at all about the dispersion. He has now told us that the offset is .5 sec. The cause? My theory is that it can't be in the GPS data. It is Of course not. where then the computed location would Bounce over a two kilometer circle. I think the error is in the conversion of internal data to ASCII. This requires many conversions of floating point internal numbers to ASCII and in a low-powered micro controller the time to convert one number depends on the value of the number. For example let's look at small integers. To convert 7 to ASCII we first load the hex value of ascii zero into a register. then we scan the bits in the number to be converted and add in a power of two (or not) based on if the bit is a one or zero. In the case of 7 we add 4, 2 and 1. If we convert a 4 we would only add 4. The variability is much, much more with floating point. Remember the little processor in the Garmin is tiny and runs slow. The thing is designed to run on battery power. Depite that I have trouble believing that the internal conversion time varies by .2 sec. When Processing NMEA on the computer, you can't do anything until you get the terminating end of line character. The PC then has to convert back to floating point. This can take a varying about of time too. But the computer is MUCH faster and so has much less variability Of course you can. You can timestamp the beginning of the sentence and then decide what to do with that timestamp when you get the end of the sentence. gpsd does not do that. It timestamps only when you actually send the output to the shm memory segment long after the end of the sentence has been received. For timing purposes that is silly. Also remember that the NMEA spec only required the all NMEA sentences be output within the second and if the GPS stutters badly it is still in-spec. But it will put out say 5 sentences in that time. That means that each sentence should come out to far greater accuracy than .2 sec. The PPS signal solves all this. The GPS 18 has one of the poorest timing spec, but even this unit's PPS is spec'd for only 1uS error (that would be one sigma about the mean) 1uS is usable to NTP. Better GPS have a single digit nanosecond error. And cheap eBay GPS will have two digit nanosecond error. Of course pps will make things better. Again, that is not the question in this thread. The question is Can the nmea be used to set the time, and what kind of accuracy can one expect ( eg better than .128 sec so stepping is not an issue) You keep harping on pps. The OP does not have PPS. So the solution is a non-starter. Perhaps if you were to send him a gift of a gps receiver with pps he might be able to use it, but even then that is not sure (company regulations, etc) I think only with timing equipment will you see specs that differ by a factor of 10,000. Look at any other gadget, the watts in a stereo, GHz clock on a computer. MPG on a car, You don't see one brand being 10,000X different like you do in GPSes. Sure you do. My little sound card puts out milliwatts, while my stereo system puts out well over 100W. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-05, Rob nom...@example.com wrote: unruh un...@wormhole.physics.ubc.ca wrote: On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote: On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote: With 18x LVC (firmware 3.70) I see errors up to 150 ms. That wouldn't be that bad if it was randomly distributed. A capture over 30 hours: http://mlichvar.fedorapeople.org/tmp/18x_nmea.png This was captured how? Is that the beginning or the end of the nmea sentence? You have some where the offset is negative. Does this really mean that the nmea came in before the beginning of the second it referred to? No, I forgot to mention that was already with 0.5s correction applied. It's from gpsd which seems to make the NMEA receive timestamp after the message is processed. Never did understand that. Timestamping the beginning of the sentences is cheap enough and easy enough. It is not that easy because it requires communicating an extra item of information (the timestamp of the beginning of the message) all the way through the protocol stack alongside with the message. Since you already communicate the message all the way through the stack, adding on a few bytes to store a timestamp is not exactly a stretch. (you would not want to store it in a global variable, would you?) Right now, the timestamp is only taken at the moment the entire message has been received at the toplevel of the stack, parsed, and it has been found to contain a time of fix. Yes, I saw that-- actually it waits until it communicates that time fix on to ntp. It does not really matter when using NMEA because there is no definition of the message timing relative to the timestamp anyway. The time in the message is a time of fix. You simply don't know how long the receiver takes from computing the fix to sending the NMEA messages, and on many receivers this amount of time wildly varies. I guess I am surprized that it wildly varies. Those receivers can send out 5 or more messages per second. That means that each message only has about .2 sec to be sent out, and since the messages often start late even less time than that. From Lichvar's plots the fluctutation in the timestamp is about .4 sec. That is surprizing. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Mon, Sep 5, 2011 at 10:34 AM, unruh un...@wormhole.physics.ubc.ca wrote: You keep harping on pps. The OP does not have PPS. So the solution is a non-starter. Perhaps if you were to send him a gift of a gps receiver with pps he might be able to use it, but even then that is not sure (company regulations, etc) The OP has an observatory with automated computer controls. I assume an extra $30 to replace a GPS would not kill him. Put the Garmin 18 on a boat. That is it's best use. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
At 08:46 PM 9/5/2011, Chris Albertson wrote... On Mon, Sep 5, 2011 at 10:34 AM, unruh un...@wormhole.physics.ubc.ca wrote: You keep harping on pps. The OP does not have PPS. So the solution is a non-starter. Perhaps if you were to send him a gift of a gps receiver with pps he might be able to use it, but even then that is not sure (company regulations, etc) The OP has an observatory with automated computer controls. I assume an extra $30 to replace a GPS would not kill him. Put the Garmin 18 on a boat. That is it's best use. So send him $30, or a replacement GPS. It won't kill you. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-06, Chris Albertson albertson.ch...@gmail.com wrote: On Mon, Sep 5, 2011 at 10:34 AM, unruh un...@wormhole.physics.ubc.ca wrote: You keep harping on pps. The OP does not have PPS. So the solution is a non-starter. Perhaps if you were to send him a gift of a gps receiver with pps he might be able to use it, but even then that is not sure (company regulations, etc) The OP has an observatory with automated computer controls. I assume an extra $30 to replace a GPS would not kill him. Put the Garmin 18 on a boat. That is it's best use. He has a device which does what he needs to do. You decide that he really should do something that he says he does not want or need to do. and should therefor buy something else. I am sure that if you sent him a pps and helped him to set that up on a Sun hardware he would appreciate it. Otherwise why not help him do what he, not you, wants to do. There is a tinker variable (step) which alters the .128 sec step limit to whatever you want (including infinity if you set it to 0) So you might want to increase it to a few seconds for the nmea input. Then just use the nmea input from say gpsd to run ntpd on your system. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
