Hi there!
I'm using a dongle on a raspberry + rtl_tcp and sdrsharp on another
machine (quad core.... 3gb ram...good machine!)
The problem occour at 00:57
http://www.youtube.com/watch?v=4E2MPfEzEi8
and at 1:34 in this video:
http://www.youtube.com/watch?v=8snz1wQSRpw
If i stop and start sdrsharp, it works ok for some minutes...then the
problem is up again!
No errors appear on the console of raspberry/rtl_tcp
I'm not able to understand if it's a problem of rtl_tcp,raspberry or
whatelse...
Things i've tryed:
1) Changed the samplerate
2) Changed the raspberry (tested tp1/tp2 too...getting 4.98v!!!)
3) Changed the dongle
4) Updated sdrsharp
The dongles tryed work ok on a pc
I've no more idea....
Anyone can help me?
PS: If someone know a program that works in linux and is similar to
sdrsharp AND CAN INTERFACE TO A REMOTE RTL_TCP...
Hi guys,
I'm new to this list (and to radio) so I hope you will please indulge me
if I ask something that is a FAQ. Also, some of these questions are
about the dongle, not the library.
I am working on a personal project to use SDR techniques to decode
aviation navigation signals (VOR). I've got the signal processing mostly
working from recorded signals, but am now trying to integrate my SW with
the radio in real time.
I have a few questions:
- What exactly is offset tuning? How is offset tuning different from
tuning to an offset?
Is this a feature that mostly benefits people who are not going to put
their IF through another mixer? In my application I am already tuning to
an offset, and pulling down a wide enough IF that actually holds many
channels of interest. (VOR channels have 50kHz spacing). I then use a
software mixer/channelizer to choose the channel I want. Am I correct in
assuming that offset tuning is of no use to me?
- regarding AGC, what is the difference between AGC and auto gain?
That is, the library API has
RTLSDR_API int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int manual)
RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_dev_t *dev, int on);
I'm guessing that these affect different AGCs. One for the tuner and one
for the RTL device.
What are the benefits and costs of having either or both on?
- regarding rtlsdr_read_async(...) and related functions.
I take it that the library is setting up a ring buffer and calling me
back when it has a new buffer of data for me.
How long to I have to work with this buffer? Obviously, if I want to
work in real-time I need to keep up with the sample rate. But my
application can afford to throw away buffers since it can decode a few
ms of data from one station and then revisit it much later. However, I'd
like to know how long I have until the buffer gets clobbered. I'm
presuming it's stable until all the n-1 other buffers have been hit.
- generally how fast can the RTL devices tune? I know, this is not an
rtlsdr question per se, but I'm curious. I noticed that when I tune, I
get a delay.
This is a great library and I'm so glad it's out there! I was not
looking forward to plumbing the depths of USB drivers to understand how
to pull data from the RTL dongle! I think rtl-sdr.h could use perhaps a
smidge more documentation. I'd be happy to submit a comments-only patch
if there's interest. :-)
Regards,
Dave Jacobowitz
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
This is with a version of rtl-sdr I got by git last night and OpenBSD 5.2 (current release). 5.2 has some pthreads fixing so I waited until I bought another computer and loaded it. Are the crashes related to threads? I don't know, but possibly. It didn't work with OpenBSD 5.0 either.
rtl_fm crashes and uses threads
rtl_adsb crashes and uses threads
rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c
rtl_test doesn't crash, doesn't use threads, won't stop
rtl_eeprom doesn't crash, doesn't use threads, ends normally
I'm not real practiced using gdb but I tried looking at a couple of core files, here's a run of rtl_fm:
rtl_fm -f 162550000 -N - | play -t raw -r 24k -e signed-integer -b 16 -c 1
-V1 -
-: (raw)
Encoding: Signed PCM
Channels: 1 @ 16-bit
Samplerate: 24000Hz
Replaygain: off
Duration: unknown
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000013
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 162802000 Hz.
Sampling at 1008000 Hz.
Output at 24000 Hz.
Exact sample rate is: 1008000.009613 Hz
Tuner gain set to automatic.
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0
Done.
Abort (core dumped)
d530# gdb -c rtl_fm.core /usr/local/bin/rtl_fm
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.2"...
Core was generated by `rtl_fm'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libpthread.so.16.0...done.
Loaded symbols for /usr/lib/libpthread.so.16.0
Reading symbols from /usr/lib/libm.so.7.0...done.
Loaded symbols for /usr/lib/libm.so.7.0
Reading symbols from /usr/local/lib/librtlsdr.so.0.0...done.
Loaded symbols for /usr/local/lib/librtlsdr.so.0.0
Reading symbols from /usr/local/lib/libusb-1.0.so.1.0...done.
Loaded symbols for /usr/local/lib/libusb-1.0.so.1.0
Symbols already loaded for /usr/lib/libpthread.so.16.0
Reading symbols from /usr/lib/libc.so.65.0...done.
Loaded symbols for /usr/lib/libc.so.65.0
Loaded symbols for /usr/libexec/ld.so
#0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0
(gdb) bt
#0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0
#1 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c)
at /usr/src/lib/librthread/rthread_sync.c:218
#3 0x1c00266e in full_demod (fm=0xcfa2de5c)
at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583
#4 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c)
at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641
#5 0x005ebc2e in _rthread_start (v=0x84da4c00)
at /usr/src/lib/librthread/rthread.c:111
#6 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0
The backtrace (bt) shows that it dies trying to do a mutex_unlock (I think). rtl_tcp also does a mutex_unlock and it doesn't crash. I'm probably reading it wrong for all I know. I don't know what's causing the signal 6 either.
I'd also like to get the -lrt of of the cmake files. OpenBSD doesn't use or have lrt, it works without. I can edit it out and compile, but every time I run cmake again, I have to edit the files again.
Alan
-----
Radio Astronomy - the ultimate DX
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,
I modified my copy of rtl-sdr to be able to store frequency calibration
on the sticks themselves. Maybe this change is generally useful?
Thanks,
andreas
Andreas Seltenreich (2):
rtl_eeprom: Add -x to store exact xtal frequency in Hz.
lib: Try reading xtal calibration from EEPROM.
src/librtlsdr.c | 21 +++++++++++++++++++--
src/rtl_eeprom.c | 17 ++++++++++++++++-
2 files changed, 35 insertions(+), 3 deletions(-)
--
1.7.10.4
Not sure if anyone else had worked on this, but I couldn't find
anything. I updated gr-osmosdr to work with GNU Radio 3.7 (currently
the next branch). You can find it here:
https://github.com/trondeau/gr-osmosdr
I didn't redo the code to be in the 3.7 API style, just made sure that
it could build off gnuradio and run properly.
Tom
Hi all,
I recently got a Raspberry Pi and an RTL2832 USB card and have been
successful in compiling rtl-sdr and running the associated examples, piping
the data up into LabVIEW for analysis with their Demodulation Toolkit. I'm
a little weak on the signal processing math knowledge here, so I was
wondering if someone could explain the math behind the offset tuning code
in rtl_fm's optimal_settings() function.
It looks like the function takes the desired center tuning frequency and
calculates an integer decimation ratio based on a "capture rate" near 1 MHz
and the desired final sampling rate. Then the center frequency is offset by
a quarter of the capture rate, and this and the capture rate are used to
program the radio. Then in the receive callback, the I/Q data is shifted 90
degrees in rotate_90(). At this point, the I/Q data represents (I presume!)
the spectrum around the original desired center frequency and at the
original sample rate.
How do I get, mathematically speaking, from the oversampled I/Q data
centered at the offset frequency to *my* desired center frequency and
sample rate? I'm especially curious as to the effect of the frequency
offset using that particular value (capture rate/4) and what role the
rotation plays in the transformation.
Thanks,
Aaron
This diff below is actually 2 changes. When scanning it will print the frequency to stderr every time something breaks squelch. When searching/scanning a range it logs active frequencies into a file in /tmp.
Two notes: there's an extra \n at the start of each frequency announcement, that's to get around sox's output. If you use something like aucat that doesn't write to the console you don't need that.
The file path should be ifdefed and an appropriate Windows path added.
This diff was taken before my fix to the scanning step, which may change the context slightly.
Alan
*** rtl_fm_original.c Wed May 22 13:18:00 2013
--- rtl_fm.c Wed May 22 13:32:53 2013
***************
*** 76,82 ****
--- 76,86 ----
static int *atan_lut = NULL;
static int atan_lut_size = 131072; /* 512 KB */
static int atan_lut_coef = 8;
+ static int f_ann = 0; /* freq announced */
+ static int searching = 0;
+ static FILE *flog; /* frequency log */
+
struct fm_state
{
int now_r, now_j;
***************
*** 587,592 ****
--- 591,603 ----
return;
}
sr = post_squelch(fm);
+ if ((sr > 0) && (f_ann == 0) && (fm->freq_len > 1)) {
+ fprintf(stderr, "\n%f\n",(double)fm->freqs[fm->freq_now]/1000000.0);
+ f_ann = 1; /* reset next hop */
+ if (searching > 0) {
+ fprintf(flog,"%f\n",(double)fm->freqs[fm->freq_now]/1000000.0);
+ fflush(flog);
+ }
if (!sr && fm->squelch_hits > fm->conseq_squelch) {
if (fm->terminate_on_squelch) {
fm->exit_flag = 1;}
***************
*** 609,614 ****
--- 620,626 ----
/* ignore under runs for now */
fwrite(fm->signal2, 2, fm->signal2_len, fm->file);
if (hop) {
+ f_ann = 0;
freq_next = (fm->freq_now + 1) % fm->freq_len;
optimal_settings(fm, freq_next, 1);
fm->squelch_hits = fm->conseq_squelch + 1; /* hair trigger */
***************
*** 676,681 ****
--- 688,696 ----
stop[-1] = '\0';
step = strchr(stop, ':') + 1;
step[-1] = '\0';
+ flog = fopen("/tmp/freqlog.txt","a");
+ if (flog != NULL)
+ searching = 1;
for(i=(int)atofs(start); i<=(int)atofs(stop); i+=(int)atofs(step))
{
fm->freqs[fm->freq_len] = (uint32_t)i;
-----
Radio Astronomy - the ultimate DX
This only affects scanning, or specifically searching a range of frequencies. I could hear it in the example from usage -f 118M:137M:25k. For some reason the step changes as the loop executes so the frequencies look like:
118950000
118975000
119000000 ok to here
119257000
119282000
119307000
119332000
119357000
119382000
119407000
119432000
119457000
119482000
119507000
119532000
119789000
119814000
119839000
119864000
The frequencies should be at 25 KHz intervals.
I don't have a diff because I have several other changes in my version, but my frequency_range() now looks like:
void frequency_range(struct fm_state *fm, char *arg)
{
char *start, *stop, *step;
int i;
int frst, frstp, frdelta;
start = arg;
stop = strchr(start, ':') + 1;
stop[-1] = '\0';
step = strchr(stop, ':') + 1;
step[-1] = '\0';
frst = (int)atofs(start);
frstp = (int)atofs(stop);
frdelta = (int)atofs(step);
fprintf(stderr,"start: %i, stop: %i, step: %i\n",frst,frstp,frdelta);
// step was changing here somehow:
// for(i=(int)atofs(start); i<=(int)atofs(stop); i+=(int)atofs(step))
for (i=frst; i<=frstp; i+=frdelta)
{
fm->freqs[fm->freq_len] = (uint32_t)i;
fm->freq_len++;
}
stop[-1] = ':';
step[-1] = ':';
}
I added the fr* variables and used them in the loop. It sounds better now that none of the frequencies are off. I'm also logging and those frequencies look OK.
Alan
-----
Radio Astronomy - the ultimate DX
Hello All
This is the first time I have posted on this list, sorry if I have done it
wrong
I would like to use a line powered "cheap and nasty" LNA with an RTL dongle.
E.g.
http://www.amazon.co.uk/Satellite-Signal-Amplifier-Booster-electrosmart%C2%…
This may seem a like stupid question (I will ask it anyway) but will the
dongle need protecting from the 18V going down the antenna line. I have
seen some diagrams with protection and some without.
If protection is required, has anyone got any suggestions on how I should
do it???
Many thanks
Jonathan, M0ZJO
Hi all,
I need some help to resolve my problem with GNURADIO.
I Built and installed rtl-sdr and it works well with the dongle
terratec.
Built and install also the osmosdr package, but when I open grc the
block sources rtl does'nt appear.
Any ideas?
GNUradio for debian package v.3.5.3.2-1 installed.
Best regards
Laurent
Hi there!
I would like to know if is it possible to change the freq. of rtl_fm "on
the fly" without cloning the process and restart it with a a different
freq. parameter.
Any idea?
I've recently developed a RTL-SDR component for REDHAWK that uses the
RTL-TCP server.
https://github.com/Axios-Engineering/acquisition-components
I'm guessing that this mailing list is the correct address to use for this
component to be listed on the "Known Apps" page for the RTL driver.
~Michael
From: LD Zhang [mailto:ldz10565@gmail.com]
Sent: Monday, May 13, 2013 2:23 PM
To: 'osmocom-sdr(a)lists.osmocom.org'
Subject: A question on osmoSDR new version
Hello,
I am very interested in the new osmoSDR that has 4MS/s rate and a 14bit ADC.
Is this new version available for purchase?
Thanks,
LD
Ah, OK - I've got you.
You also need to run the script once you have launched rtl_tcp using the command in step 3) below.
The simplest way to do this would be to add a step:
6) Sign in to rPi with a new terminal session, leaving the old one open for now. cd to the directory where you created the script and then run it using this command:
./rtl-robot (or whatever you called the script)
You could run the script from the same terminal that you launched rtl_tcp from if you used & to force rtl_tcp to detach from the console and run in the background.
I'll edit the comments on the script to make that a bit clearer...
Thanks!
Simon
----- Original Message -----
From: "Favati" <smile_k(a)libero.it>
To: osmocom-sdr(a)lists.osmocom.org
Sent: Saturday, 11 May, 2013 20:14:36 GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: Raspberry Pi based remote SDR head
> Could you describe exactly the steps you have taken?
1) installed wiringpi (and tested as described on the developer site)
2) created your script
3) launched this command:
stdbuf --output=0 rtl_tcp -a 192.168.2.15 -p 1234 > rtl.data
4) used sdrsharp to connect to my raspberry (192.168.2.15, and it
connect ok, i can use sdrsharp ok)
5) nothing is displayed on the console of my raspy except the first 2
lines of rtl_tcp output
The rtl_data is created ok and looking inside that file i can see the
normal output of "rtl_tcp" (set freq blablablabla, etc...)
At the moment i've taken another approach...i've patched the rtl_tcp.c
to set the gpio directly...i'll post my "project" asap somewhere...
Hi there,
That's odd - do you have WiringPi installed?
https://projects.drogon.net/raspberry-pi/wiringpi/download-and-install/
The script makes use of this excellent program to control the GPIO and also to report on the pin status. Originally I was using the native method of controlling the GPIO using export and echoing a value to the files on the pi. I stumbled onto WiringPi, which makes controlling the pins far simpler and does not require root privs to set them up.
Simon
----- Original Message -----
From: "Favati" <smile_k(a)libero.it>
To: osmocom-sdr(a)lists.osmocom.org
Sent: Thursday, 9 May, 2013 18:30:51 GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: Raspberry Pi based remote SDR head
Il 03/05/2013 01:57, Simon PurplePlaNET ha scritto:
> 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
>
>
>
Just tryed this command:
stdbuf --output=0 rtl_tcp -a 192.168.2.15 -p 1234 > rtl.data
I don't have anything connected to the gpio pins...but i cannot see any
output from your script while changing freqs...(yes, i've gone below
100mhz and above 500mhz).
It's quite strange....the rtl.data is created in the same folder of your
script...
Taking a look at rtl.data, it contains the correct output of the
standard output of rtl_tcp.
Any idea?
Hi Alan,
Where I live, the temperature extremes inside my attic are not so bad.
If you look at devices such as the Kinetic SBS 3, you will see that Ethernet ports are becoming quite normal on SDR gear these days. This not only allows you to minimise the cable run to the antenna (important at 1090MHz) but also to use the device from anywhere with an adequate network connection to it.
http://www.kinetic-avionics.com/
A 500 foot drum of RG-6 may only cost $32 at Home Depot, but you would need over 30,000 such drums to reach the closest Home Depot from my home. Quite an outlay when we already have the wealth of a global telecommunications industry at our fingertips and begging to be used!
My main reason for doing this however, is really to make a better radio than the RTL dongle provides on it's own. I am interested in front end filtering and an LNA and want to use the rPi to control this. You could still run 500' of lossy co-ax to the antenna if you wanted to... :-)
I could buy a Funcube Pro+ Dongle for £150 instead, but where is the fun in that?
Simon
----- Original Message -----
From: "Alan Corey" <alancorey(a)yahoo.com>
To: osmocom-sdr(a)lists.osmocom.org
Sent: Friday, 10 May, 2013 03:39:55 GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: Raspberry Pi based remote SDR head
To no one in particular: The usefulness of doing this escapes me. Sure you'd want to put the receiver up high, but in an attic? There are all kinds of temperature extremes up there, from very hot most of the year to below freezing in colder climates in the winter.
Something like a 1-transistor preamp feeding some RG-6 seems like a more practical solution. You can buy 500 feet of RG-6 for about $32 at Home Depot and good low-noise transistors are available under $1. You just need enough gain to offset the cable loss and RG-6 is pretty good.
Alan
-----
Radio Astronomy - the ultimate DX
--- On Thu, 5/2/13, Simon PurplePlaNET <simon(a)purpleplanet.org> wrote:
From: Simon PurplePlaNET <simon(a)purpleplanet.org>
Subject: Raspberry Pi based remote SDR head
To: osmocom-sdr(a)lists.osmocom.org
Date: Thursday, May 2, 2013, 7:57 PM
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
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?