GSM-noise "buzz" issue / ways forward
Joerg Reisenweber
joerg at openmoko.org
Mon Sep 22 15:34:25 CEST 2008
Am Mo 22. September 2008 schrieb Andy Green:
> Somebody in the thread at some point said:
> | On 9/22/08, Andy Green <andy at openmoko.com> wrote:
> |
> |> I agree it's not clear 100uF there is going to do anything good about
> |> the problem, unless the dips are introduced directly on MICBIAS then
> |> trying to smooth them there is the wrong place since they have already
> |> been amplified on to there and we fight the blameless amplifier. But
> |> actually, I didn't see we proved quite where the buzz starts from as LF
> |> so we are not in a position to write this off as insane.
> |
> | If you have problems with HF "infestation" a big cap will usually not
> help.
>
> Completely agree, but MICBIAS gets something different from HF during
> the buzz behaviour, it gets small depressions (like 100mV IIRC) in it at
> ~200Hz period. Basically it is exactly like the PSRR was very low and
> the impact of GSM TX action on the battery rail (also 200Hz "dents" from
> high current draw at TX time) was showing up on MICBIAS.
>
> MICBIAS as it sounds provides DC to power the microphone, now it has
> 200Hz noise in audio range we assume this forms the basis of the "buzz".
>
> Someone has seen that with a 'scope and had the idea to put a big cap on
> it to iron out the 200Hz dents.
>
> What I don't understand is how we get from 1.7GHz "infestation", which
> is clearly an issue since a bead on p4 of the headset jack does
> something, to these LF "dents" on MICBIAS.
My theory is RF is spoiling VREF, by entering the Wolfson chip via arbitrary
path (actual path doesn't matter, as RF can "jump" inside chip) and being
rectified on some nonlinear component of the circuitry inside chip
responsible for stabilizing VREF.
Basically it's always RF hitting a nonlinear junction that creates some form
of basic crystal-receiver type setup and transforms RF modulation to
DC/LF/audio-noise (there's a second possible principle of RF-to-clocked-audio
interference based on aliasing, but that's not what we see here [yet?]).
It will be very hard to find a test setup to verify this hypothetical
contamination scheme and actually spot the contamination path to the very
last P/N-junction inside chip. Anyway we won't learn anything from it that's
of any practical use for design recommendations. Basic rule is: "keep RF away
from audio circuitry, as it's not designed to cope with RF". We got a can for
this purpose, but we failed to keep RF out of the can. This is what we have
to take care about.
Well maybe luckily we *might* eventually find a magic place for a (33pF) C
somewhere near Wolfson chip, to rework GTA02 out in the field this way.
Anyway I'd rather expect this magic fix to be found by try and error, rather
than probing on a setup that's completely changed by mere applying a probe to
it.
/j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20080922/1f9da845/attachment.pgp
More information about the hardware
mailing list