FreeCalypso progress update

[Mychaela Falconia]

Hello FC community,

It's time for an update on the various things I am working on.  In no
particular order:

* I plan on getting my own oscilloscope for my home lab some time in
the next few weeks.  I don't have a close enough relationship with any
of the hardware people at my day job to use one of their scopes for my
personal project, thus in order to do any o'scope probing on our
FreeCalypso boards, I need to buy my own scope and set it up at home.
My preliminary accounting tells me that I have enough money to buy a
scope on ebay (I will have more accurate accounting when I come home
this weekend), but the expected delay of a few weeks is because of
physical space issues in the room at my home that serves as my
FreeCalypso hardware lab, and those space issues stem from the CMU200
problem.

I had to take my CMU200 apart in order to check the power levels at
the internal Tx path interface from the Rx/Tx board to the RF FE, and
right now it sits in my room in a dismantled state, taking up far more
space than it would if it were put back together.  I didn't want to
reassemble and then re-disassemble it a bunch of times, so I left it
in the dismantled state while waiting for a replacement Rx/Tx board.
That replacement module is on its way to me from a seller in Sweden,
but appears to be stuck at postal customs in New York. :-(

Once I get my own scope and learn how to use it, I plan on using it
for at least two purposes in our project: (1) probing to see if I can
spot a transient voltage drop on one of the power rails in connection
with the sleep mode self-reboot bug discussed on this list a few days
ago, and (2) investigating what should be a digital audio interface on
the MCSI pins in the so-called "Bluetooth headset" mode.

Having our FreeCalypso modem present a digital voice channel as an
alternative to the classic analog one is an important feature for some
of our prospective commercial users, and it is also an important
feature for us to use in convincing people like the Neo900 project to
offer a variant with our FreeCalypso modem instead of their usual
proprietary one: those proprietary modems do have digital voice
channel interfaces, and it is those digital interfaces, not analog,
that are used by projects like Neo900.  It appears that we can get a
digital voice interface out of the Calypso in the so-called "Bluetooth
headset" mode, and I feel that we should seize this opportunity.

The problem though is that this digital voice channel is something
that almost no one cared for back in the days when Calypso was current,
the capability appears to have been added as an afterthought in order
to support building Bluetooth-enabled dumbphones with the Calypso, and
the details aren't documented anywhere.  Therefore, we need to reverse-
engineer those details, and this reverse eng process will need to start
with putting an oscilloscope probe on the MCSI_CLK line to see if the
DSP code we are running (combination of the DSP ROM plus the downloaded
patch code we took from TCS211) puts the MCSI into clock master or
clock slave mode.

* I am waiting for some loudspeaker and microphone parts to arrive
from Digi-Key.  If they arrive on Friday like FedEx Ground tracking
says they should, then I hope to be able to test the loudspeaker
driver circuit on our FCDEV3B this Sunday and the microphone input
circuit the following week.

If the loudspeaker driver and microphone input circuits on our FCDEV3B
work, then I will feel comfortable with *finally* releasing the
assembly of the next batch of 12 boards.  Specifically, I plan on
*not* blocking this next batch assembly pending the resolution of the
sleep mode bug or pending the completion of the MCSI investigation.
Root-causing and solving the sleep mode bug may take a very long time
and lots of expensive trial and error, and it is not acceptable for
our entire project to remain blocked dead in the meantime.  Therefore,
we'll have to live with a software workaround in the form of disabling
sleep modes, much like Openmoko did with their bug #1024 for the two
years or so before they finally fixed it.  And for those who would
like to use our FCDEV3B modems stationary on a lab bench powered from
a supply which itself feeds on AC mains power, it won't make any
difference whether the modem has working sleep modes or not.

It similarly makes no sense to keep further board assembly on hold
while we figure out how the digital voice interface over MCSI works.
The mystery to be solved here is how our TCS211 DSP code configures
things inside the Calypso chip; at the board level we do nothing more
than bring the MCSI signals out to header pins, thus I do not expect
any problems at the board level when it comes to MCSI.

* As discussed on this list many times before, our current FCDEV3B was
originally designed to be a development board, not a module to be
integrated into other people's projects as a component - while it is
certainly possible to use it in the latter fashion, it is absolutely
not convenient.  Aside from FreeCalypso core developers, FCDEV3B
modems can be useful to certain specialized classes of end users,
specifically those who desire a fully open and tinkerable modem in a
"stationary mobile" application, i.e., physically stationary and
connected to a desktop PC or a server or somesuch, but accessing a GSM
network, e.g., to send and receive SMS or to make CSD calls.  But if
you are building something small and portable, akin to a smartphone,
and are in the market for a libre GSM modem module to incorporate into
your gadget, then our current FCDEV3B is totally in the wrong physical
form factor.

I have argued many times before that we should make a FreeCalypso
modem module in an SMT form factor similar to the mainstream
proprietary ones, but the devil is in the details.  If the problem is
approached in an open-ended manner, without any constraints, then
there is a near-infinite set of possibilities as to the form factor
(dimensions) of the module, its set of interface signals and the
specific form of its SMT physical interface, i.e., LGA, BGA,
castellated...  If we had to make all of these design decisions on our
own from scratch, it would be a daunting task to come up with a set of
choices that make good engineering sense.

Fortunately, I've got a major breakthrough in this direction: I found
a pre-existing historical commercial modem module of exactly the kind
we are talking about, with a Calypso chipset inside!  Take a look at
this datasheet:

ftp://ftp.freecalypso.org/pub/GSM/BenQ/BenQ_M32_ds.pdf

I originally found it back in 2011 when I first started gathering info
about the Calypso in connection with its use in the Neo FreeRunner;
looking at this datasheet and at the companion AT command document, it
is very obvious that this module has a Calypso+Iota chipset inside
(obvious from the names and descriptions of the hardware interface
signals in the datasheet), running TI-based firmware (obvious from the
AT command document which lists a bunch of TI's non-standard ones).

Even though I had originally found the above datasheet back in 2011,
it had slipped out of my mind over the years until I rediscovered it a
few days ago: I was looking through datasheets for various existing
packaged modem modules, gathering ideas for our own such module
design, until I re-stumbled across this BenQ M32.  Then a light bulb
went on in my head: what if we make our FreeCalypso SMT modem module
in exactly the same physical form factor as the historical one from
BenQ?  This way we'll be using a form factor and a set of interface
signal choices which are known to be good for the purpose of building
a modem module with Calypso inside.

But it gets even better: I found someone on ebay who has some of these
BenQ M32 modules available (and for dirt cheap too), and I bought 15
of them.  Now I need to wait for them to arrive, and once they arrive,
I will open one up for reverse eng - I haven't been able to find any
photos of the insides of this module with the top shield off, and I am
dying of curiosity to see what RF components are inside: we can deduce
the presence of Calypso and Iota from the interfaces in the datasheet,
but know nothing about the RF part so far except that it is triband
like Openmoko, Pirelli and our FCDEV3B - but there is a near-infinite
number of different ways to build a triband RFFE of this sort.

It might be possible to run our own FreeCalypso firmware on these
pre-existing historical M32 modules (won't know for sure until I get
one in my hands to pop open and see the RF components), but even if
such a port to the pre-existing historical hw is possible, it is not
my primary interest.  Instead my interest is in building our own semi-
clone of this modem module: not a 100% verbatim clone, but with some
hardware improvements, while keeping exactly the same physical form
factor and mostly the same interfaces.  What hardware improvements do
I envision relative to the historical M32?  At least two:

* If possible in terms of PCB layout and internal component placement
  constraints, make our modem quadband (using the magic M034F RF FEM
  from TI's Leonardo and E-Sample designs) instead of triband.

* MCSI signals on the Calypso are multiplexed with GPIOs (i.e., the
  pins can be set to be MCSI or GPIOs via config register bits), and
  the M32 datasheet refers to them primarily as GPIOs.  (Remember that
  in those days no one asked for a digital voice interface.)
  They have 3 of these MCSI/GPIO signals brought out on SMT interface
  pads, but the fourth one (MCSI_TXD/IO9, required for a working
  digital voice interface) is brought out only to a test point on the
  top side of the module, intended for an ancient weird test mode from
  the GSM 11.10 spec.  We will definitely need to fix this blunder and
  properly bring out all 4 MCSI signals on SMT interface pads on our
  semi-clone of this module.

These are my thoughts for the moment; off to bed now.

Hasta la Victoria, Siempre,
Mychaela aka The Mother