Talk:GPS signals

Creation of Article

I know its still rough, but I thought it best to get this out into the main Wikipedia instead of my sandbox, so that people can start using it and improving it. - Davandron | Talk 23:20, 14 March 2007 (UTC)

Almanac downloading

I recently reverted some text that User:Denelson83 had added concerning how long is required to download the GPS almanac from the space vehicles. The edit was a logical thought based on observations, but missed a detail. The satellite does not use the almanac to obtain a fix; the data contained in it is far too coarse. All it does is help the receive narrow the search of possible satellites that it could be receiving. The ephemeris data, which is received within 30 seconds of locking onto a signal, is extremely precise and is what enables the position fix.

Some quick math for an example:
If a 12-channel receiver has no idea about which satellites are in the sky above it and begins a cold search, where it requires 45-seconds to check each of the possible 32 PRN numbers to confirm if there is a bird there, how long to scan for all possible signals? 32 / 12 × 45 seconds = 135 seconds (just over 2 minutes). With 9 or 10 birds in the sky over most of the world at any given time, the odds are good that it will find at least one bird in the first 45 seconds, and very good that it will find 3 or 4 within 90 seconds. Once its locked onto a signal, the receiver get the ephemeris data within 30 seconds, and once that happens it can calculate its first fix. The almanac's purpose was for when receivers were 5-channel affairs and took a long time to lock onto the signal (a situation where the math would get much worse... 27 PRNs / 5 channels × minutes per search = 10 to 30 minutes total).

Now, if a receiver has a relatively recent almanac, and a good guess of the time and location of the receiver, the first search will be an educated search and has a good chance of hitting multiple PRNs on the first attempt, thereby reducing the time to obtain the first fix. So here is a logical extension; if you have a 32-channel receiver and there are 32 or less PRNs, do you need an almanac? ;^)

Oh, I should note that Denelson83's original thought about it taking less than 12 minutes since the almanac pages could be spread out might be true, however I have never found confirmation in the design data about almanac page spacing. I think the only way would be to confirm would be to decode the raw bit stream. If anyone finds the confirmation we can put it back in, but I hope the above shows why its an academic bit of info and not really practical today. - Davandron | Talk 04:40, 1 September 2007 (UTC)

Ah, now I understand.

However, sometimes it takes more than 30 seconds to get a full ephemeris, because the satellite signal you're getting is too weak. You need a loud-and-clear satellite signal (and by loud-and-clear, I mean -160 dBW as opposed to something like -250 dBW) to get a full ephemeris in less than a minute. And I speak from experience this time. --  Denelson83  06:25, 1 September 2007 (UTC)

True; I believe most newer receivers require a signal of better than -145 dBm (-175 dBW) to lock onto and download ephemeris data. Fortunately the average signal strength on the surface of the earth is about -126 dBm, but a weak signal will always cause problems.

Since a satellite's signal can't be used until the ephemeris data is downloaded, I believe most receivers show a "hollow bar" on a satellite signal which they are receiving but do not yet have valid data (hollow bars generally indicate that the signal is not being used for any number of other reasons as well).

As a side note, the 30 seconds worst-case scenario for ephemeris is why one does not see "time to first fix - cold start" values better than 35 or 45 seconds. In contrast, Assisted-GPS receivers, which obtain the ephemeris from somewhere other than the satellites, often have cold fix times between 1 and 10 seconds. - Davandron | Talk 04:53, 2 September 2007 (UTC)

Removal of "stronger signal equals faster fix."

Denelson83, I'm concerned about the following addition:

The stronger the received signal from a given satellite, the faster the ephemeris for that satellite is completely acquired and its position calculated.

Perhaps I'm misunderstanding it, but this claim appears either strongly obvious ("the signal must be strong enough to be received, otherwise it doesn't work") or is non-obvious and needs a citation ("stronger signals decrease download time"). Can you illuminate what you meant by it? - Davandron | Talk 03:21, 4 September 2007 (UTC)

