Meddling with GPS / Antaris protocol specification

[Daniel Willmann]

Hi,

On Mon, 14 Jul 2008 09:43:08 +0100
Andy Green <andy at openmoko.com> wrote:

> | Another thing I tried was sending a UBX command CFG_RST each
> powerup to | clear the battery backed up memory region of all its
> data, but this did | not seem to do anything about the seemingly
> sticky behaviours between | sessions.

I'm actually pretty sure that that data is really cleared at startup.
At least no epemeris and almanac is ever present after a power cycle.

> Protocol possibilities to the GPS chip in GTA02 are open (okular can
> eat this Windows chm format if a bit slowly):
> 
> http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm
> 
> The raw NMEA sentences are just plain text and kind of human readable,
> and spew once a second whether there is good data or not.  But the GPS
> chip also supports some checksummed binary packets in this UBX
> protocol documented above to control it.  If you place a canned UBX
> packet in a file, you can issue it to the GPS chip like this:

ogpsd now has a pretty complete UBX parser. You can send arbitrary
packets at startup for initialization and enable periodic reporting of
specific packets.

I already tried enabling high sensitivity mode (gps_mode = 2 in
CFG-RXM) and tried to enable SBAS (basically DGPS via satellite which
should be available in Europe and the US) without much difference (But
my Neo didn't really respond to removing the SD card either).

See
http://git.freesmartphone.org/?p=framework.git;a=blob;f=framework/subsystems/ogpsd/ubx.py;h=586d0b6ae76fbad2d71762dbded5be6751c3d5bb;hb=HEAD#l273
to get an idea on how to send initial packets for configuration.

> A current suspicion is that somehow the GPS firmware is masking the
> best satellites wrongly somehow at relatively low signal levels and
> when in "bad mode" is therefore straining itself to only find
> satellites that are not in view or are too weak to work with.  If we
> could find an effective UBX packet to defeat that (assuming this is
> even taking place) and have it restart acquisition of satellites with
> a clean slate, it may clear this sticky "bad" state we see the GPS
> can get into.

I believe ogpsd can be used to gather the needed details. We can
make a GTA02 debug device where we enable a couple of messages that
could tell us more:

NAV-SVINFO: Tells us which SVs we see, what carrier to noise ratio they
have, whether almanac of ephemeris is available (we could see how long
it takes under different situations), whether we're currently receiving
data from this SV (QI).

RXM-RAW: Tells us similar stuff to NAV-SVINFO, not sure if that is
needed. The loss of lock indicatior might be interesting.

RXM-SVSI: We can check whether we have valid ephemeris or almanac for a
SV and also see the age of the ephemeris. This is important to see
whether we are able to receive new ephemeris during normal operation.
Imagine you are standing still for 2 minutes until you get a fix. Okay,
now you have maybe ephemeris for 5 satellites. Now you are constantly
moving for a couple of hours which degrades the signal so you are
unable to download new ephemeris for new or existing SVs, but it is
good enough to still compute a fix. Over time as the initial satellites
drift out of view and ephemeris becomes obsolete you will just loose
the fix without any real indication of why that happened.

I've also started playing around with the MinCN0Initial and MinCN0After
values in CFG-NAV2 to see if that helps at all with the initial fix.
That will only help if you already have ephemeris data for that SV,
though, since ephemeris download has higher CN0 requirements.

Regards,
Daniel Willmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080727/1e62fd08/attachment.pgp