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. |