What I meant to say was "The stronger the received signal from a given satellite, the faster the ephemeris for that satellite is completely acquired and the satellite's position calculated." I just didn't want to write the word "satellite" too many times.

Also, if you're looking for a citation, see the following statement from http://www.navsync.com/notes2.html:

if the receiver itself has high sensitivity then the receiver can cold start and provide a positional fix even with satellite signal levels lower than that required to cold start in the normal satellite acquisition process (this is largely because download of ephemeris data from the satellites normally requires reasonably strong signal levels of around at least –130dBm).

--  Denelson83  06:42, 9 September 2007 (UTC)

OK, so lets change the text to what they are saying "a more sensitive receiver will potentially acquire the ephemeris data quicker than a less sensitive receiver, especially in a noisy environment." Personally, I feel when it is phrased this way it is an obvious statement and doesn't require citation but as always am open to thoughts on the matter. - Davandron | Talk 20:12, 9 September 2007 (UTC)

On second thought; no, I don't feel this is appropriate for a section discussing what the navigation message is; I've proposed an edit clarifying that the data is needed. If you really really want the faster part, I'd say it belongs somewhere other than this section (perhaps in the GPS article itself). - Davandron | Talk 20:52, 9 September 2007 (UTC)

Fair enough. I've put that statement into the Global Positioning System article proper. --  Denelson83  01:54, 10 September 2007 (UTC)

You know, my experience indicates that to get an ephemeris from a satellite, a GPS receiver needs to be getting a continuous, strong-enough signal from the satellite for the entire time that it is transmitting its ephemeris. If during the ephemeris transmission, the signal fades below a certain threshold, the ephemeris information received up to that point loses its integrity, and the receiver has to start downloading the ephemeris again the next time the satellite transmits it. --  Denelson83  23:17, 15 October 2007 (UTC)

Explain the lenghts of code and the frequency's involved

The article is a little uneven, there are highly technical parts that offer no explaination. I would like there to be a layman's explaination on code frequency and why certain codes are certain lengths, etc. That would improve the article immensly.

Also there are many diagrams out there that could help as visual aids for those of us who learn in that method.

(Gracias from Tejas) 129.107.27.230 23:26, 20 September 2007 (UTC)

Hmm... I think I see what you are talking about. But should GPS Signals cover the "basics" that are on the gps article? I guess it should, since its the main article concerning signals... I'll pull over the basic copy from the gps article and it can be worked in.

BTW, if you know of any diagrams that can be legally used here, please link them! - Davandron | Talk 03:00, 21 September 2007 (UTC)

Definitions for Almanac and Ephemeris

How to incorporate these, as there are numerous articles that need a link to good definitions of these concepts? The descriptions in this article would suffice, however without any headings, there's too much text to read to make linking to this article feasible, and the original author of the article opposes any sub-headings. —Preceding unsigned comment added by 58.179.10.41 (talk) 12:43, 30 September 2007 (UTC)

I'm opposed in this case as the subject matter under each heading ended up being only one or two sentences. It seems it would be better to link to a section of two or three paragraphs that explain, in context, what those two concepts are. - Davandron | Talk 14:53, 30 September 2007 (UTC)

Contradiction re: Almanac

In this article, it is claimed the almanac takes 12.5 minutes to transmit. In Global Positioning System, it says, "Time to collect the complete almanac is 30 seconds for each satellite that is present in the constellation (for example, 24 satellites would take 12 minutes)." Only one of these statements is correct. Which is it? --  Denelson83  05:47, 20 December 2007 (UTC)

