-----BEGIN PGP SIGNED MESSAGE----- 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): http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh7EZQACgkQOjLpvpq7dMrJ7gCfa7HtMJ0rHGepKuIpxkkzHuN7 p1YAnR8d6yt36oxquRu5RqlIh6xv3R+5 =uMl6 -----END PGP SIGNATURE-----
