GPS: How NTP time injection works

Question

I've recently known about a gps.conf file in the /system/etc/ directory. Seems that tweaking NTP_SERVER values to NTP servers nearer to the usual location improves TTFF.

Reading the source code in the LocationProvider class, seems that at boot, time is retrieved from NTP server and "injected" in the calculations. AFAIK each GPS sat has a very accurate atomic clock, and every one in the constellation is synchronized to the so called "GPS time". Once the receiver has got 4 or more satellites, it solves (by some method) an equation where there are four unknowns: x,y,z,b; where (x,y,z) is the receiver location, and b is the time difference between the receiver internal clock and the (correct) GPS time. Once it has a a fix, the receiver clock is synced with the correct time. (Please correct me if I'm wrong).

So far, I've some questions regarding the way NTP time injection works:

1. GPS Time is roughly TAI (International Atomic Time) plus an offset. Those two times do not depend on the Earth rotation, however UTC does. Given that NTP servers return UTC time, it is possible to infer GPS Time from UTC time?
2. How does retrieving NTP time from a nearer server improve the "quality" of the GPS time approximation?
3. Assuming that we have an initial GPS Time value (inferred from NTP time somehow), what is the injection about? Is this time value taken as correct to solve the equation with only x,y,z as unknowns? If so, then the first fix is also just an approximation, isn't it?
4. How does a higher quality initial approximation for GPS time improve TTFF? Is it because with a lower quality NTP time the first fixes are considered not acceptable and discarded?
5. Does having an approximate initial position help retrieving the next correct fix (like listening only to a subset of sats)?

Answer 1

Well scouting a bit of wikipedia and some other sources, let me have a few guessses.

1. Yes, you can infer GPS time from UTC time. You just have to know the offset, which is transmitted every 15 seconds and changes once in approximately 18 months. Source: Wikipedia

2. NTP does not give you exact time. It measures the time message gets from client to server and the time the response gets from server to client. These times are then used to calculate the delay of the connection. Which is then applied as an offset to received time. This works for symmetrical routes. If the routes are assymetrical, there is an error. So closer the server, lower the the chance and level of assymetry, thus lower the error. Source: Wikipedia again

3. NTP signal is not directly used to obtain the GPS fix. But for an accurate fix you need very accurate clocks. We're talking nanoseconds here. GPS satellites do transmit current GPS time, but even as it travels at speed of light, there is some delay. GPS receiver has no way to know what the delay is, so it has to approximate from several received signals. With every transmission received the clock get more precise. So the better time you have at the beginning, the less time signals you have to receive to have an accurate clock. Source: Wikipedia

4. Well pretty much explained in 3. - the lower clock error the less signals needed to approximate the correct time.

5. I'm little guessing here, but having approximate location can help you better approximate the distance from satellite and thus the delay. (Not sure if that is really used.)

I hope it makes at least a little sense ;-)

Answer 2

My answer will focus more on the NTP side of your question. For GPS, I have studied this PDF paper mentioned in a comment by mirabilos.

According to that document, for warm start of GPS receiver, you need to know time within 20s, position within 100km, velocity within 25 m/s and almanac data at most few weeks old. You still need to download ephemiride data from each satellite, which takes between 30 seconds to 3 minutes based on the GPS receiver type.

For hot start, you need also the ephemeride data (they are valid for 4 hours). They are also available via A-GPS (see below).

NTP protocol uses a hierarchy of servers starting with the original time source - GPS, atomic clock, ... This is called stratum-0 source. NTP server directly connected to this source is called stratum-1. Server using this as its upstream server is stratum-2 and so on. You need special tuned hardware to achieve less than 1 ms error even for stratum-1 servers (due to CPU interrupt latencies, serial port latencies, temperature oscillator changes).

With normal HW on normal network (not saturated DSL link for example) you can achieve about 10 ms accuracy. For example NTP pool considers its servers valid and good enough if they have time precise within 100 ms. The accuracy of time from NTP does not depend on geographical position between you and NTP server, but more on the stratum, quality of that server and how far the server is based on the network topology.

Android phones usually know the time within at least 1 second accuracy. Either via periodic time synchronization via GSM network or if data connection (wifi or cellular) is available, also via NTP.

For the mentioned application FasterGPS - changing your NTP server to better one will not help you to have faster TTFF. For that you would need to have time with precision within nanoseconds, which is not possible via NTP. Only the GPS chip itself is able to keep track of time with that precision. What helps on android to have faster TTFF is:

• You already have good time within 20s on your android phone
• Having approximate possition either via Wifi or from GSM network (within few km based on transmission towers)
• Using A-GPS - it downloads fresh copy of almanac and ephemerides for all GPS satellites via internet, so you don't need to download it from the GPS satellites (which takes 30 sec for ephemerides and 15 minutes for almanac). With A-GPS, you can use hot start and have TTFF under 10 seconds.

Answer 3

Ian is right in his comment that the answers have to do with how a GPS receiver actually works. The receiver will more quickly come to a solution if it has a more accurate estimate of the receiver clock bias. Many receivers implement an iterative solution that relies on an initial estimate of the receiver's position and clock bias. If these estimates are already close to the true value, then less iterations will be needed. This is only part of the reason that TTFF will be less. There are other important factors as well. If the initial position and time estimate are good, then the search process for acquiring the satellite signals will take significantly less time because the receiver can calculate which satellites should be visible and it can also estimate the approximate Doppler shift experienced by each of the signals relative to the receiver's reference frame.