Re: [gpsd-dev] Parallel build broken?

[Paul Fertser]

Hey Gary,

Thank you for making me read the actual standard, it's quite
informative and entertaining.

On Mon, Nov 25, 2013 at 05:59:33PM -0800, Gary E. Miller wrote:
> > > If we are going to get really technical, then yes "almanac" is sent
> > > every 12.5 minutes, but the almanac is not what we want.  As the
> > > spec says: 20.3.3.5.2.1 "The almanac is a subset of the clock and
> > > ephemeris data, with reduced precision."
> > 
> > Sure -the almana is intended to be good enough to know which SVs are
> > above the horizon and compute doppler shift.  All SVs transmit the
> > same almanac data.
> 
> Each SV only transmits its own almanac data every 12.5 minutes.

Technically speaking, yes, as for every particular SV the almanac data
is in one particular page (from frame 4 or 5), so it will be
transmitted every 12.5 minutes.

But it should be noted that each SV transmits almanacs for every other
SV every 12.5 minutes too.

20.3.2 says that "a complete data message shall require the
transmission of 25 full frames". That is, 12.5 minutes and you have
the data as complete as possible.

> > > So you really want the ephemeris, not
> > > the almanac.  And the ephemeris needs two hours:
> > >
> > > 30.3.3.1.1 "The ephemeris parameters in the message type 10 and
> > > type 11 describe the orbit of the transmitting SV during the curve
> > > fit interval of three hours. The nominal transmission interval is
> > > two hours, and shall coincide with the first two hours of the curve
> > > fit interval."
> > 
> > My understanding is that each satellite transmits an ephemeris for
> > itself (only) every 30s, and the two hours refers to how often a new
> > ephemeris message is uploaded to each satellite.
> 
> As seen in 20.3.3.5.2.1, that is the 'reduced almanac' not the
> 'midi almanac' or the 'ephemeris'.

I do not see "reduced almanac" anywhere in 20.3.3.5.2.1, on the
contrary, it says almanac is reduced precision ephemeris data. For
doing coarse navigation the almanac might be enough but for the
ordinary standard precision operation the reciever must know ephemeris
of the SVs it's locked to.

I see midi almanac and reduced almanac mentioned in CNAV data but
we're discussing here only NAV data, right?

If we were to discuss CNAV, we would be referring to 30.3.4 which
states UTC parameters should be transmitted not less often than every
288 seconds (4.8 minutes).

> > So when you turn on a receiver that has been off for a day, it finds
> > satellites within seconds
> 
> Yes, because it already has the full ephermerix.

No, ephemeris data expire in few hours time.

The real reason it "finds" the satellites is that modern GPS units
have enough correlators to "listen" to all the SVs independently at
the same time, so it doesn't have to find anything at all.

Earlier devices used stored almanac, last known position and current
time to decide what SVs might be visible right now and configured the
limited amount of correlators to decode their signal.

> >  and then after 30s of listening has
> > ephemeris and can compute a solution.
> 
> Nope.  30 Sec is one frame size, 1500 bits.  The almanac, more properly
> the reduced almanac, is one frame, It is just one frame of many that
> occur every 12.5 minutes.

In fact any modern receiver can get fix right from the cold start in
few seconds if ephemeris data is uploaded to it from some external
source (e.g. from the Internet, "AGPS solutions").

> > All that said, I think people said that the GPS-UTC offset is in the
> > almanac;
> 
> Which is wrong.  It is not in the almanac.  The 'reduced almanac' that is
> sent every 12.5 mins is documented on page 141 fo the IS-GPS-200E.  You can
> see there is no leap second there.

It's technically in neither. Reduced almanac, almanac and UTC offset
seem to be unrelated. Reduced almanac is part of CNAV data, almanac is
part of NAV data. People usually call all contents of frames 4 and 5
(of NAV data) almanac, so that includes UTC parameters. In CNAV data
UTC has its own message type and maximum interval, so unrelated to
almanac as well.

> > How many GPS receivers supported by gpsd send time to the computer in
> > GPS time, rather than UTC?
> 
> Pretty much everyone I have looked at on a cold start.  When they have
> DELTAtlf then they give you UTC, and worse they do not tell you which is
> which or when they switch.

The MTK devices I've used lately (including the new "uBlox" modules)
all reported neither :( It was incorrectly calculated UTC time, with
GPS-UTC offset assumed to be the same as during the module production
apparently.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:address@hidden