gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary E. Miller
Subject: Re: [gpsd-dev] [PATCH 5/9] Define TTFF
Date: Fri, 17 Apr 2015 13:21:05 -0700

Yo Gerry!

On Fri, 17 Apr 2015 14:58:20 -0500
Gerry Creager - NOAA Affiliate <address@hidden> wrote:

> 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.

Yes, but, people forget the Almanac, like any good almanac, contains
separate sections, broadcast at different rates, for different future
times.  For TTFF discussion we only need the Almanac parts for the 
current 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 entire Almanac is not required, and may take several hours to 
acquire.  Just enough to lock on to some sats to get their Ephemeris.

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

Yup.
 
> 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.

Which with a 66 channel receiver is not a big deal.  Just try them
all at once.

> 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.

Since we have a lock to enough sats for a fix we only need the
ephemeris.  And interleaved implies, at least to me, a 1-to-1 ratio.
But the ratio is, if memory serves me right, about 30 to 1.

> > 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.

Yup.

> > 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.

Yes, the bad old days, but with a 66 channel receiver not so much.

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

Yes.  But since the sat is locked, the Ephemeris is the important
part needed for TTFF.  Or more correctly, about four, for 3D.

> > 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.

Which is conterproductive is the receiver has been moved.

I get Chinese GPS wasting time trying to grab a BeiDou before trying GPS.

Not so bad after the first cold start.

> > 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.

Yeah, another crappy Garmin short cut.  Not important if the GPS
is mostly on, or TTFF is not so important.

> > 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.

And since I live in Oregon, modulo mountains, trees, buildings, etc.

For best accuarcy a good receiver wants to use sats well spaced, which tends
to mean the one just over the horizon.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588



reply via email to

[Prev in Thread] Current Thread [Next in Thread]