GNSS Ephemerides and Almanacs
GNSS almanacs and ephemerides both form the navigation message transmitted by each satellite. The navigation message consists of 5 subframes, where each frame is made up of 10 words and takes up 6 seconds to download. The navigation message frame structure is as follows:
subframes 1 -3: ephemerides
subframes 4-5: almanac --> full almanac requires 25 pages to completely download.
Thus one page of frames 1-5 takes 30 seconds to download. Since the almanac contains 25 pages, the total time required to download almanac is: 25 pages * 30 seconds/page = 750 seconds = 12.5 minutes. On the other hand, the ephemerides takes 6 seconds/subframe * 5 subframes = 30 seconds to download. Note that the almanac is the same for all satellites whereas the ephemeris is unique to each satellite.
What is the purpose of each one?
- contains information on week number, satellite accuracy and health, age of data, satellite clock correction coefficients, orbital parameters
- valid two hours before and two hours after time of ephemeris (toe). The toe can be thought of as when the data was computed from the GNSS control segment
- Used for real time satellite coordinate computation which is required in position computation
- contains less accurate orbital information than ephemerides
- valid for a period of up to 90 days
- Used to speed up time to first fix by 15 seconds (compared to not having almanac stored)
Thus, the receiver is capable of computing a position without having an almanac present. The almanac helps out with fixing the satellites for the first time but that is about it. The ephemerides however are vital for positioning computation.
The ephemerides are also used for post-processing as like was stated earlier, the ephemerides allow for the satellite position computation which is required in order to use trilateration to compute the receiver's position. Thus, it is very common for clients to log the ephemerides of each constellation they are tracking with the receiver. For brevity we will just refer to the GPS ephemeris from the RAWEPHEM message.We recommend clients to log this message with the ONCHANGED trigger. Here is why:
Scenario #1: LOG RAWEPHEMB ONNEW
i. GPS ephemeris for satellites currently in view (as well as those not in view but saved in NVM) will be output as soon as log command is sent.
ii. New RAWEPHEMB message will be output every 30 seconds as that is how long it takes for a frame to be received
iii. The consequence of this is logging more RAWEPHEMB messages than necessary thus using up baud rate which could be used for logging other messages
Scenario #2: LOG RAWEPHEMB ONCHANGED
i. GPS ephemeris for satellites currently in view (as well as those not in view but saved in NVM) will be output as soon as log command is sent
ii. New RAWPEHEMB message will show up every time a new satellite is tracked. This message only contains information on this new satellite
iii. No new RAWPHEMB message will show up if a satellite lock is dropped (i.e: moves below horizon).
iv. New RAWEPHEMB message will show up for each satellite once the broadcast ephemeris contains a different TOE