From bounce-tacgps-6754@lists.tapr.org Mon Dec 10 14:02:07 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA00550 for ; Mon, 10 Dec 2001 14:02:07 -0600 (CST) Message-Id: X-Sender: dhaselwood@POP3.ij.net Date: Mon, 10 Dec 2001 12:55:13 -0500 To: "TAPR Special Interest Group" From: Donald E Haselwood Subject: [tacgps] GPS osc displining references In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3.0.6.32.20011210125513.00983100@POP3.ij.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Do you have any references that address the following issue, regarding disciplining an oscillator with gps? The gps 1 pps signal has jitter, e.g. something of the order of 100ns, and also the osc being disciplined has a drift, e.g. a poor oven might allow the temp to change a few degrees as the ambient changes, giving rise to a change in freq, as well as its derivatives. I *think* that these two "noises" determine the limit on the accuracy of the disiplined osc, assuming the controller is optimal. If the controller followed the 1 pps too closely, then the disciplined osc would have poor short term stability, but the drift due to temp would be servo'ed out. However, if the controller loop filtering has an extremely low bandwidth, then the 1 pps jitter is filtered out, but the temp dift will not be disciplined. It seems like there is a "middle ground" and that results in "the best one can do," with the given specifications. I have not had much success finding anything addressing this, yet it seems like something that would have been thoroughly studied (or, it is simple enough that it is "left as an exercise for the student," as many engineering texts are wont to say (and I'm sure the prof chuckled when he or she put that in--seemed to me those problems always were more difficult than they first appeared). Anyway, discipling my Rb, as well as some similar projects, have been on my "list" for years, and this one happens to be hot at the moment. Don, W4DH --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Mon Dec 10 14:15:19 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA01557 for ; Mon, 10 Dec 2001 14:15:14 -0600 (CST) Date: Mon, 10 Dec 2001 15:14:13 -0500 From: John Ackermann N8UR To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <26785034.1007997253@WUSJA129861-8HP> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Hi Don -- There's been a *lot* of discussion over the years in the TAPR "tacgps" mailing list. There are searchable archives available from the www.tapr.org web page, and looking there should turn up lots of info. There was also an article in QST about two years ago by Brooks Shera on a PIC-based controller to discipline an oscillator to GPS. As you noted, there is a lot of noise on the GPS 1pps, but when you average over a long time period that noise goes away. Brooks' controller has a control loop time constant that's selectable out to several hours (maybe even days, I forget) and the best time constant to use depends on the long-term stability of the disciplined oscillator -- with a very good crystal or Rb, you can use a time constants of many hours, if not days. A lower quality oscillator requires a shorter loop time constant. The longer the time constant you can use, the less the short-term GPS noise will affect the short-term performance of the oscillator. When you get the right balance, you get the best of both worlds -- crystal or Rb short term stability, and GPS long term stability. The QST article has some good stuff on this, but the tacgps list will provide lots of more detailed information and pointers to other sources. Hope this helps. 73, John N8UR jra@febo.com --On Monday, December 10, 2001 12:55 PM -0500 Donald E Haselwood wrote: > Do you have any references that address the following issue, regarding > disciplining an oscillator with gps? > > The gps 1 pps signal has jitter, e.g. something of the order of 100ns, and > also the osc being disciplined has a drift, e.g. a poor oven might allow > the temp to change a few degrees as the ambient changes, giving rise to a > change in freq, as well as its derivatives. I *think* that these two > "noises" determine the limit on the accuracy of the disiplined osc, > assuming the controller is optimal. If the controller followed the 1 pps > too closely, then the disciplined osc would have poor short term > stability, but the drift due to temp would be servo'ed out. However, if > the controller loop filtering has an extremely low bandwidth, then the 1 > pps jitter is filtered out, but the temp dift will not be disciplined. It > seems like there is a "middle ground" and that results in "the best one > can do," with the given specifications. > > I have not had much success finding anything addressing this, yet it seems > like something that would have been thoroughly studied (or, it is simple > enough that it is "left as an exercise for the student," as many > engineering texts are wont to say (and I'm sure the prof chuckled when he > or she put that in--seemed to me those problems always were more difficult > than they first appeared). > > Anyway, discipling my Rb, as well as some similar projects, have been on > my "list" for years, and this one happens to be hot at the moment. > > Don, W4DH > > > > --- > You are currently subscribed to tacgps as: JRA@FEBO.COM > To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org > > > ---- John Ackermann N8UR jra@febo.com http://www.febo.com President, TAPR n8ur@tapr.org http://www.tapr.org --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Mon Dec 10 14:19:47 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA01683 for ; Mon, 10 Dec 2001 14:19:33 -0600 (CST) Message-ID: From: jim_johnson@agilent.com To: "TAPR Special Interest Group" Subject: [tacgps] RE: GPS osc displining references Date: Mon, 10 Dec 2001 12:18:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Hi Don, I am pleased to report that this problem has been solved ... by Brooks Shera. He wrote an article in QST a couple of years ago (somebody will report the exact reference on the reflector) describing a controller he build (boards and parts are available) that slaves an oscillator to the 1PPS output of a GPS receiver. A colleague of mine and I both built one of these and they work very nicely. In our case, we slaved high quality, double oven quartz oscillators to the 1PPS. Stay tuned to the reflector and I'm sure others will report on this as well. 73, Jim W6SC > -----Original Message----- > From: Donald E Haselwood [mailto:dhaselwood@ij.net] > Sent: Monday, December 10, 2001 9:55 AM > To: TAPR Special Interest Group > Subject: [tacgps] GPS osc displining references > > > Do you have any references that address the following issue, regarding > disciplining an oscillator with gps? > > The gps 1 pps signal has jitter, e.g. something of the order > of 100ns, and > also the osc being disciplined has a drift, e.g. a poor oven > might allow > the temp to change a few degrees as the ambient changes, > giving rise to a > change in freq, as well as its derivatives. I *think* that these two > "noises" determine the limit on the accuracy of the disiplined osc, > assuming the controller is optimal. If the controller > followed the 1 pps > too closely, then the disciplined osc would have poor short > term stability, > but the drift due to temp would be servo'ed out. However, if the > controller loop filtering has an extremely low bandwidth, > then the 1 pps > jitter is filtered out, but the temp dift will not be disciplined. It > seems like there is a "middle ground" and that results in > "the best one can > do," with the given specifications. > > I have not had much success finding anything addressing this, > yet it seems > like something that would have been thoroughly studied (or, > it is simple > enough that it is "left as an exercise for the student," as many > engineering texts are wont to say (and I'm sure the prof > chuckled when he > or she put that in--seemed to me those problems always were > more difficult > than they first appeared). > > Anyway, discipling my Rb, as well as some similar projects, > have been on my > "list" for years, and this one happens to be hot at the moment. > > Don, W4DH > > > > --- > You are currently subscribed to tacgps as: jim_johnson@agilent.com > To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org > --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Mon Dec 10 14:21:12 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA01803 for ; Mon, 10 Dec 2001 14:21:01 -0600 (CST) Date: Mon, 10 Dec 2001 15:20:13 -0500 From: John Ackermann N8UR To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <27144371.1007997612@WUSJA129861-8HP> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Hi again, Don (and tacgps folks) -- I responded to your posting when it showed up on the netsig@lists.tapr.org mailing list; obviously, you also subscribe to tacgps, so part of my reply seems a bit odd when viewed here! But I still suggest checking the searchable archive for detailed info. 73, John --On Monday, December 10, 2001 3:14 PM -0500 John Ackermann N8UR wrote: > Hi Don -- > > There's been a *lot* of discussion over the years in the TAPR "tacgps" > mailing list. There are searchable archives available from the > www.tapr.org web page, and looking there should turn up lots of info. > There was also an article in QST about two years ago by Brooks Shera on a > PIC-based controller to discipline an oscillator to GPS. > > As you noted, there is a lot of noise on the GPS 1pps, but when you > average over a long time period that noise goes away. Brooks' controller > has a control loop time constant that's selectable out to several hours > (maybe even days, I forget) and the best time constant to use depends on > the long-term stability of the disciplined oscillator -- with a very good > crystal or Rb, you can use a time constants of many hours, if not days. > A lower quality oscillator requires a shorter loop time constant. The > longer the time constant you can use, the less the short-term GPS noise > will affect the short-term performance of the oscillator. When you get > the right balance, you get the best of both worlds -- crystal or Rb short > term stability, and GPS long term stability. > > The QST article has some good stuff on this, but the tacgps list will > provide lots of more detailed information and pointers to other sources. > > Hope this helps. > > 73, > John N8UR > jra@febo.com > > --On Monday, December 10, 2001 12:55 PM -0500 Donald E Haselwood > wrote: > >> Do you have any references that address the following issue, regarding >> disciplining an oscillator with gps? >> >> The gps 1 pps signal has jitter, e.g. something of the order of 100ns, >> and also the osc being disciplined has a drift, e.g. a poor oven might >> allow the temp to change a few degrees as the ambient changes, giving >> rise to a change in freq, as well as its derivatives. I *think* that >> these two "noises" determine the limit on the accuracy of the disiplined >> osc, assuming the controller is optimal. If the controller followed the >> 1 pps too closely, then the disciplined osc would have poor short term >> stability, but the drift due to temp would be servo'ed out. However, if >> the controller loop filtering has an extremely low bandwidth, then the 1 >> pps jitter is filtered out, but the temp dift will not be disciplined. >> It seems like there is a "middle ground" and that results in "the best >> one can do," with the given specifications. >> >> I have not had much success finding anything addressing this, yet it >> seems like something that would have been thoroughly studied (or, it is >> simple enough that it is "left as an exercise for the student," as many >> engineering texts are wont to say (and I'm sure the prof chuckled when he >> or she put that in--seemed to me those problems always were more >> difficult than they first appeared). >> >> Anyway, discipling my Rb, as well as some similar projects, have been on >> my "list" for years, and this one happens to be hot at the moment. >> >> Don, W4DH >> >> >> >> --- >> You are currently subscribed to tacgps as: JRA@FEBO.COM >> To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org >> >> >> > > > > ---- > John Ackermann N8UR jra@febo.com http://www.febo.com > President, TAPR n8ur@tapr.org http://www.tapr.org > > > --- > You are currently subscribed to tacgps as: JRA@FEBO.COM > To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org > > > ---- John Ackermann N8UR jra@febo.com http://www.febo.com President, TAPR n8ur@tapr.org http://www.tapr.org --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Mon Dec 10 15:05:34 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA04617 for ; Mon, 10 Dec 2001 15:05:33 -0600 (CST) Message-ID: Date: Mon, 10 Dec 2001 16:05:12 -0500 From: GS Organization: bigfoot.com X-Accept-Language: en MIME-Version: 1.0 To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3C152388.10F72278@bigfoot.com> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk John Ackermann N8UR wrote: > > Hi Don -- > > There's been a *lot* of discussion over the years in the TAPR "tacgps" > mailing list. There are searchable archives available from the > www.tapr.org web page, and looking there should turn up lots of info. > There was also an article in QST about two years ago by Brooks Shera on a > PIC-based controller to discipline an oscillator to GPS. Here's a link to Brooks' web page describing his controller. I've built it and it works well. http://www.rt66.com/~shera/ Gary Sanders --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 04:09:34 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id EAA02651 for ; Tue, 11 Dec 2001 04:09:32 -0600 (CST) Message-ID: Date: Tue, 11 Dec 2001 11:07:34 +0100 From: Alberto di Bene X-Accept-Language: en MIME-Version: 1.0 To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3C15DAE6.68D79DA6@usa.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk GS wrote: > > Here's a link to Brooks' web page describing his controller. I've > built it and it works well. > > http://www.rt66.com/~shera/ > > Gary Sanders > Does anybody knows if/where the source code of the PIC 16C73A controller in the Shera's project is available ? Thanks. 73 Alberto I2PHD --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 05:44:07 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id FAA06658 for ; Tue, 11 Dec 2001 05:44:06 -0600 (CST) Message-ID: From: "W5SNX" To: "TAPR Special Interest Group" References: Subject: [tacgps] Re: GPS osc displining references Date: Tue, 11 Dec 2001 11:42:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <003101c18238$f3e2efc0$a7013842@atl.mediaone.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk The source code is available from Brooks Shera at his site. ----- Original Message ----- From: "Alberto di Bene" To: "TAPR Special Interest Group" Sent: Tuesday, December 11, 2001 10:07 Subject: [tacgps] Re: GPS osc displining references > GS wrote: > > > > > Here's a link to Brooks' web page describing his controller. I've > > built it and it works well. > > > > http://www.rt66.com/~shera/ > > > > Gary Sanders > > > > Does anybody knows if/where the source code of the PIC 16C73A > controller in the Shera's project is available ? Thanks. > > 73 Alberto I2PHD > > > > --- > You are currently subscribed to tacgps as: w5snx@atl.mediaone.net > To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org > --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 06:24:05 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id GAA08319 for ; Tue, 11 Dec 2001 06:24:02 -0600 (CST) Message-ID: Date: Tue, 11 Dec 2001 13:22:30 +0100 From: Alberto di Bene X-Accept-Language: en MIME-Version: 1.0 To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3C15FA86.EBFDC758@usa.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk W5SNX wrote: > The source code is available from Brooks Shera at his site. > Thanks, but I have found there only the binary (hex) code for the PIC. There are a couple other source codes, but they are for accessory applications to format the output of the GPS, not for the PIC controller used in the project. 73 Alberto I2PHD --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 08:14:06 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id IAA13488 for ; Tue, 11 Dec 2001 08:14:05 -0600 (CST) Date: Tue, 11 Dec 2001 09:13:21 -0500 From: John Ackermann N8UR To: "TAPR Special Interest Group" Subject: [tacgps] Position average versus time? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <4979410.1008062001@WUSJA129861-8HP> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk I'm about to start a TAC-32 position survey and am curious whether there's any general sense of position accuracy versus averaging time now that SA is gone. In other words, what's the point of diminishing returns, and what kind of accuracy ("I know where I am within X meters") can be expected for a given survey time. Alternatively, an explanation about how to reduce the averaging data that TAC-32 makes available down to a simple accuracy figure would do -- I'm mathematically challenged. John ---- John Ackermann N8UR jra@febo.com http://www.febo.com President, TAPR n8ur@tapr.org http://www.tapr.org --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 12:09:35 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA25978 for ; Tue, 11 Dec 2001 12:09:35 -0600 (CST) Message-Id: X-Sender: dhaselwood@POP3.ij.net Date: Tue, 11 Dec 2001 13:05:08 -0500 To: "TAPR Special Interest Group" From: Donald E Haselwood Subject: [tacgps] Re: GPS osc displining references In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3.0.6.32.20011211130508.0098be40@POP3.ij.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk John, Thanks. I'll revisit the TAPR archives a look. I don't remember any discussions about the best approach to the controller. There were some discussions about of how to connect into the Rb for steering it. I've looked at Brooks Shera's controller. He a did an excellent job that is quite satisfactory for most purposes. I think for steering the Rb it can be improved--at least that is what I'm looking into. He implements a PI loop which results in a second-order loop. If the osc being disciplined is off freq, but constant, then the loop will pull it onto freq. If the freq is changing--"a cool breeze blows through the window," and the osc being disciplined begins changing freq--the loop "can't keep up," resulting frequency error. A third order loop will remove a linearly changing freq. The osc steering is very similar to the problem of tracking a xmitter carrier in a satellite (Gardener's book, _PhaseLock Techniques_ 1966 is the classic ref). The noise analyses, however, are a little different than the situation here. Another aspect of Brooks' approach is that the measurement of phase between the xtal/Rb and the 1 pps is based on a xtal osc. A drift in that osc then appears as changes in the "setpoint" of the phase locked loop. This is a secondary error (looks like 1E-10 to 1E-11 (but I need to review this)). It wouldn't have much practical affect when disciplining a quartz osc, but it is significant for the Rb. This can overcome by either phase locking that xtal, measuring the time between 1 pps pulses, or driving the micro directly from the Rb. I have a breadboard with the last scheme that I was experimenting with back when the Rb issue was hot on this list. A move, amongst other things, put it all in the background. Don, W4DH --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 12:10:05 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA25994 for ; Tue, 11 Dec 2001 12:10:03 -0600 (CST) Message-Id: X-Sender: dhaselwood@POP3.ij.net Date: Tue, 11 Dec 2001 13:04:50 -0500 To: "TAPR Special Interest Group" From: Donald E Haselwood Subject: [tacgps] Re: GPS osc displining references In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3.0.6.32.20011211130450.00994660@POP3.ij.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Alberto, Yes it is available, but with some restriction. Email Brooks. I've looked at the code and it is commented sufficiently that one doesn't have to fully understand PIC assembly language to trace what is being done. Don, W4DH At 11:07 AM 12/11/01 +0100, you wrote: >GS wrote: > >> >> Here's a link to Brooks' web page describing his controller. I've >> built it and it works well. >> >> http://www.rt66.com/~shera/ >> >> Gary Sanders >> > >Does anybody knows if/where the source code of the PIC 16C73A >controller in the Shera's project is available ? Thanks. > >73 Alberto I2PHD > > > >--- >You are currently subscribed to tacgps as: dhaselwood@ij.net >To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org > > --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 13:45:04 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id NAA02428 for ; Tue, 11 Dec 2001 13:45:02 -0600 (CST) Message-ID: From: "Brooks Shera" To: "TAPR Special Interest Group" References: Subject: [tacgps] Re: GPS osc displining references Date: Tue, 11 Dec 2001 12:44:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <001201c1827c$2ea363e0$6400a8c0@brooksnotebook> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk A couple of comments on Don's discussion of my GPS-VCXO controller design: > > He implements a PI loop which results in a second-order loop. If the osc > being disciplined is off freq, but constant, then the loop will pull it > onto freq. If the freq is changing--"a cool breeze blows through the > window," and the osc being disciplined begins changing freq--the loop > "can't keep up," resulting frequency error. A third order loop will remove > a linearly changing freq. > > The osc steering is very similar to the problem of tracking a xmitter > carrier in a satellite (Gardener's book, _PhaseLock Techniques_ 1966 is the > classic ref). The noise analyses, however, are a little different than the > situation here. The controller does use a 2nd order loop, primarily because such a loop in unconditionally stable. Higher order loops can readily oscillate if the loop gain is not set carefully (see Gardner p.18). A precise loop gain is hard to guarantee since the controller was designed to be used with a variety of VCXOs. If it were necessary it could have been done with considerable effort on the part of the builder. But really, there is little to be gained by going to a 3rd order loop. Don's comment that a ramping VCXO frequency will cause a FREQUENCY error in a 2nd order loop is misleading. It actually causes a PHASE offset (see Gardner, Table 4.1) . This phase offset is of little importance for a frequency standard that is operating with a reasonably stable VCXO. > > Another aspect of Brooks' approach is that the measurement of phase between > the xtal/Rb and the 1 pps is based on a xtal osc. A drift in that osc then > appears as changes in the "setpoint" of the phase locked loop. This is a > secondary error (looks like 1E-10 to 1E-11 (but I need to review this)). > It wouldn't have much practical affect when disciplining a quartz osc, but > it is significant for the Rb. This can overcome by either phase locking > that xtal, measuring the time between 1 pps pulses, or driving the micro > directly from the Rb. As explained in the article, drift of the inexpensive 24 MHz xtal osc is *essential* to overcoming the +/- 1 count ambiguity in the phase measuring circuit. If the 24 MHz osc were looked to the VCXO the count ambiguity would cause a phase error of +/- 42 nsec. Drift of the 24 MHz xtal reduces the error to a small fraction of this amount. Also, the effect of the drift of even a cheap xtal on the phase setpoint is negligible. Brooks --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 11 23:23:51 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id XAA00514 for ; Tue, 11 Dec 2001 23:23:49 -0600 (CST) Message-ID: From: "Kirby, Brian" To: "TAPR Special Interest Group" Subject: [tacgps] RE: Position average versus time? Date: Tue, 11 Dec 2001 23:22:35 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C182CD.02246250" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <0D57AFA6D072F84884E90CE6565A367D3A5B48@ums.msfc.nasa.gov> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C182CD.02246250 Content-Type: text/plain John I ran a C/A code test about two weeks ago, for 2 days. After averaging, the position was within 3 meters. I do not have the data with me - I am at work - I'll try to remember to look at it in the morning and put some of the highlights up here. I used excel and just extracted the gga string. > ---------- > From: John Ackermann N8UR[SMTP:jra@febo.com] > Reply To: TAPR Special Interest Group > Sent: Tuesday, December 11, 2001 8:13 AM > To: TAPR Special Interest Group > Subject: [tacgps] Position average versus time? > > I'm about to start a TAC-32 position survey and am curious whether there's > > any general sense of position accuracy versus averaging time now that SA > is > gone. In other words, what's the point of diminishing returns, and what > kind of accuracy ("I know where I am within X meters") can be expected for > > a given survey time. > > Alternatively, an explanation about how to reduce the averaging data that > TAC-32 makes available down to a simple accuracy figure would do -- I'm > mathematically challenged. > > John > > ---- > John Ackermann N8UR jra@febo.com http://www.febo.com > President, TAPR n8ur@tapr.org http://www.tapr.org > > > --- > You are currently subscribed to tacgps as: brian.kirby@msfc.nasa.gov > To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org > ------_=_NextPart_001_01C182CD.02246250 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [tacgps] Position average versus time?

John I ran a C/A code test about = two weeks ago, for 2 days.  After averaging, the position was = within 3 meters.  I do not have the data with me - I am at work - = I'll try to remember to look at it in the morning and put some of the = highlights up here.

I used excel and just extracted the = gga string.

    ----------
    From:   = John Ackermann = N8UR[SMTP:jra@febo.com]
    Reply To: =       TAPR Special Interest Group
    Sent:   = Tuesday, December 11, 2001 8:13 = AM
    To: =     TAPR Special = Interest Group
    Subject: =        [tacgps] Position average versus time?

    I'm about to start a TAC-32 position = survey and am curious whether there's
    any general sense of position = accuracy versus averaging time now that SA is
    gone.  In other words, what's = the point of diminishing returns, and what
    kind of accuracy ("I know where = I am within X meters") can be expected for
    a given survey time.

    Alternatively, an explanation about = how to reduce the averaging data that
    TAC-32 makes available down to a = simple accuracy figure would do -- I'm
    mathematically challenged.

    John

    ----
    John Ackermann    = N8UR         = jra@febo.com     http://www.febo.com
    President, = TAPR           &n= bsp;    n8ur@tapr.org    http://www.tapr.org


    ---
    You are currently subscribed to = tacgps as: brian.kirby@msfc.nasa.gov
    To unsubscribe send a blank email to = leave-tacgps-6754G@lists.tapr.org

------_=_NextPart_001_01C182CD.02246250-- --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 12 12:37:40 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA16046 for ; Wed, 12 Dec 2001 12:37:34 -0600 (CST) Message-Id: X-Sender: dhaselwood@POP3.ij.net Date: Wed, 12 Dec 2001 13:36:21 -0500 To: "TAPR Special Interest Group" From: Donald E Haselwood Subject: [tacgps] Re: GPS osc displining references In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3.0.6.32.20011212133621.00989a00@POP3.ij.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Brooks, Good comments that stimulated my thinking! >The controller does use a 2nd order loop, primarily because such a loop in >unconditionally stable. And a very good choice for a general purpose controller. BTW, after doing some simulations for another home project, (steering the time keeping on my "gizmo's" on my RS-485 network), I discovered that with a digital implementation, a second order loop is NOT unconditionally stable for all gains. It took me a while to understand what was happening, as I was also of the thinking that the second order loop was unconditionally stable. (In fact, that's why I emailed you about the source code--I couldn't figure out what I was doing wrong.) What happens is that at high gains the loop frequency (which increases with gain) can reach the point where the approximations for the digital filter fall apart, or put another way, the loop frequency was getting too close to the sampling frequency--a situation that would not be a problem in the gps osc steering situation, but something my simulations for the "time keeping" ran into (where getting on-time quickly was a big consideration). >Higher order loops can readily oscillate if the >loop gain is not set carefully (see Gardner p.18). The unstable region is for low gains. Above that, the loop remains stable for all gains, so it doesn't look so critical for the phase-locked loop situation. >But really, there is little >to be gained by going to a 3rd order loop. It looks like there are advantages to the 3rd order loop. The 3rd order loop has "memory" for rate of change of freq, whereas the 2nd order loop holds just frequency (p51,52 (BTW it looks like your p18 corresponds to p16 in my old, yellowed book)). Blanchard, _Phase-Locked Loops: Application to Coherent Receiver Design_, 1976 (pages aren't quite so yellow!), shows that the 3rd order loop is optimum in the presence of noise, when the disturbance is a frequency ramp (the cool breeze through the window syndrome). >Don's comment that a ramping >VCXO frequency will cause a FREQUENCY error in a 2nd order loop is >misleading. It actually causes a PHASE offset (see Gardner, Table 4.1) . >This phase offset is of little importance for a frequency standard that is >operating with a reasonably stable VCXO. Quite true for the *steady state*. However, for discipling the osc, the problem is dealing with change, e.g. the daily temp fluctuations are the major cause of Rb drift (I found an article that showed a graph and made this statement). One could approximate this error input as a sine wave with a 24 hour period. The task is to come up with a loop design that minimizes the error. It seems like the "noises" are the key factor in the loop design, and that's where I bog down (it's been 40 yrs since my last grad level course on this, so I'm a bit rusty). The whole issue revolves around the "reasonably stable VCXO"--it is that instability that we are trying to reduce. Gardner's chapt on optimization talks about Wiener optimization; Blanchard uses it too. I suspect that Wiener or Kalman filtering might be the area of references I need to pursue. >As explained in the article, drift of the inexpensive 24 MHz xtal osc is >*essential* to overcoming the +/- 1 count ambiguity in the phase measuring >circuit. If the 24 MHz osc were looked to the VCXO the count ambiguity >would cause a phase error of +/- 42 nsec. Drift of the 24 MHz xtal reduces >the error to a small fraction of this amount. Also, the effect of the drift >of even a cheap xtal on the phase setpoint is negligible. After revisiting the setpoint changing issue it is now looking like it is not a major factor. If the setpoint were at 1000 counts (of the 24 Mhz counter) and there is a change of 10 ppm of the 24 Mhz osc, then there is a shift of the setpoint of .01 counts, out of a total one second count of 24E6, which translates to 4.2E-10 counts per one second interval. If it takes 1000 seconds for the 24 Mhz osc change, then the rate of shift is about 4.2E-13 cycles per second. Since the Rb appears--at best--stable in the 1E-12 to 1E-13 realm, then 4.2E-13--at worst--is not going to ruin the results. I was off by two orders magnitude on my earlier estimate. Concerning the drift and the increased resolution, I don't think the drift is necessary. Certainly it increases the resolution of the measurement, after averaging. If the osc were perfect, or more practical, phase locked to the Rb, then the loop would track to the point where the transition of the 24 Mhz osc counter fell exactly at the 1 pps event. Without the jitter on the 1 pps signal there would be a limit cycle that would be determined by the loop. With jitter, the limit cycle issue gets more complicated, and I expect it becomes a secondary factor. What led me to this thinking was wrestling with the resolution of the HC11 input-capture. I had an HC11 setup going about the same time you were working on your controller, where the micro clock input was driven by the Rb. At 10 Mhz, the input capture resolution is 400ns, which is rather course. The move and other life events put the project into the "think about" category. I had been pondering ways to improve this (and do so simply, e.g. faster micros, FPGAs, dither schemes,...), when it struck me that it is not all that important--the loop will stabilize with the 1 pps event coming exactly at the micro's bus cycle transition, so that the gps jitter will cause half of the events before and half after the micro's bus transition. The hardware is then "dog simple"--the Rb goes to the EXTAL input, and the gps goes to a input-capture pin. (The setpoint issue also goes away.) Another improvement might come from utilizing the 100 pps option with the Mot UT+. The specs say that the 1 pps can be switched to 100 pps, though I haven't tried this. The faster rate would help the averaging. The price paid is that the feature is not as common as the 1 pps on other gps engines. Anyway, that's where I'm at with it. If you run across some good references I'd appreciate if you would send them to me. Don, W4DH --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 12 13:54:45 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id NAA18925 for ; Wed, 12 Dec 2001 13:54:44 -0600 (CST) X-pair-Authenticated: 209.244.110.232 Message-ID: Reply-To: "TAPR Special Interest Group" From: "Tom Van Baak" To: "TAPR Special Interest Group" References: Subject: [tacgps] Re: GPS osc displining references Date: Wed, 12 Dec 2001 11:53:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio X-Message-Id: <000f01c18346$b03817a0$e86ef4d1@tlvb> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Here's a back-of-the-envelope calculation and a question for Brooks and Don. A typical Rb has a frequency drift rate of around 3E-11 per month which is about 1E-13/day (or 10 ns/day/day). A typical GPS receiver has about 100 ns short-term 1 PPS noise which, along with all the other systematic GPS time transfer errors, might average down to, what, about 10 ns to 30 ns per day? To me that would argue that a discipline action on the order of once or twice a day is all that a Rb needs. I'm curious if there is performance data on how Brooks' board does with a Rb vs. a OCXO. It would also suggest to me that higher-order loops have little to offer - the Rb drift rate being small compared to the relative lack of short-term and mid-term precision of the GPS tick; i.e., the daily drift is not much different than the daily noise. I ask because there's been a lot written about using OCXO's with Brooks' board but not much about using Rb's. Given that the average Rb has about 1000x less drift than the average OCXO I wonder if the existing implementation works as well for each. /tvb --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 12 14:07:55 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA19501 for ; Wed, 12 Dec 2001 14:07:48 -0600 (CST) Date: Wed, 12 Dec 2001 15:07:14 -0500 From: John Ackermann N8UR To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <26395304.1008169634@WUSJA129861-8HP> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Just as a data point, I was looking this morning at the web info on the SRS rubidium oscillator, and discovered that it has the built-in ability to be steered by a 1pps signal. There is a chart showing stability with and without steering. Check http://www.srsys.com/html/prs10.html for info on their system. John --On Wednesday, December 12, 2001 11:53 AM -0800 Tom Van Baak wrote: > Here's a back-of-the-envelope calculation and a question > for Brooks and Don. > > A typical Rb has a frequency drift rate of around 3E-11 > per month which is about 1E-13/day (or 10 ns/day/day). > > A typical GPS receiver has about 100 ns short-term > 1 PPS noise which, along with all the other systematic > GPS time transfer errors, might average down to, what, > about 10 ns to 30 ns per day? > > To me that would argue that a discipline action on > the order of once or twice a day is all that a Rb > needs. I'm curious if there is performance data on > how Brooks' board does with a Rb vs. a OCXO. > > It would also suggest to me that higher-order loops > have little to offer - the Rb drift rate being small > compared to the relative lack of short-term and > mid-term precision of the GPS tick; i.e., the daily > drift is not much different than the daily noise. > > I ask because there's been a lot written about > using OCXO's with Brooks' board but not much > about using Rb's. Given that the average Rb has > about 1000x less drift than the average OCXO I > wonder if the existing implementation works as > well for each. > > /tvb > > > > --- > You are currently subscribed to tacgps as: JRA@FEBO.COM > To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org > > > ---- John Ackermann N8UR jra@febo.com http://www.febo.com President, TAPR n8ur@tapr.org http://www.tapr.org --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 12 14:44:04 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA20891 for ; Wed, 12 Dec 2001 14:44:01 -0600 (CST) Message-ID: From: jim_johnson@agilent.com To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references Date: Wed, 12 Dec 2001 12:43:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Hmmm, my "envelope" shows a drift rate of 3E-11/month yielding about 86 ns/day/day, which makes the drift rate about 3 times that of the daily noise, assuming the noise is averaged down to about 30 ns/day. Am I off somewhere? Tnx, Jim W6SC > -----Original Message----- > From: Tom Van Baak [mailto:tvb@leapsecond.com] > Sent: Wednesday, December 12, 2001 11:54 AM > To: TAPR Special Interest Group > Subject: [tacgps] Re: GPS osc displining references > > > Here's a back-of-the-envelope calculation and a question > for Brooks and Don. > > A typical Rb has a frequency drift rate of around 3E-11 > per month which is about 1E-13/day (or 10 ns/day/day). > > A typical GPS receiver has about 100 ns short-term > 1 PPS noise which, along with all the other systematic > GPS time transfer errors, might average down to, what, > about 10 ns to 30 ns per day? > > To me that would argue that a discipline action on > the order of once or twice a day is all that a Rb > needs. I'm curious if there is performance data on > how Brooks' board does with a Rb vs. a OCXO. > > It would also suggest to me that higher-order loops > have little to offer - the Rb drift rate being small > compared to the relative lack of short-term and > mid-term precision of the GPS tick; i.e., the daily > drift is not much different than the daily noise. > > I ask because there's been a lot written about > using OCXO's with Brooks' board but not much > about using Rb's. Given that the average Rb has > about 1000x less drift than the average OCXO I > wonder if the existing implementation works as > well for each. > > /tvb > > --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 12 14:57:13 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA22347 for ; Wed, 12 Dec 2001 14:57:10 -0600 (CST) X-pair-Authenticated: 209.245.175.136 Message-ID: Reply-To: "TAPR Special Interest Group" From: "Tom Van Baak" To: "TAPR Special Interest Group" References: Subject: [tacgps] Re: GPS osc displining references Date: Wed, 12 Dec 2001 12:48:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio X-Message-Id: <002d01c1834f$59152ea0$88aff5d1@tlvb> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk > Just as a data point, I was looking this morning at the web info on the SRS > rubidium oscillator, and discovered that it has the built-in ability to be > steered by a 1pps signal. There is a chart showing stability with and > without steering. Check http://www.srsys.com/html/prs10.html for info on > their system. > > John Yes, the PRS10 is a very nice example. Note the cross-over point occurs somewhere around 2-300,000 seconds; about 3 days. /tvb --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 12 15:06:21 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA23032 for ; Wed, 12 Dec 2001 15:06:13 -0600 (CST) X-pair-Authenticated: 209.245.175.136 Message-ID: Reply-To: "TAPR Special Interest Group" From: "Tom Van Baak" To: "TAPR Special Interest Group" References: Subject: [tacgps] Re: GPS osc displining references Date: Wed, 12 Dec 2001 13:04:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio X-Message-Id: <004001c18350$ab5548c0$88aff5d1@tlvb> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk > Hmmm, my "envelope" shows a drift rate of 3E-11/month yielding > about 86 ns/day/day, which makes the drift rate about 3 times > that of the daily noise, assuming the noise is averaged down to > about 30 ns/day. Am I off somewhere? > > Tnx, > Jim W6SC Yeah, that's more like it. My typo. 3E-11/month is 1E-12/day. Still, my guess is most Rb do quite a bit better than that spec and are down in parts in 10^13th per day. What happens to the algorithm when the daily drift rate is on the order of the daily noise? Interesting also to note the PRS10 plot shows GPS never getting below 1E-12 even after 2 weeks. /tvb --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 12 15:30:05 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA24328 for ; Wed, 12 Dec 2001 15:30:04 -0600 (CST) Date: Wed, 12 Dec 2001 13:24:13 -0800 (PST) From: Jeffrey Pawlan To: "TAPR Special Interest Group" Subject: [tacgps] partial schematic needed for HP Z3801 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Does any one out there have at least the portion of the schematic for the HP GPS receiver model Z3801 that is the temperature regulator and control for the outer oven on the double oven crystal oscillator? This oscillator has only the heater and thermistor in the outer oven and all temperature control was done elsewhere in the receiver. I have one of these oscillators and would like to use it with Shera's board. Although I could design a controller from scratch, I am certain that a lot of time was spent characterising the thermal loop characteristics at HP and an optimal feedback loop was designed. Thus it would be useful to simply build one breadboard from their design. If anyone has this schematic, could you either scan it at high resolution or make a very clear photocopy and mail it to me if I pay for your costs? I would also need the associated parts list. 73, Jeffrey Pawlan, WA6KBL jpawlan@pawlan.com --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Thu Dec 13 06:44:26 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id GAA19655 for ; Thu, 13 Dec 2001 06:44:25 -0600 (CST) Message-ID: Date: Thu, 13 Dec 2001 13:42:58 +0100 From: Alberto di Bene X-Accept-Language: en MIME-Version: 1.0 To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc displining references References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3C18A252.BD8994E8@usa.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk John Ackermann N8UR wrote: > Just as a data point, I was looking this morning at the web info on the SRS > rubidium oscillator, and discovered that it has the built-in ability to be > steered by a 1pps signal. There is a chart showing stability with and > without steering. Check http://www.srsys.com/html/prs10.html for info on > their system. > It looks like also the PRS10 uses a second-order loop to lock into the external 1-pps signal. From the PRS10 user manual : --- Locking to External 1pps The PRS10 may be locked to an external 1 pps source (from a GPS or LORAN receiver, for example) by applying a 1 pps pulse to the 1 pps input (pin 5 on the main connector). A second order digital phase lock loop (PLL) is used to adjust the frequency of the PRS10 to match the frequency of the 1 pps source over long time intervals. --- 73 Alberto I2PHD --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Thu Dec 13 09:26:01 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id JAA26558 for ; Thu, 13 Dec 2001 09:25:58 -0600 (CST) Message-ID: From: jim_johnson@agilent.com To: "TAPR Special Interest Group" Subject: [tacgps] Re: GPS osc disciplining references Date: Thu, 13 Dec 2001 07:25:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Hi Tom, Interesting question (your algorithm question). We should pose it to somebody who has developed one ... like Brooks! I wish Robin Giffard were here (deceased as of May, 2001) to discuss these issues, especially as he has looked at GPS data for years and would be able to give some insight as to why the data never gets below 1E-12 after a long time. But, there are other experts out here too that can probably answer that question. I'm tempted to stick my uneducated neck out and offer "multi-path" as a possible reason why somebody taking data at any given location might not see numbers below 1E-12 in the long term, but if I do that I'll need to find my flack jacket first ... so I won't do it. :-) Jim > -----Original Message----- > From: Tom Van Baak [mailto:tvb@leapsecond.com] > Sent: Wednesday, December 12, 2001 1:05 PM > To: TAPR Special Interest Group > Subject: [tacgps] Re: GPS osc displining references > > > > Hmmm, my "envelope" shows a drift rate of 3E-11/month yielding > > about 86 ns/day/day, which makes the drift rate about 3 times > > that of the daily noise, assuming the noise is averaged down to > > about 30 ns/day. Am I off somewhere? > > > > Tnx, > > Jim W6SC > > Yeah, that's more like it. My typo. 3E-11/month is > 1E-12/day. Still, my guess is most Rb do quite a > bit better than that spec and are down in parts in > 10^13th per day. What happens to the algorithm > when the daily drift rate is on the order of the daily > noise? > > Interesting also to note the PRS10 plot shows GPS > never getting below 1E-12 even after 2 weeks. > > /tvb > --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Thu Dec 13 13:43:07 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id NAA09151 for ; Thu, 13 Dec 2001 13:43:05 -0600 (CST) Message-ID: From: "Brooks Shera" To: "TAPR Special Interest Group" References: Subject: [tacgps] Re: GPS osc disciplining references Date: Thu, 13 Dec 2001 12:42:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <000801c1840e$4ea79a60$6400a8c0@brooksnotebook> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Don Thanks for your thoughts on the disciplining business. I have a couple more comments. > > Concerning the drift and the increased resolution, I don't think the drift > is necessary. Certainly it increases the resolution of the measurement, > after averaging. If the osc were perfect, or more practical, phase locked > to the Rb, then the loop would track to the point where the transition of > the 24 Mhz osc counter fell exactly at the 1 pps event. Without the jitter > on the 1 pps signal there would be a limit cycle that would be determined > by the loop. With jitter, the limit cycle issue gets more complicated, and > I expect it becomes a secondary factor. > > What led me to this thinking was wrestling with the resolution of the HC11 > input-capture. I had an HC11 setup going about the same time you were > working on your controller, where the micro clock input was driven by the > Rb. At 10 Mhz, the input capture resolution is 400ns, which is rather > course. The move and other life events put the project into the "think > about" category. I had been pondering ways to improve this (and do so > simply, e.g. faster micros, FPGAs, dither schemes,...), when it struck me > that it is not all that important--the loop will stabilize with the 1 pps > event coming exactly at the micro's bus cycle transition, so that the gps > jitter will cause half of the events before and half after the micro's bus > transition. The hardware is then "dog simple"--the Rb goes to the EXTAL > input, and the gps goes to a input-capture pin. Your "dog simple" scheme has not yet convinced this dog. If I understand correctly, your arrangement would operate with a phase detector that produces no information about the size of the phase error - its phase detector needs only two output values, corresponding to phase leading or phase lagging. How do you propose to operate a PI (or PID!) controller with this limited input information? > > Another improvement might come from utilizing the 100 pps option with the > Mot UT+. The specs say that the 1 pps can be switched to 100 pps, though > I haven't tried this. The faster rate would help the averaging. The price > paid is that the feature is not as common as the 1 pps on other gps engines. I would agree, the 100 pps option would be useful if the UT+ solved the GPS position/time equations 100 times per second and thus produced 100 independent time solutions. However, I believe the UT+ gps engine only solves the equations once per second so the 99 extra output pulses present no new information and averaging them is a waste of effort. Brooks --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Thu Dec 13 23:08:05 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id XAA09720 for ; Thu, 13 Dec 2001 23:08:03 -0600 (CST) Message-ID: From: "Kirby, Brian" To: "TAPR Special Interest Group" Subject: [tacgps] RE: N8UR Date: Thu, 13 Dec 2001 23:06:31 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1845D.185B34E0" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <0D57AFA6D072F84884E90CE6565A367D3A5B4B@ums.msfc.nasa.gov> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1845D.185B34E0 Content-Type: text/plain John you asked about a positioning survey with TAC32 a couple of days ago. Here's the data I obtained. This is the average of 4 Oncore VPs. position deviation 2.97 meters lat, 2.88 meters long, 25.3 meters height. My site is surveyed (carrier phase)/adjusted against NGS benchmarks and after the averaging the above C/A data worked out to +2.52 meters north, -1.08 meters east and -23.90 meters height. ------_=_NextPart_001_01C1845D.185B34E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: N8UR

    John you asked about a positioning = survey with TAC32 a couple of days ago.  Here's the data I = obtained.  This is the average of 4 Oncore VPs.

    position deviation  2.97 = meters lat, 2.88 meters long, 25.3 meters height.

    My site is surveyed (carrier = phase)/adjusted against NGS benchmarks and after the averaging the = above C/A data worked out to +2.52 meters north, -1.08 meters east and = -23.90 meters height.


------_=_NextPart_001_01C1845D.185B34E0-- --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Sat Dec 15 06:39:12 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id GAA04579 for ; Sat, 15 Dec 2001 06:39:11 -0600 (CST) Date: Sat, 15 Dec 2001 07:38:50 -0500 From: "John R. Ackermann" To: "TAPR Special Interest Group" Subject: [tacgps] Programming help for 5370B counter Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <475718326.1008401930@[192.168.1.26]> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Hi -- I'm just starting my first-ever foray into GPIB programming, trying to get frequency and time interval data out of my HP 5370B counter. I've cobbled together a working capture routine, but I don't think it's the most effective one to minimize dead time between readings. I wonder if someone with experience in this area would be willing to work with me off-line to get the figured out. Thanks! John --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Sat Dec 15 07:01:21 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id HAA05113 for ; Sat, 15 Dec 2001 07:01:19 -0600 (CST) Date: Sat, 15 Dec 2001 08:00:43 -0500 From: "John R. Ackermann" To: "TAPR Special Interest Group" Subject: [tacgps] ANNOUNCE: New "time-nuts" mailing list for time/freq fanatics Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <477031404.1008403243@[192.168.1.26]> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk I've always felt a bit nervous about posting messages to the tacgps list that are more related to general time and frequency measurement than to GPS (like the posting I made a few minutes ago!). I've talked for a few months with some other enthusiasts about setting up a separate mailing list for these more general issues. I've decided to give it a try, so the "time-nuts@febo.com" mailing list is now available. The list charter says: "time-nuts@febo.com is a mailing list dedicated to the discussion of time and frequency measurement tools, techniques, and toys at a fairly serious level." Hopefully that's a useful description of what we're trying to accomplish. You can subscribe by sending a message to "majordomo@febo.com" with the following as the only line in the body (without the quotes): "suscribe time-nuts". You can also subscribe via the web interface at http://www.febo.com/majordomo.html. Subscription requests generate a confirmation email that you'll have to return (that avoids prank subscriptions), and to minimize spam posting is limited to subscribed addresses. That last point means that if you subscribe using an alias like "n8ur@tapr.org" you will not be able to post unless your mail program is set up to show the same address in either the "From" or the "Reply-to" headers of messages you send. To avoid problems, I suggest that you subscribe using your real email address and not an alias. All list messages are available in a searchable archive at http://www.febo.com/list-archive. I want to be clear about one thing: this new list is in no way intended to displace or replace the tacgps list, which has got to be one of the highest SNR lists of all time. The idea is simply to have a place to take broader discussions. Enjoy! John N8UR jra@febo.com --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Tue Dec 18 10:02:15 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id KAA05801 for ; Tue, 18 Dec 2001 10:02:12 -0600 (CST) Message-Id: X-Sender: dhaselwood@POP3.ij.net Date: Tue, 18 Dec 2001 11:01:36 -0500 To: "TAPR Special Interest Group" From: Donald E Haselwood Subject: [tacgps] Re: GPS osc displining references Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3.0.6.32.20011218110136.0099fe00@POP3.ij.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk This is a re-post. It's been a week and I didn't see it on the list. Don > >Brooks, > >Good comments that stimulated my thinking! > >>The controller does use a 2nd order loop, primarily because such a loop in >>unconditionally stable. > >And a very good choice for a general purpose controller. > >BTW, after doing some simulations for another home project, (steering the time keeping on my "gizmo's" on my RS-485 network), I discovered that with a digital implementation, a second order loop is NOT unconditionally stable for all gains. It took me a while to understand what was happening, as I was also of the thinking that the second order loop was unconditionally stable. (In fact, that's why I emailed you about the source code--I couldn't figure out what I was doing wrong.) What happens is that at high gains the loop frequency (which increases with gain) can reach the point where the approximations for the digital filter fall apart, or put another way, the loop frequency was getting too close to the sampling frequency--a situation that would not be a problem in the gps osc steering situation, but something my simulations for the "time keeping" ran into (where getting on-time quickly was a big consideration). > >>Higher order loops can readily oscillate if the >>loop gain is not set carefully (see Gardner p.18). > >The unstable region is for low gains. Above that, the loop remains stable for all gains, so it doesn't look so critical for the phase-locked loop situation. > >>But really, there is little >>to be gained by going to a 3rd order loop. > >It looks like there are advantages to the 3rd order loop. The 3rd order loop has "memory" for rate of change of freq, whereas the 2nd order loop holds just frequency (p51,52 (BTW it looks like your p18 corresponds to p16 in my old, yellowed book)). Blanchard, _Phase-Locked Loops: Application to Coherent Receiver Design_, 1976 (pages aren't quite so yellow!), shows that the 3rd order loop is optimum in the presence of noise, when the disturbance is a frequency ramp (the cool breeze through the window syndrome). > >>Don's comment that a ramping >>VCXO frequency will cause a FREQUENCY error in a 2nd order loop is >>misleading. It actually causes a PHASE offset (see Gardner, Table 4.1) . >>This phase offset is of little importance for a frequency standard that is >>operating with a reasonably stable VCXO. > >Quite true for the *steady state*. However, for discipling the osc, the problem is dealing with change, e.g. the daily temp fluctuations are the major cause of Rb drift (I found an article that showed a graph and made this statement). One could approximate this error input as a sine wave with a 24 hour period. The task is to come up with a loop design that minimizes the error. It seems like the "noises" are the key factor in the loop design, and that's where I bog down (it's been 40 yrs since my last grad level course on this, so I'm a bit rusty). > >The whole issue revolves around the "reasonably stable VCXO"--it is that instability that we are trying to reduce. Gardner's chapt on optimization talks about Wiener optimization; Blanchard uses it too. I suspect that Wiener or Kalman filtering might be the area of references I need to pursue. > >>As explained in the article, drift of the inexpensive 24 MHz xtal osc is >>*essential* to overcoming the +/- 1 count ambiguity in the phase measuring >>circuit. If the 24 MHz osc were looked to the VCXO the count ambiguity >>would cause a phase error of +/- 42 nsec. Drift of the 24 MHz xtal reduces >>the error to a small fraction of this amount. Also, the effect of the drift >>of even a cheap xtal on the phase setpoint is negligible. > >After revisiting the setpoint changing issue it is now looking like it is not a major factor. If the setpoint were at 1000 counts (of the 24 Mhz counter) and there is a change of 10 ppm of the 24 Mhz osc, then there is a shift of the setpoint of .01 counts, out of a total one second count of 24E6, which translates to 4.2E-10 counts per one second interval. If it takes 1000 seconds for the 24 Mhz osc change, then the rate of shift is about 4.2E-13 cycles per second. Since the Rb appears--at best--stable in the 1E-12 to 1E-13 realm, then 4.2E-13--at worst--is not going to ruin the results. I was off by two orders magnitude on my earlier estimate. > >Concerning the drift and the increased resolution, I don't think the drift is necessary. Certainly it increases the resolution of the measurement, after averaging. If the osc were perfect, or more practical, phase locked to the Rb, then the loop would track to the point where the transition of the 24 Mhz osc counter fell exactly at the 1 pps event. Without the jitter on the 1 pps signal there would be a limit cycle that would be determined by the loop. With jitter, the limit cycle issue gets more complicated, and I expect it becomes a secondary factor. > >What led me to this thinking was wrestling with the resolution of the HC11 input-capture. I had an HC11 setup going about the same time you were working on your controller, where the micro clock input was driven by the Rb. At 10 Mhz, the input capture resolution is 400ns, which is rather course. The move and other life events put the project into the "think about" category. I had been pondering ways to improve this (and do so simply, e.g. faster micros, FPGAs, dither schemes,...), when it struck me that it is not all that important--the loop will stabilize with the 1 pps event coming exactly at the micro's bus cycle transition, so that the gps jitter will cause half of the events before and half after the micro's bus transition. The hardware is then "dog simple"--the Rb goes to the EXTAL input, and the gps goes to a input-capture pin. (The setpoint issue also goes away.) > >Another improvement might come from utilizing the 100 pps option with the Mot UT+. The specs say that the 1 pps can be switched to 100 pps, though I haven't tried this. The faster rate would help the averaging. The price paid is that the feature is not as common as the 1 pps on other gps engines. > >Anyway, that's where I'm at with it. If you run across some good references I'd appreciate if you would send them to me. > >Don, W4DH > --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Wed Dec 19 15:14:57 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA24658 for ; Wed, 19 Dec 2001 15:14:54 -0600 (CST) Message-Id: X-Sender: dhaselwood@POP3.ij.net Date: Wed, 19 Dec 2001 16:12:49 -0500 To: "TAPR Special Interest Group" From: Donald E Haselwood Subject: [tacgps] Re: Fw: Re: GPS osc disciplining references In-Reply-To: <001201c1880c$af7eea80$6400a8c0@brooksnotebook> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <3.0.6.32.20011219161249.00990d90@POP3.ij.net> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Brooks, Thank you for sending a direct response, as I did miss your reply. Apparently my posts are getting through, but I haven't seen any TAPR email from any of the lists for the last 8 days. I'll try once more with this post. >> Your "dog simple" scheme has not yet convinced this dog. If I >understand >> correctly, your arrangement would operate with a phase detector that >> produces no information about the size of the phase error - its phase >> detector needs only two output values, corresponding to phase leading >or >> phase lagging. How do you propose to operate a PI (or PID!) controller >with >> this limited input information? This is the classic "bang-bang" servo. The earlier texts on automatic control covered them, as control loops with relay switching of motors was common. Now, semiconductors can drive huge loads. Kuo doesn't talk about them in his book. The size of the phase difference comes from the averaging. With the HC11 steps are 400 ns, so some means of increasing the resolution is needed. With your scheme the step is 42 ns and averaging is used (to attempt) to increase the resolution as well (more on this later). I think in both schemes that, theoretically, the loop ends up in a limit cycle, the natural outgrowth of being digital. Practically, with osc-counter scheme in your design, the cycle would be masked by the 24 Mhz osc drift, and jitter on the 1 pps. With the dog-simple scheme, I think the limit cycle problem is complicated by "multiple modes." If the loop holds the phase difference sufficiently close to zero, such that the 1 pps jitter has a some pulses fall on the "other side" of the bus transition, after averaging (which takes place automatically as a result of the low loop frequency), the result is truly proportional. If there is a region of operation where the the all the 1 pps events fall within the same bus transition, then the average difference is simply 1 (saturation type of mode). For large phase differences the input capture is proportional, where the smallest step is 1 part in 2.5E6 (i.e. 400 ns steps). This gives rise to a multimode loop; one of my books mentions the concept briefly. Of course a faster micro would reduce the course resolution problem. A friend has a couple of abandoned prototype boards from his work with 68332 processors; the manual on the TPU says the input-capture resolution is 1 clock (not bus) cycle, and the clock on these units is 16 Mhz, and the newer 68xxx units go up to 25 Mhz. Such a unit would not easily be reproduced by others, however. Motorola's HC12 offers a 4x improvement over the HC11, partly because the bus operates at 1/2 the clock rather than 1/4. The Scenix micro boasts a 50 Mhz clock, and it is cheap, but after looking at the specs the input-capture resolution is far less as it takes place in software rather than hardware. The drift issue of the 24 Mhz osc still bothers me with your scheme. I don't think there is "averaging" as you expect under all conditions. Suppose that the 24000000 Hz osc is is off-frequency "by a hair"--which will occur often. This essentially generates a less-than-1-Hz beat frequency with the 1 pps--each 1 pps occurs at slightly different phase position with respect to the 24 Mhz osc. If that beat frequency is well above the controller loop cutoff, then it serves as dither signal and the effect is increased resolution due to averaging. If that beat frequency is low then it will cause slow, periodic 42ns phase shifts; the averaging will not take it out. This effect will occur as the 24 Mhz changes frequency due to temp cycling, and would occur as the osc passes through each integral 1 hz cycle off freq, e.g. 24000001, 24000002,... The worst case would be if the room temp is relatively stable so that the freqency changes very slowly, allowing long periods where the 42 ns shifts affect the loop. Phase locking eliminates that effect, but increases the hardware complexity...which brings me back to the direct driven micro scheme. At first it looked like the jitter on the 1 pps signal would takes care of the problem, but as I think it through I believe the problem remains. The loop will drive the phase to zero difference between that measured and the setpoint, i.e. coincide with a transition of the 24 Mhz osc--a 42 ns osc-counter version of the 400 ns dog-simple scheme. Now the 24 Mhz drifts every so slightly, the measurement then shifts so that it is one count different, which in turn affects the loop output. At the present, I don't know the size of the effect. >> independent time solutions. However, I believe the UT+ gps engine >only >> solves the equations once per second so the 99 extra output pulses >present >> no new information and averaging them is a waste of effort. An interesting point worth some investigation. It depends on where the phase-locking and jitter in the gps engine take place. I was under the impression that the 1 once per second solution had to do with the navigation parameters and the phase locking was a necessary part of the signal acquisition. If the jitter is independent of the once-per-second-update, then the 100 pps is not wasted as it serves to increase the measurement resolution due to the coarse (400 ns) step. Don --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Thu Dec 20 13:19:51 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id NAA08519 for ; Thu, 20 Dec 2001 13:19:48 -0600 (CST) Message-ID: From: "Brooks Shera" To: "TAPR Special Interest Group" References: Subject: [tacgps] Re: Fw: Re: GPS osc disciplining references Date: Thu, 20 Dec 2001 12:19:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <000801c1898b$3a28dae0$6400a8c0@brooksnotebook> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Don I agree that your two-state phase detector produces the "classic" bang-bang servo loop. I suspect that time has passed by this design because it is hard to predict how it will perform in the real world due to it's multiple modes, as you suggest. I guess that even in its "proportional" mode it would be merely a type I controller. Regarding your desire to put the phase detector entirely within the microprocessor: I still fail to see your motivation here since a faster and more flexible system requires only an R/S flip-flop and an oscillator chip of whatever freq you desire. I choose 24 MHz because it was $5 from DigiK and had a divided output to clock the PIC. If you want, you could go to a higher frequency, though I don't feel it is necessary. Your discussion of the averaging process is correct, I think, but the concerns you raise seriously overestimate the stability of the cheap 24 MHz chip. For the 24 MHz osc to stay within 42 nsec of the 1 pps (and thereby destroy the averaging) for periods the order of the integration time of the loop, say 1 hour, would require a stability for this $5 chip of 1.1e-11! However, even if we found such a little gem of an xtal, there are a least two other jitter sources that will produce the needed averaging. One is GPS jitter, with SA on, it was about 40 nsec and is now about 20 nsec. But an even larger jitter is caused by the 104 nsec peak-to-peak timing sawtooth from the Oncore receiver. The sawtooth is produced because the Oncore outputs the 1 pps by gating out the "closest" pulse from a 9.5 MHz internal clock. This sawtooth averages to a mean value of zero over a minute or so, as has been discussed here in the past. Presumably the average quickly approaches zero because the 9.5 MHz clock is not phase-related to the computed 1 pps time. Does this scheme sound familiar? Regards the 100 pps output: I haven't made any measurements on this, nor heard of any, but I would guess the 99 extra pulses are produced by selecting pulses from the pulse stream from the 9.5 MHz clock, based on GPS time as computed by the receiver at the previous 1-second epoch. If this is the case, they would probably show the same 104 nsec sawtooth, but with shifting time error (phase of the sawtooth) as you progress through the 100 pulses. So sampling on all these pulses would not reduce the GPS timing jitter, but it would cause the sawtooth to average to zero faster, if that were important. Which it is not. Brooks ----- Original Message ----- From: "Donald E Haselwood" To: "TAPR Special Interest Group" Sent: Wednesday, December 19, 2001 14:12 PM Subject: [tacgps] Re: Fw: Re: GPS osc disciplining references > Brooks, > > Thank you for sending a direct response, as I did miss your reply. > Apparently my posts are getting through, but I haven't seen any TAPR email > from any of the lists for the last 8 days. I'll try once more with this post. > > >> Your "dog simple" scheme has not yet convinced this dog. If I understand > >> correctly, your arrangement would operate with a phase detector that > >> produces no information about the size of the phase error - its phase > >> detector needs only two output values, corresponding to phase leading or > >> phase lagging. How do you propose to operate a PI (or PID!) controller > >>with this limited input information? > > This is the classic "bang-bang" servo. The earlier texts on automatic > control covered them, as control loops with relay switching of motors was > common. Now, semiconductors can drive huge loads. Kuo doesn't talk about > them in his book. > > The size of the phase difference comes from the averaging. With the HC11 > steps are 400 ns, so some means of increasing the resolution is needed. > With your scheme the step is 42 ns and averaging is used (to attempt) to > increase the resolution as well (more on this later). > > I think in both schemes that, theoretically, the loop ends up in a limit > cycle, the natural outgrowth of being digital. Practically, with > osc-counter scheme in your design, the cycle would be masked by the 24 Mhz > osc drift, and jitter on the 1 pps. With the dog-simple scheme, I think > the limit cycle problem is complicated by "multiple modes." If the loop > holds the phase difference sufficiently close to zero, such that the 1 pps > jitter has a some pulses fall on the "other side" of the bus transition, > after averaging (which takes place automatically as a result of the low > loop frequency), the result is truly proportional. If there is a region of > operation where the the all the 1 pps events fall within the same bus > transition, then the average difference is simply 1 (saturation type of > mode). For large phase differences the input capture is proportional, > where the smallest step is 1 part in 2.5E6 (i.e. 400 ns steps). This gives > rise to a multimode loop; one of my books mentions the concept briefly. > > Of course a faster micro would reduce the course resolution problem. A > friend has a couple of abandoned prototype boards from his work with 68332 > processors; the manual on the TPU says the input-capture resolution is 1 > clock (not bus) cycle, and the clock on these units is 16 Mhz, and the > newer 68xxx units go up to 25 Mhz. Such a unit would not easily be > reproduced by others, however. Motorola's HC12 offers a 4x improvement > over the HC11, partly because the bus operates at 1/2 the clock rather than > 1/4. The Scenix micro boasts a 50 Mhz clock, and it is cheap, but after > looking at the specs the input-capture resolution is far less as it takes > place in software rather than hardware. > > The drift issue of the 24 Mhz osc still bothers me with your scheme. I > don't think there is "averaging" as you expect under all conditions. > Suppose that the 24000000 Hz osc is is off-frequency "by a hair"--which > will occur often. This essentially generates a less-than-1-Hz beat > frequency with the 1 pps--each 1 pps occurs at slightly different phase > position with respect to the 24 Mhz osc. If that beat frequency is well > above the controller loop cutoff, then it serves as dither signal and the > effect is increased resolution due to averaging. If that beat frequency is > low then it will cause slow, periodic 42ns phase shifts; the averaging will > not take it out. This effect will occur as the 24 Mhz changes frequency due > to temp cycling, and would occur as the osc passes through each integral 1 > hz cycle off freq, e.g. 24000001, 24000002,... The worst case would be if > the room temp is relatively stable so that the freqency changes very > slowly, allowing long periods where the 42 ns shifts affect the loop. > Phase locking eliminates that effect, but increases the hardware > complexity...which brings me back to the direct driven micro scheme. > > At first it looked like the jitter on the 1 pps signal would takes care of > the problem, but as I think it through I believe the problem remains. The > loop will drive the phase to zero difference between that measured and the > setpoint, i.e. coincide with a transition of the 24 Mhz osc--a 42 ns > osc-counter version of the 400 ns dog-simple scheme. Now the 24 Mhz drifts > every so slightly, the measurement then shifts so that it is one count > different, which in turn affects the loop output. At the present, I don't > know the size of the effect. > > >> independent time solutions. However, I believe the UT+ gps engine only > >> solves the equations once per second so the 99 extra output pulses present > >> no new information and averaging them is a waste of effort. > > An interesting point worth some investigation. It depends on where the > phase-locking and jitter in the gps engine take place. I was under the > impression that the 1 once per second solution had to do with the > navigation parameters and the phase locking was a necessary part of the > signal acquisition. If the jitter is independent of the > once-per-second-update, then the 100 pps is not wasted as it serves to > increase the measurement resolution due to the coarse (400 ns) step. > > > Don --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Fri Dec 28 16:26:12 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA00177 for ; Fri, 28 Dec 2001 16:26:09 -0600 (CST) Date: Fri, 28 Dec 2001 14:25:29 -0800 (PST) From: Rick Gilligan To: "TAPR Special Interest Group" Subject: [tacgps] Re: US$20 GPS - Report In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk On Mon, 12 Feb 2001, Darryl Smith wrote: > These units will fail to lock onto GPS when you move them significant > distances very quickly, such as when you fly one from Australia to the USA > powered down, but with the battery backup attached. Quickly removing the > battery backup with the unit powered down will reset the unit, allowing the > GPS to seach the sky for satellites. > > I think that the way this unit works is that it assumes that cars do not > drive 8,000 miles in 12 hours, and therefore is using all the computing > power to search the sky where it thinks it is, rather than spending some > time also searching for other satellites. This makes sense because the unit > has very good performance in even areas where part of the sky is obscured, > and re-acquired very quickly I'm responding to an old message, but my symptom was the same with a Motorola GT+ receiver (I believe it has 2.01 firmware). Flew from California to New Zealand, left it on three days. Only found one or two satellites which were visible both from California and New Zealand. After three days, never got a lock. Hadn't brought the proper software to re-initialize it, also didn't have Internet access to look up the commands to re-write the code. Not a good thing... the receiver knew the current GPS time, had a valid almanac (and could load new almanacs from the one or two co-visible satellites). It isn't easy to short out the soldered-in battery (nor probably a very good thing to do). 73 Rick N6NL --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Sat Dec 29 12:40:57 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA09806 for ; Sat, 29 Dec 2001 12:40:55 -0600 (CST) Date: Sat, 29 Dec 2001 13:40:37 -0500 From: "John R. Ackermann" To: "TAPR Special Interest Group" Subject: [tacgps] Using the PECL level outputs in the Z3801A? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <83361447.1009633237@[192.168.1.26]> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk Has anyone else had challenges using the 1pps and 10MHz pseudo ECL outputs on the Z3801A's DB-25 connector? I find that triggering off of these signals is fairly tricky and am wondering if I'm alone in that. I've been thinking about whether a PECL to TTL adapter might be a good idea. John --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org From bounce-tacgps-6754@lists.tapr.org Sat Dec 29 12:48:33 2001 Received: from lists.tapr.org (lists.tapr.org [204.17.217.24]) by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA10216 for ; Sat, 29 Dec 2001 12:48:32 -0600 (CST) X-Sent: 29 Dec 2001 18:48:09 GMT Message-Id: X-Sender: dbade@mail.clecom.com Date: Sat, 29 Dec 2001 13:46:38 -0500 To: "TAPR Special Interest Group" From: Doug Bade Subject: [tacgps] Re: Using the PECL level outputs in the Z3801A? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Software: Lyris Server version 3.0 List-Subscribe: List-Owner: X-List-Host: Tucson Amateur Packet Radio Reply-To: "TAPR Special Interest Group" X-Message-Id: <4.3.2.7.2.20011229134429.00b8d250@pop.oh.verio.com> Sender: bounce-tacgps-6754@lists.tapr.org Precedence: bulk I had not tried, I am using 10mhz only at this time... What seems to be the nature of the challenge??? Doug KB8GVQ At 01:40 PM 12/29/2001 -0500, you wrote: >Has anyone else had challenges using the 1pps and 10MHz pseudo ECL outputs >on the Z3801A's DB-25 connector? I find that triggering off of these >signals is fairly tricky and am wondering if I'm alone in that. I've been >thinking about whether a PECL to TTL adapter might be a good idea. > >John >--- >You are currently subscribed to tacgps as: DOUG@CLECOM.COM >To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org --- You are currently subscribed to tacgps as: lyris.tacgps@tapr.org To unsubscribe send a blank email to leave-tacgps-6754G@lists.tapr.org