Re: Openmoko Bug #1770: NAND u-boot jams FM radio

[Openmoko Public Trac]

#1770: NAND u-boot jams FM radio
-+--
Reporter:  h.koenig  |Owner:  hardware
Type:  defect|   Status:  assigned
Priority:  normal|Milestone:  
   Component:  hardware  |  Version:  
Severity:  normal|   Resolution:  
Keywords:| Haspatch:  0   
   Blockedby:|Estimated:  
 Patchreview:| Blocking:  
Reproducible:|  
-+--

Comment(by andy):

 Our memory clock is 100MHz on GTA02, that is in FM band.  It also comes
 out of CPU to external SDRAM chip.

 On GTA03 all the SDRAM is in the CPU and the actual base clock is 133MHz.

 If this thing only happens in U-Boot and not kernel for whatever reason,
 we will change to Qi soon which spends only a couple of seconds in the
 bootloader anyway, so I guess that is the fix.

-- 
Ticket URL: 
docs.openmoko.org 
openmoko trac
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| That's effectively what I did.  I attached teflon tape to the bottom of
| the connector to isolate it. The buzz is still present.

Angus, I talked to Candy here in .tw the last few days about this, she
actually did the work to perform the tests Joerg is talking about.

One thing you can try that is quite simple and easy is to override
MICBIAS net by a ~1.5V battery on it to 0V.  She told that this alone
removes the buzz, it would be good to know if you can reproduce.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkKavAACgkQOjLpvpq7dMoC+gCePrDGPEDvYVLoWd7nYpFHdKNt
O0MAnjk8ETjpdKumZOtyEhOj3IdAQMGO
=K8UG
-END PGP SIGNATURE-

___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Openmoko Bug #1770: NAND u-boot jams FM radio

[Openmoko Public Trac]

#1770: NAND u-boot jams FM radio
-+--
Reporter:  h.koenig  |Owner:  hardware
Type:  defect|   Status:  assigned
Priority:  normal|Milestone:  
   Component:  hardware  |  Version:  
Severity:  normal|   Resolution:  
Keywords:| Haspatch:  0   
   Blockedby:|Estimated:  
 Patchreview:| Blocking:  
Reproducible:|  
-+--

Comment(by werner):

 Hmm, maybe ask our hw folks to hold an antenna up in the air and look
 with a spectrum analyzer what this is. Seems pretty strong.

-- 
Ticket URL: 
docs.openmoko.org 
openmoko trac
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Openmoko Bug #1770: NAND u-boot jams FM radio

[Openmoko Public Trac]

#1770: NAND u-boot jams FM radio
-+--
Reporter:  h.koenig  |Owner:  hardware
Type:  defect|   Status:  assigned
Priority:  normal|Milestone:  
   Component:  hardware  |  Version:  
Severity:  normal|   Resolution:  
Keywords:| Haspatch:  0   
   Blockedby:|Estimated:  
 Patchreview:| Blocking:  
Reproducible:|  
-+--
Changes (by john_lee):

  * owner:  openmoko-devel => hardware
  * status:  new => assigned
  * haspatch:  => 0
  * component:  unknown => hardware


Comment:

 err, exactly what should we do about this?

-- 
Ticket URL: 
docs.openmoko.org 
openmoko trac
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[Joerg Reisenweber]

Am Do  30. Oktober 2008 schrieb Ole Kliemann:
> Thanks for the answer!
> 
> The point is, i certainly won't do the fix myself. ;) I will send my
> device to my distributor on warranty.
> 
> On Thu, Oct 30, 2008 at 12:11:47PM +0200, Joerg Reisenweber wrote:
> > Seems you always could "upgrade" to the 'botch' fix found in A7 (It 
*should* 
> > work, as our TPE engineers found it worth to implement in A7 ;-):
> 
> So as this fix is officially approved,

That's *your* way to read my words ;-)
My posting contained nothing official nor any approvement.

> I assume my distributor will 
> either be able to apply it or provide me with an A7. Gonna check with
> them soon.
> 
> > > And - if you allow me to be off-topic - is there any improvement fix for
> > > the headphone jack? I mean this hipass-filtering issue making music
> > > sound quite tinny.
> > a) place some decent 100uF (or as high cap as feasible) parallel to C4110 
and 
> > C4111. Make sure you don't create another contamination path for RF 
creeping 
> > inside big can - maybe use a ferrite ring to block RF next hole where you 
> > route some wires from those big caps inside can to C4110/11.
> > b) *short* C4110 / C4111, and insert the 100uF somewhere else in 
audiopath, 
> > b1)e.g. near R4405 / R4407 (you can even replace these R by 100uF 
> > capacitors).
> > You should remove R4117 and R4117 then, and instead place these 1k from 
> > JK4401:pin2 and pin3 (! for JACK_INSERT function) to GND
> > b2) or even place the 100uF outside FR in the housing of your hs-plug or 
> > 2.5->3.5mm adapter
> 
> Is this somewhat official? 
Nope.

