Reason for GPS problems found!

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| Do you know if the Antaris enters one of the sleep/backup modes
| on system power loss? If it does, perhaps it mode switch is triggered by
| external firmware. In backup mode it only consumes 8uA, and can
| probably remain alive for a long time on with regular large capacitors,
| such as the ones in the middle of the board.

Yes these seem to be the right thoughts... SRAM cells themselves can
hold data with no power for a surprising time.  And the firmware in ROM
in the GPS chip is closed, so we don't know its criteria for believing
that what it finds in the SRAM on powerup is valid and it should try to
use it.

Situation for backup power on the GPS chip is that backup battery is
optional, we did not take the option and seem to have correctly done the
recommended steps for no battery.  There are two backup-related balls on
the GPS chip, we tie VBAT that would take the battery to 0V, and we
place 1uF cap on VBAT18 ball.  But when power is taken, this net seems
to discharge the cap quite quickly.

I use the production test software DM2 to test GPS, in this code we use
the UBX command CFG-RST to take a dump on the stored settings and reset
ourselves again, but still the GPS chip appears willing to hold state
across powerdowns.  I have asked for support from U-Blox for some other
UBX commands that say they can read and write memory in the device
randomly, assuming that's possible I will dump and zero that memory
using those and see if we can get the GPS chip to act deterministically
on powerup without dependency on what happened last session (not too
much to ask you would think).

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiAVDMACgkQOjLpvpq7dMq4YACfYYa/m/XNWnFdP7WzaTWL8gKg
dIUAn3ZumfZC+UumEsOCD/MfJOiY2XrP
=nKuq
-----END PGP SIGNATURE-----