FC project update and hardware plan

[Spacefalcon the Outlaw]

Hello FreeCalypso community,

It's been quiet here for the past 3 weeks, so I thought I would give a
little update.

The FC firmware subproject still stands where it did at the beginning
of this month: running on either Openmoko's modem or the Pirelli DP-L10,
our gcc-built fw can access the SIM, connect to a live commercial GSM
network and send and receive SMS successfully, but voice calls fail.
Investigation into why voice calls fail led me to the conclusion that
we need to load the same DSP patches as the working TCS211 reference fw
(at least the static patch) before we can proceed further; I added that
static DSP patch and enabled its loading, but it doesn't work - the
checksum reported by the DSP is wrong, indicating that the patch must
be getting loaded incorrectly.

My plan of attack is to table this firmware subproject aside and switch
to the hardware subproject.  For a long time I've been wanting to build
a Calypso GSM development board that would serve as a platform for our
firmware development and hardware experimentation, and the issue we are
having right now with that DSP patch loading is a perfect excuse to
set the fw work aside for the moment and go build that board.  Trying
to debug the DSP patch bug using currently available hw would be a pita
because we don't have any available platform that both has JTAG and
can run TCS211: the latter can only run on the GTA02 modem, and JTAG
signals of the Calypso are completely inaccessible on that hw.  But if
we build the board I have in mind, we'll have a hardware platform that
can run TCS211 *and* provides JTAG access - just what we need.

So, what is this board I want to build?  Here is what I envision:

* Core Calypso chipset and RF section using the same "variable"
  components (RF PA, VCXO etc) and wired up exactly the same way as
  Openmoko's GTA02 modem, so we can run TCS211 on it with absolutely
  minimal surgery on the binary blobs;

* External connections for the battery-emulating power supply (VBAT)
  and for the antenna just like on TI's own historical development
  boards:

  https://www.freecalypso.org/boards/d-sample.jpeg

* Both Calypso UARTs brought out on headers, ditto for the JTAG and
  MCSI debug interfaces;

* An on-board SIM socket (obvious), a microphone and a loudspeaker for
  voice testing, connected to the respective connection points on the
  core chipset.

So how do we go about building this board?  Well, I got the schematic
design already started:

https://bitbucket.org/falconian/freecalypso-schem
https://bitbucket.org/falconian/ueda-linux

I already got the schematic design of the core section captured in my
non-graphical "schematic" language (a novel reuse of the structural
subset of Verilog, as in just wires and hierarchy instantiations), but
I have yet to capture the peripherals (connectors etc) outside of the
core section.

OK, so that's the schematic design, which is just the first half of a
board design project.  What about the other half - PCB layout?  Well,
I searched high and low for a surviving copy of TI's original layout
for their Leonardo reference board (2003-2004 timeframe), but I came
up empty-handed. :(  That reference layout appears to have been lost
in the cracks of time and obscurity. :(  But thankfully we have a
fully preserved copy of Openmoko's PCB layout for their GTA02, which
was recently released by Sean Moss-Pultz (the founder of Openmoko)
upon my request:

ftp://ftp.freecalypso.org/pub/GSM/GTA02/GTA02-MB-A6.zip

Openmoko's PCB layout was done in PADS; the ZIP cited above contains
the original PADS file, a PDF print and the full set of gerbers.  I
can think of 3 possible ways how we could produce a PCB layout for our
FreeCalypso GSM development board based on Openmoko's:

1. If some member of our community has access to a working installation
   of PADS (a version that can successfully open and edit the PCB file
   we got from Openmoko) and is a PCB design engineer who is comfortable
   with that software, perhaps we could load Openmoko's layout into
   PADS, remove all of Openmoko's components outside of the Calypso
   modem block, add the components and connections we need (external
   power and debug connectors etc) and generate our gerbers from there.

   Advantage: most direct reuse of Openmoko's known-good PCB design,
   including all of the GHz RF critical sections.

   Disadvantage: PADS is proprietary software. :(

2. We could redraw Openmoko's PCB layout from their gerbers in a FLOSS
   EDA tool of our choice, but still copy their layout verbatim,
   millimeter for millimeter, trace for trace, via for via.

   Advantage: we would break out from the clutches of a proprietary
   EDA format while preserving the known-good PCB design as with
   option 1.

   Disadvantage: while I can't speak from experience as I don't do any
   PCB layout work myself (see below), I can only imagine that trying
   to reproduce an existing layout millimeter for millimeter etc while
   manually redrawing it in a new program would probably be an
   incredible pain.  An additional problem with reproducing Openmoko's
   layout verbatim in FLOSS PCB is that the former uses blind and
   buried vias which the latter does not support at the moment.

3. We could create a new layout of our own from scratch, working from
   the ueda-generated netlist and an approximate component placement
   guide, copying only the known-good footprints from Openmoko's PADS
   layout.  (Redraw the latter in FLOSS PCB using Openmoko's gerbers
   as the reference.)

   Advantage: a work flow most similar to how new PCB design is
   conventionally done, without the added pressure of having to
   reproduce something old that was done in a foreign tool.

   Disadvantage: no real reuse of Openmoko's known-good Calypso modem
   layout (GHz RF and all) beyond part footprints; whatever quirks
   need to be accounted for in the PCB design in order for this thing
   to work, we'll have to rediscover by trial and error - possibly
   quite expensive trial and error involving board respins.

Which brings me to - I am delighted to see that my old acquaintance
Ineiev has joined our mailing list.  Welcome, dear comrade!  Ineiev is
a PCB design engineer whose work I can vouch for, as he did the PCB
layout for my OSDCU board: a CSU/DSU that converts SDSL (Symmetric DSL
aka Slow DSL aka Spacefalcon DSL) into EIA-530 (essentially the same
as V.35), including software-mediated conversion from ATM into HDLC.
The board is an Open Source Hardware design which you can find here:

ftp://ftp.freecalypso.org/pub/net/PHY/SDSL/OSDCU/

I designed the board at the schematics+BOM level, and when I was
looking for someone I could afford to hire to do the PCB layout (I was
born with a brain that excels at just about any task that can be
reduced to lines of ASCII text, but totally sucks at anything graphical
or visual, hence asking me to do my own PCB layout would be like asking
a blind person to pilot an airplane), Ineiev offered to do it for a
very affordable price - not because he is cheap, but because he
supports Open Source Hardware!

So Ineiev, would you be interested in doing the PCB layout of our
FreeCalypso GSM development board using any of the 3 approaches
outlined above?

Finally, this board design proposal won't be complete without a
discussion of the triband vs quadband dilemma.  TI had a quadband
reference design in the form of Leonardo+ (the E-Sample board for
their later Calypso+ chipset was also quadband AFAICT), but every
commercial phone or modem manufacturer to my knowledge reduced it to
either 2 bands (single-region, EU-only or US-only) or triband (2 EU
bands + 1 US band, or rarely vice-versa).  Openmoko did likewise:
hobbled the modem down from quadband to triband.  I could never
understand the reason for this hobbling: if they had a working quadband
reference design which they could just mindlessly copy, why did they
go out of their way to redesign the RF front end for fewer bands?
Just corporate malice?  But then why did Openmoko do likewise?

Building a GSM device that is anything less than quadband means that
someone would have to be excluded, and naturally I don't want to
exclude anyone.  It doesn't really matter so much for the development
board which we need to build now: making it Openmoko-like and Pirelli-
like 900/1800/1900 MHz triband (850 MHz band excluded) will be
sufficient for firmware development, PA power draw characterization,
gaining experience with RF calibration and other developer-only uses I
have in mind for this board.  But when we graduate to building libre
phones and modems for end users, I would really like to make them
quadband if at all possible.

The only way I know of how to build a quadband GSM device with the
Calypso chipset is to use this magic component for the RF front end:

ftp://ftp.freecalypso.org/pub/GSM/Calypso/M034F.pdf

as depicted on the historical Leonardo schematics:

ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_plus_quadband_schem.pdf
ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_plus_RD122.pdf

I do have those elusive Epcos M034F parts on hand physically, so we
could try building a board with this RFFE and see how well (or not so
well) it will work.  If I could find a surviving copy of TI's original
PCB layout corresponding to either of the schematic versions cited
above, I would have sent the gerbers to fab (w/o any changes at all
for the first trial version) and found some answers empirically by now
- but alas, no such surviving copy of that layout could be found; it
appears to have been irretrievably lost. :(

The only part of the original Leonardo+ quadband PCB layout that has
survived is the component placement drawing that must have been
exported from their PCB layout program; this drawing can be found at
end of Leonardo_plus_RD122.pdf, after the schematics.

The question facing us right now is whether we should make our first
development board triband following Openmoko or quadband following
Leonardo.  Look at how the core components of the chipset are arranged
in Openmoko's modem vs how they are arranged in the Leonardo component
placement drawing - they are completely different.  Furthermore, I am
rather clueless when it comes to GHz RF PCB layout, but in all existing
designs I've examined, the traces that carry the Tx output from the PA
to the antenna switch and the trace from the latter to the actual
antenna connection point are all on the top layer, are very short and
direct, and don't cross.  I can only assume that such layout is
required for proper operation.

The pinout of the Epcos M034F magic component needed for the quadband
config is such that if we tried to plop it directly into Openmoko's
layout in the place of Om's triband RFFE, there would be no way to do
it without messing the RF layout up badly: either the PA output traces
or the antenna trace would have to go through vias and an inner layer
(which I'm guessing is probably a bad idea), and the Rx differential
outputs won't connect cleanly to where they need to go.  It really
seems to me that if we were to go the quadband route with M034F, the
overall PCB layout would need to be entirely different: it would need
to follow the Leonardo component placement drawing, rather than
Openmoko's arrangement.

So Ineiev, this question is really for you - if you end up doing the
PCB layout of our board, which approach are you more comfortable with:
copying Openmoko's known-working layout as close to verbatim as
possible, which would necessarily include retaining the triband RFFE
for this first prototype, or going directly to the ambitious quadband
experiment and having to redo the layout mostly from scratch, with
only the surviving Leonardo component placement drawing as a guide?

Of course if any other members of our community have some experience
with GHz RF PCB design and see flaws or gaps in my reasoning, or if
you are considering volunteering to do the PCB layout we need, please
speak up as well. :)

Happy hacking,
Mychaela Falconia aka Space Falcon

P.S. For Ineiev or other newcomers to this list who know me from the
past but may not have heard the news of my big change yet, please see:

https://www.freecalypso.org/pipermail/community/2015-May/000016.html