-----BEGIN PGP SIGNED MESSAGE----- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiFrX0ACgkQOjLpvpq7dMoe3wCdHokzAYHLaVcVoATXt13kfcAa GxUAn3kKze522PSZXpw4LVqxldJFb96k =Oc/x -----END PGP SIGNATURE----- _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
