FCDEV3B status update

[Mychaela Falconia]

Hello FC community,

Here is an update on the status of the long-overdue FCDEV3B project.
Starting with the easy part:

* Using the $1075.77 check I received from GoFundMe, corresponding to
  the first $1170 raised in the campaign, I have placed the orders for
  all of the missing parts.  Some of these parts are on backorder, but
  they should all arrive while we work on the other steps below.

* I got an email from GoFundMe this morning, saying that they are
  sending me another check for $920.70, corresponding to the most
  recent very generous $1000 donation by Kevin - thank you once again!
  Once I receive this check, I will use it to order the reballing of
  the Spansion S71PL129NC0HFW4B BGAs.  This is the high-capacity
  (maximum addressable with the Calypso) flash+pSRAM chip we are going
  to use, same as in the Pirelli DP-L10, but the parts could only be
  obtained with RoHS solder balls, whereas I'm going to use real SnPb
  solder for the FCDEV3B reflow assembly.  Hence these BGAs need to be
  reballed; there are companies that provide such services, but they
  are a little pricey.

After the two steps above are taken care of and out of the way, we are
down to the big one: ordering PCB fabrication.  For this step we'll
need somewhere around $2300 to $2600 USD, depending on which surface
finish option we order - I will ask the assembly people for their
recommendation and go with what they say, as they will need to be able
to populate the parts on these boards.  This money has NOT been raised
yet, so we need to collect more donations before we'll be able to make
this big step.

Next, an update on the status of the design files.  Those of you who
have been following this project since late 2015 / early 2016 will
remember that the way in which the board design has come into being
and its resulting quality status are both extremely murky.

The core modem design is supposed to be a near-verbatim reuse of the
one from Openmoko, but unfortunately a certain intermediary has muddied
the waters.  Openmoko's PCB design was done in PADS; we have the PADS
files, but we still needed a PCB layout engineer to transform Om's
board into what we need: remove all non-modem components, change the
board shape to simple rectangular, add the new peripheral circuits
(mostly interface connectors), etc.

Back in late 2015 / early 2016 a certain group of people at an
anonymous company stepped forward to do this layout editing job on a
barter basis in exchange for some FreeCalypso-related software
consulting I was doing for them, and the FCDEV3B design we have today
is the result of their work.  There is one giant fly in this ointment,
however.  Instead of doing the board design in PADS (Openmoko's
original software) or perhaps translating the design into something
FLOSS like KiCad, they chose to translate the design from PADS into
the most evil of all proprietary PCB design packages: Altium.

The conversion from PADS to Altium produced a ton of errors, i.e.,
various features of the design have been mistranslated in a myriad of
places.  But instead of seeing this translation as fundamentally faulty
and untrustworthy, the people in question proceded to do all of the new
layout work for the FCDEV3B in Altium on top of this mistranslation.
In the early months of 2016 we went back and forth a lot, they would
send me gerber files, I would see errors all over the place, I would
reply to them, telling them to fix this and that, and they would send
me new gerber files.

In April-May of this year I had what I believed to be fab-ready design
files: to the best of my visual inspection ability in a gerber viewer,
all of the defects introduced by PADS->Altium mistranslation were
fixed.  But then one of the PCB fabs from whom I requested fabrication
price quotes flagged a serious error: the clearances between the auto-
computed GND copper pours and the surrounding non-GND copper objects
were too small in some places, smaller than the design rule of 4 mil
(0.1016 mm) minimum space.

Fast-forwarding to the present, I have paid a handsome sum of money
(my own personal funds, *not* from the crowdfunding campaign) to one
fine gentleman in Colorado to fix this critical defect; he also
persuaded me to change a few other things while at it, and here is the
result:

ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/fcdev3b/ggg/

There are still a few nitpicks I would like to fix - I am still in
negotiations with John (the Altium PCB layout consultant in Colorado)
regarding the feasibility and cost of these fixes - as usual, the
issues to be fixed are a defect introduced by the people who moved the
design from PADS to Altium in direct disregard of my protests.

To the best of my understanding of the physics involved, the still-
outstanding defects (the clearings in the GND copper pour on the inner
layer directly underneath the surface layer with microstrip traces
have been moved a little from their original coordinates) are NOT
expected to be show-stoppers.  In other words, if we were to fab the
boards from the current gerber files in the FTP directory linked
above, I expect that they should still work, barring the other risk
factors listed below.  The worst possible effect I anticipate from
getting the boards built from the current gerbers without fixing the
GND copper pour cutout coordinates defect is that the RF performance
in the Rx path may be slightly degraded.  Thus it would be nice to get
this defect fixed, but if we have to fab the boards without the fix,
we should still get something that will work well enough to shake out
high-level firmware bugs in the deblobbed TCS2/TCS3 hybrid config.
I am hoping to be able to fix the defects while we wait for the funds
needed for PCB fabrication to be raised.

Now let's review the risks involved in this project.  There is always
a risk that we may spend all this money only to get non-working boards.
Here are the risk factors:

