Can we ifix the audio for A5/A6/A7? (was: Re: can we stop using the headphone jack for GSM download)
wolfgang at openmoko.com
Tue Apr 1 12:30:18 CEST 2008
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.
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
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
>> 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
> 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*
> 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
> 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
> wired mount, piggyback mount). Probably will not comply with needs
> of CAM/CNC
> assembly, only feasible by manual rework.
>> Can we clarify this?
>> On Apr 1, 2008, at 7:01 AM, joerg wrote:
>>> Am Mo 31. März 2008 schrieb Wolfgang Spraul:
>>>> Sean Chiang, Willie,
>>>> my understanding is that some of our audio problems with the
>>>> 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
>>> introduce a volume attenuation of only -3dB for (supposedly
>>> 32T-headphones, and the same time 20mW of the 40mW output power / ch
>>> 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
>>> 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
>>> 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
>>> and only tweeter left. OR maybe like listening to a "good" earphone
>>> 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
>>> layout (at least for SMT, might be assembled by hand with no
>>> 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
>>> 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
>>> on how firmware is supposed to be flashed during production process.
>>> 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.
>>> The last three lines introduce a download procedure that's
>>> independent of the
>>> whole audio path, and should work unconditionally (from electronic
>>> 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
>>> production process for the firmware thing!***
>>> (well I told similar regarding the Rs yesterday, so: Please would
>>> *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
>>> 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
>>>> 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
>>> 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...
More information about the openmoko-kernel