Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.physics > #634501 > unrolled thread
| Started by | Ckeho Baùkora <unukn@owyqar.og> |
|---|---|
| First post | 2017-05-27 10:37 +0000 |
| Last post | 2017-06-09 13:35 -0700 |
| Articles | 20 on this page of 115 — 26 participants |
Back to article view | Back to sci.physics
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: GPS Again. Ckeho Baùkora <unukn@owyqar.og> - 2017-05-27 10:37 +0000
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-05-30 09:57 -0500
Re: GPS Again. Helmut Wabnig <hwabnig@.- --- -.dotat> - 2017-05-30 20:52 +0200
Re: GPS Again. Ernest Rivers <erwm@weicnne.ac> - 2017-05-30 19:17 +0000
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-05-30 15:23 -0500
Re: GPS Again. Helmut Wabnig <hwabnig@.- --- -.dotat> - 2017-05-30 22:53 +0200
Re: GPS Again. Ernest Schwanenflügel <erwm@wanenf.oa> - 2017-05-30 20:59 +0000
Re: GPS Again. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-31 00:42 +0200
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-05-30 19:03 -0500
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-05-30 21:30 -0500
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-05-30 19:01 -0500
Re: GPS Again. Ernest Rivers <erwm@weicnne.ac> - 2017-05-30 19:15 +0000
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-09 11:37 +1000
Re: GPS Again. Jim Limey <eeug@dnne.ri> - 2017-06-09 14:32 +0000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-09 12:51 -0500
Re: GPS Again. Kitubu Nkyaku <akntuu@buwkau.kk> - 2017-06-09 18:52 +0000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-10 09:23 +1000
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-10 11:23 +1000
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-10 11:21 +1000
Re: GPS Again. Kitubu Nkyaku <akntuu@buwkau.kk> - 2017-06-10 10:42 +0000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-10 19:38 -0500
Re: GPS Again. Nými Icelulózy <ejienm@wzsfwe.ul> - 2017-06-16 11:30 +0000
Re: GPS Again. Sегgi о <iinvalid@invalid.com> - 2017-06-16 10:40 -0500
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-11 11:11 +1000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-10 21:20 -0500
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-11 12:31 +1000
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-06-10 22:40 -0500
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-10 23:20 -0500
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-11 05:14 +1000
Re: GPS Again. "Paul B. Andersen" <relativity@paulba.no> - 2017-06-10 22:16 +0200
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-11 07:19 +1000
Re: GPS Again. "Paul B. Andersen" <relativity@paulba.no> - 2017-06-11 22:35 +0200
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-11 15:44 -0500
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-11 18:03 -0500
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-11 19:00 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-12 11:39 +1000
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-06-12 02:33 +0000
Re: GPS Again. "hanson" <hanson@quick.net> - 2017-06-12 10:15 -0700
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-12 13:40 -0500
Re: GPS Again. "hanson" <hanson@quick.net> - 2017-06-12 14:19 -0700
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-06-11 22:42 -0500
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-11 23:27 -0500
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-12 04:47 +0000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-12 08:20 -0500
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-12 17:18 +0000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-12 18:15 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-12 22:32 +0000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-12 20:48 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-13 01:52 +0000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-13 19:57 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-14 00:46 +0000
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-06-12 09:58 -0500
Re: GPS Again. Selina Dieter <uiueeits@wlwtwstd.ci> - 2017-06-12 15:08 +0000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-12 10:37 -0500
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-12 17:21 +0000
Re: GPS Again. Selina Dieter <uiueeits@wlwtwstd.ci> - 2017-06-12 17:40 +0000
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-12 18:05 +0000
Re: GPS Again. Selina Dieter <uiueeits@wlwtwstd.ci> - 2017-06-12 18:19 +0000
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-12 19:16 +0000
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-06-12 19:43 +0000
Re: GPS Again. pcardinale@volcanomail.com - 2017-06-12 12:22 -0700
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-12 20:01 +0000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-12 18:32 -0500
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-13 01:54 +0000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-12 22:28 -0500
Re: GPS Again. benj <benj@nobody.net> - 2017-06-13 19:59 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-14 00:48 +0000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-13 21:35 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-14 02:11 +0000
Re: GPS Again. Mahipal <mahipal7638@gmail.com> - 2017-06-13 19:50 -0700
Re: GPS Again. benj <benj@nobody.net> - 2017-06-13 23:53 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-14 05:27 +0000
Re: GPS Again. Sегg iо <invalid@invalid.com> - 2017-06-14 09:10 -0500
Re: GPS Again. benj <benj@nobody.net> - 2017-06-14 17:10 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-14 21:33 +0000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-14 18:19 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-14 22:33 +0000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-15 17:01 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-15 23:09 +0000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-13 23:49 -0400
Re: GPS Again. jimp@specsol.spam.sux.com - 2017-06-14 05:29 +0000
Re: GPS Again. Sегg iо <invalid@invalid.com> - 2017-06-13 20:29 -0500
Re: GPS Again. pcardinale@volcanomail.com - 2017-06-13 12:33 -0700
Re: GPS Again. Серг ио <invalid@invalid.com> - 2017-06-13 16:39 -0500
Re: GPS Again. benj <benj@nobody.net> - 2017-06-12 18:25 -0400
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-12 18:45 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-12 10:35 +1000
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-12 11:05 +1000
Re: GPS Again. Serg io <invalid@invalid.com> - 2017-06-11 23:29 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-12 20:12 +1000
Re: GPS Again. Poutnik <poutnik4nntp@gmail.com> - 2017-06-12 13:54 +0200
Re: GPS Again. Selina Dieter <uiueeits@wlwtwstd.ci> - 2017-06-12 12:47 +0000
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-13 04:13 +1000
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-13 12:59 +1000
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-13 04:22 +1000
Re: GPS Again. Sylvia Else <sylvia@not.at.this.address> - 2017-06-13 13:00 +1000
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-06-13 13:32 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-14 10:09 +1000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-14 09:34 +1000
Re: GPS Again. Серг ио <invalid@invalid.com> - 2017-06-13 18:42 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-14 12:40 +1000
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-06-14 04:06 +0000
Re: GPS Again. "hanson" <hanson@quick.net> - 2017-06-13 23:01 -0700
Re: GPS Again. Sегg iо <invalid@invalid.com> - 2017-06-13 23:19 -0500
Re: GPS Again. Sегg iо <invalid@invalid.com> - 2017-06-13 23:46 -0500
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-14 20:07 +1000
Re: GPS Again. Sегg iо <invalid@invalid.com> - 2017-06-14 09:17 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-17 08:26 +1000
Re: GPS Again. benj <benj@nobody.net> - 2017-06-16 20:40 -0400
Re: GPS Again. Ecembre Abin <umueuu@eibbwaw.ee> - 2017-06-17 08:05 +0000
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-17 22:20 +1000
Re: GPS Again. Sегgi о <iinvalid@invalid.com> - 2017-06-17 07:58 -0500
Re: GPS Again. benj <benj@nobody.net> - 2017-06-14 17:06 -0400
Re: GPS Again. "HGW..." <hgw@....> - 2017-05-31 09:58 +1000
Re: GPS Again. pcardinale@volcanomail.com - 2017-06-09 13:35 -0700
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Ckeho Baùkora <unukn@owyqar.og> |
|---|---|
| Date | 2017-05-27 10:37 +0000 |
| Subject | Re: GPS Again. |
| Message-ID | <ogbkt4$1sge$1@gioia.aioe.org> |
Tom Roberts wrote: > The GPS receiver's position calculation is based on the OBSERVATION that > the vacuum speed of light is isotropically c relative to the ECI > coordinates. The entire path is not in vacuum, so there are corrections > for ionospheric and atmospheric effects. This tangents to bullshits, mister Tom. The receivers are working only, and only, on the DATA received from the satellites. NOT on the speeds of the signals carrying IT. You do same UNFORGIVABLE mistake Dr. HGW does. > There are no "alternatives" -- EVERY receiver computes position in the > ECI, based on the OBSERVATION that the vacuum speed of light is > isotropically c in the ECI. The ECI position is then transformed to the > rotating-earth coordinates for reporting to the user. (Here "position" > includes GPS time.) That's not what is done in Receivers. You never had your fingers in the algorithm, actually performing those triangulations. There are no SPEED detectors embedded in GPS receivers. I must insist. All the algorithms are running on the received decrypted DATA, not on the signals. Huge difference. You guys are having it so wrong for so long time.
[toc] | [next] | [standalone]
| From | Tom Roberts <tjroberts137@sbcglobal.net> |
|---|---|
| Date | 2017-05-30 09:57 -0500 |
| Message-ID | <hcSdnRPYgd7oFbDEnZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #634501 |
On 5/27/17 5/27/17 - 5:37 AM, Ckeho BaÚkora wrote: > Tom Roberts wrote: >> The GPS receiver's position calculation is based on the OBSERVATION that >> the vacuum speed of light is isotropically c relative to the ECI >> coordinates. The entire path is not in vacuum, so there are corrections >> for ionospheric and atmospheric effects. > > The receivers are working only, > and only, on the DATA received from the satellites. NOT on the speeds of > the signals carrying IT. The algorithm does depend on the speed of the signals relative to the ECI. From the data stream the receiver can determine the satellite's position and the GPS time when a given timing mark was transmitted. Using that information for 4 (or more) satellites, plus knowledge of the speed of light relative to the ECI, plus its measured receive time for the timing marks, the receiver calculates its position in the ECI. It then transforms this to the rotating-earth coordinates for reporting to the user. If the wrong speed were used (such as Wilson's fantasy of c+V_satellite), the position calculation would yield the wrong answer. Like so many others around here, you need to LEARN something about the subject before attempting to write about it. It is USELESS to just make stuff up and pretend it is true. Tom Roberts
[toc] | [prev] | [next] | [standalone]
| From | Helmut Wabnig <hwabnig@.- --- -.dotat> |
|---|---|
| Date | 2017-05-30 20:52 +0200 |
| Message-ID | <jpfric53b8s3j90nh608f4dfb3snet3plf@4ax.com> |
| In reply to | #634748 |
On Tue, 30 May 2017 09:57:56 -0500, Tom Roberts <tjroberts137@sbcglobal.net> wrote: >On 5/27/17 5/27/17 - 5:37 AM, Ckeho BaÚkora wrote: >> Tom Roberts wrote: >>> The GPS receiver's position calculation is based on the OBSERVATION that >>> the vacuum speed of light is isotropically c relative to the ECI >>> coordinates. The entire path is not in vacuum, so there are corrections >>> for ionospheric and atmospheric effects. >> >> The receivers are working only, >> and only, on the DATA received from the satellites. NOT on the speeds of >> the signals carrying IT. > >The algorithm does depend on the speed of the signals relative to the ECI. How does the receiver know the speed (velocity) of the signal? w. ======= >From >the data stream the receiver can determine the satellite's position and the GPS >time when a given timing mark was transmitted. Using that information for 4 (or >more) satellites, plus knowledge of the speed of light relative to the ECI, plus >its measured receive time for the timing marks, the receiver calculates its >position in the ECI. It then transforms this to the rotating-earth coordinates >for reporting to the user. > >If the wrong speed were used (such as Wilson's fantasy of c+V_satellite), the >position calculation would yield the wrong answer. > >Like so many others around here, you need to LEARN something about the subject >before attempting to write about it. It is USELESS to just make stuff up and >pretend it is true. > >Tom Roberts
[toc] | [prev] | [next] | [standalone]
| From | Ernest Rivers <erwm@weicnne.ac> |
|---|---|
| Date | 2017-05-30 19:17 +0000 |
| Message-ID | <ogkgfm$1epg$5@gioia.aioe.org> |
| In reply to | #634761 |
Helmut Wabnig wrote: >>> The receivers are working only, >>> and only, on the DATA received from the satellites. NOT on the speeds >>> of the signals carrying IT. >> >>The algorithm does depend on the speed of the signals relative to the >>ECI. > > How does the receiver know the speed (velocity) of the signal? LOL.
[toc] | [prev] | [next] | [standalone]
| From | Tom Roberts <tjroberts137@sbcglobal.net> |
|---|---|
| Date | 2017-05-30 15:23 -0500 |
| Message-ID | <O-qdnfXgr_Y4SbDEnZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #634761 |
On 5/30/17 5/30/17 - 1:52 PM, Helmut Wabnig wrote: > On Tue, 30 May 2017 09:57:56 -0500, Tom Roberts > <tjroberts137@sbcglobal.net> wrote: >> The algorithm does depend on the speed of the signals relative to the ECI. > > How does the receiver know the speed (velocity) of the signal? It is hard-coded into the software. It has been solidly established that the vacuum speed of light relative to the ECI is 299,792,458 meters/sec, isotropically. (There are corrections for non-vacuum propagation in the atmosphere.) Tom Roberts
[toc] | [prev] | [next] | [standalone]
| From | Helmut Wabnig <hwabnig@.- --- -.dotat> |
|---|---|
| Date | 2017-05-30 22:53 +0200 |
| Message-ID | <pomrictddf8ii0bmk5158jghg139ov40i3@4ax.com> |
| In reply to | #634770 |
On Tue, 30 May 2017 15:23:01 -0500, Tom Roberts <tjroberts137@sbcglobal.net> wrote: >On 5/30/17 5/30/17 - 1:52 PM, Helmut Wabnig wrote: >> On Tue, 30 May 2017 09:57:56 -0500, Tom Roberts >> <tjroberts137@sbcglobal.net> wrote: >>> The algorithm does depend on the speed of the signals relative to the ECI. >> >> How does the receiver know the speed (velocity) of the signal? > >It is hard-coded into the software. It has been solidly established that the >vacuum speed of light relative to the ECI is 299,792,458 meters/sec, >isotropically. (There are corrections for non-vacuum propagation in the atmosphere.) > >Tom Roberts You do not know how things work. According to you, the receiver must have a clock with ultra high precision, which is not the case. Withou that ultra reference clock a number like 299,792,458 in software makes no sense. You do know that CPU's are clocked, do you? w.
[toc] | [prev] | [next] | [standalone]
| From | Ernest Schwanenflügel <erwm@wanenf.oa> |
|---|---|
| Date | 2017-05-30 20:59 +0000 |
| Message-ID | <ogkmek$1qeh$1@gioia.aioe.org> |
| In reply to | #634773 |
Helmut Wabnig wrote: >>> How does the receiver know the speed (velocity) of the signal? >> >>It is hard-coded into the software. It has been solidly established that >>the vacuum speed of light relative to the ECI is 299,792,458 meters/sec, >>isotropically. (There are corrections for non-vacuum propagation in the >>atmosphere.) Tom Roberts > > You do not know how things work. > According to you, the receiver must have a clock with ultra high > precision, which is not the case. > Withou that ultra reference clock a number like 299,792,458 in software > makes no sense. You do know that CPU's are clocked, do you? Excellent Helmut, finally one of the many, understood what is going on concerning GPS. Lol, thanks.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2017-05-31 00:42 +0200 |
| Message-ID | <1980322.iZASKD2KPV@PointedEars.de> |
| In reply to | #634775 |
The ’nym-shifting troll gibbered as "Ernest Schwanenflügel": > Helmut Wabnig wrote: >> Tom Roberts wrote: >>> Helmut Wabnig wrote: >>>> How does the receiver know the speed (velocity) of the signal? >>> It is hard-coded into the software. It has been solidly established that >>> the vacuum speed of light relative to the ECI is 299,792,458 meters/sec, >>> isotropically. (There are corrections for non-vacuum propagation in the >>> atmosphere.) >> >> You do not know how things work. No, *you* don’t. >> According to you, the receiver must have a clock with ultra high >> precision, which is not the case. >> Withou that ultra reference clock a number like 299,792,458 in software >> makes no sense. You do know that CPU's are clocked, do you? > > Excellent Helmut, finally one of the many, understood what is going on > concerning GPS. Lol, thanks. Unsurprisingly, the ’nym-shifting troll and his address-munging crackpot sidekick are understanding nothing at all. One does _not_ need a “clock with ultra high precision” in the GPS receiver, because the receiver clock’s bias against GPS time is the same for all GPS satellites (I am having a dèjá vu here): <https://en.wikipedia.org/wiki/Global_Positioning_System#Basic_concept_of_GPS> <https://en.wikipedia.org/wiki/Global_Positioning_System#Navigation_equations> *PLONK* -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Tom Roberts <tjroberts137@sbcglobal.net> |
|---|---|
| Date | 2017-05-30 19:03 -0500 |
| Message-ID | <u6ydnQ0OtYn2lbPEnZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #634773 |
On 5/30/17 5/30/17 3:53 PM, Helmut Wabnig wrote: > On Tue, 30 May 2017 15:23:01 -0500, Tom Roberts > <tjroberts137@sbcglobal.net> wrote: > >> On 5/30/17 5/30/17 - 1:52 PM, Helmut Wabnig wrote: >>> On Tue, 30 May 2017 09:57:56 -0500, Tom Roberts >>> <tjroberts137@sbcglobal.net> wrote: >>>> The algorithm does depend on the speed of the signals relative to the ECI. >>> >>> How does the receiver know the speed (velocity) of the signal? >> >> It is hard-coded into the software. It has been solidly established that the >> vacuum speed of light relative to the ECI is 299,792,458 meters/sec, >> isotropically. (There are corrections for non-vacuum propagation in the atmosphere.) >> >> Tom Roberts > > You do not know how things work. But I _DO_ know how the GPS works, because unlike you I have studied it. And I have the background to understand the design specifications (both physics and electronics). I first learned of the GPS at MILCOM'88, and I remember being amazed that such a thing was possible, and flabbergasted that it was actually up and (partially) operational. Even though it was not relevant to my reason for being there, I attended every session on GPS. > According to you, the receiver must have a clock with > ultra high precision, NONSENSE! I have never said anything like that. GPS receivers do NOT need a high-precision clock, because they use FOUR (or more) satellite signals from which they can fit to the data and determine the time with high precision (as well as position). Tom Roberts
[toc] | [prev] | [next] | [standalone]
| From | Serg io <invalid@invalid.com> |
|---|---|
| Date | 2017-05-30 21:30 -0500 |
| Message-ID | <ogl9rh$nj7$1@gioia.aioe.org> |
| In reply to | #634801 |
On 5/30/2017 7:03 PM, Tom Roberts wrote: > On 5/30/17 5/30/17 3:53 PM, Helmut Wabnig wrote: >> On Tue, 30 May 2017 15:23:01 -0500, Tom Roberts >> <tjroberts137@sbcglobal.net> wrote: >> >>> On 5/30/17 5/30/17 - 1:52 PM, Helmut Wabnig wrote: >>>> On Tue, 30 May 2017 09:57:56 -0500, Tom Roberts >>>> <tjroberts137@sbcglobal.net> wrote: >>>>> The algorithm does depend on the speed of the signals relative to >>>>> the ECI. >>>> >>>> How does the receiver know the speed (velocity) of the signal? >>> >>> It is hard-coded into the software. It has been solidly established >>> that the >>> vacuum speed of light relative to the ECI is 299,792,458 meters/sec, >>> isotropically. (There are corrections for non-vacuum propagation in >>> the atmosphere.) >>> >>> Tom Roberts >> >> You do not know how things work. > But I _DO_ know how the GPS works, because unlike you I have studied it. > And I have the background to understand the design specifications (both > physics and electronics). > > I first learned of the GPS at MILCOM'88, and I remember being > amazed that such a thing was possible, and flabbergasted that > it was actually up and (partially) operational. Even though it > was not relevant to my reason for being there, I attended > every session on GPS. > >> According to you, the receiver must have a clock with >> ultra high precision, > > NONSENSE! I have never said anything like that. > > GPS receivers do NOT need a high-precision clock, because they use FOUR > (or more) satellite signals from which they can fit to the data and > determine the time with high precision (as well as position). > > Tom Roberts those are "gps disiplined" oscillators, GPSDO see graph in https://a2la.org/guidance/GPS_Oscillators.pdf
[toc] | [prev] | [next] | [standalone]
| From | Serg io <invalid@invalid.com> |
|---|---|
| Date | 2017-05-30 19:01 -0500 |
| Message-ID | <ogl150$c7s$1@gioia.aioe.org> |
| In reply to | #634761 |
On 5/30/2017 1:52 PM, Helmut Wabnig wrote: > On Tue, 30 May 2017 09:57:56 -0500, Tom Roberts > <tjroberts137@sbcglobal.net> wrote: > >> On 5/27/17 5/27/17 - 5:37 AM, Ckeho BaÚkora wrote: >>> Tom Roberts wrote: >>>> The GPS receiver's position calculation is based on the OBSERVATION that >>>> the vacuum speed of light is isotropically c relative to the ECI >>>> coordinates. The entire path is not in vacuum, so there are corrections >>>> for ionospheric and atmospheric effects. >>> >>> The receivers are working only, >>> and only, on the DATA received from the satellites. NOT on the speeds of >>> the signals carrying IT. >> >> The algorithm does depend on the speed of the signals relative to the ECI. > > How does the receiver know the speed (velocity) of the signal? > all this is in the public domain, google GPS error analysis, I have a 500 page book on it.
[toc] | [prev] | [next] | [standalone]
| From | Ernest Rivers <erwm@weicnne.ac> |
|---|---|
| Date | 2017-05-30 19:15 +0000 |
| Message-ID | <ogkgd9$1epg$4@gioia.aioe.org> |
| In reply to | #634748 |
Tom Roberts wrote: >> The receivers are working only, >> and only, on the DATA received from the satellites. NOT on the speeds >> of the signals carrying IT. > > The algorithm does depend on the speed of the signals relative to the > ECI. No, it doesn't. Lol, the algorithm is burned into the chip, SoC (system on chip, a MCU). It reveals you lack Embedded Systems, and never programmed such one for real in the field, with maps and so on. > From the data stream the receiver can determine the satellite's position > and the GPS time when a given timing mark was transmitted. Using that > information for 4 (or more) satellites, plus knowledge of the speed of > light relative to the ECI, plus its measured receive time for the timing > marks, the receiver calculates its position in the ECI. It then > transforms this to the rotating-earth coordinates for reporting to the > user. Not sure, probably is right, but you miss the ESSENTIAL, with all due respect. All TIMING inclusive the LOCAL clock reading are coming remote, from the SATELLITES as well. (Since you can't base a triangulation on a local clock which is off and/or not accurate). > If the wrong speed were used (such as Wilson's fantasy of > c+V_satellite), the position calculation would yield the wrong answer. > Like so many others around here, you need to LEARN something about the > subject before attempting to write about it. It is USELESS to just make > stuff up and pretend it is true. Tom Roberts Me again?? I am not pretending nor making stuff up. Sorry seeing you like that. You should know better. Be it, I don't really care.
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@not.at.this.address> |
|---|---|
| Date | 2017-06-09 11:37 +1000 |
| Message-ID | <epuceeF5pnvU1@mid.individual.net> |
| In reply to | #634763 |
On 31/05/2017 5:15 AM, Ernest Rivers wrote: > Tom Roberts wrote: > >>> The receivers are working only, >>> and only, on the DATA received from the satellites. NOT on the speeds >>> of the signals carrying IT. >> >> The algorithm does depend on the speed of the signals relative to the >> ECI. > > No, it doesn't. Lol, the algorithm is burned into the chip, SoC (system on > chip, a MCU). It reveals you lack Embedded Systems, and never programmed > such one for real in the field, with maps and so on. The GPS time in the transmitted data from a GPS satellite allows the construction of an equation that essentially asserts that the distance between the receiver (at the time of reception) and the satellite (at the time of transmission) equals the time taken for the data to arrive multiplied by the speed of light. Since space is three dimensional, the equation contains four unknowns - the three spacial coordinates of the receiver, and the (unknown) GPS time at the receiver. The receiver solves four such equations simultaneously to determine the values of the four unknowns[*]. But, significantly, since the equations contain the speed of light, the algorithm is certainly dependent on it. The fact that the algorithm is burned into a chip (in those cases where it is), has no bearing on whether it is dependent on the speed of light. Sylvia. [*] With suitable allowance for the fact that the transmissions were not received simultaneously, and using data from more than four satellites where they are available.
[toc] | [prev] | [next] | [standalone]
| From | Jim Limey <eeug@dnne.ri> |
|---|---|
| Date | 2017-06-09 14:32 +0000 |
| Message-ID | <ohebig$c9k$2@gioia.aioe.org> |
| In reply to | #635861 |
Sylvia Else wrote: > The GPS time in the transmitted data from a GPS satellite allows the > construction of an equation that essentially asserts that the distance > between the receiver (at the time of reception) and the satellite (at > the time of transmission) equals the time taken for the data to arrive > multiplied by the speed of light. Mam, you just said you don't know the time for the data to arrive. I think i'll skip the rest till you make sure you understand the procedure correctly.
[toc] | [prev] | [next] | [standalone]
| From | Serg io <invalid@invalid.com> |
|---|---|
| Date | 2017-06-09 12:51 -0500 |
| Message-ID | <ohen80$13oj$1@gioia.aioe.org> |
| In reply to | #635885 |
On 6/9/2017 9:32 AM, Jim Limey wrote: > Sylvia Else wrote: > >> The GPS time in the transmitted data from a GPS satellite allows the >> construction of an equation that essentially asserts that the distance >> between the receiver (at the time of reception) and the satellite (at >> the time of transmission) equals the time taken for the data to arrive >> multiplied by the speed of light. > > Mam, you just said you don't know the time for the data to arrive. I think > i'll skip the rest till you make sure you understand the procedure > correctly. > yep, she left out coorolation, spread spectrum, and code chip length. much more complicated that what she stated. the speed of light is one thing, and the speed of signal travel is another, as going through the ionosphre causes delay, and atmosphere and bending. read up on an error analysis for GPS signal prosscing, very difficult and complex. a real wonder now, as it is decoded by 0.1 cubic inch electronics, and they can stick it in all cellphones, etc.
[toc] | [prev] | [next] | [standalone]
| From | Kitubu Nkyaku <akntuu@buwkau.kk> |
|---|---|
| Date | 2017-06-09 18:52 +0000 |
| Message-ID | <oheqoi$19ge$1@gioia.aioe.org> |
| In reply to | #635903 |
Serg io wrote: > yep, she left out coorolation, spread spectrum, and code chip length. You mean detection by correlation. > read up on an error analysis for GPS signal prosscing, very difficult > and complex. Does not really matters, once the Data is descrambled from the carrier. The timing is fixed. Nothing varies. > a real wonder now, as it is decoded by 0.1 cubic inch electronics, and > they can stick it in all cellphones, etc. Irrelevant. You too are stirring shit together, unnecessary. The process of fabrication, toootaly irrelevant. The outcome can only be more reliable and faster.
[toc] | [prev] | [next] | [standalone]
| From | "HGW..." <hgw@....> |
|---|---|
| Date | 2017-06-10 09:23 +1000 |
| Message-ID | <ohfakt$4e9$1@gioia.aioe.org> |
| In reply to | #635903 |
On 10/06/17 03:51, Serg io wrote: > On 6/9/2017 9:32 AM, Jim Limey wrote: >> Sylvia Else wrote: >> >>> The GPS time in the transmitted data from a GPS satellite allows the >>> construction of an equation that essentially asserts that the distance >>> between the receiver (at the time of reception) and the satellite (at >>> the time of transmission) equals the time taken for the data to arrive >>> multiplied by the speed of light. >> >> Mam, you just said you don't know the time for the data to arrive. I >> think >> i'll skip the rest till you make sure you understand the procedure >> correctly. >> > > yep, she left out coorolation, spread spectrum, and code chip length. > > much more complicated that what she stated. the speed of light is one > thing, and the speed of signal travel is another, as going through the > ionosphre causes delay, and atmosphere and bending. They also know that the signals travel slightly faster from satellites that are rising and slower from ones that are falling. > read up on an error analysis for GPS signal prosscing, very difficult > and complex. > > a real wonder now, as it is decoded by 0.1 cubic inch electronics, and > they can stick it in all cellphones, etc. I wear mine on my wrist at golf...accurate to <1M...with automatic data for 40000 courses built in. Can't see any atomic clock inside it.... --
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@not.at.this.address> |
|---|---|
| Date | 2017-06-10 11:23 +1000 |
| Message-ID | <eq0vvoFo6dqU2@mid.individual.net> |
| In reply to | #635903 |
On 10/06/2017 3:51 AM, Serg io wrote: > On 6/9/2017 9:32 AM, Jim Limey wrote: >> Sylvia Else wrote: >> >>> The GPS time in the transmitted data from a GPS satellite allows the >>> construction of an equation that essentially asserts that the distance >>> between the receiver (at the time of reception) and the satellite (at >>> the time of transmission) equals the time taken for the data to arrive >>> multiplied by the speed of light. >> >> Mam, you just said you don't know the time for the data to arrive. I >> think >> i'll skip the rest till you make sure you understand the procedure >> correctly. >> > > yep, she left out coorolation, spread spectrum, and code chip length. > > much more complicated that what she stated. the speed of light is one > thing, and the speed of signal travel is another, as going through the > ionosphre causes delay, and atmosphere and bending. Yes, there are complications, but the issue was whether the speed of light is part of the algorithm. It clearly is. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@not.at.this.address> |
|---|---|
| Date | 2017-06-10 11:21 +1000 |
| Message-ID | <eq0vtmFo6dqU1@mid.individual.net> |
| In reply to | #635885 |
On 10/06/2017 12:32 AM, Jim Limey wrote: > Sylvia Else wrote: > >> The GPS time in the transmitted data from a GPS satellite allows the >> construction of an equation that essentially asserts that the distance >> between the receiver (at the time of reception) and the satellite (at >> the time of transmission) equals the time taken for the data to arrive >> multiplied by the speed of light. > > Mam, you just said you don't know the time for the data to arrive. I think > i'll skip the rest till you make sure you understand the procedure > correctly. > The equation expresses a relationship between four unknowns, one of which is the GPS time at the receiver. The time taken by the signal to reach the receiver is the difference between that unknown and the time of transmission as encoded into the signal. This is just simple algebra. Your derisory comment suggests you don't understand it. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | Kitubu Nkyaku <akntuu@buwkau.kk> |
|---|---|
| Date | 2017-06-10 10:42 +0000 |
| Message-ID | <ohgidq$1pjn$1@gioia.aioe.org> |
| In reply to | #635977 |
Sylvia Else wrote: > On 10/06/2017 12:32 AM, Jim Limey wrote: >> Sylvia Else wrote: >> >>> The GPS time in the transmitted data from a GPS satellite allows the >>> construction of an equation that essentially asserts that the distance >>> between the receiver (at the time of reception) and the satellite (at >>> the time of transmission) equals the time taken for the data to arrive >>> multiplied by the speed of light. >> >> Mam, you just said you don't know the time for the data to arrive. I >> think i'll skip the rest till you make sure you understand the >> procedure correctly. > > The equation expresses a relationship between four unknowns, one of > which is the GPS time at the receiver. The time taken by the signal to > reach the receiver is the difference between that unknown and the time > of transmission as encoded into the signal. > This is just simple algebra. Your derisory comment suggests you don't > understand it. Sylvia. Mam, you just convinced the population you are stupid. Has nothing to do with what you say and the algorithm, which is simple, can be any, but fixed hardwired into the circuity as described above. You are indeed stupid.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | sci.physics
csiph-web