Can we fix the audio for A5/A6/A7?

[joerg]

Hi, Allen Chang

Am Di  1. April 2008 schrieb ALLEN_CHANG at fic.com.tw:
> 
> Hi Joery:
> 
> I think the root cause is about GSM download and test.

This is an issue completely unrelated to GSM download. It's all about highpass 
filter cutoff (-3dB) frequency f0=1/(2π RLCO) of the R-C highpass filter 
constituted by the 1uF capacitors(CO) and the 1kR resistors + load(RL) of 
headphones (which is supposed to be a standard of 32R !!)
Please have a look to the amp datasheet, it contains comprehensive discussion 
of this (though for selecting input C, it applies to output C as well)
Quote from a former mail of me, which i will attach fyi:
> With 1uF we might get weak bass anyway, even with highZ-headphones.
> From datasheet, p5:
>> Output coupling capacitor which blocks the DC voltage at the  
>> amplifier’s
>> output. Forms a high pass filter(!!!) with the single-ended load RL  
>> at fO =
>> 1/(2π RLCO).
> With e.g. *typical* (->ds, p.12) 32R-headphones, RL = 65 Ohm! Could  
> anybody
> check the Z for OM-headset?
> Please calculate f0 for this value!!!!!!

In attached mail, i calculated this f0 for a hypothetical headphone with 
infinite impedance, and i get 160Hz for -3dB f0. This means you can not 
connect *anything* to the headphone jack and expect to have any bass in 
sound. (with 1k impedance headphones -very rare to find- f0 is 320Hz! This is 
like phone POTS quality 400-4000Hz) Do the calculation yourself for 
32R-headphone!). Obviously for a device intended to be used as MP3-player / 
multimedia machine (among other uses) this isn't acceptable and to be 
considered a product breaker.


> If we can't resolve the issue,
The solution is plain simple: have bigger C (at least 47u).
Or completely redesign the audio circuit. :-(

> I think we don't add a big capacitor and connect directly to earphone's 
speaker ( make these capacitor to 0 ohm resistors) 

Very creative idea, not supported by application notes of amp though ;-). Alas 
i think the VDD/2 we expect to see at output of a push/pull complementary amp 
will break the jack_insert logic, the DL_GSM logic, the power saving rules 
and last not least quality of sound and maybe headphones/ears of user. Anyway 
if it really works AND improves quality of sound, it's surely one of the 
patents OM plans to register ;-)

There is no other way than having higher C in there. 
As long as i don't have hw to run tests against, as well as have no specs for 
OM-headphone (impedance?), i can not add any more better arguments to make 
the situation more clear. 
Please read the attached mails, at bottom, around "O== Components we MUST 
have" +/-30 lines


cheers
jOERG


