Jump to content

Talk:Global Positioning System/Archive 5

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by MiszaBot I (talk | contribs) at 04:34, 19 May 2010 (Archiving 30 thread(s) from Talk:Global Positioning System.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Archive 1Archive 3Archive 4Archive 5Archive 6Archive 7Archive 9

Number of satellites needed?

I'm a little cofused about the following sentence: "A typical GPS receiver calculates its position using the signals from four or more GPS satellites." - it contradicts with the info found in [4]: "In order to make this simple calculation, then, the GPS receiver has to know two things: * The location of at least three satellites above you * The distance between you and each of those satellites " Tauntz (talk) 09:49, 23 April 2008 (UTC)

If the GPS receiver had an atomic clock, it could calculate its position using only three satellites because it would have an accurate time reference. However, consumer models typically use quartz clocks which only have short-term accuracies at the precision needed for this application. So a fourth satellite is needed so that the current time can be calculated to a usable level of accuracy. — Val42 (talk) 05:39, 24 April 2008 (UTC)
Additional: The location of at least three satellites above you and the information [error, read distance instead of information Crazy Software Productions (talk) 16:02, 20 June 2008 (UTC)] between you and each satellite is indeed enough for calculation of your position. The problem with this is that you do not know the distance to each satellite and can not determine that information from only the signals of three satellites. One possible solution would be that you have a very accurate clock (as suggested in the above anwser) which is synchronised to the satellites clocks. Another way to know the distance to each satellite is to use two way communication. But GPS does not work with two way communication. A very long measuring tape is not an option either. See the paragraaf "Number of satellites needed for positioning" in this discussion session for a further explanation. GPS uses three timedifferences to determine the location. To get three timedifferences, the signals of four satelites are needed.
How can three satellites be enough to locate you in space? The earth is not a plane, it is a sphere. To locate a point in space you mathematically need four reference points (not in the same plane) to measure your distance from. Think of the intersection of four spheres. Three are not enough (you get two intersection points). Don't confuse with the plane where three reference points are enough (if and only if they are not on the same line !) to calculate your position (three circles to get one intersection point). —Preceding unsigned comment added by 212.27.60.48 (talk) 07:54, 17 June 2009 (UTC)
Problem with a lot of sites and booklets explaining the workings of the GPS that those explanations are simplified, by assuming that an accurate clock is available. For a simplified explanation this is not a problem, but if this simplified explanation then is used the determine the number of satellites needed, all sort of wrong reasons turn up why a fourth satellite is needed.Crazy Software Productions (talk) 21:19, 26 April 2008 (UTC)
Even without an atomic clock, some consumer GPS navigation devices used on the ground should be able to calculate the current position, since they have reasonable accurate information of the position of the Earth's surface. --SmilingBoy (talk) 16:17, 15 May 2009 (UTC)
The earth is the fourth sphere. And there is no down loading of the geography. The GPSR treats the earth as a sphere and you are above or below sea level.

1 satellite, a circle on the ground of the earth (the other sphere)

Incorrect, with no absolute time (quartz clock) there is no way of estimating the size of the circle. With normal clockdrift the circle could be expanding (or contracting) with supersonic speed. This problem does extend to the 2 satellite scenario, where both circles can expand or contract with high speed. Crazy Software Productions (talk) 19:04, 7 July 2009 (UTC)

2 satellites, Conjunction of two circles which is two points on the ground.

3 satellites, a single point on the earth with no altitude correction.

With three satellites and a assumed or guessed hight (distance from the middle of the earth) the location can be calculated, but the accuracy depends on the difference between the actual and the assumed hight. (There can be more than a single solution, but there is only one solution which is stable.Crazy Software Productions (talk) 19:04, 7 July 2009 (UTC)

4 satellites, correct altitude as defined by delta from sea level.

I think both sentences in question are correct if the one talking about 3 sats is not talking about altitude which will put you on the right road with a GPSR containing a map. 4 satellites for the added benefit of altitude. which is really not necessary for location.

If no altitude is known, there can be no accurate calculation of the position. If an altitude is guessed (previous known altitude) or is assumed, the calculated position is dependend on how accurate the assumed altitude was.
2D position calculation, normaly uses the last known altitude of the GPS unit. If the unit is not moved and not reset, this altitude will be accurate enough to do the positional calculation in most situations.Crazy Software Productions (talk) 19:04, 7 July 2009 (UTC)

Personally, I like locks on eight or more satellites. ;-)MBCF (talk) 00:46, 18 June 2009 (UTC)

A lot of assumptions are required: is the GPS receiver on the ground? Is the "ground" a building, mountain, etc.? Last I checked, the surface contour data was hundreds of megabytes just for the U.S. While I suppose it could be added to a modern unit, it's hard to justify it given the other variables. —EncMstr (talk) 16:25, 15 May 2009 (UTC)
See my comments just above. No GPS tells you your distance from ground. It tells you distance from sea level. (You use an altimeter to tell you when you are going to hit the ground if parachuting but right before you take off the runway you set it to zero while standing on the ground.MBCF (talk) 00:46, 18 June 2009 (UTC)
Except, if you don't have an altimeter, GPS-computed elevation is terribly inaccurate. There is such a thing, however, called the Wide Area Augmentation System, that tries to make that elevation figure a little more accurate, but it only works if you're in North America. The equivalent in Europe is EGNOS. -- Denelson83 01:33, 19 June 2009 (UTC)

Reference number 4 is dead

Site not found. brandnewbrain (talk) 09:43, 2 February 2009 (UTC)

GPS/ Meteorological satellites

Surely if you could use meteorological satellites the way you can use GPS systems, you could fit a receiver onto a vehicle such as a car and use it to provide constant updates about the weather —Preceding unsigned comment added by 78.150.77.106 (talk) 17:35, 3 February 2009 (UTC)

It doesn't work that way. Weather satellites only send their readings to meteorological organizations, which then process the readings and distributes them to the public. They don't send their analyses over those satellites. -- Denelson83 01:11, 4 February 2009 (UTC)
And even if you would be able to receive the satellite signals, for example weather pictures, you would need quite an antenna setup on on vehicle, to be able to get enough signal. (Large antenna which has to be aimed at the satellite all the time.) The weather satellites transmit far more information than the GPS satellites and therefore you need a far better receiving station.83.85.120.147 (talk) 21:56, 8 February 2009 (UTC)
However, some GPS receivers, like the Garmin GPSMAP 478, allow an XM WX receiver to be connected so you can receive weather information that way. -- Denelson83 00:58, 9 February 2009 (UTC)

Disadvantage of Multidimensional Newton Method

I removed the following sentence about Newton's method, then it was reinserted:

A disadvantage of this method is that according to,[1] "There are no good general methods for solving systems of more than one nonlinear equations."

While it is true that there are no good general methods for solving nonlinear systems, I don't think that this can be counted as a disadvantage of Newton's method, for two reasons:

  • to solve GPS, we don't need a "good general method" for nonlinear systems, we only need a method that works well for the specialized quadratic systems arising in GPS. The given reference doesn't talk about the quality of Newton as it applies to these specific systems. I don't have a reason to believe that Newton is not a "good method" when applied to those systems.
  • even if the reference claimed that there are no good methods to solve the quadratic systems arising in GPS, which it doesn't, then that criticism would apply to all methods, not just to Newton's method.

AxelBoldt (talk) 23:58, 10 February 2009 (UTC)

I am glad to see you have put your argument in the Discussion section. Perhaps we can both learn from the discussion. I think we are talking about the multidimensional Newton or Newton Raphson method. I put the quote from Numerical Recipes in for the purpose of giving both real advantages as well as disadvantages. It seems to me that the multidimensional case has the inherent disadvantage that you cannot bracket the solution between arguments that have a positive error and those which have a negative error. This of course differs from the single dimensional case where a solution can be bracketed. It may turn out that multidimensional Newton Raphson works well for finding the position and clock error corresponding to the approximate intersection of four spheres. But it seems to me that in view of the comment in Numerical Recipes, one should always be aware of the possibility of failure.

RHB100 (talk) 21:47, 12 February 2009 (UTC)

Commercial Aspect

Does the US Government charge any fee (royalty) from the producers of civilian GPS tracking devices? Does the US Government receive anything from the civilian use of GPS? Olegwiki (talk) 10:46, 11 March 2009 (UTC)

No they don't receive anything, other than I guess a warm fuzzy feeling for providing the service globally for free. PJohnson (talk) 07:20, 3 July 2009 (UTC)
So why don't they charge a royalty? Or is them just all terribly nice folks who don't care for the filthy lucre down yonder at the DOD? Maikel (talk) 11:33, 9 August 2009 (UTC)
In short, when the decision to make GPS publicly available was made, following the shoot-down of Korean Air Lines Flight 007, it was decided to make it free of charge, and no-one has since revised that policy. In a way this has worked out well; if they had set the royalties in 1983 while thinking of aircraft navigation, they might have set it quite high, compared to the $30 receivers we have nowerdays. Also, even though the government doesn't get direct royalties from GPS users, they benefit from the availability of cheap commercial-off-the-shelf receivers, the development of which is paid for by the consumer market. A license fee would also be difficult to enforce effectively. Mike1024 (t/c) 10:42, 10 August 2009 (UTC)

Contractors?

This is a very in-depth, technical article, but I find no mention of who the prime contractors are. That's odd, considering that most articles on space programs mention the contractors fairly prominently. 198.45.18.48 (talk) 14:28, 15 May 2009 (UTC)

That's a great suggestion. Please add them. —EncMstr (talk) 14:32, 15 May 2009 (UTC)

Countries forbidding GPS

I can’t find anything about the legal status of using GPS in the article. [1] tells that using GPS devices is forbidden in North Korea, Syria and Egypt. On OpenStreetMap I have heard that GPS devices were forbidden in China, but have been legalised in Egypt recently. I think this would be important information for the article. --84.153.8.183 (talk) 20:44, 17 May 2009 (UTC)

Data up to four hours old

I removed a sentence in the section on ephemeris errors stating that "data up to four hours old is consdiered valid", &c., since it's not, strictly speaking true. Ephemerides are uploaded on average every two hours, and are considered valid for the two hours BEFORE the time of ephemeris and two hours AFTER the TOE. At the end of that two hour window after TOE, the data is only two hours old, not four-- ephemerides more than two hours old are considered invalid. siafu (talk) 21:57, 28 May 2009 (UTC)

"Satellite numbers" table

The quasi-footnotes should be replaced with a non-numeric symbol because "0+123" is misleading (I first read it as 0+1728). Perhaps * ** *** or * † ‡, etc. Msanford  T  13:35, 16 June 2009 (UTC)

I agree with your suggestion. Go ahead and do it. I suggest letters but it is up to you. RHB100 (talk) 18:29, 4 August 2009 (UTC)

More on how satellites determine their positions

Only a casual reference to how a satellite knows its position is ever made. "Then the new ephemeris is uploaded and the satellite marked healthy again." I am personally unable to find reliable information about the process, but surely someone can fill in the article as to how often satellites need to be told their position, and how they calculate it in between these updates. —Preceding unsigned comment added by 72.89.225.174 (talk) 21:40, 29 July 2009 (UTC)

There is the statement, "The ephemeris is updated every 2 hours ...", in the section, Navigation signals. The ephemeris along with time enables the satellite to approximate its position. RHB100 (talk) 20:07, 1 August 2009 (UTC)

GPS / GNSS / NAVSTAR

This article is a bit two-faced, so to say. :) The intro states it's about one specific GNSS, namely NAVSTAR, but most of the article is about GNSS in general. Which of the two it should be about is a bit tricky, but a choice should be made.
I understand that, strictly speaking, GPS means NAVSTAR specifically. If it is to be about that, then a lot of (general) information should be moved to the GNSS article (or a new more in-depth article in some cases, given the amount of detail). But a much used consideration on Wikipedia is what people expect when they type in a word (or abbreviation). That would be the navigational bit, irrespective of which specific system is used. In which case a separate NAVSTAR article should be created (that link now redirects to this article). This will become more of an issue in the future, when more systems are being employed. People will most probably keep on calling that GPS, even when they use, say, Galileo. Another reason to make this the general article is that the term 'Global Positioning System' sounds rather generic.
I don't care much which decision is made, as long as one is made. Any thoughts? DirkvdM (talk) 07:06, 6 August 2009 (UTC)

Btw, this should also be addressed in other articles. For example, GNSS applications intermittently speaks of GNSS and GPS, even though (I assume) GNSS is always meant. And then there are the articles GNSS Road Pricing and GPS tracking, which are both about the generic system, but use different abbreviations. And is a GPS navigation device only for NAVSTAR? Or can several systems be used by one receiver (now or in the future)? So would that then have to be renamed to GNSS navigation device? DirkvdM (talk) 07:38, 6 August 2009 (UTC)

The article focuses on GPS, the GPS navigation signals, frequencies, etc and also covers fundamental principles. To cover GPS properly, it is necessary that these fundamental principles be included. But in so doing some material will probably be applicable to systems under development. But this is the nature of fundamental principles. This general information should remain a part of GPS. Articles covering new systems once they are developed may reference GPS or write an alternate description description of the general information. RHB100 (talk) 20:18, 6 August 2009 (UTC)
(indented your post)
Why should general information not be in an general article? Given the size of the article, such a split makes sense anyway, so why not solve the two issues at the same time? DirkvdM (talk) 07:22, 7 August 2009 (UTC)
What specifically are you talking about when you say general information? RHB100 (talk) 20:22, 7 August 2009 (UTC)
Well, the three best known GNSSes, GPS, GLONASS and Galileo, all rely on satellites in several orbital planes at medium earth orbit, with the satellites transmitting radio signals comprised of a transmission time and satellite position information; and receivers with access to at least 4 satellites are able to solve a system of equations to determine the time and receiver location, accurate to tens of meters. Both GPS and Galileo use CDMA, and GLONASS might move to CDMA in the future for compatibility. Compass may well follow the same design as well. Galileo and modernised GPS will boast very similar features, and are designed to be compatible. On the other hand, non-global satellite navigation systems like Beidou operate on different principles. I'm not sure if we should move the common features into a common article or not. Mike1024 (t/c) 10:00, 19 August 2009 (UTC)

Latest Launch

Current text: The most recent launch was on March 15, 2008.[11] The oldest GPS satellite still in operation was launched on November 26, 1990, and became operational on December 10, 1990.[12]

Correction: The most recent launch was on March 24, 2009. Citation: http://www.spaceflightnow.com/delta/d340/ —Preceding unsigned comment added by 130.221.224.5 (talk) 11:57, 13 August 2009 (UTC)

Update: The most recent launch was on Monday, August 17, 2009. Citation: http://www.spaceflightnow.com/delta/d343/ —Preceding unsigned comment added by 130.221.224.5 (talk) 16:47, 19 August 2009 (UTC)

Missing diagram

Position calculation introduction: "Another figure, Surface of Sphere Intersecting a Circle (not disk) at Two Points, illustrates the intersection."--There is no sign of the figure. I assumed it must be in the trilateration article, but it isn't. --Musiconeologist (talk) 18:48, 18 August 2009 (UTC)

This diagram has been in the Position calculation, advanced section for a long time. Up until a few months ago it was also in the Position calculation, introduction section but somebody removed it. I put it back in this morning so that it is now in both Position calculation sections again. RHB100 (talk) 19:19, 18 August 2009 (UTC)

Mathematical notation shoulld be kept large for readability

It is important that mathematical symbols be kept large since otherwise it is difficult to correctly read subscripts and superscripts. RHB100 (talk) 00:30, 20 October 2009 (UTC)

Very long template

This article is not unreasonably long. It already has been split with the addition of the introductory article. Any further split will likely interfere with it comprehensibility. I am therefore removing the very long template. Roesser (talk) 16:11, 20 October 2009 (UTC)

It is very long, and most readers won't read all of it. The details of position calculation should be moved to a sub-article like GPS position calculations. —EncMstr (talk) 16:57, 20 October 2009 (UTC)
After the split-off of the GPS Introductory article, this article is now intended (as I see it) for the technically minded reader who indeed will read most of it, especially the details of position calculation. It is more comprehenible to leave such details within the context of this article. There are various other technical details in the article, so where do we stop in splitting them off? I personnally learned a lot about GPS from this article and would hate to see it diminished by splitting off important details. Roesser (talk) 17:18, 20 October 2009 (UTC)
Somehow I missed the split off, and it took a rather concentrated effort to find the link (almost, but not quite at the top) to the split off article. I guess I expect it would be the other way around. This, Global Positioning System is the general overview and introduction, and another article has the nitty gritty details. —EncMstr (talk) 18:17, 20 October 2009 (UTC)

We already have the basic material covered in the section, Basic concept of GPS. I think one advantage of leaving it all together is that it allows readers to more easily decide what sections they want to read. I think it is great to have more detailed material available on navigation, frequencies, demodulation, decoding, and position calculation even though some readers may not be interested in these topics. RHB100 (talk) 18:59, 20 October 2009 (UTC)

Earlier this year we had a peer review of this article. I responded to many of the comments of the reviewers making changes in accordance with their suggestions so as to make the article better. Of all the comments the reviewers made, I do not recall a single one saying the article was too long. RHB100 (talk) 00:21, 21 October 2009 (UTC)

Vectors, scalars, GDOP, PDOP, and HDOP

A vector is characterized by a magnitude and a direction as defined at The Physics Department - Mechanics, Vectors. A quantity that has only size is called a scalar. A vector is not tied to a particular coordinate system but can be expressed in many coordinate system (e.g. body fixed, earth fixed, geocentric equatorial ... ). RHB100 (talk) 20:55, 16 November 2009 (UTC)

The quantities GDOP, HDOP, VDOP, TDOP defined in the section, Geometric dilution of precision computation (GDOP), are not vectors since there is no direction associated with these quantities. They are scalars. (PDOP, HDOP, VDOP, TDOP) is not a vector, it is an array of scalars. RHB100 (talk) 20:55, 16 November 2009 (UTC)

Can GPS been used at height or above of that of the GPS-Satellites?

Hi, I'm just curious to know, if it is possible to locate one's position, when the local altitude is equal or above that of the satellites. So could it been used for spacecraft applications? As far as I understand it, a sphere is needed for the projection of the coordinates. but has it be under the satellites, or is it still working above them? Thank you in advance! :) —Preceding unsigned comment added by 195.37.176.75 (talk) 19:13, 26 November 2009 (UTC)

