Hello FreeCalypso community, It's been quiet here for the past 3 weeks, so I thought I would give a little update.
The FC firmware subproject still stands where it did at the beginning of this month: running on either Openmoko's modem or the Pirelli DP-L10, our gcc-built fw can access the SIM, connect to a live commercial GSM network and send and receive SMS successfully, but voice calls fail. Investigation into why voice calls fail led me to the conclusion that we need to load the same DSP patches as the working TCS211 reference fw (at least the static patch) before we can proceed further; I added that static DSP patch and enabled its loading, but it doesn't work - the checksum reported by the DSP is wrong, indicating that the patch must be getting loaded incorrectly. My plan of attack is to table this firmware subproject aside and switch to the hardware subproject. For a long time I've been wanting to build a Calypso GSM development board that would serve as a platform for our firmware development and hardware experimentation, and the issue we are having right now with that DSP patch loading is a perfect excuse to set the fw work aside for the moment and go build that board. Trying to debug the DSP patch bug using currently available hw would be a pita because we don't have any available platform that both has JTAG and can run TCS211: the latter can only run on the GTA02 modem, and JTAG signals of the Calypso are completely inaccessible on that hw. But if we build the board I have in mind, we'll have a hardware platform that can run TCS211 *and* provides JTAG access - just what we need. So, what is this board I want to build? Here is what I envision: * Core Calypso chipset and RF section using the same "variable" components (RF PA, VCXO etc) and wired up exactly the same way as Openmoko's GTA02 modem, so we can run TCS211 on it with absolutely minimal surgery on the binary blobs; * External connections for the battery-emulating power supply (VBAT) and for the antenna just like on TI's own historical development boards: https://www.freecalypso.org/boards/d-sample.jpeg * Both Calypso UARTs brought out on headers, ditto for the JTAG and MCSI debug interfaces; * An on-board SIM socket (obvious), a microphone and a loudspeaker for voice testing, connected to the respective connection points on the core chipset. So how do we go about building this board? Well, I got the schematic design already started: https://bitbucket.org/falconian/freecalypso-schem https://bitbucket.org/falconian/ueda-linux I already got the schematic design of the core section captured in my non-graphical "schematic" language (a novel reuse of the structural subset of Verilog, as in just wires and hierarchy instantiations), but I have yet to capture the peripherals (connectors etc) outside of the core section. OK, so that's the schematic design, which is just the first half of a board design project. What about the other half - PCB layout? Well, I searched high and low for a surviving copy of TI's original layout for their Leonardo reference board (2003-2004 timeframe), but I came up empty-handed. :( That reference layout appears to have been lost in the cracks of time and obscurity. :( But thankfully we have a fully preserved copy of Openmoko's PCB layout for their GTA02, which was recently released by Sean Moss-Pultz (the founder of Openmoko) upon my request: ftp://ftp.freecalypso.org/pub/GSM/GTA02/GTA02-MB-A6.zip Openmoko's PCB layout was done in PADS; the ZIP cited above contains the original PADS file, a PDF print and the full set of gerbers. I can think of 3 possible ways how we could produce a PCB layout for our FreeCalypso GSM development board based on Openmoko's: 1. If some member of our community has access to a working installation of PADS (a version that can successfully open and edit the PCB file we got from Openmoko) and is a PCB design engineer who is comfortable with that software, perhaps we could load Openmoko's layout into PADS, remove all of Openmoko's components outside of the Calypso modem block, add the components and connections we need (external power and debug connectors etc) and generate our gerbers from there. Advantage: most direct reuse of Openmoko's known-good PCB design, including all of the GHz RF critical sections. Disadvantage: PADS is proprietary software. :( 2. We could redraw Openmoko's PCB layout from their gerbers in a FLOSS EDA tool of our choice, but still copy their layout verbatim, millimeter for millimeter, trace for trace, via for via. Advantage: we would break out from the clutches of a proprietary EDA format while preserving the known-good PCB design as with option 1. Disadvantage: while I can't speak from experience as I don't do any PCB layout work myself (see below), I can only imagine that trying to reproduce an existing layout millimeter for millimeter etc while manually redrawing it in a new program would probably be an incredible pain. An additional problem with reproducing Openmoko's layout verbatim in FLOSS PCB is that the former uses blind and buried vias which the latter does not support at the moment. 3. We could create a new layout of our own from scratch, working from the ueda-generated netlist and an approximate component placement guide, copying only the known-good footprints from Openmoko's PADS layout. (Redraw the latter in FLOSS PCB using Openmoko's gerbers as the reference.) Advantage: a work flow most similar to how new PCB design is conventionally done, without the added pressure of having to reproduce something old that was done in a foreign tool. Disadvantage: no real reuse of Openmoko's known-good Calypso modem layout (GHz RF and all) beyond part footprints; whatever quirks need to be accounted for in the PCB design in order for this thing to work, we'll have to rediscover by trial and error - possibly quite expensive trial and error involving board respins. Which brings me to - I am delighted to see that my old acquaintance Ineiev has joined our mailing list. Welcome, dear comrade! Ineiev is a PCB design engineer whose work I can vouch for, as he did the PCB layout for my OSDCU board: a CSU/DSU that converts SDSL (Symmetric DSL aka Slow DSL aka Spacefalcon DSL) into EIA-530 (essentially the same as V.35), including software-mediated conversion from ATM into HDLC. The board is an Open Source Hardware design which you can find here: ftp://ftp.freecalypso.org/pub/net/PHY/SDSL/OSDCU/ I designed the board at the schematics+BOM level, and when I was looking for someone I could afford to hire to do the PCB layout (I was born with a brain that excels at just about any task that can be reduced to lines of ASCII text, but totally sucks at anything graphical or visual, hence asking me to do my own PCB layout would be like asking a blind person to pilot an airplane), Ineiev offered to do it for a very affordable price - not because he is cheap, but because he supports Open Source Hardware! So Ineiev, would you be interested in doing the PCB layout of our FreeCalypso GSM development board using any of the 3 approaches outlined above? Finally, this board design proposal won't be complete without a discussion of the triband vs quadband dilemma. TI had a quadband reference design in the form of Leonardo+ (the E-Sample board for their later Calypso+ chipset was also quadband AFAICT), but every commercial phone or modem manufacturer to my knowledge reduced it to either 2 bands (single-region, EU-only or US-only) or triband (2 EU bands + 1 US band, or rarely vice-versa). Openmoko did likewise: hobbled the modem down from quadband to triband. I could never understand the reason for this hobbling: if they had a working quadband reference design which they could just mindlessly copy, why did they go out of their way to redesign the RF front end for fewer bands? Just corporate malice? But then why did Openmoko do likewise? Building a GSM device that is anything less than quadband means that someone would have to be excluded, and naturally I don't want to exclude anyone. It doesn't really matter so much for the development board which we need to build now: making it Openmoko-like and Pirelli- like 900/1800/1900 MHz triband (850 MHz band excluded) will be sufficient for firmware development, PA power draw characterization, gaining experience with RF calibration and other developer-only uses I have in mind for this board. But when we graduate to building libre phones and modems for end users, I would really like to make them quadband if at all possible. The only way I know of how to build a quadband GSM device with the Calypso chipset is to use this magic component for the RF front end: ftp://ftp.freecalypso.org/pub/GSM/Calypso/M034F.pdf as depicted on the historical Leonardo schematics: ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_plus_quadband_schem.pdf ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_plus_RD122.pdf I do have those elusive Epcos M034F parts on hand physically, so we could try building a board with this RFFE and see how well (or not so well) it will work. If I could find a surviving copy of TI's original PCB layout corresponding to either of the schematic versions cited above, I would have sent the gerbers to fab (w/o any changes at all for the first trial version) and found some answers empirically by now - but alas, no such surviving copy of that layout could be found; it appears to have been irretrievably lost. :( The only part of the original Leonardo+ quadband PCB layout that has survived is the component placement drawing that must have been exported from their PCB layout program; this drawing can be found at end of Leonardo_plus_RD122.pdf, after the schematics. The question facing us right now is whether we should make our first development board triband following Openmoko or quadband following Leonardo. Look at how the core components of the chipset are arranged in Openmoko's modem vs how they are arranged in the Leonardo component placement drawing - they are completely different. Furthermore, I am rather clueless when it comes to GHz RF PCB layout, but in all existing designs I've examined, the traces that carry the Tx output from the PA to the antenna switch and the trace from the latter to the actual antenna connection point are all on the top layer, are very short and direct, and don't cross. I can only assume that such layout is required for proper operation. The pinout of the Epcos M034F magic component needed for the quadband config is such that if we tried to plop it directly into Openmoko's layout in the place of Om's triband RFFE, there would be no way to do it without messing the RF layout up badly: either the PA output traces or the antenna trace would have to go through vias and an inner layer (which I'm guessing is probably a bad idea), and the Rx differential outputs won't connect cleanly to where they need to go. It really seems to me that if we were to go the quadband route with M034F, the overall PCB layout would need to be entirely different: it would need to follow the Leonardo component placement drawing, rather than Openmoko's arrangement. So Ineiev, this question is really for you - if you end up doing the PCB layout of our board, which approach are you more comfortable with: copying Openmoko's known-working layout as close to verbatim as possible, which would necessarily include retaining the triband RFFE for this first prototype, or going directly to the ambitious quadband experiment and having to redo the layout mostly from scratch, with only the surviving Leonardo component placement drawing as a guide? Of course if any other members of our community have some experience with GHz RF PCB design and see flaws or gaps in my reasoning, or if you are considering volunteering to do the PCB layout we need, please speak up as well. :) Happy hacking, Mychaela Falconia aka Space Falcon P.S. For Ineiev or other newcomers to this list who know me from the past but may not have heard the news of my big change yet, please see: https://www.freecalypso.org/pipermail/community/2015-May/000016.html _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
