From mychaela.falconia at gmail.com Mon Mar 11 10:17:36 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 11 Mar 2019 02:17:36 -0800 Subject: New RF changes and discoveries Message-ID: Hello FC community, Over the past week or so I did a bunch of RF tests with our CMU200 instrument that have resulted in a few changes to our FC firmware and some knowledge gains: * On TI's older Clara RF platform (RF 10) the AGC range went from 6 to 50 dB, whereas on the Rita chip used in all Calypso devices we work with this AGC range has been reduced, now going from 14 to 40 dB. I am guessing that TI made this simplification change to their RF silicon because the narrower AGC range is sufficient with the improved baseband ADC resolution in the Iota ABB compared to Nausica. However, as I was reviewing some AGC-related code in L1, I caught a bug that was made by TI back when they first introduced RF 12 (Rita) support, and that was apparently never caught back in the days when Calypso was active, neither by TI nor by any of TI-based phone manufacturers: the low_agc field in the T_AGC structure in l1_rf12.c was set to 6, which is not a valid AGC value for Rita RF, with the valid range being [14,40]. This number was clearly an overlooked remnant from l1_rf10.c for Clara RF, where it is correct. The effect of this bug is that when the cell search process was doing power measurements in "low AGC" mode, the AGC would get effectively set to 14 dB (the lowest possible value on Rita RF), but the higher level control code assumed it was 6 dB, with the measurement results being off by 8 dB. I fixed this bug by changing the low_agc number to 14 for Rita RF. * This weekend I was finally able to confirm through CMU200 testing that the tables of Tx ramp templates we got from Openmoko (extracted from OM's l1_cust.obj blob) are indeed correct for our OM-based RF hardware on our current FCDEV3B boards. When the CMU200 analyses the Tx signal put out by the DUT, it reports whether the power ramp meets or violates official spec tolerances, and in my FCDEV3B testing it showed passing ramp for every power control level in each of the 3 bands we support. We will probably never know whether TI-Taiwan customized these Tx ramp templates for FIC's choice of RF3166 PA or if they were calibrated on a TI Leonardo board with an RF3133 PA and required no changes for RF3166 (OM could not have changed these numbers themselves, as they got this part as an object blob from TI-TW), but whatever the history, at least we know that they are correct for our current hw, which is a big relief. * Through further CMU200 testing of several different Calypso-based target devices which we support, I also confirmed what I previously suspected: aside from possible cases of two closely related PA models from the same vendor, every different PA type requires different Tx ramp templates in order to produce correct power ramp in the final RF Tx output. Right now in our current FC firmware we have 3 different sets of Tx ramp template tables: one for our own FC hardware (from OM), another for Mot C139/140, and a third one for Mot C11x/12x and C155/156. The last one is the most recent addition: until a couple of days ago we used Mot C139/140 Tx ramp templates on all Mot C1xx targets, but my CMU200 tests this weekend revealed that these templates which Compal must have calibrated for their SKY77325 PA on Mot C139/140 do NOT produce correct RF Tx output on the older C1xx subfamilies with an older SKY77324 PA - yes, just one digit difference in the PA part number! Given that we have got two recent changes to the numbers in l1_rf12.c (the low_agc change affecting all Rita platforms and the change of Tx ramp template tables for Mot C11x/12x and C155/156), I have put out a new binary release for FC on C1xx: ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/c1xx-fcmag-20190311.tar.bz2 For C139/140 the only effective change from the previous 20190129 release is the low_agc change (all Calypso-based phone manufs back in the days lived with this bug all those years without ever noticing it, so the impact is *very* minor), but if you playing with FreeCalypso VPM (voice pseudo-modem) on Mot C11x/12x or C155/156, you definitely need to update, as the previous incorrect Tx ramp templates result in non-compliant RF Tx output. I am also going to make a new production fw release for FCDEV3B (incorporating the low_agc fix) when I make the next batch of boards, but there is no urgency, as this low_agc fix is totally non-critical. In other news, I will soon be adding support for one more historical Calypso phone target: Sony Ericsson J100. This phone was made by Compal just like Mot C1xx, all technical details are much the same (this SE J100 model is closest to C139/140, but has a different LCD and a MIDI ringtone player chip instead of Calypso-driven buzzer), only the style and mechanics of the case and the UI decorations are different between made-for-Motorola and made-for-Sony-Ericsson phones. The level of support in FC for this SE J100 model is going to be the same as for Mot C11x/12x and C155/156: only voice pseudo-modem operation with the display remaining dark, buttons doing nothing and AT commands required for control. The main purpose of adding this support will be to check how the RF hardware in this phone compares to other known Compal models in the form of Mot C1xx. This phone model is NOT expected to be an attractive choice for FC end users or tinkerers because it does not have the same headset jack as Mot C1xx, instead it has a multi-pin proprietary connector for all accessories (charger, headset, serial interface pins), and the only way to get serial access on this phone is by constructing your own cable through some cutting and soldering - as far as I can tell, no one makes serial cables for these phones like various people make for Mot C1xx. (Yes, I did the cable surgery myself: I cut apart a Sony Ericsson data cable that only works in its intact form on other SE phones that have native USB on the same pins where J100 has our Calypso UART, and soldered the wires to an off-the-shelf FT232RL adapter board. The wires in those SE data cables which need to be cut apart and soldered are *tiny*, must be no more than 28 AWG, and they are stranded, which is even more difficult to work with. I stripped and soldered them the best way I could, but it is kind of a miracle that they hold at all.) I am playing with these SE J100 phones because Harald Welte sent me one, and then I bought one more from a seller on ebay. Harald sent me this phone in relation to certain happenings in the funny circus house known as OsmocomBB: a Russian GSM/RF/SDR/etc tinkering enthusiast named Vadim Yanitskiy, who is basically the only person doing any active work on OBB in the recent months/years, has finally (after a year and a quarter of delay) got around to trying to integrate the RF calibration reading patch which I made for OBB back in 2017-Nov. Back at that time in late 2017 I was willing to support users who wanted to run OBB on our FCDEV3B boards if they would pay the full commercial price for the hardware (which hasn't happened), and for that purpose I made a patch to OBB that makes it use correct RF Tx and VCXO parameters on our hardware instead of the totally wrong numbers that are hard-coded in their mainline code, as much as OBB's flawed architecture would allow. But OBB's architecture also made it impossible to make this change just for the FCDEV3B target, and I had to bring all of their pre-existing targets up to par at the same time. SE J100 was the only OBB-supported target device which I never laid my hands on previously and which was therefore not supported in FC until my current effort to add this support. However, when I tried to run OBB (both with and without my patch) against our CMU200 instrument to see what OBB puts out in terms of RF Tx output and how my patch changes it, I was not pleased at all with what I saw. As I have just confirmed with the same RF test instrument that is used in official type approval certification tests, what OBB puts out on the air is far worse than I previously imagined, and the problems are far bigger than what my little patch can fix. See this post I made to their mailing list: http://lists.osmocom.org/pipermail/baseband-devel/2019-March/005625.html TL;DR: if you run OsmocomBB on any Calypso phone (whether your hw was made by Motorola or FreeCalypso or any other manufacturer) and do it in open air, i.e., without putting the phone in a Faraday cage or disconnecting the internal antenna, and if you get FCC regulators knocking on your door to slap you with a 6-digit fine plus a few months in jail for interfering with and disrupting radio communication networks, you will fully 100% deserve that fine and jail term. OBB's radio transmissions are *grossly* out of spec, and so bad that they most definitely *will* cause interference and disruption to GSM or other cellular networks around you. OBB's Tx output is so bad that the CMU200 is not even able to measure it (see the linked post for the details), hence we don't even know the exact degree of its badness. There is a world of difference between operating a mobile device that lacks the official rubber stamp of approval because no one paid for it, but which in fact operates 100% correctly on the air as verified with properly calibrated test instruments (the case with FreeCalypso), versus operating a mobile device whose radio Tx output is wildly out of spec and highly likely to cause harmful interference (the case with OsmocomBB), and doing so while *knowing* that your transmitter is bad. Thus if you get caught causing disruption to cellular networks by running OBB, and it can be proven that you have seen this warning post of mine with solid technical backing, then it could be argued in court that you had *willfully* caused that cellular network disruption, and your penalties will be correspondingly harsher. Prior to my CMU200 tests this weekend, I did not realize that OBB's behaviour on the air was this bad. It was widely known that OBB fails to implement many important GSM functions such as handover, and OBB's toy architecture is unsuitable for any serious use, but prior to now I mistakenly assumed that it was relatively safe to use within the constraints of its functional limitations. But now we know otherwise: it is not safe at all! In contrast, our own FreeCalypso products (both our own FCDEV3B as well as FreeCalypso fw running on Mot C1xx phones) put out 100% correct, 100% spec-compliant radio transmissions, as verified with the very same CMU200 instrument - it is the very same test instrument as used by official compliance testing labs, and our instrument is itself kept in good calibration standing. In the case of running FreeCalypso fw on Mot C1xx phones, correctness of radio transmissions is contingent on two conditions: if your C1xx variant is anything other than C139/140, you need to be running the latest firmware which I just put out with corrected Tx ramp template tables, and for all C1xx variants, you need to diligently extract the original Tx levels tables with c1xx-calextr and reupload them into your FreeCalypso FFS with fc-fsio as spelled out in C1xx-Howto instructions in the release tarball. Hasta la Victoria, Siempre, Mychaela aka The Mother From mychaela.falconia at gmail.com Mon Mar 11 21:35:19 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 11 Mar 2019 13:35:19 -0800 Subject: FCDEV3B User's Manual Message-ID: Hello FreeCalypso community, I just put out a new version of the FCDEV3B User's Manual: https://www.freecalypso.org/members/falcon/fcdev3b/fcdev3b-userman-1.25.pdf Anyone in our community who currently has one of these boards or is considering getting one should read this update; the two main updates are: * Chapter 4 has been updated to indicate that all previous limited support for OsmocomBB is now officially withdrawn on the basis of OBB's radio transmissions having been found to be in gross violation of GSM specifications, and clarifying that anyone who still chooses to run OBB on any Calypso GSM MS device despite having been warned about its badness will not only be causing interference and disruption to public radio communication networks, but doing so knowingly and willingly, which means a higher level of criminal culpability. * Appendix A has been updated with a description of our current loudspeaker and microphone components. Hasta la Victoria, Siempre, Mychaela aka The Mother From mychaela.falconia at gmail.com Fri Mar 22 02:28:38 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Thu, 21 Mar 2019 18:28:38 -0800 Subject: State of FreeCalypso Message-ID: Hello FC community, This is a periodic update to remind everyone what I am currently doing in the FreeCalypso family of projects and what other people may be able to take on. For the next couple of years, my personal goal is to produce the following two hardware gadgets in this order: 1) The first gadget I need to produce is the FreeCalypso UART+JTAG Adapter, or FC-UJA for short - an FT2232D-based USB adapter board presenting 2.8 V UART and JTAG interfaces meant to be connected to Calypso devices. This FC-UJA is quite uninteresting in itself, but I need to build it first because it is a prerequisite for the next gadget (HSMBP): when we do build the HSMBP, FC-UJA will be required on day 1 for HSMBP bring-up, hence FC-UJA needs to be built first. 2) The next gadget to be built after FC-UJA is the really interesting one: my long-desired Handset Motherboard Prototype (HSMBP). This HSMBP will serve initially as a UI development board (UIDB), making a proper replacement for TI's own D-Sample platform and finally allowing me to have the same development environment which TI's own software engineers had in their offices or cubicles Back In The Day. And because any board of this complexity will necessarily be expensive no matter what the specific design details happen to be, I am going to design this board in such a way that it kills two birds with one stone: it will serve not only as the UIDB, but also as a close-to-final prototype for my personally desired FreeCalypso Libre Dumbphone, my dream phone. The latter design aspect of the HSMBP (designing it in such a way that it can serve not only as the UIDB, but also as a close-to-final prototype for my desired practically usable phone) is the reason why FC-UJA has to be built first, prior to HSMBP itself. On my ultimate dream phone I wish to have the same USB arrangement as on the Pirelli DP-L10, with the mini-USB port on the bottom of the phone serving both as the charging port and a computer connection interface. The latter function will be achieved by incorporating a built-in USB-serial chip just like on the Pirelli DP-L10, connecting the "charging" USB port to one of Calypso's UARTs - except that I am going to connect it to the MODEM UART that carries the standard ASCII AT command interface in our version, and not to the IrDA UART like Pirelli did. But this built-in USB-serial interface will only be for end users, and not for deep development or initial bring-up - for the latter functions the IrDA UART (the one carrying RVTMUX, corresponding to the headset jack on Openmoko devices or ttyUSB1 in typical FCDEV3B setups) will be wired to an FFC (flat flexible cable, often erroneously referred to as FPC) connector for connecting an FC-UJA. Hence we will need to have FC-UJA available and working on day 1 of HSMBP bring-up, and thus the need to design and build this FC-UJA first. (For those familiar with Openmoko devices and their debug board which connects to the main device motherboard via a custom FFC, what I am designing for FreeCalypso is exactly the same arrangement: my FC-UJA will correspond to OM's debug board, and it will be required for the initial bring-up of the main motherboard just like OM's debug board would be required for initial bring-up if you produced your own GTA02 motherboard clone with both NAND and NOR boot locations completely blank on the freshly-produced board.) The pro and con of the approach I am pursuing (designing and building first FC-UJA, then HSMBP) are as follows: Pro: once I have my desired HSMBP, I will be able to *properly* clean up the phone UI code we got from TI and bring it into shape, and here is the big one: once we have the development platform I need for this UI work, the new FreeCalypso UI will run not only on the HSMBP, but also on all of our supported Mot C1xx, Pirelli DP-L10 and SE J100 targets, producing a practically usable FreeCalypso end user phone at least on the C139. Con: the journey to get there is very long. Given the need to design and build not just one but two board projects, we are looking at anywhere from 2 to 5 y from now, depending on whether or not I can get other people to help me with the astronomical cost of my big surgery. If someone helps me with the 26 kUSD surgery cost, I will be able to direct all of my energy into FreeCalypso and the HSMBP will very likely be done in 2 y, otherwise it will probably be more like 5 y from now. Now here is the current state of support in FreeCalypso for the Mot C139 and similar pre-existing phone targets. Right now only the UI is missing, whereas all of the lower layers work flawlessly on all 5 "alien" (non-TI, non-Openmoko, non-FreeCalypso) hw targets: * Mot C11x/12x * Mot C139/140 * Mot C155/156 * Pirelli DP-L10 * Sony Ericsson J100 On _all_ of the above phones, we can now run FreeCalypso firmware (run via fc-xram on the Pirelli, needs to be flashed on all others) in our so-called "voice pseudo-modem" configuration (no UI on the LCD, control from a connected computer required), and on all of these targets our FC fw absolutely correctly registers to the GSM network, makes and receives calls (voice via the phone's native earpiece and mic, dialing via AT commands from the connected computer), sends and receives SMS - and as verified with my CMU200 RF instrument, it puts out 100% correct, 100% spec-compliant radio transmissions as it does so. Only the UI is missing, everything else is already there and fully working. Most of these phones including the C139 (the most interesting one from the practical standpoint) have 96x64 pixel color LCDs, hence if someone can produce practically usable UI code for this screen size, we will immediately be able to run it on all of the listed phones. Mot C11x/12x may be the lone exception that may never be able to run FreeCalypso with untethered phone functionality (fitting our UI-enabled fw config into the tiny RAM and flash on this model would require some major contortions), but all others can easily be made to run the same UI code as the C139. The C139 will still be the most practically usable one (on the others we don't know how to make the phone ring, can only vibrate), but at least for demo purposes the UI code can run just the same on all targets. Thus there are two ways how practically usable FreeCalypso end user fw for Mot C139 and its siblings can become a reality: The sure but slow way: if someone makes a significant donation toward the cost of my surgery and thereby speeds up my FreeCalypso work, when I build my desired HSMBP, a practically usable UI for the C139 & co will appear as a side product. Alternate way: if anyone else in our community can be convinced to overcome their fear of programming and delve into the code, they may be able to produce a practically usable UI for the C139 more directly, without waiting for my development hardware. I am not willing myself to jump directly to the 96x64 pixel UI for the C139 & co because doing so would require forever giving up my dream of restoring TI's original 176x220 pixel color UI in its full glory (not willing to do that), but someone else who is more practically minded, someone who does not have the same attachment to TI's history and code as I do and who just wants a practically usable UI on the C139 may be able to produce the latter much more directly. So there are your two options for how to get a practically usable FreeCalypso phone in a foreseeable timeframe: either help me with my surgery cost, or put on the hat of a firmware developer and implement the missing UI yourself. Hasta la Victoria, Siempre, Mychaela aka The Mother From mychaela.falconia at gmail.com Thu Mar 28 18:44:20 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Thu, 28 Mar 2019 10:44:20 -0800 Subject: MCSI breakthrough Message-ID: Hello FreeCalypso community, For those with an interest in the embedded modem side of our family of projects, I have some exciting news: after having it on the back burner for almost 2 y since our first boards, I finally got MCSI to work in an acceptable manner as a digital voice interface. The details are documented in the new Calypso-digital-voice article in the freecalypso-docs Hg repository, but here are the two essentials: * As verified by hooking up 3 channels of my Rigol scope to MCSI_CLK, MCSI_FSYNCH and MCSI_TXD signals simultaneously (all 3 are outputs from the Calypso in the "Bluetooth" digital voice mode), I have confirmed that the framing format in which the digital voice samples are exchanged is indeed what I thought it was - please read my Calypso-digital-voice article in freecalypso-docs for the details. * The key to having MCSI work successfully as a practically usable digital voice i/f is that it must not be enabled continuously, instead it requires dynamic control: it needs to be turned on when a voice call is connected and turned off when a call ends, so that MCSI clocks are running only when the modem is in an active call, and not during idle between calls. As explained in my Calypso-digital-voice article in freecalypso-docs, I have just implemented a new mechanism in our Magnetite and Selenite firmwares (enabled with the new AT at VSEL=1 command) that does the necessary auto-switching magic, and with this new firmware feature the digital voice interface works reliably: the DSP bug that was previously getting in our way is reliably avoided. So if you have an FCDEV3B and you are interested in getting a digital voice interface out of your modem, you can now give it a try. You will need to compile the latest FC Magnetite firmware in the hybrid configuration (I plan on putting out a new official build in the next few days), and you will need to read the Calypso-digital-voice article in freecalypso-docs for the hardware interface details. Hasta la Victoria, Siempre, Mychaela aka The Mother From rafael at riseup.net Thu Mar 28 20:09:06 2019 From: rafael at riseup.net (Rafael Diniz) Date: Thu, 28 Mar 2019 17:09:06 -0300 Subject: MCSI breakthrough In-Reply-To: References: Message-ID: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> Thanks a lot Mychaela, I read the document. Which kind of interface could I use to connect to the MCSI pins and be able to receive the audio samples in a computer? Best regards, Rafael Diniz On 3/28/19 3:44 PM, Mychaela Falconia wrote: > Hello FreeCalypso community, > > For those with an interest in the embedded modem side of our family of > projects, I have some exciting news: after having it on the back burner > for almost 2 y since our first boards, I finally got MCSI to work in > an acceptable manner as a digital voice interface. The details are > documented in the new Calypso-digital-voice article in the > freecalypso-docs Hg repository, but here are the two essentials: > > * As verified by hooking up 3 channels of my Rigol scope to MCSI_CLK, > MCSI_FSYNCH and MCSI_TXD signals simultaneously (all 3 are outputs > from the Calypso in the "Bluetooth" digital voice mode), I have > confirmed that the framing format in which the digital voice samples > are exchanged is indeed what I thought it was - please read my > Calypso-digital-voice article in freecalypso-docs for the details. > > * The key to having MCSI work successfully as a practically usable > digital voice i/f is that it must not be enabled continuously, instead > it requires dynamic control: it needs to be turned on when a voice > call is connected and turned off when a call ends, so that MCSI clocks > are running only when the modem is in an active call, and not during > idle between calls. As explained in my Calypso-digital-voice article > in freecalypso-docs, I have just implemented a new mechanism in our > Magnetite and Selenite firmwares (enabled with the new AT at VSEL=1 > command) that does the necessary auto-switching magic, and with this > new firmware feature the digital voice interface works reliably: the > DSP bug that was previously getting in our way is reliably avoided. > > So if you have an FCDEV3B and you are interested in getting a digital > voice interface out of your modem, you can now give it a try. You > will need to compile the latest FC Magnetite firmware in the hybrid > configuration (I plan on putting out a new official build in the next > few days), and you will need to read the Calypso-digital-voice article > in freecalypso-docs for the hardware interface details. > > Hasta la Victoria, Siempre, > Mychaela aka The Mother > _______________________________________________ > Community mailing list > Community at freecalypso.org > https://www.freecalypso.org/mailman/listinfo/community > From mychaela.falconia at gmail.com Thu Mar 28 21:31:15 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Thu, 28 Mar 2019 13:31:15 -0800 Subject: MCSI breakthrough In-Reply-To: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> Message-ID: Hi Rafael! > I read the document. Which kind of interface could I use to connect to > the MCSI pins and be able to receive the audio samples in a computer? This is the difficult part: I have looked around, and I was not able to find any easy way to connect a PCM master interface (be it our Calypso MCSI or any other vendor's) to an ordinary PC or laptop. No one makes any kind of ready-made device that would go from USB (or any other "ordinary" computer interface) to a PCM slave that can be connected to an external PCM master like our MCSI. We've got FTDI adapters that can go from USB to UARTs, to JTAG, to a SPI master (driving a SPI slave such as an EEPROM or flash chip) and even to an 8-bit microprocessor bus, but nothing that can connect a PC or laptop to a PCM interface like the typical digital voice interfaces found on GSM modems, not just ours but also the mainstream proprietary ones. For this reason the target audience for the digital voice interface on FreeCalypso modems is not individual personal tinkerers who are playing with a development board connected to a PC or laptop, but larger system integrators, people who are designing and building some complex systems of their own, who need to integrate a cellular modem module into whatever larger system they are building, and who are considering FreeCalypso as an alternative to the mainstream proprietary solutions. There is a whole ton of "half-free" smartphone projects out there: someone sets out to design and build their own smartphone, they make the application processor subsystem fully free and libre, but they use a proprietary black box modem module for the cellular functionality. My goal is to convince at least one of those numerous "half-free" smartphone projects to make their solution fully free instead of "half-free" by using our FreeCalypso modem instead of a proprietary one. Some of these existing "half-free" smartphone projects (ZeroPhone) use their proprietary modem modules with analog voice interfaces, but most of the fancier "half-free" smartphone projects use modem modules with digital voice interfaces. Some of those "half-free" smartphone projects out there use TI OMAP processors for the AP subsystem, and they use mainstream proprietary modem modules that put out their digital voice channel on a PCM master interface just like our Calypso MCSI. In these "half-free" smartphone projects they take the PCM master digital voice i/f coming out of the modem and connect it to one of McBSP ports on the OMAP. Given my goal of proving FreeCalypso as a viable alternative to those disgusting proprietary modem modules, I have been toying with the idea of connecting our MCSI to McBSP on an OMAP board to make the point. The off-the-shelf board I chose for this purpose is BeagleBoard-xM: it features a DM3730 (OMAP3 variant) processor, it has been used as a development platform by some of these "half-free" smartphone projects I am talking about, and it is readily and cheaply available from Digi-Key and other distributors. Connecting our Calypso MCSI to the DM3730 processor on the BeagleBoard requires a level-shifting adapter: Calypso I/O pins are 2.8 V, whereas DM3730 I/O pins are 1.8 V and not tolerant of any higher voltages. I have designed my own little adapter PCB that plugs into the expansion connector on the bottom of the BB-xM, I have got these little PCBs fabricated and got them on hand now, and if anyone in the community would like to take this BeagleBoard-to-FreeCalypso project further, I can easily populate one of these adapter boards and send it to you. If Rafael or anyone else in the community would like to take on this project, the hardware is already taken care of: I will send you the little adapter that connects the BB-xM to our Calypso MCSI, and if the price of the BB-xM itself is too much for you, I can send you that board as well. However, you will need to do the software work for which I have no time myself: you will need to figure out how to configure the DM3730 pin multiplexing in the BB-xM Linux kernel (or perhaps in U-Boot) to connect the external pins to the right McBSP and UART cores inside, you will need to make the Linux kernel attach the McBSP driver to the selected McBSP core and configure that McBSP driver correctly for our PCM frame format, and you will need to figure out whatever ALSA or other userspace magic would be needed in order to actually exchange voice samples over the interface. It is all software work, absolutely no hardware hacking skills or tools are needed, but this BeagleBoard Linux sw work would require far more brain cycles of me than I can spare, which is why I am punting it off to the community. Another idea would be to use an AT91SAM7S board, also very cheap and readily available. The AT91SAM7S processor is an ARM7 SoC just like the Calypso, running OS-less bare-metal firmware, and the selection of peripherals include UARTs, a USB device controller and a synchronous serial controller that can be used for our MCSI. You could write fw for this AT91SAM7S processor that talks on the synchronous serial interface on one side (to be connected to Calypso MCSI) and passes these voice samples over a UART or over USB on the other side. Once again, the hardware is already there (the AT91SAM7S has 3.3 V I/O pins that can be connected directly to our FCDEV3B), but someone would have to do the non-trivial software work. So, do we have any takers for implementing a proof-of-concept system for talking to our Calypso digital voice interface? Hasta la Victoria, Siempre, Mychaela aka The Mother From rafael at riseup.net Fri Mar 29 01:13:54 2019 From: rafael at riseup.net (Rafael Diniz) Date: Thu, 28 Mar 2019 22:13:54 -0300 Subject: MCSI breakthrough In-Reply-To: References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> Message-ID: Thanks for the explanation, Mychaela. I feel my next step with the FCDEV3B will be analog audio (mic + speaker), but if there is a need from Rhizomatica for using the audio of the voice calls, I'll not mind getting a BB-xM and write the support for the MCSI framing / protocol. Cheers! Rafael Diniz Rhizomatica On 3/28/19 6:31 PM, Mychaela Falconia wrote: > Hi Rafael! > >> I read the document. Which kind of interface could I use to connect to >> the MCSI pins and be able to receive the audio samples in a computer? > > This is the difficult part: I have looked around, and I was not able > to find any easy way to connect a PCM master interface (be it our > Calypso MCSI or any other vendor's) to an ordinary PC or laptop. No > one makes any kind of ready-made device that would go from USB (or any > other "ordinary" computer interface) to a PCM slave that can be > connected to an external PCM master like our MCSI. We've got FTDI > adapters that can go from USB to UARTs, to JTAG, to a SPI master > (driving a SPI slave such as an EEPROM or flash chip) and even to an > 8-bit microprocessor bus, but nothing that can connect a PC or laptop > to a PCM interface like the typical digital voice interfaces found on > GSM modems, not just ours but also the mainstream proprietary ones. > > For this reason the target audience for the digital voice interface on > FreeCalypso modems is not individual personal tinkerers who are playing > with a development board connected to a PC or laptop, but larger system > integrators, people who are designing and building some complex systems > of their own, who need to integrate a cellular modem module into > whatever larger system they are building, and who are considering > FreeCalypso as an alternative to the mainstream proprietary solutions. > > There is a whole ton of "half-free" smartphone projects out there: > someone sets out to design and build their own smartphone, they make > the application processor subsystem fully free and libre, but they use > a proprietary black box modem module for the cellular functionality. > My goal is to convince at least one of those numerous "half-free" > smartphone projects to make their solution fully free instead of > "half-free" by using our FreeCalypso modem instead of a proprietary > one. Some of these existing "half-free" smartphone projects > (ZeroPhone) use their proprietary modem modules with analog voice > interfaces, but most of the fancier "half-free" smartphone projects > use modem modules with digital voice interfaces. > > Some of those "half-free" smartphone projects out there use TI OMAP > processors for the AP subsystem, and they use mainstream proprietary > modem modules that put out their digital voice channel on a PCM master > interface just like our Calypso MCSI. In these "half-free" smartphone > projects they take the PCM master digital voice i/f coming out of the > modem and connect it to one of McBSP ports on the OMAP. > > Given my goal of proving FreeCalypso as a viable alternative to those > disgusting proprietary modem modules, I have been toying with the idea > of connecting our MCSI to McBSP on an OMAP board to make the point. > The off-the-shelf board I chose for this purpose is BeagleBoard-xM: it > features a DM3730 (OMAP3 variant) processor, it has been used as a > development platform by some of these "half-free" smartphone projects > I am talking about, and it is readily and cheaply available from > Digi-Key and other distributors. > > Connecting our Calypso MCSI to the DM3730 processor on the BeagleBoard > requires a level-shifting adapter: Calypso I/O pins are 2.8 V, whereas > DM3730 I/O pins are 1.8 V and not tolerant of any higher voltages. I > have designed my own little adapter PCB that plugs into the expansion > connector on the bottom of the BB-xM, I have got these little PCBs > fabricated and got them on hand now, and if anyone in the community > would like to take this BeagleBoard-to-FreeCalypso project further, I > can easily populate one of these adapter boards and send it to you. > > If Rafael or anyone else in the community would like to take on this > project, the hardware is already taken care of: I will send you the > little adapter that connects the BB-xM to our Calypso MCSI, and if the > price of the BB-xM itself is too much for you, I can send you that > board as well. However, you will need to do the software work for > which I have no time myself: you will need to figure out how to > configure the DM3730 pin multiplexing in the BB-xM Linux kernel (or > perhaps in U-Boot) to connect the external pins to the right McBSP and > UART cores inside, you will need to make the Linux kernel attach the > McBSP driver to the selected McBSP core and configure that McBSP > driver correctly for our PCM frame format, and you will need to figure > out whatever ALSA or other userspace magic would be needed in order to > actually exchange voice samples over the interface. It is all software > work, absolutely no hardware hacking skills or tools are needed, but > this BeagleBoard Linux sw work would require far more brain cycles of > me than I can spare, which is why I am punting it off to the community. > > Another idea would be to use an AT91SAM7S board, also very cheap and > readily available. The AT91SAM7S processor is an ARM7 SoC just like > the Calypso, running OS-less bare-metal firmware, and the selection of > peripherals include UARTs, a USB device controller and a synchronous > serial controller that can be used for our MCSI. You could write fw > for this AT91SAM7S processor that talks on the synchronous serial > interface on one side (to be connected to Calypso MCSI) and passes > these voice samples over a UART or over USB on the other side. Once > again, the hardware is already there (the AT91SAM7S has 3.3 V I/O pins > that can be connected directly to our FCDEV3B), but someone would have > to do the non-trivial software work. > > So, do we have any takers for implementing a proof-of-concept system > for talking to our Calypso digital voice interface? > > Hasta la Victoria, Siempre, > Mychaela aka The Mother > From das.signal at freecalypso.org Sat Mar 30 13:30:56 2019 From: das.signal at freecalypso.org (Das Signal) Date: Sat, 30 Mar 2019 13:30:56 +0000 Subject: MCSI breakthrough In-Reply-To: References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> Message-ID: <20190330133056.GA3175@freecalypso.org> Hi Mychaela, Congrats on your breakthrough :) I do have a BBxM that I bought several years ago along with a flyswatter2 JTAG debugger and associated TI 14pin adapter. Also I have some unused logic level converter which is iirc https://www.adafruit.com/product/1875 Do you think this board would be adequate for the purpose of connecting the FCDEV3B to the BBxM? --DS From mychaela.falconia at gmail.com Sat Mar 30 17:23:48 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sat, 30 Mar 2019 09:23:48 -0800 Subject: MCSI breakthrough In-Reply-To: <20190330133056.GA3175@freecalypso.org> References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> <20190330133056.GA3175@freecalypso.org> Message-ID: Hi DS! > I do have a BBxM that I bought several years ago along with a flyswatter2 > JTAG debugger and associated TI 14pin adapter. OK, so far, so good... > Also I have some unused > logic level converter which is iirc https://www.adafruit.com/product/1875 > Do you think this board would be adequate for the purpose of connecting > the FCDEV3B to the BBxM? That level shifter tries to "magically autodetect" the direction for bidirectional signals, and I personally would not trust it; with our MCSI every signal is strictly unidirectional, hence it is better to use fixed-direction level shifters like I did on my BB2FC adapter. With your "generic" adapter you would also have to wire everything up manually, and you would need some external source for a 2.8 V or 3.3 V supply for the "HV" side of your converter - such supply pin is not provided by either FCDEV3B or BB-xM. Instead I very strongly urge you to use *my* BB2FC adapter, which you can find in the bb2fc directory in the freecalyps-schem Hg repository. Please have a little patience, just another few weeks, and I will then be able to send you one of these little adapter boards fully assembled, so you can just plug it into the bottom of your BB-xM and start the software work. M~ From das.signal at freecalypso.org Sun Mar 31 13:17:59 2019 From: das.signal at freecalypso.org (Das Signal) Date: Sun, 31 Mar 2019 13:17:59 +0000 Subject: MCSI breakthrough In-Reply-To: References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> <20190330133056.GA3175@freecalypso.org> Message-ID: <20190331131759.GA7868@freecalypso.org> Hi Mychaela, Thanks for the information! I will follow your advice and wait for converter. Meanwhile I have made a speaker and microphone adapters that will allow for testing analog audio. --DS From rafael at riseup.net Sun Mar 31 22:13:09 2019 From: rafael at riseup.net (Rafael Diniz) Date: Sun, 31 Mar 2019 19:13:09 -0300 Subject: MCSI breakthrough In-Reply-To: <20190331131759.GA7868@freecalypso.org> References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> <20190330133056.GA3175@freecalypso.org> <20190331131759.GA7868@freecalypso.org> Message-ID: <4e5f4821-6807-772e-ecfe-997944b39764@riseup.net> Hi Mychaela and Das Signal, Is there a way I could install two audio connectors for MIC and Speaker? For the use I have in the lab with the FCDEV3B it would be more interesting. Thanks, Rafael Diniz On 3/31/19 10:17 AM, Das Signal wrote: > Hi Mychaela, > > Thanks for the information! I will follow your advice and wait for converter. > Meanwhile I have made a speaker and microphone adapters that will allow for > testing analog audio. > > --DS > _______________________________________________ > Community mailing list > Community at freecalypso.org > https://www.freecalypso.org/mailman/listinfo/community > From mychaela.falconia at gmail.com Sun Mar 31 22:54:38 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 31 Mar 2019 14:54:38 -0800 Subject: MCSI breakthrough In-Reply-To: <4e5f4821-6807-772e-ecfe-997944b39764@riseup.net> References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> <20190330133056.GA3175@freecalypso.org> <20190331131759.GA7868@freecalypso.org> <4e5f4821-6807-772e-ecfe-997944b39764@riseup.net> Message-ID: > Hi Mychaela and Das Signal, > Is there a way I could install two audio connectors for MIC and Speaker? > For the use I have in the lab with the FCDEV3B it would be more interesting. I am afraid that I don't really understand the question. Are you asking for a way to convert the speaker and mic hook-ups on the FCDEV3B to audio connectors like the ones on a laptop, such that you could then plug off-the-shelf end-user audio stuff into them? If that is your question, then I don't have an answer to it, as I am quite illiterate in the realm of audio myself - just producing the circuits which are currently on the board was an extremely difficult struggle for me during the design phase. Someone who understands analog audio much better than I do would need to review the circuits which are currently on the board and figure out what can be done with them, other than what I found to work. As I already said before, I would be more than happy to send one of my voice kits (speaker and mic outfitted with wires and connectors that connect to the FCDEV3B) to each of you (both Rafael and DS), but if you desire something different, you will have to figure it out yourselves. You will need to start with the Leonardo schematics: ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_rev05.pdf TI's Leonardo speaker and mic circuits are depicted on page 3 of the above PDF; the corresponding circuits on the FCDEV3B are almost identical, with only a few differences: * Where the original Leonardo schematic drawing shows physical speaker and mic parts, on our FCDEV3B we have a two-post header in the place of each, for the physical speaker or mic to reside off-board; * The differential input to the TPA6203A1 loudspeaker amplifier comes only from EARN&EARP on the FCDEV3B (not from AUXON&AUXOP), and the gain control resistor values are different, tuned to produce 3.6 V of swing on each leg of TPA6203A1 output in our configuration when the output from the Iota ABB (input to the TPA6203A1) is at the maximum; * C333 and C334 footprints are omitted; * HSP3xx ESD protection features are also omitted. The above is all I know; from here onward you have to use your own audio knowledge, which I lack. Sorry for being of so little help, Mychaela aka The Mother From rafael at riseup.net Sun Mar 31 23:53:52 2019 From: rafael at riseup.net (Rafael Diniz) Date: Sun, 31 Mar 2019 20:53:52 -0300 Subject: MCSI breakthrough In-Reply-To: References: <901aba65-10fd-7e1d-b58b-9d0381a7d8db@riseup.net> <20190330133056.GA3175@freecalypso.org> <20190331131759.GA7868@freecalypso.org> <4e5f4821-6807-772e-ecfe-997944b39764@riseup.net> Message-ID: Hi Mychaela, Thanks for the support. I prefer first to have the speaker and Mic you'll provide us working fine here. As a later experimentation, I'd like to try to match the impedance of the sound card with the fcdev3b audio I/O and may be add a switch to change between official mic/speaker and AUX audio I/O. Just ideas for now. Cheers, Rafael Diniz On 3/31/19 7:54 PM, Mychaela Falconia wrote: >> Hi Mychaela and Das Signal, >> Is there a way I could install two audio connectors for MIC and Speaker? >> For the use I have in the lab with the FCDEV3B it would be more interesting. > > I am afraid that I don't really understand the question. Are you > asking for a way to convert the speaker and mic hook-ups on the FCDEV3B > to audio connectors like the ones on a laptop, such that you could then > plug off-the-shelf end-user audio stuff into them? > > If that is your question, then I don't have an answer to it, as I am > quite illiterate in the realm of audio myself - just producing the > circuits which are currently on the board was an extremely difficult > struggle for me during the design phase. Someone who understands > analog audio much better than I do would need to review the circuits > which are currently on the board and figure out what can be done with > them, other than what I found to work. > > As I already said before, I would be more than happy to send one of my > voice kits (speaker and mic outfitted with wires and connectors that > connect to the FCDEV3B) to each of you (both Rafael and DS), but if > you desire something different, you will have to figure it out > yourselves. You will need to start with the Leonardo schematics: > > ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_rev05.pdf > > TI's Leonardo speaker and mic circuits are depicted on page 3 of the > above PDF; the corresponding circuits on the FCDEV3B are almost > identical, with only a few differences: > > * Where the original Leonardo schematic drawing shows physical speaker > and mic parts, on our FCDEV3B we have a two-post header in the place > of each, for the physical speaker or mic to reside off-board; > > * The differential input to the TPA6203A1 loudspeaker amplifier comes > only from EARN&EARP on the FCDEV3B (not from AUXON&AUXOP), and the > gain control resistor values are different, tuned to produce 3.6 V of > swing on each leg of TPA6203A1 output in our configuration when the > output from the Iota ABB (input to the TPA6203A1) is at the maximum; > > * C333 and C334 footprints are omitted; > > * HSP3xx ESD protection features are also omitted. > > The above is all I know; from here onward you have to use your own > audio knowledge, which I lack. > > Sorry for being of so little help, > Mychaela aka The Mother > _______________________________________________ > Community mailing list > Community at freecalypso.org > https://www.freecalypso.org/mailman/listinfo/community >