Free board offer to OBB developer with a CMU200
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
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
Hi,
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. Let me augment/complement this offer (independently):
I will borrow out - free of charge - a R+S CRTU-RU to anyone(*) who is willing to use this to improve OsmocomBB, _and has shown_ the ability to do so (for example with a non-trivial commit to OsmocomBB). I'll handle+pay EU-wide shipping (for anything else you would have to handle shipping yourself). The CRTU-RU is a specialized variant of the CMU200 that uses the same RF architecture as the CMU200, has the same non-signalling baseband hardware, but uses different "Signalling Units". This means you can still use all the GSM non-signalling tests as the CMU200, for example you can modulate the GSM training sequences and various test sequences, and validate that the received spectrum is within-limits etc. You cannot use the ordinary CMU200 signalling test (where the CRTU-RU/CMU generates valid BCCH/TCH); instead the CRTU-RU offers a _large_ selection of (an implementation of the) official (3GPP) GSM protocol test cases, which are executed in a Windows 2000-based environment. The CRTU-RUs have been pulled out of Nokia's development labs back in 2014/2015 (when they were auctioned off), and I carefully scraped the software packages of the various CRTU-RUs in my possession. (I have the original hardlock dongles, and I was assured by R+S that by the possession of the Dongle the license was properly transferred.) These tests implement the 3GPP required tests, and are typically used for conformance testing. If we'd survive these tests without failures, there's a good chance we wouldn't disturb public networks, and there's the remote chance we'd survive proper conformance testing. OsmocomBB fails almost any of these tests for various - sometimes simple, sometimes more complicated - reasons. I've started with a few low hanging fruits (for example: 25.2.1.1.2.1 requires handling T200 correctly, which we don't - this causes us to send the SABM retry too late, so we fail the test), but quickly gave up because - honestly - I'm not capable enough to do this as a side project. The tests all come with source code. If someone is interested in this, please contact me off-list. Bonus points if you're interested in setting this up in an automated fashion that lets us test OsmocomBB builds automatically and generate a report for each commit. Thanks, Felix The full list of test packs I have is this: AP2PWS-3.61, AP2PWS-3.80, CRTKEGS-900-2.00, CRTKEGS-900-3.10, CRTKEGS-900-3.20, CRTKLU1-3.00, CRTKLU1-3.10, CRTKSS1-2.30, CRTKSS1-2.40, CRTKSS2-1.90, CRTKSS2-2.00, CRTKSS3-1.80, CRTKSS3-1.90, CRTKSS5-2.00, CRTKSS5-2.10, CRTKSS6-1.80, CRTKSS6-1.90, CRTKSS6-1.91, CRTPK1-3.20, CRTPK1-3.30, CRTPK1-3.40, CRTPK2-3.20, CRTPK2-3.30, CRTPK3-3.40, CRTPK3-3.41, CRTPK3-3.42, CRTPK4-3.50, CRTPK4-3.51, CRTPK4-3.60, CRTPK51-900-2.20, CRTPK51-900-2.21, CRTPK6-3.10, CRTPK6-3.20, CRTPK61-1800-2.21, CRTPK71-1900-2.21, CRTPK71-850-2.21, CRTPK8-3.30, CRTPK9-3.30, CRTPK9-3.40, CRTUGC02-2.30, CRTUGC02-2.40, CRTUGC02-2.50, CRTUGC03-2.00, CRTUGC03-2.10, CRTUGC04-1.80, CRTUGC04-1.81, CRTUGC05-1.90, CRTUGC05-2.00, CRTUGC05-2.10, CRTUGC06-1.80, CRTUGC06-1.90, CRTUGC07-1.90, CRTUGC07-2.00, CRTUGC08-1.60, CRTUGC08-1.90, CRTUGC08-1.91, CRTUGC09-4.30, CRTUGC09-4.40, CRTUGC18-4.70, CRTUGC18-4.80, CRTUGC19-2.10, CRTUGC20-1.90, CRTUGC23-1.40, CRTUGC23-1.71, CRTUGC23-1.80, CRTUGC23-1.90, CRTUGC28-1.40, CRTUGC29-1.53, CRTUGC29-1.60, CRTUGC31-4.50, CRTUGC31-4.60, CRTUGC32-4.40, CRTUGC32-4.50, CRTUGC33-4.60, CRTUGC33-4.61, CRTUGC34-4.80, CRTUGC34-4.90, CRTUGC35-4.70, CRTUGC35-4.71, CRTUGC36-4.50, CRTUGC36-4.60, CRTUGC37-4.50, CRTUGC37-4.60, CRTUGC38-4.40, CRTUGC38-4.50, CRTUGC41-4.70, CRTUGC41-4.80, CRTUGC61-4.50, CRTUGC61-4.60, CRTUGC62-4.40, CRTUGC62-4.50, CRTUGC63-4.40, CRTUGC63-4.50, CRTUGC64-4.10, CRTUGC64-4.60, CRTUGC64-4.70, CRTUGC65-4.50, CRTUGC65-4.60, CRTUGC68-4.50, CRTUGC68-4.60, CRTUGC69-4.70, CRTUGC69-4.80, CRTUGC69-4.90, CRTUGC70-4.60, CRTUGC70-4.61, CRTUGC71-4.40, CRTUGC71-4.50, CRTUGC72-4.60, CRTUGC72-4.70, CRTUGC72-4.71, CRTUGC73-4.10, CRTUGC73-4.60, CRTUGC73-4.61, CRTUGC74-4.40, CRTUGC74-4.50, CRTUGC75-4.60, CRTUGC75-4.70, CRTUGC76-4.50, CRTUGC76-4.60, CRTUGC77-4.61, CRTUGC77-4.70, CRTUGC77-4.80, CRTUGC78-4.60, CRTUGC78-4.61, CRTUGC78-4.70, CRTUGC79-4.50, CRTUGC79-4.60, CRTUGC80-4.40, CRTUGC80-4.50, CRTUGC81-4.51, CRTUGC81-4.60, CRTUGC82-4.30, CRTUGC82-4.40, CRTUGC84-4.70, CRTUGC84-4.71, CRTUGC85-4.60, CRTUGC85-4.70, CRTUGC86-4.50, CRTUGC86-4.60, CRTUGC87-4.50, CRTUGC87-4.60, CRTUGC88-4.60, CRTUGC88-4.70, CRTUGC89-4.60, CRTUGC90-4.70, CRTUGC90-4.71, CRTUGC90-4.72, CRTUGC91-4.40, CRTUGC91-4.50, CUGC01-2.02, CUGC01-2.10, CUGC01-2.11, CUGC01-2.20, nmp51.010_07wk49, nmp_rel4.07wk49 (*) No guarantees. I'll reserve the right to say "no" for random reasons.
Hi Felix, thanks a lot for your generous offer. I'm very happy to see this, but I have very limited hope that at this point somebody would still show such substantial interest in testing compliance of OsmocomBB :/ But for sure, let's hope my pessimism is overrated and someody would invest time into this. On Mon, Apr 01, 2019 at 05:29:58PM +0200, Felix Domke wrote:
If someone is interested in this, please contact me off-list. Bonus points if you're interested in setting this up in an automated fashion that lets us test OsmocomBB builds automatically and generate a report for each commit.
I'd be happy to put some sysmocom resources behind this, if it helps. I'm assuming that if somebody creates the "manual" test setup and works on fixing some of the fall-out, we'd contribute some development time on automatizing this setup, and also hosting/maintaining it, doing jenkins integration, ... In addition, irrespective of the above, sysmocom is happy to provide whatever calypso phones, cables, adapters, attenuators, duplexers, USB-UART-Cables, etc. for completing the physical setup. This offer is valid for anyone who'd receive Felix' equipment. Let me know what you'd need/want and I'll try to make sure you get it. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi all, On Sat, Apr 06, 2019 at 12:12:54PM +0200, Harald Welte wrote:
thanks a lot for your generous offer. I'm very happy to see this, but I have very limited hope that at this point somebody would still show such substantial interest in testing compliance of OsmocomBB :/
I am determined to make a compliant phone of my own design which includes osmocom-bb. I must work slowly but will continue to work. Currently I have acquired the needed cables to test osmocom-bb with my Racal 6103E which sounds like it may not be sufficient for this level of testing. I have looked at purchasing an R+S CMU200 eventually after I make more progress on porting layer1 to mediatek chips. I am also very interested in an automated setup. Towards that goal I already have some PCBs that were designed for the calypso phones. (can't remember the project URL right now) Cheers, Craig
Craig wrote:
I am determined to make a compliant phone of my own design which includes osmocom-bb. I must work slowly but will continue to work.
It sounds like your desire to produce a practically usable phone with OBB and MTK chips is as strong as my desire to produce a practically usable phone with TI chips and TI-based firmware. I have been working toward my goal since the fall of 2013 (when the liberation of the world's last surviving copy of TI's TCS211 abandonware from the "we won't share" gang made it possible); what I have to show so far is that I got a commercial-quality modem (with full source code freely published) that would most certainly pass the full type approval test if someone paid for it, but no phone UI yet. In order to turn this FreeCalypso modem of mine into a practically usable phone which I could carry in my purse (pocket replacement for us ladies) instead of the proprietary Pirelli DP-L10, I just need to do one more board design, adding LCD, keypad, battery charging and other handset peripherals to my proven-good modem board design. But because of cost issues (this handset board design will cost me a lot of money), I need to postpone it until after my big surgery, not before, hence it will be another few years. In the meantime, the modem (phone sans UI, control via AT commands) is already 100% working and is available today. Now please present your story (meaning Craig) - how long have you been actively working toward your respective goal? What do you have to show so far?
progress on porting layer1 to mediatek chips.
Would you mind clarifying exactly what your OBB-on-MTK layer1 can do today? Can it do a power scan across the band to find the ARFCNs of likely GSM cells? Can it sync to the frequency burst of a cell? Can it receive the synchronization burst and sync to the multiframe structure? Can it receive a cell's broadcast info on BCCH and CCCH? These are the things which OBB on Calypso could do back in 2010. Or zooming out more generally, do you have *any* control of the radio hardware (say, frequency synthesizer or other components of the Rx chain) in your OBB-MTK-L1? Do you have *any* understanding of MTK's DSP and how to talk to it? I hope you realize that every commercial GSM baseband processor, be it from TI or MTK or any other vendor, includes a DSP for signal processing functions, and that one *cannot* meaningfully receive or transmit any GSM signals without having a thorough understanding of that DSP and working with it... The people who created OBB on Calypso back in 2010 used two key sources of knowledge in order to learn how to work with Calypso's DSP: one source of knowledge was the well-publicized TSM30 source, but the other, much less well-known one was the TCS211 semi-src. Both TSM30 and TCS211 versions were absolutely critical to their success; the TSM30 version by itself would NOT have been sufficient for figuring out how to drive the Calypso+Iota+Rita chipset in Mot C1xx phones, which is quite different from the much older TI baseband + non-TI RF in the TSM30 phone. Instead the TCS211 semi-src was *the most critical* piece for working with the Calypso+Iota+Rita chipset, but being a semi-src rather than full source, it had to be supplemented by some other TI source: either TSM30 (what OBB founders used) or LoCosto (what I used instead), still in conjunction with TCS211. Do you have an equivalent source of knowledge for MTK's DSP? Just trying to see if you have anything real and tangible to show for your idea of OBB on MTK, that's all... M~
Mychaela wrote:
Now please present your story (meaning Craig) - how long have you been actively working toward your respective goal? What do you have to show so far?
I have been working with osmocom-bb since around 2010, dabbling in porting layer1 to nutt-xand starting 2-3 years ago working more earnestly on understanding layer1 and porting it to fernvale. I have also worked on getting fernly (a small system for experimenting with similar commands like osmoload has) working on other mediatek chips like mtk6261, 6735 and 6737. I have osmocom-bb firmware loading via fernly which has a working serial driver (fromfernly project) so I can get debugging out of devices like fernvale. I have more recently started to port the txburst command from uboot for the sciphone dream g2 (mtk6235) back to osmocom-bb. I have been studying the sources I have for mediatek devices and see many similarities and patterns that should work for fernvale(6260), sciphone (6235) and newer chips such as 6735 and 6739. So at this point I have some work that others did to transmit a burst on a specific ARFCN. This works on uboot for sciphone dream g2 and for some reason doesn't work when I port it back to osmocom-bb to start as a basis for layer1.
Do you have an equivalent source of knowledge for MTK's DSP?
As far as I know there is no direct knowledge/sources for MTK's DSP but I haven't quite gotten to the point where I needed to know just yet. This is a very part-time endeavor for me so I do what I can. There are some other people working on various aspects of mediatek devices including trying to get into the DSP. We generally chat/share things on matrix at #postmarketos-lowlevel:disroot.org Cheers, Craig
Craig wrote:
I have been working with osmocom-bb since around 2010,
So you have been at it for at least 3 y longer than I have, and you still haven't offered much to show for it..
dabbling in porting layer1 to nutt-x
What is the deal with that NuttX thing? What makes all of you think that it is such a good idea? Just because someone said so? None of the mainstream, commercially successful GSM modem firmwares from any reputable vendor use NuttX, they all use Nucleus, ThreadX or L4 instead. (Both MTK and the stuff I inherited from TI use Nucleus, and I seem to recall hearing of some other vendors using ThreadX and L4.) So I would be extremely wary of that NuttX stuff.
and starting 2-3 years ago working more earnestly on understanding layer1 and porting it to fernvale.
2-3 y ago is the same time when I went from running FreeCalypso purely as a software project to producing my current FCDEV3B hardware. So far my approach has worked out a lot better: FCDEV3B is now a practically usable commercial-quality GSM+GPRS modem that is fully fit for operation on live GSM networks, which cannot be said for Fernvale.
I have also worked on getting fernly (a small system for experimenting with similar commands like osmoload has) working on other mediatek chips like mtk6261, 6735 and 6737.
In other words, operating those MTK chips as general-purpose microprocessors without any cellular radio functionality, right? What you are doing here would indeed be a necessary foundational step *if* you had some *realistic* plan for how you are going to bring up cellular radio functionality, but it does not sound like you have any such realistic plan.
So at this point I have some work that others did to transmit a burst on a specific ARFCN.
What you are describing sounds like a low-level RF test mode, transmitting a burst by itself, without any synchronization with a BTS, a test mode provided in most GSM modem implementations (FreeCalypso has it too) for exercising the RF Tx hardware by itself, without a GSM network connection - this test mode is typically used in factory production line processes when doing Tx calibration.
As far as I know there is no direct knowledge/sources for MTK's DSP but I haven't quite gotten to the point where I needed to know just yet.
This is the part that shows most clearly how out of touch you are with reality when it comes to your idea of OBB on MTK. The DSP is the most essential part, and if you don't have that, then everything else is useless, plain and simple - so if you are investing work in other parts of the system without having the DSP firmly under control first, then you are simply spinning your wheels and doing completely wasted work.
This is a very part-time endeavor for me so I do what I can.
I am part-time too, I am NOT independently wealthy to where I could work on FreeCalypso full-time. Yet having a limited time budget is not an excuse for making poor judgments as to what is realistically doable and what isn't, deluding yourself and misleading others into a land of false hopes. If you really wish to have a shot at working GSM functionality on an MTK platform, the only way you might be able to achieve something functional would be if you start with MTK's official firmware: ftp://ftp.freecalypso.org/pub/GSM/MTK/ Please note that I am acting only as an archivist and nothing more by hosting that ware on my FTP site. The contributor who sent it to me back in 2015 said that it was supposedly MTK's reference fw for the MT6260 chip, but that is all I know - I don't even know if the contributor's impression was correct or not - but it is the *only* available starting point for those chips, to the best of my knowledge. You would have to spend oodles of time understanding the architecture of that firmware, how to compile it in different configurations (for example, how to select whether you need an AT-command-controlled modem or a self-contained phone handset), how to customize it for different board-level hardware (board-specific GPIO and multifunction pin assignments, and if you are doing a handset fw build, how do you select the screen size and keypad layout and all those details), and then you would need to try getting it to run on your hardware of interest, i.e., SIM800 modules or Fernvale or whatever. You won't have any realistic chance of bringing up any GSM functionality on any MTK platform until you get MTK's official fw running on that platform in a configuration which you compile yourself from semi-src and thoroughly study that MTK official fw and its architecture, just like how the people who did OBB on Calypso in 2010 made critical use of Openmoko's semi-src as a working reference for the Calypso+Iota+Rita chipset. Meanwhile, for anyone who needs a working GSM+GPRS modem with full source code *right now*, my FreeCalypso offering is the only working solution that is available *today*. In another few years I will hopefully also have a self-contained "dumbphone" handset product to complement the already-available modem offering, whereas with the approach taken by Craig, it is highly unlikely that his approach will result in any kind of usable product (be it a phone or a modem) any sooner than 2035 at the earliest, and would probably be more like year 2050. M~
Hi Mychaela, On Sat, Apr 06, 2019 at 09:39:25PM -0800, Mychaela Falconia wrote:
Craig wrote:
I have been working with osmocom-bb since around 2010,
So you have been at it for at least 3 y longer than I have, and you still haven't offered much to show for it..
Once again, there is no competition here. Not everybody has the same time and resources, level of technicality, etc.. Not everyone has the same goal. Maybe some people just want to have a fun hobby learning a bit more about GSM, reverse engineering, etc. ?
dabbling in porting layer1 to nutt-x
What is the deal with that NuttX thing? What makes all of you think that it is such a good idea? Just because someone said so?
That Someone would likely have been me.
None of the mainstream, commercially successful GSM modem firmwares from any reputable vendor use NuttX, they all use Nucleus, ThreadX or L4 instead.
So what? None of the mainstream operators are using network-side Osmocom components, but still they generally work, and some smaller operators have been running them very successfully so ;) None of the mainstream IT companies were using Linux in the mid-1990ies, still it was quite capable back then.
and starting 2-3 years ago working more earnestly on understanding layer1 and porting it to fernvale.
2-3 y ago is the same time when I went from running FreeCalypso purely as a software project to producing my current FCDEV3B hardware. So far my approach has worked out a lot better: FCDEV3B is now a practically usable commercial-quality GSM+GPRS modem that is fully fit for operation on live GSM networks, which cannot be said for Fernvale.
Did it occur to you that Fernvale had completely different goals? Also, how long do you think that your "commercial quality" modem will continue to be available, given the ancient, end-of-life components it requires? MTK still produces newer baseband chips with GSM/GPRS support, and from all we know they didn't significantly change that 2G part in ages. Why would they? It just lives next to their 3G/4G modem parts, probably copy+pasted from the older designs.
In other words, operating those MTK chips as general-purpose microprocessors without any cellular radio functionality, right? What you are doing here would indeed be a necessary foundational step *if* you had some *realistic* plan for how you are going to bring up cellular radio functionality, but it does not sound like you have any such realistic plan.
Please stop that negative attitude. Nobody needs any realistic plan if they want to play/hack around.
This is the part that shows most clearly how out of touch you are with reality when it comes to your idea of OBB on MTK.
Maybe it's you who is out of touch with Craigs reality? I think Craig is quite realistic when it comes to his ability to create a "production ready GSM/GPRS modem". But did he state anywhere that this is what he's aiming for?
I am part-time too, I am NOT independently wealthy to where I could work on FreeCalypso full-time. Yet having a limited time budget is not an excuse for making poor judgments as to what is realistically doable and what isn't, deluding yourself and misleading others into a land of false hopes.
Please respectfully leave it up to others to make whatever judgements they want on how they spend their spare time. We're not telling you how to spend yours either. Having said this, please feel free to share your points of view in a neutral way - but don't be judgemental and/or attack other people just because they are doing something that's not according to your taste, or which you think is inferior. To put it in the words of Rosa Luxemburg[1]: "Freedom is always the freedom of dissenters." Regards, Harald [1] https://en.wikiquote.org/wiki/Rosa_Luxemburg -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Sat, Apr 06, 2019 at 09:39:25PM -0800, Mychaela Falconia wrote:
So at this point I have some work that others did to transmit a burst on a specific ARFCN.
What you are describing sounds like a low-level RF test mode, transmitting a burst by itself, without any synchronization with a BTS, a test mode provided in most GSM modem implementations (FreeCalypso has it too) for exercising the RF Tx hardware by itself, without a GSM network connection - this test mode is typically used in factory production line processes when doing Tx calibration.
It is code which someone else wrote based on I think the available data sheet and possibly the sources that you reference (and other versions of similar). I have been digging through several of these sources for about a year or so and have been working through the existing txburst code. It involves manipulating the baseband interfaces that the MCU (mtk6235) provides. There is an immediate mode which is used in this case where in a typical case a buffered/programmed mode would be used. I don't think it's that far from dealing with the DSP and likely is the level needed in order to do a significant part of the work needed for layer1.
This is a very part-time endeavor for me so I do what I can.
I am part-time too, I am NOT independently wealthy to where I could work on FreeCalypso full-time. Yet having a limited time budget is not an excuse for making poor judgments as to what is realistically doable and what isn't, deluding yourself and misleading others into a land of false hopes.
I have enjoyed all of the time I have spent on this project and am excited to learn as I go. It doesn't feel like wasted time at all. :) I hope I am clear to those on this list and elsewhere: I'm just working on this. I have no idea if or when I will ever complete my goal. You can call it slow-ware or something if you like but it isn't exactly vaporware because I am making real things work.
If you really wish to have a shot at working GSM functionality on an MTK platform, the only way you might be able to achieve something functional would be if you start with MTK's official firmware:
ftp://ftp.freecalypso.org/pub/GSM/MTK/
Yes. I downloaded that source now just in case it has some missing pieces. I already have say 2-5 other source trees available for mostly 62xx chips but also 67xx and 68xx chips. Much of the 2G layer1 code is very similar in all these source trees.
You won't have any realistic chance of bringing up any GSM functionality on any MTK platform until you get MTK's official fw running on that platform in a configuration which you compile yourself from semi-src and thoroughly study that MTK official fw and its architecture, just like how the people who did OBB on Calypso in 2010 made critical use of Openmoko's semi-src as a working reference for the Calypso+Iota+Rita chipset.
I may end up doing that if it seems like the right choice. For now I have been happy and have made progress without using any semi-src. I have focused on gathering "facts" from the source code, data sheets and existing open source software.
Meanwhile, for anyone who needs a working GSM+GPRS modem with full source code *right now*, my FreeCalypso offering is the only working solution that is available *today*. In another few years I will hopefully also have a self-contained "dumbphone" handset product to complement the already-available modem offering, whereas with the approach taken by Craig, it is highly unlikely that his approach will result in any kind of usable product (be it a phone or a modem) any sooner than 2035 at the earliest, and would probably be more like year 2050.
Agreed. I can't predict when any stage of my desired end-goal of a usable device will occur. I am quite certain I have never mentioned any timeframes other than what I would ~like~ to achieve.
M~
As always I am very grateful for your attention, knowledge and detailed responses. They help me immensely in my endeavors. Be well, Craig
Dear Mychaela, I'm a bit upset by the tone of your message. This mailing list is for discussing open source mobile communications (specifically, in this case, on the phone/UE side). Anyone is welcome to share their views, but there is no competition here. I'm very impressed by your achievements with FreeCalypso, and I'm happy you are participating our discussions here and staying in touch with Osmocom, as well as helping it along [despite of what I feel is a somewhat difficult relationship for you]. However, having achieved a lot in this field yourself doesn't give you the right to intimidate or bully other members on this mailing list. So I would kindly request you to show respect to every hacker who is working in this field, no matter where they are with their project, and no matter what their "track record of achievements" may look like so far. Particularly we, the people with lots of experience and achievement in this field, need to nurture and encourage others, rather than intimidate them. I see the following part of your message as problematic: On Sat, Apr 06, 2019 at 01:14:55PM -0800, Mychaela Falconia wrote:
Now please present your story (meaning Craig) - how long have you been actively working toward your respective goal? What do you have to show so far? [...] Just trying to see if you have anything real and tangible to show for your idea of OBB on MTK, that's all...
Nobody is accountable to you and has to provide you with a record of how long they have worked on something or what they have achieved. Everyone is welcome and encouraged to share what they're doing, but that's completely voluntary and up to them to disclose. No volunteer working on a FOSS project in their spare time is required to achieve anything [beyond what they have as goals themselves]. Craig has been determined for many years and has been working on this on and off, as I understand. The mere fact that given such a huge and difficult task he hasn't given up yet is a very positive surprise :) So please let's try to be more positive and encouraging, and help others trying to venture into the area of reverse engineering cellular baseband processors. We need more of them, not less :) Thanks for your kind understanding. I hope we can avoid any further discussion on this topic and return to investing all our time into improving open/free cellular technology. Best Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 7. Apr 2019, at 19:25, Harald Welte <laforge@gnumonks.org> wrote:
LaF0rge! thank you for standing up and writing your mail. holger
Dear Mychaela,
I'm a bit upset by the tone of your message. This mailing list is for discussing open source mobile communications (specifically, in this case, on the phone/UE side). Anyone is welcome to share their views, but there is no competition here.
I'm very impressed by your achievements with FreeCalypso, and I'm happy you are participating our discussions here and staying in touch with Osmocom, as well as helping it along [despite of what I feel is a somewhat difficult relationship for you]. However, having achieved a lot in this field yourself doesn't give you the right to intimidate or bully other members on this mailing list.
So I would kindly request you to show respect to every hacker who is working in this field, no matter where they are with their project, and no matter what their "track record of achievements" may look like so far.
Particularly we, the people with lots of experience and achievement in this field, need to nurture and encourage others, rather than intimidate them.
I see the following part of your message as problematic:
On Sat, Apr 06, 2019 at 01:14:55PM -0800, Mychaela Falconia wrote:
Now please present your story (meaning Craig) - how long have you been actively working toward your respective goal? What do you have to show so far? [...] Just trying to see if you have anything real and tangible to show for your idea of OBB on MTK, that's all...
Nobody is accountable to you and has to provide you with a record of how long they have worked on something or what they have achieved.
Everyone is welcome and encouraged to share what they're doing, but that's completely voluntary and up to them to disclose.
No volunteer working on a FOSS project in their spare time is required to achieve anything [beyond what they have as goals themselves].
Craig has been determined for many years and has been working on this on and off, as I understand. The mere fact that given such a huge and difficult task he hasn't given up yet is a very positive surprise :)
So please let's try to be more positive and encouraging, and help others trying to venture into the area of reverse engineering cellular baseband processors. We need more of them, not less :)
Thanks for your kind understanding. I hope we can avoid any further discussion on this topic and return to investing all our time into improving open/free cellular technology.
Best Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (6)
-
Craig Comstock -
craig＠unreasonablefarm.org
-
Felix Domke -
Harald Welte -
Holger Freyther -
Mychaela Falconia