From olegtsss at mail.ru Mon Sep 4 15:53:34 2017 From: olegtsss at mail.ru (=?UTF-8?B?0J7Qu9C10LMg0KHRg9Cy0L7RgNC+0LI=?=) Date: Mon, 04 Sep 2017 18:53:34 +0300 Subject: =?UTF-8?B?aGVscCBtZQ==?= Message-ID: <1504540414.600319080@f142.i.mail.ru> ? ?Hello, I am from Russia, can you help me with Filter Replacement! I have to mobile, Motorolla C115 and C118. I was bye all elements to make filter replacement. Motorolla C115 look like your instruction and I was done filter replacement. Motorolla C115 nice work after it. But Motorolla C118 don`t look like in your instruction (no network signal or network signal is 1 level from 5). ? ?I read:?"Different circuit Sometimes the input (at the bottom of the balun) is not with caps in series and a resistor in parallel. Instead it might be without the resistors in parallel and resistors in series. Remove the resistors and place 2x the appropriate cap in series (22 pF for GSM90, 15 pF for DCS1800". ? ?But I don`t understand what I must do. I do like my picture (your network email network filter doesn`t allow me to download my photo, but I can send it if you allow this), but after it Motorolla don`t work: No signal from Network (or network signal is 1 level from 5). Can you help me? With Best Regards, Oleg Syvorov -------------- next part -------------- An HTML attachment was scrubbed... URL: From kantooon at gmail.com Wed Sep 6 10:28:44 2017 From: kantooon at gmail.com (Adrian Musceac) Date: Wed, 6 Sep 2017 11:28:44 +0100 Subject: SDR_PHY question Message-ID: Hello, I am interested in the sdr_phy work being done currently, and I'm trying to get it set up on my computer. I built osmo-trx from the ms branch and implemented a crude power measurement command. When running trxcon everything works fine, I get power indications for channels, and then when the mobile app is trying to sync to an ARFCN I start having issues. The FCCH bursts are decoded fine, and so are the SCH bursts (which I can also see in the osmo-trx terminal). I had to change the code of trxcon in order for SCH to work, because the bit values were inverted (0 was 1 and viceversa). I am attaching the changes at the end of the message. Unfortunately, the BCCH and CCCH bursts are not decoded: <0006> sched_lchan_sch.c:98 Received SCH: bsic=30, fn=1116799, sched_fn=1116798 <0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116800 ts=0 bid=0 <0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116801 ts=0 bid=1 <0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116802 ts=0 bid=2 <0006> sched_lchan_xcch.c:69 Data received on BCCH: fn=1116803 ts=0 bid=3 <0006> sched_lchan_xcch.c:117 Received bad data frame at fn=1116800 (2/51) for BCCH with 66 errors It appears as if the deinterleaving in gsm0503_xcch_decode does not work... could be the order of bursts? I'd appreciate any help here. I'm also ready to share the changes I've made to osmo-trx/ms and trxcon. Best regards, Adrian diff --git a/src/host/trxcon/trx_if.c b/src/host/trxcon/trx_if.c index 6a84af6..def571c 100644 --- a/src/host/trxcon/trx_if.c +++ b/src/host/trxcon/trx_if.c @@ -325,6 +325,11 @@ int trx_if_cmd_setslot(struct trx_instance *trx, uint8_t tn, uint8_t type) return trx_ctrl_cmd(trx, 1, "SETSLOT", "%d %d", tn, type); } +int trx_if_cmd_sync(struct trx_instance *trx, uint8_t type) +{ + return trx_ctrl_cmd(trx, 1, "SYNC", "%d", type); +} + /* * Tuning Control * @@ -392,7 +397,7 @@ int trx_if_cmd_measure(struct trx_instance *trx, LOGP(DTRX, LOGL_ERROR, "ARFCN %d not defined\n", arfcn_start); return -ENOTSUP; } - + trx_ctrl_cmd(trx, 1, "RXTUNE", "%d", freq10 * 100); return trx_ctrl_cmd(trx, 1, "MEASURE", "%d", freq10 * 100); } @@ -421,6 +426,7 @@ static void trx_if_measure_rsp_cb(struct trx_instance *trx, char *resp) arfcn == trx->pm_arfcn_stop); /* Schedule a next measurement */ + usleep(50000); if (arfcn != trx->pm_arfcn_stop) trx_if_cmd_measure(trx, ++arfcn, trx->pm_arfcn_stop); } @@ -558,9 +564,9 @@ static int trx_data_rx_cb(struct osmo_fd *ofd, unsigned int what) /* Copy and convert bits {254..0} to sbits {-127..127} */ for (i = 0; i < 148; i++) { if (buf[8 + i] == 255) - bits[i] = -127; + bits[i] = 127; else - bits[i] = 127 - buf[8 + i]; + bits[i] = -127 + buf[8 + i]; } From axilirator at gmail.com Wed Sep 6 13:20:56 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 6 Sep 2017 20:20:56 +0700 Subject: SDR_PHY question Message-ID: Hi Adrian, > I am interested in the sdr_phy work being done currently Great to hear that. > I built osmo-trx from the ms branch and implemented a crude > power measurement command. When running trxcon everything works > fine, I get power indications for channels, and then when the > mobile app is trying to sync to an ARFCN I start having issues. I have never developed / tested trxcon with OsmoTRX so far. Currently I am using GR-GSM as a L1 back-end, and the virtual connection between OsmocomBB and OsmoBTS during development. In general, trxcon should be able to 'speak' with OsmoTRX, because one do use classical transceiver UDP interfaces. But there are some CTRL commands, which aren't implemented in OsmoTRX yet (such as ECHO and MEASURE). > I had to change the code of trxcon in order for SCH to work, > because the bit values were inverted (0 was 1 and viceversa). > I am attaching the changes at the end of the message. Sounds strange. In case of virtual Um-interface (FakeTRX) and GR-GSM TRX all SCH messages are decoded correctly. I will look closer to this issue, thanks anyway! > It appears as if the deinterleaving in gsm0503_xcch_decode > does not work... could be the order of bursts? The order of bursts should be consistent, I mean frame-by-frame. You need to make sure that a frame number from SCH burst is being decoded correctly by OsmoTRX. Every burst coming from OsmoTRX has a header with frame number, which is used by trxcon to determine a current frame position within a multiframe. Probably, the problem is due to incorrect / consistent frame number values. The internal clock counter (sched_clck.c) is only used to schedule the UL bursts transmission. > I'd appreciate any help here. I'm also ready to share the > changes I've made to osmo-trx/ms and trxcon. For now, have a look at: - GR-GSM based transceiver: https://github.com/axilirator/gr-gsm/tree/fixeria/trx - Virtual Um-interface (brief description): http://git.osmocom.org/osmocom-bb/tree/src/target/fake_trx/README?h=fixeria/fake_trx - The latest version of trxcon (use fixeria/fake_trx branch): http://git.osmocom.org/osmocom-bb/log/?h=fixeria/fake_trx You can also join the development process, feel free to mail me. I will create the wiki page as soon as possible. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kantooon at gmail.com Wed Sep 6 15:40:51 2017 From: kantooon at gmail.com (Adrian Musceac) Date: Wed, 6 Sep 2017 16:40:51 +0100 Subject: SDR_PHY question In-Reply-To: References: Message-ID: Hi Vadim, > > In general, trxcon should be able to 'speak' with OsmoTRX, > because one do use classical transceiver UDP interfaces. But > there are some CTRL commands, which aren't implemented in OsmoTRX > yet (such as ECHO and MEASURE). > Yes, I implemented both commands, I can share the code with you. My problem is that Gnuradio (distro version) is built against an incompatible ABI version of libuhd, so I have to jump through major hoops just to get both osmo-trx and gnuradio working. So currently all my tests are using osmo-trx only. > > The order of bursts should be consistent, I mean frame-by-frame. > You need to make sure that a frame number from SCH burst is being > decoded correctly by OsmoTRX. Every burst coming from OsmoTRX > has a header with frame number, which is used by trxcon to > determine a current frame position within a multiframe. > Probably, the problem is due to incorrect / consistent > frame number values. The internal clock counter (sched_clck.c) > is only used to schedule the UL bursts transmission. > Yes, the SCH burst has a correct frame number. But the BCCH and CCCH bursts fail to be decoded. CRC fails in libosmocore/coding/gsm0503_coding.c Is your gr-gsm fake-trx able to decode correctly BCCH and CCCH? I double checked the osmo-trx code and besides some major differences between the MS branch and master, everything looks correct. > > You can also join the development process, feel free to mail me. > I will create the wiki page as soon as possible. > Yes, I'd like that, but for now I just want to get BCCH and CCCH working and the mobile syncing with the BTS. Then I will be able to test. Cheers, Adrian From domi at tomcsanyi.net Wed Sep 6 16:09:29 2017 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 6 Sep 2017 18:09:29 +0200 (CEST) Subject: SDR_PHY question In-Reply-To: References: Message-ID: <0C360E18-9153-438C-89E3-7EBCAEAC6559@tomcsanyi.net> Hi, Just a quick thing: to get ABI supported version of UHD do not use the Ettus ppa uhd, but use the one called uhd-lts or something similar. It is compiled with the right ABI version for the gnuradio distro package. Cheers, Domi 2017. szept. 6. d?tummal, 17:42 id?pontban Adrian Musceac ?rta: > Hi Vadim, > >> >> In general, trxcon should be able to 'speak' with OsmoTRX, >> because one do use classical transceiver UDP interfaces. But >> there are some CTRL commands, which aren't implemented in OsmoTRX >> yet (such as ECHO and MEASURE). >> > > Yes, I implemented both commands, I can share the code with you. My > problem is that Gnuradio (distro version) is built against an > incompatible ABI version of libuhd, so I have to jump through major > hoops just to get both osmo-trx and gnuradio working. So currently all > my tests are using osmo-trx only. > >> >> The order of bursts should be consistent, I mean frame-by-frame. >> You need to make sure that a frame number from SCH burst is being >> decoded correctly by OsmoTRX. Every burst coming from OsmoTRX >> has a header with frame number, which is used by trxcon to >> determine a current frame position within a multiframe. >> Probably, the problem is due to incorrect / consistent >> frame number values. The internal clock counter (sched_clck.c) >> is only used to schedule the UL bursts transmission. >> > > Yes, the SCH burst has a correct frame number. But the BCCH and CCCH > bursts fail to be decoded. CRC fails in > libosmocore/coding/gsm0503_coding.c > Is your gr-gsm fake-trx able to decode correctly BCCH and CCCH? I > double checked the osmo-trx code and besides some major differences > between the MS branch and master, everything looks correct. > >> >> You can also join the development process, feel free to mail me. >> I will create the wiki page as soon as possible. >> > > Yes, I'd like that, but for now I just want to get BCCH and CCCH > working and the mobile syncing with the BTS. Then I will be able to > test. > > Cheers, > Adrian From axilirator at gmail.com Wed Sep 6 16:37:23 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 6 Sep 2017 19:37:23 +0300 Subject: SDR_PHY question In-Reply-To: References: Message-ID: > Yes, I implemented both commands, I can share the code with you. It would be great. Just send these patches here using git format-patch / send-email. I'll have a look. > My problem is that Gnuradio (distro version) is built against an > incompatible ABI version of libuhd, so I have to jump through > major hoops just to get both osmo-trx and gnuradio working. > So currently all my tests are using osmo-trx only. Ah, just build it yourself. It would be much better. Distro versions are often pretty dated :( Excluding Arch Linux and similar ;) > Yes, the SCH burst has a correct frame number. > But the BCCH and CCCH bursts fail to be decoded. CRC fails in > libosmocore/coding/gsm0503_coding.c Regarding to the 'bits conversation' you mentioned in the first mail, it's done the same way as in OsmoBTS. It should work as is. Probably SCH bursts are not actually forwarded from OsmoTRX. Or being forwarded in a wrong way. > Is your gr-gsm fake-trx able to decode correctly BCCH and CCCH? Sure. I am even able to make a voice call. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Thu Sep 7 07:26:32 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 7 Sep 2017 10:26:32 +0300 Subject: SDR_PHY question In-Reply-To: References: Message-ID: Hi, > I believe I need to keep focusing on osmo-trx support > as the gr-gsm app does not seem to support TX (please > correct me if I'm wrong though). You are right, currently it doesn't. But we together with Piotr Krysik are working on TX support for GR-GSM... > I will keep investigating this and I will provide you > some patches for osmo-trx which enable power > measurement and synchronization. Great! Having both OsmoTRX and GR-GSM TRX support would be good. I am currently busy with TCH implementation for trxcon, so as soon as I finish, I'll put my development power on this too. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvvelichkov at gmail.com Thu Sep 7 14:44:56 2017 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Thu, 7 Sep 2017 17:44:56 +0300 Subject: Osmocombb on Ubuntu 16.04 In-Reply-To: References: <0E79A3A0-7F68-44B8-8204-D48ABFB1EA44@gnumonks.org> <00a140a8-5220-d982-1b0b-df8fb16c1c63@sysmocom.de> Message-ID: ?? 31.08.2017 ? 20:11, ty ??????: > ?Hello. Resending after seeing Harald's email about the outage. I > hadn't received a response so I suspect my mail never got delivered.? > > > On Fri, Aug 25, 2017 at 5:02 PM, ty > wrote: > > Thanks once again Pau. > > I managed to fix the above error. It was a symlink issue which > forced the build to use the old libtalloc. > > However, the build now fails with this error: > > arm-none-eabi-ld: section .text.exceptions VMA [0080001c,00800037] > overlaps section .compal.reservedram VMA [00800000,008000fe] > Makefile.inc:135: recipe for target > 'board/compal_e88/hello_world.e88flash.elf' failed > make[1]: *** [board/compal_e88/hello_world.e88flash.elf] Error 1 > make[1]: Leaving directory > '/home/tyrus/osmocom-bb/src/target/firmware' > Makefile:89: recipe for target 'firmware' failed > make: *** [firmware] Error 2 > See https://osmocom.org/issues/1917 On Fedora 26 I was able to build it using gcc-4.9.4, binutils-2.21.1a and newlib-1.19.0. I've build the arm toolchain using the build script and instructions from https://osmocom.org/projects/baseband/wiki/GnuArmToolchain BR Vasil -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Sep 7 19:27:27 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 7 Sep 2017 21:27:27 +0200 Subject: Osmocombb on Ubuntu 16.04 In-Reply-To: References: <0E79A3A0-7F68-44B8-8204-D48ABFB1EA44@gnumonks.org> <00a140a8-5220-d982-1b0b-df8fb16c1c63@sysmocom.de> Message-ID: >> arm-none-eabi-ld: section .text.exceptions VMA [0080001c,00800037] >> overlaps section .compal.reservedram VMA [00800000,008000fe] Yeah, IIRC the issue is that the newer GCC can't have overlapping regions even if they're NOLOAD. Problem is that we use that in the builds .... so we've just been sticking with older GCC that support that. Cheers, Sylvain From laforge at gnumonks.org Thu Sep 7 19:40:30 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 7 Sep 2017 21:40:30 +0200 Subject: Osmocombb on Ubuntu 16.04 In-Reply-To: References: <0E79A3A0-7F68-44B8-8204-D48ABFB1EA44@gnumonks.org> <00a140a8-5220-d982-1b0b-df8fb16c1c63@sysmocom.de> Message-ID: <20170907194030.32wmynblxqpqc2md@nataraja> On Thu, Sep 07, 2017 at 09:27:27PM +0200, Sylvain Munaut wrote: > >> arm-none-eabi-ld: section .text.exceptions VMA [0080001c,00800037] > >> overlaps section .compal.reservedram VMA [00800000,008000fe] > > Yeah, IIRC the issue is that the newer GCC can't have overlapping > regions even if they're NOLOAD. Problem is that we use that in the > builds .... so we've just been sticking with older GCC that support > that. See also the laforge/lib-update branch where I tried to fix this some months ago (but never completed related work), specifically commit 4de980b32c09dc0697f8f84302b646d48cdbef28 Author: Harald Welte Date: Sun Jan 15 16:49:06 2017 +0100 WIP: Attempt to make linker scripts compatible with binutils 2.27 In binutils-2.27, one can no longer have linker sections with overlapping VMA addresses. Let's try to work around this. See https://osmocom.org/issues/1917 for more details. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Fri Sep 8 12:30:05 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 8 Sep 2017 15:30:05 +0300 Subject: GAPK status update Message-ID: Dear Osmocom community, I have been working on GAPK (GSM Audio Packet Knife) for some time, and now I would like to share some achievements. Previously GAPK was represented as a single binary that could be called with some command line arguments in order to perform required operations. This is only handy for humans, but not for other programs, which may also need to perform some format / codec conversations or audio capture / playback. One of such programs is the mobile from OsmocomBB project. Currently, when you're making a voice call, both audio capture and playback are only possible on the L1 side, i.e. on a Calypso based phone. Of course, the audio stream can be redirected via MNCC socket, but this is not what a regular OsmocomBB user would like to do. Moreover, there is a lack of AMR codec support. Also, there is another GNURadio based project named GR-GSM. In short, this is a set of blocks for GSM signal reception, demodulation and further processing. At the moment, one has TCH Full Rate decoding capabilities only. Audio playback is not supported yet. Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects. Brief list of changes were made: - Composed a shared library named libosmogapk - All exposed symbols have got an 'osmo_gapk' prefix - Added a pkg-config manifest and a symbol export map - Integrated the Osmocom logging framework - Benchmarking is now disabled by default - Processing queue now based on the linuxlist - Fixed program exit due to ALSA buffer underrun - Fixed ALSA audio playback from file - Old gapk application was renamed to 'osmo-gapk' and linked against the library - Adjusted verbosity level (normal / debug) - Fixed I/O combinations (ALSA, RTP, file...) check All changes could be found at the fixeria/lib branch of GAPK. I hope to see them merged, and open for discussions ;) With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Sep 8 13:16:34 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 8 Sep 2017 15:16:34 +0200 Subject: GAPK status update In-Reply-To: References: Message-ID: <20170908131634.fahl5vqfb7gpdudr@nataraja> Hi Vadim, On Fri, Sep 08, 2017 at 03:30:05PM +0300, Vadim Yanitskiy wrote: > Having these projects in my mind, I have got an idea of > creating a shared library from the GAPK source code. And, > a few days ago I was managed to get the audio playback > working in OsmocomBB. I hope, this library will be also > usable for other projects. I like this very much. Actually, this could even be used by something like the new osmo-mgw to have more or less generic transcoding capabilities for gsm-related codecs as well as PCM / G.711. comments: * the new introduced memory allocation could have been done via talloc, but since it's just for the non-standard benchmarking case, calloc is ok. * it would be nice to convert all allocations to talloc, like in other osmo-* code. This facilitates memory leak debugging. * rather than listing all symbols individually, you can also simply export osmo_gapk_* with a wilcard. All non-exported symbols then have to avoid that prefix. I prefer this to long lists of symbols that you often forget to update when adding new functions * assuming you have multiple processing queues in a program in the future, each queue should have a user-settable identifier which is then used as a prefix in all the logging. Finally, as a personal wishlist item, I would love to see some unit tests that create a couple of processing queues, destroy them, check if the resulting encode/decodes is what was expected, and [if possible?] even check if allocated memory has been properly cleaned up during destruction of the processing queue. Let's see what Sylvain has to say about all of this, it's his creation after all :) 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 axilirator at gmail.com Sun Sep 10 13:52:55 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 10 Sep 2017 16:52:55 +0300 Subject: GAPK status update In-Reply-To: <20170908131634.fahl5vqfb7gpdudr@nataraja> References: <20170908131634.fahl5vqfb7gpdudr@nataraja> Message-ID: Hi Harald, > I like this very much. Actually, this could even be used by > something like the new osmo-mgw to have more or less > generic transcoding capabilities for gsm-related codecs > as well as PCM / G.711. Thanks for your response! Hope my recent commits would help to move this forward. > * it would be nice to convert all allocations to talloc, like in other > osmo-* code. This facilitates memory leak debugging. > * rather than listing all symbols individually, you can also simply > export osmo_gapk_* with a wilcard. All non-exported symbols then > have to avoid that prefix. I prefer this to long lists of symbols > that you often forget to update when adding new functions > * assuming you have multiple processing queues in a program in the > future, each queue should have a user-settable identifier which is > then used as a prefix in all the logging. Done. Only libgsmhr do use generic malloc / free calls. And I think there is no reason to link this library against talloc as there is only one allocation / deallocation cycle. BTW: what about the 'laforge/mmx' branch? Does anything prevents us from merging it to the master? > Finally, as a personal wishlist item, I would love to see some unit > tests that create a couple of processing queues, destroy them, check > if the resulting encode/decodes is what was expected, and [if possible?] > even check if allocated memory has been properly cleaned up during > destruction of the processing queue. Yeah, I have this idea too. But I don't have enough time right now. Will do it as soon as it will be possible. What do you think about adding GAPK to Gerrit? Regarding to the proper memory deallocation check, I think it should be possible via the talloc debugging API. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olegtsss at mail.ru Sun Sep 10 16:26:54 2017 From: olegtsss at mail.ru (=?UTF-8?B?0J7Qu9C10LMg0KHRg9Cy0L7RgNC+0LI=?=) Date: Sun, 10 Sep 2017 19:26:54 +0300 Subject: =?UTF-8?B?aGVscCBtZSBvc21vY29tQkI=?= Message-ID: <1505060814.319370589@f504.i.mail.ru> Can you help me? -------- ???????????? ????????? -------- ?? ????: ???? ??????? ????: baseband-devel ????: ???????, 1 ???????? 2017, 18:28 +06:00 ????: help me Hello, I am from Russia, can you help me with Filter Replacement! I have to mobile, Motorolla C115 and C118. I was bye all elements to make filter replacement. Motorolla C115 look like your instruction and I was done filter replacement. Motorolla C115 nice work after it. But Motorolla C118 don`t look like in your instruction. I read:? "Different circuit Sometimes the input (at the bottom of the balun) is not with caps in series and a resistor in parallel. Instead it might be without the resistors in parallel and resistors in series. Remove the resistors and place 2x the appropriate cap in series (22 pF for GSM90, 15 pF for DCS1800". But I don`t understand what I must do. I do like my picture (?118_2.jpg), but after it Motorolla don`t work: No signal from Network. Can you help me? With Best Regards, Oleg Syvorov ---------------------------------------------------------------------- ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From testtestphone8 at gmail.com Mon Sep 11 07:19:58 2017 From: testtestphone8 at gmail.com (Testphone Test) Date: Mon, 11 Sep 2017 11:19:58 +0400 Subject: OpenBSC and OsmocomBB Message-ID: Dear List I am trying to run osmocomBB with motorola c118 with openbsc.I tried to get openbsc network on my phone it works well and I am able to register on openbsc network. But when i try to run osmocomBB with openBSC i am not able to get network. Also when i run rssi firmware on c118 phone i get network and its working fine. I am using default configuration file for OpenBSC and using NanoBTS with 1800Mhz support. Is there any configuration change is needed in openBSC ? Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Mon Sep 11 08:51:44 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 11 Sep 2017 11:51:44 +0300 Subject: OpenBSC and OsmocomBB Message-ID: Hi, Probably, the problem is related to https://osmocom.org/issues/1458 In short, a phone is unable to sync a strong BTS due to the ADC input overload. As a quick solution, you can use the 'stick ARFCN' option in 'mobile.cfg'. This helped me when a phone was pretty close to my BTS. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From testtestphone8 at gmail.com Mon Sep 11 08:58:45 2017 From: testtestphone8 at gmail.com (Testphone Test) Date: Mon, 11 Sep 2017 12:58:45 +0400 Subject: OpenBSC and OsmocomBB In-Reply-To: References: Message-ID: Thanks for reply I tried running with Stick Option. but still I am unable to do so. Also why its working properly in rssi firmware app. can you somehow change this behavior of phone somehow. On 11 September 2017 at 12:51, Vadim Yanitskiy wrote: > Hi, > > Probably, the problem is related to https://osmocom.org/issues/1458 > In short, a phone is unable to sync a strong BTS due to the ADC > input overload. > > As a quick solution, you can use the 'stick ARFCN' option in 'mobile.cfg'. > This helped me when a phone was pretty close to my BTS. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: