Hi folks,
I've been messing around with rtl_tcp and an RTL2832 device on a Raspberry Pi and want to add a bank of front end filters and a LNA that can be controlled by the GPIO.
I want to allow manual control of the signal path via a web page hosted on the Pi, but also want to be able to have the filters selected automatically based on the frequency that the RTL device is tuned to.
I noticed that rtl_tcp helpfully echos the frequency changes to the console, so I wrote a simple shell script to gather this data and control the GPIO.
Somebody may have already done this and there is probably a better way to achieve it but, if this would be of any use to you, please feel free to copy and use as you wish.
http://www.purpleplanet.org/?q=rtl-robot
Cheers,
Simon
Hello,
I just wanted to let you guys know that the Digital Now Quad DVB-T Receiver (http://digitalnow.com.au/product_pages/Quad.html) works. It's a PCI-e card with 4 tuners on it, linked up internally via USB. This has pleased me no-end - I might finally be able to get DAB+ working on my media centre!
I had to add the following line to librtlsdr.c
{ 0x0413, 0x6680, "QuadDVBT" }
Do I need to let anyone else know?
Thanks!
----------------------------------------------
Myles Eftos
Mobile: +61-409-293-183
MadPilot Productions - Created to be Different
URL: http://www.madpilot.com.au
Phone: +618-9227-5616
Fax: +618-9467-6289
Try our time tracking system: 88 Miles!
http://www.88miles.net
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.
Hello
I have been fighting to compile the gr-osmosdr package in my osx
These are the minor fixes I had to do:
1- Change in Cmakelists.txt: find_package(Boost COMPONENTS thread system),
If thread and system is not included then there are linking problems.
Although I see that this was removed recently...
2- cmake -DCMAKE_INSTALL_PREFIX=/opt/local (so it is installed together
wit my ports intallation, this is really optional)
3- Before compiling I manually edit CmakeCache.txt, and change all the
references of /usr/lib/python to /opt/local/lib/python. If not it links
agains the system python instead of the ports's python!
4- Add this line in my .bashrc so python can find the package
export PYTHONPATH="/opt/local/lib/python2.7/site-packages/"
I am aware that this is not the most elegant way to solve the problem but
is the only one that I was able to come up. Hope it helps
Regards
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?