The correct figure is 25 frames (12.5 minutes) for the whole almanac (it's not per satellite). Reference page 103 of spec IS-GPS-200D. I'll fix it and remove the tag... LouScheffer (talk) 06:45, 20 December 2007 (UTC)

MNAV Navigation message - packeted vs framed?

GPS signals states that "..this new MNAV is packeted instead of framed, allowing for very flexible data payloads. ". It isn't clear to me that there is any fundamental difference between a packet and a frame (when these terms are used in the generic sense). Maybe the statement being made is comparing fixed-length frames with variable-length packets - in which case I can see the advantage. Should this be so, then it would help if this were explicitly stated. Maybe someone in the know can clarify.

P.S There seems to be alot of duplication of information at GPS Peartree85 (talk) 07:31, 27 May 2009 (UTC)

Ref needed for codeless approaches to tracking P(Y)

Can we get a reference for the following paragraph:

The details of the W-code are kept secret, but it is known that it is applied to the P-code at approximately 500 kHz, which is a slower rate than that of the P-code itself by a factor of approximately 20. This has allowed companies to develop semi-codeless approaches for tracking the P(Y) signal, without knowledge of the W-code itself.

68.35.69.60 (talk) 12:31, 18 August 2009 (UTC)

This is a research paper describing codeless and semi-codeless P(Y) acquisition techniques for GPS spoofing detection. This does not verify that "companies" have developed semi-codeless approaches, but it's something: http://web.mae.cornell.edu/psiaki/Paper_E4_8_ION_GNSS_2010.pdf 130.126.139.230 (talk) 21:13, 13 December 2011 (UTC)

Proposed merger

The Global Positioning System article currently has a good bit of content on the signals that this one doesn't. I am proposing merging that additional content into this article with the eventual goal of reducing the size of the GPS article (it is currently far in excess of recommended size guidelines). Since the content here overlaps substantially with that article this obviously means making choices about which version of the content on specific items to keep.

As I have not been a contributor to either until very recently I wanted to put this up for discussion here. Please feel free to volunteer to be the one to do the merging.

--Mcorazao (talk) 18:45, 6 June 2010 (UTC)

I've taken a stab at merging into this article. It still needs a lot of work ... --Mcorazao (talk) 15:08, 9 June 2010 (UTC)

Rise in position uncertainty for L2C

Under L2C Frequency information, there's a claim that navigating on L2C only gives you 65% more position uncertainty. The reference sends you to IS-GPS-200D. I've looked through both Revision D and E, and could not find anything relating to that. Anyone know where the claim comes from? And in case it has no basis, we should probably remove it.

DemonBeaver (talk) 09:47, 11 June 2012 (UTC)

I can't fathom where this claim would come from; it certainly is not factually correct as the position uncertainty is going to be based much, much more on other factors like the quality of the receiver, the receiving environment, and the methods used for positioning. This should be removed. siafu (talk) 16:13, 11 June 2012 (UTC)

It comes from the fact that the L2 ionospheric delay is 65% larger than the delay at L1, due to the ratio of their squared frequencies, or 154^2/120^2. If you use single frequency, you have to eat the error in the iono alpha-beta model. The errors are 65% larger at L2 than at L1. Pqmos (talk) 22:09, 10 July 2014 (UTC)

Article Lead

The article lead is redundant and doesn't adequately summarize the article. The second paragraph, for example, would read better as part of the section on the actual types of signals. If there is to be a second paragraph, then it should contribute to the summary of the article.Jodayagi (talk) 21:17, 22 May 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on GPS signals. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20141107091706/http://www.u-blox.com:80/images/stories/Resources/gps_compendiumgps-x-02007.pdf to http://www.u-blox.com/images/stories/Resources/gps_compendiumgps-x-02007.pdf
• Added archive https://web.archive.org/web/20120908003700/http://www.losangeles.af.mil/shared/media/document/AFD-070803-059.pdf to http://www.losangeles.af.mil/shared/media/document/AFD-070803-059.pdf
• Added {{dead link}} tag to http://www.kowoma.de/en/gps/signals.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:02, 2 January 2017 (UTC)

Plain Vocabulary

The article may be improved by explaining technical jargon, such as the acronymonious CNAV and MNAV. Is one a civilian navigation message format and the other a military message. — Preceding unsigned comment added by 144.183.224.2 (talk) 22:48, 3 February 2017 (UTC)

Time to archive old discussions

Discussions going back to 2007 and up to 2013 should be archived. If nobody else does it and nobody objects, I'll do it soon. Thanks! Damotclese (talk) 01:24, 6 December 2017 (UTC)