That depends on how high an orbit you're trying to achieve. GPS satellites actually broadcast their signals in one direction (like a torch), rather than broadcasting in every direction (like a lightbulb). So if you were orbiting at the same altitude as GPS satellites do (20,000 km) you wouldn't get a signal because the 'torch' isn't pointed at you. On the other hand, not everything orbits that high! The international space station orbits at about 300 km, and the space shuttle can't get above 1000 km. At those sorts of altitudes the 'torch' would still be pointing at you so you could still get GPS - just go to a space equipment supplier like BAE Systems and you can buy a Space GPS Receiver and you're ready to go. Mike1024 (t/c) 17:45, 27 November 2009 (UTC)
The main problem with the position is the 'torch' effect of the GPS satellites as described above. They point towards the earth. But there are some satellites which are almost at the other side of the earth but are still visible, so their torches directed at the earth just mis the earth by a bit and might be received. Mathematically there is no problem of calculating the position if the receiver is higher than the GPS satellites if you have enough signal. I have seen (do not know where) a paper how the GPS satellites can be used beyond the distance of the 20000 km above earth. This paper did not give any indication if this was put into practice. One other point is that it can not be a 'civilian' reciever, because for civilian recievers they are not allowed to operate under these conditions. (Above a certain hight and above a certain speed).
Positioning of satellites at the moment is done the other way round. The satellite sends a signal which is received by several time synchronised stations. The same mathematics as in GPS is used to calculate the position of the satellite. Because the satellite does not take any sharp turns, and their trajectory is very predictable, this method of positioning the satellite is sufficient for knowing the position of the satetellite. Crazy Software Productions (talk) 12:35, 28 November 2009 (UTC)
GPS positioning is used in ISS operations these days (fairly new). It is used by both the ATV and the HTV cargo vessels (and ISS of course) for early approach. Final approach is usually infrarad or radar or something like that. And the space shuttle uses GPS to land since late 2007. It starts GPS tracking prior to the de orbit burn , and except during a short portion of deorbit, it uses it all the way until it lands. —TheDJ (talkcontribs) 14:14, 28 November 2009 (UTC)

