Hi everyone,
although there are some comparisons between the R820T and the E4000
already [1, 2], I also did some tests with another use-case in mind.
I'm working on a thing similar to RTLSDR-Scanner [3]. I want to
monitor a large part of the spectrum continuously.
So I compared the R820T with the E4000 using RTLSDR-Scanner w/ and w/o
an antenna.
My results are here:
https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=shar…
There's much more spurs with the E4000 than w/ the R820T. According to
[1, 2] one also would expect a better overall sensivity compared to
the E4000.
However, the GSM900 signals for example seem to be way better with the
E4000 according to the RTLSDR-Scanner. Tuning to a certain channel w/
OsmoSDR Source in GNUradio gives about the same SNR - contrary to the
RTLSDR-Scanner output. Can anyone explain this?
Also, the DVB-T channel at 502MHz is quite weak in the R820T
RTLSDR-Scanner output when compared to the E4000. I had a closer look
at the lower limit of the channel in gnuradio. This can be seen in the
502MHz_*.png pictures. The E4000 produces a nice +20dB step while one
can hardly see the channel in the R820T spectrum. I don't understand
this as well. Is this AGC-related? Manually setting a fixed gain
didn't really help though...
Any explanations?
Thank you!
Best regards,
Hunz
[1] http://steve-m.de/projects/rtl-sdr/tuner_comparison/
[2] http://www.hamradioscience.com/rtl2832u-r820t-vs-rtl2832u-e4000/#more-1852
[3] https://github.com/EarToEarOak/RTLSDR-Scanner
Some of you are probably using multiple dongles with alternating
applications as well.
Regarding the frequency correction, I put a sticker on each dongle and
wrote the ppm value on it.
However manually setting the value in each application is still annoying.
So I used rtl_eeprom to write the value into the product-ID with the
following format: "RTL%+dppm" resulting in sth. like this: RTL+87ppm
I'm not sure if this is the best way to do it, but this approach works
without changing librtlsdr.
Another option might be storing the value in a non-used eeprom
location and adding get/set functions to librtlsdr.
Is it possible to write arbitrary values to unused eeprom locations
without fucking up the realtek eeprom handling? Do you think this
would be a better way?
I'd like to hear your comments on this.
It would be awesome if we could find a solution that many existing
applications could incorporate.
(Of course the ppm value still changes with temperature, but having a
base value is still closer to the truth than 0ppm I'd say.
I measured the offset directly after grabbing samples for 20 minutes
at room-temperature and jitter is <1ppm.)
Best regards,
Hunz
Hi all,
One of the designers of the R820T tuner has recently been posting on the
ultra-cheap-sdr group, and has kindly supplied a map of the R820T registers
for private use only within the SDR community. He has asked that it not be
posted on any website, but only be forwarded around privately.
To that end, if anyone would like a copy of this spreadsheet and would be
willing to likewise not publish it on the web, let me know off-list and I'll
send it to you.
There's not a huge amount in the way of explanations, but it lists all the
registers and a very brief description of what they do.
Cheers,
Adam.
I am also having the rtl_fm scanning bug which was first reported in
http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html
The scanning mode in rtl_fm hangs during the re-tuning process. This
makes it impossible to use rtl_fm in scanning mode. I am using Ubuntu
12.10 with libusb 2:1.0.12-2, the latest git master version of rtl-sdr,
and an Elonics E4000 (Realtek, RTL2838UHIDIR).
Here are the steps to reproduce:
1. Find some frequency FREQ_NOISE that is not in use, and some frequency
FREQ_SIGNAL which is in use constantly (i.e., like a commercial FM
station). Find an appropriate squelch value SQUELCH which will stop
FREQ_NOISE but pass FREQ_SIGNAL.
2. rtl_fm -f ${FREQ_NOISE} -l ${SQUELCH}. The program should not pass
any audio, but it will exit cleanly with ^C.
3. rtl_fm -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program should pass audio
and exit cleanly with ^C
4. rtl_fm -f ${FREQ_SIGNAL} -f ${FREQ_NOISE} -l 0. The scan will pause
on the first channel and pass audio.
5. rtl_fm -f ${FREQ_NOISE} -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program
will not output any audio, even though the first frequency is squelched
out and the scanning function should skip immediately to the second
frequency. Additionally, it will not exit if sent a SIGINT with ^C, and
it must be killed with a SIGKILL.
I've made a stack trace of this behavior. The program hangs very
consistently at the same location each time:
http://pastebin.com/wzE09MCi
Thread 1 (the USB buffer reading thread) hangs while waiting for the
data_write mutex lock in rtl_fm.c:642. I presume the thread has
exhausted its supply of data and isn't getting any more.
Thread 2 is slightly more interesting, because it hangs during the
libusb system calls within the tuning function rtlsdr_set_center_freq()
in librtlsdr.c:796. My guess is that it's making a blocking call that
never returns.
Can anyone else reproduce this bug?
I am attempting to write a program in c++ to transform the output of
RTL_TCP to an audio device as nFM 12500 bandwidth.
The problem is I have no idea where to even start could someone point me in
the right direction to find out what format the out put of RTL_TCP is or
where to find some documentation on how to even start converting it to
audio.
thanks for your time
Hello,
Thank you for your great software!
While building gr-osmosdr yesterday and the day before, I have been
getting this new error while compiling. The compiler is gcc 4.7 under
Os X 10.5.8
I'm also having unexplained crashes.. Applications that use the
library are having issues.
Here is the complete message. It occurs twice,
Linking CXX shared library libgnuradio-osmosdr.dylib
cd /Volumes/xyz/builds/osmocom/gr-osmosdr/build/lib &&
"/Applications/CMake 2.8-7.app/Contents/bin/cmake" -E
cmake_link_script CMakeFiles/gnuradio-osmosdr.dir/link.txt --verbose=1
/opt/local/bin/i386-apple-darwin9-g++-mp-4.7 -O3 -DNDEBUG -arch i386
-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
-dynamiclib -Wl,-headerpad_max_install_names -compatibility_version
0.0.1 -o libgnuradio-osmosdr.0.0.1git.dylib -install_name
/Volumes/xyz/builds/osmocom/gr-osmosdr/build/lib/libgnuradio-osmosdr.0.0.1git.dylib
CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o
CMakeFiles/gnuradio-osmosdr.dir/osmosdr_sink_c_impl.cc.o
CMakeFiles/gnuradio-osmosdr.dir/osmosdr_ranges.cc.o
CMakeFiles/gnuradio-osmosdr.dir/osmosdr_device.cc.o
CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o
CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o
CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_f.cc.o
CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o
-L/opt/local/lib /opt/local/lib/libboost_thread-mt.dylib
/opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libgruel.dylib
/opt/local/lib/libgnuradio-core.dylib
/opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib
/opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib
ld: warning: could not create compact unwind for
rtl_source_c::rtl_source_c(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&): stack subq
instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for
rtl_source_c::rtl_source_c(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&): stack subq
instruction is too different from dwarf stack size
.....
Then a few lines down, it happens a second time..
Linking CXX shared module _osmosdr_swig.so
cd /Volumes/xyz/builds/osmocom/gr-osmosdr/build/swig &&
"/Applications/CMake 2.8-7.app/Contents/bin/cmake" -E
cmake_link_script CMakeFiles/_osmosdr_swig.dir/link.txt --verbose=1
/opt/local/bin/i386-apple-darwin9-g++-mp-4.7 -O3 -DNDEBUG -arch i386
-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
-bundle -Wl,-headerpad_max_install_names -o _osmosdr_swig.so
CMakeFiles/_osmosdr_swig.dir/osmosdr_swigPYTHON_wrap.cxx.o
-L/opt/local/lib
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib
../lib/libgnuradio-osmosdr.0.0.1git.dylib
/opt/local/lib/libboost_thread-mt.dylib
/opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libgruel.dylib
/opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib
/opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib
ld: warning: could not create compact unwind for
swig::SwigPySequence_Ref<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::operator
std::basic_string<char, std::char_traits<char>, std::allocator<char>
>() const: stack subq instruction is too different from dwarf stack
size
ld: warning: could not create compact unwind for
swig::SwigPySequence_Ref<osmosdr::device_t>::operator
osmosdr::device_t() const: stack subq instruction is too different
from dwarf stack size
ld: warning: could not create compact unwind for
swig::SwigPySequence_Ref<std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> >::operator std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
>() const: stack subq instruction is too different from dwarf stack
size
ld: warning: could not create compact unwind for
swig::SwigPySequence_Ref<osmosdr::range_t>::operator
osmosdr::range_t() const: stack subq instruction is too different from
dwarf stack size
???
This might be a better question for the Gnuradio list, but for years I've known that some broadcast FM stations actually transmit a second audio program which is somehow modulating a subcarrier in the main transmission. It probably carries mostly elevator music type junk but is rumored to be commercial-free (a rare thing in the US!). I remember seeing dedicated receivers advertised for this, but never actually bought one because I wasn't sure it was active in my area. These date back to Lafayette Electronics days I think and ever since so 40 years or more.
I've noticed (in SdrSharp) that on some FM stations I can see what look like they might be subcarriers on either side of the main signal. Anyone decoded those?
Alan
-----
Radio Astronomy - the ultimate DX
Sending commands to RTL_TCP
What format do the commands need to be in order to change the frequency of
RTL_TCP.
I have tried the following and the frequency will change but no to the
frequency that is expected for example:
This code :
char SET_FREQUENCY[] ={0x01};
string Freq = string(SET_FREQUENCY,1)+"500000000";
answer = send(sConnect,Freq.c_str(),11,0);
Changes the freq to this:
client accepted!
set freq 892350512
ll+, now 1
ll+, now 2
Any help would be greatly appreciated as i have been stuck on this for days.
Thanks
Thank you all for the quick response.
Unfortunately I'm still having some trouble.
This is what I have so far ( Its a lil messy but just for testing it should
work )
This is based on the Client implementation:
http://cgit.osmocom.org/gr-osmosdr/tree/lib/rtl_tcp/rtl_tcp_source_f.cc#n275
#define COMM_SET_FREQ ((unsigned char) 0x01)
struct command{
unsigned char cmd;
unsigned int param;
};
unsigned char cmds;
int iFreq = 500000000;
cmds = COMM_SET_FREQ;
struct command cmd = {cmds, htonl(iFreq)};
answer = send(sConnect, (const char*)&cmd, sizeof(cmd), 0);
and the response is :
client accepted!
set freq -858993635
ll+, now 1
ll+, now 2
ll+, now 3
I'm sure I'm missing something I just don't know what.
Thanks