Reason for GPS problems found! / more patches

Andy Green andy at
Tue Jul 22 11:50:53 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
|> So the fact you were OK at drive level 0 should mean are able to use SD
|> card how you like without problems from SD_CLK to GPS any more.
| Surely the hardware and software 'fixes' can only be seen as a total fix
| if they make the SN (signal to noise ratio) of the GPS the same as if
| the SD card is not present. I would have thought that each of these
| modifications would improve the SN ratio but would not make it the same
| as not having the SD card present.
| I know it is hard but it would be nice to get some figures on how each
| of these modifications by themselves and together effect the SN ratio.

As far as it is understood, having the SD card in or not is not actually
the issue... the problem has been that with an SD Card in we ran SD_CLK
all the time, and this raises the noise at 1.5GHz where GSM works.

There is a figure for the cap efficacy, it attenuates the crap coming
from SD_CLK by 10dB.  But of course stopping the clock does better, and
changing the rise and fall time is also directly effective even when the
clock does run.

| It might turn out that the software clock drive solution by itself is as
| good as or better than adding the capacitor, and adding the capacitor
| does not improve the SN ratio any further once the clock drive mod is
| done, which would make it unnecessary.

That's the current thinking, this issue can be solved by kernel update
and no rework.  Basically we're then not running the clock most time
anyway, and tests like the one in this thread (which ran the clock all
the time) show that at drive strength "0" we talk to the card fine but
do not perturb GPS significantly.

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


More information about the hardware mailing list