Some clarifications for the AGPS/SUPL/OMA threads in the OpenMoko list.

Marcus Bauer marcus.bauer at
Tue Dec 26 03:45:27 CET 2006

On Mon, 2006-12-25 at 14:36 -0800, Sean Moss-Pultz wrote:
> These are comments from a Global Locate Engineer (NOT ME) from various
> threads about GPS and related functionality. Hope this will help answer some
> of your questions.

Not really.

A GPS chip needs three things to aquire a fix:

      * almanac
      * ephemeris
      * time synchronisation (~1us)

With the quality and performance of today's gps chipsets everything else
-like mobile station based/cell information- is pretty unimportant.

The almanac contains the coarse position data of the satellites and is
*good for weeks*. Size is 37.500 bit and gets sent by all satellites in
30sec chunks at 50bit/s. Downloading from one satellite takes 12.5
minutes. The almanac is freely available on the internet.

The ephemeris data is the precise position data of 1500 bits length.
Each satellite sends only its own at 50 bits/s thus repeating it every
30 seconds. The ephemeris data ages rapidly and is valid only for *two
hours*. It can be pre-computed with good quality for ~7 days. The
current data plus 6 hours into the future is freely available on the net

The time synchronisation is an iterative process mostly based on the PRN
and happening inside the gps chip once a first coarse position is known.
Takes some seconds but precise specs are company secrets. GSM -as
opposed to CDMA- supplies only coarse time information, thus is no help.

Now what one wants to have is a short time to first fix (TTFF). A
current chipset like the Sirf starIII takes on average:

      * ~0.1 sec - almanac, ephemeris cached in chip and time
      * ~8 sec - almanac, ephemeris cached but time not synchronised
      * ~45 sec - no almanac, no ephemeris, no time; first fix only
        +/-150m precision. TTFF may go up to several minutes when

All the OMA SUPL stuff is completely irrelevant here because it is about
the transport between whosoever and the phone but not between the phone
and the chip. I don't care about OMA because the data is available
elsewhere for free and I get it easily into the phone i.e. over http /
tcp/ip / gprs|USB-net

Sirf however has published a reference guide [1] for the binary protocol
of its chips which already allows to preload almanac and ephemeris into
the chip - but unfortunately we are stuck here with the Global Locate. 

Actually all these questions of preloading almanac and ephemeris are
handled in the gpsd which will be closed source. With all the openess of
the neo-plattform it is a pity not to have a Sirf or any other
performant chip with open protocol specs.

Global Locate uses LTO[tm][2] as selling point. However it doesn't need
overly much computing power to precompute the ephemeris and the software
to do so and the data of plenty of reference stations is available on
the net. LTO is a nice convenience for people who plan a week long trip
into the wilderness without any network access and can't wait out there
45 seconds TTFF.

Indoor fixes are possible with the Sirf starIII chip too, it has the
same sensitivity specs of -159dbm as the GL hammerhead; -159dbm is
~1000th of the clear sky signal strength of the GPS satellites.

It would be interesting to know why GL was chosen in the first place.

> > free routing possible, but what is the protocol of the AGPS data
> > that the globallocate chip expect?
> "Very standard stuff: the SUPL specification by OMA.  Works with any
> standard SUPL server. OMA and SUPL are easily googled for more info."

Again the question is how to get it into the chip and not into the
phone. Partially the question goes to the openmoko team writing the


[1] Sirf Reference guide, "2-7 set almanac", "2-18 set ephemeris"

[2] LTO is GL's trademark and stands for long term orbit, meaning
pre-computed ephemeris.

More information about the community mailing list