The "see also" template should be removed

There is a template which says, "The length of this "see also" section may adversely affect readability." I don't know whether that is true or not. The length of the "see also" section has never bothered me in the slightest. However the template has certainly adversely affected the readability of the document for me. Whenever I right click on a reference so as to view it under a new tab, I don't see the reference but instead I am redirected to this uninformative template. RHB100 (talk) 21:05, 1 December 2009 (UTC)

I think there are cases where the template presents a far bigger problem than the problem the template is trying to correct and that this "see also" template is one of those caes. RHB100 (talk) 20:35, 1 December 2009 (UTC)

Figures on demodulation, decoding, and position calculation

There are problems with the figure in the file, Gps_ca_gold.svg depicted in the section, Demodulation and decoding, of the 00:51, 6 January 2010 version. The problems are

(1) The figure makes it appear that there are only two channels corresponding to satellite n1 and satellite n2. There should be channels corresponding to satellite n1, satellite n2, satellite n3 ... . and
(2) Some of the text is shown with a black font on a blue background making it difficult to read.

There is certainly no objection to improving on the art in the original figure in the file, Image:Ca gold.jpg, but please make sure you take care of the problems (1) and (2) above.

There is a problem with the figure in the file, Lat_2spheres_2.svg‎ depicted in the section, Position calculation advanced, of the 00:51, 6 January 2010 version.. This figure is not compatible with the text, "A figure, Two Sphere Surfaces Intersecting in a Circle, is shown below depicting this which hopefully will aid the reader in visualizing this intersection. Two points at which the surfaces of the spheres intersect are clearly marked on the figure. The distance between these two points is the diameter of the circle of intersection. If you are not convinced of this, consider how a side view of the intersecting spheres would look. This view would look exactly the same as the figure because of the symmetry of the spheres. And in fact a view from any horizontal direction would look exactly the same. This should make it clear to the reader that the surfaces of the two spheres actually do intersect in a circle."

