GPS Almanac versus Sky Search

Question

The total almanac data is transmitted in 25 navigation messages. Each navigation message takes at least 30 seconds to transmit. So, receiving the almanac data from the satellites takes at least 12.5 minutes, not taking Assisted GPS into account for the moment. If the signal was lost while receiving the message, the entire message has to be received again. This could double the time it takes to download the almanac data, depending on which navigation message is missing.

However, all the almanac data really does is give you a clue which satellites to look for. This information is not really worth the time and energy it needs when designing a low-power system. It requires you to keep track of the time, rough/last known location and almanac data.

Most GPS receivers nowadays include a lot of channels correlators, up to 256 from what I've seen. A satellite signal is repeated every millisecond and could be shifted by 1023 bits. Using a single channel per satellite, determining whether the satellite is in view or not could take one second, before it moves on to the next satellite. With 256 channels, determining whether the satellite is in view or not could only take 4 milliseconds.

Performing a sky search means that the receiver will process all the satellites and check if they are in view. This sounds more logical to me than downloading the almanac data to determine which satellite to look for. With as many as 256 channels, it would theoretically only take 100 milliseconds to know which satellites are in view and needs their ephemeris data downloaded from.

So the question here is: is downloading the almanac really necessary? Would it be better to skip downloading the almanac data when the amount of available energy is low? Especially when you want to avoid the need of having a RTC etc.

---

Edit:

I made a wrong assumption about the satellite signal decoding attempts, as pointed out by Dmitry.

However, the question remains if it would be feasible to ignore the almanac data. For instance, the datasheet of the Maestro A2035-H GPS module states that it has over 400,000 correlators. It consumes 40 mA while searching for visible satellites and 29 mA while tracking (getting the ephemeris data and calculating the position). It only takes 35 seconds to acquire a fix with a cold start, without a recent almanac or time and position estimate.

To me, it seems like it ignores the almanac like I suggested. Has the almanac still any use?

Answer 1

There are several points highlighted in Wikipedia article about GPS signals acquisition:

• Only satellites with a clear line of sight can be acquired without the almanac. Satellites visible via reflections cannot be used.
• Far more that 1023 decoding attempts are required to detect a signal from a single satellite (Wikipedia gives two estimations: 40,920 and 104,346 assessments, depending on the method used).
• Once one satellite is found, getting the almanac from it requires little power since you only have to run a single channel. Running 256 channels in parallel will require 256 times more power.

In the end, there may be situations when you can do without an almanac. If your device is stationary and no obstacles are around to block the view, you may be able to find satellites directly. Whether this will save you some energy will depend on how much your memory and RTC will consume vs running 256 channels in parallel, and how often you will use the GPS receiver.

Answer 2

Most receivers these days work very well without the almanac. Except in very weak signal conditions (or very strong interference conditions) they can typically acquire and start tracking all satellites in view within a small handful of seconds from a cold start, i.e. without any prior information on the receiver's position and time and without any almanac or ephemeris data. This rapid acquisition may be with the aid of many traditional hardware correlators working in parallel, extended "multi-tap" hardware correlators, or FFT techniques** that allow the entire code phase space to be searched simultaneously.

Time To First Fix is then dominated by the time it takes to receive sufficient navigation message frames to put together the satellite ephemerides. This can vary from 18 to 36 seconds depending on where in the broadcast cycle the receiver happened to be turned on.

Andreas makes good points about the solution quality improving after waiting for the ionosphere and UTC correction data.

For your application that needs a single daily fix and is very energy sensitive - in case you don't actually need to use the position/velocity/time information in the embedded device, but merely need to log it and be able to determine the P/V/T later, you can use a very low hardware footprint, low power technique that simply records a few milliseconds of RF baseband data (about 50 kB worth) for offline postprocessing. This expired patent outlines the principles, and I have published open-source code to perform the postprocessing, though it is not well documented for new users. I could probably be persuaded to tidy it up and write better docs.

** I have no idea why the this paper was considered publishable, it is has been a well-known technique for years, but this is at least a conveniently linkable explanation

Answer 3

A receiver can do without using data from subframes 4 and 5 of the navigation message (Almanac, Iono, UTC offset, health flags, message correction, text messages). It can also do without non-volatile memory and real-time-clock. These simplifications will degrade the performance in several ways:

1. If Almanac, last known position or current time estimate are not available, the receiver has to do cold acquisition on power up. It will take more time to get an initial fix.
2. If Almanac data is not used, the receiver will have no clue when to search for spacecraft that rise above the horizon. It will have to use more of its correlators to search for new signals all the time.
3. Not using ionospheric correction will deteriorate the positioning precision.
4. Not using the UTC-data means the receiver only knows GPS-time (which differs from UTC for severals seconds and does not have leap seconds)
5. Health flags and correction table are ways do deal with spacecraft malfunctions. Not decoding them means the system is less robust.

Downloading this data is not an active process. The receiver has to keep synch on the bit boundaries and framing anyway. So you get the bits for free. Decoding the data is computationally cheap compared to the processing that is needed to track the signal. It will not do much difference with respect to energy efficiency. The impact on firmware code size is however notable, getting everything correct needs quite a few lines of code.

Once the almanac is complete, the receiver only needs to monitor the 8 bit TOA-field, which is guaranteed to change for each new version. New data typically becomes available every 24 hours (this interval is not fixed).

The receiver does not have to start over if reception is shaky. All satellites transmit the same Almanac synchronously (which is not optimal IMHO). Partial Almanac data can be used. Receivers will typically use the latest available data for each subpage, which can be a mix of several almanac versions.