From mychaela.falconia at gmail.com Sat Nov 11 01:17:21 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 10 Nov 2017 17:17:21 -0800 Subject: Calypso vs. SDR PHY Message-ID: Hello OsmocomBB community, I am the manufacturer of a GSM mobile station development board based on the Calypso+Iota+Rita chipset from TI. The hardware product in question has been created for the primary purpose of running the end-use-oriented GSM+CSD+GPRS modem firmware that was previously maintained by TI and whose maintenance has since been taken over and continued by FreeCalypso, but being based on the Calypso chipset, my board is also capable of running OsmocomBB. The purpose of the present inquiry is to find out whether this hardware product might be of interest to the OsmocomBB community, or if those who wish to run OsmocomBB (as opposed to TI-based FreeCalypso firmware) would be better advised to use an SDR device instead. 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. But the dirt-cheap Calypso phone situation is now firmly in the past, and newly made Calypso devices like my FCDEV3B are nowhere close to cheap. 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, but getting any kind of firm numbers beyond a guesstimate would require actual work, and that work will only be done if I receive some expression of serious and genuine interest. But even if we manage to bring the price down to, say, $200 per board with a really large order quantity, it *still* won't be anywhere near as cheap as old Calypso phones used to be, and the price is still essentially in the same ballpark as a midrange SDR device. 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? 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? 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? Just seeking some clarification... M~ P.S. Before anyone says that Calypso chips themselves are no longer made and thus don't constitute a viable option, please note that I can still buy them on the Chinese grey market at least in tens of thousands of pieces, maybe more, and there is no conceivable way that all current phone hacking and phone liberation communities combined can produce enough demand to exhaust that supply. And if someone does order 100 thousand Calypso boards at $300 or so apiece, that would be more than enough money to hire a pirate chip fab to clone every chip in the Calypso chipset. From holger at freyther.de Mon Nov 13 10:43:30 2017 From: holger at freyther.de (Holger Freyther) Date: Mon, 13 Nov 2017 18:43:30 +0800 Subject: Reliability of no shutdown/shutdown loop Message-ID: <8FA2132C-399B-4629-8B3D-9D4571672535@freyther.de> Hi, as part of adding bindings I wrote code that is doing shutdown/no shutdown every second. Actually I call mobile_init/mobile_exit with a script like this: local start = false osmo.ms().start() function toggle_it() osmo.timeout(1, function() if start then start = false osmo.ms().start() else start = true osmo.ms().stop() end toggle_it() -- start the timer again end end toggle_it() And while debugging I have nothing connected for the l1ctl. This means the l1ctl reset ack is not being received by the application. So when doing the above the following happens. mobile_init() mobile_exit() mobile_init() |-> busy loop of adding a timer already in the tree Turns out that mobile_exit checks the state and then takes an early exit without stopping the timers. So let's use the force option that is meant to not send a IMSI detach. Let's try it again. mobile_init() mobile_exit() mobile_init() |-> busy loop of adding a timer already in the tree Why is that? Even force mobile_exit() will exit early and mobile_init() doesn't take the device out of shutdown. From my point of view a mobile_exit(ms, force) should really take the device down and never fail. Any objections to modify the code for this? regards holger From axilirator at gmail.com Thu Nov 16 05:30:54 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 16 Nov 2017 12:30:54 +0700 Subject: Calypso vs. SDR PHY Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mychaela.falconia at gmail.com Thu Nov 16 06:58:08 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Wed, 15 Nov 2017 22:58:08 -0800 Subject: Calypso vs. SDR PHY In-Reply-To: References: Message-ID: Vadim Yanitskiy 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~ From axilirator at gmail.com Thu Nov 16 07:33:17 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 16 Nov 2017 14:33:17 +0700 Subject: Calypso vs. SDR PHY In-Reply-To: References: Message-ID: > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig at unreasonablefarm.org Sat Nov 18 12:51:13 2017 From: craig at unreasonablefarm.org (craig at unreasonablefarm.org) Date: Sat, 18 Nov 2017 06:51:13 -0600 Subject: Calypso vs. SDR PHY In-Reply-To: References: Message-ID: <20171118125113.GA22041@localhost> 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 From laforge at gnumonks.org Sat Nov 18 19:26:06 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 Nov 2017 20:26:06 +0100 Subject: Calypso vs. SDR PHY In-Reply-To: References: Message-ID: <20171118192606.hrhly2w4bs5ticdd@nataraja> Hi Mychaela, On Fri, Nov 10, 2017 at 05:17:21PM -0800, Mychaela Falconia wrote: > 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. Actually, it's also (3) the (particularly) receiver performance of the TIS DSP is pretty damn good and it is quite some effort to achieve comparable performance with a general-purpose SDR. You can e.g. add external band filters for downlink, but then you're still missing the analog matches 270kHz baseband filter in front of the ADC to avoid loosing any ADC resolution to nearby in-band carriers. The analog filters in integrated RFICs today typically don't go smaller than 1MHz (if at all) which is quite far from the 270kHz that GSM uses. (4) you can actually run the entire application (e.g. http://osmocom.org/projects/baseband/wiki/Rssibin) inside a small, hand-held, battery-powered device. Try that with PC + SDR and look at your size + power budget. (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. > But the dirt-cheap Calypso phone situation is now firmly in the past, > and newly made Calypso devices like my FCDEV3B are nowhere close to > cheap. It is also something to keep in mind that a lot of the people who had an interest in OsmocomBB have those phones for years. And the number of new people who haven't been around for many years with an interest in playing with "old" cellular systems such as GSM is quite low. > 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. But sure, it will not be at the level of a used old phone. > 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? See above. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Nov 18 19:30:23 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 Nov 2017 20:30:23 +0100 Subject: Calypso vs. SDR PHY In-Reply-To: References: Message-ID: <20171118193023.5s3xjg3hkxdbsewh@nataraja> 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. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Sun Nov 19 03:03:51 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sat, 18 Nov 2017 19:03:51 -0800 Subject: Calypso vs. SDR PHY In-Reply-To: <20171118193023.5s3xjg3hkxdbsewh@nataraja> References: <20171118193023.5s3xjg3hkxdbsewh@nataraja> Message-ID: 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~ From craig at unreasonablefarm.org Sun Nov 19 05:41:47 2017 From: craig at unreasonablefarm.org (Craig Comstock) Date: Sat, 18 Nov 2017 23:41:47 -0600 Subject: adjust gnu arm toolchain directions for newer gcc (7.2.0-14) In-Reply-To: <20171118193023.5s3xjg3hkxdbsewh@nataraja> References: <20171118193023.5s3xjg3hkxdbsewh@nataraja> Message-ID: <20171119054147.7i7ml6yd7sfp2sx3@localhost.localdomain> 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=ec1cc0263f156f70693a62cf17b254a0029f4852 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 From laforge at gnumonks.org Sun Nov 19 08:20:58 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 19 Nov 2017 09:20:58 +0100 Subject: Calypso vs. SDR PHY In-Reply-To: References: <20171118193023.5s3xjg3hkxdbsewh@nataraja> Message-ID: <20171119082058.ochqqdlgn77qgfq7@nataraja> 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: > > https://bitbucket.org/falconian/freecalypso-tools 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 -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Sun Nov 19 15:32:11 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 19 Nov 2017 18:32:11 +0300 Subject: Calypso vs. SDR PHY In-Reply-To: References: Message-ID: Hi Mychaela, On Sat, Nov 11, 2017 at 4:17 AM, Mychaela Falconia wrote: > But the dirt-cheap Calypso phone situation is now firmly in the past, > and newly made Calypso devices like my FCDEV3B are nowhere close to > cheap. 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, but getting any kind of firm numbers > beyond a guesstimate would require actual work, and that work will > only be done if I receive some expression of serious and genuine > interest. But even if we manage to bring the price down to, say, $200 > per board with a really large order quantity, it *still* won't be > anywhere near as cheap as old Calypso phones used to be, and the price > is still essentially in the same ballpark as a midrange SDR device. > > 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? > 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? I'm not an active OsmocomBB user or developer, but being involved with SDR development since 2008 I want to add my 2cc. I personally think that the SDR way makes much more sense at this moment. Combine an SDR like our XTRX with any of the widely available ARM boards and you get a very portable device which can do GSM and more. If you create a custom board you can even add PA, filters (bandpass and/or channel), SIM card slot and get a real phone. Such a carrier board will be very easy to route and cheap to manufacture so I'm quite sure it'll be at least no more expensive. And given a much wider functionality, it will be probably much higher volume, again helping drive the cost down. Another benefit of the SDR approach is that it will allow you to have a real FOSS phone - see Harald's comment which I 100% support. In a "naive" approach receive sensitivity will be degraded compared to a real phone, but you can put an extra PLL with channel filter to resolve this at a slight increase in the cost. Most researchers don't probably need champion sensitivity though, so you can make this an option. It's easy to route it so that you can populating or not those components depending on your customer requirements. Obvious "cons" of the SDR approach is a higher power consumption. In our XTRX (not sure about other SDRs) we can turn off RFIC or even the FPGA but I think it will be more power hungry anyway. Frequency hoping should be doable as well. We haven't done real measurements yet, but our back-of-the-envelope calculations showed that we can hop much faster than what you need for GSM. We'll do measurements once we're done with more basic stuff. That said, SDR path while more forward-looking and liberating will require a different skillset than hacking an existing hardware platform. So at the end, it's your choice which path you find more compelling. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From holger at freyther.de Mon Nov 20 12:29:35 2017 From: holger at freyther.de (Holger Freyther) Date: Mon, 20 Nov 2017 20:29:35 +0800 Subject: primitives without msgb Message-ID: Hi, while I am adding scripting support to the mobile application I tried using a primitive interface between the scripting implementation and the mobile application. On new indications a callback in the primitive interface user will be invoked and there is a generic submit function that will dispatch (switch/case) over the primitive and call the right internal functions. To prototype this I have implemented "timer" support, SMS and the started/shutdown handling through primitives. The neat thing about this approach is that I don't tie a specific scripting solution into the code, the indications are generic enough to be useful in multiple contexts, the submit/dispatch is about high level operations ("send SMS", "switch device off") that map to other programming languages as well. E.g. it is easy to imagine that one writes a TCP/IP adapter to send these primitives to another process/application. The controversial part is that this code is not using a msgb. Normally the primitive header is inside a msgb and then more or less points to itself. But in the scripting layer case the "timer", "new sms", "network selection" are already fully parsed objects (or where never parsed from a network representation) so are normally not located in a msgb in any form. One option is not to bother and deal with the primitive header just being embedded in another structure. The concept of request/response/indication is bigger than network messages. The other is to create a dummy msgb to obey the interface and follow the existing users but I am not sure what we would gain. For XYZ->internal we can use direct function calls and avoid the indirection of the primitives and for indications either call directly into the scripting code or create a script_indications struct and put it into the struct osmocom_ms. Only downside that doing RPC requires more work? So far I only forsee a single "script_indications" callback. comments? opinions? holger From laforge at gnumonks.org Mon Nov 20 13:25:28 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 20 Nov 2017 14:25:28 +0100 Subject: primitives without msgb In-Reply-To: References: Message-ID: <20171120132528.gxxs5fsctfqwnww5@nataraja> Hi Holger, thanks for bringing this up. The original idea of introducing osmo_prim was for asynchronous primitives being exchanged between individual parts of a protocol stack. I think the L1/L2 interface in OsmocomBB was one of the first users. There we also need the async nature, as primitives are sent over the serial line. In other parts of the code, like the libosmo-sigtran MTP-USER-SAP or SCCP-USER-SAP, there are still msgb-wrapped osmo_prim, despite us currently dispatching them synchronously into the user application code. The idea was that this could later be evolved into a system where the related msgb's are sent over a unix domain socket between applications to isolate the sigtran/sccp stack from the user application. So my general "road map" for osmo_prim and related SAPs is in that direction: * turn SAPs into first-class citizens with infrastructure to register them, VTY introspection, etc. * have facilities for accessing SAPs from different processes via unix domain sockets and exchange osmo-prim over sockets On Mon, Nov 20, 2017 at 08:29:35PM +0800, Holger Freyther wrote: > The neat thing about this approach is that I don't tie a specific > scripting solution into the code, the indications are generic enough > to be useful in multiple contexts, the submit/dispatch is about high > level operations ("send SMS", "switch device off") that map to other > programming languages as well. E.g. it is easy to imagine that one > writes a TCP/IP adapter to send these primitives to another > process/application. I very much like this and support it. This is also how I had envisioned this feature to move ahead: First have some primitives for those operations, and then use those primitives from a language binding such as lua. > The controversial part is that this code is not using a msgb. Normally > the primitive header is inside a msgb and then more or less points to > itself. Yes, and the goal of this is to have all information inside the primitive. We don't pass pointers across a SAP. All information is self-contained and only identifiers are used to refererence other state/objects. This means they can be queued, transported over sockets (at least on the same host where the struct alignment/padding/endinanness is identical), ... > But in the scripting layer case the "timer", "new sms", "network > selection" are already fully parsed objects (or where never parsed > from a network representation) so are normally not located in a msgb > in any form. Yes, understood. Still, those structures could probably simply be copied/wrapped into a msgb? Like the struct that represents a parsed SMS? > One option is not to bother and deal with the primitive header just > being embedded in another structure. The concept of > request/response/indication is bigger than network messages. correct. However, I think it might actually be good to call things differently or to find some kind of naming to make it easy for them not to be confused? > The other is to create a dummy msgb to obey the interface and follow > the existing users but I am not sure what we would gain. We wouldn't gain anything as long as there would still be pointers or other non-serialized data inside the msgb itself. Wrapping into a msgb only makes sense if the msgb-wrapped-prim is self-contained. At that point you gain that you can queue them, work asynchronosly on them, and that e.g. a script language VM/interpreter/... could run in a completely different process. I would love to see that, but of course if it's only possible by crating tons of new struct definitions, copying the data back and forth, etc. a shortcut like you proposed might be more realistic. But then, given that the number of high-level primitives is expected to be rather small (perform LU, MO-SMS, MT-SMS, USSD) in theory it should not be too much data that needs to be converted? For call control, it occurs to me only now, we could and probably should actually use the MNCC interface that OsmocomBB already offers. So existing MNCC primitives (which predate osmo_prim, but which would have been be a very good fit conceptually) can be created/used by the "script language process/thread/binding" side to create higher-level functions that can be used from the script language. So the script would simply synchonously ask for make_a_mo_voice_call(msisdn) while then the underlying C code would translate that to MNCC and use the existing socket for that? In the end, you are doing the work, and it's your call. I see some benefits of going the msgb way, but then I don't understand the implications in detail as you do, working on the given task. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Fri Nov 24 20:13:45 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 24 Nov 2017 12:13:45 -0800 Subject: OsmocomBB layer1 with FreeCalypso changes Message-ID: Hello OsmocomBB community, I have just produced a modified version of the Calypso target fw part of OsmocomBB, adding proper support for the FCDEV3B board target and also bringing the pre-existing Calypso targets up to par while at it. You can find it here: ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/obb-fcmods-r1.tar.bz2 obb-fcmods-r1 stands for "OsmocomBB with FreeCalypso modifications, release 1". Here are the main changes relative to mainline OsmocomBB, quoted from the README file inside the tarball: * Added support for FreeCalypso FCDEV3B target, target name fcdev3b, new board/fcdev3b directory, compiling into board/fcdev3b/layer1.highram.bin. * Fixed GPIO and ASIC_CONF_REG configuration on the pre-existing Openmoko GTA0x target: very similar to our own FCDEV3B, but not identical. * Fixed ASIC_CONF_REG setting on the Pirelli DP-L10 target to match what Pirelli's official fw sets. * Implemented reading of factory RF calibration values, not only on our own FCDEV3B, but also on the pre-existing Motorola C1xx, Openmoko GTA0x and Pirelli DP-L10 targets. * The old OsmocomBB Tx power level control code and tables have been removed entirely and replaced with new logic that exactly matches what the official chipset firmware (TI/FreeCalypso) does, using tables in TI/FreeCalypso format. These tables are normally populated with factory-programmed RF calibration values on all supported targets. Compiled-in tables serve as a fallback and match each target's respective original fw. * A different AFC slope value is used on different targets; OsmocomBB's original value was/is only correct for the Mot C1xx family, whereas GTA0x/FCDEV3B and Pirelli DP-L10 need different values because Openmoko's VCXO (copied on the FCDEV3B) and Pirelli's VCTCXO are different from what Motorola used. * The initial AFC DAC value for the FB search is taken from factory calibration records on those targets on which it has been calibrated per unit at the factory. The tarball contains a source + build products tree, i.e., ready-to-use board/*/layer1.highram.bin images are included. They have been compiled with Tx support enabled. Happy hacking, Mychaela From mychaela.falconia at gmail.com Fri Nov 24 23:07:00 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 24 Nov 2017 15:07:00 -0800 Subject: GSM850 downlink band SAW filter Message-ID: Hello OsmocomBB community, Now that the software issues have been solved with my obb-fcmods-r1 release, there is only one remaining feature of the historical Mot C1xx phones that is not matched by the newly-made FCDEV3B product: support for the GSM850 band. Mot C1xx phones were made in 900+1800 MHz and 850+1900 MHz versions; my current FCDEV3B is 900/1800/1900 MHz triband, but no 850 MHz band. I could easily produce an 850/1800/1900 MHz version of the FCDEV3B if I knew which SAW filter part number I should populate instead of the EGSM downlink band B7820 filter which currently sits in the low band Rx path. But I don't know this part number. I know that Openmoko produced both 900/1800/1900 MHz and 850/1800/1900 MHz versions of their GTA02 by populating different SAW filter parts onto the same PCB footprint, but I only know the part number for the EGSM downlink band filter (B7820, populated on current FCDEV3B boards), but not the one for the GSM850 downlink band. I looked at the schematics for a later quadband board from TI (I-Sample, LoCosto chipset), but the SAW filters used there have a different PCB footprint (smaller), hence their part won't work. So, would anyone happen to know a part number for a GSM850 downlink band SAW filter (be it the same one as used by Openmoko or a different one) in the same physical package as the B7820, B7821 and B7851 for EGSM, DCS and PCS downlink bands? TIA, Mychaela From axilirator at gmail.com Sun Nov 26 16:26:40 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 26 Nov 2017 23:26:40 +0700 Subject: OsmocomBB layer1 with FreeCalypso changes Message-ID: Hi Mychaela, Great work! I just had a quick look and did some tests. Do you agree if I would merge your changes to the mainstream under GNU GPL version 2 license, keeping you as the author? With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mychaela.falconia at gmail.com Sun Nov 26 17:58:22 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 26 Nov 2017 09:58:22 -0800 Subject: OsmocomBB layer1 with FreeCalypso changes In-Reply-To: References: Message-ID: Hi Vadim, > Do you agree if I would merge your changes to the mainstream > under GNU GPL version 2 license, keeping you as the author? Sure thing! M~ From laforge at gnumonks.org Sun Nov 26 21:08:26 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 26 Nov 2017 22:08:26 +0100 Subject: OsmocomBB layer1 with FreeCalypso changes In-Reply-To: References: Message-ID: <20171126210826.GG24341@nataraja> Hi Mychaela, also thanks from my side (I didn't have time to look at it so far, but based on your mail it seems great progress). On Sun, Nov 26, 2017 at 11:26:40PM +0700, Vadim Yanitskiy wrote: > Do you agree if I would merge your changes to the mainstream > under GNU GPL version 2 license, keeping you as the author? Thanks Vadim. It would be great to see this as patches in gerrit for review and merge. Do you have a FreeCalypso board to test? If not, we can make one remotely accessible (SSH to Linux box which has it connected to UART + USB based power cycling capability of the board power suplpy) in the sysmocom lab, if needed. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Sun Nov 26 22:42:17 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 26 Nov 2017 14:42:17 -0800 Subject: OsmocomBB layer1 with FreeCalypso changes In-Reply-To: <20171126210826.GG24341@nataraja> References: <20171126210826.GG24341@nataraja> Message-ID: Hi Harald, > Do you have a FreeCalypso board to test? If not, we > can make one remotely accessible (SSH to Linux box which has it > connected to UART + USB based power cycling capability of the board > power suplpy) in the sysmocom lab, if needed. Please keep in mind that the board I sent you back in April has not been calibrated: because you claimed it early, it was sent to you before our FreeCalypso RF calibration software (replacement for Openmoko's original which according to you has been lost and couldn't be found) had been developed later in the summer. According to my notes, that board I sent you did have a properly formatted flash file system structure in the first 2 MiB of the second (non-bootable) flash bank, but there are no /gsm/rf/* calibration files in that FFS. If you have a CMU200 which is itself in good calibration standing and an N-to-SMA cable whose insertion loss at the GSM frequencies of interest is precisely known (very important), you should be able to calibrate your FCDEV3B board yourself with my FreeCalypso tools: https://bitbucket.org/falconian/fc-rfcal-tools As alternative options, you can ship the board back to me and I can reship it to you with calibration, or I could send you one of my second-batch boards (already calibrated), and then you send the old one back to me once you receive the new one and confirm that it's good, so you don't have a time window without any board. In the interest of full disclosure, my own CMU200 currently has uncertain calibration status, and I've been told that getting it calibrated at R&S's USA (Maryland) office would cost somewhere around $1600 USD. Unless some sponsor covers it sooner, I expect to be able to make that expenditure some time in 2018 and get truly dependable calibration, but until then there is about 0.5 dB of uncertainty in the Tx power levels I calibrate on FCDEV3B boards. It should definitely be within the tolerances allowed by the GSM 05.05 spec, but I am a perfectionist... There is a more detailed explanation in the doc/Tx-cal-theory article in the fc-rfcal-tools source repository linked above. M~ From holger at freyther.de Mon Nov 27 08:55:54 2017 From: holger at freyther.de (Holger Freyther) Date: Mon, 27 Nov 2017 16:55:54 +0800 Subject: primitives without msgb In-Reply-To: <20171120132528.gxxs5fsctfqwnww5@nataraja> References: <20171120132528.gxxs5fsctfqwnww5@nataraja> Message-ID: > On 20. Nov 2017, at 21:25, Harald Welte wrote: > > Hi Holger, > > Yes, understood. Still, those structures could probably simply be > copied/wrapped into a msgb? Like the struct that represents a parsed > SMS? > At that point you gain that you can queue them, work asynchronosly on > them, and that e.g. a script language VM/interpreter/... could run in > a completely different process. I would love to see that, but of course > if it's only possible by crating tons of new struct definitions, copying > the data back and forth, etc. a shortcut like you proposed might be more > realistic. > In the end, you are doing the work, and it's your call. I see some > benefits of going the msgb way, but then I don't understand the > implications in detail as you do, working on the given task. So it will be neat to just send the msgb to another application but it was easier to just put the struct on the stack and dispatch it. But as you have pointed out we have the MNCC interface, SMS will not be a big deal and the others are probably not very data intensive either. Let's try using msgb and see how that will go. holger From axilirator at gmail.com Tue Nov 28 00:34:25 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 28 Nov 2017 07:34:25 +0700 Subject: OsmocomBB layer1 with FreeCalypso changes In-Reply-To: References: <20171126210826.GG24341@nataraja> Message-ID: Hi Harald, > Thanks Vadim. It would be great to see this as patches > in gerrit for review and merge. Sure, I am working on it in spare time... The 34C3 talk preparation takes the most of time for now :) > Do you have a FreeCalypso board to test? Not yet. > If not, we can make one remotely accessible (SSH to Linux box > which has it connected to UART + USB based power cycling > capability of the board power suplpy) in the sysmocom lab, > if needed. Would be great, thanks! My public key should be in Gerrit, but I can sent it personally, if required. BTW: We have a few wiki pages about the custom Calypso development board. Some of them: https://osmocom.org/projects/baseband/wiki/GsmDevelBoard https://osmocom.org/projects/baseband/wiki/Custom_Calypso_Board https://osmocom.org/projects/baseband/wiki/GsmDevelBoardGsmDevelBoardFPGA I think it makes sense to add a new page about the FCDEV3B. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Nov 29 16:04:27 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 30 Nov 2017 00:04:27 +0800 Subject: State of primitives and lua bindings Message-ID: <2A070A3F-B22F-43FC-B9D5-4124CDF1095D@freyther.de> Hey, I think I have the minimal patchset to add primitives and lua bindings to have useful functionality and know what is good/bad with it and extend/iterate it from here. I would like to share the state and what's next. On the higher level we have: * Primitive for timers * Primitives OP_IND for started/shutdown handling * Primitives OP_IND for SMS status and RX SMS * Primitives OP_IND for Mobility Management state changes Next steps: * Pack MNCC and enable/handle voice calls as well to do call control. What needs to change in future iterations: * SMS, MM, started/shutdown indications should be async. Especially for MM handling that will do further state changes from within the new_mm_state. So if we enable/disable the MS within this callback we ask for trouble. * The lua scripting code is calling some routines directly. E.g. for a "simple" SMS sending routine, to query state. This should probably be converted to primitives as well. But that can be done while keeping the lua API (e.g. with continuations or cache the MS status). * Finish the OsmocomBB manual documentation for the API * Bikeshed. Number vs. Bool... ;) Bugs found by scripting: * I found an ASAN issue in mobile (fix pending) * Noticed paging with outdated TMSI on NITB * Trying to encode an alphabetic phone number causes issue in libosmocore (bug report pending) cheers holger Examples: # Print through logging framework print("Hello from Lua"); log_notice("Notice from lua"); log_debug("Debug from Lua"); log_error("Error from Lua"); log_fatal("Fatal from Lua"); # Start a timer... and cancel it. Notice the ':' local timer = osmo.timeout(1000, function() print("After timeout!!!") end) timer:cancel() # Access a osmo.ms() singleton table/object print("MS", type(osmo.ms())); osmo.ms():imsi() osmo.ms():imei() osmo.ms():shutdown_state() osmo.ms():started() osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23) osmo.ms():start() osmo.ms():shutdown(force) # Callbacks... function ms_started_cb(started) end function ms_shutdown_cb(old_state, new_state) end function sms_cb(sms, cause, valid) for i, v in pairs(sms) do print(i, v) end end function mm_cb(new_state, new_substate, old_substate) if new_state == 19 and new_substate == 1 then osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23) end end local cbs = { Started=ms_started_cb, Shutdown=ms_shutdown_cb, Sms=sms_cb, Mm=mm_cb } osmo.ms():register(cbs) From Zemlyakgleb at gmail.com Mon Nov 20 08:46:55 2017 From: Zemlyakgleb at gmail.com (Zemlyak) Date: Mon, 20 Nov 2017 08:46:55 -0000 Subject: Mobile.cfg test-sim Message-ID: <1511167299089-0.post@n3.nabble.com> Hi Can anyone say,what does it mean "ki xor" in mobile app when I use a test-sim? Does it ciphyring kc? -- Sent from: http://baseband-devel.722152.n3.nabble.com/ From Zemlyakgleb at gmail.com Tue Nov 21 12:21:00 2017 From: Zemlyakgleb at gmail.com (Zemlyak) Date: Tue, 21 Nov 2017 12:21:00 -0000 Subject: Mobile.cfg test sim Message-ID: <1511266859316-0.post@n3.nabble.com> Hi Can anyone tell about "ki xor" in a mobile app-test SIM card data ? -- Sent from: http://baseband-devel.722152.n3.nabble.com/