Just trying to figure out how to use the rtlsdr_read_sync() function, and
I'm not understanding just by reading the source. Am I supposed to call
this function continuously in a loop in a thread separate from the sample
processing, or can I do some processing in between calls to
rtlsdr_read_sync()? In other words, are the samples being buffered on the
rtlsdr device in between calls? If so, what's the size of that buffer?
Also, what functions need to be called before I can use the read_sync or
read_async functions? I'm calling rtlsdr_open, rtlsdr_set_center_freq, and
rtlsdr_set_sample_rate before calling rtlsdr_read_sync, but I'm not getting
any samples (and subsequent calls to rtlsdr_read_sync or read_async fail,
e.g. from running the rtlsdr_fm program).
Thanks,
Allen
Hi,
I'm running a RTL-SDR over a Raspberry Pi. On my old machine everthing
worked fine. But now I had to move to another machine and I'm getting
this output everytime I start my programm:
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.007.002-0-unknown
Warning: failed to XInitThreads()
Gtk-Message: Failed to load module "canberra-gtk-module"
Using Volk machine: avx_64_mmx_orc
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
bladerf rfspace airspy
Segmentation fault
I have installed GNU Radio with the build-gnuradio script. So everthing
should be installed correctly.
Thank you for your help!
Björn
Hi,
I have tried to use gqrx with an RFSPACE sdriq using the gr-osmosdr.
The experiment failed on both 10.7.5 and 10.9.5 despite following the ftdi site instructions for either OS.
I have installed all s/w via mac ports.
D2XX is installed in /usr/local/lib and, according to the suggestion of a person from Ettus, tried to set DYLD_INSERT_LIBRARIES=/usr/local/lib/libftd2xx.1.2.2.dylib gxrz.
All to no avail. When I run gqrx I get:
and if I edit the settings, I get:
But there is not /dev/ttyUSB0 nor do I know why a device is required if there is direct access (I suppose via libusb?).
System profiler clearly show the device:
Could anybody tell me what is the prescribed way of achieving what I am trying, or a way of debugging what is wrong?
Thank you,
Alex
Hi again,
I am working on my own SDR project for Stereo FM radio support, but i
would like to also improve quality for rtl_fm application, i made
unoficial patch to add:
Complex FIR - to filter strong signals close to wanted signal
Real FIR - to filter pilot from FM
Stereo FIR
Stereo Deemphasis
AGC support - it can give better resolution of IQ data
Some other improvments in FM radio code.
All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts, of
course SSE is the fastest one and it should works on Intel Atoms, but
not on ARM.
Feel free to use any part of code in any of you programs, I know that
this code is little to much to add it into rtl_fm, but maybe it could
somebody help to recieve HW stereo FM radio.
Speed of SSE code is much better than anything you can get around here,
on Core i7 it consume only 5% of one CPU, so i could demodulate at least
80 channels at the same time in stereo quality of course.
I tried this code only on AMD64 and GCC Linux, so i am not sure if it
can be compiled under windows.
--
Miroslav Slugeň
+420 724 825 885
Teramos Multimedia s.r.o.
Hello list,
I am pleased to announce the SoapySDR project. SoapySDR is a vendor
neutral and platform independent SDR support library. The library
provides a generic API for accessing SDR devices, and a plugin
architecture for supporting vendor hardware drivers. Currently SoapySDR
offers both a C++ and a C API, as well as Python language bindings.
SoapySDR already supports most devices through osmosdr and uhd based
plugins. The API covers an almost complete superset of available
functionality found in these libraries. Therefore, there is an API for
things like burst controls, heterogeneous channels, timed streaming,
timed command, find tuning adjustments, automatic gain controls...
I have seen a lot of applications where the developer has gone through
the trouble of wrapping several low level drivers to gain support for
each new device. But this can be way easier: you can use SoapySDR right
now, write the code once, and have support for most devices.
Please read more about SoapySDR on its main project page:
https://github.com/pothosware/SoapySDR/wiki
-- Community feedback --
Making a generic library has its challenges, and we will probably never
get it 100% right. But with feedback from vendors and users, we can make
sure the the library has what most people need. Missing a feature? Need
another language binding? Don't like the way something works? Lets hear it.
https://github.com/pothosware/SoapySDR/wiki/FAQ
-- GNU Radio blocks --
We have created out-of-tree GNU Radio source and sink blocks based on
SoapySDR that can provide a GNU Radio interface for the vast majority of
SDR devices and capabilities:
https://github.com/pothosware/gr-sdr/wiki
Volunteers? The source and sink blocks have full basic functionality,
but there are still additional APIs to wrap and apps to port over. The
eventual goal is to mainline this component into GNU Radio:
https://github.com/pothosware/gr-sdr/issues
There has been some debate over what would be a good name for this GNU
Radio component. Please help us with feedback about the name by taking
this online poll:
https://github.com/pothosware/gr-sdr/wiki#help-us-name-gr-sdr
-- Hardware vendors --
If you are a hardware vendor, chances are that your device is already
supported through the uhd or osmo libraries. However, you may be
interested in directly hosting a SoapySDR support module along with your
low-level driver: for simplicity's sake, licensing reasons, or because
it exposes additional features.
Hosting a module build with along with the driver is fairly simple and
has many advantages. I'm happy to work with anyone who is interested:
https://github.com/pothosware/SoapySDR/tree/master/ExampleDriver
Thanks,
-Josh
Has anyone tried the Spectrum Sensing app that is listed as a part of
OsmocomSDR?
http://sdr.osmocom.org/trac/wiki/GrOsmoSDR
It seems that documentation for it is in the works. I need to generate a
spectrum survey log file comprising time, frequency and signal strength.
My RF front end is a HackRF. Any pointers would be greatly appreciated.
Thanks!
I saw a post about Nooelect sellings the dvb-t2 dongle and that it
is slightly wider bandwidth than the plain dvb-t dongle.
> http://www.rtl-sdr.com/nooelec-now-selling-rtl-sdrs-r820t2-tuner/
Looking up DVB-T2 on google, it indicates the bandwidth is 8MHz. There
is a plot on the older DVB-T wiki of a DVB-T signal at about 7.5MHz
bandwidth.
So the question is why do we only see +/- 2MHz? The dump1090 program
would benefit with more bandwidth.
Hi,
I've followed the steps in http://sdr.osmocom.org/trac/wiki/rtl-sdr
All built OK, I opened up GRC clicked on RTLSDR in sources,
but all I get is something flashing up on screen, looks like a block
of text on a yellow background, but it seen to be flashing and
scrolling and near impossible for me to read.
rtl_test -t shows
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.
What do I need to do now to get a working srd display, ie spectrum and
waterfall display, or point me in the direction of the idiot guide
please
TIA
--
--
Best wishes /73
Richard Bown
Email : richard(a)g8jvm.com
HTTP : http://www.g8jvm.com
nil carborundum a illegitemis
##################################################################################
Ham Call G8JVM . OS Linux Mint 16 x86_64 on a Dell Inspiron N5030 laptop
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
Microwave 23 cms 140W, 13 cms 100W, 6 cms 0W & 3cms 5W
##################################################################################
Hi,
gr-osmosdr is great at abstracting the device type, but now I find myself
wishing to de-abstract. For instance: HackRF has large DC offset, so I'd
like the option to switch in a DC blocking filter when using that source.
RTL dongles can't support more than 2.4Msps reliably, so I'd like to be
able to cope accordingly at initialization time.
Is there a good way to retrieve, say, a string descriptor telling me which
particular source I'm using?
--n
