GSM-noise "buzz" issue
joerg at openmoko.org
Fri Sep 19 20:17:32 CEST 2008
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
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
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
> 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.
> 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
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20080919/939c9380/attachment.pgp
More information about the hardware