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