osmocom-sdr January 2014

osmocom-sdr@lists.osmocom.org

39 participants
47 discussions

RE: [hpsdr] rtl_hpsdr an RTL to HPSDR software translation server
by Richard Koch 16 Jan '14

16 Jan '14

Hi Vasiliy, It identifies itself as a Hermes FW version 2.4 I was hoping it may be useful for skimmer use. I don't know a lot about it though. -Rick =================== Hi Rich This is great! What Board ID and fw version does rtl_hpsdr send to the discovery request? your solution can be used potentially with the skimmer server and HermesIntf.dll for multichannel decoding. (I don't have a dongle yet to give this a try) 73 Vasiliy

1 0

rtl_hpsdr an RTL to HPSDR software translation server
by Richard Koch 16 Jan '14

16 Jan '14

I am releasing to the public via GPL an RTL to HPSDR software translation server. Hosted on https://github.com/n1gp/rtl_hpsdr Screenshots listed and end. README: It currently builds and runs on Linux. It identifies and uses up to seven (theoretically eight) USB RTL2832U-based DVB-T dongles. The dongles can be set up with an up converter or use RTL direct-mode for HF receive. Or direct input to provide it's native > HF receive range. The program can be passed in a variety of command line options. One of which is a frequency offset not only for up converter use but also to allow a full range of frequency options to HPSDR programs that are coded to only allow the real HPSDR radio's (i.e. Hermes) frequency range which is from 10KHz to 55MHz. The main purpose of this program is to provide a mechanism that allows RTL Dongle owners the ability to use them on HPSDR specific software programs. One such program, cuSDR64 has the ability to control and display up to 7 rcvr slices simultaneously. With rtl_hpsdr, if your host has the horsepower, you can run 7 RTL Dongles to emulate the HPSDR rcvr. cuSDR64 also can be built and run on Linux. Since the real HPSDR (i.e. Hermes) rcvr can do up to eight rcvr slices, there is a concept of 'COPY' rcvrs in this server. This would allow one to use HPSDR programs that expected more rcvrs than were attached. Currently if a program request more rcvrs than are actually attached the rtl_hpsdr server will make copies of the last 'real' rcvr. This alows one to only have one RTL dongle attached and run PowerSDR mRX which may expect up to four rcvr slices. Refer to: http://openhpsdr.org/softwareinfo.php for a list of HPSDR supported applications. I have tested this only on cuSDR64, cuSDR32, and PowerSDR mRX. I was successful running 7 RTL dongles simultaneously on a Quad core ARM Cortex A9 based mini-pc, model EKB311 running a version of Picuntu, http://ubuntu.g8.net/ This was using R820T based dongles on a USB 2.0 hub. I did have to replace the USB hub power supply with one that provided 5V @ 2A. My 7 reveiver dongle setup: http://home.comcast.net/~n1gp/RTL_HPSDR/7_usb_rcvr.jpg Display of using 5 RTL dongle rcvrs with cuSDR64 http://home.comcast.net/~n1gp/RTL_HPSDR/5_rcvrs.jpg This PCIE card provides 4 RTL Dongles (DigitalNow Quad DVB-T) http://home.comcast.net/~n1gp/RTL_HPSDR/dn_quad.jpg Display of using 2 RTL dongle rcvrs with PowerSDR mRX http://home.comcast.net/~n1gp/RTL_HPSDR/powersdr.jpg

1 0

What's the settling time after new frequency set to dongle?
by Jiao Xianjun 14 Jan '14

14 Jan '14

Hi, Is there any information or hint on the settling time after new frequency set to dongle? Or is there any method to read information from dongle to see if all things get stable? Can I immediately read samples after new frequency is set by rtlsdr_set_center_freq? If so, will the samples quality be degraded? Thanks! BR Jiao Xianjun

4 5

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr January 2014