GSM-noise "buzz" issue

[Joerg Reisenweber]

Am Do  18. September 2008 schrieb Werner Almesberger:
> Andy Green wrote:
> > Yeah, waving hands about RF in cans is not understanding: pretty sure
> > about it.
> 
> I think we all would be much more comfortable about our understanding
> of the situation if someone could identify the actual contamination
> path.
RF is tending to exit wires and go OTA or coupling to nearby structures, 
either by inductive or capacitive signal component (or both).
The amount of this effect depends on structure not only of the "sending" 
and "receiving" part and their geometrical position to each other, but also 
on "environment" (look at a couple of different Yagi, may be a good example 
of what I'm talking about).
In the end this means: a) we might easily find multiple pathes (with 
multiple "hops" each) of contamination, once the RF got inside the can, b) we 
might change situation even by mods of "far away" details of the whole device 
(to the point where we see changes of buzz depending on the way the phone is 
held. Placing it on a steel-table produced most noise).
Peter Wippich explained we always see a dipole formed by actual antenna as 
one "half" and virtually entire device (ideally only ground-plane) as the 
other half. Obviously *any* change on any half of this dipole changes 
RF-situation as a whole.

> 
> It's one thing to identify violations of good design practice (and to
> avoid them in the future), but to debug an actual problem, we can only
> be sure the true root cause has been found if we have the complete
> story, or at least a plausible theory for every step.
The whole story is we get RF inside the can, and nobody can exactly predict 
what it's going to do once it got inside. It might jump to any pin of 
Wolfson, or even directly to the chip inside it's plastic housing, and we 
won't learn anything from months of investigation on the actual contamination 
path, as we couldn't fix anything even if we had a detailed explanation.
The fix is to keep RF away from Wolfson, and for the given design that means 
keep RF out of the can.
My suspicion is RF is spoiling the MICBIAS voltage regulation, and we could 
probe for this by scoping MICBIAS with RF-reject probe *during actual buzz* 
(this actual-buzz-detail wasn't regarded or at least not mentioned when TPE 
did this test some time ago. Without buzz I of course would expect a smooth 
MICBIAS, alas this doesn't tell us anything). So much for a plausible theory, 
that's even explaining the changes of buzz amplitude when placing insanely 
large capacitors on MICBIAS. Anyway it's just as good as any other actual 
theory, as in the end there's exactly one thing we reasonably can do: keep RF 
out.

Honestly, I'm much more interested in a complete story on how a 100uF (C4306, 
R4303) connected from one pin of mic to the other, is supposed to stop this 
ripple on MICBIAS while still delivering decent audio-signal to the amp 
connected to those two pins. From my POV that's much more of the kind of 
thing we need a *decent* *comprehensive* story about every step, *before* we 
consider to introduce such a bug into MP. And with "every step" I also 
address change of alsa.state TPE reported we will need to make this 
alleged "fix" work at all, as well as some decent audio-test we MUST do on 
this deprecated "fix" to assure our devices still meet certification 
criteria.

> 
> This, by the way, also applies to the SD vs. GPS interaction. We now
> have what I believe is a thorough understanding of what gets emitted
> and how to silence it, but we never identified where this gets picked
> up and causes trouble.
YUP.

> 
> If this is an over-the-air path,
When removing a "dead-end" 5mm piece of metal (JK4401) isn't a sufficient 
proof for OTA, and the bead, and injecting buzz from external source even 
doesn't confirm this, I really don't know what else we could do to get any 
wiser.

> of limited use and might draw attention from more deserving areas.
ATM this discussion is drawing attention from an area that should be first 
priority: fix the bug for good, by placing 3 beads or better EMI-filters on 
JK4401-audio-traces

> Now, I'm not suggesting to reopen the GPS noise investigation, but I
> would very much like to see an explanation for how and where the RF
> noise "received" by the audio jack jumps into the mic signal even
> after all components actually connecting the traces have been removed.
See placement of R4408. I think that's enough of a good story.

cheers
jOERG
-------------- 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/20080919/939c9380/attachment.pgp