From shelden3@ionet.net Sun Sep 06 02:54:18 1998 Received: from mail.ionet.net (mail.ionet.net [206.41.128.16]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA20567 for ; Sun, 6 Sep 1998 02:54:15 -0500 (CDT) From: shelden3@ionet.net Received: from charlie (who@okcnas2-32.ionet.net [38.193.48.94]) by mail.ionet.net (8.9.1a/8.9.1) with SMTP id CAA03061 for ; Sun, 6 Sep 1998 02:55:48 -0500 (CDT) Date: Sun, 6 Sep 1998 02:55:48 -0500 (CDT) Message-Id: <199809060755.CAA03061@mail.ionet.net> X-Sender: shelden3@ionet.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: tacgps@tapr.org Subject: oncore connector I just received a Motorola VP Oncore, does anyone know of a source for the OSX connector for the antenna plug? Thanks for any information in advance. Charlie KC5NBH From srbible@gate.net Sun Sep 06 06:52:19 1998 Received: from osage.gate.net (root@osage.gate.net [198.206.134.25]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id GAA04463 for ; Sun, 6 Sep 1998 06:52:18 -0500 (CDT) Received: from avatar (kngga2-56.gate.net [207.36.2.56]) by osage.gate.net (8.8.6/8.6.12) with SMTP id HAA86876 for ; Sun, 6 Sep 1998 07:52:07 -0400 Message-Id: <3.0.5.32.19980906075253.00914460@pop.gate.net> X-Sender: srbible@pop.gate.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 06 Sep 1998 07:52:53 -0400 To: tacgps@tapr.org From: "Steven R. Bible" Subject: Re: [TACGPS:1822] oncore connector In-Reply-To: <199809060755.CAA03061@mail.ionet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:57 AM 9/6/98 -0500, you wrote: > I just received a Motorola VP Oncore, does anyone know of a source >for the OSX connector for the antenna plug? Thanks for any information in >advance. Charlie, TAPR sells a RF pigtail that has the MCX connector on one end and nothing on the other. The coax is 24" (I think) of RG-174. The connectors can be bought at Digikey, but you need a crimping tool to install them. - Steve (n7hpr@tapr.org) From w2hob@uscom.com Sun Sep 06 10:11:32 1998 Received: from fillmore.criticalpath.net (fillmore.criticalpath.net [209.188.6.131]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA10772 for ; Sun, 6 Sep 1998 10:11:26 -0500 (CDT) Received: (cpmta 20747 invoked from network); 6 Sep 1998 08:11:20 -0700 Received: from usol-209-186-28-19.uscom.com (HELO w2hob) (209.186.28.19) by smtp.uscom.com with SMTP; 6 Sep 1998 08:11:20 -0700 X-Sent: 6 Sep 1998 15:11:20 GMT Message-Id: <3.0.1.32.19980906110320.006e133c@mail.uscom.com> X-Sender: w2hob@mail.uscom.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 06 Sep 1998 11:03:20 -0400 To: tacgps@tapr.org From: Boyd Prestwood Subject: Re: [TACGPS:1822] oncore connector In-Reply-To: <199809060755.CAA03061@mail.ionet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:57 AM 9/6/98 -0500, you wrote: > I just received a Motorola VP Oncore, does anyone know of a source >for the OSX connector for the antenna plug? Thanks for any information in >advance. > > Charlie KC5NBH W2HOB RESPONSE: Charlie, check the GPS page. They have a pigtail available for $15. Have fun es 73 de Boyd From henk@ripe.net Mon Sep 07 02:49:54 1998 Received: from ncc.ripe.net (ncc.ripe.net [193.0.1.99]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id CAA11248 for ; Mon, 7 Sep 1998 02:49:53 -0500 (CDT) Received: from localhost by ncc.ripe.net with SMTP id AA07581 (5.65a/RIPE-NCC); Mon, 7 Sep 1998 09:49:21 +0200 Date: Mon, 7 Sep 1998 09:49:20 +0200 (MET DST) From: "Henk Uijterwaal (RIPE-NCC)" To: tacgps@tapr.org Subject: Re: [TACGPS:1822] oncore connector In-Reply-To: <199809060755.CAA03061@mail.ionet.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 6 Sep 1998 shelden3@ionet.net wrote: > I just received a Motorola VP Oncore, does anyone know of a source > for the OSX connector for the antenna plug? Thanks for any information in > advance. I've order them (through a local distributor) from The Phoenix Company, 555 Pond Drive, Wood Dale, IL 60191-1192, phone 1-800-323-9562. They have connectors, tools to attach them to a cable as well as several off-the-shelf cables with a OSX connector on one or both ends. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Pager: +31.6.57626855 ------------------------------------------------------------------------------ %DCL-E-NOCFFE, unable to locate coffee - keyboard input suspended. From shelden3@ionet.net Mon Sep 07 08:17:59 1998 Received: from mail.ionet.net (mail.ionet.net [206.41.128.16]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA27748 for ; Mon, 7 Sep 1998 08:17:57 -0500 (CDT) From: shelden3@ionet.net Received: from charlie (okcnas6-27.ionet.net [38.193.49.41]) by mail.ionet.net (8.9.1a/8.9.1) with SMTP id IAA26603 for ; Mon, 7 Sep 1998 08:19:32 -0500 (CDT) Date: Mon, 7 Sep 1998 08:19:32 -0500 (CDT) Message-Id: <199809071319.IAA26603@mail.ionet.net> X-Sender: shelden3@ionet.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: tacgps@tapr.org Subject: mcx connector Thanks to all for the information, a friend of mine came over and looked at the connector and said "hey i hve on of those in my van". Sure enough he did, it was sold by garman but works just the same. Once again thanks for the responses. Charlie From rick@cnssys.com Mon Sep 07 18:12:46 1998 Received: from gw.cnssys.com (root@cnssys.com [207.97.17.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA24048 for ; Mon, 7 Sep 1998 18:12:43 -0500 (CDT) Received: from rick (rick.cnssys.com [207.97.17.16]) by gw.cnssys.com (8.9.0/8.9.0) with SMTP id SAA31560; Mon, 7 Sep 1998 18:52:56 -0400 From: "Richard M. Hambly" To: , Subject: RE: [TACGPS:1793] TAC32 forwarded help request Date: Mon, 7 Sep 1998 18:51:53 -0400 Message-ID: <001301bddab2$1b560ce0$101161cf@rick.cnssys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Luciano, I finally received a number of old model UT and GT receivers for testing. My initial results show that Tac32 is working correctly. > I am testing the tac32 with my Oncore UT but I have discovered that > elevation and azimuth are not displayed on the screen and the sky map > of the sat is empty. This is correct. The message that conveys this information is the @@Bb. The Oncore UT did not include this message until Version 1.6. The GT did not include this message until Version 2.0 (the first GT+). > Another problem is that if the software recognize the receiver > the configuration page is forbidden to the user and is impossible to > change the functions (example: timing or static application mode). Tac32 is programmed to know what you can and cannot change based on the receiver type version number. There are no changes on that page that will work with the UT Version 1.3. Your workaround makes it look as though you are changing the parameters but the reviver is not doing anything different. For example, the UT Version 1.3 will only operate in 3-D mode. It does not support the position hold or altitude hold messages. The moral of the story is get a UT+ (version 2.0 or newer) or a VP version 8.8 or newer. Older UT and GT units can be reprogrammed with new firmware, which will help. They still can only do what the hardware allows but most functions can be activated this way. The price for Hams is $16 plus shipping. Contact me if you are interested. Rick WB2TNL -----Original Message----- From: Richard M. Hambly [mailto:rick@cnssys.com] Sent: Tuesday, August 25, 1998 11:27 AM To: LUCIANO_PARAMITHIOTTI@HP-Italy-om4.om.hp.com; tacgps@tapr.org Subject: RE: [TACGPS:1793] TAC32 forwarded help request Luciano, Just a quick note from the author of TAC32 to let you know that I am looking into this. Unfortunately the only UT 1.3 receiver I have here is not working. I am trying to get another one so I can complete the tests. I suspect a problem with TAC32. I will let you know. Rick WB2TNL -----Original Message----- From: tacgps@tapr.org [mailto:tacgps@tapr.org]On Behalf Of Brooks Shera Sent: Tuesday, August 18, 1998 5:34 PM To: tacgps@tapr.org Subject: [TACGPS:1793] TAC32 forwarded help request I am forwarding the message below for consideration by the TAC-32 experts. Any ideas about what's wrong? Brooks ----------------------------------------------------------------------- > > I am testing the tac32 with my Oncore UT but I have discovered that > elevation and azimut are not displayed on the screen and the sky map > of the sat.is empty.Another problem is that if the software recognize > the receiver > the configuration page is forbitten to the user and is impossible to > change the functions (example: timing or static application mode). > The work around is to disconnect the serial cable PC/RX ,start the tac > and ,after the rx failure message reconnect the cable.This way permit > the correct receiver mode selection.Some help? > My receiver is a model R221A1111 software version 1 rev.3 (Motorola) > sw date sept 1996 HWDR P/N 1 SERIAL R000MU MANUFACTUR DATE 6G25. > > Luciano > >LUCIANO_PARAMITHIOTTI@HP-Italy-om4.om.hp.com From rraspet@erols.com Tue Sep 08 06:36:30 1998 Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id GAA11372 for ; Tue, 8 Sep 1998 06:36:29 -0500 (CDT) Received: from erols.com (207-172-137-111.s48.as2.dam.erols.com [207.172.137.111]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id HAA28350 for ; Tue, 8 Sep 1998 07:36:26 -0400 (EDT) Message-ID: <35F51631.D87DC3FB@erols.com> Date: Tue, 08 Sep 1998 07:34:09 -0400 From: Ron Raspet Reply-To: rraspet@erols.com X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: tacgps@tapr.org Subject: GPS Question References: <001301bddab2$1b560ce0$101161cf@rick.cnssys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Friends, I have access to a "TRIPMATE" Hyperformance GPS Navigation unit. The cpmpany that sold this GPS receiver is DeLorme. When I asked DeLorme if this unit had a 1 pps signal, they told me that it would work on a serial port. Does anyone know if it supoports the 1 pps signal? Thanks Ron N3JLF From eac@shore.net Tue Sep 08 07:49:23 1998 Received: from mermaid.shore.net (mermaid.shore.net [207.244.124.6]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA17963 for ; Tue, 8 Sep 1998 07:49:21 -0500 (CDT) Received: from lynnma-07-68.port.shore.net (lynnma-07-68) [207.244.109.68] by mermaid.shore.net with smtp (Exim) id 0zGNCr-0007VS-00; Tue, 8 Sep 1998 08:49:14 -0400 Message-ID: <35F519A9.53A4@shore.net> Date: Tue, 08 Sep 1998 07:48:57 -0400 From: "Eric A. Cottrell" X-Mailer: Mozilla 2.02 (OS/2; I) MIME-Version: 1.0 To: tacgps@tapr.org Subject: Re: [TACGPS:1828] GPS Question References: <35F51631.D87DC3FB@erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ron Raspet wrote: > > Friends, > > I have access to a "TRIPMATE" Hyperformance GPS Navigation unit. The cpmpany > that sold this GPS receiver is DeLorme. When I asked DeLorme if this unit had a > 1 pps signal, they told me that it would work on a serial port. > > Does anyone know if it supoports the 1 pps signal? Hello, The Zodiac chipset used does support a 1 pps but it is not brought out to the serial port. It is also unknown of the 1 pps is synced to UTC although later firmware does claim this feature. Look up the Tripmate FAQ at Peter Bennett's GPS website for more info. 73 Eric eac@shore. From jra@febo.com Fri Sep 11 14:45:05 1998 Received: from meow.febo.com (root@meow.febo.com [209.115.70.194]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA06825 for ; Fri, 11 Sep 1998 14:45:03 -0500 (CDT) Received: from meow.febo.com (jra@localhost [127.0.0.1]) by meow.febo.com (8.8.5/8.8.5) with ESMTP id PAA01953 for ; Fri, 11 Sep 1998 15:44:59 -0400 Message-Id: <199809111944.PAA01953@meow.febo.com> To: tacgps@tapr.org Subject: Worst Case timing performance of Oncore? Date: Fri, 11 Sep 1998 15:44:59 -0400 From: John Ackermann N8UR Does anyone have a feel for what the worst-case PPS performance of a 6 channel Oncore (the old style unit) would be? I'm interested in knowing whether the worst case is still better than 1 microsecond, whether it could be as much as a few milliseconds, or if it's somewhere in between, just where that might be. By "worst case," I mean running in 0D mode, but with lousy satellite geometry, perhaps only 3 or 4 birds locked, loses lock occassionally, but in general is locked and running. I'm asking because I'm trying to understand performance of the ntp/kernel PLL timekeeping in Linux, and I'm seeing some results that could lead one to believe there's some amount of jitter on the PPS signal from the Oncore. I am skeptical that's the case, but some info would help me rule the GPS in or out as a problem. Thanks, John N8UR jra@febo.com From jjjohnson@saiph.hpl.hp.com Mon Sep 14 20:30:28 1998 Received: from hplms26.hpl.hp.com (root@hplms26.hpl.hp.com [15.255.168.31]) by tapr.org (8.8.5/8.8.5) with ESMTP id UAA02815 for ; Mon, 14 Sep 1998 20:30:27 -0500 (CDT) Received: from saiph.hpl.hp.com (saiph.hpl.hp.com [15.9.144.186]) by hplms26.hpl.hp.com (8.8.6/8.8.6 HPLabs Relay) with ESMTP id RAA09674 for ; Mon, 14 Sep 1998 17:47:59 -0700 (PDT) Received: (from jjjohnson@localhost) by saiph.hpl.hp.com (8.8.6/8.8.6 HPLabs) id RAA22057 for tacgps@tapr.org; Mon, 14 Sep 1998 17:47:52 -0700 (PDT) From: "James L. Johnson" Message-Id: <199809150047.RAA22057@saiph.hpl.hp.com> Subject: Re: [TACGPS:1830] Worst Case timing performance of Oncore? To: tacgps@tapr.org Date: Mon, 14 Sep 1998 17:47:52 -0800 (PDT) In-Reply-To: <199809111944.PAA01953@meow.febo.com> from "John Ackermann N8UR" at Sep 11, 98 02:47:05 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Date: Fri, 11 Sep 1998 14:47:05 -0500 (CDT) > Sender: tacgps@tapr.org > From: John Ackermann N8UR > To: tacgps@tapr.org > Subject: [TACGPS:1830] Worst Case timing performance of Oncore? > > Does anyone have a feel for what the worst-case PPS performance of a 6 > channel Oncore (the old style unit) would be? I'm interested in knowing > whether the worst case is still better than 1 microsecond, whether it > could be as much as a few milliseconds, or if it's somewhere in between, > just where that might be. > > By "worst case," I mean running in 0D mode, but with lousy satellite geometry, > perhaps only 3 or 4 birds locked, loses lock occassionally, but in general is > locked and running. > > I'm asking because I'm trying to understand performance of the ntp/kernel PLL > timekeeping in Linux, and I'm seeing some results that could lead one to > believe there's some amount of jitter on the PPS signal from the Oncore. I > am skeptical that's the case, but some info would help me rule the GPS in or > out as a problem. > > Thanks, > > John N8UR > jra@febo.com > > John, I ran your question by a colleague who has a lot of experience with the Motorola receivers and here is his reply: 73, Jim W6SC jjohnson@hpl.hp.com -------------------------------------------------------------------- From: Robin P Giffard To: jjohnson@hpl.hp.com (Jim Johnson) Date: Mon, 14 Sep 1998 17:28:01 -0800 (PDT) Jim, While a healthy 6-channel ONCORE is tracking at least one satellite in position-hold mode, the time error will not reach 1 microsecond. This assumes calibrated delays, and a satisfactory set of antenna coordinates. Tracking is indicated by a continuous mode=8 reading. However, the older receivers do not have time "RAIM". This means that a single malfunctioning, or mis-programmed, satellite can pull the solution quite a lot. This is rare but has been known to happen. I believe that a single satellite showing an error of more than 60 microseconds will be eliminated if enough satellites remain for a fix. If the receiver loses its GPS time solution for any reason, the 1 PPS output will begin to drift backward in time at a rate of about 13 microseconds per second. The more recent UT receiver has RAIM, and a bad satellite will be eliminated from the solution if there are 4 or more being tracked. This receiver can also be programmed to blank its 1 PPS pulse if no UTC fix is possible. No RAIM algoritm can eliminate a bad satellite unless several are being tracked. So if you are tracking a single satellite in position hold, it had better be good. Robin Giffard, HP Labs. From wd5ivd@tapr.org Mon Sep 14 21:10:14 1998 Received: from [207.8.125.53] (greg-jones-pc4.customer.jump.net [207.8.125.53]) by tapr.org (8.8.5/8.8.5) with ESMTP id VAA07059; Mon, 14 Sep 1998 21:10:04 -0500 (CDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Date: Mon, 14 Sep 1998 21:09:36 -0500 To: "HF SIG list mailing", " Spread Spectrum ", " TAPR/AMSAT DSP ", "APRS SIG list mailing", "NETSIG list mailing", "BBS SIG list mailing", " tacgps ", aprsnews, mic-e, TAPR Regional Freq From: "Greg Jones, WD5IVD" Subject: TAPR.ORG Down and now Back TAPR.ORG was down on Saturday for a system upgrade. We installed a new processor board as well as added more memory and a new 9G HD. Sunday morning very early, the root drive crashed and burned. Lee spent Sunday and today (Monday) recovering from the crash on root. We had backed up the system just before the upgrade, so we didn't get hit very hard. We took this time to also upgrade the OS on the system, which we had planned to in the future. Lee got the system back operational about 6pm tonight and all aspects of the system should be operational by this posting. We will be spending the rest of tonight doing checks on various automatic operations to make sure that everything is running correctly. Cheers - Greg ----- Greg Jones, WD5IVD President TAPR (http://www.tapr.org) PhD Candidate, Instructional Technology, UT Austin email: wd5ivd@tapr.org web: http://www.tapr.org/~wd5ivd Experience is what you get when you were expecting something else. From jra@febo.com Tue Sep 15 11:02:06 1998 Received: from meow.febo.com (root@meow.febo.com [209.115.70.194]) by tapr.org (8.8.5/8.8.5) with ESMTP id LAA00597 for ; Tue, 15 Sep 1998 11:02:02 -0500 (CDT) Received: from meow.febo.com (jra@localhost [127.0.0.1]) by meow.febo.com (8.8.5/8.8.5) with ESMTP id HAA09195 for ; Tue, 15 Sep 1998 07:21:01 -0400 Message-Id: <199809151121.HAA09195@meow.febo.com> To: tacgps@tapr.org Subject: Re: [TACGPS:1831] Re: Worst Case timing performance of Oncore? In-reply-to: Your message of "Mon, 14 Sep 1998 21:13:07 CDT." <199809150047.RAA22057@saiph.hpl.hp.com> Date: Tue, 15 Sep 1998 07:21:01 -0400 From: John Ackermann N8UR Thanks for the great information! John ---- In message <199809150047.RAA22057@saiph.hpl.hp.com>, "James L. Johnson" writes: >> Date: Fri, 11 Sep 1998 14:47:05 -0500 (CDT) >> Sender: tacgps@tapr.org >> From: John Ackermann N8UR >> To: tacgps@tapr.org >> Subject: [TACGPS:1830] Worst Case timing performance of Oncore? >> >> Does anyone have a feel for what the worst-case PPS performance of a 6 >> channel Oncore (the old style unit) would be? I'm interested in knowing >> whether the worst case is still better than 1 microsecond, whether it >> could be as much as a few milliseconds, or if it's somewhere in between, >> just where that might be. >> >> By "worst case," I mean running in 0D mode, but with lousy satellite geometr >y, >> perhaps only 3 or 4 birds locked, loses lock occassionally, but in general i >s >> locked and running. >> >> I'm asking because I'm trying to understand performance of the ntp/kernel PL >L >> timekeeping in Linux, and I'm seeing some results that could lead one to >> believe there's some amount of jitter on the PPS signal from the Oncore. I >> am skeptical that's the case, but some info would help me rule the GPS in or >> out as a problem. >> >> Thanks, >> >> John N8UR >> jra@febo.com >> >> > > >John, > > I ran your question by a colleague who has a lot of experience >with the Motorola receivers and here is his reply: > >73, >Jim W6SC >jjohnson@hpl.hp.com >-------------------------------------------------------------------- > >From: Robin P Giffard >To: jjohnson@hpl.hp.com (Jim Johnson) >Date: Mon, 14 Sep 1998 17:28:01 -0800 (PDT) > >Jim, > > While a healthy 6-channel ONCORE is tracking at least one satellite in > position-hold mode, the time error will not reach 1 microsecond. This > assumes calibrated delays, and a satisfactory set of antenna coordinates. > Tracking is indicated by a continuous mode=8 reading. > > However, the older receivers do not have time "RAIM". This means that a > single malfunctioning, or mis-programmed, satellite can pull the solution > quite a lot. This is rare but has been known to happen. I believe > that a single satellite showing an error of more than 60 microseconds > will be eliminated if enough satellites remain for a fix. If the > receiver loses its GPS time solution for any reason, the 1 PPS output > will begin to drift backward in time at a rate of about 13 microseconds > per second. > > The more recent UT receiver has RAIM, and a bad satellite will be > eliminated from the solution if there are 4 or more being tracked. This > receiver can also be programmed to blank its 1 PPS pulse if no UTC fix is > possible. > > No RAIM algoritm can eliminate a bad satellite unless several are being > tracked. So if you are tracking a single satellite in position hold, it > had better be good. > > Robin Giffard, > HP Labs. From vkean@ds.net Tue Sep 15 11:45:25 1998 Received: from s1.ds.net (s1.ds.net [207.239.204.1]) by tapr.org (8.8.5/8.8.5) with ESMTP id LAA06734 for ; Tue, 15 Sep 1998 11:45:17 -0500 (CDT) Received: from desk.k1lt.ampr.org (i2p81.ds.net [207.239.204.81]) by s1.ds.net (8.8.5/8.8.5) with SMTP id XAA06257 for ; Mon, 14 Sep 1998 23:50:03 -0400 (EDT) Received: by desk.k1lt.ampr.org with Microsoft Mail id <01BDE03B.517905A0@desk.k1lt.ampr.org>; Mon, 14 Sep 1998 23:56:41 -0400 Message-ID: <01BDE03B.517905A0@desk.k1lt.ampr.org> From: "Victor A. Kean, Jr." To: "'tacgps@tapr.org'" Subject: External Antenna for Garmon GPS12 Date: Mon, 14 Sep 1998 23:56:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by tapr.org id LAA06734 Right, the Garmon 12, unlike the 12XL, doesn't have provisions for an external antenna. Nevertheless, you can use it inside. I do, in my basement. I have on of those hockey puck external antennas, which is outside, on about 20 feet of RG58. The puck receives its power from my Garmon 20. I inserted a BNC T connector into the line between the antenna and the Garmon 20. In the third position on the T connector, I inserted a 1.8 inch wire. When the 1.8 inch wire is taped to the surface of the Garmon 12, I get full scale signals from the satellites that have an unobstructed view of my puck. Thus, I can play GPS with the 12 inside. If this technique were done with attention to impedance matching and antennas more effective than 1/4 wave of #18 wire, perhaps there would be enough signal to get a few inches across the room. Now I have more incentive to mount the puck on the top of my tower. Vic, K1LT From clark@tomcat.gsfc.nasa.gov Tue Sep 15 15:11:10 1998 Received: from aleph.gsfc.nasa.gov (aleph.gsfc.nasa.gov [128.183.201.86]) by tapr.org (8.8.5/8.8.5) with ESMTP id PAA02505 for ; Tue, 15 Sep 1998 15:11:09 -0500 (CDT) Received: from tomcat.gsfc.nasa.gov (scheat.gsfc.nasa.gov) by aleph.gsfc.nasa.gov; Tue, 15 Sep 1998 16:11:02 -0400 Message-Id: <35FEC9D4.4B4891CA@tomcat.gsfc.nasa.gov> Date: Tue, 15 Sep 1998 16:11:00 -0400 From: "Dr Thomas A Clark (W3IWI)" Reply-To: clark@tomcat.gsfc.nasa.gov X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 To: tacgps@tapr.org Subject: Re: [TACGPS:1830] Worst Case timing performance of Oncore? References: <199809111944.PAA01953@meow.febo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Ackermann N8UR wrote: > Does anyone have a feel for what the worst-case PPS performance of a 6 > channel Oncore (the old style unit) would be? I'm interested in knowing > whether the worst case is still better than 1 microsecond, whether it > could be as much as a few milliseconds, or if it's somewhere in between, > just where that might be. You got several other answers, I'll speak from my experience with 50+ 6-channel units around the world. First, let me presume that the receivers have version 5.x or greater firmware. The original PVT-6 performance before Version 5 was disappointing, and pre-5.0 receivers had a ~600 nsec timing bias in them. My first answer is that I have NEVER seen a receiver that was tracking satellites have an error more than one usec. If it loses all satellites, then the pulse drifts off slowly, depending on the internal xtal in the rcvr. This might give rise to a 1 msec error after ~1 hour. I presume you are asking in the context of your LINUX xntpd effort. Let me offer a caveat: The "stock" GPS xntpd uses the time in the $GPGGA message, but the GGA time is the time of the LAST VALID POSITION FIX. Therefore in zero-D mode, or if the receiver is unlocked and "coasting", the GGA HHMMSS field is not updated at all. This is the reason I strongly recommend that the xntpd code must be modified to handle the $GPZDA message which has the CURRENT UTC time, regardless of the zero-D or "coasting". Jim's posting of the note from Robin Giffard has some good info in it. The TRAIM option in the newer receivers virtually guarantees the integrity of the timing. The TRAIM code in the receivers lets you select the option of disabling the 1PPS output if TRAIM decides the timing is bogus. AFAIK, TRAIM was never included in any of the 6-channel receivers like you mentioned. Robin said that TRAIM was in the UT -- I believe that the original UT lacked TRAIM, but it is in the newer UT+ and it is also in the newer VP ONCORE receivers. Basically, TRAIM for timing says "OK -- I only need one satellite for timing. But If I have three in lock, and one is bad, I know which two are good." [Extend this to more than three and you have not only a good/bad test but also a way to quantify the "how good?" question as well as an over- determined timing solution.] 73, Tom From relseth@siosolutns.win.net Wed Sep 16 20:12:09 1998 Received: from ns2.win.net (ns2.win.net [204.215.209.4]) by tapr.org (8.8.5/8.8.5) with ESMTP id UAA00886 for ; Wed, 16 Sep 1998 20:12:07 -0500 (CDT) Received: from siosolutns.UUCP (uucp@localhost) by ns2.win.net (8.8.7/8.6.9) with UUCP id SAA23983 for tacgps@tapr.org; Wed, 16 Sep 1998 18:04:16 -0400 (EDT) Received: by win.net!siosolutns; Wed, 16 Sep 1998 17:03:25 X-Mailer: WinNET Mail, v3.5 Message-ID: <190@siosolutns.win.net> Reply-To: relseth@siosolutns.win.net (Raymond A. Elseth) To: tacgps@tapr.org Date: Wed, 16 Sep 1998 17:03:25 Subject: Re: [TACGPS:1835] Re: Worst Case timing performance of Oncore? From: relseth@siosolutns.win.net (Raymond A. Elseth) Slightly (but not much) off-topic..... I have just recieved a CNSClock (very nice piece, BTW). Our organization has an older RS/6000 running AIX v.3.2.5 (an older but still supported release of AIX). I would like to set the RS/6000 up as a xntpd server using the CNSClock under AIX, however we are not strong on AIX/Unix skills. Can anyone point me to a source for a "compile and go" xntpd module that includes Tom's recommended $GPZDA mod _and_ will run under AIX v.3.2.5? RAE ______________________________________________________________________ Raymond A. Elseth Internet: relseth@siosolutns.win.net SIO Solutions CIS UserID: 76137,2426 Palatine, IL Voice: 847/705-9721 From jra@febo.com Wed Sep 16 20:32:08 1998 Received: from meow.febo.com (root@meow.febo.com [209.115.70.194]) by tapr.org (8.8.5/8.8.5) with ESMTP id UAA02394 for ; Wed, 16 Sep 1998 20:32:06 -0500 (CDT) Received: from meow.febo.com (jra@localhost [127.0.0.1]) by meow.febo.com (8.8.5/8.8.5) with ESMTP id IAA16021 for ; Wed, 16 Sep 1998 08:09:18 -0400 Message-Id: <199809161209.IAA16021@meow.febo.com> To: tacgps@tapr.org Subject: Re: [TACGPS:1835] Re: Worst Case timing performance of Oncore? In-reply-to: Your message of "Tue, 15 Sep 1998 15:19:35 CDT." <35FEC9D4.4B4891CA@tomcat.gsfc.nasa.gov> Date: Wed, 16 Sep 1998 08:09:18 -0400 From: John Ackermann N8UR In message <35FEC9D4.4B4891CA@tomcat.gsfc.nasa.gov>, "Dr Thomas A Clark (W3IWI) " writes: >My first answer is that I have NEVER seen a receiver that was >tracking satellites have an error more than one usec. If it >loses all satellites, then the pulse drifts off slowly, >depending on the internal xtal in the rcvr. This might give >rise to a 1 msec error after ~1 hour. Thanks! That's what I was looking for. >I presume you are asking in the context of your LINUX xntpd >effort. Let me offer a caveat: The "stock" GPS xntpd uses the >time in the $GPGGA message, but the GGA time is the time of >the LAST VALID POSITION FIX. Therefore in zero-D mode, or if >the receiver is unlocked and "coasting", the GGA HHMMSS field >is not updated at all. This is the reason I strongly recommend >that the xntpd code must be modified to handle the $GPZDA >message which has the CURRENT UTC time, regardless of the >zero-D or "coasting". I'm using a modified nmea driver that (a) uses the GPZDA sentence, and (b) uses the PPS signal for its time mark. It's available via my ntp web page at http://www.febo.com/ntp/ntp.html and seems to work pretty well. The problem I'm dealing with is figuring out what the "true" time is from the various data that xntpd gives me. The output of ntpq -p showing all the clocks indicates that the GPS clock is usually around 6ms slow, with the external stratum one servers clustered +/- 10ms or so from that. The output of ntptime shows various things, none of them well documented, but leads me to believe that the kernel timekeeping also has an estimated error that's typically in the range of 12-20ms. I'm trying to figure out why these values based on the PPS signal aren't closer to 0, or at least less than 1ms. It seems that if both the kernel timekeeping, and xntpd, are running from the same PPS signal, the difference between them should be very small indeed. Maybe I just haven't a clue how to interpret the results, but I've had difficulty getting much clarification from the ntp folks. Thanks again for the info. 73, John From Terje.Mathisen@hda.hydro.com Thu Sep 17 10:41:32 1998 Received: from vkhdib01.hda.hydro.com (vkhdib01.hda.hydro.com [136.164.216.55]) by tapr.org (8.8.5/8.8.5) with ESMTP id KAA00227 for ; Thu, 17 Sep 1998 10:41:27 -0500 (CDT) Received: from no115350d ([136.164.10.192]) by vkhdib01.hda.hydro.com (8.8.8/8.8.7) with SMTP id PAA84502 for ; Thu, 17 Sep 1998 15:43:59 +0200 Message-ID: <3601121F.1B13@hda.hydro.com> Date: Thu, 17 Sep 1998 15:43:59 +0200 From: Terje Mathisen Organization: Hydro X-Mailer: Mozilla 3.04 (WinNT; I) MIME-Version: 1.0 To: tacgps@tapr.org Subject: Re: [TACGPS:1837] Re: Worst Case timing performance of Oncore? References: <199809161209.IAA16021@meow.febo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Ackermann N8UR wrote: > I'm using a modified nmea driver that (a) uses the GPZDA sentence, and > (b) uses the PPS signal for its time mark. It's available via my ntp > web page at http://www.febo.com/ntp/ntp.html and seems to work pretty > well. After getting a few pointers from John, I have built an xntpd deamon using this driver, and it did work as soon as I figured out that my first serial port was named /dev/ttyS0 by linux. > The problem I'm dealing with is figuring out what the "true" time is from > the various data that xntpd gives me. The output of ntpq -p showing all > the clocks indicates that the GPS clock is usually around 6ms slow, with > the external stratum one servers clustered +/- 10ms or so from that. > The output of ntptime shows various things, none of them well documented, > but leads me to believe that the kernel timekeeping also has an estimated > error that's typically in the range of 12-20ms. > > I'm trying to figure out why these values based on the PPS signal aren't > closer to 0, or at least less than 1ms. It seems that if both the kernel > timekeeping, and xntpd, are running from the same PPS signal, the difference > between them should be very small indeed. I don't know if this is relevant or not, but I get similar results: On both unpatched 2.0.31 linux, i.e. without the PPS kit, and with 2.1.73, which I believe include the needed support (?), I get strange timing results: The $GPZDA timestamp is about 120ms off, which corresponds well with a (around) 60-character string at 4800 baud, but I never seem to get hooked up to the PPS signal: I have set the GPS_NMEA driver to minpoll 4 (i.e. every 16 seconds), and it goes into a sawtooth pattern: The offset (relative to a local TrueTime server, after adding those 120ms back in) drops steadily from 6-7 miliseconds to near zero, over a time of a few minutes, and then makes an abrupt jump back to around 7 ms. BTW. the reduction in offset always happens in steps of around 1.1ms! This sounds like I am not getting the PPS signal, and that the Oncore has some internal interaction between the GPZDA output and the PPS generation which cause it to make small time steps until the offset is too big, whereupon it is janked back. > Maybe I just haven't a clue how to interpret the results, but I've had > difficulty getting much clarification from the ntp folks. I'll try the build a kernel with the PPSkit tomorrow, and see what happens. Terje la8nw PS. The ntp4 source includes a refclock_oncore, written by the dane, Paul Henning Kemp of FreeBSD note. This version depends on hooking the PPS signal to a paralell port IRQ line however, which seems rather wasteful when the serial port already has a couple of interrupt-capable input pins. -- - Using self-discipline, see http://www.eiffel.com/discipline "almost all programming can be viewed as an exercise in caching" From jra@febo.com Thu Sep 17 11:02:15 1998 Received: from meow.febo.com (root@meow.febo.com [209.115.70.194]) by tapr.org (8.8.5/8.8.5) with ESMTP id LAA01463 for ; Thu, 17 Sep 1998 11:02:11 -0500 (CDT) Received: from meow.febo.com (jra@localhost [127.0.0.1]) by meow.febo.com (8.8.5/8.8.5) with ESMTP id HAA22970 for ; Thu, 17 Sep 1998 07:33:38 -0400 Message-Id: <199809171133.HAA22970@meow.febo.com> X-Mailer: exmh version 1.6.9 8/22/96 To: tacgps@tapr.org Subject: Re: [TACGPS:1836] Re: Worst Case timing performance of Oncore? In-reply-to: Your message of "Wed, 16 Sep 1998 21:42:33 CDT." <190@siosolutns.win.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Sep 1998 07:33:37 -0400 From: John Ackermann N8UR It's not compile and go, but http://www.febo.com/ntp/ntp.html has instructions and a pointer to a modified version of the nmea driver that supports the $GPZDA sentence as well as the PPS pulse on the DCD line. John N8UR jra@febo.com > Slightly (but not much) off-topic..... > > I have just recieved a CNSClock (very nice piece, BTW). Our > organization has an older RS/6000 running AIX v.3.2.5 (an older > but still supported release of AIX). I would like to set the RS/6000 > up as a xntpd server using the CNSClock under AIX, however we are > not strong on AIX/Unix skills. Can anyone point me to a source for a > "compile and go" xntpd module that includes Tom's recommended $GPZDA > mod _and_ will run under AIX v.3.2.5? > > RAE > > > ______________________________________________________________________ > Raymond A. Elseth Internet: relseth@siosolutns.win.net > SIO Solutions CIS UserID: 76137,2426 > Palatine, IL Voice: 847/705-9721 From reg@dwf.com Thu Sep 17 12:41:51 1998 Received: from clemens.dwf.com (clemens.dwf.com [204.134.2.1]) by tapr.org (8.8.5/8.8.5) with ESMTP id MAA07009 for ; Thu, 17 Sep 1998 12:41:47 -0500 (CDT) Received: (from reg@localhost) by clemens.dwf.com (8.8.5/8.8.5) id LAA28834 for tacgps@tapr.org; Thu, 17 Sep 1998 11:41:19 -0600 (MDT) Date: Thu, 17 Sep 1998 11:41:19 -0600 (MDT) From: Reg Clemens Message-Id: <199809171741.LAA28834@clemens.dwf.com> To: tacgps@tapr.org Subject: Re: Worst Case timing performance of Oncore? Just to add to the discussion, I have been playing with the drivers in NTP myself, and seem to have had better luck. I have been playing on an old SunOS machine and my Linux Box with similar results on both. After a period of time with my hacked (to use $GPZDA) NMEA driver, the NMEA/ATOM combination get to a point where ntpdc reports an offset of less than 100us, usually in the 10-20us range. I have not been comparing these to an outside source, as Im at the end of a slow line here, although I surly should be able to see the sorts of offsets being reported if I give it a shot (this weekend?). However, the long time to `pull in' and the ugly changes that I had to make to the ntpv3 sources caused me to look at the ntpv4 sources. They are MUCH cleaner, and support the idea that you are going to send ascii and PPS to one port without any serious changes. I found that the NMEA/ATOM combination works there (ntpv4) about as well as it does on ntpv3, but that the ONCORE driver, which is really an alpha release works MUCH better. Rather than having the NMEA driver pull the clock in some distance towards lock then pass the effort over to the ATOM driver, it does the whole job. Off the top of my head, I would say that it pulls in from a several sec offset to 10us in mabe 1/2 hour, probably less. All of my efforts in the last week have been towards cleaning this thing up and getting it to work reliably. Incidently, I have the ONCORE driver set up as was noted in a note earlier this week to use the T-RAIM stuff (anyone know what RAIM stands for?) and in addition to the additional accuracy this should provide, it does cause the PPS to stop if you pull the antenna cable... Ill get the changes I am using together and put them out where others can get to them this weekend, but from my end there are is still one large open question. Could be part of what John is seeing. The above experiments were done on SunOS where there is no Kernel PLL, and on Linux (2.0.35) with the kernel PLL turned OFF. If I turn the KERNEL PLL stuff ON in Linux, then instead of 10us mean, 100us max, for the offset from the PPS source, I see it pull into 10us, then drift back out to 5-8ms where it stays forever. I need to put some debug prints in both ntpd and the kernel to try to see what is wrong when the PLL is engaged, since it should give better not worse results than when it is off. Could be an error in ntp or the kernel (since I see two flags on at once that I am told should never be active at the same time), or Im told, it could be an inherent scheduling problem in the 2.0.x linux kernels (Im going to try 2.1.119 the next day or two, and see what happens (but have to move the PPS stuff there first). More if anyone is interested. Reg.Clemens reg@dwf.com From k4jpj@appstate.campus.mci.net Thu Sep 17 13:39:42 1998 Received: from aus-a.mp.campus.mci.net (aus-a.mp.campus.mci.net [208.140.84.21]) by tapr.org (8.8.5/8.8.5) with ESMTP id NAA10258 for ; Thu, 17 Sep 1998 13:39:38 -0500 (CDT) Received: from donaldha (s23-pm15.snaustel.campus.mci.net [207.49.121.220]) by aus-a.mp.campus.mci.net (8.9.0/8.8.8) with SMTP id OAA26507 for ; Thu, 17 Sep 1998 14:37:59 -0400 (EDT) Message-Id: <3.0.5.32.19980917143653.0083f980@appstate.campus.mci.net> X-Sender: k4jpj@appstate.campus.mci.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 17 Sep 1998 14:36:53 -0400 To: tacgps@tapr.org From: "Donald E. Haselwood" Subject: Oncore UT+, 100 pps output In-Reply-To: <35FEC9D4.4B4891CA@tomcat.gsfc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I noticed that the Oncore UT+ has a 1 pps/100 pps feature (tech note 490-1, www.synergy-gps.com). It seems that 100 pps output would be useful for xtal/rube steering, as it would increase the GPS-versus-osc measurement rate by a factor of 100. (The timing accuracy on the 1 pps is listed as the same as the VP Oncore.) If the GPS pps output jitter is 30 ns rms, and the measurement has a resolution of say, 100 ns, the total rms would be about 104 ns [sqrt((30^2 + 100^2)/N)]. For one second and 1 pps, N is one, but for 100 pps, N is 100, so the total rms jitter is reduced by a factor of 10. For steering purposes should we be looking at the UT+? 73's Don, W4DH From tvb@veritas.com Thu Sep 17 17:58:31 1998 Received: from athena.veritas.com (athena.veritas.com [192.203.46.191]) by tapr.org (8.8.5/8.8.5) with ESMTP id RAA23110 for ; Thu, 17 Sep 1998 17:58:27 -0500 (CDT) Received: from megami.veritas.com (megami.veritas.com [192.203.46.101]) by athena.veritas.com (8.9.1a/8.9.1) with SMTP id PAA22144; Thu, 17 Sep 1998 15:58:23 -0700 (PDT) Received: from v-tomvb6 by megami.veritas.com with smtp (Smail3.1.29.0 #7) id m0zJn0H-0000BQC; Thu, 17 Sep 98 15:58 PDT Message-ID: <36019378.913@veritas.com> Date: Thu, 17 Sep 1998 15:55:52 -0700 From: Tom Van Baak Reply-To: tvb@veritas.com Organization: VERITAS Software X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: tacgps@tapr.org CC: "Donald E. Haselwood" Subject: Re: [TACGPS:1841] Oncore UT+, 100 pps output References: <3.0.5.32.19980917143653.0083f980@appstate.campus.mci.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Donald E. Haselwood wrote: > > I noticed that the Oncore UT+ has a 1 pps/100 pps feature (tech note 490-1, > www.synergy-gps.com). It seems that 100 pps output would be useful for > xtal/rube steering, as it would increase the GPS-versus-osc measurement > rate by a factor of 100. (The timing accuracy on the 1 pps is listed as > the same as the VP Oncore.) Yes, it seems tempting, but I think the GPS sample rate is not really the limiting factor. I would guess a steering device (such as a TOC) averages the 1 (or 100) PPS GPS output for three different and independent reasons. 1) The time interval circuit in Brooks' circuit (or Tom's TOC) has finite resolution. A 10 MHz sample clock gives you 100 ns of resolution, a 24 MHz clock gives you 40 ns of resolution, etc. Assuming the sample clock and the pulse being measured aren't phase locked, averaging N samples gives you sqrt(N) better resolution. 2) The Oncore needs to create a 1 (or 100) PPS pulse "on time". Internally it knows when this pulse should occur to within 1 ns. But the pulse is derived from the on-board VCO clock which runs slightly under 10 MHz. Thus, regardless of when the Oncore would like to create the 1 PPS pulse, the actual pulse will be delivered within a +/- 52 ns band of the desired value. If one averages for 10s to 100s of seconds the effect of this 104 ns band is reduced. 3) The final effect is SA and other GPS noise. This results in a 100 to 200 ns wander of the 1 PPS output from the true UTC value. So even if one eliminated the jitter errors above and had a 1 PPS (or 100 PPS) accurate to 1 ns, the pulses would still be subject to SA and wander by at least 100 ns over the duration of an hour. If one averages the 1 PPS output for several hours the effect of SA is reduced. > If the GPS pps output jitter is 30 ns rms, and the measurement has a > resolution of say, 100 ns, the total rms would be about 104 ns [sqrt((30^2 > + 100^2)/N)]. For one second and 1 pps, N is one, but for 100 pps, N is > 100, so the total rms jitter is reduced by a factor of 10. > > For steering purposes should we be looking at the UT+? > > 73's > Don, W4DH It seems to me except for the first few hours, the amount of steering to a good xtal or Rb is so minimal that having to average the N PPS signal for 10s or 100s of minutes is not really a problem. Factor #3 dominates over the effects of factors #1 and #2. Tom or Brooks, is this your understanding/experience also? Does anyone have the UT+ or know if the 100 PPS output has the same +/- 52 ns jitter as the UT? Thanks, /tvb From clark@tomcat.gsfc.nasa.gov Thu Sep 17 20:38:26 1998 Received: from tomcat.gsfc.nasa.gov (tomcat.gsfc.nasa.gov [128.183.88.42]) by tapr.org (8.8.5/8.8.5) with SMTP id UAA00255 for ; Thu, 17 Sep 1998 20:38:26 -0500 (CDT) Date: Thu, 17 Sep 98 19:45:56 UTC Message-Id: <71459@tomcat.gsfc.nasa.gov> From: clark@tomcat.gsfc.nasa.gov (Tom Clark -- W3IWI) Reply-To: clark@tomcat.gsfc.nasa.gov To: tacgps@tapr.org Subject: Re: [TACGPS:1840] Re: Worst Case timing performance of Oncore? RAIM = Redundant Autonomous Integrity Monitor Tom From ufujioka@mb.infoweb.ne.jp Fri Sep 18 11:33:36 1998 Received: from mf004.infoweb.ne.jp (mf004.infoweb.ne.jp [210.131.99.14]) by tapr.org (8.8.5/8.8.5) with ESMTP id LAA09501 for ; Fri, 18 Sep 1998 11:33:33 -0500 (CDT) Received: from mb.infoweb.ne.jp by mf004.infoweb.ne.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-09/12/97) id BAA02638; Sat, 19 Sep 1998 01:33:19 +0900 Message-ID: <36028B14.EFA6AF43@mb.infoweb.ne.jp> Date: Sat, 19 Sep 1998 01:32:20 +0900 From: Utaro Fujioka X-Mailer: Mozilla 4.05 [ja] (Win95; I) MIME-Version: 1.0 To: tacgps@tapr.org Subject: Does GPS25 have raw measurement output? References: <199805100518.BAA25773@orbitor.ica.net> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Does GPS 25 (from TAPR) have raw measurement output? GARMIN GPS 25 LP series seems to have raw measurement output. UTARO From davem@cs.ubc.ca Fri Sep 18 12:02:44 1998 Received: from pedigree.cs.ubc.ca (root@pedigree.cs.ubc.ca [142.103.6.50]) by tapr.org (8.8.5/8.8.5) with ESMTP id MAA10182 for ; Fri, 18 Sep 1998 12:02:43 -0500 (CDT) Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id KAA13744 for ; Fri, 18 Sep 1998 10:02:38 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <36028B14.EFA6AF43@mb.infoweb.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Sep 1998 10:02:38 -0700 To: tacgps@tapr.org From: Dave Martindale Subject: Re: [TACGPS:1844] Does GPS25 have raw measurement output? >Does GPS 25 (from TAPR) have raw measurement output? >GARMIN GPS 25 LP series seems to have raw measurement output. >From discussions with Garmin, I believe that all GPS 25 models have always had the capability to output raw data on their second serial port, while continuing to output NMEA on the main serial port. Older GPS 25s did not have this turned on by default; you had to run a piece of DOS code supplied by Garmin to download some extra stuff into the unit to enable raw data out. From then on, it was permanently turned on. The GPS 35 and 36, which are just a 25 in a housing, couldn't be used for this because they didn't bring out wires connected to the second serial port. But newer GPS 25's all have the raw output firmware installed, and the raw data can be turned on and off at will be sending the unit a particular NMEA configuration command on the main serial port. You can also change the NMEA update rate on these units. >From looking at Garmin's web site, they now say that the GPS 35 support raw output as well, so I assume that new 35s also have the extra wires needed to access the second serial output. On top of all this, I get the impression that the GPS 25 LP is in fact the only "GPS 25" currently in production, so if you buy one from TAPR now it will probably be a 25 LP anyway. There are still multiple versions of the 25 LP, depending on whether they have a switching regulator on board and whether the inputs and outputs are CMOS or RS-232 levels, but they all have the same firmware. Dave From reg@dwf.com Sun Sep 20 15:46:43 1998 Received: from clemens.dwf.com (clemens.dwf.com [204.134.2.1]) by tapr.org (8.8.5/8.8.5) with ESMTP id PAA01564 for ; Sun, 20 Sep 1998 15:46:40 -0500 (CDT) Received: (from reg@localhost) by clemens.dwf.com (8.8.5/8.8.5) id OAA29585 for tacgps@tapr.org; Sun, 20 Sep 1998 14:46:37 -0600 (MDT) Date: Sun, 20 Sep 1998 14:46:37 -0600 (MDT) From: Reg Clemens Message-Id: <199809202046.OAA29585@clemens.dwf.com> To: tacgps@tapr.org Subject: Re: Worst Case timing performance of Oncore? In-Reply-To: Mail from 'John Ackermann N8UR ' dated: Wed, 16 Sep 1998 21:43:41 -0500 (CDT) On Sep 16 21:38 jra@febo.com said > In message <199809161209.IAA16021@meow.febo.com>, John Ackermann N8UR writes: > > The problem I'm dealing with is figuring out what the "true" time is from > the various data that xntpd gives me. The output of ntpq -p showing all > the clocks indicates that the GPS clock is usually around 6ms slow, with > the external stratum one servers clustered +/- 10ms or so from that. > The output of ntptime shows various things, none of them well documented, > but leads me to believe that the kernel timekeeping also has an estimated > error that's typically in the range of 12-20ms. > > I'm trying to figure out why these values based on the PPS signal aren't > closer to 0, or at least less than 1ms. It seems that if both the kernel > timekeeping, and xntpd, are running from the same PPS signal, the difference > between them should be very small indeed. > and In message <3601121F.1B13@hda.hydro.com>, Terje Mathisen writes > On both unpatched 2.0.31 linux, i.e. without the PPS kit, and with > 2.1.73, which I believe include the needed support (?), I get strange > timing results: > > The $GPZDA timestamp is about 120ms off, which corresponds well with a > (around) 60-character string at 4800 baud, but I never seem to get > hooked up to the PPS signal: > > I have set the GPS_NMEA driver to minpoll 4 (i.e. every 16 seconds), and > it goes into a sawtooth pattern: The offset (relative to a local > TrueTime server, after adding those 120ms back in) drops steadily from > 6-7 miliseconds to near zero, over a time of a few minutes, and then > makes an abrupt jump back to around 7 ms. BTW. the reduction in offset > always happens in steps of around 1.1ms! > These two messages got me worrying about just what my offsets were,- since Im doing this at home Im at the end of a 28.8 line, and I hadnt tried any experiments connecting out the the `real' world, but heres what I saw Sunday Afternoon After 5min ntpdc> dmpeers remote local st poll reach delay offset disp ======================================================================= LOCAL(0) 0.0.0.0 8 64 17 0.00000 0.000000 16.0000 clock.llnl.gov 204.134.2.1 1 64 17 0.19147 -0.017913 0.93822 mustang.plk.af. 204.134.2.1 2 64 17 0.26848 -0.031604 0.93817 GPS_ONCORE(0) 0.0.0.0 0 64 7 0.00000 -0.004757 1.93800 After 15min ntpdc> dmpeers remote local st poll reach delay offset disp ======================================================================= LOCAL(0) 0.0.0.0 8 64 377 0.00000 0.000000 16.0000 .clock.llnl.gov 204.134.2.1 1 64 377 0.18581 -0.007382 0.00307 .mustang.plk.af. 204.134.2.1 2 64 377 0.26625 -0.024799 0.00447 *GPS_ONCORE(0) 0.0.0.0 0 64 376 0.00000 -0.000146 0.00098 after 1hr ntpdc> dmpeers remote local st poll reach delay offset disp ======================================================================= LOCAL(0) 0.0.0.0 8 64 377 0.00000 0.000000 16.0000 .clock.llnl.gov 204.134.2.1 1 64 377 0.18460 -0.010478 0.00105 .mustang.plk.af. 204.134.2.1 2 64 377 0.26488 -0.022540 0.00096 *GPS_ONCORE(0) 0.0.0.0 0 64 377 0.00000 0.000096 0.00095 So my greatest fear, that I would end up having the ms or us right, but have the second wrong is not founded. After an hour (this is on SunOS, my linux box is w/o its ethernet adaptor for a week) the offset from the PPS signal is on the order of 100us, and I appear to have offsets of the oposite sign of 10-20ms to the two external sources (but with the delays being in the 200ms range, and both being 10-15 hops away, I guess Im not suprised). At the moment my Linux box (Kernel PLL off) is showing 40-200us offsets depending on when I look at it. Terje Said: > I'll try the build a kernel with the PPSkit tomorrow, and see what > happens. Be sure to blow away the config file that NTP built and reconfigure or it wont notice that that you have installed the PPSKit routines (Im not sure if just reconfiguring will notice,- blowing away the old file will definately have it looking again. AND Ive found its worth the effort to always LOOK at config.h after its been built and check all the things with PLL or PPS in their name and see that they appear to be set correctly,- on my system they definately werent and I had to set things by hand... I want to try a 2.1.x Linux kernel with this stuff, but it looks like most (all) of the PPS stuff is still missing over there, so it would take longer than I have this weekend to integrate the changes. John said: > Maybe I just haven't a clue how to interpret the results, but I've had > difficulty getting much clarification from the ntp folks. Amen. Ive got some good suggestions from email to Mills and Ulrich.Windl (who wrote PPSKit and seems to have integrated the PPS stuff and some of the PLL stuff into the Linux Kernel), but it always seems to take putting in my OWN debug statements, since whats there is not documented well enough for someone other than the writer of the code to understand. Reg.Clemens reg@dwf.com From shelden3@ionet.net Sun Sep 20 17:53:46 1998 Received: from mail.ionet.net (mail.ionet.net [206.41.128.16]) by tapr.org (8.8.5/8.8.5) with ESMTP id RAA06470 for ; Sun, 20 Sep 1998 17:53:45 -0500 (CDT) From: shelden3@ionet.net Received: from charlie (okcnasa-34.ionet.net [38.193.49.240]) by mail.ionet.net (8.9.1a/8.9.1) with SMTP id RAA11021 for ; Sun, 20 Sep 1998 17:55:26 -0500 (CDT) Date: Sun, 20 Sep 1998 17:55:26 -0500 (CDT) Message-Id: <199809202255.RAA11021@mail.ionet.net> X-Sender: shelden3@ionet.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: tacgps@tapr.org Subject: gps ant. I just recently purchased a Motorola Oncore VP. Does anyone know of any webpages that have some plans for building GPS antenna's? Also does anyone know if the oncore will work with a passive antenna? I built a "patch" antenna but I can't see any birds, even after leaving the program running for 1 hour or more. Thanks in advance for any information anyone may have. Charlie, KC5NBH http://borg.rass.org By the way the GPS will be used with APRS on a upcoming balloon launch. From kc5ejk@onramp.net Sun Sep 20 23:49:35 1998 Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by tapr.org (8.8.5/8.8.5) with ESMTP id XAA05593 for ; Sun, 20 Sep 1998 23:49:34 -0500 (CDT) Received: from [206.50.200.243] (ppp13-51.dllstx.onramp.net [206.50.200.243]) by mailhost.onramp.net (8.8.7/8.8.7) with ESMTP id XAA10812; Sun, 20 Sep 1998 23:49:29 -0500 (CDT) X-Sender: kc5ejk@mailhost.onramp.net Message-Id: In-Reply-To: <199809202255.RAA11021@mail.ionet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Sep 1998 23:50:56 -0600 To: tacgps@tapr.org From: Robert Winingham Subject: Re: [TACGPS:1847] gps ant. Cc: shelden3@ionet.net > I just recently purchased a Motorola Oncore VP. Does anyone know of >any webpages that have some plans for building GPS antenna's? Also does >anyone know if the oncore will work with a passive antenna? > >I built a "patch" antenna but I can't see any birds, even after leaving the >program running for 1 hour or more. > >Thanks in advance for any information anyone may have. > > Charlie, KC5NBH > http://borg.rass.org > >By the way the GPS will be used with APRS on a upcoming balloon launch. Try running TAC32 software to see what you can see as the Motorola Oncore OPTICAL port sometimes does not work. :-) Best to set up the unit with a know good working Ant. I used the Ant. from my Garmin-45, which is a passive Ant, for my first test. Fry's , West Marine and TAPR have low cost Active ants and are worth the price. TAC32 and SAwatch will help you when testing different ant designs. As you have APRS get the SIGPLOT.BAS program (part of DOS APRS) to plot the antenna performance. - The North Texas Balloon group has tried Tripmates and a Garmin-45. I wish they would use a Motorola Oncore VP. ---- 73 Bob - Dallas,TX --- kc5ejk@onramp.net or kc5ejk@amsat.org --- From wd5ivd@tapr.org Tue Sep 22 17:41:59 1998 Received: from [128.83.74.103] (edb536j-2.edb.utexas.edu [128.83.74.103]) by tapr.org (8.8.5/8.8.5) with ESMTP id RAA01721; Tue, 22 Sep 1998 17:41:55 -0500 (CDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Date: Tue, 22 Sep 1998 17:41:08 -0500 To: "TAPR-BB list mailing" From: "Greg Jones, WD5IVD" Subject: 1998 ARRL and TAPR DCC this coming weekend ! Cc: "HF SIG list mailing", " Spread Spectrum ", " TAPR/AMSAT DSP ", "APRS SIG list mailing", "NETSIG list mailing", "BBS SIG list mailing", " tacgps ", aprsnews, mic-e, TAPR Regional Freq Just as a reminder the 1998 ARRL and TAPR Digital Communications Conference in Chicago, IL is happening this weekend! The conference schedule and information is on-line at http://www.tapr.org/dcc The abstract page should be on-line shortly. Hope to see you in Chicago this weekend! Cheers - Greg Jones, WD5IVD ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd From cheisler@cyberia.com Thu Sep 24 20:06:02 1998 Received: from cyberia.com (cyberia.com [205.160.224.234]) by tapr.org (8.8.5/8.8.5) with ESMTP id UAA15124 for ; Thu, 24 Sep 1998 20:05:56 -0500 (CDT) Received: from cheisler ([208.13.144.58]) by cyberia.com with SMTP (IPAD 2.06) id 6375200 ; Thu, 24 Sep 1998 21:28:04 EDT X-Sender: cheisler@cyberia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 24 Sep 1998 21:00:44 -0400 To: tacgps@tapr.org From: "Charles E. Heisler" Subject: SA Watch/Nova Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <199809250228.6375200@cyberia.com> Has any body else compared the GPS Sat. locations that SA Watch reports with where Nova calculates them to be? They don't agree for me by a bunch. (bunch= hi tech word meaning too much.) And yes, the computer time is correct and the Keps. are up to date etc. Charlie K3VDB From Terje.Mathisen@hda.hydro.com Fri Sep 25 01:57:32 1998 Received: from vkhdib01.hda.hydro.com (vkhdib01.hda.hydro.com [136.164.216.55]) by tapr.org (8.8.5/8.8.5) with ESMTP id BAA08163 for ; Fri, 25 Sep 1998 01:57:26 -0500 (CDT) Received: from no115350d ([136.164.10.192]) by vkhdib01.hda.hydro.com (8.8.8/8.8.7) with SMTP id IAA144998; Fri, 25 Sep 1998 08:57:10 +0200 Message-ID: <360B3EC6.1FF2@hda.hydro.com> Date: Fri, 25 Sep 1998 08:57:10 +0200 From: Terje Mathisen Organization: Hydro X-Mailer: Mozilla 3.04 (WinNT; I) MIME-Version: 1.0 To: Robert Dal Santo CC: tacgps@tapr.org Subject: Re: Oncore, PPS, Time etc References: <3.0.5.32.19980925114800.00797470@psy.uq.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Dal Santo wrote: > > Hi, Saw your posting about the accuracy of the PPS on Oncores versus > others. I am looking at building a GPS clock board to link to a FreeBSD box > vix PPS on the DCD line and either NMEA or Motoroloa's "binary" prorotcol. > > I'd be very interested in how you go when you get the Oncore connected. I got everything working at the office yesterday (after lots of help from Ulrich Windl and Reg Clemens), and did some 'ntpq -p ' checks from home. I have had to leave the antenna indoors, facing northwest into a cliff-face, so it is _very_ suboptimal, but I still get up to 7 connected sats at some times. :-) Normally it is more like 1-4, so the Oncore looses lock once or twice every hour or so. When properly connected, I've seen very good timing performance, running Linux 2.0.35 using Ulrich Windl's PPSkit-0.3.7.tar.gz. I have the PPS signal attached to the Carrier Detect line on the serial port of a very old Dell 486-66 machine (i.e. no RDTSC-based ultra-high resolution timestamps), but this is still good enough that I've seen the offset settle down below 20 microsecs, with dispersion near zero. > have you considered other GPS receivers like the Garmin GPS-25? Yeah, I just decided that if I was going to solder up a kit, I'd like to know that I had the best possible reference source, short of a private UTC atomic clock. :-) For a 'production' setup, I'd probably use either the ready-made CNS clock, or one of the special timing receivers, which has the GPS engine embedded in the antenna enclosure, and with just a serial connection to the PC. > Hopefully I'll be trying NTP with driver 20 (generic NMEA) or driver 30 > (Poul-Henning Kamp's ONCORE driver) in the next month or so :) I tried the GPZDA-modified NMEA driver first, but now I'm using phk's very nice Oncore, which uses Motorola binary protocol. It seems like phk have done a very good job on FreeBSD timing, using his OS and Oncore driver should get you as close as possible to UTC on a very limited budget. :-) Terje -- - Using self-discipline, see http://www.eiffel.com/discipline "almost all programming can be viewed as an exercise in caching" From pat.kilroy@gsfc.nasa.gov Fri Sep 25 09:21:24 1998 Received: from popd.gsfc.nasa.gov (popd-f.gsfc.nasa.gov [128.183.251.102]) by tapr.org (8.8.5/8.8.5) with ESMTP id JAA28277 for ; Fri, 25 Sep 1998 09:21:23 -0500 (CDT) Received: from PKILROY.GSFC.NASA.GOV (pkilroy.gsfc.nasa.gov [128.183.144.225]) by popd.gsfc.nasa.gov (8.8.8/8.6.12) with SMTP id KAA11024 for ; Fri, 25 Sep 1998 10:21:21 -0400 (EDT) Message-Id: <3.0.5.32.19980925102120.00854100@pop700.gsfc.nasa.gov> X-Sender: plkilroy@pop700.gsfc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 25 Sep 1998 10:21:20 -0400 To: tacgps@tapr.org From: Pat Kilroy Subject: Re: TACGPS digest 329 > Rcvr Vs. Nova In-Reply-To: <199809250111.UAA15219@tapr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:11 PM 9/24/98 -0500, tacgps@tapr.org wrote: > TACGPS Digest 329 >From: "Charles E. Heisler" >Subject: SA Watch/Nova > > Has any body else compared the GPS Sat. locations that > SA Watch reports with where Nova calculates them to be? They don't > agree for me by a bunch. (bunch= hi tech word meaning too much.) And > yes, the computer time is correct and the Keps. are up to date etc. Hi Charlie, For a referee, I'd use the GPS receiver itself to say where the satellites are. That is, if you are using a receiver with an LCD. But then again, doesn't SAWatch use the *receiver* data to provide the position info? You make the call. Pat WD8LAQ Greenbelt From prossen@znet.com Sat Sep 26 11:46:46 1998 Received: from sd.znet.com (sd.znet.com [207.167.64.5]) by tapr.org (8.8.5/8.8.5) with ESMTP id LAA13348 for ; Sat, 26 Sep 1998 11:46:45 -0500 (CDT) Received: from pete-s-486 (sdts1-50.znet.net [207.167.64.50]) by sd.znet.com (8.9.1/8.9.1/jjb-sd) with ESMTP id JAA14994 for ; Sat, 26 Sep 1998 09:46:41 -0700 (PDT) Message-Id: <199809261646.JAA14994@sd.znet.com> From: "Pete Prossen" To: "Tapr GPS list server" Subject: DGPS Experimental License Date: Sat, 26 Sep 1998 09:11:49 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Last month, the FCC (Office of Engineering and Technology Experimental Branch) granted an experimental license to Lockheed Martin Corp for the creation of a local differential GPS system. The experimental call sign, WA2XTC, allocates two repeater pairs (464.5 & 469.5 and 464.55 & 469.55) for mobil use in the continental US. Since DGPS is a burning interest of mine, I would like to know more about this application. Anyone out there know? Regards Pete Prossen WA6ZUH From tac@clark.net Sat Sep 26 15:46:19 1998 Received: from postal.clark.net (postal.clark.net [168.143.0.17]) by tapr.org (8.8.5/8.8.5) with ESMTP id PAA22043 for ; Sat, 26 Sep 1998 15:44:08 -0500 (CDT) Received: from loas.clark.net (loas.clark.net [168.143.0.13]) by postal.clark.net (8.9.1/8.9.1) with ESMTP id QAA03962 for ; Sat, 26 Sep 1998 16:43:42 -0400 (EDT) Received: from clark.net (tac.clark.net [168.143.32.123]) by loas.clark.net (8.8.8/8.8.8) with ESMTP id QAA13509 for ; Sat, 26 Sep 1998 16:44:11 -0400 (EDT) Message-ID: <360D51D8.FB72CB02@clark.net> Date: Sat, 26 Sep 1998 20:43:04 +0000 From: "Dr Thomas A Clark (W3IWI)" Reply-To: tac@clark.net X-Mailer: Mozilla 4.5b2 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: tacgps@tapr.org Subject: Re: [TACGPS:1850] SA Watch/Nova References: <199809250228.6375200@cyberia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charlie, K3VDB wrote: > > Has any body else compared the GPS Sat. locations that > SA Watch reports with where Nova calculates them to be? They don't > agree for me by a bunch. (bunch= hi tech word meaning too much.) And > yes, the computer time is correct and the Keps. are up to date etc. SA Watch, TAC32, Showtime etc all pick up their az/el data from the GPS rcvr's RS232 output data. None of them have any orbital computations built in. Your GPS receiver computes the az/el from the latest almanac data it has (typically only a few hours old). If it made the geometric calculations wrong, it would not work as a GPS rcvr! So trust it to be correct. Perhaps the problem is in the mapping of international GPS satellite ID (like GPS35) assigned at the time of launch into the PRN code it is transmitting (like PRN03) that is the ID by which your GPS rcvr (and hence SA Watch etc knows it)? Tom