In order to be compatible with the text, it is necessary that the polar axis of each sphere be vertical and that they are both along the same vertical line. There is no objection to improving the art work of the figure in the file, Lat_2spheres_2.jpg‎, but any improved version must be fully compatible with the text, just looking pretty is not sufficient. —Preceding unsigned comment added by RHB100 (talkcontribs) 21:33, 6 January 2010 (UTC)

Isn't Ca gold.jpg wrong anyway, though? I mean, don't most modern receivers modulate the broadcast signal down to an intermediate frequency, digitise it, then track each individual satellite with a separate costas loop? That's the impression I got, from the books I've read. I mean, every satellite's signal is doppler shifted, so the carrier frequencies are actually spread over a few kHz; surely trying to demodulate them all with the same carrier signal wouldn't work? Of course, I realise some simplifications to make the article accessible to its audience Mike1024 (t/c) 11:12, 7 January 2010 (UTC)

There are some simplifications in Ca gold.jpg. However, as you point out some simplifications to make the article accessible to its audience are necessary. RHB100 (talk) 20:40, 15 January 2010 (UTC)

NUDET/nuclear detonation detection payload needs love?

IMO a section of the article should be devoted to info on the nuclear detonation detection payload aboard GPS satellites. Since it seems that the article on the satellites themselves has been largely merged into this article on GPS, their alternate use should be mentioned here. This is something that almost no one with user level knowledge about GPS knows, but a use that is probably just as important to the US military as GPS location. I always thought it was clever that they found a way to build a watchful eye on the world that no one would want to destroy :). If someone wants to find for references to this usage, you could start with looking up the suspected nuclear detonation off the coast of Africa years ago, I think that's how I had learned about it. these 2 pages are a start: http://www.rand.org/pubs/monograph_reports/MR614/MR614.appb.pdf http://www.decodesystems.com/gps.html —Preceding unsigned comment added by 67.172.0.150 (talk) 13:41, 11 January 2010 (UTC)

inaccurate

The hidden comment, "The wikipedia article does describe trilateration, but not how an iterative version for the problem at hand would work. The algoritm which is mentioned in this article only does not always converge towards a solution" is vague, ambigous, and apparently self contradictory depending on how you resolve the vagueness and ambiguity. The Wikipedia article on GPS certainly does describe how an iterative approach using one dimensional root finding with the aid of trilateration would work along with a description of how a multi-dimensional approach not using trilateration would work. RHB100 (talk) 21:42, 22 February 2010 (UTC)

