GSM-noise "buzz" issue

Joerg Reisenweber 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 
separate compartments.

> 
> > > 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.

/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/20080921/e428033e/attachment.pgp 


More information about the hardware mailing list