FCDEV3B status update

[Mychaela Falconia]

Hello FreeCalypso community,

I have written the first draft of the FCDEV3B User's Manual that covers
the current state of the hardware and firmware.  You can read it here:

https://www.freecalypso.org/members/falcon/fcdev3b/fcdev3b-userman-1.5.pdf

Anyone who is considering buying an FCDEV3B should read this manual so
you know exactly what you'll be getting and what you'll be able to do
with it.  At the present time we have just two hardware blemishes,
i.e., defects relative to the original design intent:

* The sleep mode bug is still there, but it is hidden from the user by
  both Citrine and Magnetite firmwares being built with DISABLE_SLEEP=1.
  Given that these are development boards, they will almost always be
  powered from a supply that ultimately comes from AC mains power,
  rather than a battery, hence it is very unlikely that having sleep
  modes disabled will have any practical negative impact on any users,
  but from my perspective as the Mother, I need to get to the bottom
  of this sleep mode bug before we can use the FCDEV3B design as a
  basis for further FreeCalypso hardware product designs.

* The loudspeaker acoustic volume is much quieter than I was hoping for.

When it comes to the speaker loudness issue, I need to emphasize that
the FCDEV3B was designed to be a development board, i.e., a platform
for FreeCalypso firmware developers, rather than a building-block
component for people to integrate into their whatever designs.  If I
had been making a building-block modem module, I would have simply
brought out the analog audio signals as they come out of the Iota
chip, without additional amplifier circuits, and let the user decide
what to do with them - that's what I am going to do on the FCM01
(FreeCalypso modem in the SMT module form factor copied from BenQ M32)
if anyone ever steps forth to fund that idea.  But that is not what we
have on the FCDEV3B - instead the FCDEV3B has an extra audio amplifier
circuit (copied from TI's Leonardo schematics) between the EARN&EARP
output from the Iota ABB and the two-post header where one can actually
connect a loudspeaker.

The reason why that extra amplifier circuit is there is because of my
FC-fw-developer-oriented design intent: I wanted to make the speaker
loud enough so that I (with my FC firmware developer hat on) can make
test calls during fw development and testing iterations with the board
sitting on a lab bench in front of me (and not held up to my ear), and
still be able to comfortably hear the call downlink audio.  A 32 ohm
earpiece speaker of the kind that the Iota ABB can drive directly
won't be loud enough for such usage, hence the extra audio amplifier
circuit to drive a beefier 8 ohm loudspeaker.

I know that what I want is possible because TI did it on their
D-Sample platform - a platform specifically for firmware development,
just like my design intent for the FCDEV3B.  The D-Sample has the same
Calypso+Iota chipset as our FCDEV3B and other FC targets (the different
RF is besides the point), and TI must have used an external amplifier
between one of Iota's outputs (can't tell which one) and the speaker
in the handset part of the kit similar to the one in the Leonardo
schematics.  When I power the D-Sample board from the same supply as I
use for the FCDEV3B (remember that our choice of the big orange power
input connector was copied from TI's own development boards), get it
connected to the network and make a test call, I can comfortably hear
the call downlink audio while sitting in front of the lab bench with
the hardware setup, without lifting the D-Sample handset part out of
its cradle.

But the Soberton SP-1510 speaker (part picked arbitrarily from
Digi-Key) I have tried connecting to our current FCDEV3B boards is
much quieter: the acoustic volume I get out of it is what I would
expect from a 32 ohm earpiece speaker driven directly by the Iota ABB,
not from an 8 ohm speaker driven by an external amplifier.  Obviously
I am missing something, but then I readily admit that I am essentially
clueless when it comes to audio and speakers.

I've got an idea for an experiment to shed some light on this speaker
loudness mystery by narrowing down the diffs between our FCDEV3B and
TI's D-Sample.  On the D-Sample the speaker resides in the handset
part, and this handset is attached to the main board via a DB44
connector (44 pins in 3 rows in a DB-sized shell).  While we don't
have any schematics for the D-Sample, we have such for the I-Sample,
as well as a PADS PCB file for the E-Sample.  The handset part hasn't
changed much in this development platform evolution, so we know with
reasonably good confidence which pins on that interface carry the
loudspeaker and microphone wires.

I have just ordered a free-hanging (solder cup termination) female
DB44 connector from Digi-Key, to mate with the male connector on the
D-Sample handset part.  When this female connector arrives, I am going
to solder wires to the pins where I expect the speaker connection to
be and connect the other end of these wires to speaker connector J312
on the FCDEV3B, with the effect of connecting the loudspeaker driver
circuit on our board to TI's D-Sample handset speaker.  Then check the
resulting acoustic loudness.  The objective of this experiment is to
differentiate between poor choice of the physical speaker part vs.
issues in our loudspeaker driver circuit.

So that's on the speaker loudness issue.  When it comes to the sleep
mode bug (the other defect), my plan of attack is to narrow down the
diffs between Openmoko's working original and our defective semi-clone
thereof.  I have already ruled out the power supply vs. directly
attached battery hypothesis proposed by Kent del Pino - I ruled it out
by taking a bare GTA02 motherboard sans case (I got two such boards as
scrap from GolDeliCo), powering it from a bench PSU via long wires and
not-so-great alligator clips on the contacts meant for the battery,
and observing that the sleep mode bug does not occur - while it does
occur on FCDEV3B boards powered from the same PSU.  The big tantalum
cap at C323 which Kent has been picking on is also not the problem, as
the D-Sample board has exactly the same arrangement with the same cap
in singular quantity, using the same power input connector as we use,
but does not exhibit the sleep mode bug.

My next experiment will be to buy another batch of Calypso and Iota
chips from my trusty Chinese supplier, this time with RoHS balls (the
ones I have on hand from 2013 which have been used for the current
board builds have SnPb balls), and build another batch of FCDEV3B
boards with RoHS solder.  Chips with SnPb solder balls can't be a
problem in themselves, as they are used on the D-Sample board from
2002 which does not suffer from the sleep mode bug, but perhaps I got
chips from a bad batch.  Openmoko used RoHS chips and solder, hence it
is one more diff between their version and ours which we should try
eliminating.

If we build another batch of FCDEV3B boards with RoHS chips and solder
but the sleep mode bug remains, the next experiment will be to populate
Openmoko's original Samsung K5A3281 flash+RAM chip instead of our much
larger Spansion S71PL129NC0HFW4B copied from the Pirelli DP-L10.  If
changing to the smaller flash+RAM chip makes the sleep mode bug go
away, it does not mean that I would be happy to give up the extra RAM
and flash capacity, but having the culprit narrowed down would greatly
aid further work toward a solution.  Please remember that the Pirelli
DP-L10 which uses the exact same huge flash+pSRAM chip does not
exhibit the sleep mode bug.

With these thoughts, I am off to bed.

Hasta la Victoria, Siempre,
Mychaela aka The Mother