Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.physics.relativity > #420688 > unrolled thread
| Started by | "HGW, DSc." <HG@....> |
|---|---|
| First post | 2017-05-27 06:49 +1000 |
| Last post | 2017-06-05 00:49 +0000 |
| Articles | 20 on this page of 159 — 37 participants |
Back to article view | Back to sci.physics.relativity
GPS Again. "HGW, DSc." <HG@....> - 2017-05-27 06:49 +1000
Re: GPS Again. Ckeho Baùkora <unukn@owyqar.og> - 2017-05-26 21:01 +0000
Re: GPS Again. "David (Lord Kronos Prime) Fuller" <fuller.david@hotmail.com> - 2017-05-26 15:49 -0700
Re: GPS Again. Ckeho Baùkora <unukn@owyqar.og> - 2017-05-27 09:20 +0000
Re: GPS Again. dancouriann@gmail.com - 2017-05-26 15:50 -0700
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-05-26 17:58 -0500
GPS Again. "David (Lord Kronos Prime) Fuller" <fuller.david@hotmail.com> - 2017-05-26 16:14 -0700
GPS Again. "David (Lord Kronos Prime) Fuller" <fuller.david@hotmail.com> - 2017-05-26 16:38 -0700
Re: GPS Again. xxein1x1@gmail.com - 2017-05-26 16:25 -0700
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-05-27 00:18 +0000
Re: GPS Again. Tom Roberts <tjroberts137@sbcglobal.net> - 2017-05-26 19:51 -0500
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. xxein1x1@gmail.com - 2017-06-10 16:11 -0700
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-10 18:32 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-11 14:43 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-13 07:50 -0700
Re: GPS Again. Lolek Atoru <oitiruc@rwuca.oa> - 2017-06-13 20:56 +0000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-14 09:25 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-13 17:02 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-14 12:36 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-13 20:04 -0700
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-06-14 04:43 +0000
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-14 20:11 +1000
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-06-14 14:47 +0000
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. 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. Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2017-06-15 10:06 -0700
Re: GPS Again. Kotovanich Nzerovu <ivhvruo@wovewvw.ev> - 2017-06-15 17:30 +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. 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. mlwozniak@wp.pl - 2017-06-12 23:03 -0700
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. mlwozniak@wp.pl - 2017-06-14 01:20 -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. "Paul B. Andersen" <relativity@paulba.no> - 2017-05-27 07:36 +0200
Re: GPS Again. "HGW... DSc." <hgw@....> - 2017-05-28 10:57 +1000
Re: GPS Again. Rafael Valls Hidalgo-Gato <rvalls162@gmail.com> - 2017-05-31 07:02 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-01 09:00 +1000
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-05-31 23:42 +0000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-01 19:36 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-01 05:33 -0700
Re: GPS Again. "HGW, DSc." <HG@....> - 2017-06-02 19:51 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-03 05:10 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-04 08:08 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-03 15:27 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-04 08:50 +1000
Re: GPS Again. pnalsing@gmail.com - 2017-06-03 19:37 -0700
Re: GPS Again. Poutnik <poutnik4nntp@gmail.com> - 2017-06-04 07:09 +0200
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-04 16:06 +1000
Re: GPS Again. Prudence Youngs <usue@weuem.ge> - 2017-06-04 11:11 +0000
Re: GPS Again. Poutnik <poutnik4nntp@gmail.com> - 2017-06-04 14:23 +0200
Re: GPS Again. Prudence Youngs <usue@weuem.ge> - 2017-06-04 12:33 +0000
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-06-04 18:17 +0000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-04 05:06 -0700
Re: GPS Again. Prudence Youngs <usue@weuem.ge> - 2017-06-04 12:12 +0000
Re: GPS Again. anne <0140519@gmail.com> - 2017-06-04 05:32 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-05 08:48 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-04 16:09 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-05 11:12 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-04 19:24 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-05 16:38 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-05 04:49 -0700
Re: GPS Again. mlwozniak@wp.pl - 2017-06-05 05:53 -0700
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-06 08:38 +1000
Re: GPS Again. Gary Harnagel <hitlong@yahoo.com> - 2017-06-05 20:30 -0700
Re: GPS Again. Poutnik <poutnik4nntp@gmail.com> - 2017-06-04 15:00 +0200
Re: GPS Again. Prudence Youngs <usue@weuem.ge> - 2017-06-04 11:10 +0000
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-06-04 13:25 +0000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-05 08:46 +1000
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-06-04 23:13 +0000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-05 11:16 +1000
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-06-05 09:26 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-06 08:46 +1000
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-06-05 23:17 +0000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-07 10:11 +1000
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-06-07 03:04 +0000
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-07 14:58 +1000
Re: GPS Again. Odd Bodkin <bodkinodd@gmail.com> - 2017-06-07 12:17 -0500
Re: GPS Again. "HGW..." <hgw@....> - 2017-06-08 09:06 +1000
Re: GPS Again. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-06-05 00:49 +0000
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Serg io <invalid@invalid.com> |
|---|---|
| Date | 2017-05-30 21:30 -0500 |
| Message-ID | <ogl9rh$nj7$1@gioia.aioe.org> |
| In reply to | #421148 |
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 | #421086 |
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 | #421057 |
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 | #421094 |
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 | #422008 |
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 | #422057 |
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 | #422074 |
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 | #422074 |
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 | #422074 |
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 | #422057 |
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 | #422120 |
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]
| From | Serg io <invalid@invalid.com> |
|---|---|
| Date | 2017-06-10 19:38 -0500 |
| Message-ID | <ohi3fv$2ms$1@gioia.aioe.org> |
| In reply to | #422144 |
On 6/10/2017 5:42 AM, Kitubu Nkyaku wrote:
> 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.
>
no need to say she is stupid, and it is not simple algebra.
best to google for GPS signal processing, it is much more complicated
spread spectrum, tracking, etc. than simply sending a time stamp back
and forth.
far too complicated to discuss in a newsgroup
https://en.wikipedia.org/wiki/GPS_signals
good one here;
http://web.ics.purdue.edu/~ecalais/teaching/geodesy/GPS_observables.pdf
[toc] | [prev] | [next] | [standalone]
| From | Nými Icelulózy <ejienm@wzsfwe.ul> |
|---|---|
| Date | 2017-06-16 11:30 +0000 |
| Message-ID | <oi0fh3$b8f$4@gioia.aioe.org> |
| In reply to | #422207 |
Serg io wrote: > best to google for GPS signal processing, it is much more complicated > spread spectrum, tracking, etc. than simply sending a time stamp back > and forth. To the best of my knowledge that DSP is done by a dedicated chip, sir. Are you a doctor?
[toc] | [prev] | [next] | [standalone]
| From | Sегgi о <iinvalid@invalid.com> |
|---|---|
| Date | 2017-06-16 10:40 -0500 |
| Message-ID | <oi0u5g$15e9$1@gioia.aioe.org> |
| In reply to | #422705 |
On 6/16/2017 6:30 AM, NÜmi Icelulózy wrote: > Serg io wrote: > >> best to google for GPS signal processing, it is much more complicated >> spread spectrum, tracking, etc. than simply sending a time stamp back >> and forth. > > To the best of my knowledge that DSP is done by a dedicated chip, sir. Are > you a doctor? > Hi, yes it is amazing how far we have gone in integrating GPS, there are cellphone chips out there that have integrated GPS processing too, for $7 on amazon. checkout this GPS chip; $40. Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3 https://www.amazon.com/Adafruit-Ultimate-GPS-Breakout-channel/dp/B00GLW4016/ref=sr_1_3/134-9404701-3381400?ie=UTF8&qid=1497626679&sr=8-3&keywords=gps+chipset this one is $15 https://www.amazon.com/DIYmall-AeroQuad-Antenna-Arduino-Aircraft/dp/B01H5FNA4K/ref=pd_sbs_147_4?_encoding=UTF8&pd_rd_i=B01H5FNA4K&pd_rd_r=EHK72GE8G5Z76SR0R1FR&pd_rd_w=thiFR&pd_rd_wg=kdjoH&psc=1&refRID=EHK72GE8G5Z76SR0R1FR ............................ the actual processing techniques on a GPS chip of 12 simaltanious GPS is hard to find out in the open, it was a tough design in the past to meet the high # of corrolators AND average power. Then the ARM processors came along... http://pccomponents.com/datasheets/SIRF-GRF2I.PDF "SiRFstarIIe/LP architecture sets the standard for high volume GPS performance. The SiRFstarIIe/LP still uses 1,920 corrolators and 12 channels to provide fast acquisition and reaquisition times, while keeping peak current to under 65 mA. TricklePower extends battery life even further by reducing average current to under 20mA. Now superior performance" I'm no Dr, but have masters,
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@not.at.this.address> |
|---|---|
| Date | 2017-06-11 11:11 +1000 |
| Message-ID | <eq3jm6Fbp3jU1@mid.individual.net> |
| In reply to | #422144 |
On 10/06/2017 8:42 PM, Kitubu Nkyaku wrote: > 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. > As, I thought, the algebra is beyond you, and you cannot see that regardless of how its implemented, it still has a dependency on the speed of light. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | Serg io <invalid@invalid.com> |
|---|---|
| Date | 2017-06-10 21:20 -0500 |
| Message-ID | <ohi9e4$ai1$1@gioia.aioe.org> |
| In reply to | #422210 |
On 6/10/2017 8:11 PM, Sylvia Else wrote: > On 10/06/2017 8:42 PM, Kitubu Nkyaku wrote: >> Sylvia Else wrote: >> >>> On 10/06/2017 12:32 AM, Jim Limey wrote: >>>> Sylvia Else wrote: >>>> > > As, I thought, the algebra is beyond you, and you cannot see that > regardless of how its implemented, it still has a dependency on the > speed of light. > > Sylvia. there are relativistic effects that must be backed out, Clocks in orbit appear to run faster (38.3 μsec/day = 11.5 km/day!) ⇒tuned at 10.22999999543 MHz before launching (g.) −Clocks speed is a function of orbit eccentricity (45 nsec= 14 m) 1 Measure arrival time of GPS signals from several satellites simultaneously 2 Decode the GPS signal and figure out the signal propagation time (tr-te), multiply by c= “pseudoranges” (= GPS data, or observables) 3 Decode the navigation message and convert it into satellite positions 4 Use at least 4 pseudoranges acquired at the same time from 4 different satellites to compute a position in an ECEF frame. 5 Convert ECEF position into latitude-longitude-height in any geodetic system (for instance WGS84). (note the sattilite positions must be known, the ECEF is the intersection of 3 spheres
[toc] | [prev] | [next] | [standalone]
| From | Sylvia Else <sylvia@not.at.this.address> |
|---|---|
| Date | 2017-06-11 12:31 +1000 |
| Message-ID | <eq3ochFcnfvU1@mid.individual.net> |
| In reply to | #422215 |
On 11/06/2017 12:20 PM, Serg io wrote: > On 6/10/2017 8:11 PM, Sylvia Else wrote: >> On 10/06/2017 8:42 PM, Kitubu Nkyaku wrote: >>> Sylvia Else wrote: >>> >>>> On 10/06/2017 12:32 AM, Jim Limey wrote: >>>>> Sylvia Else wrote: >>>>> > >> >> As, I thought, the algebra is beyond you, and you cannot see that >> regardless of how its implemented, it still has a dependency on the >> speed of light. >> >> Sylvia. > > there are relativistic effects that must be backed out, Clocks in orbit > appear to run faster (38.3 μsec/day = 11.5 km/day!) > ⇒tuned at 10.22999999543 MHz before launching (g.) > > −Clocks speed is a function of orbit eccentricity (45 nsec= 14 m) > > 1 Measure arrival time of GPS signals from several satellites > simultaneously > > 2 Decode the GPS signal and figure out the signal propagation time > (tr-te), multiply by c= “pseudoranges” (= GPS data, or observables) c being the speed of light, so it depends on the speed of light, which is the point of this subthread. Sylvia.
[toc] | [prev] | [next] | [standalone]
| From | Tom Roberts <tjroberts137@sbcglobal.net> |
|---|---|
| Date | 2017-06-10 22:40 -0500 |
| Message-ID | <9-WdndqChJsuJqHEnZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #422215 |
On 6/10/17 6/10/17 9:20 PM, Serg io wrote:
> there are relativistic effects that must be backed out, Clocks in orbit appear
> to run faster (38.3 μsec/day = 11.5 km/day!)
> ⇒tuned at 10.22999999543 MHz before launching (g.)
Yes, a receiver on earth receives satellite signals with a clock frequency of
10.23000000000 MHz, because they were generated at 10.22999999543 MHz and
relativistic effects bring it to that value, as required to keep GPS time in
sync with UTC (which is defined on the geoid).
The relativistic effects must NOT be "backed out", as they are essential to the
operation of the GPS.
> −Clocks speed is a function of orbit eccentricity (45 nsec= 14 m)
Satellite clock tick rate is indeed a function of the satellite's orbital
eccentricity; its contribution to the error budget is quite small.
Your number is just the vacuum speed of light, unrelated to
orbital eccentricities.
> 1 Measure arrival time of GPS signals from several satellites simultaneously
This can only be done approximately -- their signals do NOT arrive
simultaneously. The receiver relies on its local clock to determine the time
differences between the arrivals of the various time markers. The error
introduced by the inaccuracy of the local clock is only significant for the
overall time offset of the local clock (the local clock tick rate is good enough
that its error is negligible over these short durations).
> 2 Decode the GPS signal and figure out the signal propagation time (tr-te),
> multiply by c= “pseudoranges” (= GPS data, or observables)
Yes. Contrary to claims in this thread, this is where the vacuum speed of light
enters the calculation.
> 3 Decode the navigation message and convert it into satellite positions
>
> 4 Use at least 4 pseudoranges acquired at the same time from 4 different
> satellites to compute a position in an ECEF frame.
No. The pseudoranges determine position in the ECI frame. The navigational
messages also contain the details of the transform from ECI to ECEF.
The key property of the GPS is that each satellite clock always displays the GPS
time that an ECI coordinate clock at its current location would display. Since
the vacuum speed of light is isotropically c in the ECI coordinates, the
calculation of pseudo ranges is straightforward (corrections for the effects of
propagation in air are generally small).
> 5 Convert ECEF position into latitude-longitude-height in any geodetic system
> (for instance WGS84).
>
> (note the sattilite positions must be known, the ECEF is the intersection of 3
> spheres
The ECI position is the intersection of FOUR spheres, or it is the best fit
among five or more spheres (limited to 12 because that is the largest number of
GPS satellites visible from any point on earth at any given time).
Most receivers require at least four satellites, because
they must determine 4 values of the position in the ECI:
{x,y,z,t}. Some specialized receivers have algorithms capable
of determining position with fewer satellites by using
additional information (e.g. watching the satellites for a
long time, or knowing the altitude, time, or previous position
independently).
Tom Roberts
[toc] | [prev] | [next] | [standalone]
| From | Serg io <invalid@invalid.com> |
|---|---|
| Date | 2017-06-10 23:20 -0500 |
| Message-ID | <ohigf0$ir7$1@gioia.aioe.org> |
| In reply to | #422217 |
On 6/10/2017 10:40 PM, Tom Roberts wrote:
> On 6/10/17 6/10/17 9:20 PM, Serg io wrote:
>> there are relativistic effects that must be backed out, Clocks in
>> orbit appear to run faster (38.3 μsec/day = 11.5 km/day!)
>> ⇒tuned at 10.22999999543 MHz before launching (g.)
>
> Yes, a receiver on earth receives satellite signals with a clock
> frequency of 10.23000000000 MHz, because they were generated at
> 10.22999999543 MHz and relativistic effects bring it to that value, as
> required to keep GPS time in sync with UTC (which is defined on the geoid).
>
> The relativistic effects must NOT be "backed out", as they are essential
> to the operation of the GPS.
it is a identifiable and calculable error term which is removed
>
>> −Clocks speed is a function of orbit eccentricity (45 nsec= 14 m)
>
> Satellite clock tick rate is indeed a function of the satellite's
> orbital eccentricity; its contribution to the error budget is quite small.
>
> Your number is just the vacuum speed of light, unrelated to
> orbital eccentricities.
nope, 14 meter higher is 45 ns longer...
>
>> 1 Measure arrival time of GPS signals from several satellites
>> simultaneously
>
> This can only be done approximately -- their signals do NOT arrive
> simultaneously.
the statement says 'measure' simultaneously, not arrive .....
> The receiver relies on its local clock to determine the
> time differences between the arrivals of the various time markers.
part of it, but the signals are corrolated...
> The
> error introduced by the inaccuracy of the local clock is only
> significant for the overall time offset of the local clock (the local
> clock tick rate is good enough that its error is negligible over these
> short durations).
in some cases
>
>> 2 Decode the GPS signal and figure out the signal propagation time
>> (tr-te), multiply by c= “pseudoranges” (= GPS data, or observables)
>
> Yes. Contrary to claims in this thread, this is where the vacuum speed
> of light enters the calculation.
>
>> 3 Decode the navigation message and convert it into satellite positions
>>
>> 4 Use at least 4 pseudoranges acquired at the same time from 4
>> different satellites to compute a position in an ECEF frame.
>
> No. The pseudoranges determine position in the ECI frame. The
> navigational messages also contain the details of the transform from ECI
> to ECEF.
see #3 above
>
> The key property of the GPS is that each satellite clock always displays
> the GPS time that an ECI coordinate clock at its current location would
> display. Since the vacuum speed of light is isotropically c in the ECI
> coordinates, the calculation of pseudo ranges is straightforward
> (corrections for the effects of propagation in air are generally small).
small errors cause poor resolution,
>
>> 5 Convert ECEF position into latitude-longitude-height in any geodetic
>> system (for instance WGS84).
>>
>> (note the sattilite positions must be known, the ECEF is the
>> intersection of 3 spheres
>
> The ECI position is the intersection of FOUR spheres, or it is the best
> fit among five or more spheres (limited to 12 because that is the
> largest number of GPS satellites visible from any point on earth at any
> given time).
>
> Most receivers require at least four satellites, because
> they must determine 4 values of the position in the ECI:
> {x,y,z,t}. Some specialized receivers have algorithms capable
> of determining position with fewer satellites by using
> additional information (e.g. watching the satellites for a
> long time, or knowing the altitude, time, or previous position
> independently).
>
> Tom Roberts
>
[toc] | [prev] | [next] | [standalone]
| From | "HGW, DSc." <HG@....> |
|---|---|
| Date | 2017-06-11 05:14 +1000 |
| Message-ID | <ohhgbq$18h7$1@gioia.aioe.org> |
| In reply to | #422120 |
On 10/06/17 11:21, Sylvia Else wrote: > On 10/06/2017 12:32 AM, Jim Limey wrote: >> > > 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. It is not simple once all the relevant 'corrections' are included. IN fact, GPS navigation now effectively uses the number of wavelengths between satellite and receiver to determine distance rather than ct. So that stuffs up all your dingleberry claims about GPS. As I have been pointing out regularly, wavelength is absolute and so GPS now fully supports BaTh. > Sylvia.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | sci.physics.relativity
csiph-web