GSM-noise "buzz" issue
joerg at openmoko.org
Sun Sep 21 00:11:05 CEST 2008
Am Sa 20. September 2008 schrieb Werner Almesberger:
> But that's something you'll have to solve anyway. Otherwise, even
> the nicest CMU200 will be of little use.
Well it's a little different to run a certified GSM-phone on a CMU200 which
itself is at -80dBm, or to run a selfmade 2W-oscillator ;-)
Though the result is the same from a technical point of view.
> > > Basic guidelines:
> Good principles for sure.
> > > All connectors to outside of housing SHOULD have EMI-filters [[edit: as
> > > close as possible to component]] on all lines
> Shouldn't the EMI filters rather be where the signals enters the cage ?
Actually these "quick-and-dirty" specs require both. It's arguable whether we
can save one of them.
The spec was done to *guarantee* a clean buzz-free design, rather than with
BOM in mind ;-)
> > > *) that's one of the points why it's more reasonable to have a separate
> > > cage.
> Hmm, makes the mechanical setup more complex, though.
Marginally. We could have another tin-wall inside the current can, forming two
> > > We don't want the need for EMI-block on lines that aren't related to
> > > audio, but run to same cage.
> Shouldn't they be filtered anyway, lest we contaminate other signal
> paths, e.g., hyper-sensitive GPS ?
Hm, guess I don't get it. Idea is to block all RF from entering can.
Clock-harmonics and the like are a completely different story, and also the
clock frequency itself could create noise if a clocked component is placed
inside audio can, not only it's harmonics.
-------------- 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/20080921/e428033e/attachment.pgp
More information about the hardware