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