osmocom-sdr

osmocom-sdr@lists.osmocom.org

904 discussions

RTL-SDR support package available for MATLAB and Simulink
by Ethem Sozer 14 Jan '14

14 Jan '14

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.

3 3

rtlsdr_read_sync failure
by Nikos Balkanas 14 Jan '14

14 Jan '14

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

3 7

RTL2832/E4000 Crystal Frequency?
by Dennis Sheirer 12 Jan '14

12 Jan '14

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

2 2

Bug in rtl-sdr / libusb / usbfs
by Gonzalo José Carracedo Carballal 11 Jan '14

11 Jan '14

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

3 3

re: Incorrect samplerate from RTL-SDR
by Richard Koch 10 Jan '14

10 Jan '14

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.

2 1

Elonics DVB-T dongle initialization
by Nikos Balkanas 09 Jan '14

09 Jan '14

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

2 5

LIBOSMOSDR_FOUND = FALSE
by johan+osmocom-sdr＠lowestorder.com 09 Jan '14

09 Jan '14

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>

2 1

One issue with LTE cell scanner?
by Jiao Xianjun 08 Jan '14

08 Jan '14

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.

2 1

Re: How to get IQ samples from multiple rtl-sdr dongles in asynchronized manner?
by Jiao Xianjun 06 Jan '14

06 Jan '14

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

3 3

Incorrect samplerate from RTL-SDR
by Joris van Rantwijk 05 Jan '14

05 Jan '14

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.

2 3

← Newer
1
...
55
56
57
58
59
60
61
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr