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@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community