Hi, Allen Chang
Am Di 1. April 2008 schrieb [EMAIL PROTECTED]:
>
> 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:[EMAIL PROTECTED]
> Sent: 2008/4/1 [星期二] 下午 06:30
> To: joerg; ALLEN_CHANG (張吉隆)
> Cc: [email protected]
> 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
> >>>
> >>
> >
> >
>
>
>
--- Begin Message ---
Teenie, Tim Lee -
same as before, please look into this.
Thanks,
Wolfgang
Begin forwarded message:
From: joerg <[EMAIL PROTECTED]>
Date: March 30, 2008 10:45:59 AM GMT+08:00
To: [email protected]
Cc: Andy Green <[EMAIL PROTECTED]>, Wolfgang Spraul <[EMAIL PROTECTED]
>
Subject: GTA02A5: bug in Headset Amp circuitry, max output power to
headset
To make things worse and this a real bug, we have 1kR R4116,R4117 as
additional load after the Cs, in parallel to the speakers of headset.
(No, these Rs are ok, they just make things worse wrt small
capacitors)
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!!!!!!
So even with some headset with "infinite" Z, my result for above
equation is
f0=~160Hz still, which is not acceptable for high quality sound
(IMHO not for
music playback at all!). This means you can't even connect your home
stereo
to the earphone outlet to get usable sound, it also will drop
[EMAIL PROTECTED]
This much for frequency response. Now for volume:
With 3.3V power for amp, we won't even get as few as around 1mW(!)
Po(max) to
the headset speakers for Z(speaker) = 1kR, single ended amp. No matter
whether there is a 33R series resistor, this limits *maximum* volume
to
possibly <80 dB Sound Pressure Level, depending on sensitivity of
headset.
This also isn't acceptable for high quality sound. A headset amp
should be
able to power any headset with at least 10~20mW.
By choosing a headset with even higher Z loudness decreases, with
lower Z low
cutoff frequency increases ([EMAIL PROTECTED] for 1kR
headset!!!!!!!!!!!!!!!!!!!).
Ergo: this design is definitely broken. There is simply *no* headset
that
yields _good_ sound quality with NEO. The vast majority of
headsets/headphones will probably not work at all. In fact the
headset outlet
itself cuts frequencies below 160Hz, this gets worse when you connect
anything.
Fix:
O== Components we MUST have
6.8uF C minimum for 1kR internal + highZ(>>1k) external load, like
amp input /
active speakers, so we at least have one chance to get good audio
signal
directly out of Freerunner by any means.
O== ...We SHOULD have
For [EMAIL PROTECTED] with a load of 65R (internal 33R + std low impedance
headset) we
need 47uF.
For tradeoff power against low cutoff frequency, we should keep the
33R series
resistors, thus shifting f0 from 100Hz to 50Hz for the usual 32R-
headphone,
and still having a comfortable 20mW for high sensitive earphones
with >80dB
SPL / mW.
O== ...nice to have
If we can have C >= 100uF, we should use 0R series (1R gets
hot(0.5W) on
short), thus allowing to connect to common passive stereo computer
satelite
speakers, with option active subwoofer, and drive them with a nice
300mW.
With 32R-HP we really get HiFi with C>100uF.
For a future design i suggest to insert a similar highpass (plus
f0=1Hz
lowpass, to compensate offset) to R4112/R4115 feedback path, to
compensate
frequency response. Or switch from U-amp design to I-amp (feedback
current,
not voltage)
cheers
jOERG
--- End Message ---
