Hello Mychaela,
First of all, my congratulations! I have been watching the project you lead for some long time, and it's great to see your achievements.
As I understand it, there are two reasons for why the original incarnation of OsmocomBB (prior to the recent addition of SDR PHY support) used Calypso phones as its physical transceiver instead of USRP-style SDR devices: (1) the work done by the Calypso DSP is already done, hence there was less work for OsmocomBB developers to do, and (2) Calypso phones used to be dirt-cheap, whereas SDR devices cost some non-trivial money.
Yeah, moreover I think when OsmocomBB was initiated, the prices of available SDR hardware were higher, than today...
Thus with the cost of an SDR device and that of a newly made Calypso device being comparable (or as things stand presently, the Calypso option is more expensive), is there any remaining reason to use Calypso devices as opposed to SDR PHY for OsmocomBB? In other words, is there any solid technical reason (not involving cost) to prefer a Calypso device over SDR PHY for OsmocomBB purposes, or is there not?
Personally, for research and development purposes I would preffer SDR. The main reason is that my research scope isn't limited by GSM only, there are other pretty interesting technologies like Iridium, TETRA, GMR, and of course UMTS followed by LTE.
Which translates into: is there any reason to support running OsmocomBB on FreeCalypso hardware and to market such hw to the OsmocomBB community, or would it be better to tell people that if they want OsmocomBB, they should use an SDR PHY, and leave FC hardware for people like me who are interested in end use applications (as opposed to hacking) using TI-based FC firmware?
SDR PHY isn't finished yet. We only managed to get actual burst transmission working only a couple of weeks ago. At the moment, both AGC and Timing Advance loops are missing, and TX power is not high enough to 'deal' with real base stations...
So, I think, Motorola C1XX phones remain the primary hardware back-end for now, thus would be better to tell people about them.
One argument I have heard against the use of SDR for GSM MS role is that SDR devices supposedly have a difficult time retuning every 4.615 ms, and thus would have a difficult time connecting in the MS role to a GSM network that employs frequency hopping. Is there any truth to that argument, or has that problem already been solved? Are there any other areas in which a chipset like the Calypso that is specifically designed for the GSM MS role would perform better than an SDR device of the kind that are viable cost competitors against newly made Calypso hardware?
Yeah, both frequency popping and neighbour power measurement are the hard topics for SDR PHY. There are some ideas how to implement that, but right now we are keeping this problem aside until all the rest is done ;)
With best regards, Vadim Yanitskiy.
Vadim Yanitskiy axilirator@gmail.com wrote:
So, I think, Motorola C1XX phones remain the primary hardware back-end for now, thus would be better to tell people about them.
Except that Mot C1xx phones with 900+1800 MHz bands are no longer available except occasional single units here and there, so I assume that you meant to say that Calypso devices (Calypso in general rather than Mot C1xx specifically) remain the primary hw back-end, and that it is a good idea to tell people about the availability of new Calypso devices that aren't Mot C1xx phones.
As a side-by-side comparison between Mot C1xx phones vs. the newly made FreeCalypso FCDEV3B hardware for the purposes of running OsmocomBB, the differences are:
* You need to run a different version of OsmocomBB's layer1: instead of running the version built in board/compal_*/layer1.*, you need to run the board/gta0x/layer1.highram.bin version.
* Running the gta0x version of layer1 on the FCDEV3B is technically cheating, as the FCDEV3B is not Openmoko GTA0x - it is very very close, but not identical.
* If you are going to exercise voice call functionality and would like to hear the call downlink audio come out of the loudspeaker connected to the FCDEV3B (you'll need to procure the actual loudspeaker part yourself) in the same way how it comes out of the earpiece speaker on Mot C1xx phones, you will need to make a tiny change to the code in board/gta0x/init.c to configure Calypso GPIO 1 as an output and to drive this output high.
If the OsmocomBB community wishes to support the FCDEV3B as a hardware target, someone in the OsmocomBB camp (i.e., not me) will need to decide whether to use the same gta0x target for both actual Openmoko GTA0x devices and for the FCDEV3B, or to bifurcate the two. The concerns with using the same gta0x target for both GTA0x and FCDEV3B devices are:
* Calypso GPIO 1 should be configured as an output on both targets (the current OsmocomBB code incorrectly leaves it as an input), but it performs different functions on the two hw platforms. On my FCDEV3B it controls the loudspeaker amplifier like on TI's own D-Sample and Leonardo development boards and needs to be driven high to enable it, but on Openmoko devices it is an interrupt to the application processor of the phone. I don't know if anyone cares about running OsmocomBB on OM devices, and what will happen if the code is changed to assert GPIO 1 high.
* If you guys ever get around to making use of the factory-written per-unit RF calibration values on the devices you run on, you will need to know whether you are running on GTA0x or FCDEV3B hardware: while the FFS (flash file system) format is exactly the same, the physical flash location of this FFS is different.
This factory RF calibration is another big issue in itself. In producing my own FreeCalypso hardware I have expended a very significant effort to produce per-unit RF calibration that is no worse than that which was done by the historical Calypso device manufs like Openmoko, Pirelli and Motorola. Every FCDEV3B board which I offer for sale has passed a calibration procedure in which the DUT was connected to a Rohde&Schwarz CMU200 Universal Radio Communication Tester (the exact same professional RF test equipment that was used by all of the big guys in the days of yore), and the following RF parameters are precisely calibrated for each individual unit:
* The VCXO frequency as a function of the AFC DAC control value, for use by the advanced AFC algorithm implemented by TI for use in production firmwares;
* The correct APC DAC values to produce each of the Tx power levels specified in the GSM 05.05 spec for all 3 supported bands, putting each Tx power level exactly where it needs to be per spec, within the tolerances given in the spec;
* The "magic gain" constant needed in order to determine the actual input level in dBm from the DSP's power measurement, for each of the 3 supported bands;
* The per-channel variation in this "magic gain" constant caused by the irregularities in the passband of the SAW filters, needed for proper RSSI reporting.
Thanks to this proper RF calibration, I have a very high confidence that the radio operation of my FreeCalypso devices when running the official FreeCalypso Magnetite firmware is 100% correct per all of the relevant official specs, and that my hw+fw combo would pass FCC/etc certification and type approval testing if someone were to cough up the $$$ for it.
All other Calypso devices that are currently supported by OsmocomBB (Mot C1xx, Pirelli DP-L10, Openmoko GTA0x) also had the same kind of per-unit RF calibration performed at their respective factories, with the results saved either in the FFS in TI's format (in the case of OM GTA0x) or in some proprietary flash data structure (in the case of Mot C1xx and Pirelli DP-L10), but OsmocomBB fails to make use of these data on any target, even on those on which the location and format of these factory RF calibration values are well-known.
I naturally have my reservations about expending the effort to calibrate each hardware unit I produce with utmost diligence, only to sell them to people who are going to run firmware that completely ignores these factory RF calibration values and runs with some hard-coded off-the-wall numbers instead.
M~
Except that Mot C1xx phones with 900+1800 MHz bands are no longer available except occasional single units here and there, so I assume that you meant to say that Calypso devices (Calypso in general rather than Mot C1xx specifically) remain the primary hw back-end, and that it is a good idea to tell people about the availability of new Calypso devices that aren't Mot C1xx phones.
Sure, I meant Calypso devices in general. The main idea is that SDR PHY is far from the state at which it could be used by OsmocomBB users nowdays. It's in R&D and testing state.
With best regards, Vadim Yanitskiy.
fwiw, my interest leans towards cheap and accessible.
So my unreasonable goals are: 1 - port osmocom-bb to fernvale 2 - use that port and adjust for $5 sim800 modules 3 - make nuttx-bb for those cheap 6261 based watches 4 - make a custom board/device
cheers, Craig
Hi Mychaela,
On Wed, Nov 15, 2017 at 10:58:08PM -0800, Mychaela Falconia wrote:
I naturally have my reservations about expending the effort to calibrate each hardware unit I produce with utmost diligence, only to sell them to people who are going to run firmware that completely ignores these factory RF calibration values and runs with some hard-coded off-the-wall numbers instead.
The source code is out there. Apparently none of the (at some point many) OsmocomBB users has ever seen significant enough need to research and understand the format of those calibration tables and make use of them from OsmocomBB.
It's sad, but that's the state of affairs, even 7 years into the project.
Hi Harald,
(5) somewhat ties into (4): One goal was always to run also 'mobile' inside a phone and have a FOSS-based telephone. Nobody has had the time + endurance to get there, and I doubt it will still happen at this point.
Regarding the last part (doubting that a FOSS-based mobile phone will still happen at this point), it most certainly will happen, but unless you beat me to it, it will happen with FreeCalypso firmware rather than OsmocomBB.
But right now you do have a great opportunity to beat me to that goal. In FreeCalypso land the biggest current blocker on the road toward a usable untethered phone is my unwillingness to start hacking TI's demo/prototype UI code to fit into the 96x64 pixel LCD space on Mot C1xx phones and do all of the upfront debugging in this reduced-screen environment, without first bringing this UI up in its original 176x220 pixel form - TI targeted the 176x220 pix LCD on their D-Sample board. The liberated copy of TI's TCS211 fw we are working with (the world's sole surviving copy of any TCS211 fw to the best of my knowledge) has TPU driver code only for Rita RF and not Clara, hence no ability to use the original D-Sample board which I do have. Thus the only way I can get the 176x220 pixel LCD on a FreeCalypso device for my UI development path is to design and build a new board, a successor to the FCDEV3B, adding that LCD and the standard buttons and other usual handset peripherals. It'll probably take me another year or two.
But you are not using TI's original code, hence you have no need for a platform with a 176x220 pixel LCD; if you are developing the UI from scratch yourself, you can go directly to whatever LCD size is your desired target, such as 96x64 for the Mot C1xx family. So if you really want to show the world how much better OsmocomBB is than FreeCalypso and how your reimplement-from-scratch approach is superior to my liberated proprietary source direct reuse approach, then your chance is NOW, before I build that next FreeCalypso board with my desired 176x220 pixel LCD to do it my way.
The qty-1 retail price for one of my FCDEV3B boards is $500 USD; if someone were to order a large batch (say, 100 boards), I am reasonably confident that the per-unit price can be brought down to $300 USD or maybe even lower,
Having done a fair amount of electronics manufacturing in this kind of quantity, I would seriously be surprised if you'd still be at that kind of pricing in a MOQ-100 situation.
Tt was much more of a guess on my part than an estimate. I haven't started seriously looking into what a reasonable "large" batch size would be and how much it would cost, as I need to resolve some outstanding issues first, most notably the sleep mode bug. The current FreeCalypso workaround is to disable all sleep modes in the fw, and of course firmwares like OsmocomBB that have no sleep mode capability in the first place are completely unaffected, but I need to get to the bottom of that mystery before I seriously think about producing any kind of large batch.
The source code is out there. Apparently none of the (at some point many) OsmocomBB users has ever seen significant enough need to research and understand the format of those calibration tables
Just so we are clear, the format of the RF calibration tables used by mainline TI->Openmoko->FreeCalypso firmwares is not any kind of secret, and there is nothing that needs to be "researched" there. The people who work professionally on the official firmware for the Calypso chipset (employed formerly by TI and presently by Falconia Partners LLC) naturally understand the meaning of every number in every RF calibration data structure. Of course if OsmocomBB people don't understand the meaning of these numbers, that's a different story...
For anyone who does wish to study the official L1 code created by the same people who created the chips it is meant to run on, the source for the official FreeCalypso fw (formerly TI's official fw) is public, including 100% C source for all of L1 (it used to be binary objects in that sole surviving copy of TCS211, but it has been reconstructed back to full C source form in FC), so you can see all of the structure definitions and all of the code that uses these RF parameters in genuine C form, no reverse eng of any kind needed. I have even published the source for the in-house production calibration software (my own original work) that is used at Falconia Partners LLC to generate these RF calibration numbers with the help of a CMU200 RF test station, so you can see not only the code that makes use of various RF calibration parameters, but also the process by which they come into being.
It is true that Mot C1xx phones use a different format of Mot/Compal's own invention, not TI's, but just earlier today I finished implementing the utility that extracts the useful numbers from Mot/Compal's proprietary flash data structures and converts them to the mainline TI/FreeCalypso format. You can find it in my freecalypso-tools Hg repository:
https://bitbucket.org/falconian/freecalypso-tools
and make use of them from OsmocomBB.
This part could indeed be very difficult, as your code architecture (which I haven't studied too closely) is probably very different from the official one.
However, I am now considering an alternative approach. The people who have expressed an interest in my FCDEV3B hardware but who say that they need to use OsmocomBB rather than FC firmware are typically researchers who are looking for the researcher-oriented functionality of OsmocomBB's L23 software, but I haven't seen any indication that they are particularly attached to OsmocomBB's specific implementation of layer1. Therefore, I am considering implementing an adapter or gateway process that would allow OsmocomBB's L23 to connect to FreeCalypso L1 instead of OsmocomBB's own. I haven't done any serious feasibility study yet, but I now feel that it would be worth looking into.
M~
Hi Mychaela,
On Sat, Nov 18, 2017 at 07:03:51PM -0800, Mychaela Falconia wrote:
(5) somewhat ties into (4): One goal was always to run also 'mobile' inside a phone and have a FOSS-based telephone. Nobody has had the time + endurance to get there, and I doubt it will still happen at this point.
Regarding the last part (doubting that a FOSS-based mobile phone will still happen at this point), it most certainly will happen, but unless you beat me to it, it will happen with FreeCalypso firmware rather than OsmocomBB.
FreeCalypso is *not* FOSS, and hence does not qualify regarding my statement above. It's not compliant to the FSF's Free Software Definition, nor the Debian Free Software Guidelines, nor under and OSI approved license for Open Source. Hence, neither Free Software nor Open Source.
You may not care about that, and it is your free choice to do so, which I do respect. However, the vast majority of people has a pre-existing notion about what FOSS is. And calling FreeCalypso FOSS is what I strongly object to.
But right now you do have a great opportunity to beat me to that goal.
People with an interest in OsmocomBB have that opportunity. I personally have no time for that, and I have different priorities (otherwise I would have worked on this already some 5-7 years ago, when creating OsmocomBB in the first place).
The source code is out there. Apparently none of the (at some point many) OsmocomBB users has ever seen significant enough need to research and understand the format of those calibration tables
Just so we are clear, the format of the RF calibration tables used by mainline TI->Openmoko->FreeCalypso firmwares is not any kind of secret, and there is nothing that needs to be "researched" there.
Anything that is not clear / obvious to the people involve needs to be "researched".
The people who work professionally on the official firmware for the Calypso chipset (employed formerly by TI and presently by Falconia Partners LLC) naturally understand the meaning of every number in every RF calibration data structure.
And those people - like anyone else on the planet - are happily invited to contribute related patches to OsmocomBB, if they care about it.
It appears that you care about OsmocomBB not using the calibration tables, and based on the 7 years of OsmocomBB history, nobody among the OsmocomBB users seems to care sufficiently to work on it. That's sad, but it is a fact. People do have tons of other projects and responsibilities, and steps towards regulatory compliance for a highly experimental project like OsmocomBB apparently was not on the top priority list.
Of course if OsmocomBB people don't understand the meaning of these numbers, that's a different story...
Hence, either the people who understand it contribute a patch, or the "OsmocomBB people" need to research the topic, or it will not happen.
For anyone who does wish to study the official L1 code created by the same people who created the chips it is meant to run on, the source for the official FreeCalypso fw (formerly TI's official fw) is public,
I am sure by now everyone on this list is aware of that.
It is true that Mot C1xx phones use a different format of Mot/Compal's own invention, not TI's, but just earlier today I finished implementing the utility that extracts the useful numbers from Mot/Compal's proprietary flash data structures and converts them to the mainline TI/FreeCalypso format. You can find it in my freecalypso-tools Hg repository:
Thanks a lot, I'm sure this is an excellent pointer in case somebody wants to go ahead and implement reading of the calibration tables.
Therefore, I am considering implementing an adapter or gateway process that would allow OsmocomBB's L23 to connect to FreeCalypso L1 instead of OsmocomBB's own. I haven't done any serious feasibility study yet, but I now feel that it would be worth looking into.
Sure, the MS-side L1CTL interface can most likely be implemented for various different L1 implementations. It's what has been done by various groups publicly and privately before. Last but not least, the new virtphy takes the same approach: Simulate L1 in a way that's completely transparent towards L23.
L1CTL is very simple and was crated very ad-hoc at the time, so be warned if you think it's not very elegant: It isn't :/
For sure it's much more work than reading + processing the calibration values, AFAICT.
Kind Regards, Harald
Hi all,
Just got a new laptop and was trying to build and run fernly (for fernvale/mtk6260) and found that arm-none-eabi toolchain from debian (9ish I think... PureOS is what I am using) doesn't run succesfully. This is a known issue. What really caused me trouble was when I went to use the gnu arm toolchain instructions on the osmocom wiki I ran into problems. My PureOS machine has gcc 7.2.0-14. I wonder if we should add some instructions to the wiki about patches needed and maybe update the shell script to automate these changes if we can isolate them to a particular version of gcc?
https://osmocom.org/projects/baseband/wiki/GnuArmToolchain
PROBLEM with cfns.gperf fixes FIX: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ec1cc0263f156f70693a62cf17...
PROBLEM: a few tex problems in gcc docs, @tex should appear at a line beginning FIX: https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html
PROBLEM: newlib.../libc/sys/arm/trap.S:88: Error: lo register required -- `sub ip,sp,ip' FIX: https://sourceware.org/ml/newlib/2011/msg00140.html FIX: add --disable-newlib-supplied-syscalls
Craig
baseband-devel@lists.osmocom.org
-
Craig Comstock -
craig＠unreasonablefarm.org
-
Harald Welte -
Mychaela Falconia -
Vadim Yanitskiy