> Is it included in any newer revision? 
For sure not, as any "official" fix (that may or may not be included in A7, 
I'm pushing it but result is somewhat... hmm, limited) for sure simply will 
rearrange layout to make space for decent 100uF in place of the former 1uF 
C4110/C4111.


/jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[Angus Ainslie]

On Thu, Oct 30, 2008 at 7:30 AM, Joerg Reisenweber <[EMAIL PROTECTED]>wrote:

> Attaching the bead is *not* the fix exactly, cutting the connection from
> JK4401:4 to coppertrace is considered the fix.


 I cut the connection between pin 4 and its pad. The bead is now in series
between the pad and the spring that used to be JK4401:4.


> Anyway it seems you tried to achieve this by cutting the contact from
> JK4401
> (your first picture). Alas it's not clear if you correctly isolated
> pin4-pad
> on PCB, so to me it looks like you soldered the bead on the pin4-pad and
> maybe you just shorted the tiny gap between PCB-pad and the metal-stub
> where
> you cut off pin4-contact on JK4401, while soldering the bead.
>

No there is no direct connection between pad 4 and the connector.


>
> Cutting the contact sure is a good thing, anyway I recommend to isolate
> pin4
> PCB-pad by some plastic, so it is securely NC and in some distance to
> JK4401:4 metal spring. (see:
>
> http://people.openmoko.org/joerg/GSM_EMI_noise/noise_stopped_by_cut_pin4/JK4401_isolate_pin4__2.jpg)
> Then do first test to find buzz is gone.


That's effectively what I did.  I attached teflon tape to the bottom of the
connector to isolate it. The buzz is still present.


> Then place bead to pad of R4404 NC, or even piggyback it to C4405, and
> connect
> to upper golden contact of JK4401, above pin4. (Please note you need the
> bead
> only for hs mic function, which may still be broken when using it during
> GSM
> RF activity)
>

Right now I what to get rid of the buzz ( I'm going to attempt the A7 bodge
) and have the connector reattached so I can try and dump the GSM firmware.

Angus


-- 
Angus Ainslie
http://www.handheldshell.com/
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[Alastair Johnson]

Joerg Reisenweber wrote:
> Am Mi  29. Oktober 2008 schrieb Ole Kliemann:
>> Hi Joerg and others,
>>
>> I haven't followed the whole thread as I only understand 1%. So just one
>> quick and dirty question:
>>
>> I have the two years EU warranty and am going to send my FR to my
>> distributor anyway because GPS is not working with the internal antenna.
>> (Independant of SD card.)
>>
>> So if I send it in, is there any fix that could be applied for the
>> buzz? Or is it worth to wait, say another week, because there will be
>> something then?
> 
> Seems you always could "upgrade" to the 'botch' fix found in A7 (It *should* 
> work, as our TPE engineers found it worth to implement in A7 ;-):
> 
> replace R4403: 0R -> 2k2
> add C4306: NC -> 100uF (probably you won't find a 100uF to fit in anywhere, 
> so 
> a 47uF might kinda suffice. C4306 pads aren't existent in A5/A6, but you can 
> use pads of NC R4304 which isn't mentioned in public schematics)
> 
> 
> 
> A _yet_unapproved_(!) variant is to use a LM336-2.5 in place of the huge 
> capacitor, and to 
> change R4305: 2k2-> 860R (to make LM336 operate on >400uA, when setting 
> MICBIAS to VDD*0.9)
> You also have to
> replace R4403: 0R -> 2k2
> In theory this rework should yield even better stabilization of MICBIAS 
> voltage, the path where ripple caused by GSM RF is introduced to audio path.
> See all but first 6 pics at http://people.openmoko.org/joerg/buzzfix-lm336/
> (first 6 pics are a nasty approach to cut pin4 using some dremel-like mill. 
> Those are not related to LM336 fix)

All of this is on the Mic2 side of the micbias supply. Is Mic1 also buzz 
free after this mod, or does it only help for the handset mic?

___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[Ole Kliemann]

Thanks for the answer!

The point is, i certainly won't do the fix myself. ;) I will send my
device to my distributor on warranty.

On Thu, Oct 30, 2008 at 12:11:47PM +0200, Joerg Reisenweber wrote:
> Seems you always could "upgrade" to the 'botch' fix found in A7 (It *should* 
> work, as our TPE engineers found it worth to implement in A7 ;-):

So as this fix is officially approved, I assume my distributor will
either be able to apply it or provide me with an A7. Gonna check with
them soon.

> > And - if you allow me to be off-topic - is there any improvement fix for
> > the headphone jack? I mean this hipass-filtering issue making music
> > sound quite tinny.
> a) place some decent 100uF (or as high cap as feasible) parallel to C4110 and 
> C4111. Make sure you don't create another contamination path for RF creeping 
> inside big can - maybe use a ferrite ring to block RF next hole where you 
> route some wires from those big caps inside can to C4110/11.
> b) *short* C4110 / C4111, and insert the 100uF somewhere else in audiopath, 
> b1)e.g. near R4405 / R4407 (you can even replace these R by 100uF 
> capacitors).
> You should remove R4117 and R4117 then, and instead place these 1k from 
> JK4401:pin2 and pin3 (! for JACK_INSERT function) to GND
> b2) or even place the 100uF outside FR in the housing of your hs-plug or 
> 2.5->3.5mm adapter