The error analysis which has been added to the GPS article is based on [http://books.google.com/books?id=lvI1a5J_4ewC&printsec=frontcover&source=gbs_navlinks_s#v=onepage&q=&f=false The global positioning system: theory and applications By Bradford W. Parkinson, James J. Spilker], which is a highly respected source. RHB100 (talk) 21:42, 22 February 2010 (UTC)

The receiver utilizes the messages it receives to determine thetransit time of each message and computes the distances to eachsatellite. These distances along with the satellites' locations areused with the possible aid of trilaterationto compute the position of the receiver. This position is thendisplayed, perhaps with a moving map display or latitude and longitude;elevation information may be included. Many GPS units also show derivedinformation such as direction and speed, calculated from positionchanges.

This is not true. For this, the receiver would need a very precise clock. It doesn't have one. In fact, it measures the differences between the times of the messages, and from those differences, it calculates the differences between the distances, and then it calculates the location. I will fix this, feel free to change my wordings and so. --Gerrit CUTEDH 22:34, 11 February 2010 (UTC)
The statement "This is not true. For this, the receiver would need a very precise clock" is an invalid conclusion. Just because you don't know how to get around the problem of receiver clock inaccuracy does not mean that other people cannot solve the problem. RHB100 (talk) 20:47, 22 February 2010 (UTC)
Unfortunately this error is very common. One website that gets it right is [2], otherwise one would probably have to look in scientific literature and technical reports and patents, and I'm not sure how accessible and public those are. --Gerrit CUTEDH 22:45, 11 February 2010 (UTC)
An accurate clock is not required to get the distances to each satellite. The clock just needs to be "in the ball park" and the distance to the fourth satellite along with some very clever math will provide the clock correction. -- Denelson83 09:02, 12 February 2010 (UTC)
I do agree with Gerrit. If a simplified model is used to explain the principle, keep it simple and do not try to use the simple model to explain the complex calculations. It's nice that the next paragraaf explains the clock correction. But the "Correcting a GPS receiver's clock" is flawed (as well). The suggested algoritm sometimes converges towards a solution, sometimes 'overcompensates' and then does not converge to a solution and sometimes does not even go towards the solution. The does not indicate in which direction and by how much the clock should be corrected for. In general the trilateration solution is not a good solution, problems with it are: It does not always converge, if it does converge it converges 'slow', it can not be used to discern between the two points. Compared to the pseudoalgoritm published on several places on the internet it uses a hugh amount of operations.
I think the statement regarding is untrue since it is specifically stated that the GPS receiver clock can be advanced if is positive or delayed if is negative. It also says by how much since b is in units of time. RHB100 (talk) 20:47, 22 February 2010 (UTC)
With the information of one single constellation of 4 satellites and one receiver and one starting error, the gives different results depending on which satellite is used as the 4th satellite. With the same constellation, b can be positive and can be negative, also the value does vary to some extend, some values becoming so large that if used for correction the error becomes larger.
With positive and negative values for one single constellation, there is no indication that b should be added or subtracted to correct the error, with the different sizes the size is no real indication for the size of the error.
I do agree with you that you stated how to add or subtract b from the 'time'. But by 'correction' I expect that after the correction the error is smaller than before. With B being negative and positive for the same constellation and 'time', it can not be that in both situations the endresult is an improvement.
The algoritm I used was constructed from the information in the 'trilateration' article and from the information given in the GPS article. Because the used formulas where derived from the texts it is difficult to see where the actual problem lies. This is not the only objection to iteration using trilateration, but one of the objections to iteration with trilateration. So if the complete algoritm was given in formulas or in programming code (pseudo code for example) it would be easier to point out the shortcommings of the method.
Crazy Software Productions (talk) 21:11, 24 February 2010 (UTC)
The pseudorangealgoritm works far superior compared to trilatertion. In general the pseudorange algoritm needs only one iteration for each solution and needs far fewer operations than trilateration for each cycle. Pseudorange calculation can be used to correct the clocktime, but does not need the clock time, only the relative distances (pseudoranges) are needed. The pseudo algoritm does not use spheres (and is not based on spheres).
I have implemented the pseudo range algoritm and the trilateration algoritm. With the trilateration algoritm I have showed with examples that it does not always converge. I came to the conclusion that the author did not try the trilateration algoritm on enough examples to see that there are plenty of examples where it does not converge well or at all.
The pseudo range algoritm always performs well, but it needs a starting estimate for were the receiver is. This starting estimate can be hundreds of miles off, even with hundreds of miles off, 5 iterations are enough to get a solution which is matematically correct within mm (milimeters). (With almost all satellite configurations even the middle of the earth can be choosen as a starting estimate and still only 5 iterations are needed to get within a mm solution).Crazy Software Productions (talk) 16:39, 20 February 2010 (UTC)


The paragraph right after that explains clock accuracy. Your explanation needlessly introduces a complex topic "differences in distance". The idea is that this section oversimplifies in order to communicate the concept. That it is not rigorous is a feature, not an inaccuracy. Despite that, it was reasonably faithful to the technical material, but I might be biased. (I wrote the text which largely remained there.) —EncMstr (talk) 23:38, 11 February 2010 (UTC)

In a paragraph above, Gerrit says "One website that gets it right is [3]". However if you read this article you will find that it says, "The position is determined based on triangulation". But GPS is not based on triangulation as defined at triangulation. RHB100 (talk) 21:15, 17 February 2010 (UTC)

Move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: page not moved after 18 days. Anthony Appleyard (talk) 15:52, 21 March 2010 (UTC)



Global Positioning SystemGPS — Latter redirects here, WP:COMMONNAME, Category:GPS and this discussion. —Justin (koavf)TCM23:03, 4 March 2010 (UTC)

  • Oppose. Our usual titling standards tend to support expanding acronyms, unless the expanded version is never used at all. For instance, we have an article at Federal Bureau of Investigation for the entity universally known as the FBI. "Global Positioning System" is much more frequently used than that example, even if it is frequently abbreviated. Gavia immer (talk) 12:39, 21 March 2010 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Relativity - correction


The effect of gravitational frequency shift on the GPS system due to general relativity is that a clock closer to a massive object will be slower than a clock farther away. Applied to the GPS system, the receivers are much closer to Earth than the satellites, causing the GPS clocks to be faster by a factor of 5×10^(-10), or about 45.9 μs/day. This gravitational frequency shift is also a noticeable effect.


There is a mistake. Yes, it is true, that the clock father away will be faster due to the weaker gravitional field. However, in case of orbiting satellites the effective gravitational field is completely canceled by the acceleration (remember totaly weightless astronauts in the orbit). According of the postulate of the general relativity theory an steady acceleration is equivalent to a homogenuos gravitational field - the satellite is in the effective zero-field. Thus, the factor 45.9 μs/day must correspond to zero-field time dilatation, not somewhat-weaker-field time dilatation.

--Huncut (talk) 13:30, 18 March 2010 (UTC)

GPS2, is there such a thing?

I heard a guy talking about GPS2. According to him, it wasn't a new system, not even new satellites. Instead it was a new way of sending signals, so that the receiver would be able to tell whether, and maybe even how, a signal had reflected on buildings or other obstacles, before reaching the receiver.

There is a wikipedia page "GPS2" that redirects to the GPS article, but no information on it here.

Does anyone know about this?

Velle (talk) 23:25, 24 March 2010 (UTC)

Perhaps you're thinking of GPS modernization, which is (according to that article) sometimes called GPS III, and involves the launch of so-called 'block 3' satellites? The GPS satellites have a designed life of 10 to 15 years, so as they gradually get replaced, new satellites are launched with some new capabilities, to get the benefits of technologies developed since the 1985 launch of the first GPS satellites. The new signals will be easier for receivers to track reliably, and they'll be broadcast alongside the existing signals so older receivers will keep on working. For more information, see GPS modernization.
Block 1 GPS satellites were the demonstration satellites launched in the 1970s and early 1980s prior to the launch of the main GPS constellation; Block 2 satellites are the current main satellites; Block 3 satellites are the modernised satellites with new signals. I've never heard the expression "GPS 2" used before, but perhaps it would refer to the block 2 satellites, i.e. the satellites currently in operation, while "GPS 1" would refer to the block 1 satellites? Mike1024 (t/c) 09:20, 25 March 2010 (UTC)

Iteration using Trilateraton



Note 1.


In the trilateration / gps article this algoritm is described.


What root finding algorithm was used? RHB100 (talk) 21:17, 12 April 2010 (UTC)




A trilateration point is calculated. (Trilat point TP X,Y,Z)
The distance to the fourth satellite (X4,Y4,Z4) R4 is calculated.
R4= SQRT( (X - X4)^2 + (Y - Y4)^2 + (Z - Z4)^2 )
P4 is the measured pseudorange to the fourth satellite.
DA = R4 - P4 This is supposidly used for the clock correction.



Note 2.
All numbers are represented in meters except for da/c which is meters/(meters/sec) = seconds.
The trilateraton points can easely be verified by recalculating the distance to the satellites,
this will give the exact measured pseudoranges.
R4 can easely be verified by recalculationg the distance from the trilateration point to the fourth satellite.
P4 is the measured pseudorange distance to the satellite which is used as the fourth satellite.
DA and DA/c can easely be calculated.


The Example. The satellite constellation is from an example on the web. Satellite (SV) coordinates in ECEF XYZ Ephemeris Parameters and SV time for satellites SV15 SV27 SV7 and SV31.

The example

Satellites and measured pseudoranges
Sat X Y Z P
1 15524471.18 -16649826.22 13512272.39 22262088.18
2 -2304058.534 -23287906.47 11917038.11 19908187.05
3 -14799931.4 -21425358.24 6069947.224 21479180.58
4 16680243.36 -3069625.561 20378551.05 24554242.17


The above constellation is used four times, each time a different satellite is used as the fourth satellite. Three satellites are used to calculate the trilateration point X,Y,Z. The fourth satellite is used to calculate the distance (R4) from the trilateration point to the 4th sphere.

Diagram depicting satellite 4, sphere, p4, r4, and da


Use 1/2/3 for trilaterationpoint use 4 as fourth satellite
X Y Z r4 p4 da da/c
-734005.2869 -5442255.690 3233513.890 24552753.99 24554242.17 -1488.179383 -4.96403E-06

X, Y, and Z as used above and below are first estimates of receiver position based on intersection of sphere surfaces. RHB100 (talk) 20:20, 14 April 2010 (UTC)

Use 1/2/4 for trilaterationpoint use 3 as fourth satellite
X Y Z r4 p4 da da/c
-733247.0627 -5443641.024 3230804.528 21479004.27 21479180.58 -176.3092095 -5.88104E-07


Use 1/3/4 for trilaterationpoint use 2 as fourth satellite
X Y Z r4 p4 da da/c
-733092.4407 -5443569.809 3230637.652 19908335.89 19908187.05 +148.8429348 4.96487E-07


Use 2/3/4 for trilaterationpoint use 1 as fourth satellite
X Y Z r4 p4 da da/c
-732774.6495 -5443898.772 3230360.492 22261818.53 22262088.18 -269.6591897 -8.99486E-07


The corrections are shown in Red. (-1488.179383, -176.3092095, +148.8429348, -269.6591897)


Off the above numbers only two of the corrections converge towards a solution, two others diverge from a solution. The example shows that the calculated corrections can be in the wrong direction (plus and minus) and the corrections do vary in 'size'. Because the direction of the error and the size of the error is unknown, a correction can not be evaluated to being correct or not. This example shows that iteration using trilateration using the algoritme as given in both articles can not work.

You should not have used da/c. You should have used, the correction from one of the root finding methods in Numerical Recipes. RHB100 (talk) 20:38, 13 April 2010 (UTC)

It is a regrettable that the author(s) of these parts of the articles have not checked for this.

This is not the only problem for this supposed method of positional calculation.

Conclusion:
Iterating using trilateration as described in the article and in the trilateration article is not suitable for positional calculations.


There is no description of the iterative algorithm using trilateration to use in the GPS article. Therefore your conclusion refers to something which does not exist. Most important, there is no description of the function of da for choosing the value of b for the next iteration. Reference is made to the chapter on root finding in the book on Numerical Recipes but the choice of which root finding method to use is the responsibility of the algorithm developer. I have not found any statement of what root finding method you used. If you simply used da/c to estimate the time correction, it is not at all surprising that your algorithm did not converge. You need to thoroughly understand the chapter on root finding in numerical recipes. RHB100 (talk) 21:17, 12 April 2010 (UTC)



Crazy Software Productions (talk) 12:02, 7 April 2010 (UTC)

If this is not original research and if it can be properly sourced (with preferably secondary sources), perhaps you can incorporate it into the article. DVdm (talk) 12:09, 7 April 2010 (UTC)
The article mentions trilateration eleven times and discusses solving for position and clock offset separately - but I can't see a citation supporting that. For example, where article says "The receiver can solve by trilateration followed by one dimensional numerical root finding. [48]" citing Numerical Recipes - but google book search tells me that numerical recipes does not contain the word "trilateration" or "GPS" - in other words, that citation doesn't really seem to support the assertion that trilateration is used for GPS positioning. Does anyone know where all this stuff about trilateration is sourced from? Mike1024 (t/c) 16:06, 7 April 2010 (UTC)

Well you should certainly not expect any search of Numerical Recipes or any other book on numerical analysis to contain the word trilateration since trilateration is not a numerical technique. However, you should recognize that finding the value of b which drives da to zero (i.e. finding the clock correction which causes 4 satellite surfaces to intersect) is a root finding problem. Therefore you should search Numerical Recipes for "root finding". RHB100 (talk) 02:05, 13 April 2010 (UTC)

Soure data of the example, the constellation given on:
http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html
On the page : Pseudo-Range Navigation Solution
The timing error is made up, the pseudoranges are calculated, from the distances and the timing error.
The picture is taken from the main article.
The algoritm is implemented as described in the GPS, trilateration articles.

All tekst, building the algoritm and the calculations is original. Therefore there is no source. Because there is no source, the 'proof' is selfcontained, it can easily be verified. There is no need to calculate where the three spheres intersect, you can just verify that the calculated point is on all three spheres. (Use Phytagoras for that.) And therefore the calculated point is the same as the trilateration point. R4 can also be calculated (also with Phytagoras). Calculating the correction then is easy calculate DA (and DA/c), which is supposed to be used as the correction for the clock.
The resulting factor DA is the correction for the clock (in meters) or DA/c (in seconds) is the correction for the clock. Because DA varies in sign and in size, it can not be that all values converge to a solution. So some of the anwsers will diverge from the solution.
Trilateration has some further flaws.


So the remark I added:
Regrettabilly this does not work, in a single constellation, one can get four different value's for da, depending on which satellite is used as the fourth satellite. Some of the values will converge towards a solution some of the values will not. See the discussion page for an example where the calculated DA values do not converge towards a solution.,
is correct and can therefore be part of the article.
I'll await a reaction, but am considering to reinstate the remark. I realy do not think the complete proof of something NOT working should be in a main article.


For a level playing field I expect the text about trilateration to be threated with the same rules as the removed text.
Crazy Software Productions (talk) 21:28, 7 April 2010 (UTC)

I don't think that such a paragraph will survive. It sounds highly unencyclopedic. Perhaps you can find a way put things right by either (1) challenging the part that is wrong (or unsourced) with {{cn}} tags, or (2) by correcting the erroneous text, with sources. DVdm (talk) 21:40, 7 April 2010 (UTC)
Added some citation needed tags - I don't know how the article came to contain so many mentions of trilateration; surely traditional trilateration surveys use round-trip-time electronic distance measurement, and so don't have to worry about receiver clock biases? Mike1024 (t/c) 09:35, 8 April 2010 (UTC)
If you get such wildly different da values for each fourth satellite, why not just average them out? -- Denelson83 02:57, 8 April 2010 (UTC)
If you've got a system with four equations (i.e. four pseudoranges) and four unknowns (position in x, y, and z, and receiver clock bias) the system is precisely determined - there should be no errors to average out. Allow me to demonstrate!
Satellites and measured pseudoranges
Sat ECEF X (m) ECEF Y (m) ECEF Z (m) Pseudorange (m)
1 15524471.18 -16649826.22 13512272.39 22262088.18
2 -2304058.534 -23287906.47 11917038.11 19908187.05
3 -14799931.4 -21425358.24 6069947.224 21479180.58
4 16680243.36 -3069625.561 20378551.05 24554242.17
Receiver position and clock bias
ECEF X (m) ECEF Y (m) ECEF Z (m) Clock Bias (m)
-733185.996310 -5443791.999681 3231192.995208 -299.991910

We can calculate the Euclidean distance from the x,y,z positions of the rover and satellites - Let's call that the true range.

Residuals using that solution
Sat Pseudorange (m) True Range (m) True range - Clock Bias (m) Error (m)
1 22262088.18 22261788.188090 22262088.180000 0.000000
2 19908187.05 19907887.058090 19908187.050000 0.000000
3 21479180.58 21478880.588090 21479180.580000 0.000000
4 24554242.17 24553942.178090 24554242.170000 0.000000
In other words: With 4 measurements and 4 unknowns, a solution is available with no error - so there's no point in averaging errors out! Mike1024 (t/c) 11:48, 8 April 2010 (UTC)


In reaction to Denelson83 why not just average them out?
My point is to show that iteration with trilateration as described in te mentioned articles is seriously flawed, it is not my intention to improve the algoritm and therefore obscure the flaws. Yes it might be possible to improve by taking the average. Or using the two middle values and averaging them. Both methods actually do improve this example, and maybe more constellations will be improved by them, but there is no prove (not even plausibility) that this will improve all situations where there is non-convergence. So to implement such a 'average' only obscures the 'errors' in the method. But as said I am trying to show that the suggested algoritm is not tested sufficiently and therefore it is very unlikely that this is the method used for positioning.
(The pseudorange calculation method is wel researched, does not contain this flaw and neither does it contain the flaws suggested in the article, and is probably the basis where most positioning calculation systems are based on.).


My reaction to Mike
Thanks for the support.
Question how did you obtain your results?
I had some trouble in replicating your results (in Excel), but this was to the fact that the numbers published above where not exactly the same as the numbers I had used. So using the exact numbers of above I could replicate your result starting of with a first estimate of the centre of the earth within four iterations you get a sub centimeter result, to replicate to your accuracy I needed five iterations, that is also the limit with the amount of digits the calculation is done. Although by the fifth iteration the calculation is accurate to abouth 7 digits after the decimal point, this is still an approximation. In normal circumstances the previous position can be used and one itration will be more than sufficient for all practical purposes.
Receivers estimated position. (pseudorange calculation)
ECEF X (m) ECEF Y (m) ECEF Z (m) Clock Bias (m) Comment
0 0 0 unknown First estimate, centre of the earth.
-1045082.2047576 -6564007.3980417 4496846.2500250 1600116.3413396 One iteration
-755836.507944 -5489986.462656 3326348.039697 95944.331654 Two iterations
-733256.0797 -5443899.222 3231500.767 649.7511078 Three iterations
-733185.9969 -5443792 3231192.998 299.9950171 Four iterations
-733185.996310 -5443791.999681 3231192.995208 299.991910 Five iterations

Crazy Software Productions (talk) 22:40, 8 April 2010 (UTC)

Question how did you obtain your results?
I used the technique outlined by Bancroft in "An Algebraic Solution of the GPS Equations" - more information available in this assignment sheet. It does not require iteration, but it's unintuitive; IMHO it's complicated enough to be beyond the scope of an encyclopaedia article.
Although by the fifth iteration the calculation is accurate to about 7 digits after the decimal point, this is still an approximation.
Most calculations end up being performed using 64-bit floating point numbers where the fraction is 52 bits long. You can see some doubles in binary format using " this applet. The practical implication of this is: there is a one-bit difference between 22262088.180000000 and 22262088.180000003 meaning smaller additions get lost due to rounding error. Use almost any calculator to calculate 22262088.18 + 0.00000005 - 22262088.18 and see what you get! You can read more about this in "What Every Computer Scientist Should Know About Floating-Point Arithmetic".
It's possible to avoid this problem by using Arbitrary-precision arithmetic - where instead of 52 bits of precision, you can have as many bits as you can fit into memory. However, this tends to be slow, because modern processors have hardware-accelerated handling of 64-bit floating point numbers - but no hardware acceleration for arbitrary precision arithmetic. Applications like the Windows XP calculator use arbitrary precision arithmetic so it will get 22262088.18 + 0.00000005 - 22262088.18 right.
There's no point in using arbitrary-precision arithmetic for GPS (mostly) because a rounding error of 3 nanometres is much, much smaller than errors due to the ionosphere, measurement noise, ephemeris error, multipath, and so on. Mike1024 (t/c) 09:31, 9 April 2010 (UTC)

GPS article discusses but does not specify algorithm using trilateration

The conclusion, "Iterating using trilateration as described in the article and in the trilateration article is not suitable for positional calculations" made above is based on based on a non existent description.



There is no description of the iterative algorithm using trilateration to use in the GPS article. Therefore your conclusion refers to something which does not exist. Most important, there is no description of the function of da for choosing the value of b for the next iteration. Reference is made to the chapter on root finding in the book on Numerical Recipes but the choice of which root finding method to use is the responsibility of the algorithm developer. I have not found any statement of what root finding method you used. If you simply used da/c to estimate the time correction, it is not at all surprising that your algorithm did not converge. You need to thoroughly understand the chapter on root finding in numerical recipes. RHB100 (talk) 21:17, 12 April 2010 (UTC)


You say that that there is no description of choosing b for the next iteration. At the moment the article seems to contain a few different equations, examples of algorithms, and links to pages like Trilateration which contain other equations ("The article, trilateration, shows mathematically how the equation for this circle of intersection is determined."). Because of this, I think it's easy for a reader to become confused about how the calculations are performed.
Also I think because of this confusion, it is difficult for me to know whether the article is right or not; if there are calculations and I don't get the right answer when I perform them, does that mean the calculations are wrong, or that I have misunderstood them or missed steps out? Perhaps we should make the article clear, so that I do not misunderstand or miss steps out - and then when people perform the calculations and get the right answers it will be easy for them to be confident the article is correct!
I also think that if it isn't possible to present the calculations clearly and without steps missed out, then maybe instead of presenting the calculations unclearly and confusing people, we should refer them to a credible source where the calculations are made clear and aren't too confusing. What do you guys think? Mike1024 (t/c) 10:10, 20 April 2010 (UTC)
I am not convinced that a detailed algorithm is required in an encyclopedia article. The general principles upon which an algorithm may be developed is quite often more important. RHB100 (talk) 20:13, 22 April 2010 (UTC)
Surely even if you don't think a working algorithm would be appropriate for the article, you could post more detail to this talk page? For example, here's the code I used to perform the calculations above:
As I mentioned above, I used the technique outlined by Bancroft in "An Algebraic Solution of the GPS Equations", which is also explained in this assignment sheet. Would it trouble you too much to provide this much information on how the algorithm in the article works? This way we know there are no omitted steps! Mike1024 (t/c) 22:26, 22 April 2010 (UTC)

Mike1024, I will be happy to post more detailed information. I have now got a FORTRAN program written and the results indicate that it works for all 4 cases. It uses zbrac.f for finding a bracket and rtbis.f for finding the solution using the midpoint method from Numerical Recipes. It uses a routine called trilat.f that I wrote. I will try to further verify that the solution is correct and clean up the code before posting. I am glad to see that you posted that pdf document on the Bancroft method. RHB100 (talk) 22:03, 23 April 2010 (UTC)

Mike1024, I have placed code and results from using trilateration and one dimensional root finding in a separate section below. RHB100 (talk) 03:43, 24 April 2010 (UTC)

I think that anything that is not properly backed by secondary sources should be removed from the article. DVdm (talk) 10:18, 20 April 2010 (UTC)

The method involving trilateration is fully backed up by the many references to GPS and trilateration articles below shown below and the book on Numerical Recipes. RHB100 (talk) 20:13, 22 April 2010 (UTC)

Thumbnail sizes

Thumbnails, per guidelines, should not be sized; that way each browser / user can set their preferred default size, and if more clarify is needed they click on the image for the full size version. Currently, almost all the images were sized to similar to thumbnail size, and the two outliers are understandable at thumbnail size.

I goofed on the edit history; those should have been links to Wikipedia:Accessibility#Images and Wikipedia:IMGSIZE#Displayed_image_size - Davandron | Talk 02:20, 12 April 2010 (UTC)

Understandable at thumbnail size?
Understandable at thumbnail size?
How big have you set your thumbnails? Mine are 200px wide, which I think is the default(?) - I've forced these images to that size to ensure that we're all seeing the same thing, regardless of our settings - and I'm not sure I'd agree that these images are understandable at thumbnail size.
Is this animated?
Is this animated?
Also, I note that Image:ConstellationGPS.gif seems to lose its animation when scaled down. There seem to be periodic mediawiki changes that break/unbreak animated GIF scaling, which might be why it was scaled down in the first place - but can we agree that at present, scaling the image down breaks the animation? Mike1024 (t/c) 08:57, 12 April 2010 (UTC)

Excellent catch on the animation; it shouldn't be a thumbnail at all. Looks like this was already fixed. On the flow diagrams, perhaps they should be removed (style guide "Avoid entering textual information as images" and accessibility "Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who can't see the image can gain some understanding of the concept."). Alternatively, I believe they could be edited to increase clarity at smaller sizes, and marked-up as images at a designed size (note, from guide "An image should generally be no more than 500 pixels tall and 400 pixels"). Thoughts? - Davandron | Talk 16:13, 15 April 2010 (UTC)

The proper thumbnail size for these images is 300 px. This is fully allowed by Wikipedia. Also it is quite proper to use text in a diagram. Your quote from what you call the style guide has nothing to do with these diagrams. RHB100 (talk) 03:50, 17 April 2010 (UTC)

Articles relating GPS and Trilateration

There are many articles relating GPS and Trilateration as can be seen at GPS and Trilateration articles. Unfortunately most of these articles seemed to be dumbed down, they talk about circles instead of spheres as if the concept of a sphere were too difficult to comprehend.

One of the better articles in my opinion is "Position Determination with GPS".

It is not difficult to understand that there are so many such articles since one of the fundamental principles in GPS is the determination of location in part by determining the intersections of three spheres. Once the clock error has been approximately driven to zero so that four spheres intersect approximately, an estimate of position will have been obtained.

This is the reason why trilateration as a part of numerical root finding (i.e. finding the value of b which drives da to zero through an iterative process) is one of the two methods discussed in Position calculation, advanced.

The other method discussed is multidimensional root finding. This method does not involve the use of trilateration.

It should be kept in mind that these methods are discussed on the conceptual level. They are not descriptions of algorithms.

It should be kept in mind that there is noting to prevent someone with the capability from adding a description of the Bancroft method. I do not have access to the article on this method. RHB100 (talk) 01:46, 13 April 2010 (UTC)

Code and results from using trilateration and one dimensional root finding

There have been some who have expressed some doubt as to whether the method involving trilateration and one dimensional root finding as discussed in the GPS article would work. It is hoped that this section will clarify that misunderstanding by showing that this method certainly does work. The results of running a Fortran program which uses this method can be seen by clicking show on the bar labelled "Results from using trilateration and one dimensional root finding". Three of the routines that comprise the Fortran program can be seen by clicking show on the indicated bars below. Two of the subroutines, subroutines zbrac and rtbis, cannot be shown because they are protected by copyright. These subroutines can be found in the book on Numerical Recipes. The subroutine zbrac performs the task of finding a bracket for the solution given an initial guess. The subroutine rtbis performs the task of making a binary search to find a small enough bracket of the solution to meet the specified accuracy.

The results below show for each case the positions and psuedoranges of the three satellites which are used for trilateration and the one satellite which is not used for trilateration. The solution, the receiver position is then shown along with RBIAS which is the bias in dimensions of distance rather than time. RHB100 (talk) 21:14, 24 April 2010 (UTC)


The main routine reads in and writes out the data. A call to trilat and a function evaluation of dacomp help to provide initial estimates of a bounding bracket between BIAS1 and BIAS2. A call to zbrac modifies BIAS1 and BIAS2 if necessary to assure that the solution is bracketed. The subroutine rtbis returns with the solution, RGBIAS, which is the value of the argument of function dacomp required to cause the function to evaluate close enough to zero to satisfy the specified accuracy requirement.


The subroutine trilat computes any intersections of three surfaces given the sphere centers and radii as described in trilateration.


The function dacomp computes the closest distance from three surface intersections to the fourth sphere surface as a function of its argument, a range bias.


RHB100 (talk) 05:20, 24 April 2010 (UTC)

WP is not a discussion forum

The preceding section is running way out of hand, with even the publishing of written computer code. Wikipedia is not a discussion forum. If you want to explore your original research together, please find a more appropriate place. −Woodstone (talk) 05:09, 24 April 2010 (UTC)

This is a discussion page relevant to what goes into Wikipedia. The purpose of showing the code and results is to provide solid proof that the method involving trilateration and one dimensional root finding certainly does work. RHB100 (talk) 05:19, 24 April 2010 (UTC)
It is not considered acceptable evidence in WP. See the WP:OR. What you need is independent published sources that state that it is really used in that way. It is not enough that it would work. −Woodstone (talk) 05:48, 24 April 2010 (UTC)
But surely you agree that if it would not work, it would be incorrect, and should be removed; we are simply establishing that this is not the case, after Crazy Software Productions raised doubts. I agree with you that citations, not demonstrations, are needed for the main article; that's why the demonstrations are here on the talk page!
As to this discussion being original research, my code above links to a peer-reviewed IEEE paper with 149 citations, which contains (almost) the exact algorithm I posted; I only repeated it in case you don't have IEEE journal access. Perhaps I didn't make it clear that the algorithm was from that paper; would my actions really qualify as original research?
I agree that these discussions are making the talk page get a bit long - but talk pages can always be archived when discussions are over, right? Mike1024 (t/c) 12:14, 24 April 2010 (UTC)

There are links to trilateration and Numerical Recipes which are more than adequate to establish the validity of the method discussed in the GPS article. I merely used the methods in these more than adequate citations to clearly establish that the method worked since some did not seem to understand the methods. There were also expressions of interest in a detailed description of the algorithm. RHB100 (talk) 21:34, 24 April 2010 (UTC)

  1. ^ Cite error: The named reference NR was invoked but never defined (see the help page).