Can we ifix the audio for A5/A6/A7? (was: Re: can we stop using the headphone jack for GSM download)

Tue Apr 1 12:43:31 CEST 2008

Hi Joery:

I think the root cause is about GSM download and test.
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)

Best Wish 
  Allen Chang

-----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 HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080401/feb6a99b/attachment.htm 