gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Parallel build broken?


From: Gary E. Miller
Subject: Re: [gpsd-dev] Parallel build broken?
Date: Mon, 25 Nov 2013 17:59:33 -0800

Yo Greg!

On Mon, 25 Nov 2013 20:13:33 -0500
Greg Troxel <address@hidden> wrote:

> 
> "Gary E. Miller" <address@hidden> writes:
> 
> > 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.  Each 
SV transmits all the almanac data as part of the ephermis every 2 hours.


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

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

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

> The first time it is turned
> on, it has to search.  And if it's only been off for 10 minutes, it
> can compute a solution without receiving ephemeris because it already
> has it.

Well, not ther FIRST time it turned on.  The first time it is turned on
if it has been on a while, and thus has an ephermeris.

> 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 not a per-satellite parameter, and one only needs it to
> compute UTC for external use;

Yes it is per system.  The leap second is called DELTAtls. and is

in message type 33.  Leap Second Future is also there and is called
DELTAtlsf.  See IS-GPS-200E page 143.  

Message type 33 is not the reduced almanac, midi almanac or ephemeris.  It
is called the 'Clock & UTC'.

Sorry my email will not typeset math symbols...

Technically the ephemeris is just the orbital constants of the satellites.
The other stuff GPS needs to work is technically not the ephemeris.  But
it is commn practice to refer to the 2 hour data as the ephemeris.

>  the navigation solutions are in GPS time
> and don't need it.

Yes, but you need the ephermeris (2 hour data) to do that accurately.
And if you have the epermeris you have the DELTAtls and DELTAtlsf.

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

>  Is that the only reason gpsd needs to have
> leapsecond information?

Yup, to know what UTC time it is.

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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