FreeCalypso > hg > freecalypso-docs
comparison Quadband-ideas @ 20:3fa4006696d0
Quadband-ideas article written
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Tue, 22 Oct 2019 00:04:25 +0000 |
| parents | |
| children | 00216b7cfc4d |
comparison
equal
deleted
inserted
replaced
| 19:f68ca40fa5c1 | 20:3fa4006696d0 |
|---|---|
| 1 Our current Openmoko-based Calypso+RF modem core is very very good, but it has | |
| 2 one shortcoming compared to TI's Leonardo+ reference design: it is triband | |
| 3 rather than quadband. This triband restriction stems from OM's use of discrete | |
| 4 antenna switch and SAW filter components as opposed to an integrated FEM (front | |
| 5 end module) like on Leonardo+. In addition to the band restriction, our current | |
| 6 triband RF design suffers from one other very unpleasant problem: we have no | |
| 7 datasheet for the antenna switch component which we have to use. We know from | |
| 8 Openmoko's BOM data that the manufacturer is Darfon and that the part number for | |
| 9 this antenna switch component is ASM4532T0P06-1, we are able to buy this part | |
| 10 from our Chinese grey market suppliers, we build our boards with these parts and | |
| 11 our boards do work perfectly fine when we get a good batch, but we have to do | |
| 12 this entire process blindly, without any datasheet or other documentation for | |
| 13 this mystery part. | |
| 14 | |
| 15 This article outlines some ideas for how we may be able to move from this RFFE | |
| 16 to a different one, replacing our current mystery antenna switch with something | |
| 17 less mysterious and better documented, and improving our radio capability from | |
| 18 triband to quadband at the same time. | |
| 19 | |
| 20 Epcos M034F | |
| 21 =========== | |
| 22 | |
| 23 TI's Leonardo+ and E-Sample boards used a magic component made by Epcos (the | |
| 24 canonical SAW filter manufacturer during that era) called M034 or M034F (the | |
| 25 exact proper designation is unclear). It was an integrated quadband FEM, | |
| 26 integrating the antenna switch and SAW filters in one component package, with a | |
| 27 special twist. The special twist is that even though there are 4 separate Rx | |
| 28 band SAW filters inside that M034 "chip" module, corresponding to its advertised | |
| 29 quadband capability, only 3 Rx signal path differential pairs come out of it, | |
| 30 neatly corresponding to the 3 LNA inputs on TI's Rita transceiver. This twist | |
| 31 is important because even though the Rita transceiver itself is fully quadband | |
| 32 internally, it has only 3 LNA inputs, with GSM850 and EGSM bands sharing the | |
| 33 same LNA input while each of DCS and PCS get their own. | |
| 34 | |
| 35 We do have an M034F.pdf datasheet for this magic component (came along with | |
| 36 Calypso and Leonardo docs), and the block diagram on page 6 shows the magic | |
| 37 quite clearly: there is a baseband-controlled switch selecting between EGSM Rx | |
| 38 and GSM850 Rx (in addition to the two usual Tx switches), this switch directs | |
| 39 the low band Rx path toward one of two different SAW filters, and the outputs | |
| 40 of those two filters are then joined. The high band Rx path always goes to both | |
| 41 DCS and PCS band SAW filters (I assume it is a 50/50 split of the total incoming | |
| 42 energy, with each path suffering by 3 dB as a result), and each of those high | |
| 43 band Rx SAW filters gets its own output going to its own dedicated Rita LNA | |
| 44 input. | |
| 45 | |
| 46 I (Mother Mychaela) would absolutely love to play with an M034-based quadband | |
| 47 Calypso+Iota+Rita board in my lab with the trusty CMU200 instrument, and to see | |
| 48 how well it actually performs, especially in comparison with our current | |
| 49 OM-based triband version. However, in all of my years of searching I have never | |
| 50 found a physical Leonardo board (any version), nor have we ever found any | |
| 51 Leonardo PCB layout files which would allow us to build a modern recreation - | |
| 52 thus the magic of M034 remains elusive. | |
| 53 | |
| 54 Unless a miracle happens and we are able to obtain either a physical Leonardo+ | |
| 55 board or a PADS PCB file for one, there is no quick or low-effort way to "just | |
| 56 try" this M034 RFFE. Instead if we wish to build a FreeCalypso board with this | |
| 57 RFFE, it would have to be "the full 9 yards": a full-blown PCB design and layout | |
| 58 effort. There is no way to just "drop" the M034 into our existing PCB design | |
| 59 in the place of our current triband RFFE, it would have to be either a very | |
| 60 disruptive RF section layout change or an entirely new PCB layout, making this | |
| 61 idea very open-ended - an open-ended venture with quite uncertain outcome, but | |
| 62 with a high dollar cost attached to it. Given the massive effort required and | |
| 63 PCB layout labor costs, I currently have no active plans to pursue this idea | |
| 64 beyond hypothetical. | |
| 65 | |
| 66 Commissioning a new custom RF FEM | |
| 67 ================================= | |
| 68 | |
| 69 Here is a wild thought: what if instead of twisting over backwards trying to | |
| 70 hammer an existing RF FEM like M034F into our not-quite-fitting PCB design, we | |
| 71 were to get an entirely new FEM made specially for us, made exactly the way we | |
| 72 need it? If we were to venture that way, I would ask for a FEM very similar | |
| 73 conceptually to M034F, but with a few changes: | |
| 74 | |
| 75 1) Instead of diplexing between DCS and PCS SAW filter inputs with a 50/50 | |
| 76 energy split, implement another switch (just like the GSM850 Rx switch) for | |
| 77 PCS Rx, exactly the same way how it is done in classic triband designs like | |
| 78 our current OM-based one. This change should eliminate the extra 3 dB | |
| 79 penalty which I assume (for lack of experimental data) must happen with the | |
| 80 existing M034 FEM. Or as an alternative to making this change, if someone | |
| 81 who is more knowledgeable than me in this area can explain to me why it isn't | |
| 82 necessary, I would accept that option as well. | |
| 83 | |
| 84 2) I would ask for a rearranged pinout: the existing M034F pinout does not fit | |
| 85 at all into our OM-based PCB layout, but it would fit much better with some | |
| 86 rearrangement. | |
| 87 | |
| 88 3) The hypothetical M034-like FEM would fit into our OM-based PCB layout a lot | |
| 89 better if it were made a little smaller than the 8.2x5.5 mm size of M034F. | |
| 90 Considering that the original M034F was created some 15-16 y ago, I assume | |
| 91 that it should be possible to make a smaller version in 2020 or 2021 or | |
| 92 whenever. | |
| 93 | |
| 94 Timeline sequentiality | |
| 95 ====================== | |
| 96 | |
| 97 All of the above ideas will be considered on a less hypothetical level after we | |
| 98 get our already-committed FCM40 product built. FCM40 will be a modem module in | |
| 99 the same 56.5x36 mm form factor as Huawei GTM900 (with a mostly-compatible FPC | |
| 100 interface with only a few changes), featuring the same OM-based triband modem | |
| 101 core as FCDEV3B V2. The reason for this sequencing is that our current FCDEV3B | |
| 102 suffers from a couple of issues which FCM40 is expected to solve: | |
| 103 | |
| 104 1) FCDEV3B has a very tight PCB layout: not only do we have the tightly laid out | |
| 105 core from GTA02, but also the whole board is quite small for the implemented | |
| 106 peripheral complexity, imposing further constraints from all sides. This | |
| 107 tight and complex layout makes a poor choice of starting point for bold | |
| 108 experiments like RFFE changes. | |
| 109 | |
| 110 2) FCDEV3B is locked into Altium. Layout data migration from Altium to FOSS | |
| 111 appears to be much less feasible than migration from PADS to FOSS, thus | |
| 112 freeing our PCB layout from the clutches of proprietary software will most | |
| 113 likely require giving up (or rather setting aside) all of FCDEV3B new layout | |
| 114 and going back to the GTA02 starting point, which is in PADS format rather | |
| 115 than Altium. Redoing all of FCDEV3B anew does not sound appealing at all, | |
| 116 but the much simpler FCM40 board offers a perfect opportunity for a fresh | |
| 117 start. | |
| 118 | |
| 119 FCM40 will have exactly the same OM-based triband RFFE as our current FCDEV3B, | |
| 120 but it will be a much simpler board, and if we can get it done in FOSS instead | |
| 121 of continuing the Altium track, then we would have a very solid reference and a | |
| 122 good starting point for potential RFFE change experiments. | |
| 123 | |
| 124 Firmware compatibility | |
| 125 ====================== | |
| 126 | |
| 127 Our current FreeCalypso firmwares drive TSPACT RFFE control signals as follows | |
| 128 on FC hw family targets (CONFIG_TARGET_FCFAM): | |
| 129 | |
| 130 TSPACT1 = Rx PCS band | |
| 131 TSPACT2 = Tx high bands | |
| 132 TSPACT4 = Tx low bands | |
| 133 TSPACT5 = Rx GSM850 band | |
| 134 | |
| 135 The driving of TSPACT1, TSPACT2 and TSPACT4 matches the way these signals have | |
| 136 been assigned by Openmoko and thus the way they function on our current OM-based | |
| 137 triband RFFE, whereas TSPACT5 is a new signal which is not wired anywhere on | |
| 138 our current FCDEV3B. This signal driving arrangement is expected to be | |
| 139 compatible with all 3 RFFE hw possibilities under consideration: | |
| 140 | |
| 141 * On our current OM-based triband RFFE it works as is. | |
| 142 | |
| 143 * If we use Epcos M034 or a semi-clone thereof that has the two Tx switches and | |
| 144 a GSM850 Rx switch but no PCS Rx switch, then we will need to connect TSPACT2, | |
| 145 TSPACT4 and TSPACT5 per the table above, and leave TSPACT1 unconnected. | |
| 146 | |
| 147 * If we get a new M034-like FEM custom-made with a full set of all 4 switches, | |
| 148 then all 4 TSPACT signals will need to be connected per the table above. |
