digital audio to FCDEV3B

[Mychaela Falconia]

Hi Serg!

> I'm looking for a way to connect FCDEV3B (given that it will be available
> at some point) to an external system which is going to make and receive GSM
> voice calls. The easy way would be to connect it via analog AUXI and AUXOP
> interfaces available in Iota, however it would be a bit inefficient when
> source and consumer of the audio is all digital.

Indeed using an analog voice interface to connect a Calypso GSM modem
to an all-digital external voice system would be highly inefficient,
introducing needless loss of quality in the extraneous D->A->D
conversion in *each direction* of the call.  Furthermore, the specific
method you propose in the quoted paragraph (using the AUXI and
AUXON/AUXOP analog interfaces) won't be possible on the FCDEV3B as it
is currently designed and being produced, as these interfaces are not
brought out.

Instead the external voice interface which *is* brought out on the
FCDEV3B is MCSI, described below, and it's a digital interface, not
analog.  On the analog side of things, instead of bringing analog
interfaces out externally, the FCDEV3B design includes on-board
loudspeaker and microphone circuits for exercising voice calls in the
simplest possible manner.

> I see that Iota is connected directly to LEAD SPI (DSP core). And also Iota
> is driving the interface by sending 500kHz clock signal and VFS, when
> bi-directional DX/DR serial transfer of 16-bit words is initiated. Do we
> know if there is any way to intercept data transferred here and replace it
> with encoded audio from/to the host system? I could not find any way to do
> it from Calypso nor Iota side.
> Alternatively it would be nice to be able to disconnect Iota VSP using a
> jumper exposed on an external header and let an external system to
> encode/decode data and implement SPI master hardware, which is available as
> an FPGA IP as an example.

The VSP interface was intended by TI to be a "private" interface
between their DBB and ABB chips, and was never meant to have external
users interfacing to it.  And once again, the FCDEV3B as it is
currently designed and being produced does NOT include any provisions
for tapping or intercepting or redirecting this interface - the signals
in question run directly from one BGA to the other; this part is the
circuit remains unchanged from Openmoko's modem on which our design is
based, which was in turn based on TI's Leonardo reference design.

However, back when Calypso was current stuff, TI did provide an
_official_ way to connect an external digital voice channel to a
Calypso GSM modem, and this "proper" way *is* supported on the FCDEV3B.
This "official" way works as follows: the Calypso DSP is switched into
the so-called "Bluetooth headset" mode, and the external digital voice
channel appears on the Calypso chip's MCSI pins.  (MCSI, not VSP!)
These MCSI pins are brought out to a header on the FCDEV3B.

Why did they call it the Bluetooth headset mode?  Answer: when TI
supported phone manufs making Bluetooth-enabled dumbphones with their
Calypso, Calypso+ and LoCosto chips, the MCSI interface was connected
to the Bluetooth chip.  GSM is digital, Bluetooth is digital (AFAIK),
hence when a GSM phone is used with a BT headset to make a voice call,
the objective is to pass the digital voice between natively-digital
GSM and natively-digital BT without an extraneous intermediate analog
conversion, i.e., exactly the same goal as yours.

How does one switch the Calypso DSP into the "BT headset" mode so that
the digital voice channel coming out of the DSP moves from the Iota-
connected VSP to the externally-brought-out MCSI?  Answer: by setting
the right control bits in the d_audio_init DSP API word in the DSP's
NDB page.  These bits are defined in the audio_include/l1audio_const.h
header file; look for B_GSM_ONLY, B_BT_CORDLESS and B_BT_HEADSET
definitions.  B_GSM_ONLY is the "vanilla" configuration in which the
GSM voice channel is connected to Iota analog hardware, "BT cordless"
is the configuration in which GSM is not used at all and the BT voice
channel (MCSI) is connected to the local analog hardware via the Iota
(not really interesting to us), and "BT headset" is the configuration
we are after: GSM voice channel connected to MCSI.

In TI's official TCS211 firmware for the Calypso, the proper high-level
way to cause the "BT headset" mode to be activated in the DSP is to go
through the RiViera Audio Service, usually by way of an audio mode file
written into the FFS (flash file system) and activated with an
audio_mode_load() call.  Openmoko added a non-standard AT command to
their fw that exercises this audio_mode_load() call, but their
implementation is broken because they didn't know what they were doing:
it is pretty obvious that they never had a Calypso modem firmware
engineer of my level on their staff. :)  I plan on fixing this command
to work properly in our Magnetite firmware after the FCDEV3B is built.

However, I also know from our previous discussions that you are more
interested in FreeCalypso Citrine than in FC Magnetite, and also that
your end application requires some very significant departures from
the classic self-contained GSM phone/modem architecture - I assume
that you and your team are or will be developing your own custom
firmware, using FC Citrine as your starting point.  One hitch that you
will encounter with your approach (or rather with the approach which I
assume you'll be taking) is that the abovementioned RiViera Audio
Service firmware component is currently not present at all in the
Citrine version, and the L1 audio layer on top of which it sits hasn't
been deblobbed yet, i.e., the L1 audio code will need to be
reconstructed from TCS211 binary objects and the LoCosto source before
this chunk of functionality will become available in blob-free fw
versions.

But there is a shortcut which you might be able to take.  If you will
always operate the Calypso modem with the voice channel routed to MCSI,
i.e., never use Iota analog audio hardware and have no need for dynamic
switching between the two configurations, you may be able to just
change the initialization in l1audio_init.c from B_GSM_ONLY to
B_BT_HEADSET and be done with it.

I propose that we test all of the above possibilities (both the
"official" way of going through RiViera Audio Service in the Magnetite
environment and direct hacking of the DSP setup in Citrine) *after*
the FCDEV3B has been built.  Speaking of the devil, here is the
current status with FCDEV3B production: right now I am waiting for
PCBCart (www.pcbcart.com, the PCB fab I'm currently trying to use) to
get back to me with their review of the FCDEV3B gerber files and the
price quotes to produce the boards with two possible surface finish
options: either selective OSP/ENIG (OSP for the SMT pads, ENIG for the
plated through holes) or ENIG throughout.

Explanation: back in early 2016 I was attracted to PCBCart because
their automated board quoting web form can give instant price quotes
even complex boards like ours; with most fabs quotes for such complex
boards can only be custom-prepared.  PCBCart's automated quote form
supports several surface finish choices including HASL, OSP and ENIG,
and I was using the quotes from that form as the basis for my cost
projections as to how much money we needed.  However:

* The auto-generated quote for the ENIG option (Electroless Nickel,
  Immersion Gold) is contingent on the gold-plated area being no more
  than 15% of the board, otherwise the cost goes up - but they can
  only know after a manual review;

* There is no option for selective OSP/ENIG in the automated quoting
  web form.

Selective OSP/ENIG (OSP for SMT pads, ENIG for plated through holes,
test points and connect-by-pressure pads which our board doesn't have)
has been the standard in the cellular industry at least in the Calypso
days: all pre-existing Calypso boards whose surface finish is known to
me (Openmoko GTA02, Pirelli DP-L10 and TI's E-Sample development board)
were made with this OSP/ENIG combination.  Note that this set includes
not only commercial mass-produced products (Openmoko and Pirelli), but
also a development board from TI - the E-Sample.  Furthermore, the
E-Sample dates from 2004, so it appears that their choice of OSP+ENIG
over HASL was not a RoHS-ism, but perhaps motivated by HASL being
poorly suited for fine-pitch micro-BGAs, even without any deplorable
RoHS stipulations.  Thus I decided that following "the canon" and
using the same OSP+ENIG combo for our FCDEV3B is probably our safest
choice.

I hope that using selective finish (OSP for SMT pads, ENIG for PTH)
will be cheaper than using ENIG throughout, as the former means lesser
amount of expensive gold needed, but OTOH it might be more expensive
because of the increased number of process steps.  Hence I decided to
ask PCBCart for the price of both options and then decide.  But right
now the problem is that they are being awfully slow with getting back
to me: I submitted everything to them back on Wednesday, Dec 28
(China time), expected to get a quote back in a few hours, but when I
asked after a day of silence, I got this reply:

: Maybe it will take several days. Our technician now is checking your file.

Several days when it should take hours??  WTF...  In any case, I'll
ping them again in a few days, and if they keep stalling, I'll have to
start looking at other fabs.  The anonymous person who donated the
3000 EUR (converted to just a little over 3000 USD by the receiving
bank on my end), the money which is to be used to cover the PCB
fabrication cost, told me that they (I don't know this anonymous
person's gender) knew of another good Chinese PCB fab, thus if PCBCart
keep stalling or come back with some price that is way higher than
what their automated quote form said initially, I will go back to that
donor and ask them about their other fab recommendation.

> I checked an option to handle TCH data directly by bypassing the vocoder,
> however I would like to take advantage of available hardware. Handling TCH
> directly would be okay, but it will tax the host system resources and
> require more strict UART data prioritization in order to keep codec data
> flowing. Also for better compatibility we would need to implement more
> codec variants including FR/HR and possibly AMR.

The TCH rerouting hack is *not* a recommended way to connect external
voice channels to a FreeCalypso GSM modem; it is only a hack and
nothing more.

M~