Hello,
it's my first mail on this list, so please forgive me if I do something
wrong.
I'm about to post a couple of patches for RTL drivers:
1. RTL-SDR: convert _lut to float[] to reduce size by a factor of 256.
The _lut is being indexed by I + Q (16 bits = 65536 entries), however
both samples can be processed independently, resulting in 8-bit LUT.
Saves a bit of RAM and CPU cache.
lib/rtl/rtl_source_c.cc | 19 ++++++-------------
lib/rtl/rtl_source_c.h | 4 ++--
2 files changed, 8 insertions(+), 15 deletions(-)
2. RTL-TCP: Convert to single class model
The existing RTL TCP driver is quite different from its brother RTL_SDR.
It's much more complicated, uses gr::blocks::deinterleave and
gr::blocks::float_to_complex, and generally doesn't work correctly
(e.g. https://github.com/csete/gqrx/issues/99
Spectrum is mirrored when filter or demodulator changes (rtl_tcp) #99)
I've converted the RTL TCP driver to the model used by RTL_SDR,
simplifying it in the process, and fixing the GQRX issue.
lib/rtl_tcp/CMakeLists.txt | 1 -
lib/rtl_tcp/rtl_tcp_source_c.cc | 352 ++++++++++++++++++++++++++++++++--------
lib/rtl_tcp/rtl_tcp_source_c.h | 32 +++-
lib/rtl_tcp/rtl_tcp_source_f.cc | 327 -------------------------------------
lib/rtl_tcp/rtl_tcp_source_f.h | 125 --------------
5 files changed, 309 insertions(+), 528 deletions(-)
I'm also thinking about merging the code common to RTL-SDR and RTL-TCP,
but this it's done yet.
Comments?
--
Krzysztof Halasa
Hello,
I bought a RTL-SDR dongle from ebay which has a new hardware ID. The dongle
*is working* after adding its hardware ID to the list of supported devices
in the "/src/librtlsdr.c" file.
*Hardware ID:*
ID 15f4:0133 HanfTek
*Description of the dongle:*
Black cover with white text "DAB+FM+DVB-T".
Please update the source code, because I can't use gqrx-sdr as this
hardware id is currently missing in the library. Although I compiled
rtl-sdr with my added hardware id, I dont know how to make gqrx-sdr work
with my own compiled rtl-sdr version and not the original library that
lacks my hardware id. I'm using Ubuntu.
Sincerely,
Martin
Hello
I'm wondering if the Nooelec R820T SDR & DVB-T NESDR Mini is compatible
with the GNU Radio Companion?
I've tried using the osmocom and the rtl-sdr as the source but both didn't
work. What happen is that i get "aUaUaU.." on the output box.
Thank you,
Reen
Following my recent inquiry about direct sampling using the newer
RTL2832U+R820T(2) DVB-T receivers:
1/ I know from past experience that the E4k based dongles work fine in
direct sampling. Since the E4k is zero-IF, I could just get rid of the
I+/I- or Q+/Q- capacitors and feed the RTL2832U with the signal I want
to sample. This works fine.
2/ The proposed patch I got last week aimed at canceling the IF
frequency since R820T(2) receivers are not zero-IF. Here I was failing
to get any result.
Going back to basics, I realized that using my old E4k in direct
sampling mode (rtl=0,direct_samp=1 in Gnuradio-companion osmosdr
source) is also not working. This is an unexpected behavior since E4k
based dongle configuration should not change whether direct sampling is
used or not. Indeed using the same dongle *without* the direct_samp
option did generate the right results.
I tried yesterday hacking librtlsdr in an ugly way to get raw samples
from the 820T(2) based receiver (solving my short term concern of
getting data). I could indeed acquire relevant raw samples by getting
librtlsdr to believe I was using a E4k dongle by replacing line
1580 of librtlsdr.c (right after the "found:" label) with
dev->tuner_type=RTLSDR_TUNER_E4000;
now this induces a change in all the init functions with the
function pointers just defined afterwards (&tuners[dev->tuner_type];).
I have not yet tracked the difference between the init
functions, but I think it would be more or less safe
to jump to the E4k code in case the direct_samp
option is given.
JM
--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France
I am attempting to use a RTL2832U based DVB-T dongle as a "fast" ADC
for recording baseband signals. gr-osmosdr under GNURadio 3.7 (as provided
by Debian GNU/Linux) provides the expected samples when using an E4000 (zero
IF) dongle. Being obsolete, such a dongle is no longer relevant, and I want
to do the same with the (non-zero IF) R820T(2) dongles. From
http://sdr.osmocom.org/trac/wiki/GrOsmoSDR I should be able to use the
direct_samp=1|2 option, but that does not work. I kept pins 1 and 2 connected
to the R820T output and connected a wire to pin 5 (Q-) while Q+ (pin 4) is
short circuited to pin 3 (gnd). A signal generator outputs a periodic signal
(150 mV amplitude, 100 kHz) but still no baseband signal, and on the FFT
of the osmosdr output I still see the spectrum of the FM band when tuning
to 100 MHz rather than the samples from the (initially unconnected) Q input.
Any idea if the "Device Arguments" of osmosdr-source is actually parsed
and interpreted ? or is there a command line way of acquiring the raw baseband
I/Q data ?
Thanks, JM
--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.