[ntp:questions] garmin 18x and linux
I am trying to connect a garmin 18x to a redhat 6 computer. According to minicom I get responses from the GPS, but ntpd does not seem to see the device. My /etc/ntp.conf file has it listed as server 127.127.20.0 mode 0 prefer I get the following when I run ntp manually: ntpd 4.2.4p8@1.1612-o Thu May 13 14:38:25 UTC 2010 (1) addto_syslog: precision = 0.107 usec addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled addto_syslog: Listening on interface #2 lo, ::1#123 Enabled addto_syslog: Listening on interface #3 eth0, fe80::f66d:4ff:fe92:6e2c#123 Enabled addto_syslog: Listening on interface #4 lo, 127.0.0.1#123 Enabled addto_syslog: Listening on interface #5 eth0, 10.1.2.98#123 Enabled addto_syslog: Listening on interface #6 virbr0, 192.168.122.1#123 Enabled addto_syslog: Listening on routing socket on fd #23 for interface updates local_clock: time 0 offset 0.00 freq 0.000 state 0 addto_syslog: kernel time sync status 2040 addto_syslog: frequency initialized -40.923 PPM from /var/lib/ntp/drift peer_crypto_clear: at 0 next 0 assoc ID 19059 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 19059 refid INIT refclock_setup fd 5 modem status: 0x6 refclock_ioctl: fd 5 flags 0x1 newpeer: 127.0.0.1->127.127.20.0 mode 3 vers 4 poll 6 10 flags 0x10a1 0x1 ttl 0 key local_clock: time 0 offset 0.00 freq -40.923 state 1 report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) nmea: gpsread 60 $GPRMC,195342,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*68 nmea: timecode 60 $GPRMC,195342,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*68 refclock_transmit: at 1 127.127.20.0 auth_agekeys: at 1 keys 1 expired 0 timer: refresh ts 0 timer: interface update nmea: gpsread 60 $GPRMC,195343,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*69 nmea: timecode 60 $GPRMC,195343,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*69 refclock_receive: at 1 127.127.20.0 nmea: gpsread 60 $GPRMC,195344,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*6E nmea: timecode 60 $GPRMC,195344,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*6E nmea: gpsread 60 $GPRMC,195345,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*6F nmea: timecode 60 $GPRMC,195345,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*6F addto_syslog: ntpd exiting on signal 2 Any sugguestions? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
"Greg Hennessy" wrote in message news:j3op2e$la7$1...@dont-email.me... I am trying to connect a garmin 18x to a redhat 6 computer. [] Any sugguestions? Can't help with Linux, but I suggest running the latest firmware (3.70) on your 18x. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-01, David J Taylor wrote: > "Greg Hennessy" wrote in message > news:j3op2e$la7$1...@dont-email.me... >> I am trying to connect a garmin 18x to a redhat 6 computer. > [] >> Any sugguestions? > > Can't help with Linux, but I suggest running the latest firmware (3.70) on > your 18x. The problem with the older firmware was that sometimes the time message would be sent more than one second after the PPS it was associated with. This meant that ntp could not associate the time with the right pulse, and the computer would get signals one second out occasionally. If that is not your problem then the firmware is probably not the solution. Of course having properly operating firmware is always good, but you should not put in a huge amount of time to update the firmware and then discover that it does nothing for your problem. > > Cheers, > David > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Thu, Sep 1, 2011 at 3:43 PM, David J Taylor wrote: > "Greg Hennessy" wrote in message > news:j3op2e$la7$1@dont-email.**me... > > I am trying to connect a garmin 18x to a redhat 6 computer. >> > [] > >> Any sugguestions? >> > > Can't help with Linux, but I suggest running the latest firmware (3.70) on > your 18x. > Also, don't expect any reasonable result until you connect the pulse per second to NTP. You only listed one line from the config file. Post more of it. And finally it helps a lot if you can add some pool servers to the config file. Add the PPS connection and pool servers and then post your result -- 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-02, Chris Albertson wrote: > Also, don't expect any reasonable result until you connect the pulse per > second to NTP. There is no PPS for the GPS18x PC. > You only listed one line from the config file. Post more of it. And > finally it helps a lot if you can add some pool servers to the config file. The only other line is the driftfile line. The computer is meant for control of a telescope and observatory, and isn't on the internet. Adding pool servers won't help for that reason. Given that ntp in debug mode shows gpsread showing NTP at least sees the GPRMC messages, can anyone sugguest why NTP never syncs? Is there additional debug flags that would be useful? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
As I said, Without a PPS signal you will not get reasonable results. If the GPS lacks the PPS get another GPS. They are cheap. Really nice units with timing specs literally 100X better than the 18X can be bought on eBay for $20 to $30. The problem with NMEA only setups is that (I think) the firmware takes non-determinic time to convert its internal data to ASCII. This means the sentence is never output at the exact second "tick". This error is enough to cause the GPS to fail NTPs clock selection algorithm. There are two classes of GPS. The first is the more common one. These are "navigation receivers". The second class are "timing receivers" these are special units that can take advantage of the fact that they KNOW their antenna is not moving.Knowing your exact position allows better timing solutions. The best timing GPS have nanosecond level error. You NMEA only unit likely has millisecond level error which is about 6 orders of magnitude worse. To use an expression. NTP has likely "voted it off the island". I said there were two classes of GPS, but really as long as a GPS has a PPS output it can be used for timing. These is considerable crossover.The one thing all dedicated timing receivers will have is the ability to tell it the antenna location and that it is not moving. OK, no Internet at the observatory. But try using pool servers while you are setting up and debugging. You will need additional ref clocks to verify your GPS. the "one second off" problem is common as are delays in the PPS being out of phase with the true UTC second "tick". I did this exact something a few years back. We built an astronomical camera specialized for photometry. I put NTP into the firmware so when the camera wrote out the FITS image files the time would be accurate. On Thu, Sep 1, 2011 at 7:24 PM, Greg Hennessy wrote: > On 2011-09-02, Chris Albertson wrote: > > Also, don't expect any reasonable result until you connect the pulse per > > second to NTP. > > There is no PPS for the GPS18x PC. > > > You only listed one line from the config file. Post more of it. And > > finally it helps a lot if you can add some pool servers to the config > file. > > The only other line is the driftfile line. The computer is meant for > control of a telescope and observatory, and isn't on the > internet. Adding pool servers won't help for that reason. > > Given that ntp in debug mode shows gpsread showing NTP at least sees > the GPRMC messages, can anyone sugguest why NTP never syncs? Is there > additional debug flags that would be useful? > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > -- 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-02, Chris Albertson wrote: > As I said, Without a PPS signal you will not get reasonable results. If > the GPS lacks the PPS get another GPS. They are cheap. Really nice units > with timing specs literally 100X better than the 18X can be bought on eBay > for $20 to $30. > > The problem with NMEA only setups is that (I think) the firmware takes > non-determinic time to convert its internal data to ASCII. This means the > sentence is never output at the exact second "tick". This error is enough > to cause the GPS to fail NTPs clock selection algorithm. No. ntp can use the GPS nmea sentences to time the clock to a few 10s of ms. -- you may need to fudge the time offset to make up for the delay of the nmea sentence. > > There are two classes of GPS. The first is the more common one. These are > "navigation receivers". The second class are "timing receivers" these are > special units that can take advantage of the fact that they KNOW their > antenna is not moving.Knowing your exact position allows better timing > solutions. The best timing GPS have nanosecond level error. You NMEA only > unit likely has millisecond level error which is about 6 orders of magnitude > worse. To use an expression. NTP has likely "voted it off the island". It would only vote it off the island if it had a better source. Since this is the only source the vote is rigged. It is always on the island. > > I said there were two classes of GPS, but really as long as a GPS has a PPS > output it can be used for timing. These is considerable crossover.The > one thing all dedicated timing receivers will have is the ability to tell it > the antenna location and that it is not moving. A gps with just nmea can be used for timing. Not as accurate, but then 10ms is only .1 seconds of arc on the telescope and I doubt he needs better accuracy than that. > > OK, no Internet at the observatory. But try using pool servers while you > are setting up and debugging. You will need additional ref clocks to verify > your GPS. the "one second off" problem is common as are delays in the PPS > being out of phase with the true UTC second "tick". > > I did this exact something a few years back. We built an astronomical > camera specialized for photometry. I put NTP into the firmware so when the > camera wrote out the FITS image files the time would be accurate. > Accurate to what accuracy? > > > > > On Thu, Sep 1, 2011 at 7:24 PM, Greg Hennessy wrote: > >> On 2011-09-02, Chris Albertson wrote: >> > Also, don't expect any reasonable result until you connect the pulse per >> > second to NTP. >> >> There is no PPS for the GPS18x PC. >> >> > You only listed one line from the config file. Post more of it. And >> > finally it helps a lot if you can add some pool servers to the config >> file. >> >> The only other line is the driftfile line. The computer is meant for >> control of a telescope and observatory, and isn't on the >> internet. Adding pool servers won't help for that reason. >> >> Given that ntp in debug mode shows gpsread showing NTP at least sees >> the GPRMC messages, can anyone sugguest why NTP never syncs? Is there >> additional debug flags that would be useful? >> >> ___ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions >> > > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-02, Chris Albertson wrote: > As I said, Without a PPS signal you will not get reasonable > results. I would appreciate advice on solving the problem I have, not buying the equipment you wished I have. I don't need microsecond timing. I don't need millisecond timing. I have a need to have my clock set to about a second, which a NMEA only gps should be able to solve. > The problem with NMEA only setups is that (I think) the firmware takes > non-determinic time to convert its internal data to ASCII. This means the > sentence is never output at the exact second "tick". This error is enough > to cause the GPS to fail NTPs clock selection algorithm. With only one source, how do I verify that your suspicion is correct? ntpq -p shows reach never changing from zero. > OK, no Internet at the observatory. But try using pool servers while you > are setting up and debugging. You will need additional ref clocks to verify > your GPS. My problem is not that my GPS reported time is bad. My problem is that ntp is not showing it is processing any of the data. Running ntpd with the -n and -d flags shows that input from the GPS goes into ntp, but reach never changes from zero. >> On 2011-09-02, Chris Albertson wrote: >> > Also, don't expect any reasonable result until you connect the pulse per >> > second to NTP. >> >> There is no PPS for the GPS18x PC. >> >> > You only listed one line from the config file. Post more of it. And >> > finally it helps a lot if you can add some pool servers to the config >> file. >> >> The only other line is the driftfile line. The computer is meant for >> control of a telescope and observatory, and isn't on the >> internet. Adding pool servers won't help for that reason. >> >> Given that ntp in debug mode shows gpsread showing NTP at least sees >> the GPRMC messages, can anyone sugguest why NTP never syncs? Is there >> additional debug flags that would be useful? >> >> ___ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions >> > > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Fri, Sep 02, 2011 at 02:24:44AM +, Greg Hennessy wrote: > Given that ntp in debug mode shows gpsread showing NTP at least sees > the GPRMC messages, can anyone sugguest why NTP never syncs? Is there > additional debug flags that would be useful? NTP isn't syncing because the GPS is reporting that it doesn't have a valid fix. > $GPRMC,195342,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*68 The "V" in the second data field means that the fix is invalid (it will be "A" if it's valid). See the documentation for the NMEA driver[1] for details on just what each of the fields mean. As an example of what you should see when the GPS is working properly, here's a recent NMEA sentence from my Garmin 18-LVC (with the location masked): $GPRMC,025652,A,.,N,x.,W,000.0,038.0,020911,002.6,W*xx [1] http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
Greg Hennessy wrote: > On 2011-09-02, Chris Albertson wrote: >> As I said, Without a PPS signal you will not get reasonable >> results. > > I would appreciate advice on solving the problem I have, not buying > the equipment you wished I have. I don't need microsecond timing. I > don't need millisecond timing. I have a need to have my clock set to > about a second, which a NMEA only gps should be able to solve. You will find (you have found) that by posting on this group, your message falls into the hands of a small group of people that will either base all their solutions on much more stringent requirements than you actually have (e.g. they don't consider using GPS serial messages because it is not possible to have millisecond precision with that), or they go on an on about how the requirements you post cannot be achieved at all and should be relaxed or be realized with atom clocks etc. This is usually partly the fault of the original poster (who omits requirements from the question or copies something from an external spec that mentions microseconds), but it is the fault of the people on this group, who are "time nuts" and blindly assume that everyone else is one too. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
Greg Hennessy wrote: On 2011-09-02, Chris Albertson wrote: As I said, Without a PPS signal you will not get reasonable results. I would appreciate advice on solving the problem I have, not buying the equipment you wished I have. I don't need microsecond timing. I don't need millisecond timing. I have a need to have my clock set to about a second, which a NMEA only gps should be able to solve. The problem with NMEA only setups is that (I think) the firmware takes non-determinic time to convert its internal data to ASCII. This means the sentence is never output at the exact second "tick". This error is enough to cause the GPS to fail NTPs clock selection algorithm. With only one source, how do I verify that your suspicion is correct? ntpq -p shows reach never changing from zero. You need to check the gps on a pc with ntp working correctly and having a low offset. I have four GPS, BR304, Garmin 18x-LVC, Sure and Motorola Oncore. I've not yet coupled up the Oncore. The NMEA output of the BR304 has too much variation of >> +/- 100ms and I gave up on use as ntp timesource. The Garmin and Sure are probably around +/- 50ms and could be used by ntpd. The 3.70 firmware for the Garmin would be a big improvement but but it has PPS which gets me within a few us same as with the Sure. If you can't couple it to an internet connected pc, the next best is to use the computers local clock as reference with the gps nmea marked as 'no select' and running loopstats, peerstats and summary utilities from your ntpd distribution. David OK, no Internet at the observatory. But try using pool servers while you are setting up and debugging. You will need additional ref clocks to verify your GPS. My problem is not that my GPS reported time is bad. My problem is that ntp is not showing it is processing any of the data. Running ntpd with the -n and -d flags shows that input from the GPS goes into ntp, but reach never changes from zero. On 2011-09-02, Chris Albertson wrote: Also, don't expect any reasonable result until you connect the pulse per second to NTP. There is no PPS for the GPS18x PC. You only listed one line from the config file. Post more of it. And finally it helps a lot if you can add some pool servers to the config file. The only other line is the driftfile line. The computer is meant for control of a telescope and observatory, and isn't on the internet. Adding pool servers won't help for that reason. Given that ntp in debug mode shows gpsread showing NTP at least sees the GPRMC messages, can anyone sugguest why NTP never syncs? Is there additional debug flags that would be useful? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-02, Courtney Bane wrote: > NTP isn't syncing because the GPS is reporting that it doesn't have a > valid fix. > >> $GPRMC,195342,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*68 Thank you. I will try to move it to a place with more visibility. And if I can find the person who thought having a 'V' indicate not valid data, I will hit him with a nerf bat. Anyone want to guess where my telescope is located? ;) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
Rob wrote: You will find (you have found) that by posting on this group, your message falls into the hands of a small group of people that will either base all their solutions on much more stringent requirements than you actually have (e.g. they don't consider using GPS serial messages because it is not possible to have millisecond precision with that), or they go on an on about how the requirements you post cannot be achieved at all and should be relaxed or be realized with atom clocks etc. NTP isn't designed to work at accuracies worse than a few 10s of milliseconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Fri, Sep 2, 2011 at 12:06 AM, unruh wrote: > > No. ntp can use the GPS nmea sentences to time the clock to a few 10s of > ms. -- you may need to fudge the time offset to make up for the delay of > the nmea sentence. > > Yes, maybe NTP can but not with this Garmin 18 unit. Some GPSes are better than others. And like I said very good units are available for not much money. These Garmin units have problems with their NMEA timing. I tried to use an even earlier unit and had the same result. Not worth knocking your head on a wall when good timing units are available for cheap. The problem is not just with the timing of the serial data coming out of the GPS. There are FIFO buffers in the Serial port in the computer and in the OS.PPs is handled by a very low latency interrupt driven interface that tie stamps the PPS. 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-02, David Woolley wrote: > Rob wrote: > >> >> You will find (you have found) that by posting on this group, your message >> falls into the hands of a small group of people that will either base >> all their solutions on much more stringent requirements than you actually >> have (e.g. they don't consider using GPS serial messages because it is >> not possible to have millisecond precision with that), or they go on an >> on about how the requirements you post cannot be achieved at all and should >> be relaxed or be realized with atom clocks etc. > > NTP isn't designed to work at accuracies worse than a few 10s of > milliseconds. ?? Where does this come from? While it is true that there is the 128ms rule ( which I believe can be adjusted) but where is this coming from? And besides, Garmin GPS nmea can control to better than 10ms. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-03, Chris Albertson wrote: > On Fri, Sep 2, 2011 at 12:06 AM, unruh wrote: > >> >> No. ntp can use the GPS nmea sentences to time the clock to a few 10s of >> ms. -- you may need to fudge the time offset to make up for the delay of >> the nmea sentence. >> >> > Yes, maybe NTP can but not with this Garmin 18 unit. Some GPSes are better > than others. And like I said very good units are available for not much > money. These Garmin units have problems with their NMEA timing. I tried > to use an even earlier unit and had the same result. Not worth knocking > your head on a wall when good timing units are available for cheap. > > The problem is not just with the timing of the serial data coming out of the > GPS. There are FIFO buffers in the Serial port in the computer and in the > OS.PPs is handled by a very low latency interrupt driven interface that > tie stamps the PPS. I do not argue that pps is not better than nmea. It is. But that is irrelevant. The question is whether or not nmea can be used to control the system to a few ms. If you are saying that this particular nmea unit has such huge fluctuations, then it would be good to have some backing for that. The FIFO buffers are certainly able to better than 100ms. And the OS does not take that much time. > > 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
unruh wrote: ?? Where does this come from? While it is true that there is the 128ms rule ( which I believe can be adjusted) but where is this coming from? And besides, Garmin GPS nmea can control to better than 10ms. Basically the 128ms, but one doesn't want to anywhere close to that 128ms. Note I said a few tens, which could be say 40-50. I was replying to someone that said they only wanted time to 1 second and I was really pointing out that there can be time sources that would satisfy that requirement, but would be unsuitable for use with NTP, so by asking on an NTP newsgroup, they are effectively asking for times that are significantly better than 128ms. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
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. On Fri, Sep 2, 2011 at 11:19 PM, unruh wrote: > On 2011-09-02, David Woolley wrote: > > Rob wrote: > > > >> > >> You will find (you have found) that by posting on this group, your > message > >> falls into the hands of a small group of people that will either base > >> all their solutions on much more stringent requirements than you > actually > >> have (e.g. they don't consider using GPS serial messages because it is > >> not possible to have millisecond precision with that), or they go on an > >> on about how the requirements you post cannot be achieved at all and > should > >> be relaxed or be realized with atom clocks etc. > > > > NTP isn't designed to work at accuracies worse than a few 10s of > > milliseconds. > > ?? Where does this come from? While it is true that there is the 128ms > rule ( which I believe can be adjusted) but where is this coming from? > And besides, Garmin GPS nmea can control to better than 10ms. > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-03, David Woolley wrote:
> unruh wrote:
>
>> ?? Where does this come from? While it is true that there is the 128ms
>> rule ( which I believe can be adjusted) but where is this coming from?
>> And besides, Garmin GPS nmea can control to better than 10ms.
>>
>
> Basically the 128ms, but one doesn't want to anywhere close to that
> 128ms. Note I said a few tens, which could be say 40-50.
I believe that the 128ms is user adjustable.
>
> I was replying to someone that said they only wanted time to 1 second
> and I was really pointing out that there can be time sources that would
> satisfy that requirement, but would be unsuitable for use with NTP, so
> by asking on an NTP newsgroup, they are effectively asking for times
> that are significantly better than 128ms.
Which the nmea sentence from a gps certainly should be.
I also believe it takes a few 128ms before ntp will step. It would be
grossly irresponsible if it stepped each time it got a 128ms (just
imagine the havoc when a single return packet was delayed by 1 second,
which can happen). Thus that time source would have to have a persistant
jitter of greater than 128ms. Ie, while you concern may be right it is
also irrelevant to the discussion here.
Can one use a Garmin 18x nmea and ntp to control the clock to better
than 1 second? Yes.
Also note that this is an ntp newsgroup, NOT an ntpd newsgroup. Ie,
there exist many implimentations of ntp which are not ntpd and this is
also the newsgroup for them. Many of them do NOT have the 128ms rule,
which has always struck me a totally bizarre anyway ("We have a 500PPM
max rule, except when we run the system at infinite slow rate.")
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Sep 3, 10:35 am, unruh wrote: > > Can one use a Garmin 18x nmea and ntp to control the clock to better > than 1 second? Yes. > I ran ntp at our community TV station using a USGlobalSat EM-406 module with no working PPS (it has the pin, but I could never get pulses out of it.) NTPd (the Meinberg distribution) ran fine on this module once I got the offset figured out. I don't recall what figures I got since I replaced the module with a Garmin GPS-18x LVC with a working PPS but 50 mS sounds about right. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-03, David Woolley wrote: > I was replying to someone that said they only wanted time to 1 second As the person who started this, I wanted time to better than one second, and claimed I didn't need time to the microsecond, nor even the milli second, but I had a need for something I thought was possible with a NMEA only gps source. If you want to tell me that NTP isn't designed to work with an NMEA only source, fine, but if so, you are the first person to make such an argument. > by asking on an NTP newsgroup, they are effectively asking for times > that are significantly better than 128ms. And since time better than 128 ms meets my requirement, I asked here. ___ 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 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] garmin 18x and linux
On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote: > On 2011-09-05, Miroslav Lichvar 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 wrote: > On 2011-09-05, Miroslav Lichvar 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 wrote: > On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote: >> On 2011-09-05, Miroslav Lichvar 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
unruh wrote: > On 2011-09-05, Miroslav Lichvar wrote: >> On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote: >>> On 2011-09-05, Miroslav Lichvar 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. (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. 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. ___ 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 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 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 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 wrote: > On Mon, Sep 5, 2011 at 8:04 AM, unruh wrote: >> On 2011-09-05, Miroslav Lichvar 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 wrote: > unruh wrote: >> On 2011-09-05, Miroslav Lichvar wrote: >>> On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote: On 2011-09-05, Miroslav Lichvar 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 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 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 wrote: > On Mon, Sep 5, 2011 at 10:34 AM, unruh 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
Re: [ntp:questions] garmin 18x and linux
On Mon, Sep 05, 2011 at 04:47:20PM +, unruh wrote: > On 2011-09-05, Miroslav Lichvar wrote: > > 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? There are other messages enabled (I like to monitor the visibility of satellites in cgps), but RMC and GGA are transmitted first. The baud rate is set to 115200. The measured time it takes to transmit one batch is about 85 +/- 10 ms. Here is another capture, this time only over couple hours, but it's the offset to the beginning of the transfer (i.e. start of RMC). http://mlichvar.fedorapeople.org/tmp/18x_nmea2.png The offset still moves in a 300ms range. -- 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-06, Chris Albertson wrote: > 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. If you want to tell my supervisor why a perfectly good GPS needs to be thrown away and a new one purchased, go ahead. Where do I find the $30 dollar GPS with serial cable for the PPS signal? However, I'm perfectly happy with my GPS now that I've moved it to a place with better visibility. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-06, Greg Hennessy wrote: > On 2011-09-06, Chris Albertson wrote: >> 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. > > If you want to tell my supervisor why a perfectly good GPS needs to be > thrown away and a new one purchased, go ahead. > > Where do I find the $30 dollar GPS with serial cable for the PPS > signal? Well, it is actually a $150 dollar unit. $30 for the unit, and $120 for your time to solder a couple of wires across the board to get the pps out to the serial port and make a box to house the receiver :-) Example is the Sure unit eg-- http://www.satsignal.eu/ntp/Sure-GPS.htm > > However, I'm perfectly happy with my GPS now that I've moved it to a > place with better visibility. I would keep an eye on ntpd to make sure that the .128 sec step threshold does not get in your way. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-06, unruh wrote: > Well, it is actually a $150 dollar unit. $30 for the unit, and $120 for > your time to solder a couple of wires across the board to get the pps > out to the serial port and make a box to house the receiver :-) Why don't the manufacturers provide the PPS signal to the serial port themselves? Is it meant to be NMEA only? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
Greg Hennessy wrote: On 2011-09-06, unruh wrote: Well, it is actually a $150 dollar unit. $30 for the unit, and $120 for your time to solder a couple of wires across the board to get the pps out to the serial port and make a box to house the receiver :-) Why don't the manufacturers provide the PPS signal to the serial port themselves? Is it meant to be NMEA only? 1) It will be intended for embedded system use; 2) TTL outputs are specified for rise times and propagation delays of the order of 10ns, whereas RS 232 isn't really specified for much better than 1 microsecond. RS232C is designed to driver medium length lines, whereas TTL wasn't really intended to drive more than about 10 inches. Both are mismatched to the transmission line. TTL aims to cope with reflections by making the line too short, whereas RS232 attempts to do so by controlling rise time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
> Why don't the manufacturers provide the PPS signal to the serial port > themselves? Is it meant to be NMEA only? You are thinking that all GPS recievers are only used for NTP. There are many other uses of PPS that do not involve the serial port on a PC. In fact I'd guess that MOST GPS used for precision timing do not send PPS to a computer. A common use a PPS is to phase lock a local oscillator to prevent it from drifting. If cost is an issue there are even lower priced options then the one from Sure Electronics. Older Moterola UT+ receivers sell for $18. These actually have better specs and the signals are all run out to a 10-pin header, no soldering. If you have $100 you can get a "Thunderbolt" GPS which is ideal for precision timing. There are a wide range of products and you can find some that come with USA based tech support and are "turn key". Or you buy the $18 unit from China solder some parts together. You can find anything you want. -- 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 6 September 2011 23:02, Chris Albertson wrote: > > Why don't the manufacturers provide the PPS signal to the serial port > > themselves? Is it meant to be NMEA only? > > If cost is an issue there are even lower priced options then the one > from Sure Electronics. Older Moterola UT+ receivers sell for $18. > These actually have better specs and the signals are all run out to a > 10-pin header, no soldering. > I second this. I am looking at a Motorola Oncore UT+ unit I got on ebay for about 10 USD. I believe the antenna cost me 7 USD. :-) A quick trip to the local electronics shop and with a bit of soldering I have a board that gets the power from USB and returns the GPS signals to NTP. Oncore is connected to this board by a flat 10 wire cable. Quite neat! :-) The performance is quite impressive: oncore# uptime; ntpq -p; ntpdc -c kerninfo 12:02AM up 2:07, 1 user, load averages: 0.00, 0.00, 0.00 remote refid st t when poll reach delay offset jitter == oGPS_ONCORE(0) .GPS.0 l7 16 3770.000 -0.001 0.001 canon.inria.fr .GPSi. 1 u 34 64 377 49.0540.621 0.383 ptbtime1.ptb.de .PTB.1 u 36 64 377 66.4750.864 0.316 ntp.ien.it .CTD.1 u6 64 377 52.0640.452 0.263 ntp02.oal.ul.pt 194.117.9.1382 u 27 64 3779.4860.565 0.453 ntp04.oal.ul.pt 194.117.9.1382 u 34 64 377 10.109 -0.831 0.235 Router7.Lisboa. 193.136.250.246 2 u 27 64 3778.1810.508 0.258 Router15.Porto. 193.136.250.246 2 u 13 64 377 12.5380.528 0.129 pll offset: -8.37e-07 s pll frequency:-32.057 ppm maximum error:0.004234 s estimated error: 1e-06 s status: 2107 pll ppsfreq ppstime ppssignal nano pll time constant:4 precision:1e-09 s frequency tolerance: 496 ppm pps frequency:-32.057 ppm pps stability:0.016 ppm pps jitter: 1.811e-06 s calibration interval: 256 s calibration cycles: 50 jitter exceeded: 5 stability exceeded: 0 calibration errors: 3 I've tried Garmin 18 LVC and Sure. Not want to start a war here but for the specifications and price Oncore beats both. :-) Just my 2c. Cheers, Miguel ___ 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 wrote: > You are thinking that all GPS recievers are only used for NTP. Not exactly. I'm thinking that any GPS receiver that calculatates a PPS that doesn't provide it to the outside has wasted money. If a PPS is provided by a BNC connector instead of a serial port that makes sense, but it seems (to me) to be of only small incremental cost to provide the PPS to a serial port connection. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-07, Miguel Gonçalves wrote: > The performance is quite impressive: > > oncore# uptime; ntpq -p; ntpdc -c kerninfo > 12:02AM up 2:07, 1 user, load averages: 0.00, 0.00, 0.00 > remote refid st t when poll reach delay offset jitter >=== > oGPS_ONCORE(0) .GPS. 0 l7 16 3770.000 -0.001 0.001 > canon.inria.fr .GPSi.1 u 34 64 377 49.0540.621 0.383 > ptbtime1.ptb.de .PTB. 1 u 36 64 377 66.4750.864 0.316 > ntp.ien.it .CTD. 1 u6 64 377 52.0640.452 0.263 > ntp02.oal.ul.pt 194.1... 2 u 27 64 3779.4860.565 0.453 > ntp04.oal.ul.pt 194.1... 2 u 34 64 377 10.109 -0.831 0.235 > Router7.Lisboa. 193.1... 2 u 27 64 3778.1810.508 0.258 > Router15.Porto. 193.1... 2 u 13 64 377 12.5380.528 0.129 Nice snapshot. Can you use peer.awk to summarize a week of peerstats files? -- Steve Kostecke 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
On 7 September 2011 05:07, unruh wrote: > > I've tried Garmin 18 LVC and Sure. Not want to start a war here but for > the > > specifications and price Oncore beats both. :-) > > Beats them how? What measurements have you made of those two units in > comparison with the oncore? > I am not disputing but would like evidence rather than mystical > feelings. > I have no pretension to be a GPS expert. I am an IT guy and therefore I rely on others opinions/tests but 1. Oncore (as is Resolution T from Trimble) is a GPS specifically designed to do GPS time transfer and has features like position hold and TRAIM. This is a fact. I assume (and my rational thinking is usually right) that this must be better than a positional GPS receiver that has PPS like Garmin 18 and Sure. This is my belief... As lawyers in court would put "this is MY opinion". Of course, if I don't back my statements with evidence and facts I expect people to take what I say with a grain of salt and judge themselves. 2. I could buy a lot of gear, study a lot, and prove this, but in my line of work I get better things to spend my time on. And even then, Garmin and Sure could be as good as Oncore. But even then Oncore was cheaper. Did you really expect I would do this? 3. You could also prove I am wrong. I am not asking you to do this. :-) I will stick to 1 and 2. > Just my 2c. > Is it worth that? > It's actually worth much more. This is just a typical Internet used expression, that I've seen over the last 18 years, when people barge in discussions just to add their small contribution. Additionally, please bear in mind that not everyone in this list is an English native speaker. Being Canadian, you most probably speak English and French. I speak them both and also Portuguese (native language). I believe that your Portuguese is not as good as my English or French. Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Wed, 7 Sep 2011, Miguel Gonçalves wrote: On 7 September 2011 05:07, unruh wrote: > I've tried Garmin 18 LVC and Sure. Not want to start a war here but for the specifications and price Oncore beats both. :-) Beats them how? What measurements have you made of those two units in comparison with the oncore? I am not disputing but would like evidence rather than mystical feelings. I have no pretension to be a GPS expert. I am an IT guy and therefore I rely on others opinions/tests but 1. Oncore (as is Resolution T from Trimble) is a GPS specifically designed to do GPS time transfer and has features like position hold and TRAIM. This is a fact. I assume (and my rational thinking is usually right) that this must be better than a positional GPS receiver that has PPS like Garmin 18 and Sure. This is my belief... As lawyers in court would put "this is MY opinion". Of course, if I don't back my statements with evidence and facts I expect people to take what I say with a grain of salt and judge themselves. And I looked at a paper from 2003 in which the encore was tested against a survey class/timing gps usnit and found to be 160ns later than tht unit. 2. I could buy a lot of gear, study a lot, and prove this, but in my line of work I get better things to spend my time on. And even then, Garmin and Sure could be as good as Oncore. But even then Oncore was cheaper. Did you really expect I would do this? That is fine, but why then are you saying that it is better? Cheaper, perhaps ( althoubh comparing aftermarket second hand antennaless unit price with a new price seems a bit disingenuous.) I have nothing against the encore. But I know of nothing for it either except an advertising bunff claim that its accuracy is far higher than anything I believe possible. 3. You could also prove I am wrong. I am not asking you to do this. :-) Oh come on. You are starting to sound like Fox news-- make any unsupported outrageous statement and tell others it is up to them to prove you wrong. I will stick to 1 and 2. Just my 2c. Is it worth that? It's actually worth much more. This is just a typical Internet used expression, that I've seen over the last 18 years, when people barge in discussions just to add their small contribution. I have not seen the evidence that, on this topic, it is worth that much. And when I ask for evidence I get the above. Additionally, please bear in mind that not everyone in this list is an English native speaker. Being Canadian, you most probably speak English and French. I speak them both and also Portuguese (native language). I believe that your Portuguese is not as good as my English or French. ?? What does "english speaker" have to do with anything? Yes, I know the overused phrase. I also know it is ironic (since the speaker almost always feels that his opinion just expressed is worth far more than that and it is an attempt at assuming an "aw shucks, look at how humble I am". Which was the reason for my comment. Cheers, Miguel -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
2011/9/7 Miguel Gonçalves : > On 7 September 2011 05:07, unruh wrote: > >> > I've tried Garmin 18 LVC and Sure. Not want to start a war here but for >> the >> > specifications and price Oncore beats both. :-) >> >> Beats them how? What measurements have you made of those two units in >> comparison with the oncore? >> I am not disputing but would like evidence rather than mystical >> feelings. Simply read the manufacture's specifications.The most notable difference is the one sigma error on the time of the PPS. The newest Oncore units (sold new by Synergy) are at the 2nS level while Garmin claims 1uS. That is a 500X difference. The older UT+ version on eBay typically com in at about 55nS (one sigma) and these sell for under $20. In the specific case we have here the Garmin unit lacks any PPS at all. That is a HUGE difference. The other huge difference is the ability of the Oncore units to self-survey their location, typically to within a third of a foot over a 2 hour period. They then use this known fixed location in their time solutions and greatly reduce uncertainty. They use a binary protocol of the serial wire that dumps a lot of detailed information and the timing is "good" bt not measured One thing that comes over this bnary stream is the exact time relative to UTC of the last pulse. And an error estimate. Som for example it might say "xxx.2314 plus minus 35nS" This is functionality not present in any NMEA based GPS. 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 Wed, 7 Sep 2011, Chris Albertson wrote: 2011/9/7 Miguel Gonçalves : On 7 September 2011 05:07, unruh wrote: > I've tried Garmin 18 LVC and Sure. Not want to start a war here but for the specifications and price Oncore beats both. :-) Beats them how? What measurements have you made of those two units in comparison with the oncore? I am not disputing but would like evidence rather than mystical feelings. Simply read the manufacture's specifications.The most notable I do not believe manufacturer's specs, especially not when they seem to badly overstate the performance. difference is the one sigma error on the time of the PPS. The newest Oncore units (sold new by Synergy) are at the 2nS level while Garmin Yes, and I simply do not believe this. Note that Oncore has claimed this accuracy since at least 2003 ( ie old units). claims 1uS. That is a 500X difference. The older UT+ version on eBay I believe we were comparing Oncore to Sure, not Oncore to GPS18LVM typically com in at about 55nS (one sigma) and these sell for under $20. 55ns I might believe. In the specific case we have here the Garmin unit lacks any PPS at all. That is a HUGE difference. No argument. But there the argument was not the PPS timing but whether or not it met the OP's needs. It did. That is all that is required. The other huge difference is the ability of the Oncore units to self-survey their location, typically to within a third of a foot over a 2 hour period. They then use this known fixed location in their time solutions and greatly reduce uncertainty. That may, or may not, be an advantage, depending on how they do it. They use a binary protocol of the serial wire that dumps a lot of detailed information and the timing is "good" bt not measured One thing that comes over this bnary stream is the exact time relative to UTC of the last pulse. And an error estimate. Som for example it might say "xxx.2314 plus minus 35nS" This is functionality not present in any NMEA based GPS. Agreed, but also irrelevant. And I am confused. You were claiming that the pulses were within 2ns of utc, and your example here is 23us out from utc. That is 1 times different. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Wed, Sep 7, 2011 at 8:36 AM, Bill Unruh wrote: > On Wed, 7 Sep 2011, Chris Albertson wrote: > >> 2011/9/7 Miguel Gonçalves : >>> >>> On 7 September 2011 05:07, unruh wrote: >>> > I've tried Garmin 18 LVC and Sure. Not want to start a war here but for the > > specifications and price Oncore beats both. :-) Beats them how? What measurements have you made of those two units in comparison with the oncore? I am not disputing but would like evidence rather than mystical feelings. >> >> Simply read the manufacture's specifications. The most notable > > I do not believe manufacturer's specs, especially not when they seem to > badly > overstate the performance. Read these papers. THey are old and were done with the older version of Oncore with are not as good as current version. But in all cases the units performed quite a bit better than specs. If anything Motorola was being conservative. You'd expect this as the units are marketed to sophistication users who would have in-house time meteorology labs. http://tycho.usno.navy.mil/ptti/1997/Vol%2029_31.pdf http://tycho.usno.navy.mil/ptti/1996/Vol%2028_37.pdf http://www.febo.com/time-freq/gps/performance/index.html 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
Comments bellow... 2011/9/7 Bill Unruh > On Wed, 7 Sep 2011, Miguel Gonçalves wrote: > > On 7 September 2011 05:07, unruh wrote: >> >> > I've tried Garmin 18 LVC and Sure. Not want to start a war here but for >>> the >>> specifications and price Oncore beats both. :-) >>> >>> Beats them how? What measurements have you made of those two units in >>> comparison with the oncore? >>> I am not disputing but would like evidence rather than mystical >>> feelings. >>> >>> >> I have no pretension to be a GPS expert. I am an IT guy and therefore I >> rely >> on others opinions/tests but >> >> 1. Oncore (as is Resolution T from Trimble) is a GPS specifically designed >> to do GPS time transfer and has features like position hold and TRAIM. >> This >> is a fact. I assume (and my rational thinking is usually right) that this >> must be better than a positional GPS receiver that has PPS like Garmin 18 >> and Sure. This is my belief... As lawyers in court would put "this is MY >> opinion". Of course, if I don't back my statements with evidence and facts >> I >> expect people to take what I say with a grain of salt and judge >> themselves. >> > > And I looked at a paper from 2003 in which the encore was tested against a > survey class/timing gps usnit and found to be 160ns later than tht unit. I thought Oncore (not encore) was a timing GPS unit. I might be wrong. But wait... NO! It is a timing unit. > > >> 2. I could buy a lot of gear, study a lot, and prove this, but in my line >> of >> work I get better things to spend my time on. And even then, Garmin and >> Sure >> could be as good as Oncore. But even then Oncore was cheaper. Did you >> really >> expect I would do this? >> > > That is fine, but why then are you saying that it is better? Cheaper, > perhaps > ( althoubh comparing aftermarket second hand antennaless unit price with > a > new price seems a bit disingenuous.) I have nothing against the encore. But > I > know of nothing for it either except an advertising bunff claim that its > accuracy is far higher than anything I believe possible. Call it advertising... Believe what you want. I believe in a unit that was tested at USNO and is still today used worldwide by reputable entities. Want to know which ones? Use Google! > >> 3. You could also prove I am wrong. I am not asking you to do this. :-) >> > > Oh come on. You are starting to sound like Fox news-- make any unsupported > outrageous statement and tell others it is up to them to prove you wrong. I don't watch Fox News. What I am saying is that everyone should use logic and reason against everything that is thrown at them. Some people do but recently I've seen that a lot of people that don't. It's easier. I also expect that people in this list have huge amounts of logic and reasoning and will judge all the opinions to come to a solution. > > I will stick to 1 and 2. >> >> Just my 2c. >>> Is it worth that? >>> >>> >> It's actually worth much more. This is just a typical Internet used >> expression, that I've seen over the last 18 years, when people barge in >> discussions just to add their small contribution. >> > > I have not seen the evidence that, on this topic, it is worth that much. > And > when I ask for evidence I get the above. > > >> Additionally, please bear in mind that not everyone in this list is an >> English native speaker. Being Canadian, you most probably speak English >> and >> French. I speak them both and also Portuguese (native language). I believe >> that your Portuguese is not as good as my English or French. >> > > ?? What does "english speaker" have to do with anything? Yes, I know the > overused phrase. I also know it is ironic (since the speaker almost always > feels that his opinion just expressed is worth far more than that and it is > an > attempt at assuming an "aw shucks, look at how humble I am". Which was the > reason for my comment. > You assume too much. When I say "A" I mean "A", not something else. I am not being ironic. So please don't say things I didn't say. And "English speaker" is so you don't think I am being ironic. Got it? For me this discussion has ended. I have better things to do. I also agree with Chris, go and read the papers. Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-07, Chris Albertson wrote: > The most notable > difference is the one sigma error on the time of the PPS. The newest > Oncore units (sold new by Synergy) are at the 2nS level while Garmin > claims 1uS. I'm not even sure the USNO provided time sync to GPS is at the 2nS level. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
At 12:32 PM 9/7/2011, Greg Hennessy wrote... I'm not even sure the USNO provided time sync to GPS is at the 2nS level. USNO has this to say: "GPS time is automatically steered to UTC(USNO) on a daily basis to keep system time within one microsecond of UTC(USNO), but during the last several years has been within a few hundred nanoseconds." But, it's often much better. The past week, it's well under 10 ns difference, the majority of the time. More info here: http://tycho.usno.navy.mil/gpstt.html ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Wed, Sep 7, 2011 at 9:32 AM, Greg Hennessy wrote: > I'm not even sure the USNO provided time sync to GPS is at the 2nS > level. This is not an accuracy issue. it is an intentional offset to account for the earth's slowing rotation rate. here are various time scales and at this level they only more or less ageree as each is defined differently What we are talking about when we say "accuracy" is the amount of uncertainty. Here is another paper to read: http://gpstime.com/files/tow-time2011.pdf Slide #21 shows an older VT+ Receiver's PPS output compared to a hydrogen maser. Slide #24 is pretty good. It shows the RMS error from a newer MT+. -- 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 Mon, Sep 5, 2011 at 6:25 AM, Miroslav Lichvar 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 > > -- > Miroslav Lichvar > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > -- 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-07, Chris Albertson wrote: > On Wed, Sep 7, 2011 at 9:32 AM, Greg Hennessy wrote: > >> I'm not even sure the USNO provided time sync to GPS is at the 2nS >> level. > > This is not an accuracy issue. it is an intentional offset to account > for the earth's slowing rotation rate. here are various time scales > and at this level they only more or less ageree as each is defined > differently The second has been divorced from the earth's roatation rate for a long time, whether that is a gps second or a utc second. The link is made via leapseconds which is an entirel ydifferent issue than how accurately gps is steared. > > What we are talking about when we say "accuracy" is the amount of uncertainty. No we mean how closely the gps absolute time agrees with the utc absolute time (modulo leap seconds). > > Here is another paper to read: > http://gpstime.com/files/tow-time2011.pdf > Slide #21 shows an older VT+ Receiver's PPS output compared to a hydrogen > maser. > Slide #24 is pretty good. It shows the RMS error from a newer MT+. And the new MT+ have an offset built in. Also, if you only have a view of part of the sky, the troposphere and ionosphere delays will not average out, and give a time uncertainty. > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
>> What we are talking about when we say "accuracy" is the amount of >> uncertainty. > > No we mean how closely the gps absolute time agrees with the utc > absolute time (modulo leap seconds). Accuracy is always expressed as an uncertainty. For example I might say "the voltage is 6.32V plus or minus my meter's 2% error" This means I'm un-certain of the true voltage in the wire but think the value I gave is within 2% of "truth" When we buy a UT+ and read that it has 55nS accuracy what that is saying is roughly that about 2/3 of the time the true UTC time will be no more than 55nS from what the GPS says.In other words Motorola claims there will be an error that you can't know but does tell you the statistical properties of the error.I used the word "uncertainty" to describe an known error. Again this is all pretty much moot for NTP. Once your GPS has an error of less than a microsecond you are as good as "perfect" for NTP. 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-09, Chris Albertson wrote: >>> What we are talking about when we say "accuracy" is the amount of >>> uncertainty. >> >> No we mean how closely the gps absolute time agrees with the utc >> absolute time (modulo leap seconds). > > Accuracy is always expressed as an uncertainty. For example I might > say "the voltage is 6.32V plus or minus my meter's 2% error" This > means I'm un-certain of the true voltage in the wire but think the > value I gave is within 2% of "truth" Actually there are two kinds of errors-- systematic and random. Thus, the troposphere causes a delay in the signal of about 8.1ns/sin(elevation) where elevation is the angle above the horizon of the sattelite. The ionisphere has an error of about 9ms/sin(theta) but with an random error of about plus or minus 4.5ns. The MT12+ also apparently has a delay of a few 10s of ns in sending out the pulse. Are these uncertainties? If yo udo not know about them, they are. If you know about them you can subtract out the systematic errors, but you cannot do that for the random errors. Note that this means that the Oncore is far far from being within 2ns of the "truth" (ie UTC) More like 30ns.Plus the onboard trigger mechanism in the gps produces another 30-60ns of sawtooth error, which you can eliminate if you happen to be able to read and use the messages the unit can send out. Bbecause the noise depends on the elevation of the sattelites, and because the reported time is an "average" over many different elevations, those are also not possible to correct for. > > When we buy a UT+ and read that it has 55nS accuracy what that is > saying is roughly that about 2/3 of the time the true UTC time will be > no more than 55nS from what the GPS says.In other words Motorola > claims there will be an error that you can't know but does tell you > the statistical properties of the error.I used the word > "uncertainty" to describe an known error. And what are unkown errors? Surely they also affect the accuracy with which you know the time. > > Again this is all pretty much moot for NTP. Once your GPS has an > error of less than a microsecond you are as good as "perfect" for NTP. Well, one can certainly use ntp to control the clock to the ns level. For most computers who receive their signal via an interrupt line, that would agreed be useless since the interrupt cannot be serviced faster than a few usec. However, ntp can be used for a hardware clock which can timestamp the pulse edge to ns precision as well. > > 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
"...The organization of the measurements is very similar to the setup applied at BIPM and Besanqon in the experiment carried out in 1996 (Lewandowski et al., 1997). The Stanford SR-620 time-interval counter (Fig* 1) is started by the 1 pps pulse from the local UTC clock driven by the Oscilloquartz EUDICS 3020 cesium frequency standard. The counter is stopped by the 1 pps pulse from the Motorola Oncore VP receiver," So they are measuring the offset between a local cesium clock and the output of an Motorola Oncore type GPS. On Fri, Sep 9, 2011 at 3:38 PM, unruh wrote: > On 2011-09-09, Chris Albertson wrote: What we are talking about when we say "accuracy" is the amount of uncertainty. >>> >>> No we mean how closely the gps absolute time agrees with the utc >>> absolute time (modulo leap seconds). >> >> Accuracy is always expressed as an uncertainty. For example I might >> say "the voltage is 6.32V plus or minus my meter's 2% error" This >> means I'm un-certain of the true voltage in the wire but think the >> value I gave is within 2% of "truth" > > Actually there are two kinds of errors-- systematic and random. Thus, > the troposphere causes a delay in the signal of about > 8.1ns/sin(elevation) where elevation is the angle above the horizon of > the sattelite. The ionisphere has an error of about 9ms/sin(theta) but > with an random error of about plus or minus 4.5ns. A timing GPS has an advantage. it knows it's antenna location. and it knows the location is not changing. I think this allows for a "best fit" solution using all of the eight satellites that it tracks. I can't figure out how much is gained be doing this. Yes I know about many possible sources of error. It could be quite bad. But then I read test reports that come out of national standards labs and these papers get published. The reports are all pretty much in agreement that GPS can be astoundingly good. We can argue that "the error must be larger" and then we measure and it's not. I remember years ago when the government still had SA turned on the the error in location was purposefully kept quite large. What they did was encrypt the low order bits of the signal. That was until some smart person said "what if I place my GPS at a site that is surveyed at the centimeter level? Can't I figure out what the induced error in the signal is when know the right answer in advance?" It turns out the answer was "yes". I think if you have known location and a good local crystal oscillator all the GPS receiver needs GPS for is to measure the crystal oscillator drift. The GPS does not need to compute and instant solution each second, it can maintain a running average of the current time.I think it's doing about the same thing NTP does. I think it tries to phase lock it's internal clock to the eight GPS satellites that it tracks. 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 06:38 PM 9/9/2011, unruh wrote... The MT12+ also apparently has a delay of a few 10s of ns in sending out the pulse. Are these uncertainties? If yo udo not know about them, they are. If you know about them you can subtract out the systematic errors, but you cannot do that for the random errors. Note that this means that the Oncore is far far from being within 2ns of the "truth" (ie UTC) More like 30ns. What's the basis for that claim? Sounds like you didn't set the cable delay appropriately, if at all. What were you comparing against? When properly corrected for, the PPS offset pretty much stays within +- 10 ns of UTC. This paper pretty well summarizes the accuracy which an M12+ can provide, and they were comparing directly with UTC(USNO): http://tycho.usno.navy.mil/ptti/ptti2002/paper9.pdf According to this presentation: ftp://ivscc.gsfc.nasa.gov/pub/TOW/tow2011/notebook/Hambly.Sem.pdf , "All the M12+ receivers, including the 4 receivers in the 2002 test, appear to agree with UTC(USNO) to better than ±10 nsec." Of course, that would vary depending on UTC(USNO)-UTC(GPS) at any given time. But, that can only be corrected after the fact. But, they also say that "The M12Ms show a bias errors up to ~30 nsec as compared with our 'Gold' reference Motorola receiver," so maybe you're confusing the M12+ with the M12M. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 9/9/2011 6:38 PM, unruh wrote: On 2011-09-09, Chris Albertson wrote: What we are talking about when we say "accuracy" is the amount of uncertainty. No we mean how closely the gps absolute time agrees with the utc absolute time (modulo leap seconds). Accuracy is always expressed as an uncertainty. For example I might say "the voltage is 6.32V plus or minus my meter's 2% error" This means I'm un-certain of the true voltage in the wire but think the value I gave is within 2% of "truth" Actually there are two kinds of errors-- systematic and random. Thus, the troposphere causes a delay in the signal of about 8.1ns/sin(elevation) where elevation is the angle above the horizon of the sattelite. The ionisphere has an error of about 9ms/sin(theta) but with an random error of about plus or minus 4.5ns. The MT12+ also apparently has a delay of a few 10s of ns in sending out the pulse. Are these uncertainties? If yo udo not know about them, they are. If you know about them you can subtract out the systematic errors, but you cannot do that for the random errors. Note that this means that the Oncore is far far from being within 2ns of the "truth" (ie UTC) More like 30ns.Plus the onboard trigger mechanism in the gps produces another 30-60ns of sawtooth error, which you can eliminate if you happen to be able to read and use the messages the unit can send out. Bbecause the noise depends on the elevation of the sattelites, and because the reported time is an "average" over many different elevations, those are also not possible to correct for. When we buy a UT+ and read that it has 55nS accuracy what that is saying is roughly that about 2/3 of the time the true UTC time will be no more than 55nS from what the GPS says.In other words Motorola claims there will be an error that you can't know but does tell you the statistical properties of the error.I used the word "uncertainty" to describe an known error. And what are unkown errors? Surely they also affect the accuracy with which you know the time. Again this is all pretty much moot for NTP. Once your GPS has an error of less than a microsecond you are as good as "perfect" for NTP. Well, one can certainly use ntp to control the clock to the ns level. For most computers who receive their signal via an interrupt line, that would agreed be useless since the interrupt cannot be serviced faster than a few usec. However, ntp can be used for a hardware clock which can timestamp the pulse edge to ns precision as well. Dream on! You *may* have a PPS signal with an edge that might be within 50 nanoseconds. Can you even begin to time the steps between the arrival of the PPS in your GPS receiver and the updating of the computer's clock? There are damned few hobbyists who can time anything at the nanosecond level! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-10, Richard B. Gilbert wrote: > On 9/9/2011 6:38 PM, unruh wrote: >> On 2011-09-09, Chris Albertson wrote: > What we are talking about when we say "accuracy" is the amount of > uncertainty. No we mean how closely the gps absolute time agrees with the utc absolute time (modulo leap seconds). >>> >>> Accuracy is always expressed as an uncertainty. For example I might >>> say "the voltage is 6.32V plus or minus my meter's 2% error" This >>> means I'm un-certain of the true voltage in the wire but think the >>> value I gave is within 2% of "truth" >> >> Actually there are two kinds of errors-- systematic and random. Thus, >> the troposphere causes a delay in the signal of about >> 8.1ns/sin(elevation) where elevation is the angle above the horizon of >> the sattelite. The ionisphere has an error of about 9ms/sin(theta) but >> with an random error of about plus or minus 4.5ns. >> The MT12+ also apparently has a delay of a few 10s of ns in sending out >> the pulse. Are these uncertainties? If yo udo not know about them, they >> are. If you know about them you can subtract out the systematic errors, >> but you cannot do that for the random errors. >> Note that this means that the Oncore is far far from being within 2ns of >> the "truth" (ie UTC) More like 30ns.Plus the onboard trigger mechanism >> in the gps produces another 30-60ns of sawtooth error, which you can >> eliminate if you happen to be able to read and use the messages the unit >> can send out. Bbecause the noise >> depends on the elevation of the sattelites, and because the reported >> time is an "average" over many different elevations, those are also not >> possible to correct for. >> >> >>> >>> When we buy a UT+ and read that it has 55nS accuracy what that is >>> saying is roughly that about 2/3 of the time the true UTC time will be >>> no more than 55nS from what the GPS says.In other words Motorola >>> claims there will be an error that you can't know but does tell you >>> the statistical properties of the error.I used the word >>> "uncertainty" to describe an known error. >> >> And what are unkown errors? >> Surely they also affect the accuracy with which you know the time. >> >>> >>> Again this is all pretty much moot for NTP. Once your GPS has an >>> error of less than a microsecond you are as good as "perfect" for NTP. >> >> Well, one can certainly use ntp to control the clock to the ns level. >> For most computers who receive their signal via an interrupt line, that >> would agreed be useless since the interrupt cannot be serviced faster >> than a few usec. However, ntp can be used for a hardware clock which can >> timestamp the pulse edge to ns precision as well. >> > > Dream on! You *may* have a PPS signal with an edge that might be within ?? Pls read. What I refered to was a special hardware clock which would timestamp the edge of the pulse as it came in-- obviously using a special onboard clock, not the computer's clock, which the computer would also refer to to get the time. I agree perfectly that the computer's clock itself cannot be discplined to better than about 1us, but that piece of hardware can use ntp to discipline the clock on that piece of hardware itself. ntp is a clock discipline procedure. ntpd is a piece of software running on a personal computer which impliments the ntp protocol. > 50 nanoseconds. Can you even begin to time the steps between the > arrival of the PPS in your GPS receiver and the updating of the > computer's clock? With the right hardware? Sure. > > There are damned few hobbyists who can time anything at the nanosecond > level! > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
> >> 50 nanoseconds. Can you even begin to time the steps between the >> arrival of the PPS in your GPS receiver and the updating of the >> computer's clock? Yes. You can find any number of older HP Universal Counters in eBay. Some are cheap. I paid $35 for one recently. Shipping cost as much. Better ones are about $250.With one of these I can measure the time it takes for a pulse to travel down a few meters of coax cable. I connect the "start" and "stop" triggers with a length of rg58 coax cable and then place a signal generator on the "start" using a "tee". The pulse starts the timer same pulse delayed by the cable stops it. I can measure the length of the cable this way with accuracy better than a foot. The better (affordable) counters work at the 100 pico second level. This is 80's vintage test equipment that goes for cheap on eBay. The PPS interrupt processing time is dead easy to measure assuming you have a counter. So is the delay cause by the GPS antenna feed line and the RS232 cable that goes from the GPS to the computer. All these cable delays are "huge" if you are working at the nanosecond level. If you have one of these counters the next thing to buy is a very stable frequency reference. It is not hard to set up a oscillator with Allan deviation of about 10e-12. (12 zeros is a lot) then using the counter you measure the phase of the GPS' PPS signal relative to your clock. Believe me many people have done this. My equipment here at home can measure to 250 pS but I don't have a good enough local clock to take advantage of this.Next on my shopping list is a good a couple clocks first ovenized quartz crystal oscillator. Second on the list is a Rubidium oscillator. Rubidium is the "entry level" atomic clock and they've come down in price. Serviceable units go for $150. 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-11, Chris Albertson wrote: >> >>> 50 nanoseconds. ?Can you even begin to time the steps between the >>> arrival of the PPS in your GPS receiver and the updating of the >>> computer's clock? > > Yes. You can find any number of older HP Universal Counters in eBay. > Some are cheap. I paid $35 for one recently. Shipping cost as much. > Better ones are about $250.With one of these I can measure the > time it takes for a pulse to travel down a few meters of coax cable. > I connect the "start" and "stop" triggers with a length of rg58 coax > cable and then place a signal generator on the "start" using a "tee". > The pulse starts the timer same pulse delayed by the cable stops it. > I can measure the length of the cable this way with accuracy better > than a foot. The better (affordable) counters work at the 100 pico > second level. This is 80's vintage test equipment that goes for cheap > on eBay. Except that measuring the time it takes to travel down the cable is not what was wanted or discussed. > > The PPS interrupt processing time is dead easy to measure assuming you > have a counter. So is the delay cause by the GPS antenna feed line > and the RS232 cable that goes from the GPS to the computer. All these > cable delays are "huge" if you are working at the nanosecond level. The interrupt processing time is NOT easy to measure, because it is highly variable. It depeds on what the computer is doing at the time. It can fluctuate by usec. > > If you have one of these counters the next thing to buy is a very > stable frequency reference. It is not hard to set up a oscillator > with Allan deviation of about 10e-12. (12 zeros is a lot) then using > the counter you measure the phase of the GPS' PPS signal relative to > your clock. Believe me many people have done this. My equipment The clock in this case is the internal system clock in the PC, which is a complex combination of timer interrupts and cpu couters, or hpet, or whatever you computer uses. And none of those signals is delivered out onto some measuring point. > here at home can measure to 250 pS but I don't have a good enough > local clock to take advantage of this.Next on my shopping list is > a good a couple clocks first ovenized quartz crystal oscillator. > Second on the list is a Rubidium oscillator. Rubidium is the "entry > level" atomic clock and they've come down in price. Serviceable units > go for $150. But that still does not get the time inside your computer which is where it is wanted. > > > Chris Albertson > Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
