Hello FreeCalypso community, I have some ideas about what we may be able to do after we get our FCDEV3B built, and I would like to run these ideas by all of you.
The FCDEV3B has always been intended as a *development* board, rather than an end-use product of any kind. IOW, it has been my intent that these boards will be used by developers (either core FC developers or new community members taking on tasks of a development or experimental nature) for developer tasks (FC firmware development and/or experimental discovery of those Calypso hardware features which are insufficiently documented, like the current MCSI discussion), rather than for any kind of end use. But what is the end outcome of all this development activity? Back in my home country we had steel mills that made steel for building more steel mills; while I readily admit that I do oftentimes enjoy hacking for the sake of hacking, I am also hoping to see our FreeCalypso family of projects produce some end-use products as well. As discussed on this list many times before, there are two fundamental classes of end products that can be made with the Calypso chipset: phones and modems. And as we've also discussed numerous times before, the firmware we've inherited from our predecessors at TI and Openmoko is much better suited for the modem configuration than the dumbphone one. Hence I continue to feel strongly that we should use our firmware advantage to produce a fully finished, commercial quality GSM+GPRS libre modem end product in addition to the more nebulous and less certain quest to produce a much more complex FreeCalypso dumbphone. It *will* be possible to use the FCDEV3B as a modem board for end-use applications, even though such use is not what I originally envisioned - but it won't be very convenient. The on-board loudspeaker and microphone circuits on the FCDEV3B (copied from TI's Leonardo which I sought to recreate) are intended for the usage scenario where a FreeCalypso firmware developer has this board on a lab bench in front of her, needs to make a test voice call, and would like the convenience of directly hearing the downlink audio out the loudspeaker and speaking into an on-board microphone for uplink testing. But these circuits will almost certainly be useless for anyone who would like to use our board as a modem module in some larger system. For such users, we'll have the option of producing boards with these circuit components unpopulated to avoid part waste. Next comes the power-up process. Originally coming from the dumbphone world and later adapted for modem applications, TI's GSM chipsets (like all other classic ones) expect an explicit power-on request separate from the appearance of "battery" power. This power-on request needs to take the form of the PWON pin (on the Iota chip) being briefly shorted to ground, then released - on a classic dumbphone this sequence corresponds to the human user depressing the power button, then releasing it. Just like on TI's historical Leonardo board which I sought to recreate, there is a physical user pushbutton on the FCDEV3B, shorting PWON to GND. A FreeCalypso developer working with one of these boards on a lab bench will need to physically press this button with her finger (or a stylus) to command the Calypso to boot. But of course this approach won't work too well if one desires to use the modem board as a component in a larger system. There is a two-post header on the FCDEV3B, wired in parallel with the PWON pushbutton switch; one can put a shorting block on these header pins, but I don't know if TI's chipset and firmware will be happy with the power button being effectively pressed down forever, rather than pressed and released as normally expected - yet another thing to be tested experimentally once we get the development boards built. In Openmoko's smartphones, the AP would simulate the PWON button press to the Calypso modem, but their Linux kernel code which accomplishes this feat simulates a button press and release sequence, rather than holding the PWON "button" down forever. Hence you may need to connect a relay or transistor circuit to the PWON header that does the trick - see Openmoko schematics for a working example. Finally, my choice of connectors for the power input (copied from TI's historical development boards), for the two UARTs and for MCSI should be compatible with any potential end-use modem application, but none of these choices were made with end-use convenience in mind, only FC developer convenience. All of the above brings me to the following proposal: once we get the FCDEV3B built and proven working, and after we complete all of the experiments (MCSI learning etc) planned for this development board, let's build an end-use-oriented commercial FreeCalypso modem product next - an actual product intended for end use as a production modem, rather than a development board. So what form factor would our proposed commercial FreeCalypso modem take? Look at all of the mainstream (unfortunately 100% closed and proprietary) commercial GSM modem modules for M2M/IoT applications: they all take the form of physically small modules intended to be soldered onto the user's application board as if the module were a chip. Most take the BGA/LGA approach, with solderable pads or solder balls on the bottom of the module, so that it reflow-solders onto the user's board like a really big BGA/LGA chip, but some use the castellated module approach, with half-cut holes along the sides which are used as soldering connection points. I propose that we make our future (after the FCDEV3B) end-use-oriented modem in the form of a castellated module. We won't have a huge number of signals to bring out (about 30), so I figure it should be possible to bring all of the modem's external interface signals (which would include analog EARN&EARP and MICIN&MICIP as well as digital MCSI for the voice channel) to castellated holes around the perimeter, which will serve as connection points. Functionally it will be just like the core of the FCDEV3B (which in turn is a copy of Openmoko's modem block with a couple of minor fixes), but without the developer-oriented (TI Leonardo-inspired) peripheral circuits. For the antenna connection, I'm thinking about putting a u.fl connector on the top of the module, just outside the shieldcan, and having users use u.fl pigtails as is commonly done with WiFi modules. Most commercial GSM modem modules bring the antenna connection on one of the bottom pads like other signals, but my GHz RF-fu is not good enough to do that feat right; a u.fl connector on the top would be a safer approach, even if it's less popular among mainstream commercial products in this sector. Once we produce the core modem as a solder-onto-another-board castellated module, there will be endless possibilities for it to be repackaged into any other convenient form factor (either by us or by anyone else) by way of breakout or carrier boards: we'll have one simple carrier board that brings everything out to connectors just like the FCDEV3B (but with PWON etc better thought-out for end use applications), and we can let others build trivial adapter boards that would turn our modem into an Arduino shield or a Beagle cape or whatever they have for RPi... Having a fully commercialized FreeCalypso modem end-use product would provide us with an official primary target for our modem (as opposed to dumbphone) firmware builds: Openmoko devices are discontinued-ware receding into history, the FCDEV3B is merely a development board rather than an end-use product, but having an official modem product of the end-use kind would finally fill the void. And then we can start working on the dumbphone prototype... But all of these plans are purely hypothetical for now. Before we can take any steps at all toward what I just outlined, we need to complete the following milestones first: * Get the FCDEV3B built and working, proving our core design and the quality of the components, some of which can only be sourced from the grey market; * Get the MCSI situation figured out experimentally: we need to know how it works and prove it working for our needs before we can comtemplate building a commercial modem product that offers a digital voice channel by way of MCSI; * Develop the RF calibration process. All historical commercial Calypso-based GSM devices have been RF-calibrated at the factory, i.e., some RF parameters that differ from each individual unit to the next have been measured and recorded in the flash file system on a per-unit basis on the factory production line. In order to be no worse, we need to replicate this process, and the climbing of the necessary learning curve would be done more sensibly on the development board, before advancing to building the next product. We will need to deblob the l1tm code that handles RF test modes involved in the calibration process, learn the associated TM3 protocol commands, and add support for these commands to our fc-tmsh host utility. Then acquire the necessary external RF test equipment and learn how to use it. It is possible to run a Calypso GSM device without RF calibration; such uncalibrated radio operation happens whenever you run FreeCalypso firmware on one of Mot C1xx targets (Mot/Compal moved their calibration data from TI's standard format into their own proprietary flash data structure which we don't know how to grok), and also whenever you run OsmocomBB on any target, as they don't know how to use RF calibration values at all, even when they are stored in TI's standard format. So far I haven't had a situation where I couldn't connect to a GSM network at all because of the lack of calibration, thus I hope that we should be able to do high-level GSM fw development and testing on the FCDEV3B before we climb the calibration learning curve, but I would argue that we *will* need calibration before we can seriously talk about a commercial product. So these are my thoughts - comments, opinions, flames? Hasta la Victoria, Siempre, The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
