osmocom-sdr April 2020

osmocom-sdr@lists.osmocom.org

8 participants
6 discussions

Start a nNew thread

gr-osmosdr: add clock_source= parameter

by Michael Loeffler

Hello, the attached patch allows to set the clock_source on uhd devices in programs like gqrx. Bye

4 years, 6 months

[PATCH] Loop in soapy_source_c::work() when readStream() returns SOAPY_SDR_OVERFLOW

by Anton Blanchard

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 <anton(a)ozlabs.org> --- 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

5 years, 4 months

PS Name and PI code modification

by Marco Domenico Cimato

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

5 years, 5 months

Bug in rtl_sdr

by John Tiller

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

5 years, 6 months

OSMOCOM TRX_BTS_BSC Connection Issue

by Aalto Koskinen

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@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'

5 years, 6 months

RTL-SDR Installation on Ubuntu 18.04

by Jenrica Decafe

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

5 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr April 2020