baseband-devel

baseband-devel@lists.osmocom.org

2023 discussions

primitives without msgb
by Holger Freyther 27 Nov '17

27 Nov '17

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

2 2

GSM850 downlink band SAW filter
by Mychaela Falconia 25 Nov '17

25 Nov '17

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

1 0

OsmocomBB layer1 with FreeCalypso changes
by Mychaela Falconia 24 Nov '17

24 Nov '17

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

1 0

Mobile.cfg test sim
by Zemlyak 21 Nov '17

21 Nov '17

Hi Can anyone tell about "ki xor" in a mobile app-test SIM card data ? -- Sent from: http://baseband-devel.722152.n3.nabble.com/

1 0

Mobile.cfg test-sim
by Zemlyak 20 Nov '17

20 Nov '17

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/

1 0

Calypso vs. SDR PHY
by Mychaela Falconia 19 Nov '17

19 Nov '17

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.

3 2

Re: Calypso vs. SDR PHY
by Vadim Yanitskiy 19 Nov '17

19 Nov '17

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.

5 7

Reliability of no shutdown/shutdown loop
by Holger Freyther 13 Nov '17

13 Nov '17

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

1 0

Want to do paid work on Osmocom? sysmocom is hiring
by Harald Welte 31 Oct '17

31 Oct '17

Dear Osmocom community, I would like to point out that at sysmocom, we're currently (again) hiring [1]. If you happen to have an interest in open source cellular communications and are fluent in C language development, we would love to hear from you. sysmocom probably doesn't need any introduction here, but just in case: The company was founded by Holger Freyther and Harald Welte, two of the leading OpenBSC and Osmocom developers from the very early days of the project. Today we are responsible for by far the largest number of commits to the Osmocom GSM/3G infrastructure related git repositories. Among our current priorities are automatic testing for the GPRS PCU, generalization of the OsmoMGW media gateway, support for load-based hand-over, inter-BSC hand-over as well as various improvements on the lower layers of the GPRS protocol stack. We're very dedicated to the cause in furthering the capabilities of open source cellular infrastructure from 2G to 4G. We believe in working upstream, no open core or dual licensing. If you have an interest working with an enthusiastic, strong technical and dedicated team of Osmocom hackers, please don't hesitate to let me know, best by e-mail to jobs(a)sysmocom.de Thanks, Harald p.s.: I hope this kind of message is not disturbing to anyone. I think it is important to the Osmocom project to have more paid people working on the stack, so it is justified. The positions we are seeking to fill will work [almost exclusively] on Osmocom, so it's not a random job ad but in the very interest of Osmocom, and hence on-topic for this list. [1] https://www.sysmocom.de/jobs/ -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

layer23/mobile: VTY is broken
by Vadim Yanitskiy 23 Oct '17

23 Oct '17

On 22 October 2017 at 19:20, Snehasish Kar <snehasish.cse(a)live.com> wrote: > Hello Vadim > > I tried using your trxcon along with grgsmtrx, > but when i start the app mobile in the l2l3 software > it gives me the following error: > > Assert failed !check_element_exists(cnode, cmd->string) command.c:627 > backtrace() returned 7 addresses > /usr/local/lib/libosmovty.so.3(install_element+0x136) [0x7f7a8c7fd4b6] > ./mobile() [0x43d371] > ./mobile() [0x40548e] > ./mobile() [0x4049e7] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7a8bffaf45] > ./mobile() [0x404a83] > > Please help. Hi, This message was forwarded to the ML. Please do the same in the future to make others able to know about the problem and possible solutions. Actually, this crash isn't related to trxcon application anyhow, it's caused by the recent libosmocore changes, related to the VTY default nodes. A quick solution would be to drop all custom 'exit' commands from the 'vty_interface.c'. I'll try to fix the problem in spare time... If you have some time and feel yourself able to write a proper fix, just send me a patch, and I'll review one ASAP ;) BTW: we have some updates regarding to TX support. Please look at the 'origin/ptrkrysik/trx' and 'axilirator/fixeria/trx' on GitHub. With best regards, Vadim Yanitskiy.

3 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel