Tentative plan: FreeCalypso modem end-use product

[Mychaela Falconia]

Hello FreeCalypso community,

I have some ideas about what we may be able to do after we get our
FCDEV3B built, and I would like to run these ideas by all of you.

The FCDEV3B has always been intended as a *development* board, rather
than an end-use product of any kind.  IOW, it has been my intent that
these boards will be used by developers (either core FC developers or
new community members taking on tasks of a development or experimental
nature) for developer tasks (FC firmware development and/or experimental
discovery of those Calypso hardware features which are insufficiently
documented, like the current MCSI discussion), rather than for any kind
of end use.

But what is the end outcome of all this development activity?  Back in
my home country we had steel mills that made steel for building more
steel mills; while I readily admit that I do oftentimes enjoy hacking
for the sake of hacking, I am also hoping to see our FreeCalypso
family of projects produce some end-use products as well.

As discussed on this list many times before, there are two fundamental
classes of end products that can be made with the Calypso chipset:
phones and modems.  And as we've also discussed numerous times before,
the firmware we've inherited from our predecessors at TI and Openmoko
is much better suited for the modem configuration than the dumbphone
one.  Hence I continue to feel strongly that we should use our firmware
advantage to produce a fully finished, commercial quality GSM+GPRS
libre modem end product in addition to the more nebulous and less
certain quest to produce a much more complex FreeCalypso dumbphone.

It *will* be possible to use the FCDEV3B as a modem board for end-use
applications, even though such use is not what I originally envisioned
- but it won't be very convenient.  The on-board loudspeaker and
microphone circuits on the FCDEV3B (copied from TI's Leonardo which I
sought to recreate) are intended for the usage scenario where a
FreeCalypso firmware developer has this board on a lab bench in front
of her, needs to make a test voice call, and would like the convenience
of directly hearing the downlink audio out the loudspeaker and speaking
into an on-board microphone for uplink testing.  But these circuits
will almost certainly be useless for anyone who would like to use our
board as a modem module in some larger system.  For such users, we'll
have the option of producing boards with these circuit components
unpopulated to avoid part waste.

Next comes the power-up process.  Originally coming from the dumbphone
world and later adapted for modem applications, TI's GSM chipsets
(like all other classic ones) expect an explicit power-on request
separate from the appearance of "battery" power.  This power-on request
needs to take the form of the PWON pin (on the Iota chip) being briefly
shorted to ground, then released - on a classic dumbphone this sequence
corresponds to the human user depressing the power button, then
releasing it.  Just like on TI's historical Leonardo board which I
sought to recreate, there is a physical user pushbutton on the FCDEV3B,
shorting PWON to GND.  A FreeCalypso developer working with one of
these boards on a lab bench will need to physically press this button
with her finger (or a stylus) to command the Calypso to boot.  But of
course this approach won't work too well if one desires to use the
modem board as a component in a larger system.

There is a two-post header on the FCDEV3B, wired in parallel with the
PWON pushbutton switch; one can put a shorting block on these header
pins, but I don't know if TI's chipset and firmware will be happy with
the power button being effectively pressed down forever, rather than
pressed and released as normally expected - yet another thing to be
tested experimentally once we get the development boards built.  In
Openmoko's smartphones, the AP would simulate the PWON button press to
the Calypso modem, but their Linux kernel code which accomplishes this
feat simulates a button press and release sequence, rather than holding
the PWON "button" down forever.  Hence you may need to connect a relay
or transistor circuit to the PWON header that does the trick - see
Openmoko schematics for a working example.

Finally, my choice of connectors for the power input (copied from TI's
historical development boards), for the two UARTs and for MCSI should
be compatible with any potential end-use modem application, but none
of these choices were made with end-use convenience in mind, only FC
developer convenience.

All of the above brings me to the following proposal: once we get the
FCDEV3B built and proven working, and after we complete all of the
experiments (MCSI learning etc) planned for this development board,
let's build an end-use-oriented commercial FreeCalypso modem product
next - an actual product intended for end use as a production modem,
rather than a development board.

So what form factor would our proposed commercial FreeCalypso modem
take?  Look at all of the mainstream (unfortunately 100% closed and
proprietary) commercial GSM modem modules for M2M/IoT applications:
they all take the form of physically small modules intended to be
soldered onto the user's application board as if the module were a
chip.  Most take the BGA/LGA approach, with solderable pads or solder
balls on the bottom of the module, so that it reflow-solders onto the
user's board like a really big BGA/LGA chip, but some use the
castellated module approach, with half-cut holes along the sides which
are used as soldering connection points.

I propose that we make our future (after the FCDEV3B) end-use-oriented
modem in the form of a castellated module.  We won't have a huge number
of signals to bring out (about 30), so I figure it should be possible
to bring all of the modem's external interface signals (which would
include analog EARN&EARP and MICIN&MICIP as well as digital MCSI for
the voice channel) to castellated holes around the perimeter, which
will serve as connection points.  Functionally it will be just like
the core of the FCDEV3B (which in turn is a copy of Openmoko's modem
block with a couple of minor fixes), but without the developer-oriented
(TI Leonardo-inspired) peripheral circuits.  For the antenna connection,
I'm thinking about putting a u.fl connector on the top of the module,
just outside the shieldcan, and having users use u.fl pigtails as is
commonly done with WiFi modules.  Most commercial GSM modem modules
bring the antenna connection on one of the bottom pads like other
signals, but my GHz RF-fu is not good enough to do that feat right;
a u.fl connector on the top would be a safer approach, even if it's
less popular among mainstream commercial products in this sector.

Once we produce the core modem as a solder-onto-another-board
castellated module, there will be endless possibilities for it to be
repackaged into any other convenient form factor (either by us or by
anyone else) by way of breakout or carrier boards: we'll have one
simple carrier board that brings everything out to connectors just
like the FCDEV3B (but with PWON etc better thought-out for end use
applications), and we can let others build trivial adapter boards that
would turn our modem into an Arduino shield or a Beagle cape or
whatever they have for RPi...

Having a fully commercialized FreeCalypso modem end-use product would
provide us with an official primary target for our modem (as opposed
to dumbphone) firmware builds: Openmoko devices are discontinued-ware
receding into history, the FCDEV3B is merely a development board
rather than an end-use product, but having an official modem product
of the end-use kind would finally fill the void.  And then we can
start working on the dumbphone prototype...

But all of these plans are purely hypothetical for now.  Before we can
take any steps at all toward what I just outlined, we need to complete
the following milestones first:

* Get the FCDEV3B built and working, proving our core design and the
  quality of the components, some of which can only be sourced from
  the grey market;

* Get the MCSI situation figured out experimentally: we need to know
  how it works and prove it working for our needs before we can
  comtemplate building a commercial modem product that offers a digital
  voice channel by way of MCSI;

* Develop the RF calibration process.  All historical commercial
  Calypso-based GSM devices have been RF-calibrated at the factory,
  i.e., some RF parameters that differ from each individual unit to
  the next have been measured and recorded in the flash file system on
  a per-unit basis on the factory production line.  In order to be no
  worse, we need to replicate this process, and the climbing of the
  necessary learning curve would be done more sensibly on the
  development board, before advancing to building the next product.
  We will need to deblob the l1tm code that handles RF test modes
  involved in the calibration process, learn the associated TM3
  protocol commands, and add support for these commands to our fc-tmsh
  host utility.  Then acquire the necessary external RF test equipment
  and learn how to use it.

It is possible to run a Calypso GSM device without RF calibration;
such uncalibrated radio operation happens whenever you run FreeCalypso
firmware on one of Mot C1xx targets (Mot/Compal moved their calibration
data from TI's standard format into their own proprietary flash data
structure which we don't know how to grok), and also whenever you run
OsmocomBB on any target, as they don't know how to use RF calibration
values at all, even when they are stored in TI's standard format.  So
far I haven't had a situation where I couldn't connect to a GSM network
at all because of the lack of calibration, thus I hope that we should
be able to do high-level GSM fw development and testing on the FCDEV3B
before we climb the calibration learning curve, but I would argue that
we *will* need calibration before we can seriously talk about a
commercial product.

So these are my thoughts - comments, opinions, flames?

Hasta la Victoria, Siempre,
The Mother