Re: [gpsd-dev] [PATCH 5/9] Define TTFF

[Gerry Creager - NOAA Affiliate]

Yo, Gary!

On Fri, Apr 17, 2015 at 2:17 PM, Gary E. Miller <address@hidden> wrote:

Yo Hal!

First off, best to be very specific about the Almanac and the Ephemeris.

They are different, but both are needed.  They are also send on different
timescales.  The Almanac is course, but is valid for weeks.  The Ephemeris
is accurate, but only valid for 30 mins.  Each sat only sends it
own Empemeris, but sends all Almanacs.

With only a few exceptions, there's only one active Almanac at any given time.

By way of explanation, think of the almanac and ephemeris as having the same basic data but different precision. While this isn't really correct, it's a good starting point. Once the almanac is received... fully... and assuming a good last-fix, the receiver can begin a sky-search for all available birds. Once it acquires one, it can get time, and that bird's ephemeris.

The onboard ephemeris is updated by SPACOM twice per day, minimum.

WIthout an almanac... any almanac, often including expired ones, the receiver cannot do more than open its correlator and attempt to snag onto a spreading signal with a recognizable Gold-code. Then it can start receiving data.

Almanac and ephemeris data are interleaved in the data transmission, which reduces the length of needed to get both the almanac and the first ephemeris.

I write a tool so gpsd can dump this data, but never got around to checking
it in.

On Fri, 17 Apr 2015 11:45:52 -0700
Hal Murray <address@hidden> wrote:

> > +<p>The time required for a GPS to get a fix (Time To First Fix
> > (TTFF)) +can vary from under 15 seconds up to just under 30 minutes
> > (actually, +29 plus calculation time).  The main factors affecting
> > this latency are +(a) whether it has an almanac available,
> > +(b) whether it has satellite ephemerides available, and
> > +(c) whether it has recent fix available.
> > +Of course the quality of signal at your location matters as
> > well.</p>
>
> Perhaps I don't understand what's going on, but I think it's
> misleading to claim something like a 29 minute upper limit.  I think
> that reasoning is based on 15 minutes for the whole cycle.

Not misleading at all.  29 minutes is pretty common.  Most GPS, less
so with modern ones, will wait for the start of the next 50bps cycle,
which could take 15mins minus a few seconds.  Then take 15 mins to grab
a whole cycle of he almanac.  Not to be confused with a full almanac
which can take hours.

Most of that time, on the single channel receivers, was devoted to rolling through the Gold-codes trying to lock with a satellite... any satellite. Also, should more than one be detected during cold-start on a single channel receiver, most of the ones I played with would then stay on the first satellite they captured and not multiplex, until they had the almanac and ephemeris from that bird. THEN, with an almanac, and an imprecise (but pretty good) idea of what satellites were overhead, they'd narrow the search and get all the satellites they could find, and their ephemerides.
 

The almanac tells the GPS rceiver which sats should be in view at
the current time.  This is important for old single channel receivers
to not waste time looking for a sat.

But to get the almanac, they had to do a sky search.
 

Modern multi channel receivers just try to listen to a bunch of sats at
once to try to grab their Ephemeris.

And almanac.
 

Most GPS cheat on their hot start times.  They assume it stored the
lat/lon of the last fix and has an approximmate time of day.  So can guess
which sats to try first.

A number of 'em also keep a copy of the last almanac and ephemeris around.
 

Ship a GPS from Shenszhen to Oregon and it often takes 15 to 30 mins
to locate.


> That assumes you can only hear one satellite and can hear it clearly
> for the whole time and that you have to start at the beginning of a
> cycle.

Sort of.  Each sat send its own ephemeris, and only its own ephemeris,
so you get the one matching the sat you are receiving.  To get all the
orbital parameters only takes about 30 seconds.

But without the almanac finding all the sats, and handing off as sats
move will be troublesome.

> The data is sent in chunks.  You have to collect them all.

Not really.  Some of the Almanac data is for weeks in the future, those are
not needed for a current fix.

Original interpretation of the Red Books was that the entire  almanac had to be stored. I believe it was Garmin who first decided that wasn't really necessary.

> With one satellite, you can start in the middle.  So the nasty case
> takes N+1 chunk slots rather than almost 2x the whole thing.

Assuming smart firmware, not guaranteed.

> All the satellites are sending the same data.

Nope.  Each sat send only it own ephemeris.  Each sat sends all the
almanacs.

>  If you can hear
> several satellites,  you can potentially reduce the collection time
> by the number of satellites.  (But that assumes you can find them
> which is hard without the data you are trying to collect.)

Nope, they pretty much all send the Almanac in lockstep.

> If you are unlucky, some noise will trash a chunk of data so you will
> have to go around again.  If you are really unlucky, it will trash
> the same chunk several times in a row.

Or you get Almanac part from one sat, and part from another.

> How long is a GPS satellite in view?  If I want to listen to one for
> 15 minutes, what are the chances it goes out of sight?

Easy to see, just stare at your GPS sky view for a bit.  The sats are
in vaying orbits

The GPS satellites are in 6 orbital planes, with a common period and inclination. The planes are equally spaced around the equator (60 degrees apart). And while we on it. with most of the geodetic post-processing code I've played with, if you observe too long, have a satellite (or several) go out of view, then reemerge, the reintroduction of the satellite, despite modelling using  the almanac and ephemeris, leads to instability that looks a lot like an orbital harmonic introduced to the baseline code; that's not pertinent to this discussion, though.

gerry

--

Gerry Creager

NSSL/CIMMS

405.325.6371

++++++++++++++++++++++

“Big whorls have little whorls,

That feed on their velocity; 

And little whorls have lesser whorls, 

And so on to viscosity.” 

Lewis Fry Richardson (1881-1953)