baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

Re: removing ancient libosmocore fork from osmocom-bb.git
by Craig Comstock 17 May '17

17 May '17

Looks like in package libnewlib-dev for stretch (unstable) we have sys/select.h but in jessie (stable) it is not included. https://packages.debian.org/stretch/libnewlib-dev https://packages.debian.org/jessie/libnewlib-dev craig@box:~/libosmocore$ ./configure --prefix=/usr/local/arm-none-eabi --host=arm-none-eabi --enable-embedded --disable-shared CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" craig@box:~/libosmocore$ make make all-recursive make[1]: Entering directory '/home/craig/libosmocore' Making all in include make[2]: Entering directory '/home/craig/libosmocore/include' make all-am make[3]: Entering directory '/home/craig/libosmocore/include' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/craig/libosmocore/include' make[2]: Leaving directory '/home/craig/libosmocore/include' Making all in src make[2]: Entering directory '/home/craig/libosmocore/src' make all-am make[3]: Entering directory '/home/craig/libosmocore/src' CC select.lo select.c:27:24: fatal error: sys/select.h: No such file or directory #include <sys/select.h> ^ compilation terminated. Makefile:510: recipe for target 'select.lo' failed make[3]: *** [select.lo] Error 1 make[3]: Leaving directory '/home/craig/libosmocore/src' Makefile:373: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/craig/libosmocore/src' Makefile:519: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/craig/libosmocore' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 -------------------------------------------- On Tue, 5/16/17, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: removing ancient libosmocore fork from osmocom-bb.git To: baseband-devel(a)lists.osmocom.org Date: Tuesday, May 16, 2017, 11:18 AM Dear all, when we initially crated OsmocomBB, we moved the code that it shared with the pre-existing OpenBSC project into libosmocore.git, where libosmocore and libosmogsm are built. As libosmocore was quite a bit in flux (and we didn't have jenkins+gerrit yet), we decided to have a local clone of libosmocore.git as a git-subtree module inside osmocom-bb.git Meanwhile, upstream libosmocore received more and more code, and none of that was ever built with an 'arm-non-eabi' toolchain and --enable-embedded. I've been working quite a bit during the last week on making that embedded build work again. The idea is to be able to configure + build libosmocore.git master using something like ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" and then install it onto the host pc. I've used /usr/local/arm-none-eabi as the prefix, but it could of course be anywhere. The above already works for me on Debian unstable using libosmocore.git master. I have some patches pending in laforge/sercomm and laforge/pseudotalloc, but those are not mandatory to make the build work The local clone of libosmocore in OsmocomBB src/shared/libosmocore will be removed, and the Makefiles of osmocom-bb instructed to use the system-installed libosmocore from /usr/local/arm-none-eabi (see my 'laforge/remove-libosmocore' branch in). This also already "works" on my Debian unstable system, in as far as there are no unresolved symbols or other compilation/linking issues, and the firmware images are generated. I have not tested any of the resulting binaries yet, and as I'm travelling without compatible hardware (and overloaded), it's unlikely that I'll be able to test it soon. Nevertheless, this is what I would like to move to. If anyone wants to try if he can build the embedded libosmocore and resulting osmocom-bb from laforge/remove-libosmocore branch, please do so and report your progress/success/issues here. Next steps (after validating the above) are: * remove old sercomm.c code from osmocom-bb and use the new code from libosmocore * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from libosmocore.git (plus an embedded 'malloc' like umm_malloc) Further ideas: * create Debian/Ubuntu package of cross-compiled libosmocore for embedded-arm, which we can add to the Osmocom nightly builds apt repository. * have an (optional?) osmocom-bb makefile step to git clone + configure + make install libosmocore Anyone interested in helping out with this, please feel free to join in. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

removing ancient libosmocore fork from osmocom-bb.git
by Harald Welte 17 May '17

17 May '17

