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. März 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
