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