From aaltokoskinen at gmail.com Thu Apr 2 15:00:14 2020 From: aaltokoskinen at gmail.com (Aalto Koskinen) Date: Thu, 2 Apr 2020 18:00:14 +0300 Subject: OSMOCOM TRX_BTS_BSC Connection Issue Message-ID: Hi, I looked at the forum for answers before posting, but I unfortunately couldn't get answers to what I was looking for. I looked into particular https://www.mail-archive.com/openbsc at lists.osmocom.org/msg09819.html for solving my issue. Issue: I cannot connect BTS,TRX and BSC. The other modules of the network are able to connect to each other. I have the RSP POWEROFF message originating in log from TRX-UHD module and the BTS module is shuttiing down. BTS connects via OML but fails to connect RSL. I looked through the configuration files and seem correct to me. As per the previous email archive, I wanted to login to VTY and check the logs, but, it logs out as the BTS module shuts down (I cannot connect and see what's happening). Any suggestions would be appreciated on solving the issue. I am trying to create a test 2G OSMOCOM network. Logs are written below and configuration as attachments. Thanks for your help! *OSMO_BTS_TRX log:* systemd[1]: Started Osmocom osmo-bts for osmo-trx. osmo-bts-trx[23221]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238 osmo-bts-trx[23221]: <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 osmo-bts-trx[23221]: <0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting to 192.168.0.9:3002 osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason Abis close osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: Shutdown timer expired osmo-bts-trx[23221]: ((*)) osmo-bts-trx[23221]: | osmo-bts-trx[23221]: / \ OsmoBTS *OSMO_TRX_UHD log:* osmo-trx-lms[7995]: DTRXCTRL <0001> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF' osmo-trx-lms[7995]: DTRXCTRL <0001> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF 0' -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bsc.cfg Type: application/octet-stream Size: 1206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-trx-uhd.cfg Type: application/octet-stream Size: 390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts-trx.cfg Type: application/octet-stream Size: 600 bytes Desc: not available URL: From fgugliuzza.mail at gmail.com Thu Apr 9 12:12:06 2020 From: fgugliuzza.mail at gmail.com (Francesco Gugliuzza) Date: Thu, 9 Apr 2020 14:12:06 +0200 Subject: RTL-SDR Installation on Ubuntu 18.04 In-Reply-To: References: Message-ID: Hi Jenrica, you have to install the RTL-SDR library first ( http://cgit.osmocom.org/rtl-sdr/), then the Osmocom GNU Radio source ( https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR). Have a nice day! Francesco Il giorno mar 7 apr 2020 alle ore 20:57 Jenrica Decafe ha scritto: > Good day! I am Jenrica from the Philippines and I am currently developing > a low-cost SDR ground radio receiver for L/S band satellites. I personally > emailed you to ask for your build steps for rtlsdr on gnu radio > installation (ubuntu 18.04). I have tried many ways already but I still > can't find the rtl-sdr source in the GRC. Your positive response is highly > appreciated. > > Thank you > -- Francesco Gugliuzza M.Sc. in Computer Engineering Ph.D. in Technological Innovation Engineering Qualified to practice as a Professional Engineer E-mail: fgugliuzza.mail at gmail.com PEC: francesco.gugliuzza at pec.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at osmocom.org Sat Apr 11 11:02:59 2020 From: laforge at osmocom.org (Harald Welte) Date: Sat, 11 Apr 2020 13:02:59 +0200 Subject: OSMOCOM TRX_BTS_BSC Connection Issue In-Reply-To: References: Message-ID: <20200411110259.GH4127396@nataraja> Hi Aalto, On Thu, Apr 02, 2020 at 06:00:14PM +0300, Aalto Koskinen wrote: > Issue: I cannot connect BTS,TRX and BSC. The other modules of the network > are able to connect to each other. [...] this is the osmocom-sdr mailing list which is intended for projects like gr-osmosdr and rtl-sdr. Your question should be raiased on the openbsc at lists.osmocom.org mailing list. 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 anton at ozlabs.org Wed Apr 15 12:38:13 2020 From: anton at ozlabs.org (Anton Blanchard) Date: Wed, 15 Apr 2020 22:38:13 +1000 Subject: [PATCH] Loop in soapy_source_c::work() when readStream() returns SOAPY_SDR_OVERFLOW Message-ID: <20200415223813.41a6399b@kryten.localdomain> I'm using an Airspy HF+ Discovery with the Soapy driver. Whenever I turn AGC off it stops receiving samples. On closer inspection, switching AGC off results in samples stalling for an extended period (hundreds of milliseconds). As such, we hit the timeout in SoapyAirspyHF::readStream() and return SOAPY_SDR_TIMEOUT (-1). Things go wrong at this point. It takes a long time before readStream() is called again, presumably because we returned 0 from work(). By this time our buffers have overflown, readStream() returns SOAPY_SDR_OVERFLOW (-2) and work() returns 0. We loop forever, continually overflowing buffers. Fix this by looping in soapy_source_c::work() when ->readStream() returns SOAPY_SDR_OVERFLOW so that we consume the buffers straight away. Signed-off-by: Anton Blanchard --- lib/soapy/soapy_source_c.cc | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/lib/soapy/soapy_source_c.cc b/lib/soapy/soapy_source_c.cc index a645361..9dcc885 100644 --- a/lib/soapy/soapy_source_c.cc +++ b/lib/soapy/soapy_source_c.cc @@ -96,9 +96,13 @@ int soapy_source_c::work( int noutput_items, { int flags = 0; long long timeNs = 0; - int ret = _device->readStream( - _stream, &output_items[0], - noutput_items, flags, timeNs); + int ret; + + do { + ret = _device->readStream( + _stream, &output_items[0], + noutput_items, flags, timeNs); + } while (ret == SOAPY_SDR_OVERFLOW); if (ret < 0) return 0; //call again return ret; -- 2.25.2 From laforge at osmocom.org Wed Apr 15 13:46:55 2020 From: laforge at osmocom.org (Harald Welte) Date: Wed, 15 Apr 2020 15:46:55 +0200 Subject: [PATCH] Loop in soapy_source_c::work() when readStream() returns SOAPY_SDR_OVERFLOW In-Reply-To: <20200415223813.41a6399b@kryten.localdomain> References: <20200415223813.41a6399b@kryten.localdomain> Message-ID: <20200415134655.GI4127396@nataraja> Hi Anton, long time no see! Thanks for your patch. Looks fine to me. Anyone here on the list interested in trying/tetsing the patch? 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 246tnt at gmail.com Wed Apr 15 14:30:56 2020 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 15 Apr 2020 16:30:56 +0200 Subject: [PATCH] Loop in soapy_source_c::work() when readStream() returns SOAPY_SDR_OVERFLOW In-Reply-To: <20200415134655.GI4127396@nataraja> References: <20200415223813.41a6399b@kryten.localdomain> <20200415134655.GI4127396@nataraja> Message-ID: > long time no see! Thanks for your patch. Looks fine to me. Looks to me like this has the potential to just hang and prevent the thread from terminating. This needs bounds. One retry is fine, infinite ones not so much. Cheers, Sylvain From anton at ozlabs.org Wed Apr 15 23:30:31 2020 From: anton at ozlabs.org (Anton Blanchard) Date: Thu, 16 Apr 2020 09:30:31 +1000 Subject: [PATCH] Loop in soapy_source_c::work() when readStream() returns SOAPY_SDR_OVERFLOW In-Reply-To: References: <20200415223813.41a6399b@kryten.localdomain> <20200415134655.GI4127396@nataraja> Message-ID: <20200416093031.2b07f1e6@kryten.localdomain> Hi Sylvain, > Looks to me like this has the potential to just hang and prevent the > thread from terminating. > This needs bounds. One retry is fine, infinite ones not so much. Good idea, how does this look? Anton -- I'm using an Airspy HF+ Discovery with the Soapy driver. Whenever I turn AGC off it stops receiving samples. On closer inspection, switching AGC off results in samples stalling for an extended period (hundreds of milliseconds). As such, we hit the timeout in SoapyAirspyHF::readStream() and return SOAPY_SDR_TIMEOUT (-1). Things go wrong at this point. It takes a long time before readStream() is called again, presumably because we returned 0 from work(). By this time our buffers have overflown, readStream() returns SOAPY_SDR_OVERFLOW (-2) and work() returns 0. We loop forever, continually overflowing buffers. Fix this by looping in soapy_source_c::work() when ->readStream returns SOAPY_SDR_OVERFLOW so that we consume the buffers straight away. Signed-off-by: Anton Blanchard --- lib/soapy/soapy_source_c.cc | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/soapy/soapy_source_c.cc b/lib/soapy/soapy_source_c.cc index a645361..5c683c9 100644 --- a/lib/soapy/soapy_source_c.cc +++ b/lib/soapy/soapy_source_c.cc @@ -96,9 +96,14 @@ int soapy_source_c::work( int noutput_items, { int flags = 0; long long timeNs = 0; - int ret = _device->readStream( - _stream, &output_items[0], - noutput_items, flags, timeNs); + int ret; + int retries = 1; + + do { + ret = _device->readStream( + _stream, &output_items[0], + noutput_items, flags, timeNs); + } while (retries-- && (ret == SOAPY_SDR_OVERFLOW)); if (ret < 0) return 0; //call again return ret; -- 2.25.2 From marco.cimato at gmail.com Sat Apr 25 11:04:53 2020 From: marco.cimato at gmail.com (Marco Domenico Cimato) Date: Sat, 25 Apr 2020 13:04:53 +0200 Subject: PS Name and PI code modification Message-ID: Hi everyone, thanks in advance for the support, where I can modify the subject value. I have found the variable inside rds_mod.c but I didn't find anywhere they are set. The request is made because seems the windows binaries has them but they were set and compiled or it's me that I didn't find where they are? Kind regards, Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Sat Apr 25 11:11:23 2020 From: steve at steve-m.de (Steve Markgraf) Date: Sat, 25 Apr 2020 13:11:23 +0200 Subject: PS Name and PI code modification In-Reply-To: References: Message-ID: <017880bb-f966-ba96-30dd-2bb3de273155@steve-m.de> Hi, On 25.04.20 13:04, Marco Domenico Cimato wrote: > thanks in advance for the support, where I can modify the subject value. > I have found the variable inside rds_mod.c but I didn't find anywhere > they are set. > The request is made because seems the windows binaries has them but they > were set and compiled or it's me that I didn't find where they are? They are hardcoded here: https://cgit.osmocom.org/osmo-fl2k/tree/src/fl2k_fm.c#n581 Should be quite easy to add commandline options to override them if needed, feel free to submit a patch. Regards, Steve From tillerja at gmail.com Tue Apr 14 05:01:50 2020 From: tillerja at gmail.com (John Tiller) Date: Tue, 14 Apr 2020 05:01:50 -0000 Subject: Bug in rtl_sdr Message-ID: <19ea7f42-6085-b6aa-7c3e-33650cfc4fc8@gmail.com> I believe there is a bug in rtl_sdr.c at lines 89 and 242.? When bytes_to_read == len (or n_read), then bytes_to_read becomes 0 at lines 101 and 258 and the read never terminates since 0 means infinite read. I believe the fix is to change lines 89 and 242 to read: if ((bytes_to_read > 0) && (bytes_to_read <= len)) { // Versus bytes_to_read < len if ((bytes_to_read > 0) && (bytes_to_read <= (uint32_t)n_read)) { // Likewise John Tiller