Is this somewhat official? Is it included in any newer revision? If not,
I don't think I can convice my distrubtor to do it on warranty. ;)

Ole


pgpDDL5dJhnH9.pgp
Description: PGP signature
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Openmoko Bug #1352: Some noise via headset

[Openmoko Public Trac]

#1352: Some noise via headset
---+
Reporter:  [EMAIL PROTECTED]  |Owner:  hardware
Type:  defect  |   Status:  assigned
Priority:  high|Milestone:  
   Component:  hardware|  Version:  current svn head
Severity:  normal  |   Resolution:  
Keywords:  | Haspatch:  0   
   Blockedby:  |Estimated:  
 Patchreview:  | Blocking:  
Reproducible:  |  
---+
Changes (by john_lee):

  * owner:  openmoko-kernel => hardware
  * status:  new => assigned
  * haspatch:  => 0
  * component:  openmoko-dialer => hardware


Comment:

 is this
 http://lists.openmoko.org/pipermail/hardware/2008-August/000415.html ?

-- 
Ticket URL: 
docs.openmoko.org 
openmoko trac
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[Joerg Reisenweber]

Am Mi  29. Oktober 2008 schrieb Angus Ainslie:
> On Wed, Oct 29, 2008 at 12:08 PM, Ole Kliemann <
> [EMAIL PROTECTED]> wrote:
> 
> > Hi Joerg and others,
> >
> > I haven't followed the whole thread as I only understand 1%. So just one
> > quick and dirty question:
> >
> > I have the two years EU warranty and am going to send my FR to my
> > distributor anyway because GPS is not working with the internal antenna.
> > (Independant of SD card.)
> >
> > So if I send it in, is there any fix that could be applied for the
> > buzz? Or is it worth to wait, say another week, because there will be
> > something then?
> >
> > And - if you allow me to be off-topic - is there any improvement fix for
> > the headphone jack? I mean this hipass-filtering issue making music
> > sound quite tinny.
> >
> > Thanks!
> > Ole
> >
> >
> Hi Ole,
> 
> I don't know whether Joerg has attempted the hardware fix yet.
Please see the whole thread to find we did quite a number of tests to verify 
it, in TPE.

> I finished 
> mine yesterday. Attaching the bead to the pad of pin 4 does NOT fix the GSM
> buzz issue.
Attaching the bead is *not* the fix exactly, cutting the connection from 
JK4401:4 to coppertrace is considered the fix.
Anyway it seems you tried to achieve this by cutting the contact from JK4401 
(your first picture). Alas it's not clear if you correctly isolated pin4-pad 
on PCB, so to me it looks like you soldered the bead on the pin4-pad and 
maybe you just shorted the tiny gap between PCB-pad and the metal-stub where 
you cut off pin4-contact on JK4401, while soldering the bead.

Cutting the contact sure is a good thing, anyway I recommend to isolate pin4 
PCB-pad by some plastic, so it is securely NC and in some distance to 
JK4401:4 metal spring. (see: 
http://people.openmoko.org/joerg/GSM_EMI_noise/noise_stopped_by_cut_pin4/JK4401_isolate_pin4__2.jpg
 )
Then do first test to find buzz is gone.
Then place bead to pad of R4404 NC, or even piggyback it to C4405, and connect 
to upper golden contact of JK4401, above pin4. (Please note you need the bead 
only for hs mic function, which may still be broken when using it during GSM 
RF activity)

/j



> 
> There are a couple of pictures.
> 
> Connector with pad 4 removed:
> 
> http://handheldshell.com/connector.jpg
> 
> It's a little hard to see, in this photo the bead is soldered standing up on
> pin4 with a jumper wire from the top of the bead to the side of the headset
> plug.
> 
> http://handheldshell.com/board.jpg
> 
> With this change the buzz is just as bad as ever.
> 
> Angus
> 
> -- 
> Angus Ainslie
> http://www.handheldshell.com/
> 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Openmoko Bug #1198: Audio (via headphone jack) doesn't couple well to some line-inputs

[Openmoko Public Trac]

#1198: Audio (via headphone jack) doesn't couple well to some line-inputs
---+
Reporter:  [EMAIL PROTECTED]  |Owner:  hardware
Type:  defect  |   Status:  assigned
Priority:  high|Milestone:  
   Component:  hardware|  Version:  GTA01Bv4
Severity:  normal  |   Resolution:  
Keywords:  | Haspatch:  0   
   Blockedby:  |Estimated:  
 Patchreview:  | Blocking:  
Reproducible:  |  
---+
Changes (by john_lee):

  * owner:  sean_chiang => hardware
  * haspatch:  => 0
  * component:  Audio => hardware


Comment:

 Hardware issue.  This also seems to be a problem on gta02.

-- 
Ticket URL: 
docs.openmoko.org 
openmoko trac
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA04 SoC/CPU and LCD size

[Joerg Reisenweber]

+1 
for some sort of transflexive screen that displays (a maybe somewhat reduced 
set of) information without backlit.

/j


Am Do  30. Oktober 2008 schrieb Alastair Johnson:
> Uwe Klein wrote:
> > Now for something completely different:
> > 
> > is a OLPC / Pixel Qi type reflective LCD an option?
> > http://www.pixelqi.com
> 
> I've been thinking the same thing. The poor daylight readability is the 
> only thing I don't like about the current screen, and is a real issue 
> when it's on my bike. Reduced power consumption would be a bonus.
> 
> ___
> hardware mailing list
> hardware@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/hardware
> 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA04 SoC/CPU and LCD size

[Alastair Johnson]

Uwe Klein wrote:
> Now for something completely different:
> 
> is a OLPC / Pixel Qi type reflective LCD an option?
> http://www.pixelqi.com

I've been thinking the same thing. The poor daylight readability is the 
only thing I don't like about the current screen, and is a real issue 
when it's on my bike. Reduced power consumption would be a bonus.

___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA04 SoC/CPU and LCD size

[Joop Boonen]

I think it would be great.
1) Low power.
2) High BW resolution
3) Sun light readability

Regards,

Joop.

> Now for something completely different:
>
> is a OLPC / Pixel Qi type reflective LCD an option?
> http://www.pixelqi.com
>
> uwe
>
> ___
> hardware mailing list
> hardware@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/hardware
>



___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[MarcO'Chapeau]

On Thu, 30 Oct 2008 12:11:47 +0200, Joerg Reisenweber <[EMAIL PROTECTED]>
wrote:
> Am Mi  29. Oktober 2008 schrieb Ole Kliemann:
>> Hi Joerg and others,
>> 
>> I haven't followed the whole thread as I only understand 1%. So just one
>> quick and dirty question:
>> 
>> I have the two years EU warranty and am going to send my FR to my
>> distributor anyway because GPS is not working with the internal antenna.
>> (Independant of SD card.)
>> 
>> So if I send it in, is there any fix that could be applied for the
>> buzz? Or is it worth to wait, say another week, because there will be
>> something then?
> 
> Seems you always could "upgrade" to the 'botch' fix found in A7 (It
> *should* 
> work, as our TPE engineers found it worth to implement in A7 ;-):
> 
> replace R4403: 0R -> 2k2
> add C4306: NC -> 100uF (probably you won't find a 100uF to fit in
anywhere,
> so 
> a 47uF might kinda suffice. C4306 pads aren't existent in A5/A6, but you
> can 
> use pads of NC R4304 which isn't mentioned in public schematics)
> 
> 
> 
> A _yet_unapproved_(!) variant is to use a LM336-2.5 in place of the huge 
> capacitor, and to 
> change R4305: 2k2-> 860R (to make LM336 operate on >400uA, when setting 
> MICBIAS to VDD*0.9)
> You also have to
> replace R4403: 0R -> 2k2
> In theory this rework should yield even better stabilization of MICBIAS 
> voltage, the path where ripple caused by GSM RF is introduced to audio
> path.
> See all but first 6 pics at
http://people.openmoko.org/joerg/buzzfix-lm336/
> (first 6 pics are a nasty approach to cut pin4 using some dremel-like
mill.
> 
> Those are not related to LM336 fix)
> 
> 
> 
>> 
>> And - if you allow me to be off-topic - is there any improvement fix for
>> the headphone jack? I mean this hipass-filtering issue making music
>> sound quite tinny.
> a) place some decent 100uF (or as high cap as feasible) parallel to C4110
> and 
> C4111. Make sure you don't create another contamination path for RF
> creeping 
> inside big can - maybe use a ferrite ring to block RF next hole where you

> route some wires from those big caps inside can to C4110/11.
> b) *short* C4110 / C4111, and insert the 100uF somewhere else in
audiopath,
> 
> b1)e.g. near R4405 / R4407 (you can even replace these R by 100uF 
> capacitors).
> You should remove R4117 and R4117 then, and instead place these 1k from 
> JK4401:pin2 and pin3 (! for JACK_INSERT function) to GND
> b2) or even place the 100uF outside FR in the housing of your hs-plug or 
> 2.5->3.5mm adapter
> 
> HTH
> cheers
> jOERG
>

Hi,

Given all the work that is being done on these issues, I do not doubt that
a solution will be eventually found. I'm pretty patient, and I can wait
till we get there.

There remains a question that still deserves a firm and clear answer
though. Will we be able to send our devices to the distributors or to some
customer care center to get those fixes applied ?

Do we have some form of warranty ?

Cheers,
-- Marc-Olivier Barre --
 --- MarcO'Chapeau 
- www.marcochapeau.org -

___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GTA04 SoC/CPU and LCD size

[Uwe Klein]

Now for something completely different:

is a OLPC / Pixel Qi type reflective LCD an option?
http://www.pixelqi.com

uwe

___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: GSM-noise "buzz" issue

[Joerg Reisenweber]

Am Mi  29. Oktober 2008 schrieb Ole Kliemann:
> Hi Joerg and others,
> 
> I haven't followed the whole thread as I only understand 1%. So just one
> quick and dirty question:
> 
> I have the two years EU warranty and am going to send my FR to my
> distributor anyway because GPS is not working with the internal antenna.
> (Independant of SD card.)
> 
> So if I send it in, is there any fix that could be applied for the
> buzz? Or is it worth to wait, say another week, because there will be
> something then?

Seems you always could "upgrade" to the 'botch' fix found in A7 (It *should* 
work, as our TPE engineers found it worth to implement in A7 ;-):

replace R4403: 0R -> 2k2
add C4306: NC -> 100uF (probably you won't find a 100uF to fit in anywhere, so 
a 47uF might kinda suffice. C4306 pads aren't existent in A5/A6, but you can 
use pads of NC R4304 which isn't mentioned in public schematics)



A _yet_unapproved_(!) variant is to use a LM336-2.5 in place of the huge 
capacitor, and to 
change R4305: 2k2-> 860R (to make LM336 operate on >400uA, when setting 
MICBIAS to VDD*0.9)
You also have to
replace R4403: 0R -> 2k2
In theory this rework should yield even better stabilization of MICBIAS 
voltage, the path where ripple caused by GSM RF is introduced to audio path.
See all but first 6 pics at http://people.openmoko.org/joerg/buzzfix-lm336/
(first 6 pics are a nasty approach to cut pin4 using some dremel-like mill. 
Those are not related to LM336 fix)



> 
> And - if you allow me to be off-topic - is there any improvement fix for
> the headphone jack? I mean this hipass-filtering issue making music
> sound quite tinny.
a) place some decent 100uF (or as high cap as feasible) parallel to C4110 and 
C4111. Make sure you don't create another contamination path for RF creeping 
inside big can - maybe use a ferrite ring to block RF next hole where you 
route some wires from those big caps inside can to C4110/11.
b) *short* C4110 / C4111, and insert the 100uF somewhere else in audiopath, 
b1)e.g. near R4405 / R4407 (you can even replace these R by 100uF 
capacitors).
You should remove R4117 and R4117 then, and instead place these 1k from 
JK4401:pin2 and pin3 (! for JACK_INSERT function) to GND
b2) or even place the 100uF outside FR in the housing of your hs-plug or 
2.5->3.5mm adapter

HTH
cheers
jOERG


signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: Microphone level & GSM-noise "buzz" issue

[Joerg Reisenweber]

Am Mi  29. Oktober 2008 schrieb Erland Lewin:
> Here is some speculation on the GSM buzz issue:
> 
> I was doing some testing today, calling my SIP number connected to my server
> and recording the audio.
> 
> Firstly, I have never been able to get a strong signal (high sample values)
> at the receiving end when calling from the Freerunner, despite trying
> various ALSA state files.
> 
> Today I tried holding the Freerunner flat in front of my face (as opposed to
> holding it with the earphone beside my ear. I got a significantly stronger
> signal at the other end with the microphone orientation like this. Not only
> did I get a stronger signal, but also a weaker background GSM buzz. My guess
> is that this is because the ALC (Automatic Level Control) of the Wolfson
> chip decreased the gain of the microphone amplifer whereby the GSM buzz also
> decreased.
> 
> Is the signal from the microphone in general is so low that the Wolfson chip
> needs to run at max gain (and still doesn't manage to get a very strong
> output signal)? And that this high gain makes the GSM buzz so loud (despite
> being fairly low on the input)?
> 
> Is there anything that could be done to increase the signal from the
> microphone? It seems to me like this might improve audio quality,
> transmitted audio level, and decrease GSM buzz. Is there a bias voltage that
> can be increased? Could the mic be replaced with a more sensitive one? By
> the way, is there a data sheet for the microphone?
> 
> Comments?
> 

there is no ALC involved inside Wolfson, on standard GSM-handset.state 
profile.
Your observations make perfect sense though, assuming the ALC is done on 
network side (or *inside* calypso chipset).
Alas there's very obviously nothing we can do via mixer settings to improve 
this situation.

cheers
jOERG



signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware

Re: USB-OVP

[Joerg Reisenweber]

Am Mi  29. Oktober 2008 schrieb silver62:
> 
> Hi,
> why there is a requirement for VCHGR_UNDSHT < 4V? If the voltage of charger
> fall below 4V when the charger is connected for 2 ms is this a big issue?
> 
> Regards,
> 
> Silvestro


I didn't write this spec ;-), but I guess it's to avoid possible oscillation 
caused by device detecting USB-removal due to Vusb < 4V and switching off USB 
power path.
Also note this is a USB2.0 complying spec, and USB2/USB-OTG uses Vusb 
modulation to signal certain status changes between host and device.

cheers
jOERG


> 
> 
> Joerg Reisenweber wrote:
> > 
> > FYI:
> > 
> > From http://www.usb.org/developers/devclass_docs/batt_charging_1_0.zip
> > 
> > -
> > Battery Charging
> > Specification
> >  Revision 1.0
> >   Mar 8, 2007
> > 
> > p.19:
> > If the current drawn from a USB charger changes suddenly within the range
> > of 
> > 0mA to 500mA, then the
> > transient voltage from a USB charger shall not go below VCHGR_UNDSHT.
> > Under no 
> > circumstances shall the
> > transient voltage of a USB charger exceed VCHGR_OVRSHT.
> > 
> > p.23:
> > Charger Overshoot Voltage VCHGR_OVRSHT 6.0 V max.
> > -
> > 
> > Though we couldn't even attach a USB-charger compliant to this spec, as it
> > has 
> > to be equipped with micro-USB plug, we should expect to see voltages on 
> > USB-receptacle of up to 6.0V AT LEAST.
> > 
> > I think it's a strong argument for additional OVP extending our actual 
> > abs.max.rating of 5.5V to limits safely beyond 6.0V, like we are actually 
> > about to do for GTA03.
> > 
> > cheers
> > jOERG
> > 
> >  
> > ___
> > hardware mailing list
> > hardware@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/hardware
> > 
> > 
> 
> -- 
> View this message in context: 
http://n2.nabble.com/USB-OVP-tp790003p1394138.html
> Sent from the Openmoko Hardware mailing list archive at Nabble.com.
> 
> 
> ___
> hardware mailing list
> hardware@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/hardware
> 




signature.asc
Description: This is a digitally signed message part.
___
hardware mailing list
hardware@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware