digital audio to FCDEV3B

Tue Jan 3 02:25:42 UTC 2017

Hi Mychaela,

Thank you very much for explanations.
I guessed that VSP looks like a private interface, however MCSI is not very
well explained in the docs, so I clearly overlooked this option.

I will look into BT application for proper SPI parameters and data formats.
If you could suggest any docs on FTP to aid this activity it will be
greatly appreciated.
Since I will never use analog audio, the hardcoded MCSI configuration will
be sufficient for now.

Right now I'm working on the application architecture with the goal to keep
firmware changes at the bare minimum and contain them in the conditional
compilation statements treated as "features".

BTW do you have mechanical drawings of FCDEV3B with positions of mounting
holes and headers? I could not find it on FTP. I was thinking to start
working on the standalone enclosure and mounting brackets for integrated
installation.

Thanks,

-Serg

On Mon, Jan 2, 2017 at 10:17 AM, Mychaela Falconia <
mychaela.falconia at gmail.com> wrote:

> 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~
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community
>