3
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ As far I know GPS uses only one channel for all sattelites. \$\endgroup\$ – Marko Buršič Dec 21 '15 at 10:37
  • \$\begingroup\$ @MarkoBuršič The answer to this question implies otherwise \$\endgroup\$ – Spectre208 Dec 21 '15 at 11:02
  • \$\begingroup\$ There is more than one understanding of "channel" ... the lnked Q/A says: "Background : All the satellites transmit on essentially the same frequency. They are technically walking all over each others' signals." which is what Marko means by single channel. \$\endgroup\$ – Brian Drummond Dec 21 '15 at 11:20
  • \$\begingroup\$ @Spectre208 Citing from answer linked: Each correlator is called a "channel" for the sake of marketing. So yes by channel I mean a single frequency with dedicated bandwidth, this is how GPS works. Read the linked answer again. \$\endgroup\$ – Marko Buršič Dec 21 '15 at 11:49
  • \$\begingroup\$ @MarkoBuršič You're right, I'm sorry. I misunderstood your comment there \$\endgroup\$ – Spectre208 Dec 21 '15 at 12:55
3
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Thanks, I missed out on the frequency space. The point is that my application only needs a single GPS fix every day. I was hoping to not be needing to power the RTC and memory. As for my application, getting the almanac actually isn't using little power. \$\endgroup\$ – Spectre208 Dec 21 '15 at 13:00
  • \$\begingroup\$ With 1 GPS measurement per day, not using the almanac may actually be interesting. But I'm afraid it might be hard to find a receiver optimized for your needs. Typical GPS receivers are made for continuous operation on moving appliances (satellites coming and going out of view all the time), so they rely on the almanac. \$\endgroup\$ – Dmitry Grigoryev Dec 21 '15 at 13:15
  • \$\begingroup\$ Typical modern GPS receivers really don't need the almanac. At best it might save a couple of seconds. \$\endgroup\$ – pericynthion Sep 30 '16 at 0:11
4
\$\begingroup\$

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

\$\endgroup\$
3
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Does the almanac contain only UTC offset or full UTC time? I find conflicting information on that, and maybe someone here knows better. I am talking about the almanac, subframe 4, not the "normal" gps signal. \$\endgroup\$ – TJJ Apr 10 at 12:33
  • 1
    \$\begingroup\$ @TJJ Do not mistake \$t_ot\$ (subframe 4 page 18) as current time, it is reference time for application of first order corrections \$ A_1 \$. If you do not count handover word HOW as part of the almanac, then there is no current time in almanac. HOW (sent in every subframe) gives time of week TOW truncated to multiples of 6 seconds, but you can infer missing precision down to spreading code timing (1/1,023,000 sec). And to tell the week, you need subframe 1. \$\endgroup\$ – Andreas Apr 10 at 19:54
  • 1
    \$\begingroup\$ @TJJ Reading your comment a second time, I think you are asking "offset vs full time". The answer to this is "offset only", GPS-time to UTC offset to be specific. And from the databits of almanac alone (not using the HOW), you cannot tell when it was sent (not in GPS-time and not in UTC). \$\endgroup\$ – Andreas Apr 10 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.