FC audio mode progress

Mychaela Falconia mychaela.falconia at gmail.com
Tue Nov 9 21:52:53 UTC 2021


Das Signal wrote:

> After doing the necessary soldering work and connecting the wires to the
> DUART28, here is the result of the fc-tmsh commands you listed:

I have analyzed these read results, and added the new data and analysis
to our freecalypso-reveng Hg repository - look under compal/audio.

At some later time I am also going to replicate this C139 soldered
UART connection setup on my end - but there is no particular urgency
to it, which is why I haven't done it yet.  I just looked at the label
on the Digi-Key plastic bag containing Molex crimp terminals which I
use to assemble female connectors that mate with header pins on various
development boards, and it says they are rated for the full range from
24AWG down to 30AWG - and my Molex crimping tool is rated likewise -
thus I should be able to crimp them directly onto the little 30AWG
wires coming out of the hacked C139, without having to make a
transition to a larger wire gauge with extra solder joints in the
middle of each wire connection.

I do prefer to get those 30AWG wires in 3 different colors, though, as
otherwise the probability of making a wire order mistake goes way up.
The approach I am thinking of is to get 30AWG wires in 3 different
colors first, then assemble the crimped end, i.e., the mounted-on-wires
crimp-assembled female connector that will plug into DUART28 as a
solid piece.  And then take this wire assembly and a C139 phone to
Technotronix and ask my friends there to solder 30AWG wire ends to the
production test pads inside the phone.  But given the lack of urgency,
I am waiting until I have a need to order something else from Digi-Key,
so I can add those colored 30AWG wires to the same order.

Audio tuning bits gathered from both C139 and Pirelli phones (both the
ones which our dear DS just provided and the ones I have collected
earlier) help improve our understanding of how previous commercially
successful Calypso-based phone models had their audio tracts tuned by
their respective historical manufacturers.  By collecting these audio
tuning bits from two different models by two different manufacturers
with different technical architectures (C139 and Pirelli), we can get
a better idea of what the general industry standards were in the era
which we seek to recreate.  Between these two historical reference
models, I generally choose to copy Pirelli's way for FreeCalypso - but
in some instances it helps to see how Pirelli's way compares to more
mainstream manufacturers of that day, hence the desire to look at C139
as well.

One of the next coming-up-soon audio reverse eng tasks in my plan
involves DSP-generated audio tones.  All standard phone UI designs
include various conditions in which the phone emits some beeps or
tones beyond just ringtones: there is the keyclick tone, there are
DTMF tones, there are call waiting and busy etc tones, and so forth.
Ringing alert sounds (ringtones) are special in that they are generated
using either a dedicated buzzer or a loudspeaker - it's a loud noise
as intended - but other UI tones are different.  Non-ringing UI tones
(keyclicks and others) are generated through the regular audio path,
without turning on the loudspeaker or the buzzer, and in the idle
state they emanate from the earpiece speaker.

In our Calypso chipset all such UI tones are generated in the DSP: the
"keybeep" and "tones" functional blocks in our Calypso DSP generate
arbitrary programmed tones up to 2000 Hz, half of the Nyquist
frequency.  (Melody E1 mechanism used for ringtones can also produce
tones in the upper half of the frequency range, where the cosine of
omega goes negative, but not the more basic "keybeep" and "tones"
audio tasks.)  Furthermore, these DSP-generated tones can be produced
at any desired amplitude as in dBfs.  So the question now becomes: at
what dBfs amplitude _should_ these tones be sounded?

TI's TCS211 delivery includes a glue layer of "Condat drivers" that
sits between their demo/prototype/PoC UI code and the solid chipsetsw
layers underneath.  The "audio" driver in this Condat glue layer
implements several DSP-based tones: keyclick, DTMF, call waiting, busy
and ringback - the latter is used only when the GSM network does not
provide an in-band ringback tone on TCH during the call alerting
phase.  However, the dBfs amplitude at which these tones are sounded
has NOT been tuned very well in this demo/prototype/PoC from TI: it is
way too loud in most cases.  Or more precisely, the amplitude of the
keybeep tone seems to be correct for the classic handheld configuration
(the sound emanates from the earpiece speaker, but the phone is away
from the user's ear at the moment, as keyclicks happen in response to
button presses), but is wrong for most other cases.

My current idea is to get a detailed view of how these various tones
are implemented on Pirelli DP-L10.  Pirelli's fw is a close derivative
of TCS211, and it has seemingly-all classic TCS211 L1 traces in readily
recognizable form.  And sure enough, if I enable keyclick sounds in
Pirelli's menu, I start seeing KBP_R or TON_R (for plain keyclick or
DTMF) traces in rvtdump or rvinterf.  The next step will be to do a
more systematic study: capture these traces for every exercisable
sound in each of the 3 audio modes (handheld, headset and loudspeaker,
if possible), and thoroughly analyze them.  Start with Pirelli DP-L10
because it is easier, and depending on what we discover, possibly then
look at Mot C139 too in this regard.  Stay tuned!

Hasta la Victoria, Siempre,
Mychaela aka The Mother


More information about the Community mailing list