Dear all,
I found that the fix for the USB issue on ARM systems has finally made
it into the Linux kernel, 5.6.14 and 5.7-rc6. Today I installed the
latest Manjaro 64 unstable mainline kernel on my rpi4 and made some
quick tests with fl-wspr (https://github.com/tejeez/fl2k-tool).
There are no more USB errors*, but I still get underflow errors at high
sample rates. In my quick tests the maximum reliable sample rate was about
20 MHz when running in an X session with other programs. When I
stopped the X server and ran in a text console I could go above 30 MHz
without underflows.
This means that the rpi4 is fine as an SDR transceiver for many
purposes- but it would be nice to know if it is possible to tune the
system for a bit higher sample rates!
All the best
SM2YHP Fredrik
* Installed AUR package libosmo-fl2k-git to fix other USB
device issues
--
------------------
Carl-Fredrik Enell
Föraregatan 26B
SE-98139 Kiruna
+46705508256
-----------------
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
Hello,
I am working on making a binary format for rtl_power to save space on
my server for observing the spectrum. I am wondering if anyone else would
be interested in this idea.
I am hoping keep the same format in terms of how the data is organized in
the file but instead of using text use some form of binary format. For
example for the date and time I think using a unix epoch timestamp would
work.
I am hoping to receive any comments or criticism.
Thanks, KD9KCK