Dear all, when we initially crated OsmocomBB, we moved the code that it shared with the pre-existing OpenBSC project into libosmocore.git, where libosmocore and libosmogsm are built. As libosmocore was quite a bit in flux (and we didn't have jenkins+gerrit yet), we decided to have a local clone of libosmocore.git as a git-subtree module inside osmocom-bb.git Meanwhile, upstream libosmocore received more and more code, and none of that was ever built with an 'arm-non-eabi' toolchain and --enable-embedded. I've been working quite a bit during the last week on making that embedded build work again. The idea is to be able to configure + build libosmocore.git master using something like ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" and then install it onto the host pc. I've used /usr/local/arm-none-eabi as the prefix, but it could of course be anywhere. The above already works for me on Debian unstable using libosmocore.git master. I have some patches pending in laforge/sercomm and laforge/pseudotalloc, but those are not mandatory to make the build work The local clone of libosmocore in OsmocomBB src/shared/libosmocore will be removed, and the Makefiles of osmocom-bb instructed to use the system-installed libosmocore from /usr/local/arm-none-eabi (see my 'laforge/remove-libosmocore' branch in). This also already "works" on my Debian unstable system, in as far as there are no unresolved symbols or other compilation/linking issues, and the firmware images are generated. I have not tested any of the resulting binaries yet, and as I'm travelling without compatible hardware (and overloaded), it's unlikely that I'll be able to test it soon. Nevertheless, this is what I would like to move to. If anyone wants to try if he can build the embedded libosmocore and resulting osmocom-bb from laforge/remove-libosmocore branch, please do so and report your progress/success/issues here. Next steps (after validating the above) are: * remove old sercomm.c code from osmocom-bb and use the new code from libosmocore * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from libosmocore.git (plus an embedded 'malloc' like umm_malloc) Further ideas: * create Debian/Ubuntu package of cross-compiled libosmocore for embedded-arm, which we can add to the Osmocom nightly builds apt repository. * have an (optional?) osmocom-bb makefile step to git clone + configure + make install libosmocore Anyone interested in helping out with this, please feel free to join in. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Re: CalypsoBTS and modern OsmoBSC
by Vadim Yanitskiy 12 May '17

12 May '17

Hi, > I found that the manual from the main site is outdated. Yeah, still couldn't find some time to update the wiki. > If I understood it correct, I have to setup calypso bts > as bts of type nanoBTS, correct? Why do you think so? No, CalypsoBTS has nothing related toip.access nanoBTS. From the other side, we don't have a dedicated type for OsmoBTS, so you can use 'sysmoBTS'. > I can sync with commercial cell, I can run OsmoBSC and > OsmoBTS but I still cannot find my network from my personal > phone in searching mode. Please watch a great Sylvain's talk, where he explained almost everything you need to know: "Further hacks on the Calypso platform" https://media.ccc.de/v/29c3-5226-en-further_hacks_calypso_h264 In short: BTS should transmit a continuous beacon on C0 to be detected. Normal MS can't do that. CalypsoBTS was hacked to perform the following timeslot layout: Tt_R_ttt, where 'T' means TX on Downlink, 'R' means RX on Uplink, and 't' means channel filling - dummy bursts. Phone cannot RX and TX at the same time, so one phone serves only one TS. With two phones you have the following layout: TT_RRttt, so you have two timeslots served. This is why you will have some detection troubles even with working BSS setup :/ > In logs of osmo-bts I can see: > > <0000> rsl.c:246 Tx RSL RF RESource INDication > <000b> trx_if.c:397 transceiver (phy0.0) rejected TRX command with > response: 'RSP SETTSC -1' > <0000> rsl.c:2353 (bts=0,trx=0,ts=0,ss=0) Rx RSL BCCH_INFO Just delete the 'settsc' line from your config, because CalypsoBTS transceiver only supports 'setbsic'. Have a fun! With best regards, Vadim Yanitskiy.

3 8

Timeslot allocation
by Anton Gorbachev 12 May '17

12 May '17

Dear colleagues, Could you please tell me when I am wrong in my assumptions? My story is about beacon channel. >From different resourses I got the information that we transmit bcch data (fcch,sch,bcch) which is required for MS to find our network. OK? On the pictures it's drawn like we transmit BCCH on C0T0. So DL TS1-7 can be used for i.e. TCH. So if we want just to create bts which can be found by MS and that's all, we may not transmit on TS1-7 at all. OK? When we are talking about CalypsoBTS we say that we must transmit several burst in a row. So here I am a bit confused. So if we want to just transmit bcch messages we can transmit every TS0 and rest on TS1-7. Why not? Why I can see in manuals and videos pictures like Ttt_R_tt? Why do I need these dummy "t" bursts? Why one burst is "t" and another is "T"? Sure I understand that we must receive something for normal BTS operation like RACH and need some time to switch Tx/Rx. But why we just cannot use mask like T_R_T_R_ ...? I understood that we cant use mask TTT_RR because calypso phone was not hacked to receive two bursts in a row. Thanks in advance!

1 0

CalypsoBTS and modern OsmoBSC
by Anton Gorbachev 10 May '17

10 May '17

Dear colleagues, I am trying to set up CalypsoBTS with the last version of OsmoNTIB and branch jolly/testing (so using two phones). I found that the manual from the main site is outdated. It doesn't work with the config provided os I am trying to figure out how to tune it manually. If I understood it correct, I have to setup calypso bts as bts of type nanoBTS, correct? I can sync with commercial cell, I can run OsmoBSC and OsmoBTS but I still cannot find my network from my personal phone in searching mode. Could you please tell me what can be wrong? I tried both GSM900 and DSC1800, different channels selected after RSSI checking... Both phones are w/o filter rework, they are motorola c113 and c113a. In logs of osmo-bts I can see: <0000> rsl.c:246 Tx RSL RF RESource INDication <000b> trx_if.c:397 transceiver (phy0.0) rejected TRX command with response: 'RSP SETTSC -1' <0000> rsl.c:2353 (bts=0,trx=0,ts=0,ss=0) Rx RSL BCCH_INFO In osmo-bsc log everything looks fine: <001e> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3003 <0005> abis_nm.c:2513 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK <0005> abis_nm.c:698 OC=CHANNEL(03) INST=(00,00,00) Set Channel Attributes ACK <0004> bsc_init.c:288 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 29 using MCC=1 MNC=1 LAC=5 CID=5 BSIC=5 <0003> system_information.c:544 Serving cell: 29 <0003> bsc_init.c:105 SI1: 55 06 19 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 e5 04 00 2b Here below are my configs: ======================================= osmo-bts.cfg phy 0 instance 0 bts 0 band GSM900 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 0 paging queue-size 200 paging lifetime 0 ms-power-loop -60 timing-advance-loop settsc setbsic trx 0 phy 0 instance 0 ========================================= open-bsc.cfg phy 0 instance 0 bts 0 band GSM900 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 0 paging queue-size 200 paging lifetime 0 ms-power-loop -60 timing-advance-loop settsc setbsic trx 0 phy 0 instance 0 root@osmobox:~/.osmocom# cat open-bsc.cfg ! ! OpenBSC (0.15.0.754-c6e8) configuration saved from vty !! ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll everything logging level cc everything logging level mm everything logging level rr everything logging level rsl everything logging level nm everything logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level ranap debug logging level sua debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice log file logfile logging filter all 0 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll notice logging level cc notice logging level mm notice logging level rr notice logging level rsl notice logging level nm info logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level ranap debug logging level sua debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive network network country code 1 mobile network code 1 short name HomeGSM long name HomeGSM auth policy closed authorized-regexp .* location updating reject cause 13 encryption a5 0 neci 0 paging any use tch 0 rrlp mode none mm info 0 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 40 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 10 timer t3141 0 dyn_ts_allow_tch_f 0 subscriber-keep-in-ram 0 bts 0 type nanobts band GSM900 cell_identity 5 location_area_code 5 base_station_id_code 5 ms max power 0 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1801 0 ip.access rsl-ip 127.0.0.1 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr hr amr gprs mode none no force-combined-si trx 0 rf_locked 0 arfcn 29 nominal power 23 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/H hopping enabled 0 timeslot 2 phys_chan_config TCH/H hopping enabled 0 timeslot 3 phys_chan_config TCH/H hopping enabled 0 timeslot 4 phys_chan_config TCH/H hopping enabled 0 timeslot 5 phys_chan_config TCH/H hopping enabled 0 timeslot 6 phys_chan_config TCH/H hopping enabled 0 timeslot 7 phys_chan_config TCH/H hopping enabled 0 mncc-int default-codec tch-f amr default-codec tch-h amr nitb subscriber-create-on-demand assign-tmsi

1 0

Re: CalypsoBTS + GPRS and SDR suggestion
by Vadim Yanitskiy 09 May '17

09 May '17

Hi, > I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the > best way to do that, but I would like to have a cheap solution. I got the > setup working with a normal phone and the BTS seems to work correctly > (using jolly/testing), but from my understanding it support only GSM calls > and SMS and GPRS is not implemented into the transceiver. I'm wrong or this > part has not been implemented yet? Right, isn't implemented. When you run OsmoBTS, it first does some basic configuration of transceiver, including timeslot type setting. PDCH has its own dedicated type, which is being indicated by the SETSLOT command. So you can look at OsmocomBB sources, and check whether the transceiver handles this type or not. > Also, given that CalypsoBTS can only provide single (or two?) timeslot, > there are a long list of reasons why it would not work straight-forward. > But technically also possible to make work. With two Calypso phones it becomes possible to serve two timeslots. Basically, second phone serves one TCH timeslot, but (if I am correct) PDCH has no fundamental differences from TCH, so its support could be implemented too. After a quick look at OsmoTRX source code, I can assume, that the only difference between TCH channel combinations (I, II and III) and PDCH channel combination (XIII) is a fillerModulus value. Correct me if I am wrong. With best regards, Vadim Yanitskiy.

3 2

CalypsoBTS + GPRS and SDR suggestion
by inode 08 May '17

08 May '17

Hi everybody, I'm pretty new to the GSM/UMTS environment and I'm doing some tests. Currently I need to analyze some IoT devices that use 2G network to comunicate via GPRS. I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the best way to do that, but I would like to have a cheap solution. I got the setup working with a normal phone and the BTS seems to work correctly (using jolly/testing), but from my understanding it support only GSM calls and SMS and GPRS is not implemented into the transceiver. I'm wrong or this part has not been implemented yet? If needed to use a GPRS BTS can you suggest the best cheap SDR to use with OsmoBTS? (I saw BladeRF and LimeSDR but I was unable to understand if they are full supported via OsmoBTS) Thank you in advance. inode

3 2

Re: to qcom hexagon porting
by Craig Comstock 08 May '17

08 May '17

> what are problem should i expect > while porting to qcom hexagon > is it a bad idea There would be a lot of questions and things to research. I am not familiar with qcom hexagon SDK. I am a little familiar with osmocom-bb source code and 2G GSM details. I am currently in the very beginning stages of porting osmocom-bb to the MediaTek 6260/6261 chip which supports 2G. I also have ideas to try and work through 3G on a MediaTek 6735 (ZTE Obsidian phone). Recently there have been mentions of re-writing the PHY layer of osmocom-bb for an SDR platform like LimeSDR. https://github.com/axilirator/osmocom-bb So at the current time I assume that osmocom-bb communicates with the DSP chip on the motorola phones in a way that abstracts the PHY layer details away and relies on the proprietary Texas Instruments firmware in the DSP as-is. So I would imagine you might have to implement the PHY layer and also the interface to the PHY layer. There was a discussion about this recently on IRC #osmocom. It seems the thought was that qcom had released enough with their Hexagon SDK to allow development of a PHY layer + whatever else. Some links of interest. https://developer.qualcomm.com/ - SDK https://github.com/ttsou/openphy - LTE PHY for Ettus USRP https://androiddatahost.com/fgd43 - qcom flash image loader I have a few qcom modems that I'd be happy to do experiment on if that helps. -Craig

1 0

to qcom hexagon porting
by thayyil09 yil 08 May '17

08 May '17

what are problem should i expect while porting to qcom hexagon is it a bad idea

1 0

Re: CalypsoBTS no sync, ms hang
by Vadim Yanitskiy 07 May '17

07 May '17

> isn't fixed in branch jolly/testing I am using for calypsoBTS. > So all I needed is just implement the fix and recompile from sources. You can also use an older version of toolchain as a temporary solution: https://github.com/axilirator/gnu-arm-installer - in this repo I have fixed some installation (texinfo) related issues. With best regards, Vadim Yanitskiy.

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel