gpsd and AGPS

Ken Yale kyale at broadcom.com
Mon Sep 3 21:24:45 CEST 2007


Hello,

The AGPS functionality is split into these components:
1)  Hammerhead GPS silicon - performs GPS measurements under control of (2).
2)  Computation library - converts the GPS measurements into positions.  The library is embedded into the GLLIN control program.  NMEA output is via named pipe /tmp/nmeaNP.
3)  OMGUI - user interface to test the GLLIN:  stop/start, show signal strength, etc.
4)  liblto - library to examine LTO expiration date
5)  GPSD - standard GPSD with extensions to control host-based GLLIN.

Here's the status of each:

1)  Hammerhead is proven to work very well on GTA01 - I have measured down to -160 dBm sensitivity.  The GTA01 antenna is VERY good, and the FIC designers did a great job keeping GPS RFI out of the antenna.
2)  GLLIN is complete and tested for LTO AGPS.  More on this below.  The EULA/SLA for GLLIN is currently bouncing back & forth between FIC and Broadcom.
3)  OMGUI is done, but I'm sure a GTK+ hacker will find lots of cool ways to zoom it up, add maps, etc.
4)  liblto is also done.
5)  GPSD is started.  OMGUI/src/gllin.cpp can be used to finish it to start/stop GLLIN.  I hear the FIC team has the IPC mechanism running on it.  (I forget the IPC name:  DB, ADB, DBM??)

AGPS Status:

There are many levels to AGPS.  Even a standard autonomous GPS receiver has a simple form of AGPS by virtue of caching recent information:  position, time, ephemeris, clock frequency, etc.  The GLLIN has this level of AGPS, embodied in two NVRAM.dat files kept in gpsd directory.  (You can test factory cold start of GPS by removing these files).

Beyond that, the only AGPS capability in the GTA01 is LTO.  This is long-term orbit data files downloaded from the network.  The delivery of the files can be done via wget or the lto_get facility included with OMGUI.  FIC has purchased LTO delivery for the GTA01 for the lifetime of the product with the price of the Hammerhead chip.  LTO is there now and it is free for FIC customers.

Normally, ephemeris satellite data is downloaded at 50 bps from the satellites, but only when the signal strength is above about -142 dBm.  Live ephemeris data is good for about 2 hours.  With a data connection (I use a USB TCP/IP bridge to a PC, and then to the network), we can download 7 days of ephemeris in 3 or 4 seconds, independent of GPS signal conditions.

When the GTA01 can make a data call, SUPL will be tested on the GLLIN.  The choice of which SUPL server to connect to will be a command-line option to the GLLIN.  The SUPL protocol is an OMA standard, so there will be competition in this arena.  Broadcom sells a SUPL server, and we'll use it to test the GTA01 when this is possible, but there will not be any automatic "lock-in" to a specific server.  When GTA01 is productized and customized by large integrators, there may be such lock-ins performed by the integrators that is not under control of FIC or Broadcom.  Such a lock-in will be to meet the needs of the integrators' customer base, and would not affect the developer community.

Behind the SUPL server are a bunch of other complicated servers and services that most network operators are getting into place.  Here's some of the things a SUPL server needs to play well with:
- access to the GPS ephemeris.  There is yet another standard for this data pipe, and competition in this area.  Of course Broadcom has a product for delivery of the ephemeris, as to others.
- database of cellID --> initial position look up.  I understand network operators cherish and protect this database.
- interface to E911.  This seems reasonable, but I don't know for sure about it.  With C-Plane AGPS, E911 is definitiely there.

GLLIN should be capable of supporting MS-BASED and MS-ASSISTED SUPL requests.  Typically, SUPL-NI (Network Initiated) requests are signalled via a SUPL-NI data packet sent via SMS.  I doubt this is available on the TI Calypso.

Unfortunately, the TI Calypso GSM chipset does not provide control-plane access, so RRC and RRLP assistance is not available.

So you can see that direct access to LTO via TCP/IP bypasses lots of complicated infrastructure, and can be accelerated to suit your style of use of the GTA01.  On WindowsCE devices, the LTO mechanism is enhanced by these features, all of which can be added to GTA01 by the OpenMoko community:
-  cache LTO on a PC.  Upon PC<==>GTA01 sync; squirt the LTO to the GTA01
-  on GTA01:  detect data connection creation and retrieve LTO if needed
-  on GTA01:  add a cron job.
-  for specialized GTA01 environments:  store & forward the LTO file as needed.

I hope this helps,
Ken Yale



-----Original Message-----
From: Ian Stirling [mailto:OpenMoko at mauve.plus.com]
Sent: Mon 9/3/2007 9:38 AM
To: List for OpenMoko community discussion
Subject: Re: gpsd and AGPS
 
Luca Cabriolu wrote:
> Hi Ian,
> 
> thanks for your answer.
> 
> I'd like to know how AGPS is currently supported on the NEO 1973.
> Can you help me to understand how it works from a software and a 
> hardware point of view?

Fortunately, the answer is very simple.
Unfortunately, that answer is "It's not".

The binary GPS program seems to have the ability to communicate with 
AGPS servers run by Global Locate - however, these require a 
subscription by some third party willing to buy service.
I don't know the prices.







More information about the community mailing list