Hello FC community, It's time for an update on the various things I am working on. In no particular order:
* I plan on getting my own oscilloscope for my home lab some time in the next few weeks. I don't have a close enough relationship with any of the hardware people at my day job to use one of their scopes for my personal project, thus in order to do any o'scope probing on our FreeCalypso boards, I need to buy my own scope and set it up at home. My preliminary accounting tells me that I have enough money to buy a scope on ebay (I will have more accurate accounting when I come home this weekend), but the expected delay of a few weeks is because of physical space issues in the room at my home that serves as my FreeCalypso hardware lab, and those space issues stem from the CMU200 problem. I had to take my CMU200 apart in order to check the power levels at the internal Tx path interface from the Rx/Tx board to the RF FE, and right now it sits in my room in a dismantled state, taking up far more space than it would if it were put back together. I didn't want to reassemble and then re-disassemble it a bunch of times, so I left it in the dismantled state while waiting for a replacement Rx/Tx board. That replacement module is on its way to me from a seller in Sweden, but appears to be stuck at postal customs in New York. :-( Once I get my own scope and learn how to use it, I plan on using it for at least two purposes in our project: (1) probing to see if I can spot a transient voltage drop on one of the power rails in connection with the sleep mode self-reboot bug discussed on this list a few days ago, and (2) investigating what should be a digital audio interface on the MCSI pins in the so-called "Bluetooth headset" mode. Having our FreeCalypso modem present a digital voice channel as an alternative to the classic analog one is an important feature for some of our prospective commercial users, and it is also an important feature for us to use in convincing people like the Neo900 project to offer a variant with our FreeCalypso modem instead of their usual proprietary one: those proprietary modems do have digital voice channel interfaces, and it is those digital interfaces, not analog, that are used by projects like Neo900. It appears that we can get a digital voice interface out of the Calypso in the so-called "Bluetooth headset" mode, and I feel that we should seize this opportunity. The problem though is that this digital voice channel is something that almost no one cared for back in the days when Calypso was current, the capability appears to have been added as an afterthought in order to support building Bluetooth-enabled dumbphones with the Calypso, and the details aren't documented anywhere. Therefore, we need to reverse- engineer those details, and this reverse eng process will need to start with putting an oscilloscope probe on the MCSI_CLK line to see if the DSP code we are running (combination of the DSP ROM plus the downloaded patch code we took from TCS211) puts the MCSI into clock master or clock slave mode. * I am waiting for some loudspeaker and microphone parts to arrive from Digi-Key. If they arrive on Friday like FedEx Ground tracking says they should, then I hope to be able to test the loudspeaker driver circuit on our FCDEV3B this Sunday and the microphone input circuit the following week. If the loudspeaker driver and microphone input circuits on our FCDEV3B work, then I will feel comfortable with *finally* releasing the assembly of the next batch of 12 boards. Specifically, I plan on *not* blocking this next batch assembly pending the resolution of the sleep mode bug or pending the completion of the MCSI investigation. Root-causing and solving the sleep mode bug may take a very long time and lots of expensive trial and error, and it is not acceptable for our entire project to remain blocked dead in the meantime. Therefore, we'll have to live with a software workaround in the form of disabling sleep modes, much like Openmoko did with their bug #1024 for the two years or so before they finally fixed it. And for those who would like to use our FCDEV3B modems stationary on a lab bench powered from a supply which itself feeds on AC mains power, it won't make any difference whether the modem has working sleep modes or not. It similarly makes no sense to keep further board assembly on hold while we figure out how the digital voice interface over MCSI works. The mystery to be solved here is how our TCS211 DSP code configures things inside the Calypso chip; at the board level we do nothing more than bring the MCSI signals out to header pins, thus I do not expect any problems at the board level when it comes to MCSI. * As discussed on this list many times before, our current FCDEV3B was originally designed to be a development board, not a module to be integrated into other people's projects as a component - while it is certainly possible to use it in the latter fashion, it is absolutely not convenient. Aside from FreeCalypso core developers, FCDEV3B modems can be useful to certain specialized classes of end users, specifically those who desire a fully open and tinkerable modem in a "stationary mobile" application, i.e., physically stationary and connected to a desktop PC or a server or somesuch, but accessing a GSM network, e.g., to send and receive SMS or to make CSD calls. But if you are building something small and portable, akin to a smartphone, and are in the market for a libre GSM modem module to incorporate into your gadget, then our current FCDEV3B is totally in the wrong physical form factor. I have argued many times before that we should make a FreeCalypso modem module in an SMT form factor similar to the mainstream proprietary ones, but the devil is in the details. If the problem is approached in an open-ended manner, without any constraints, then there is a near-infinite set of possibilities as to the form factor (dimensions) of the module, its set of interface signals and the specific form of its SMT physical interface, i.e., LGA, BGA, castellated... If we had to make all of these design decisions on our own from scratch, it would be a daunting task to come up with a set of choices that make good engineering sense. Fortunately, I've got a major breakthrough in this direction: I found a pre-existing historical commercial modem module of exactly the kind we are talking about, with a Calypso chipset inside! Take a look at this datasheet: ftp://ftp.freecalypso.org/pub/GSM/BenQ/BenQ_M32_ds.pdf I originally found it back in 2011 when I first started gathering info about the Calypso in connection with its use in the Neo FreeRunner; looking at this datasheet and at the companion AT command document, it is very obvious that this module has a Calypso+Iota chipset inside (obvious from the names and descriptions of the hardware interface signals in the datasheet), running TI-based firmware (obvious from the AT command document which lists a bunch of TI's non-standard ones). Even though I had originally found the above datasheet back in 2011, it had slipped out of my mind over the years until I rediscovered it a few days ago: I was looking through datasheets for various existing packaged modem modules, gathering ideas for our own such module design, until I re-stumbled across this BenQ M32. Then a light bulb went on in my head: what if we make our FreeCalypso SMT modem module in exactly the same physical form factor as the historical one from BenQ? This way we'll be using a form factor and a set of interface signal choices which are known to be good for the purpose of building a modem module with Calypso inside. But it gets even better: I found someone on ebay who has some of these BenQ M32 modules available (and for dirt cheap too), and I bought 15 of them. Now I need to wait for them to arrive, and once they arrive, I will open one up for reverse eng - I haven't been able to find any photos of the insides of this module with the top shield off, and I am dying of curiosity to see what RF components are inside: we can deduce the presence of Calypso and Iota from the interfaces in the datasheet, but know nothing about the RF part so far except that it is triband like Openmoko, Pirelli and our FCDEV3B - but there is a near-infinite number of different ways to build a triband RFFE of this sort. It might be possible to run our own FreeCalypso firmware on these pre-existing historical M32 modules (won't know for sure until I get one in my hands to pop open and see the RF components), but even if such a port to the pre-existing historical hw is possible, it is not my primary interest. Instead my interest is in building our own semi- clone of this modem module: not a 100% verbatim clone, but with some hardware improvements, while keeping exactly the same physical form factor and mostly the same interfaces. What hardware improvements do I envision relative to the historical M32? At least two: * If possible in terms of PCB layout and internal component placement constraints, make our modem quadband (using the magic M034F RF FEM from TI's Leonardo and E-Sample designs) instead of triband. * MCSI signals on the Calypso are multiplexed with GPIOs (i.e., the pins can be set to be MCSI or GPIOs via config register bits), and the M32 datasheet refers to them primarily as GPIOs. (Remember that in those days no one asked for a digital voice interface.) They have 3 of these MCSI/GPIO signals brought out on SMT interface pads, but the fourth one (MCSI_TXD/IO9, required for a working digital voice interface) is brought out only to a test point on the top side of the module, intended for an ancient weird test mode from the GSM 11.10 spec. We will definitely need to fix this blunder and properly bring out all 4 MCSI signals on SMT interface pads on our semi-clone of this module. These are my thoughts for the moment; off to bed now. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
