Hi Martin, hi Community,
first of all: thanks for all the fish err GREPs! We need to kick off
this discussion.
So, this PR is very dear to my heart, because I consider log4cpp to be
an especially problematic dependency.
And I consider our logging to be subpar considering the size of the
code base, user base and the fact that people are using GNU Radio in
infrastructure for rather expensive things.
So, I took the opportunity (being at 35c3, just to pose around a little
bit) and talked to a couple Osmocom folks. Osmocom people, please
correct me if I make any mistakes.
What they have in osmocore is essentiall logging in both quantized
severity and in categories, and logging routing.
For them, that's very important, as they use that to supply resilient
infrastructure. I hope I'm representing the idea kinda correctly here:
They might want to log system events ("SUPERVISOR: INFO system load
surpassing 75%") somewhere, and development info ("gr-6G: TRACE found a
preamble") on-screen, and critical messages ("gr-digital: FATAL run out
of developer coffee") everywhere.
I want that too. I want this to be easily integratable into software
that uses GNU Radio as library. And if I'm already making wishes here,
I want loggers that interface to modern logging systems, be it
journald, graylog or SNMP. Something.
So, I think that's pretty similar to what UHD does (correct me please,
Martin). I think that UHD is a bit more flexible on the logging
"categories" than I'd like to be, but that really just means we need to
set a convention.
So, I'm stuck wondering whether we adopt the self-implemented system
that UHD uses, or the self-implemented system that osmocore uses, or
implement our own.
Familiarity suggests UHD, maturity osmocore.
Best regards,
Marcus
On Thu, 2018-12-27 at 13:49 -0800, Martin Braun wrote:
> This GREP was recently submitted here:
>
>
https://github.com/gnuradio/greps/blob/master/grep-0013-remove-log4cpp.md
>
> We may or may not go through with this. However, we like to kill
> dependencies (hey there node.js developers :D ), and log4cpp has some
> issues of its own that we're currently inheriting.
>
> Personally, I use GR logging only for debugging purposes. But I know
> that others use it for other reasons, and this thread is a good place
> to discuss:
> - Alternatives to log4cpp (I've listed Boost.Log and hand-spun as
> options)
> - What people need it for
> - Is the current logging in a good shape as it is
> - Who wants to own this task?
> - etc.
>
> Cheers,
> Martin
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio(a)gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hello! I made SDR server on my android TV BOX. WOrks great! (by ethernet!). I am connecting to RTL SDR v3 dongle via network from my windows pc running sdr sharp!
Could you say, how can i automate server starting? Because every time i disconnect sdr sharp (on my pc), i should turn connect display to android box and click START STREAM button. It would be great if it possible to make sdr server independent with no need to start ir every time.
Youre server and driver are great!
--
Sincerely,
Max Semashko
Hello, I hope this is the correct list to ask this question.
I have an SDR-IQ connected via USB to Ubuntu 18.04 and version 3.7.13.4
GNU Radio. I am getting data from the source at correct center
frequency and sampling rate, however ...
I am having trouble find 3 of 4 gain controls.
I believe these to be the settings affecting the device gain:
1. RF Gain: -20, -10, 0, 10 dB. These I can successfully change via
the RF Gain setting in the Osmocom source. It's good!
2. IF Gain: 24, 18, 12, 6, and 0 dB. This is a "digital gain" and
changes a coefficient of the "6620 Digital Downconverter", which
apparently is hardware in the SDR-IQ which does filtering and
decimation.
3. Preamp Gain, via a "GN Code" of range 0-127, which goes from Off,
and then a range of -8.08 to 34 dB.
4. A step attenuator with 0 and 10 dB settings.
I got the above by examining the "SpectraVue" Windows application for
the SDR-IQ provided by RFSpace.
#1 is no problem, it works. What about 2, 3, and 4?
So is there any hope of controlling these settings with the osmocom
source?
Regards,
Greg R
So I wanted to compile gr-osmosdr from source. I created a build
directory and I ran `cmake ..` and then `make`.
These are the errors I got:
```
[ 57%] Linking CXX shared library libgnuradio-osmosdr-0.1.5git.so
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o: in function `_GLOBAL__sub_I_source_impl.cc':
source_impl.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: source_impl.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o: in function `_GLOBAL__sub_I_sink_impl.cc':
sink_impl.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: sink_impl.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/device.cc.o: in function `_GLOBAL__sub_I_device.cc':
device.cc:(.text.startup+0x60): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: device.cc:(.text.startup+0x67): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/osmosdr/osmosdr_src_c.cc.o: in function `_GLOBAL__sub_I_osmosdr_src_c.cc':
osmosdr_src_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: osmosdr_src_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o: in function `_GLOBAL__sub_I_file_source_c.cc':
file_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: file_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/file/file_sink_c.cc.o: in function `_GLOBAL__sub_I_file_sink_c.cc':
file_sink_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: file_sink_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o: in function `_GLOBAL__sub_I_rtl_source_c.cc':
rtl_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: rtl_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o: in function `_GLOBAL__sub_I_rtl_tcp_source_c.cc':
rtl_tcp_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: rtl_tcp_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/uhd/uhd_sink_c.cc.o: in function `_GLOBAL__sub_I_uhd_sink_c.cc':
uhd_sink_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: uhd_sink_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/uhd/uhd_source_c.cc.o: in function `_GLOBAL__sub_I_uhd_source_c.cc':
uhd_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: uhd_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/miri/miri_source_c.cc.o: in function `_GLOBAL__sub_I_miri_source_c.cc':
miri_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: miri_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/hackrf/hackrf_source_c.cc.o: in function `_GLOBAL__sub_I_hackrf_source_c.cc':
hackrf_source_c.cc:(.text.startup+0x58): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: hackrf_source_c.cc:(.text.startup+0x5f): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/hackrf/hackrf_sink_c.cc.o: in function `_GLOBAL__sub_I_hackrf_sink_c.cc':
hackrf_sink_c.cc:(.text.startup+0x58): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: hackrf_sink_c.cc:(.text.startup+0x5f): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/bladerf/bladerf_source_c.cc.o: in function `_GLOBAL__sub_I_bladerf_source_c.cc':
bladerf_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: bladerf_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/bladerf/bladerf_sink_c.cc.o: in function `_GLOBAL__sub_I_bladerf_sink_c.cc':
bladerf_sink_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: bladerf_sink_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/rfspace/rfspace_source_c.cc.o: in function `_GLOBAL__sub_I_rfspace_source_c.cc':
rfspace_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: rfspace_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/airspy/airspy_source_c.cc.o: in function `_GLOBAL__sub_I_airspy_source_c.cc':
airspy_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: airspy_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/soapy/soapy_source_c.cc.o: in function `_GLOBAL__sub_I_soapy_source_c.cc':
soapy_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: soapy_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/soapy/soapy_sink_c.cc.o: in function `_GLOBAL__sub_I_soapy_sink_c.cc':
soapy_sink_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: soapy_sink_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/redpitaya/redpitaya_source_c.cc.o: in function `_GLOBAL__sub_I_redpitaya_source_c.cc':
redpitaya_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: redpitaya_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/redpitaya/redpitaya_sink_c.cc.o: in function `_GLOBAL__sub_I_redpitaya_sink_c.cc':
redpitaya_sink_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: redpitaya_sink_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/freesrp/freesrp_source_c.cc.o: in function `_GLOBAL__sub_I_freesrp_source_c.cc':
freesrp_source_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: freesrp_source_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
/usr/bin/ld: CMakeFiles/gnuradio-osmosdr.dir/freesrp/freesrp_sink_c.cc.o: in function `_GLOBAL__sub_I_freesrp_sink_c.cc':
freesrp_sink_c.cc:(.text.startup+0x54): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
/usr/bin/ld: freesrp_sink_c.cc:(.text.startup+0x6b): undefined reference to `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
collect2: error: ld returned 1 exit status
make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:555: lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0] Error 1
make[1]: *** [CMakeFiles/Makefile2:141: lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
```
As you can see, all error messages refer to the same reference to a
log4cpp appender function.
I have log4cpp version 1.1.3 installed by my package manager on Arch
Linux. It is installed in /usr/lib. It seems like a missing library in
CMakeLists.txt . Am I correct?
Thanks for creating this software.
Error Message in osmocom_spectrum_sense command line tool:
tune: Exception: global name 'time' is not defined
Undefined command: "tune", Try "help"
Simple fix for the osmocom_spectrum_sense utility, the message queue is
really good at clearing itself, but for low tune/dwell delays the
threads need to sleep while it clears.
---
apps/osmocom_spectrum_sense | 1 +
1 file changed, 1 insertion(+)
diff --git a/apps/osmocom_spectrum_sense b/apps/osmocom_spectrum_sense
index ea365bb..0d280bd 100755
--- a/apps/osmocom_spectrum_sense
+++ b/apps/osmocom_spectrum_sense
@@ -30,6 +30,7 @@ from gnuradio.eng_option import eng_option
from optparse import OptionParser
import sys
import math
+import time
import struct
import threading
from datetime import datetime
--
2.19.1
Hi,
I encountered this strange behavior when running fl2k_test on Windows 7:
basically after a while the sample rate drifts and speeds up considerably.
Sometimes it even starts up directly like that.
In the command prompt I get:
C:\Users\Francesco
Gugliuzza\Downloads\Sviluppo\FL2000fl2k_win_2018-08-09>fl2k_test.exe -s
138e6
Reporting PPM error measurement every 10 seconds...
Press ^C after a few minutes.
real sample rate: 146656386 current PPM: 62727 cumulative PPM: 62727
real sample rate: 150803676 current PPM: 92780 cumulative PPM: 77858
real sample rate: 149716182 current PPM: 84900 cumulative PPM: 80218
real sample rate: 150107883 current PPM: 87738 cumulative PPM: 82104
real sample rate: 150526750 current PPM: 90774 cumulative PPM: 83843
The same thing happens if I compile the latest osmo-fl2k myself using
Cygwin.
I'm running everything on a laptop with an i7 4710HQ CPU and 8 GB of ram,
and I'm using a RayCue HDMI+VGA box.
Do you have an idea why the real sample rate drifts so much?
Thanks!
--
Francesco Gugliuzza
I have a rtl_sdr.com RTL2832U R820T2 dongle. It works with HDSDR and SDRSHARP programs.
Using win10 64 BIT 10.0.17134.345 and GNURadio 3.7.13.4/V1.5Windows reports VID_0BDA, PID_2838
When I run GNUradio, I get [R82XX] PLL not locked!
When I open the GNUradio command prompt and run rtl_test -t, I get this:
setting gnuradio environmentMicrosoft Windows [Version 10.0.17134.345]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Program Files\GNURadio-3.7\bin>rtl_test -t
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.
C:\Program Files\GNURadio-3.7\bin>
At this page, https://osmocom.org/projects/rtl-sdr/wiki/Rtl-sdr shows this table :
VID PID tuner device name
0x0bda 0x2832 all of them Generic RTL2832U (e.g. hama nano) 0x0bda 0x2838 E4000 ezcap USB 2.0 DVB-T/DAB/FM dongle
Is it possible RTL_TEST is looking for a E4000 because of it's dongle's screwy PID, even though it sees a R820T. If not, why is it not working?thanks.
| | Virus-free. www.avast.com |
Hello,
For my purposes in GNU Radio using the osmocom source block i would like to
disable the internal AGC in my AirSpy HF+. I see that i can choose the
"Gain Mode" setting, however i am not sure that will disable (when set to
manual) the AGC on the AirSpy HF+.
Do you know of any good way to achieve this?
I have installed the following library for the AirSpy HF+, where there is
an API which enables you to disable the AGC, however i am not sure how to
achieve this in GNU Radio:
https://github.com/airspy/airspyhf
*$airspyhf_info*
AirSpy HF library version: 1.4.2
S/N: "removed"
Part ID: 0x00000001
Firmware Version: R1.7.2
Available sample rate: 768 kS/s
*$uname -a*
Linux hedric-dev 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Hopefully this is enough information for you, otherwise let me know.
Kind regards,
Richard
Dear all,
I am confused about some parameters of osmocom fft spectrum analyzer.
I am wonder what exactly the vertical axis shows? It is written Power(dB); if so, what is the reference power? Is it 1dBW?
Moreover, by changing the PGA Gain, I will have different values of power (dB). What is the relation between PGA gain and the received power in dBm?
In general, does anyone know how should I find the received power in dBm, having the PGA gain(dB) and the value on vertical axis. (Picture in attach)
Looking forward to your reply.
Bests,
--
--
Le informazioni contenute nella presente comunicazione sono di natura
privata e come tali sono da considerarsi riservate ed indirizzate
esclusivamente ai destinatari indicati e per le finalità strettamente
legate al relativo contenuto. Se avete ricevuto questo messaggio per
errore, vi preghiamo di eliminarlo e di inviare una comunicazione
all’indirizzo e-mail del mittente.
--
The information transmitted is
intended only for the person or entity to which it is addressed and may
contain confidential and/or privileged material. If you received this in
error, please contact the sender and delete the material.
I've been trying to get some RTL-SDRs to function properly on my
Tinkerboard, running Armbian Bionic, Kernel 4.14y. I noticed that with the
Osmocom drivers rtl_test would result in huge sample drops (millions of
samples dropped each time). However, Keenerds branch did not drop any
samples, nor did the presumably older Osmocom drivers from apt-get.
I did a diff against Keenerds and discovered the new zerocopy buffer code
in the Osmocom drivers. After commenting that out, the Osmocom drivers work
fine on the Tinkerboard with Armbian and there is no sample loss.
Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run
Kernel 4.4, I do not get sample loss with the Osmocom drivers and the
zerocopy code enabled.
I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which is
also running Kernel 4.14, and on Raspbian, and on those there is no sample
loss. So it seems to be something specific to the Tinkerboard and Armbian
with Kernel 4.14y.
Not sure if the zerocopy code is just not getting activated on those other
OSes or what. How do I check if the installed libusb API version is >=
0x01000105?
Any ideas what could cause the zero copy code to result in the lost samples?
Regards,
Carl Laufer
Michael Auß <michael.auss(a)gmail.com> writes:
> I did encounter problems with syntax errors when compiling with clang, see
> OS#3663 for details. (Relating to rtl_tcp)
>
> I did not add something to the README.
I can certainly believe you had errors. But, changing the compiler
requirement is significant -- particularly on platforms that don't have
last week's compiler -- and if it isn't the plan to require C++14, then
it seems like a workaround to enable that. My point really is that
there should be a decision about the language, that should be in the
README, and the build system should set --std for that chosen language,
and then whatever needs to be fixed should be fixed.
(I am one of several who look after ham/gnuradio stuff in pkgsrc.)
In gr-osmosdr, it seems 0.1.4 is the most recently release, long ago.
The v0.1.4 tarball seems to build aginst gnuradio 3.7.
There is a gr3.6 branch that has both many commits more than and less
than the v3.6 tag. master has 127 commits beyond v0.1.4 but is not
missing any. This seems odd, as I would expect gr3.6 to be based on
some intermediate commit along the path from 0.1.4 to master.
So I am not following what is going on and why. Now that gnuradio 3.7
seems normal, it seems there should be a release based on master, and
there is no real reason for anyone to use the 3.6 branch (unless they
are on a system that is intentionally using old gnuradio).
Can somebody explain? With any luck I'm confused.
Greg
CC to mailing list
------- Weitergeleitete Nachricht ------
Von: Michael Auß <michael.auss(a)gmail.com>
Datum: Fr. 19. Okt. 2018 um 22:26
Betreff: Re: [PATCH] Related: OS#3663 Fix failed compilation on macOS
Mojave with clang in CMakeLists.txt
An: Greg Troxel <gdt(a)lexort.com>
I did encounter problems with syntax errors when compiling with clang, see
OS#3663 for details. (Relating to rtl_tcp)
I did not add something to the README.
KR
Michael
Greg Troxel <gdt(a)lexort.com> schrieb am Fr. 19. Okt. 2018 um 21:44:
> Michael Auß <michael.auss(a)gmail.com> writes:
>
> > Fix regarding the issue https://osmocom.org/issues/3663macOS Mojave
> > comes with clang but the binary matches by the name c++ instead of
> > clang.Additionally the compiler flag std=c++14 had to be added.
>
> I am surprised about c++14. Is it new that c++14 is required? Is it
> in the README?
>
> gr-osmosdr is at 0.1.4 in pkgsrc, which appears to be the latest
> official release on github. It's marked as needing "c++" which means
> 03, not 11, and not 14.
>
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
I encountered this strange behavior when running fl2k_test on Windows 7:
basically after a while the sample rate drifts and speeds up considerably.
Sometimes it even starts up directly like that.
In the command prompt I get:
C:\Users\Francesco
Gugliuzza\Downloads\Sviluppo\FL2000fl2k_win_2018-08-09>fl2k_test.exe -s
138e6
Reporting PPM error measurement every 10 seconds...
Press ^C after a few minutes.
real sample rate: 146656386 current PPM: 62727 cumulative PPM: 62727
real sample rate: 150803676 current PPM: 92780 cumulative PPM: 77858
real sample rate: 149716182 current PPM: 84900 cumulative PPM: 80218
real sample rate: 150107883 current PPM: 87738 cumulative PPM: 82104
real sample rate: 150526750 current PPM: 90774 cumulative PPM: 83843
The same thing happens if I compile the latest osmo-fl2k myself using
Cygwin.
I'm running everything on a laptop with an i7 4710HQ CPU and 8 GB of ram,
and I'm using a RayCue HDMI+VGA box.
Do you have an idea why the real sample rate drifts so much?
Thanks!
Francesco
--
Francesco Gugliuzza
M.Sc. in Computer Engineering
Ph.D. Student at DIID, Università degli Studi di Palermo
Qualified to practice as a Professional Engineer
E-mail: fgugliuzza.mail(a)gmail.com
PEC: francesco.gugliuzza(a)pec.it
Reproducible segfault apparently from race condition on my system in librtlsdr.
---
$ uname -r
4.14.67-1.pvops.qubes.x86_64
rtl-sdr and libusb are both current git master.
---
1. run librtlsdr under gdb
$ gdb --args rtl_sdr -f 43M -n 1000 /dev/null
2. place a breakpoint when the cancellation condition is hit,
currently line 1915
1914 if (RTLSDR_CANCELING == dev->async_status) {
1915
next_status = RTLSDR_INACTIVE;
1916
(gdb) break ./src/librtlsdr.c:1915
3. run and continue; segfault after second breakpoint
(gdb) run
(gdb) cont
(gdb) cont
Thread 1 "rtl_sdr" received signal SIGSEGV, Segmentation fault.
0x00007ffff7d76a15 in add_to_flying_list (transfer=0x426590) at
../../libusb/io.c:1396
1396 if (!timerisset(cur_tv) || (cur_tv->tv_sec >
timeout->tv_sec) ||
--
The crash appears to be because the transfers are deallocated while
they are still in flight, and then later referenced by libusb.
I think this happens because the pause gives the transfer time to
complete before it is canceled. The cancel then fails because the
transfer was completed, and the current code assumes this means it is
not in flight, when it actually hasn't been handled yet and will be
resubmitted.
The documentation for libusb_transfer::status at
http://libusb.sourceforge.net/api-1.0/structlibusb__transfer.html#a64b2e70e…
states that it is only correct to read the field from within the
callback handler, and the documentation for libusb_cancel_transfer at
http://libusb.sourceforge.net/api-1.0/group__asyncio.html#ga685eb7731f9a059…
states that the transfer
cancellation is only complete when the callback handler is called with
such status.
Although I imagine there are simpler solutions, I think the correct
solution would be to move cancellation of the transfers into the
callback handler entirely, to eliminate race conditions like this and
respect the libusb documentation. I would enjoy crafting a patch to
make such a change, if that would be helpful.
Karl Semich
1. _running is guarded with a lock in the rtl event loop epilogue.
this prevents a possible hang that could arise from _buf_cond
being notified prior to work() waiting on _buf_cond, but after
work() checks _running.
2. _buf_used is guarded with a lock in the work function to prevent
it from spuriously reading zero if it is nonatomically written
from the rtl event callback.
---
lib/rtl/rtl_source_c.cc | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc
index a371464..bbd0140 100644
--- a/lib/rtl/rtl_source_c.cc
+++ b/lib/rtl/rtl_source_c.cc
@@ -323,7 +323,11 @@ void rtl_source_c::rtlsdr_wait()
{
int ret = rtlsdr_read_async( _dev, _rtlsdr_callback, (void *)this, _buf_num, _buf_len );
- _running = false;
+ {
+ boost::mutex::scoped_lock lock( _buf_mutex );
+
+ _running = false;
+ }
if ( ret != 0 )
std::cerr << "rtlsdr_read_async returned with " << ret << std::endl;
@@ -347,7 +351,7 @@ int rtl_source_c::work( int noutput_items,
if (!_running)
return WORK_DONE;
- while (noutput_items && _buf_used) {
+ while (noutput_items) {
const int nout = std::min(noutput_items, _samp_avail);
const unsigned char *buf = _buf[_buf_head] + _buf_offset * 2;
@@ -363,6 +367,9 @@ int rtl_source_c::work( int noutput_items,
_buf_head = (_buf_head + 1) % _buf_num;
_buf_used--;
+
+ if (_buf_used == 0)
+ break;
}
_samp_avail = _buf_len / BYTES_PER_SAMPLE;
_buf_offset = 0;
--
2.11.0
Small change to work function to finish draining buffers
before closing when device disappears. Provides a little
more data when device is unexpectedly lost.
---
lib/rtl/rtl_source_c.cc | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc
index a371464..c0ba0b3 100644
--- a/lib/rtl/rtl_source_c.cc
+++ b/lib/rtl/rtl_source_c.cc
@@ -340,13 +340,18 @@ int rtl_source_c::work( int noutput_items,
{
boost::mutex::scoped_lock lock( _buf_mutex );
- while (_buf_used < 3 && _running) // collect at least 3 buffers
+ while (_buf_used < 3) // collect at least 3 buffers
+ {
+ if (!_running) {
+ // finish when remaining samples are drained
+ if (!_buf_used)
+ return WORK_DONE;
+ break;
+ }
_buf_cond.wait( lock );
+ }
}
- if (!_running)
- return WORK_DONE;
-
while (noutput_items && _buf_used) {
const int nout = std::min(noutput_items, _samp_avail);
const unsigned char *buf = _buf[_buf_head] + _buf_offset * 2;
--
2.11.0
From: Karl Semich <0xloem(a)gmail.com>
Previously overflow was handled by outputting "O" on stderr and
placing the extra data at the start of the buffer queue.
This had a number of issues:
- as only 1 buffer advanced on overflow, many overflows could occur in
sequence, as only small amounts of data was allowed to drain
- if the work function was partway through reading the head of the
queue, it would continue reading at the same offset from the new
head rather than from the start, causing extra loss of data
- buffer processing in work function is not guarded with a lock,
so it was possible for overflow to overwrite data while it was
being copied, resulting in garbage passed on
This patch rewrites overflow handling such that streaming is paused
until the work function can catch up. This resolves all 3 issues.
---
lib/rtl/rtl_source_c.cc | 32 ++++++++++++++++++++++++++------
lib/rtl/rtl_source_c.h | 2 ++
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc
index a371464..0d26831 100644
--- a/lib/rtl/rtl_source_c.cc
+++ b/lib/rtl/rtl_source_c.cc
@@ -48,6 +48,7 @@ using namespace boost::assign;
#define BUF_LEN (16 * 32 * 512) /* must be multiple of 512 */
#define BUF_NUM 15
#define BUF_SKIP 1 // buffers to skip due to initial garbage
+#define BUF_MIN 3 /* minimum buffers to run work function */
#define BYTES_PER_SAMPLE 2 // rtl device delivers 8 bit unsigned IQ data
@@ -87,8 +88,7 @@ rtl_source_c::rtl_source_c (const std::string &args)
_running(false),
_no_tuner(false),
_auto_gain(false),
- _if_gain(0),
- _skipped(0)
+ _if_gain(0)
{
int ret;
int index;
@@ -297,6 +297,9 @@ void rtl_source_c::rtlsdr_callback(unsigned char *buf, uint32_t len)
return;
}
+ if (_overflow)
+ return;
+
{
boost::mutex::scoped_lock lock( _buf_mutex );
@@ -304,8 +307,9 @@ void rtl_source_c::rtlsdr_callback(unsigned char *buf, uint32_t len)
memcpy(_buf[buf_tail], buf, len);
if (_buf_used == _buf_num) {
- std::cerr << "O" << std::flush;
- _buf_head = (_buf_head + 1) % _buf_num;
+ std::cerr << "OVERFLOW: rtl-sdr stream restarting after draining unread buffers" << std::endl;
+ _overflow = true;
+ rtlsdr_cancel_async( _dev );
} else {
_buf_used++;
}
@@ -321,7 +325,20 @@ void rtl_source_c::_rtlsdr_wait(rtl_source_c *obj)
void rtl_source_c::rtlsdr_wait()
{
- int ret = rtlsdr_read_async( _dev, _rtlsdr_callback, (void *)this, _buf_num, _buf_len );
+ int ret;
+
+ do {
+ {
+ boost::mutex::scoped_lock lock( _buf_mutex );
+ // let unread buffers from last run drain
+ while ( _buf_used >= BUF_MIN )
+ _work_cond.wait( lock );
+ }
+
+ _overflow = false;
+ _skipped = 0;
+ ret = rtlsdr_read_async( _dev, _rtlsdr_callback, (void *)this, _buf_num, _buf_len );
+ } while ( _overflow );
_running = false;
@@ -340,7 +357,7 @@ int rtl_source_c::work( int noutput_items,
{
boost::mutex::scoped_lock lock( _buf_mutex );
- while (_buf_used < 3 && _running) // collect at least 3 buffers
+ while (_buf_used < BUF_MIN && _running) // collect at least BUF_MIN buffers
_buf_cond.wait( lock );
}
@@ -364,6 +381,9 @@ int rtl_source_c::work( int noutput_items,
_buf_head = (_buf_head + 1) % _buf_num;
_buf_used--;
}
+
+ _work_cond.notify_one();
+
_samp_avail = _buf_len / BYTES_PER_SAMPLE;
_buf_offset = 0;
} else {
diff --git a/lib/rtl/rtl_source_c.h b/lib/rtl/rtl_source_c.h
index 902b386..aafea5f 100644
--- a/lib/rtl/rtl_source_c.h
+++ b/lib/rtl/rtl_source_c.h
@@ -133,6 +133,8 @@ private:
unsigned int _buf_used;
boost::mutex _buf_mutex;
boost::condition_variable _buf_cond;
+ boost::condition_variable _work_cond;
+ bool _overflow;
bool _running;
unsigned int _buf_offset;
--
2.11.0
Small API added to allow sample buffers to be used after the
lifetime of the callback, and manually returned to librtlsdr.
Allows multithreaded apps to track USB buffer buildup without
requiring memcpy() be called in the callback.
This update includes a fix to handle unsubmitted buffers on
cancel.
---
include/rtl-sdr.h | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
src/librtlsdr.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h
index 3ed13ae..1ef508d 100644
--- a/include/rtl-sdr.h
+++ b/include/rtl-sdr.h
@@ -331,6 +331,7 @@ RTLSDR_API int rtlsdr_set_offset_tuning(rtlsdr_dev_t *dev, int on);
*/
RTLSDR_API int rtlsdr_get_offset_tuning(rtlsdr_dev_t *dev);
+
/* streaming functions */
RTLSDR_API int rtlsdr_reset_buffer(rtlsdr_dev_t *dev);
@@ -381,6 +382,55 @@ RTLSDR_API int rtlsdr_read_async(rtlsdr_dev_t *dev,
RTLSDR_API int rtlsdr_cancel_async(rtlsdr_dev_t *dev);
/*!
+ * Enable or disable automatic resubmission of async transfer buffers.
+ * By default this is enabled, but if disabled then buffers will not
+ * be refilled with data until passed to rtlsdr_release_manual().
+ *
+ * This allows applications to track buildup of streaming buffers
+ * by returning from the callback quickly, without requiring an
+ * extra memcpy to take the data out of the callback for processing.
+ *
+ * \param dev the device handle given by rtlsdr_open()
+ * \param on 0 means disabled, 1 enabled
+ * \return 0 on success
+ */
+RTLSDR_API int rtlsdr_set_automatic_release(rtlsdr_dev_t *dev, int on);
+
+/*!
+* When automatic releases are disabled, release a long-lived buffer that
+* was passed to an async callback. Such buffers will not be reused until
+* released.
+*
+* There must be enough released buffers submitted to libusb at all times
+* to accommodate driver and hardware communication latency. The total
+* number of buffers filling this role, and the total number of buffers
+* unreleased, can be calculated:
+*
+* buf_num = value passed to rtlsdr_read_async at stream start
+* callback_calls = number of times a buf has been passed to callback
+* buf_releases = number of successful calls to rtlsdr_release_manual()
+*
+* bufs_reserved = callback_calls - buf_releases
+* bufs_in_flight = buf_num - bufs_reserved
+*
+* Note that this calculation assumes that all reserved buffers have been
+* passed to the callback already. It is only useful if the callback
+* returns very quickly every time. If the callback waits, buffers
+* may accumulate in the waiting time, and only be found when it returns.
+*
+* Once bufs_in_flight falls too low, the integrity of the stream is
+* compromised as the device rewrites over its full buffer. The cutoff
+* for this depends on latency in the operating system and hardware.
+*
+* Once bufs_in_flight hits zero, streaming will stop completely.
+*
+* \param dev the device handle given by rtlsdr_open()
+* \param buf a pointer to the start of the buffer
+* \return 0 on success
+*/
+RTLSDR_API int rtlsdr_release_manual(rtlsdr_dev_t *dev, unsigned char *buf);
+
+/*!
* Enable or disable the bias tee on GPIO PIN 0.
*
* \param dev the device handle given by rtlsdr_open()
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 433ed5b..e093ed7 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -103,6 +103,7 @@ struct rtlsdr_dev {
void *cb_ctx;
enum rtlsdr_async_status async_status;
int async_cancel;
+ int manual_release;
int use_zerocopy;
/* rtl demod context */
uint32_t rate; /* Hz */
@@ -1702,7 +1703,8 @@ static void LIBUSB_CALL _libusb_callback(struct libusb_transfer *xfer)
if (dev->cb)
dev->cb(xfer->buffer, xfer->actual_length, dev->cb_ctx);
- libusb_submit_transfer(xfer); /* resubmit transfer */
+ if (!dev->manual_release)
+ libusb_submit_transfer(xfer); /* resubmit transfer */
dev->xfer_errors = 0;
} else if (LIBUSB_TRANSFER_CANCELLED != xfer->status) {
#ifndef _WIN32
@@ -1753,7 +1755,8 @@ static int _rtlsdr_alloc_async_buffers(rtlsdr_dev_t *dev)
dev->use_zerocopy = 1;
for (i = 0; i < dev->xfer_buf_num; ++i) {
- dev->xfer_buf[i] = libusb_dev_mem_alloc(dev->devh, dev->xfer_buf_len);
+ dev->xfer_buf[i] = libusb_dev_mem_alloc(dev->devh, dev->xfer_buf_len
+ + sizeof(struct libusb_transfer *));
if (!dev->xfer_buf[i]) {
fprintf(stderr, "Failed to allocate zero-copy "
@@ -1780,7 +1783,8 @@ static int _rtlsdr_alloc_async_buffers(rtlsdr_dev_t *dev)
/* no zero-copy available, allocate buffers in userspace */
if (!dev->use_zerocopy) {
for (i = 0; i < dev->xfer_buf_num; ++i) {
- dev->xfer_buf[i] = malloc(dev->xfer_buf_len);
+ dev->xfer_buf[i] = malloc(dev->xfer_buf_len +
+ sizeof(struct libusb_transfer *));
if (!dev->xfer_buf[i])
return -ENOMEM;
@@ -1873,6 +1877,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx,
(void *)dev,
BULK_TIMEOUT);
+ *(struct libusb_transfer **)(dev->xfer_buf[i] + dev->xfer_buf_len) =
+ dev->xfer[i];
+
r = libusb_submit_transfer(dev->xfer[i]);
if (r < 0) {
fprintf(stderr, "Failed to submit transfer %i\n"
@@ -1909,6 +1916,14 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx,
if (LIBUSB_TRANSFER_CANCELLED !=
dev->xfer[i]->status) {
r = libusb_cancel_transfer(dev->xfer[i]);
+ if (r == LIBUSB_ERROR_NOT_FOUND) {
+ /* transfer was not in flight */
+ r = 0;
+ dev->xfer[i]->status =
+ LIBUSB_TRANSFER_CANCELLED;
+ continue;
+ }
+
/* handle events after canceling
* to allow transfer status to
* propagate */
@@ -1961,6 +1976,31 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev)
return -2;
}
+int rtlsdr_set_automatic_release(rtlsdr_dev_t *dev, int on)
+{
+ if (!dev)
+ return -1;
+
+ if (RTLSDR_INACTIVE != dev->async_status)
+ return -2;
+
+ dev->manual_release = !on;
+
+ return 0;
+}
+
+int rtlsdr_release_manual(rtlsdr_dev_t *dev, unsigned char *buf)
+{
+ struct libusb_transfer * xfer;
+
+ if (!dev)
+ return -1;
+
+ xfer = *(struct libusb_transfer **)(buf + dev->xfer_buf_len);
+
+ return libusb_submit_transfer(xfer);
+}
+
uint32_t rtlsdr_get_tuner_clock(void *dev)
{
uint32_t tuner_freq;
--
2.11.0
New rtl-sdr manual buffer resubmission patch after discussion on IRC.
This implementation uses the existing rtlsdr_read_async API and is
more compartmentalized.
RTLSDR driver is amended to handle overflows in a robust way.
Previous code appeared to have many issues: overflows were happening
more than needed and could result in data corruption. Handling is
changed to stop the stream when buffers are exhausted, and restart it
when they have drained.
I apologize that my patches are sent as attachments; I only have
access to webmail at this time.
Hi,
I've modified gr-osmosdr such that all devices respond to message
commands ala USRP.
I feel this is a really valuable addition, and I am happy to continue
to work with it to meet any needs or desires.
Please let me know that this e-mail was received.
Thanks so much,
Karl
Hi,
I've modified gr-osmosdr such that all devices respond to message
commands ala USRP.
I feel this is a really valuable addition, and I am happy to continue
to work with it to meet any needs or desires.
Please let me know that this e-mail was received.
Thanks so much,
Karl
Hi,
I was trying to take advantage of the async zero-copy buffer feature
in librtlsdr, but I found that the automatic resubmission of them made
it hard to make use of them safely.
This patch adds a couple function to manage buffers in a more advanced
manner, so that latency and reuse can be tracked precisely.
I also added some documentation.
I can occasionally make a lot of mistakes, so if anybody has time to
take a brief glance through, it would be really great.
Karl
This builds on the work started in gr-osmosdr-gqrx arispyhf branch by
Alexandru Csete. Further adds support for all the gain stages within
the Airspy.
Kieren Rasmussen (3):
- Added support for manual gain modes of AirspyHF+ - TODO support for
AGC threshold level
- Incorrect gain clipping when setting attenuation - Verified working
with a git build of GQRX
- Split the AirspyHF+ into a separate block in GRC with more relevant
parameters exposed
README | 1 +
grc/CMakeLists.txt | 1 +
grc/gen_airspyhf_blocks.py | 281 ++++++++++++++++++++++++++++++
grc/gen_osmosdr_blocks.py | 2 +
lib/airspyhf/airspyhf_source_c.cc | 102 ++++++++++-
lib/airspyhf/airspyhf_source_c.h | 9 +
6 files changed, 392 insertions(+), 4 deletions(-)
create mode 100644 grc/gen_airspyhf_blocks.py
--
2.18.0
If there is a better mailing list for the following question, I will gladly take
it there.
I want to use as much of the gnu radio project as
practical but the graphical way to string various modules
together isn't terribly useful for computer users who happen to
be blind.
Unix and to a lesser degree, DOS handled input and output
logic elegantly with <, >, | and even tee when one sends output
to multiple files and unix just turned 50 this Summer so it's
doing something right.
Is there any kind of text-based way to string those python GNU
modules together to cause them to work as they do when
connected using GRC?
This could very well be a dumb question as I have only
scratched at python a few years ago and what I am talking
about may be similar to a Makefile which is what you use to refer
to a bunch of C modules that might be in a program.
Anyway, I sure hope there is something else out there
that accomplishes the same job.
I have played with the Realtek, RTL2838UHIDIR and it does
surprisingly well on analog signals so it's time to string some
of those modules together and try some digital decoding.
Thanks for any and all constructive suggestions.
Martin McCormick WB5AGZ
Good afternoon everyone.
I write here to see if any of you know that installation errors I may have had to use the r820t2 in gnu radio companion.
I'm trying to make an FM receiver and other analog TV receiver but when running the program does not receive any type of signal and the view errors, I have: devices not supported. I believe that this is some driver to be installed but I don't know where or how.
The steps that I have followed for installation (Ubuntu 16.04 LTS) have been:
1. Install gnuradio.
2. Install Xenial Xerius specifications (it is supposed to do I need for my version of Ubuntu).
I3. nstall specifications of gr-osmosdr to enable some features of the chip.
The Stick comes with a CD but i do not know how to install it since, according to the specifications only works for WXP, 2000, Vista, 7 and 8; and it is something that it seems strange to me since I have seen videos where they use this same model of stick to carry out projects in Gnuradio on Ubuntu.
I tried with this:
sudo apt-get update
sudo apt-get install git
sudo apt-get install cmake
sudo apt-get install build-essential
sudo apt-get install libusb-1.0-0-dev
git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr/
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
Opening /etc/modprobe.d folder
Creating a new file 'blacklist-rtl.conf' and add this one line:
blacklist dvb_usb_rtl28xxu
rtl_test -t
I tried those commands but I do not know if I need to install something else because GNRC still says: "FATAL: No supported devices found to pick from"...
Please, if any of you know that i need to install It would serve as much help as I am a novice programmer and i need to resolve this problem for my project.
Enviado desde Outlook<http://aka.ms/weboutlook>
Hello
I'm trying to get the osmo-trx-lms to work with my LimeSDR. the setup is the latest version of LimeSDR and osmo-trx built from source with the command (./configure --with-lms) .
I can see the device through LimeUtil but when I try the command it fails with the following error
Info: SSE3 support compiled in and supported by CPU
Info: SSE4.1 support compiled in and supported by CPU
Sun Jul 29 07:01:27 2018 DLGLOBAL <0002> telnet_interface.c:104 telnet at 127.0.0.1 4237
Sun Jul 29 07:01:27 2018 DLCTRL <0009> control_if.c:887 CTRL at 127.0.0.1 4236
Config Settings
Log Level… 3
Device args…
TRX Base Port… 5700
TRX Address… 127.0.0.1
GSM BTS Address… 127.0.0.1
Channels… 1
Tx Samples-per-Symbol… 4
Rx Samples-per-Symbol… 4
EDGE support… 0
Reference… 0
C0 Filler Table… 1
Multi-Carrier… 0
Tuning offset… 0
RSSI to dBm offset… 0
Swap channels… 0
Tx Antennas… 'BAND1’
Rx Antennas… ‘LNAW’
Setting SCHED_RR priority(18)
Sun Jul 29 07:01:27 2018 DMAIN <0000> osmo-trx.cpp:379 [tid=140014553808704] Config: Setting SCHED_RR failed
I tried using the configuration file from the osmo-trx git url and the below file as well. both gave the same result.
https://osmocom.org/attachments/3219/limesdr.cfg1
Any ideas?
Thanks
Bahaeddin Sagar
Hello
I submitted a pull request on Github[1] which fixes bug with bias-T
power. The bias-T voltage was staying on after rtl tools ended. This
is dangerous and can lead to damage device.
[1] https://github.com/steve-m/librtlsdr/pull/47
Hi,
I have submitted a pull request on Github[1] which improves the
performance of the hackrf source. With this patch the conversion
int8_t -> float is done in realtime instead of looking up values in
the "_lut" lookup table.
In this way the compiler is able to generate AVX/SSE code (-O3
-march=native) to perform the conversion.
In [2] you can find a benchmark to show the differences.
Using -Ofast (or -O3) and -march=native I get ~2.8x using an
Intel i7 (4th gen) and 3.1x on a Core i5 (6th gen).
Gqrx with the patched library can play a WFM radio without any
interruption even with just 3 buffers (option="hackrf=0,buffers=3").
Best regards,
Alain
[1] https://github.com/osmocom/gr-osmosdr/pull/14
[2] https://gist.github.com/carpikes/cad029c338605f70d9f687aeee447db4
For anyone using the willcode/gr-osmosdr sdrplay2 branch, the SDRplay
API/SDK version 2.13 is now required. Previously, any 2.X version would
work.
There was a change to a function signature in 2.13, and since there
aren't a lot of users of this branch, I decided not to sprinkle ifdefs
around the code.
Thanks to krippendorf for the fix.
With just 'inline', if the compiler decides not to inline them, it isn't
required to emit them at all. For some targets with -Os that is causing
build failures.
Perhaps we might consider using '__attribute__((always_inline))' for
GCC builds, but 'static inline' is a good start.
---
src/rtl_adsb.c | 8 ++++----
src/rtl_power.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 9087de4..7aea8dd 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -183,7 +183,7 @@ int magnitute(uint8_t *buf, int len)
return len/2;
}
-inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
+static inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
/* takes 4 consecutive real samples, return 0 or 1, BADSAMPLE on error */
{
int bit, bit_p;
@@ -224,17 +224,17 @@ inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d
return BADSAMPLE;
}
-inline uint16_t min16(uint16_t a, uint16_t b)
+static inline uint16_t min16(uint16_t a, uint16_t b)
{
return a<b ? a : b;
}
-inline uint16_t max16(uint16_t a, uint16_t b)
+static inline uint16_t max16(uint16_t a, uint16_t b)
{
return a>b ? a : b;
}
-inline int preamble(uint16_t *buf, int i)
+static inline int preamble(uint16_t *buf, int i)
/* returns 0/1 for preamble at index i */
{
int i2;
diff --git a/src/rtl_power.c b/src/rtl_power.c
index 00f4d9f..625d818 100644
--- a/src/rtl_power.c
+++ b/src/rtl_power.c
@@ -250,7 +250,7 @@ void sine_table(int size)
}
}
-inline int16_t FIX_MPY(int16_t a, int16_t b)
+static inline int16_t FIX_MPY(int16_t a, int16_t b)
/* fixed point multiply and scale */
{
int c = ((int)a * (int)b) >> 14;
--
2.17.1
Hi all,
So I decided to add support for SpyServer in gr-osmosdr. It is currently
at a fork of mirrored in github: https://github.com/racerxdl/gr-osmosdr
What should be my next steps to get this to the official branch?
--
Lucas Teske
Teske Virtual System
GPG: BD29 7EF3 4CCB EB61 B790 06C3 351A 8000 DEAD CE11
GPG: 4A90 974B ACE0 A9A6 AF09 B3B1 6C39 C1C1 6A9D A7BE
GPG: BD09 9175 6DE8 37F4 08D3 B296 DE7A 51C3 87C9 27EE
Hi everyone @ gr-osmosdr,
I have created a small pull request to fix compilation with boost-1.67.
I filed it on your github mirror, but am not sure that's the way to
make a contribution.
It's available here:
https://github.com/osmocom/gr-osmosdr/pull/13
I'll also include the patch here for completeness:
diff -ura gr-osmosdr.orig/lib/CMakeLists.txt gr-osmosdr/lib/CMakeLists.txt
--- gr-osmosdr.orig/lib/CMakeLists.txt 2018-06-10 12:06:35.662484236 +0200
+++ gr-osmosdr/lib/CMakeLists.txt 2018-06-10 12:06:51.886207437 +0200
@@ -43,6 +43,8 @@
time_spec.cc
)
+list(APPEND Boost_LIBRARIES pthread)
+
GR_OSMOSDR_APPEND_LIBS(
${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES}
Cheers,
Maxime
Hi Torben,
I'm replying with the mailing-list in Cc, as this might also be
interesting for others.
As mentioned earlier, the issue is that the FL2000 has a very inflexible
I2C implementation that was only intended (I guess?) for I2C EEPROMs.
The PCF8574 you want to use is much simpler, as it expects only one data
byte after being addressed.
If you can live with only 6 of the 8 outputs on your port expander, you
might still be able to get it working.
What the FL2000 does for an I2C write is the following:
START, I2C_ADDR(W), REG_ADDR, DATA[0], STOP
START, I2C_ADDR(W), REG_ADDR+1, DATA[1], STOP
START, I2C_ADDR(W), REG_ADDR+2, DATA[2], STOP
START, I2C_ADDR(W), REG_ADDR+3, DATA[3], STOP
As you can see, REG_ADDR is the first byte of data that is being sent to
the device after the address. This is where you need to put the data
you want to set on the IO expander outputs. As the FL2000
auto-increments the register address, you need to set the lowest 2 bits
to 0, so that the increment is not carried to the higher bits. But that
also means that output 0 and 1 of your port-expander will toggle with
each write and are not controllable by you.
>From the datasheet of the PCF8574:
"If other data bytes are sent from the master, following the
acknowledge, they are ignored by this device."
That means that DATA[0-3] are completely ignored, which probably means
that the device will send a NAK for that byte.
So the transfer always will fail from the view of the FL2000, so you
must ignore the return value of fl2k_i2c_write(), which means you also
have no feedback if the slave is actually present or not.
The first thing I would suggest trying is writing a non-zero reg_addr to
all possible slave addresses and observe the output of the port
expander. If you have a logic analyzer, I suggest to use that and have a
look at the I2C bus.
If all that doesn't work, using a small MCU and dealing with the FL2000
I2C oddities there is probably the easiest solution.
Regards,
Steve
On 17.06.2018 21:11, Torben Keil wrote:
> Hi Steve,
>
> I tried my luck with i2c... but I wasn't successful.
> There's a PCF8574 (Portextender) connected directly on the I2C interface
> of fl2k.
>
> Here's my code:
>
> torben@Mworkstation: <mailto:torben@Mworkstation:>~/Amateurfunk/C++$ cat
> fl2k_i2c.cpp
> // g++ fl2k_i2c.cpp -L/home/torben/Amateurfunk/osmo-fl2k/build/src
> -I/home/torben/Amateurfunk/osmo-fl2k/include -losmo-fl2k -o fl2k-i2c_test
> #include "osmo-fl2k.h"
> #include <iostream>
> #include <bitset>
>
> int main (int argc, char *argv[] ) {
> int status;
> fl2k_dev_t *dev = NULL;
> uint8_t i2c_addr = 0b01000001; // Letztes Bit: Read / #Write
> uint8_t reg_addr = 0;
> uint8_t *data = new uint8_t[10];
> uint32_t dev_index = 0;
>
> fl2k_open(&dev, (uint32_t)dev_index);
> if (NULL == dev) {
> std::cerr << "Failed to open fl2k device " << dev_index
> << std::endl;
> return -1;
> }
>
> for (i2c_addr=0; i2c_addr<128; i2c_addr++) {
> status = fl2k_i2c_read(dev, i2c_addr, reg_addr, data);
> if( status >= 0 ) {
> std::cout << "Adress: " << i2c_addr;
> std::cout << "; I2C-Status: " << status << "; Data: ";
> for( int i=0; i<static_cast<int>(status); i++) {
> std::cout << " " << std::bitset<8>(data[i]);
> }
> std::cout << std::endl;
>
> }
>
>
> data[0]=127;
> for (i2c_addr=0; i2c_addr<128; i2c_addr++) {
> //fl2k_i2c_write(fl2k_dev_t *dev, uint8_t i2c_addr, uint8_t
> reg_addr, uint8_t *data);
> status = fl2k_i2c_write(dev, i2c_addr, 0, data);
> if( status >= 0 ) {
> std::cout << "Write Adress: " << i2c_addr;
> std::cout << "; I2C-Status: " << status << std::endl;
> } else {
> std::cout << static_cast<int>(i2c_addr) << "\t";
> }
> }
> }
>
> fl2k_close(dev);
>
> free(data);
>
> return 0;
>
> }
>
> Output of that program after a fresh reboot of the system:
> torben@Mworkstation:~/Amateurfunk/C++$ ./fl2k-i2c_test
> Kernel mass storage driver is attached, detaching driver. This may take
> more than 10 seconds!
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
> 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
> 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
> 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98
> 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116
> 117 118 119 120 121 122 123 124 125 126 127
>
> So there's nothing reachable via I2C.
>
> What am I doing wrong here?
>
>
> Greetings,
> Torben
>
>
>
> Am 17.06.2018 03:18, schrieb Steve Markgraf:
>> Hi Torben,
>>
>> On 16.06.2018 09:40, Torben Keil wrote:
>>> do you have a git repository for the code so that I could have a try?
>>
>> I've debugged and cleaned up the I2C code and just pushed it.
>> I2C transfers with the FL2000 seem to fail from time to time, so make
>> sure to check the return code of fl2k_i2c_read()/fl2k_i2c_write().
>>
>> Regards,
>> Steve
Hello List,
I tried to get a signal over the i2c interface but it wasn't sucsessful.
Do you have an idea how to enable the i2c interface on the fl2k chip?
Best whishes,
Torben
Hi Marcus and thanks for your reply.
>Your video is about 13 minutes longer than I'd like – can you pinpoint
>at which time in that video your transmission stops?
You can watch this video between 7:00 & 8:00 to observe the breakdowns.
>As usual, debugging on the side of the observing party might very well
>be helpful here. Figure out whether the program halts (a software
>debugger, e.g. gdb, would be the appropriate tool), the USB transfers
>stop (wireshark might be helpful here), or whether just something
>happens inside the device while the computer and software happily
>continue to work. Observing the spectrum might help.
You just gave me a good point to start debugging this issue! Actually I don’t have a RTL-SDR or anything else in hand right now to observe the spectrum but I will do the tests soon.
--------------------------------------------
Hi Steve, did a great job!
>This will happen if the host cannot supply enough data to the device,
>you need to use a lower sample rate in this case, or get rid of
>a hypervisor like VMware, as is the case in this video.
I tried fl2k_fm both in VMWare and in GNU radio live image booted from a flash drive and in both I had the problem. and why should I use a lower sample rate when my system can handle the samples well? (take a look at attachments)
I’m using VMWare Workstation Pro (Version: 14.1.2 build-8497320) on a brand new ACER laptop (Model: Aspire A715-71G-71Y3) running Windows 10 Pro 1803 (Build: 17134.112) with 16 gigabyte RAM and an Intel Core i7 7700HQ CPU. The USB host controller is Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft) witch I believe it can handle up to 157 MS/s. all drivers are updated.
However, I didn’t see anything wrong with virtualization except that the maximum achievable sample rate was a little lower than the GNU radio live booted from flash drive. Except for this, I didn't encounter by anything.
>There seems to be a 'frame loss' mechanism to detect this in through an
>interrupt transfer, but I haven't implemented this yet and have no idea
>if this works with disabled synchronization.
Looking forward to the results!
And don’t mind asking me for a helping hand. I’ll do my best to help this project.
I was reading the comments below this post in rtl-sdr.com blog and I saw a user who had the same issue mentioned something that might be useful:
Of futher note (hopefully someone from osmocom will see this) the bug where the broadcast intermittently ceases in fl2k_fm under both an ubuntu virtual machine and directly ran as a windows exe seems to have something to do with cpu affinity and / or process priority – generally it starts spitting out the underflow message on stdout then the signal drops out and the process requires a restart.
Regards,
Sajjad