Re: [gpsd-dev] Parallel build broken?

[Gary E. Miller]

Yo Paul!

On Tue, 26 Nov 2013 11:13:20 +0400
Paul Fertser <address@hidden> wrote:

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

No, just for one other SV each 12.5 minutes.  And there are several
ephemeris to transmit (for future times) in that slow as well.  Thus the 
2 hours.

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

Well, yess it is a complete frame, but all data is not in each frame.

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

Yes, might be enough, but not as good as it gets.  Sorta depends on
you definitiion aof good enough.

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

Actually, the original discussion was leap seconds.  So we have drifted
off topic.

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

Yes.

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

No.  Ephemeris data goes our for weeks.  See table 20-XIII.  Ephermis data
goes out more than 6 days.

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

Yes.  It finds the sats, but without the full precision ephemeris it
does not know exactly where they are, thus the GPS does not know exactly
where it is.  Maybe the reduced precision is not important in your
application.

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

Yes, and new devices as well.

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

Well, if they have AGPS info, then it is not eactly a 'cold start'.
 
> > > 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,

No, they call that the ephemeris, if they have any clue.

> so that includes UTC parameters.

Well, some people are wrong, thus this converstaion.

> In CNAV data
> UTC has its own message type and maximum interval, so unrelated to
> almanac as well.

Yes.

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

And the $64,000 question: how long is it wrong?  Forever?

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

signature.asc
Description: PGP signature