FCDEV3B update

[Serg l]

Excellent!
I cannot promise anything, but I will try to reach RF experts, who are well
familiar with PCB design techniques for similar applications on Monday.

Regarding initial tests concerns, we can try OpenBTS in controlled
environment. It is not the same as going against live network, however it
can help to make sure that FCDEV3B is not doing something terribly wrong. I
do have USRP2 SDR and I can lend it to you for as long as needed. It can
also work as a spectrum analyzer when you go live, with two receivers to
monitor uplink and downlink at the same time.

On Jan 21, 2017 9:55 PM, "Mychaela Falconia" <mychaela.falconia at gmail.com>
wrote:

> Hello FC community,
>
> It's time for another update on the FCDEV3B project and some related
> happenings.  As I posted here earlier, the order for FCDEV3B PCB
> fabrication was placed on 20170109 with pcbcart, a Chinese PCB
> manufacturer.  Shortly after I submitted the order and sent the Paypal
> payment for $2480.04 USD, they started coming back to me with various
> questions about the order.  Every question they asked me required me
> to do more research and learning (i.e., go deeper and deeper down the
> rabbit hole), but eventually I was able to resolve most of them.
>
> There is, however, one unresolved question which we may only be able
> to answer experimentally, i.e., by trial and error.  Because our
> Calypso+RF modem core is copied directly from Openmoko GTA02 at the
> physical layout level, our board needs to have the same essential
> structure as the GTA02 motherboard: at the minimum, the same number of
> copper layers (8) and the same structure for blind and buried vias.
> However, my original intent was to take our copying of the GTA02 one
> step further and replicate not only the layer count and via drill
> structure, but the complete physical layer stackup: the exact thickness
> of every copper layer and the exact material type and thickness of
> every dielectric layer in between.
>
> We do have FIC/Openmoko's original fabrication notes for GTA02-MB-A6
> which indicate the complete physical layer stackup they used:
>
> ftp://ftp.freecalypso.org/pub/GSM/GTA02/GTA02-MB-A6_fab_notes.pdf
>
> The document is mostly in Chinese (despite all those Germans, Openmoko
> hardware design was still done in Taiwan with manufacturing in
> mainland China, it seems), but the layer stackup description is
> readable nonetheless.  This stackup description includes not only the
> thickness of each copper and dielectric layer (needed for microstrip
> and stripline impedance calculations), but also the exact material
> type (as in fiberglass fabric weave type and resin content percentage)
> for each "prepreg" dielectric layer.
>
> I originally sought to replicate this exact physical stackup verbatim
> for our FCDEV3B, and I had copied the stackup description from the
> Chinese PDF into my own fab notes for the FCDEV3B.  But when the
> people at pcbcart took a sufficiently thorough look at our design
> files (including this stackup request) after receiving the order and
> the payment, they came back to me and said that they need to change
> the stackup.  I asked them why they couldn't replicate the old stackup
> from the GTA02 verbatim, and they said they don't have the PP 1078
> material, which Om's fab notes specify for the L1-L2, L2-L3, L6-L7 and
> L7-L8 dielectrics.  I asked them if they could procure this type of
> prepreg specifically for our board order, and they made me wait about
> a week, saying they were looking into it, but then they came back and
> said they couldn't get it.  They also gave me the impression that this
> type of prepreg is very uncommon, at least nowadays - I don't know
> what the situation was in the days of Openmoko.
>
> The big question here to which we have no answer is whether the layer
> stackup listing in Om's old fab notes is a description or a
> prescription: were they using PP 1078 because 10 y ago the situation
> was different, this type of PP was common and this stackup was used
> regularly by their fab at the time, or do they specifically call for
> PP 1078 no matter how uncommon or expensive it may be because it is
> needed for some technical reason?  Unfortunately, we have no answer to
> this question, hence I'm afraid that we'll have to go with trial and
> error.
>
> Pcbcart proposed an alternative physical stackup in which the copper
> layers stay exactly the same (8 total, 1 oz copper on each), but the
> dielectic thicknesses are a little different:
>
> https://www.freecalypso.org/members/falcon/fcdev3b/
> pcbcart/stackup-20170119.png
>
> It's a bit counter-intuitive, but the numbers on the left in mils are
> the thickness values for the dielectrics alone, whereas the numbers on
> the right in mm give the thickness of the dielectric plus the copper
> foil where the description in the middle column includes one of the
> latter.  Also where it says 18 um for the top and bottom copper layers
> (corresponding to half-oz copper), that's the copper before the
> plating; they said the finished copper thickness after the plating
> will correspond to 1 oz as required.  If we accept their stackup
> proposal, they will also adjust the trace widths for controlled
> impedance as follows:
>
> * 50 ohm microstrips on L8 will need to be widened from 11 mil to
>   12.8 mil;
>
> * 50 ohm striplines on L5 will need to be shrunk from 6.95 mil to
>   5.15 mil.
>
> Based on my very limited knowledge as an outsider (i.e., as someone
> who doesn't know why the cellular industry 10 y ago did things the way
> they did and not some other way), I don't see anything wrong with the
> stackup proposed by pcbcart, i.e., as long as they maintain the
> impedance of our RF traces within 10% of the expected 50 ohm (Om's
> original fab notes also say 10% tolerance for the impedance), I don't
> foresee any problems with the functioning of the circuit.  But then
> again, I am an outsider who constantly scratches her head in
> bewilderment at why things were done the way they were, and not a true
> expert by any means.
>
> In any case, given that pcbcart folks say they can't reproduce the
> original GTA02 layer stackup verbatim, including the use of PP 1078,
> we practically have two choices at this point:
>
> 1. We can accept pcbcart's proposed stackup change and give them the
>    go-ahead to proceed with fabrication.
>
> 2. We can tell pcbcart to cancel the order, demand a Paypal refund,
>    and go back to square one, looking for other PCB fabs who may be
>    able to use PP 1078 and reproduce Om's original stackup exactly,
>    likely at a much higher cost, and we don't even know if anyone does
>    PP 1078 any more.
>
> Given our circumstances, my own leaning is toward option 1.  Given
> that we really don't know if the use of PP 1078 is necessary or if
> using an alternate stackup like the one proposed by pcbcart is just
> fine, it does not make sense to me to throw ourselves back to square
> one and probably spend a lot more money because of this uncertainty.
> Yes, there is the risk with option 1 that after we have spent the
> money getting our boards built, we may discover that the resulting
> boards have degraded RF performance (poorer Rx sensitivity, higher BER
> or needing more source power to produce the same Tx power levels at
> the antenna) compared to Openmoko's original because of the stackup
> change.  But then we have plenty of other risk factors (we won't know
> for certain if our Calypso and other chips are good until we spend the
> money and get our boards built, for example), and like it or not, we
> have to take these risks in order to advance our project forward.
>
> Right now I have an outstanding email inquiry to the anonymous person
> whose very generous donation of 3000 EUR has paid for the current
> on-hold order with pcbcart - I need that person's approval (or a
> timeout) before I can proceed with option 1 per my own leanings.  If I
> get this person's approval, or if I hear nothing back by next Friday,
> I will give my go-ahead to pcbcart, let them build our boards with
> their stackup and hope for the best.
>
> The "hope for the best" part requires an explanation of its own.  The
> arguably most essential part of a Calypso GSM device, the part that
> actually makes it a GSM device as opposed to any run-of-the-mill
> general-purpose microprocessor board, is the radio tract, but it is
> not the first part to be tested during bring-up.  When I get the first
> few boards populated with parts, the first bring-up milestone we'll
> need to achieve (after the power-up sequence) will be talking to the
> Calypso boot ROM via the UARTs, loading some code into the Calypso
> on-chip internal RAM and running that code, e.g., by running
> fc-loadtool and having it successfully load and run loadagent on the
> target.  Once we have reached this milestone, the next step will be to
> get the external (board level) flash+pSRAM chip working, i.e., have
> working XRAM and the ability to load code into flash.  Only then we'll
> be able to run our first firmware image, and even at this point the
> radio tract could be missing altogether!  Once we can get a firmware
> image running (after having got the Calypso boot ROM, the UARTs and
> the flash+XRAM chip working), we'll be able to check out the SIM
> interface, and only then try bringing up the radio...
>
> OK, so assuming that all of listed prerequisites pass and we reach the
> point of being ready to start exercising the GSM radio part of our
> board, how do we actually do the latter?  If the SIM interface works,
> I'll try the quick and easy way: insert a SIM, issue an AT+CFUN=1
> command followed by AT+COPS=0, and see if the modem is able to pick up
> and register to the live GSM network in my neck of the woods.  Yes, I
> know full well that firing up a completely untested experimental MS
> against a live network is against all rules, but I am a naughty girl
> used to breaking rules, and it is by far the quickest and easiest test.
> But if this quick&easy test fails, or if there is a problem with the
> SIM interface such that we would like to bypass the latter and try
> bringing up the radio without the SIM, we'll need to do the slow and
> proper way: L1/RF test modes and calibration.
>
> Going through the complete RF test and calibration procedure will be
> the only way to objectively evaluate the RF performance of our boards
> and to compare it against that of the Openmoko-made GTA02, and to give
> our boards the proper fighting chance of being able to operate on
> commercial GSM networks.  Even if get lucky and succeed in connecting
> to a live network in the uncalibrated state, we are still going to
> need to do the calibration to ensure fully reliable operation, and if
> we don't get so lucky, we'll need to reserve judgment until we have
> tried calibration.  The results of the RF calibration tests will also
> give us an objective empirical answer as to whether or not it was
> acceptable to change the board layer stackup details, and several
> other currently unanswerable questions of similar nature.
>
> Given the importance of the RF test and calibration procedures, I've
> been making some preparations for venturing into that land ahead of
> the boards.  There are two parts to these RF test and calibration
> procedures:
>
> * External RF test equipment to be connected to the device under test
>   in place of the GSM antenna.  TI used Rohde & Schwarz CMU200;
>   looking on ebay, I see several of them up for sale on any given day,
>   with prices ranging from affordable to really expensive.  Of course
>   I don't know what the catch may be with the lower-priced units - I
>   still have a lot of learning ahead of me.
>
> * Special L1/RF test processes to be executed on the Calypso device
>   itself.  We need to get this part fully under our control before it
>   will make any sense to acquire a CMU200 or other external test
>   equipment, hence I am currently focusing on this part.
>
> As the first preparatory step toward RF calibration and test
> procedures, I have deblobbed the part of L1 responsible for the test
> modes.  TI's official TCS211 firmware for the Calypso includes a
> special component for executing RF test operations; this component is
> implemented inside L1 and remains a part of the fw images shipped with
> products, but it lies dormant until and unless it receives special
> command packets over the debug trace UART port aka RVTMUX.
> Manufacturers of TI-based GSM devices who followed TI's canonical way
> of doing things without major rearchitecting - Openmoko being the best
> example - programmed their devices at the factory with a TCS211-based
> fw image, then sent those special commands to the device running the
> fw to perform the per-unit RF calibration, and then kept the same fw
> for the shipping product, i.e., there is no special code that needs to
> be flashed or executed out of RAM just for production tests and
> calibration, and the code intended to only ever run on the factory
> production line remains in the shipped products.
>
> Because the fw component in question is implemented as part of L1, we
> have received the canonical Calypso/TCS211 version of this component
> in the form of binary blobs rather than source, just like the rest of
> L1.  The core parts of L1 (everything except audio functions, test
> modes and GPRS-specific code) have been successfully deblobbed back in
> the first half of 2016, i.e., I successfully reconstructed C code that
> compiles into an equivalent of the binary blobs we got with the
> official delivery, but l1audio and l1tm were left for later.  Well, I
> am proud to announce that l1tm has now been deblobbed too; you can
> find this work in the tcs211-l1-reconst Hg tree.  At the present time
> I don't seek to make any changes to this code, and I would like our RF
> test and calibration procedures to work against the unmodified blob-
> laden TCS211 fw build, but having reconstructed the source to the l1tm
> code allows us to study and understand it.
>
> But the l1tm code inside the firmware is only one part; the other part
> of the magic lies in the host tools that send those special command
> packets that awaken the l1tm beast.  Unfortunately TI made their host
> tools only for Windows, AFAIK most devices manufacturers only got them
> as Windows EXE and DLL binaries sans source, and even in the case of
> those Windows binaries, I haven't been able to locate all of them.  We
> have the Windows binaries for PCO (a G23M stack debug tool) and CSST
> (a LoCosto-ism, I don't know if it can work with Calypso at all), but
> not FLUID or any of their PCTM or TMSH tools.  FLUID was their low-
> level flashing tool which is now fully supplanted by our fc-loadtool,
> but we still need to write our own replacement for TI's PCTM or TMSH.
>
> It appears that TI's original Winblows tool for sending Test Mode
> commands to their GSM firmwares and catching the responses was called
> PCTM, and then at some point it got renamed or transformed into
> something they called TMSH for Test Mode Shell - perhaps this change
> happened at the same time when ETM joined the original non-enhanced TM
> on the firmware side, or maybe the two happened at different times.
> As I already said, I haven't found any Windows binaries (let alone
> sources) for either PCTM or TMSH, but we have a couple of TI documents
> which explain how to perform RF test and calibration procedures using
> PCTM or TMSH commands, thus giving examples of their syntax, and I
> also found a seemingly-complete listing of TMSH commands on this web
> page:
>
> http://elinux.org/Peek#Tools
>
> Looking at that list of commands, one can clearly see that some of
> them are FFS (flash file system) operations which we have already
> implemented in our own different way in our fc-fsio utility, a few are
> generic memory and register peeks and pokes that can be implemented
> either through older TM3 command packets to the fw or newer ETM ones,
> and then there are the L1/RF test mode commands which we'll need for
> our test and calibration procedures.
>
> I had heard of at least the name TMSH quite early in the FreeCalypso
> project, thus as far back as 2013-11 when I started writing our first
> host utility for sending ETM command packets to running fw, I named it
> fc-tmsh.  This fc-tmsh program still exists in the present FreeCalypso
> host tools suite, and it serves approximately the same purpose as TI's
> TMSH (to the extent to which I can make inferences about the latter
> without actually having a copy): sending TM and ETM commands to
> running GSM device firmwares and receiving and displaying fw responses
> to these commands.  Our fc-tmsh is strictly a low-level tool: each
> command typed by the operator results in a corresponding TM/ETM packet
> being sent to the target.  TI's TMSH appears to include both elementary
> operations of this sort as well as some higher-level commands for FFS
> where a single user command corresponds to quite a few complex ETM
> packet exchanges with the target; in our case we have moved these
> complex FFS operations from fc-tmsh into fc-fsio, a separate utility
> with a very different internal architecture that is more suitable for
> performing complex sequences of elementary operations.
>
> Right now our fc-tmsh bears no resemblance at all to TI's TMSH: no FFS
> commands in fc-tmsh (and the ones that are implemented in fc-fsio have
> entirely different names, syntax and command repertoire), no L1/RF
> test mode commands yet, and for the few ETM operations which are
> supported by both TI's TMSH and our fc-tmsh, the syntax is once again
> different.  This incompatibility is what usually happens when you have
> to do a from-scratch reimplementation without being able to even look
> at the original...
>
> But I am hoping to mend this rift between TI's PCTM/TMSH and our fc-tmsh
> at least a little bit in the case of the L1/RF test mode commands.
> Even though we don't have a copy of TI's PCTM or TMSH, we now have the
> reconstructed source for the l1tm target-side code that receives and
> acts upon the commands sent by these Windows tools, and we have TI
> documents with examples of how PCTM and TMSH commands were typed.  The
> command packet types (called CIDs) which can be sent to l1tm via the
> TM3 protocol are defined in l1tm_msgty.h on the GSM fw side (look in
> the tcs211-l1-reconst repository), and the names of user commands
> implemented by TI's TMSH are listed on the web page above.  Comparing
> the two, there is a very obvious one-to-one correspondence:
>
> tms command sends a TM_MODE_SET packet
> rfe command sends an RF_ENABLE packet
> rfpw command sends an RF_PARAM_WRITE packet
>
> and so forth.  Furthermore, the examples of these commands in TI's RF
> calibration tutorial documents show very clearly that the arguments to
> these commands (all numbers) go directly into those command packets in
> the most straightforward manner, without any intelligence on the part
> of the Windows tool.  Thus if I implement these commands in the most
> straightforward manner in our fc-tmsh, we'll provide essentially the
> same operator experience as TI's tools did, and the syntax given in
> TI's RF calibration tutorials should work with our Free Software tools.
>
> The only commands which I plan on implementing differently from TI's
> tools are rftw for sending RF_TABLE_WRITE packets and ttw for sending
> TX_TEMPLATE_WRITE.  The ttw packet carries a payload of 32 bytes
> giving the Tx power ramp-up and ramp-down profiles; the rftw packet
> carries different payload types and formats depending on the opcode
> (the first numeric argument after the rftw command keyword), but these
> tables range from 24 to 128 bytes.  Adjusting for 16-bit and 32-bit
> fields, the count of decimal numbers going into a single table to be
> sent with a single rftw command ranges from 8 to 96; I dunno about
> others, but I do not particularly feel like entering a table of 96
> numbers all on one line.  Hence I plan on making fc-tmsh versions of
> these commands read the to-be-sent table content from sensibly
> formatted text files.
>
> So far I have implemented tms, rfe, scw, scr, sr, rfpw and rfpr
> commands in fc-tmsh; rftw, rftr, rxpw, rxpr, txpw, txpr, ttw, ttr,
> mpw, mpr and me remain to be implemented.  I was working on this code
> last weekend, but then paused to decide what to do about the big table
> sending commands.  I will need to finish this implementation (either
> before or after we get our FCDEV3B boards built) before we can start
> really playing with L1/RF test modes.
>
> Hasta la Victoria, Siempre!
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community
>