latest c139 build

Mychaela Falconia mychaela.falconia at
Tue Oct 25 17:00:16 UTC 2016

> sigh! personally if the firmware just ignored the camera and wlan stuff
> I'd be happy, but I don't doubt what you say, both about the replacement
> mboard route and using the hardware as is

If only the camera and WLAN stuff would just stand out of the way for
regular phone functionality...  But alas, it does NOT just stand out
of the way: the path to the display goes *through* the undocumented
SPCA552E camera chip, hence we have to deal with that nasty chip if we
want to put anything on the LCD or even turn it on.  I borrowed the
knowledge of how to do this part from OsmocomBB - and whoever figured
it out on their end has done a really heroic reverse eng effort to get
this far.

But the trouble does not stop there: when I tried to play with the
W56940 ringtone generator and loudspeaker driver chip (required if we
want to make the phone ring or to use the hands-free loudspeaker for
calls), I started tracing out the connections to this chip (OsmocomBB
folks never touched it, so I have to figure it all out on my own), and
I saw that the reset line to the ringtone chip comes from guess where:
from the same darned SPCA552E!  I did not try to go any further, as it
would be pointless without knowing how to control the reset line.

Well, OK, we may still be able to make the Pirelli phone vibrate even
if we can't make it ring: in the last couple of days I made a purely
accidental discovery (I was playing with the AT at SND debug command I
added to Magnetite fw) that Pirelli's vibrator is hooked up to the
Calypso output that was originally meant for the piezoelectric buzzer
(like on Mot C139), thus trying to ring the piezo buzzer on the Pirelli
turns on the vibrator instead.

But would you want a phone that can only vibrate but not ring on
incoming calls and SMS?  And the W56940 ringtone chip is not just for
ringing, one has to turn this chip on and do some magic to it in order
to use the loudspeaker for calls as well - and if we sacrifice the
hands-free loudspeaker function, that is one of the main advantages of
the Pirelli over the C139 for me personally...

> > I've also been doing some work on ringtones - I'll post an explanation
> > a little later, it's bedtime for me now.
> For me that's another issue - the Pirelli excels here, but the c139
> (at least the models I have) are so quiet I often don't hear a
> incoming call.

When I said I was working on ringtones, I wasn't talking about the
loudness of the ring, I was referring to the great technical challenges
involved in playing any kind of ringtone at all on our own phone, be
it our own hw+sw or just our own sw on alien hw - but since you've
mentioned ring loudness, for me that is another area where Pirelli's
proprietary fw is misdesigned.

One of the big problems I have with Pirelli's fw is that they have only
one volume setting that is global across all modes: the ring volume is
the same as the earpiece volume in calls, which is also the same as the
in-call volume in loudspeaker and headset modes.  So if I turn the ring
volume all the way up so I can hear it when I'm outside or when I may
be some distance from the phone, I then get a blast in my ear when I
make or answer a call, so I have to turn it down to talk comfortably -
and if I subsequently don't crank it all the way up again, I might not
hear it when it rings.  A huge defect for me.

What makes Pirelli's bug in this regard so ironic is that TI's reference
code already contains a proper solution to this very issue, as I have
also just discovered in the last couple of days.  Openmoko put a file
in their modem FFS (programmed into every unit on the production line)
called /aud/para0.cfg, and added the non-standard AT at AUL command that
requests the RiViera Audio Service fw component to load this audio
config - but this function has always been broken (AT at AUL always
returns ERROR and does nothing) even in their original moko10/11

As I was investigating this oddity, I learned that TI's Audio Service
requires these audio config files to come in pairs: for every *.cfg
there must also be a corresponding *.vol file, and it will refuse to
load the *.cfg if the corresponding *.vol is missing.  Because there
is no /aud/para0.vol in Openmoko's factory FFS programming (you can
now trivially add this file yourself with fc-fsio, but this is besides
the point), the programmed /aud/para0.cfg profile cannot be loaded and
this whole piece of functionality never comes into play.  Clearly
Openmoko Inc. did NOT have a Calypso modem engineer of my level on
their staff: they had the source for far longer than we have, and yet
they failed to do the job properly - draw your own conclusions..

And just why does TI's Audio Service require a volume file to come
along with every audio config file?  Answer: to solve the very same
problem that is exhibited by Pirelli's fw!  In TI's solution the
volume setting exists as a per-config datum: each audio mode has its
own corresponding volume setting, and whenever you turn the volume up
or down while in a particular mode, the Audio Service automatically
updates the *.vol file in FFS for your current mode.  If you then
switch modes, the volume instantly switches to the last saved setting
for the new mode, and when you switch back to your previous mode, that
mode's saved volume comes back.  They got it right!  Now why did
Foxconn (the makers of the Pirelli) not simply follow TI's reference..

This point about how Pirelli's and other production firmwares for
various historical Calypso-based phones always seem to do things
differently from how TI's reference fw does them comes back full circle
to our original problem: the code from TI for above-the-modem handset
functionality is utterly unfinished and unusable as-is, hence the
phone manufs had no choice but to finish themselves in their own ways
what TI failed to deliver..

But it gets even more complicated as TI's reference fw actually
contradicts itself in many places, i.e., different parts of the fw
(developed by different TI groups with very different coding styles)
exhibit different "vision" as to how things should work.  TI's Layer1
and all code in the RiViera land was developed in France, the G23M
protocol stack and ACI were developed in Germany (former Condat), and
the pathetic demo/prototype/reference UI code you've experienced with
FreeCalypso on the C139 was developed by Condat-UK turned TI-UK.

What is the "proper" or "canonical" way to produce ringtones on a
Calypso phone that is equipped with a loudspeaker instead of a piezo
buzzer?  Whatever answer the people at TI back in Those Days had in
mind, I don't know it, and the code we have strongly suggests that
different people at TI had very different ideas in this regard.  On
the one hand, the Calypso DSP and Layer1 supposedly provide a way to
generate melodies internally within the DSP itself (the so-called
Melody E1 and Melody E2 features), so the phone manuf won't need to do
anything more than hook up a "dumb" (purely analog) audio amplifier
between Iota's AUX output and the speaker - and automagically get a
loudspeaker that works for both ringtones and hands-free calls.

But I have never seen a real-life Calypso phone (well, OK, our
knowledge is limited to the set of models discovered and documented by
OsmocomBB, which is a very small sample, but still) that works this
way.  Instead the two Calypso phones in our known set that have
loudspeakers instead of piezo buzzers (Mot C155/156 and the Pirelli)
both use external MIDI player chips.  In Pirelli's case they seem to
have routed the Iota's headset output (not AUX) to both the headset
jack and their W56940 MIDI chip, and when their fw turns on the
loudspeaker for calls, it must be doing something to the primarily-
for-ringtones MIDI chip to make it amplify the external analog input
instead.  With Mot C155/156 it's even worse: Mot never listed hands-
free loudspeaker as a feature at all for this model, their fw offers
no such mode, and we don't know if it's an artificial fw limitation or
if there is some issue with the hw as well.

This loudspeaker ringtone generation issue will be a really sticky
point for us when we get to building our own Libre Dumbphone hardware,
but I'm going to leave this story for another day.


More information about the Community mailing list