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