> 
> -----Original Message-----
> From: Wolfgang Spraul [mailto:wolfgang at openmoko.com]
> Sent: 2008/4/1 [星期二] 下午 06:30
> To: joerg; ALLEN_CHANG (張吉隆)
> Cc: openmoko-kernel at lists.openmoko.org
> Subject: Re: Can we ifix the audio for A5/A6/A7? (was: Re: can we stop using 
the headphone jack for GSM download)
>  
> joerg,
> great explanation, thanks a lot.
> I talked to Allen Chang a bit, and he says:
> 
> 1. there is no way a 100uF cap will fit on A5/A6. Even goldcap etc.  
> won't work.
> 2. we could do an A7 with this change, but Allen doesn't believe the  
> 100uF will make the big improvement you believe it will do.
> 3. I asked Allen whether he can rework 1 prototype A5 with 100uF, but  
> he says it's very hard to do (plus #2 he doesn't believe in it much :-))
> 
> joerg & Allen - can you take this discussion from here? I forwaded the  
> mail including history to openmoko-kernel
> Best Regards,
> Wolfgang
> 
> On Apr 1, 2008, at 4:01 PM, joerg wrote:
> 
> > Hi all,
> >
> > (OP) Wolfgang Spraul:
> >> my understanding is that some of our **audio** problems with the  
> >> headphone
> >> jack come from the fact that we also use the headphone jack for GSM
> >> firmware download.
> > NO, THEY DO NOT!
> > Once more for maximum clarity:
> > When fixing the audio problem, there will be *NO* impact or  
> > interference with
> > current practice of using jack for gsm firmware download. (We keep  
> > the 33R!)
> >
> > Fixing audio just means replacing 1uF by 100uF. This needs PCB A7 to  
> > make
> > space for these capacitors, or we find a way to have 100uF on A5/A6.
> > NO IMPACT ON FIRMWARE DOWNLOAD VIA JACK. NO NEED TO CHANGE DL_GSM  
> > CIRCUITRY /
> > PRODUCTION FLASHING PROCEEDINGS. NO NEED TO GET RID OF AUDIO JACK.
> >
> > *IF* there are any problems in/while using the jack for *firmware*  
> > *download*
> > RIGHT NOW (in current production test), we have to ask better  
> > questions to
> > solve these problems. They can't be fixed by fixing audio.
> > If there is any issue, please report in detail so i may try to help.
> >
> > THE PROBLEM OF BAD AUDIO QUALITY IS NOT REALTED TO FIRMWARE DOWNLOAD.
> >
> >
> > Am Di  1. April 2008 schrieb Wolfgang Spraul:
> >> Tony, Sean Chiang -
> >> if what joerg says is true, it sounds like:
> >>
> >> 1. we don't need the ability to download GSM firmware via headphone
> >> jack for PRODUCTION USE even today?
> > Flashing firmware via the 2 testpoints works independently of audio  
> > jack.
> > We don't need it (that is if using jack was ok up til now).
> > If the testpoints are placed in a way they can't be reached, we  
> > obviously con
> > not us them.
> >
> >> 2. we only need the ability to download GSM firmware via headphone
> >> jack for R&D USE, where we could also switch to FLUID?
> > Please can somecone give me a pointer to FLUID?
> >
> >> 3. we can then improve the audio quality as an SMT change,
> > With minimal PCB redesign, the AUDIO problem can be solved.
> >
> >> maybe even
> >> for A5 and A6?
> > If we can find a way to have 100uF on current A5/6 PCB: YES.
> > Options (for A5/6):
> > o- find a capacitor that fits on footprint and yields 100uF (goldcap,
> > different formfactor, lower max voltage...)
> > o- find a way to mount capacitor with larger footprint (PCB backside  
> > mount,
> > wired mount, piggyback mount). Probably will not comply with needs  
> > of CAM/CNC
> > assembly, only feasible by manual rework.
> >
> > jOERG
> >
> >
> >>
> >> Can we clarify this?
> >> Wolfgang
> >>
> >> On Apr 1, 2008, at 7:01 AM, joerg wrote:
> >>
> >>> Am Mo  31. Marz 2008 schrieb Wolfgang Spraul:
> >>>> Sean Chiang, Willie,
> >>>>
> >>>> my understanding is that some of our audio problems with the
> >>>> headphone
> >>>> jack come from the fact that we also use the headphone jack for GSM
> >>>> firmware download in production.
> >>>
> >>> There a few problems caused by the fact the design of audio path was
> >>> done with
> >>> DL_GSM in mind. When i got this right, DL of GSM-FW will be
> >>> impossible or
> >>> less relyable when we replace the 33R with 0R in audio path. These  
> >>> 33R
> >>> introduce a volume attenuation of only -3dB for (supposedly  
> >>> standard)
> >>> 32T-headphones, and the same time 20mW of the 40mW output power / ch
> >>> are
> >>> burned in these Rs. Not nice but not really that much both values,
> >>> and I
> >>> wouldn't mind, as long as there is the reason of FW DL to keep these
> >>> 33R.
> >>>
> >>> The *big killer* are not the Rs, but the 1uF capacitors, in a
> >>> literal sense.
> >>> They kill frequencies below 160Hz when jack is virtually
> >>> opencircuit. With a
> >>> 32R-headphone connected this cutoff frequency f0(-3dB) jumps to some
> >>> absurdly
> >>> high 4-digit value (no use to exactly calculate this horror figure
> >>> now) which
> >>> will make the whole thing sound like a speaker box with killed bass
> >>> speaker
> >>> and only tweeter left.  OR maybe like listening to a "good" earphone
> >>> from
> >>> 50cm distance :-(((
> >>> The problem is these C are 1uF now, and must become ~100uF, which
> >>> have much
> >>> higher volume and larger footprint and simply don't fit on PCB with
> >>> current
> >>> layout (at least for SMT, might be assembled by hand with no  
> >>> technical
> >>> problems i guess. At least for a prototype).
> >>> Just a little pushing and squeezing on the layout to make space and
> >>> adapt pads
> >>> for footprint will solve the whole problem though. Probably can be
> >>> done
> >>> without any "topological" rerouting of PCB.
> >>>
> >>>
> >>>> So my first question would be: Can we stop using the headphone jack
> >>>> for GSM firmware download?
> >>>
> >>> We don't need to do this.
> >>>
> >>>
> >>>> Can we download the firmware by running FLUID on the Neo?
> >>>
> >>> Just for completeness:
> >>> I do not know what FLUID is. In GTA02A5 circuit diagram there are
> >>> instructions
> >>> on how firmware is supposed to be flashed during production process.
> >>> [quote]
> >>> In RD side, the download path is
> >>> 1`Download Jack insert
> >>> 2`Host detect pin 2 of JK4401 is low,download cable confirm.
> >>> 3`Host set /DL_GSM to low,download path is on.
> >>> In factory,the download path is
> >>> 1`Operator put on the PCBA to download fixture.
> >>> 2`Download directly through H_TP4401`H_TP4402.
> >>> [/quote]
> >>> The last three lines introduce a download procedure that's
> >>> independent of the
> >>> whole audio path, and should work unconditionally (from electronic
> >>> engineers
> >>> point of view), no matter what will happen to the audio components.
> >>> ***NB: There's no problem arising for DL_GSM from changing the Cs
> >>> 1uF ->
> >>> 100uF. Headphone jack method will continue to work and *no_need* to
> >>> change
> >>> production process for the firmware thing!***
> >>> (well I told similar regarding the Rs yesterday, so: Please would
> >>> someone
> >>> *doublecheck_all_my_findings*, as I have just only ONE way - reading
> >>> schematics - to get these results, I can't check then by e.g probing
> >>> the
> >>> hardware for now - don't have!)
> >>>
> >>>> Could we change the production process to switch to that method?
> >>>> I'm not saying that is what we want to do - I want to find out
> >>>> whether
> >>>> it's possible and how much work it would be?
> >>>>
> >>>> If we wanted to do this the steps would be:
> >>>>
> >>>> 1. Make our production process use FLUID instead of headphone  
> >>>> jack to
> >>>> upload GSM firmware
> >>> Not needed.
> >>>
> >>>> 2. remove GSM firmware download wiring from headphone jack (in
> >>>> schematics)
> >>> Not needed
> >>>
> >>>> 3. fix our headphone quality issues as described by joerg
> >>>> 4. make another board revision, A7
> >>> Push the other parts a little to get them out of the way, use 100uF
> >>> (or at
> >>> least 47u) instead of 1uF -> everything fine.
> >>> Or some cute hacker features a way to fit these 100uF to the
> >>> footprint of
> >>> current A6 layout...
> >>>
> >>> HTH
> >>> Regards
> >>> jOERG
> >>>
> >>
> >
> >
> 
> 
> 


-------------- next part --------------
An embedded message was scrubbed...
From: Wolfgang Spraul <wolfgang at openmoko.com>
Subject: Fwd: GTA02A5: bug in Headset Amp circuitry,
	max output power to headset
Date: Sun, 30 Mar 2008 12:16:43 +0800
Size: 11753
Url: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080402/7c438d04/attachment.eml