* Calypso chips and many of the associated components have not been
  made new for some years and are not available through any "official"
  channels.  Instead the only source for these components is the
  Chinese grey market - I presume them to be surplus from the days
  when mass-produced phones were made with this chipset and the
  associated surrounding components.  The parts in my stash have been
  bought from Jotrin (www.jotrin.com) - one of the apparently many
  vendors in this market.  I have heard of other people who have
  successfully built their own Calypso GSM devices (for some
  proprietary non-public applications, apparently), and I presume that
  they used the same kind of grey market sources as we are using - as
  there are no other sources - so I most sincerely hope that the
  Calypso chips and other critical parts in my stash are good.  But
  there is absolutely no way to know for sure if they are good or not
  until we spend the money to fab the PCBs and populate these parts on
  those PCBs.

* This is my first board project of this level of complexity.  I don't
  have any prior experience with building boards with HDI features,
  precisely defined complex layer stack-ups and controlled impedances.
  Here I seek to copy all of these parameters unchanged from Openmoko's
  GTA02: thanks to Mr. Sean Moss-Pultz graciously donating the big pile
  of design files, we have what looks like the correct document.  But
  of course we don't know for certain if this document is really
  correct, and we won't know until we spend the money and see if the
  resulting boards work.  I also don't have any prior experience with
  ordering such complex boards and properly communicating all of the
  requirements to the fabricator - and of course PCB fabricators can
  only do what you tell them to do.

* I have very thoroughly reviewed the parts of the FCDEV3B design which
  were meant to be preserved unchanged from Openmoko and oversaw the
  fixing of a myriad of defects introduced by the PADS-to-Altium
  people.  At this point I consider it quite unlikely that any killer
  defect is still there, but the possibility cannot be ruled out with
  100% certainty.

In summary, the level of risk involved in this board project is quite
high, but we have to do it - there is no other way.  I am not willing
to be forever limited to the existing Motorola, Openmoko and Pirelli
hardware, hence the goal of a 100% libre phone will not be reached
without building our own hardware for as long as I am the only
developer.  If someone disagrees with my insistence on building our
own hardware and would rather work on the existing hw, feel free to
dive into the code yourself - it's all in the open.

Finally, regarding the big bone in our collective throat known as
Altium.  As already discussed here, the FCDEV3B which we are seeking
to build currently is not our last board, but only the first.  We
already know that we'll need to start working on the next board
shortly afterward: another Calypso board with the same core chipset,
but adding the LCD, the keypad and hopefully the rest of the hardware
features needed in a complete handset: battery charging circuit, USB
port that combines charging with serial access, separate earpiece and
loudspeaker circuits, headset jack and the associated circuits, etc.

My plan is to free ourselves from the chains of Altium with our next
board by going back to Openmoko's original and translating it from
PADS into KiCad.  Yes, KiCad - a *free software* PCB design tool, as
opposed to the status-quo proprietary stuff.  Up until recently I saw
no practically feasible way to do cellular boards with free sw tools
because of my personal bias.  In the world of free sw EDA tools, there
are two chief competitors: geda-pcb and KiCad.  I have always been
very heavily biased in favor of geda-pcb (my "first love" in this
realm, so to speak), to the point that I wasn't willing to even look
at KiCad.  But there is a problem with this personal bias of mine:
geda-pcb currently lacks the features needed to do cellular boards of
the Calypso kind (the missing features are blind/buried vias and
copper pours), and the changes required to add these missing features
to geda-pcb would be so massive that they aren't likely to happen any
time soon.  But unlike geda-pcb, KiCad already supports these two
critical features today - hence it *is* suitable for doing cellular
board designs.

KiCad may not be my personal favourite (it is not as Unixy as geda-pcb,
i.e., it caters to more "modern" tastes), but it is Free Software,
hence it is still an infinitely better choice than using status-quo
proprietary software like PADS and Altium, proprietary sw for which
there is no source, which requires M$ Windows and which operates on
undocumented binary file formats.

I plan on moving the "hardware division" of FreeCalypso into KiCad by
writing my own translator from PADS to KiCad, custom-made for the
specific job of translating Openmoko's GTA02 PCB design, or rather the
specific portion of this PCB design that is of interest to us.  We
already have the GTA02 PCB design in PADS' ASCII format in addition to
the native binary, PADS' ASCII format is documented and I have already
studied it extensively, and I am confident in my ability to translate
into some FLOSS PCB tool that has the necessary capabilities - and it
looks like KiCad fits the bill.

Of course a translation from PADS to KiCad would only give us the
starting point from Openmoko, and not any of the new layout done for
the FCDEV3B.  I reason that we can tolerate this loss for our next
board because I don't expect much of this FCDEV3B new layout to carry
over anyway: it will need to be changed, so we may as well restart
from the GTA02 baseline and finally put behind us all of the enormous
pain inflicted upon us by the PADS-to-Altium people.

I have considered moving the FCDEV3B to KiCad as well, either by
developing an Altium->KiCad translator in addition to (or instead of)
PADS->KiCad, or by restarting from the GTA02 starting point and redoing
the FCDEV3B layout anew in KiCad, but either way it would be a massive
project - so I don't think it would be acceptable to delay the FCDEV3B
by however long such a project would take.  Hence I feel that we have
to fab the FCDEV3B from Altium, PADS-to-Altium introduced defects and
all, and hope for the best.  In the worst case, if we build the FCDEV3B
this way and it doesn't work as well as we would like, we could then do
FCDEV3B V2 in KiCad...

Until next time,
Mychaela aka The Mother