Meddling with GPS / Antaris protocol specification

Andy Green andy at
Mon Jul 14 10:43:08 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

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

Protocol possibilities to the GPS chip in GTA02 are open (okular can eat
this Windows chm format if a bit slowly):

Basically GPS talks overy simply a serial port /dev/ttySAC1, with a
little bit of magic you can cycle the GPS power and see the raw NMEA
data like this from a shell (all one line):

echo 0 > /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron &&
sleep 3s && echo 1 >
/sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron && stty -F
/dev/ttySAC1 -echo && cat -u /dev/ttySAC1 | grep -v ^$

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:

cat my-ubx-packet >/dev/ttySAC1

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.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list