From mychaela.falconia at gmail.com Sun Mar 10 07:48:18 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sat, 9 Mar 2019 23:48:18 -0800 Subject: OBB does not work against CMU200 BTS simulator Message-ID: Hello OsmocomBB gang, Earlier today I was trying to run OBB against my CMU200 GSM MS RF tester, with the objective of trying to determine if the change currently stalled in OS#3582 (switching the Tx APC code in OBB from the original to my modified version that uses the same numbers as each target's respective original fw, i.e., Compal's numbers on Mot C1xx or FreeCalypso numbers on the FCDEV3B) makes things better or worse on OBB's primary compal_e88 platform (Mot C118). Running OBB with Tx enabled on a Motorola phone that has its internal antenna connection fully intact is not only illegal (transmitting in the tightly regulated GSM bands from an unlicensed device) but actually dangerous and harmful: as my CMU200 experiments have confirmed, OBB's transmissions are so wildly out of spec that the risk of causing *actual* interference and disruption to cellular networks is very real. While I don't give a damn about silly laws that declare perfectly safe and harmless things to be illegal, I do very much care about not disrupting cellular networks which people actually use for important communication, including safety-of-life communication, hence letting OBB transmit on real live airwaves is a big no-no. Instead the *only* safe way to run a Tx-enabled build of OBB layer1 on a Mot C1xx or SE J100 phone is to insert an RF cable terminated with an appropriate probe adapter into the RF test port on the back of the phone, and connect this cable to your own test BTS or to a specialized GSM MS RF tester like R&S CMU200. Pull out the rubber plug that keeps dust out, and insert the appropriate adapter. I use a Hirose MS-147-HRMJ-1 adapter for old-style MS-147 RF test ports on C118 and C155/156 phones, and a Murata MXHS83QH3000 adapter for the newer style of RF test ports found on Mot C139/140, SE J100, Openmoko, Pirelli and most newer phones. Both adapters are from Digi-Key, and both are still readily and cheaply available there. Both adapters convert the RF test port to SMA, and unlike the other SMA to MS-147 pigtail sold by Sysmocom, neither of my adapters requires any disassembly of the phone case - just pull out the rubber plug. The critical point here is that when you insert a probe into that RF test port under the rubber cover, the internal antenna is disconnected. Because I do not currently have my own sysmoBTS (at least not yet, may be able to afford one in another couple of months) and I have no interest in messing with SDR devices or trying to make a poor man's BTS out of one, the only thing to which I can connect GSM MS devices under test is my R&S CMU200 instrument. This instrument is generally considered to be the gold standard in the mainstream professional (non-FOSS) GSM industry, and I use it all the time to test not only my own FreeCalypso devices, but also various pre-existing ones, and they don't have to be TI-based or have hackable firmware. The CMU200 does have a so-called non-signalling mode that allows low-level Rx and Tx operations to be tested directly, and this mode of operation does require GSM MS firmware with special RF test modes that bypass all higher layers of the protocol stack - but the CMU200 instrument also has a "signalling" mode in which it acts as a standard BTS, allowing any MS to be tested as a black box. This signalling mode of the CMU200 works with every GSM MS in my experience (with FreeCalypso, with Motorola's original fw on all C1xx phones, and with various other phones with completely unknown chipsets and firmware architectures) with the exception of OBB. At first I had no success with getting OBB to play nice with the CMU200 at all: I would turn on the simulated BTS downlink signal on the CMU, run OBB's mobile app, and it would register to the test network - but as soon as I press the "Connect mobile" (call to MS) button on the CMU, everything would go haywire. However, after a lot of trial and error I figured out where at least some of the breakage is happening: 1) In order for the "call to MS" operation to succeed, the MS Tx power level setting on the CMU200 (i.e., the power level which the CMU acting as a BTS directs the MS to transmit at) must be set to each band's respective maximum (PCL 5 for low bands or PCL 0 for high bands), which is not the default setting. If one tries to make a call-to-MS from the CMU with the MS Tx power level set to something lower, it works just fine with every type-approved or would-pass-approval-if-someone- paid-for-it GSM MS including FreeCalypso and Mot original fw, but if one tries the same thing with OBB, a message pops up on the CMU200 screen saying "Overload at connector RF2", mobile's vty window says "% Call has been released", and everything breaks from there onward. At first I was totally bewildered as to how CMU200's input could possibly be overloaded when the RF2 port in question is rated for 33 dBm continuous power, the PA on my FCDEV3B or on Mot C1xx phones cannot put out anything more than 30 dBm in the DCS/PCS high bands, and my cable has about 2.2 dB of attenuation which I account for in my calibration and test procedures - an overload sounds physically impossible in this setup. But then I realized what is happening: because the CMU200 expects the MS to transmit at the power level instructed by the CMU acting as the BTS, the instrument software configures its sophisticated Rx chain for optimal reception at power levels around that target. What appears to be happening with OBB as the MS is that OBB does not implement Tx power control correctly, and transmits at the maximum power level even when the BTS told it to transmit at some much lower level. The CMU does not expect such gross misbehaviour from candidate MS devices submitted for type approval testing, and some stage in the configured Rx chain gets overloaded. Next experiment: I established a call between OBB and the CMU200 by setting the MS Tx power level knob to the maximum for the band I am testing in, and then tried changing it within the active call, i.e., had the CMU acting as the BTS command the MS to change its Tx power level while staying in dedicated mode. I am not sure if this signalling happens over FACCH or SACCH, but once again it works without a hitch with every type-approved or would-pass-approval phone I have available for testing, and I use this method all the time to verify the complete range of Tx power levels on the MS under test. Not so with OBB: I don't remember the exact error message displayed by the CMU200, but it was something along the lines of the MS failing to act on the Tx power level change command, and then it would drop the call. So apparently OBB fails to implement this aspect of the spec as well. So what about the OS#3582 change? Does it make things better or worse? Answer: I was unable to test it because the other show-stopping defects in OBB's GSM MS implementation prevent me from getting that far. The combination of the two bugs above (no ability to establish the call unless the MS Tx power level is set to max, and no ability to change the power level within the test call) makes it impossible to step through the power levels and see what the mobile puts out at each PCL, hence no ability to test the change. There also appears to be something wrong with OBB's timing of various steps involved in burst transmission, i.e., Calypso TPU programming. I say so because even if I stay at the band's maximum power level (don't try to change it), the CMU200 reports the power ramp as being out of tolerance, even with my OS#3582 patch which makes the actual ramp programming exactly the same as what each device's official fw uses to produce perfectly passing ramps - so it is probably something to do with timing. OK, so why did I produce this OS#3582 patch if it doesn't make things any better in practice because of other major bugs elsewhere? The answer is that it was my knee-jerk reaction to seeing hard-coded numbers for Tx power levels and ramps and for the VCXO slope that are completely and obviously wrong for Openmoko/FCDEV3B hardware. The hard-coded Tx power level and VCXO slope numbers in the current OBB master are approximately correct (at least within the ballpark of correctness) for Mot C11x/12x/155/156, but are NOT correct even for Mot C139/140 (different PA with different characteristics), and are wildly off-base for the completely different Openmoko/FCDEV3B RF hw - someone claimed Openmoko gta0x as "supported" all those years ago without anyone doing any real tests on that platform, and without noticing the utter bogosity. What was happening is that people were asking about running OBB on FCDEV3B hardware, I was trying to support those people in the hope that they would buy the hardware at the fair commercial price (which hasn't happened), it was obvious to me from a very cursory glance at the code that the stuff in current master has exactly zero chance of working anywhere close to correctly on my hw given those totally wrong hard-coded numbers, so I felt that at that very minimum, I had to fix those bogus numbers. Trying to fix just the numbers while keeping the architecture of the code that uses them was also a non-starter (more utter bogosity like trying to use GSM900 band APC numbers for all bands), so I did the only thing that seemed sensible: ripped that gunk out and replaced it with Tx parameter tables in the chip vendor's original format, filled with bits read from factory RF calibration records. But as today's experiments show, it was pretty much for nothing: while you do need to apply this patch if you wish to have any chance of ever putting out spec-compliant radio transmissions, it is nowhere close to being sufficient. The *only* way how OBB would ever reach a point of being safe to use as a GSM MS on live airwaves and being able to seriously compete with properly functioning, spec-compliant GSM MS products like FreeCalypso or Qualcomm/MTK/etc phones running their respective official fw would be if someone were to invest many, many person-years into it, and also invest their own money into appropriate test equipment - a CMU200 or equivalent is an absolute must, otherwise you have no way of knowing what your MS really puts out. And I will *not* *ever* be that person who invests her time and energy into whipping OBB into something that could kinda-sorta approach what MTK, Spreadtrum and FreeCalypso (have I missed any other GSM chipset vendors? I don't count Qualcomm as they hate GSM and give it the "unwanted bastard child" level of support) already provide today, with at least one of the listed vendors freely publishing their full source code. Meanwhile, the takeaway lesson is that running current OBB with Tx enabled on a Motorola phone without disconnecting its internal antenna is NOT safe, and the danger of interference to GSM or other cellular networks is way too high. People on this list swear up and down that no one uses OBB as a phone, instead people who call themselves "researchers" supposedly use it in their test setups somehow. But how exactly? I somehow doubt that most of you so-called "researchers" have expensive Faraday cages or go to the trouble of a fully cabled setup (lots of extra components required: duplexer, attenuators, multiple cables, adapters for connecting to RF test ports on phones) with no radiated transmissions. It seems far more likely to me that most of you so-called "researchers" probably operate your SDR-acting- as-a-BTS in open air, with the downlink signal power level set low enough so you don't get caught despite having no actual license, and your OBB phone transmits back to your home-grown BTS via open air. What I am here to tell you is that doing the above is NOT as safe as you think: if OBB is transmitting at the maximum power level the phone can put out, which is 2 W in the GSM900 band, if the power control is not working (OBB does not lower its Tx power when the BTS tells it to) and the power ramp is wrong for whatever reason (the CMU200 shows it as being out of tolerance), then only Cthulhu knows what kind of interference you may be putting out. My greatest hope is that some day more people will see the light and do the right thing: retire OBB to the dustbin of history as a project that may have been interesting once upon a time but is absolutely NOT worth doing any more work on in the present reality, and redirect their forces to more productive efforts. I am convinced that it would take far less work to reimplement the researcher-oriented functionality of OBB on top of the rock-solid FreeCalypso code base than to bring OBB to a point of being able to compete on technical merit. M~ From mychaela.falconia at gmail.com Sun Mar 10 21:32:14 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 10 Mar 2019 13:32:14 -0800 Subject: OBB does not work against CMU200 BTS simulator In-Reply-To: <20190310211507.dmkuwsb4bwxtml2i@x220> References: <20190310135808.GA14707@localhost> <20190310211507.dmkuwsb4bwxtml2i@x220> Message-ID: Craig wrote: > I do have a Racal Instruments 6103E GSM Digital Radio Test Set which seems to > work well so far. Sorry, I don't have any experience with that instrument, and therefore won't be able to tell you whether or not it would make an acceptable substitute for a CMU200. The CMU200 is the only instrument I have first-hand experience with. > > Another question: is there any way to run any official MTK-based > > firmware, however non-free and blob-laden it may be, on Fernvale hw? > > Probably. I know from reading that Bunnie and Xobs who designed fernvale did > run standard firmware/OS on some similar 6260 based devices. Maybe we could > track down a good firmware and test on fernvale. Firmwares are made for boards, not chips, and there is no such thing as "a good firmware" which you could just "track down". You cannot take fw built for one board and expect it to work on a different board, so if the makers of the Fernvale have not made a customized version of MTK's firmware specifically for their board in the same way how I maintain my own version of TI-based fw specifically for my FCDEV3B, then you are basically screwed on their hw, and won't have any way of testing if their RF hw even works. [RF testing and calibration] > I don't have any clue about these details. Will have to rely on Harald or > maybe inquire of Bunnie and Xobs. My guess is that they probably skipped all RF test and calibration steps which all standard GSM MS manufacturers are required to do, and just ship completely untested RF hardware. This Fernvale is the most misguided hardware project I have ever seen, and I have seen a lot of dumb ideas in my professional career of about 20 y so far. M~ From craig at unreasonablefarm.org Sun Mar 10 21:15:07 2019 From: craig at unreasonablefarm.org (craig) Date: Sun, 10 Mar 2019 16:15:07 -0500 Subject: OBB does not work against CMU200 BTS simulator In-Reply-To: References: <20190310135808.GA14707@localhost> Message-ID: <20190310211507.dmkuwsb4bwxtml2i@x220> Oops, I accidentally replied to Mychaela directly, here's our conversation so far, please others join in with thoughts. On Sun, Mar 10, 2019 at 09:09:31AM -0800, Mychaela Falconia wrote: > Hi Craig, > > > Thanks again for your details Mychaela. I will read this very carefully > > and keep it in mind as I try to port osmocom-bb to fernvale/mediatek. > > I already expect a good dose of refactoring in layer1 so maybe I will touch > > on fixing the issue. > > Have you got yourself a CMU200 instrument or not yet? A CMU200 is > absolutely required if you wish to have any chance of success at your > idea of OBB on MTK. I do have a Racal Instruments 6103E GSM Digital Radio Test Set which seems to work well so far. I have tested some SIM800 modules (mtk6261) with the internal BTS. Not sure if that will fall short or not but I'll take things one step at a time. When I need a CMU200 I'll probably get one. :) > Another question: is there any way to run any official MTK-based > firmware, however non-free and blob-laden it may be, on Fernvale hw? Probably. I know from reading that Bunnie and Xobs who designed fernvale did run standard firmware/OS on some similar 6260 based devices. Maybe we could track down a good firmware and test on fernvale. For what it's worth the fernvale isn't exactly my main target. I would much rather use a SIM800 module or eventually design of my own. > Has anyone actually done it and posted howto instructions? If not, > then how do you know if the RF hw on your Fernvale kit is actually any > good and not physically defective? Whoever physically manufactured > those Fernvale boards sold by Sysmocom, have they actually tested > their RF hw and how? And what about calibration - have they performed > individual per-unit calibration of various RF parameters on those > Fernvale kits like every standard GSM MS hardware manufacturer is > required to? I don't have any clue about these details. Will have to rely on Harald or maybe inquire of Bunnie and Xobs. > I calibrate my FCDEV3B boards at production time, use > the calibration procedure to also serve as a test of the RF tract, and > ship every unit with turnkey-working official firmware and a fully > valid and legitimate IMEI, fully fit for operation as an MS on public > GSM networks - do they do likewise or not? If not, then they are > substandard. > > M~ Thanks for your efforts, Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From mychaela.falconia at gmail.com Tue Mar 12 00:36:14 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 11 Mar 2019 16:36:14 -0800 Subject: Free board offer to OBB developer with a CMU200 Message-ID: Hello again OBB folks, In light of my discovery two days ago through CMU200 testing that current OBB on all Calypso devices (with or without my OS#3582 patch) produces grossly incorrect (spec-violating) radio transmissions, I am making the following offer to your gang in the case that any of you are interested in doing the work to fix your software and bring its radio transmissions into compliance. The offer is: if there is anyone in this so-called "community" who (a) has a CMU200 instrument or is willing to invest into buying one and getting it properly calibrated, and (b) is willing to do the major work of bringing OBB's radio transmissions into compliance as verified with that CMU200 instrument, then I am willing to send that person a fully tested, fully working and properly calibrated FCDEV3B GSM MS board free of cost. To recap, the areas in which OBB's radio transmissions were found to be non-compliant in my CMU200 tests last Saturday are as follows: 1) At least in the test scenario when the CMU200 instrument acting as a BTS makes a call to the connected MS, OBB's implementation of GSM MS transmits at each band's maximum power level instead of the lower power level commanded by the CMU acting as the BTS. 2) When the CMU200 commands the connected MS to change its Tx power level, OBB's implementation of GSM MS does not act on these commands. 3) Even when the MS Tx power level is set to each band's maximum on the CMU200 before initiating the call to the MS and not changed afterward, the power ramp put out by OBB is flagged by the CMU as being out of tolerance - despite the OS#3582 patch which makes OBB use the same Tx ramp template bits as the official FreeCalypso and Motorola firmwares (I tested on both hw platforms), or FreeCalypso fw on Motorola's hw, all of which produce perfectly compliant power ramps as deemed by the CMU200. 4) Without the OS#3582 patch, not only the power ramp but also the power level itself is out of tolerance. I do not see how anyone could address these defects without having their own CMU200 instrument so they can reproduce the problem first, and see the same thing I am seeing, which is why I am limiting my FCDEV3B offer only to those who have a CMU200 or are willing to invest in one. Furthermore, I also know from first-hand experience that many CMU200 units that sell on ebay for cheap may be defective in very subtle and non-obvious ways, or may have been subjected to repairs or repair attempts in less than fully diligent ways. Therefore, unless you bought your CMU200 from a high-end seller who sells it with a recent calibration certificate and with all case seals from the calibration lab intact, the only way to know for sure if the instrument's measurements are trustworthy is to send it to your nearest Rohde&Schwarz office for calibration, which costs about $1400 at least at the Columbia, Maryland (USA) office, which is where I had mine calibrated. For the above reasons, I further limit my free-of-cost FCDEV3B offer to those who not just own a CMU200 instrument in some unknown condition, but are also able to present a recent calibration certificate for it. (And don't even think about faking one, as I know what real ones look like - I got my own.) You will also need to have an N-to-SMA RF cable with precisely known insertion loss at GSM frequencies (at the center frequency of each uplink and downlink band, 8 frequencies in total), i.e., you need to demonstrate sufficient RF knowledge to compute a good estimate for these insertion loss numbers if you don't have access to a VNA to measure them directly. (In case it isn't already obvious, let me spell it out: producing your own GSM MS implementation that is safe to use on public airwaves does require spending a non-trivial amount of money on proper test equipment.) If you have the necessary test equipment as above and are interested in getting a free-of-cost FCDEV3B, you will need to further agree to do the following upon receiving the board: 1) Connect the FCDEV3B to your CMU200 while the board still runs its official FreeCalypso fw, and confirm with your own eyes and your own CMU200 that all RF transmissions put out by the FreeCalypso hw+fw combo satisfy all of the compliance tests. 2) Run OBB on the same FCDEV3B still connected to your CMU200, and confirm with your own eyes and your own CMU200 that OBB's transmissions exhibit the same problems which I see in my test setup. 3) Work toward bringing OBB's RF transmissions into compliance as seen by the CMU200, i.e., toward being like what the official FreeCalypso fw puts out. The tests performed by the CMU200 are the exact same ones which are performed by official certification labs on candidate GSM MS devices submitted for type approval testing; I don't know exactly what equipment those labs use, but I wouldn't be surprised if it is the very same CMU200 at least for the low-level tests, plus something else (a real BTS maybe) for higher-level GSM L3 protocol tests. Aside from the just-detailed offer of a free-of-cost board to whoever is willing to do the above work and has the necessary setup, I am now restricting sales of FCDEV3B hardware to OBB users. If anyone is interested in buying an FCDEV3B for the purpose of running OBB on it, I will only sell it to you if you can demonstrate that you have one of the following 3 acceptable setups: Option 1: a CMU200 or some other instrument acting as a base station simulator; Option 2: your own BTS plus all of the numerous pieces which are required in order to connect an MS directly to a BTS with a cabled setup without any radiated transmissions; Option 3: your own BTS plus a solid RF-blocking enclosure (reliably blocking any leakage) that is big enough to fit both your BTS and your MS. If I were to sell a board to an OBB user who does not have any of the above, then I would be helping facilitate willful interference and disruption of public radio communication networks, and could potentially be held liable for whatever damage you will cause by letting OBB transmit on GSM frequencies in open air, so nope, sorry, won't do. And finally let me pre-emptively address one very likely response: if someone says "why don't you, Mychaela, do the work of bringing OBB's radio transmissions into compliance and contribute code patches, given that you already have all of the needed high-end test equipment", my answer is that this work can only be done by someone who believes that investing effort into further development of OsmocomBB is the right thing to do, which is a position I disagree with - instead I believe that OBB (or at least OBB on Calypso, no opinion regarding OBB on SDR or the floating-around vaporware idea of OBB on MTK) should be deprecated from use and retired to the dustbin of history as a failed project that may have been interesting and may have had some merit at one time, but is now completely pointless. Sincerely, Mychaela Falconia, Mother of FreeCalypso www.freecalypso.org From craig at unreasonablefarm.org Tue Mar 12 02:12:32 2019 From: craig at unreasonablefarm.org (craig at unreasonablefarm.org) Date: Mon, 11 Mar 2019 22:12:32 -0400 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: References: Message-ID: <20190312021232.GA23688@localhost> Mychaela, I will try to reproduce your results with my Racal 6103e. It may not be capable or calibrated properly but it may show the defect all the same. Good learning opportunity for me but likely not the scientific reproduction that is really needed in this case. Cheers, Craig