Hi All,
RTL-SDR support package for MATLAB and Simulink has been released:
http://www.mathworks.com/hardware-support/rtl-sdr.html
Using this support package, you can receive signals from your RTL-SDR dongle directly into MATLAB and Simulink. The package also contains several examples to get you started.
Have fun and let me know if you have any questions or comments.
Ethem Mutlu Sozer
Principal Engineer
Signal Processing and Communications Group
MathWorks, Inc.
Hi,
I need to get a few traffic data bytes ~ 16 B from my dongle. libusb's bulk
transfer and therefore rtlsdr_read_sync, will fail with -8 if used with
less than 1024 B. Can anyone think of another way to read them? (async also
uses libusb's fill_bulk_transfer :-()
I could possibly use rtlsdr_read_array, except that i don't know the block
and address that I need to use for traffic data :-(
Thanks,
Nikos
Does anyone know if you can check the crystal frequency from one of the RTL2832 registers?
Or, has anyone seen an early version E4000 dongle using a crystal other than 28.8 MHz?
I've been measuring the sample output rates of my E4000 and found the output rates differed from the expected rates that I'm setting using the rtlsdr library method.
https://groups.google.com/forum/#!topic/ultra-cheap-sdr/r_BLWQ5C4mw
Denny
Hello!
This is my first time using this mailing list, hope it's the right
place to post this.
I compiled rtl-sdr under Debian 7.2 (32 bits x86) it detects my ezcap
e4k properly but it's unable to read samples. When running rtl_sdr
like this, it just hangs:
---8<--------------------------------------------------------------------------------------------
% rtl_sdr -f 100000000 -
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN:
Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in async mode...
---8<--------------------------------------------------------------------------------------------
Pressing Ctrl+C only makes rdl_sdr say "Signal caught, exiting!", but
it won't exit unless you kill it explicitly with SIGKILL. If I run it
in synchronous mode, I get this output instead:
---8<--------------------------------------------------------------------------------------------
% rtl_sdr -f 100000000 -S -
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN:
Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in sync mode...
WARNING: sync read failed.
Library error -8, exiting...
rtlsdr_demod_write_reg failed with -1
---8<--------------------------------------------------------------------------------------------
I tried to reinstall libusb, recompiling it from a newer version (I'm
currently using 1.0-16rc10) and got the same output. As -8 means
overflow for libusb, I decided to increase the output block size. I
had to edit rtl_sdr.c to read as much as 30M, and that was the only
way I could get some output. Block sizes below 10M just won't do the
trick:
---8<--------------------------------------------------------------------------------------------
% rtl_sdr -b 30000000 -f 100000000 -S -
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN:
Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in sync mode...
Short read, samples lost, exiting!
Library error 0, exiting...
(here be messy bytes of 64 bytes sampled by RTL)
---8<--------------------------------------------------------------------------------------------
That's why I recompiled libusb with logging, and I got this output
(now, with 3M blocks):
---8<--------------------------------------------------------------------------------------------
[...]
Reading samples in sync mode...
libusb: 1.079895 debug [submit_bulk_transfer] need 184 urbs for new
transfer with length 3000000
libusb: 1.080660 debug [libusb_handle_events_timeout_completed] doing
our own event handling
libusb: 1.080692 debug [handle_events] poll() 4 fds with timeout in 60000ms
libusb: 1.083056 debug [handle_events] poll() returned 1
libusb: 1.083082 debug [reap_for_handle] urb type=3 status=-75 transferred=64
libusb: 1.083104 debug [handle_bulk_completion] handling completion
status -75 of bulk urb 1/184
libusb: 1.083125 debug [handle_bulk_completion] overflow, actual_length=64
libusb: 1.083146 debug [disarm_timerfd]
libusb: 1.083161 debug [usbi_handle_transfer_completion] transfer
0x97a0424 has callback 0xb775c7f0
libusb: 1.083182 debug [bulk_transfer_cb] actual_length=64
WARNING: sync read failed.
Library error -8, exiting...
[...]
---8<--------------------------------------------------------------------------------------------
Status -75 (overflow) made me think about a limitation on the URB size
in my system, but it looks that in Linux that's a standard (16K), so I
ran out of ideas. I don't know where the problem is anymore, whether
in rtl-sdr, libusb, usbfs or even in my system; because I've compiled
it in two different systems already (my laptop - Ubuntu 12.04 - and my
home computer - Debian Sid -) and it works fine in both of them.
Regards,
--
>> Gonzalo José Carracedo Carballal
Hi Steve,
In regards to your post about the anti-aliasing filter
you referred to, it appears that it is getting set in
librtlsdr.c, rtlsdr_init_baseband()
If one wanted to change that to optimize the anti-aliasing
to a lower bandwidth, say 1500 Khz instead of the 2048 Khz
How would you change the fir_coeff[] table entries to achieve
this? The 8 bit entries and 12 bit entries are confusing to me.
==== orig post ====
> I have seen other reports on the mailing list, saying that sample rates
> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
> devices, then maybe it should be documented and the library can return
> an error code for such sample rates. Otherwise people will keep walking
> into this trap.
We could return some sort of error in those cases, but such low rates
(< 1MS/s) aren't recommended in general. First of all, the
anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
although the coefficients can be changed, I doubt you can get a nice
filter for lower bandwidths with such a low order. And then the ADCs
only have 8 bits resolution, so you want to improve that by decimating,
and also profit from decimation gain.
Even Realtek uses 2.048 MS/s for FM reception in their original Windows
software.
Hi,
I am new to sdr and reading the site, I got an Elonics DVB-T dongle for it.
Does anyone know the initialization sequence that need to be send for it to
work correctly, or a reference for them?
I work with Linux and a lot of the rtl drivers are for windows. Therefore I
am developing my own drivers and would like to skip libsdr for now.
Thanks,
Nikos
Hey list, new guy here!
Got rtl-sdr built and it looks like my dongle (ezcap RTL2832U/FC0013) is
working. I have gnuradio v3.7.2.1-116-ge751e54a installed and working.
I'm confused about configuring gr-osmosdr. In particular this output from
cmake:
-- Configuring sysmocom OsmoSDR support...
-- Dependency LIBOSMOSDR_FOUND = FALSE
-- Disabling sysmocom OsmoSDR support.
-- Override with -DENABLE_OSMOSDR=ON/OFF
Isn't libosmosdr part of gr-osmosdr? How can it have itself as a dependency?
I tried overriding, but it didn't have any effect.
I went ahead and built and installed anyway and a bunch of osmosdr stuff did
get installed in my gnuradio dir (see below).
Before I try to get my dongle working in gnuradio, I just wanted to check
that there aren't any important pieces missing due to "Disabling sysmocom
OsmoSDR support". It sounds scary.
Thanks, Johan
foo:~/local/gnuradio> find . -name \*osmo\*
./lib/libgnuradio-osmosdr-0.1.1git.so.0
./lib/pkgconfig/gnuradio-osmosdr.pc
./lib/libgnuradio-osmosdr-0.1.1git.so.0.0.0
./lib/libgnuradio-osmosdr.so
./lib/libgnuradio-osmosdr-0.1.1git.so
./include/osmosdr
./include/osmosdr/swig/osmosdr_swig.i
./include/osmosdr/swig/osmosdr_swig_doc.i
./share/gnuradio/grc/blocks/osmosdr_source.xml
./share/gnuradio/grc/blocks/osmosdr_sink.xml
./lib64/python2.7/site-packages/osmosdr
./lib64/python2.7/site-packages/osmosdr/osmosdr_swig.pyc
./lib64/python2.7/site-packages/osmosdr/osmocom_siggen_base.pyo
./lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py
./lib64/python2.7/site-packages/osmosdr/osmocom_siggen_base.py
./lib64/python2.7/site-packages/osmosdr/_osmosdr_swig.so
./lib64/python2.7/site-packages/osmosdr/osmocom_siggen_base.pyc
./lib64/python2.7/site-packages/osmosdr/osmosdr_swig.pyo
./bin/osmocom_siggen_nogui
./bin/osmocom_fft
./bin/osmocom_siggen
./bin/osmocom_spectrum_sense
foo:~/local/gnuradio>
I found that librtlsdr in github 003bd51167d9680e9721c7296323fdffe4be5a09
can't work with
LTE-Cell-Scanner<https://github.com/Evrytania/LTE-Cell-Scanner>5fa3df8a5d915c73cacea843021ce0c5b317522f
in github.
But librtlsdr release 0.5.2
2d0eaa898d2d4e271aed87ae3849a80ac12cf76c is OK.
The 'can't work' means:
LTE-Cell-Scanner show seg-fault/core-dump when it checks the second
frequency point after finishes the first frequency point.
A debug tracing shows that the crash is at rtlsdr_set_center_freq().
BR
Ryan.
Hi,
I have questions on usage of rtlsdr_read_sync(dev, buffer, out_block_size,
&n_read):
For example, if sampling rate is 1Msps, and out_block_size is 1000000,
question is:
1. the rtlsdr_read_sync() will cost 1s exactly? Or is there any lower level
device/driver buffer, which perhaps feed rtlsdr_read_sync() with history
data quickly and makes rtlsdr_read_sync() return in a time shorter than 1s?
2. in this infinite processing loop:
while(1)
{
rtlsdr_read_sync(dev, buffer, out_block_size, &n_read);
processing_function(buffer); // let's assume that this cost 0.001s
}
Those samples during the 0.001s processing period will be losted or not? Is
there any method to not lost them?
Thanks very much!
BR
Jiao Xianjun
On Thu, Jan 2, 2014 at 9:25 PM, Jiao Xianjun <putaoshu(a)gmail.com> wrote:
> I see some UDP packet performance issues in my laptop (but not in my
> desktop computer). Will the common (interleave multiple receives) UDP link
> helps?
>
> The issue is that fread for the second dongle in matlab get less data than
> expectation sometimes. Seem that fread for the first dongle works well.
> ------------------------------
> From: Sdr Guru <sdrguru1(a)gmail.com>
> Sent: 2014/1/2 5:39
> To: osmocom-sdr(a)lists.osmocom.org
> Subject: Re: How to get IQ samples from multiple rtl-sdr dongles in
> asynchronized manner?
>
> Hi
>
> rtl-sdr-relay
> Some of the recommendations.
> Please add PPM error calculation, exactly like new rtl_test -p
> but multiple receivers simultaneously.
> It provides immediate information if something is wrong with USB or
> dongles.
>
> https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c…
> https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_test.c
>
> Please add automatic eeprom PPM calibration
>
> https://github.com/keenerd/rtl-sdr/commit/ecf267737ca52f5005b7a12a352307e8c…
>
> default sample rate 2.4M (28.8/12) or 1.2M (28.8/24), probably lower jitter
> MAX_NUM_DEV 4->16 :)
>
> Some nice to have features.
> ip binding
> multicast support
> one common (interleaved) stream of all the receivers
> timestamped stream
>
> I'm trying to convert MATLAB script to Ocatve.
>
> SG
>
> On Mon, Dec 30, 2013 at 9:38 AM, Jiao Xianjun <putaoshu(a)gmail.com> wrote:
>
>> Hi guys,
>>
>> For the multiple dongles synchronization in signal level instead of
>> bits/packets level, I setup a working repo in github, and write a initial
>> demo framework. See below:
>>
>> https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git
>>
>> You may find information and instruction of demo quickly by reading the
>> README.
>>
>> My initial purpose is performing in-fly calibration for multiple dongles
>> according to some pre-known signal (GSM, ADS-B?) to let them work together
>> coherently.
>>
>> An ideal scheme may be that we should generate a very narrow band and
>> very week signal in (or just located at the edge of) target working band of
>> dongles, and perform the software in-fly calibration in background (or
>> driver level). This would be user friendly.
>>
>> I know it is far from final state currently, and many things are not
>> clear yet (See TODO). But please join me if you also think this is a good
>> idea. Just check out the demo and run it to have a look.
>>
>> Currently I just test the demo in Ubuntu-Linux.
>>
>> BR
>>
>> Jiao Xianjun
>>
>>
Hi,
Let me first say that librtlsdr is great. It is a fantastic way for me
to learn about SDR. Also, the library seems very well designed, easy to
use, and at a convenient level of abstraction. Many thanks for putting
this together!
I'm using librtlsdr to make a wideband FM receiver in C++. Perhaps more
about that later.
I noticed the following problem:
When I configure a sample rate lower than 1 MS/s, I often get a very
different sample rate then what I ask for. The library reports back the
same sample rate that I asked (via rtlsdr_get_sample_rate), but the
actual sample rate does not match at all.
For example, asking 900 kS/s results in ~ 290 kS/s.
Asking 800 kS/s gives ~ 285 kS/s.
Asking 600 kS/s gives ~ 255 kS/s.
Asking 400 kS/s gives ~ 1700 kS/s.
Asking 300 kS/s gives 300 kS/s.
I know the real samplerate from looking at the amount of data I get out
of the library in a given amount of time. I have also looked at the
FFT spectrum of the data and this confirms my estimate of the actual
sample rate (this eliminates the hypothesis that RTL is sampling at
configured rate but losing some of the data packets).
After diving into librtlsdr.c, I found that the pattern of configured
vs real sample rate can be explained by assuming a specific bit error in
the configuration word rsamp_ratio. Bit 28 of the word is forced equal
to bit 27.
It is as if somebody is doing
rsamp_ratio = (rsamp_ratio & 0x0fffffff) |
((rsamp_ratio & 0x08000000) << 1);
after the configuration is sent out via USB but before it is applied by
the RTL chip.
I have a Terratec Cinergy Tstick RC rev3, USB ID 0ccd:00d3.
The RTL-SDR library reports:
Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Terratec Cinergy T Stick RC (Rev.3)
Found Elonics E4000 tuner
Does this ring any bells for people who understand the RTL chip?
Is it caused by the difference between RTL2832 vs RTL2838?
I have seen other reports on the mailing list, saying that sample rates
between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
devices, then maybe it should be documented and the library can return
an error code for such sample rates. Otherwise people will keep walking
into this trap.
Kind regards,
Joris van Rantwijk.
