Hi again,
I am working on my own SDR project for Stereo FM radio support, but i
would like to also improve quality for rtl_fm application, i made
unoficial patch to add:
Complex FIR - to filter strong signals close to wanted signal
Real FIR - to filter pilot from FM
Stereo FIR
Stereo Deemphasis
AGC support - it can give better resolution of IQ data
Some other improvments in FM radio code.
All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts, of
course SSE is the fastest one and it should works on Intel Atoms, but
not on ARM.
Feel free to use any part of code in any of you programs, I know that
this code is little to much to add it into rtl_fm, but maybe it could
somebody help to recieve HW stereo FM radio.
Speed of SSE code is much better than anything you can get around here,
on Core i7 it consume only 5% of one CPU, so i could demodulate at least
80 channels at the same time in stereo quality of course.
I tried this code only on AMD64 and GCC Linux, so i am not sure if it
can be compiled under windows.
--
Miroslav Slugeň
+420 724 825 885
Teramos Multimedia s.r.o.
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,
I want to use multiple rtl-sdr dongles to do some multi-antenna experiments.
Is it possible to read IQ samples from multiple rtl-sdr dongles in a
synchronized manner?
I already have a glance at dump1090 codes, which is a project using rtl-sdr
to decode aircraft broadcasting ADS-B messages in 1090MHz.
Seems that I should use rtlsdr_read_async() instead of rtlsdr_read_sync(),
because that if rtlsdr_read_sync() is used, I have to call it multiple
times sequentially. That looks not synchronized.
But rtlsdr_read_async() function only accept one rtl-sdr device as input
parameter, and it will be blocked after it is called. So seems that it also
can't be used for my purpose directly.
Also welcome any opinion on how to improve rtl-sdr lib/driver to support
this feature.
Thank you.
BR
Jiao Xianjun
A quite good (AM/SW)/FM/DAB/DVB-T USB dongle.
Mirics FlexiTV MSi3101 (two chips MSi001+MSi2500)
http://www.mirics.comhttp://www.mirics.com/node/31
Data sheets available, register yourself at Mirics portal.
RF Tuner: MSi001/MSi002 ( used by FUNcubrePro+ ?), seems better than R820T
ADC and HiSpeed USB interface: MSi2500 . ADC 10 bit , better than
8 bit RTL2832U aDC.
Windows binary software available: FMDABplayer, DVB_T decoder,
Windows lib.dll and API doc.
IO-DATA GV-TV100 stick sold on Japan .
Stick, chips and dev board available from Mirics.
Linux software at address
http://cgit.osmocom.org/libmirisdr/
It seems project on stand-by .
Can author Steve Markgraf comment ?
Francesco
OK, so you plug a $20 dongle into a Raspberry Pi, hook some stuff to the GPIO connector and with probably minor tweaks to something like RTL_FM you can use it as a radio in radio-controlled model planes, cars, boats. Add the Pi's $25 camera and you could have a radio-controlled camera, useful for sending up in a radio-controlled plane or doing wildlife photography. If you've got some analog (pulse position) channels those would be good for rudder, flaps, various camera settings. This can be done in the 27 MHz CB band or with a ham license in something like the 6 meter ham band. I had no trouble getting RTL_FM running on my Pi but it probably doesn't have enough CPU horsepower to do a lot of processing on the dongle side and on the imaging side at the same time.
Anybody done this?
Alan
-----
Radio Astronomy - the ultimate DX
Since my last Windows Update (not sure that's the cause), I'm having
a hell to regain access to my Terratec DVB-Tstick with ther Elonics E4000
tuner. I've modified librtlsrc.c to include some more traces and relinked rtl_test
with it. All I'm getting is LIBUSB_ERROR_PIPE trying to read/write the I2C-bus:
Osmocom-SDR\src\rtl_test.exe
Found 1 device(s):
0: Terratec T Stick PLUS
Using device 0: Terratec T Stick PLUS
librtlsdr.c(392): I2C addr C8: got 00, rd_len: -9, wr_len: -9
librtlsdr.c(394): Read error: LIBUSB_ERROR_PIPE, Pipe error
librtlsdr.c(396): Write error: LIBUSB_ERROR_PIPE, Pipe error
librtlsdr.c(392): I2C addr C6: got 00, rd_len: -9, wr_len: -9
...
No supported tuner found
Enabled direct sampling mode, input 1
Supported gain values (1): 0.0
----------------
What could be the reason for this? What else should I try?
--gv
Hello.
I have some build problem with building gr-igbalance with documentation
enabled. Build fails with a message saying that shell interpreter can't
execute Doxyfile. It is the same as I noticed some time ago while
building gr-osmosdr (see
http://lists.osmocom.org/pipermail/osmocom-sdr/2013-April/000553.html
). It was solved by the patch by Jaroslav Škarvada (
http://cgit.osmocom.org/gr-osmosdr/commit/?id=2f6592566bd60d2539f5b976dcf61…
).
Similar patch, attached, help for gr-iqbalance. It moves doxygen
detection test to toplevel CMakeLists.txt. Please add it to git
repository.
Wojciech Kazubski
Hi all,
I've been using rtl_fm piped into multimon-ng for a while now which
has been working pretty well for decoding POCSAG, I use this command
line:
rtl_fm -f 153.350M -r 22050 - | ./multimon-ng -t raw -a POCSAG512 -a
POCSAG1200 -a POCSAG2400 -f alpha -D pocsag.db -
I updated rtl_sdr today and now all I get is junk decodes
POCSAG2400-: Address: 1318769 Function: 255
POCSAG2400-: Alpha: KA^MA
POCSAG1200-: Address: 1700218 Function: 255
POCSAG1200-: Alpha: )"<DLE>'f
POCSAG1200-: Address: 143961 Function: 255
I rolled back to an earlier version using git checkout commit and it
appears the following commit broke it:
c4fcfbb46e0a432902a2b78db4951bd20f68b9b2
Commit 8c3a99c8f7a88d7d2a05845d4b20cfcdacac4054 works fine, whereas
the commit after causes multimon_ng to spit out garbage :-(
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,
I didn't find rtl_sdr with implemented direct sampling mode, so I made the patch. Also it has an option to set RTL AGC on.
This feature allows to use tuners as cheap data loggers without changing the schematic of the tuners. You can just connect wires directly to pins 1-2 of RTL2832 (I channel, diff. input) or pins 3-4 (Q channel, diff. input). When direct sampling mode is on - tuner's chip outputs are disabled and doesn't affect external signal.
For example, this command will write 8 bit samples to file 'mydata' at 2.4 MHz sampling rate with automatic gain:
rtl_sdr.exe -f 0 -s 2400000 -i -G mydata
Hope this will be useful for somebody as it was for me.
If you will accept the patch - please, update the windows binaries.
Thanks,
psb.
-------------------------------------------------------------------------------
diff --git a/src/rtl_sdr.c b/src/rtl_sdr.c
index eeb6dba..3564329 100644
--- a/src/rtl_sdr.c
+++ b/src/rtl_sdr.c
@@ -42,6 +42,7 @@
static int do_exit = 0;
static uint32_t bytes_to_read = 0;
static rtlsdr_dev_t *dev = NULL;
+static int samp_mode = 0;
void usage(void)
{
@@ -54,6 +55,9 @@ void usage(void)
"\t[-b output_block_size (default: 16 * 16384)]\n"
"\t[-n number of samples to read (default: 0, infinite)]\n"
"\t[-S force sync output (default: async)]\n"
+ "\t[-i set direct sampling mode (I)]\n"
+ "\t[-q set direct sampling mode (Q)]\n"
+ "\t[-G use RTL automatic gain]\n"
"\tfilename (a '-' dumps samples to stdout)\n\n");
exit(1);
}
@@ -81,6 +85,8 @@ static void sighandler(int signum)
static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
{
+ uint32_t i, r;
+ unsigned char *p1, *p2;
if (ctx) {
if (do_exit)
return;
@@ -91,7 +97,16 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
rtlsdr_cancel_async(dev);
}
- if (fwrite(buf, 1, len, (FILE*)ctx) != len) {
+ if (samp_mode) {
+ // For direct sampling mode we throw out each 2nd value,
+ // i.e., save only one channel data - I or Q.
+ for (i=0, p1=buf, p2=buf; i<len; i+=2, p2++)
+ *p1++ = *p2++;
+ r = (fwrite(buf, 1, len/2, (FILE*)ctx) == len/2);
+ } else
+ r = (fwrite(buf, 1, len, (FILE*)ctx) == len);
+
+ if (!r) {
fprintf(stderr, "Short write, samples lost, exiting!\n");
rtlsdr_cancel_async(dev);
}
@@ -119,8 +134,10 @@ int main(int argc, char **argv)
uint32_t out_block_size = DEFAULT_BUF_LENGTH;
int device_count;
char vendor[256], product[256], serial[256];
+ uint32_t use_rtlagc = 0;
+ unsigned char *p1, *p2;
- while ((opt = getopt(argc, argv, "d:f:g:s:b:n:S::")) != -1) {
+ while ((opt = getopt(argc, argv, "d:f:g:s:b:n:S::Gqi")) != -1) {
switch (opt) {
case 'd':
dev_index = atoi(optarg);
@@ -143,6 +160,15 @@ int main(int argc, char **argv)
case 'S':
sync_mode = 1;
break;
+ case 'q':
+ samp_mode = 2;
+ break;
+ case 'i':
+ samp_mode = 1;
+ break;
+ case 'G':
+ use_rtlagc = 1;
+ break;
default:
usage();
break;
@@ -205,6 +231,15 @@ int main(int argc, char **argv)
if (r < 0)
fprintf(stderr, "WARNING: Failed to set sample rate.\n");
+ /* Set direct sampling */
+ if (samp_mode) {
+ r = rtlsdr_set_direct_sampling(dev, samp_mode);
+ if (r < 0)
+ fprintf(stderr, "WARNING: Failed to set direct sampling mode.\n");
+ else
+ fprintf(stderr, "Tuner set to direct sampling mode (%c).\n", (samp_mode==1)?'I':'Q');
+ }
+
/* Set the frequency */
r = rtlsdr_set_center_freq(dev, frequency);
if (r < 0)
@@ -231,6 +266,21 @@ int main(int argc, char **argv)
fprintf(stderr, "Tuner gain set to %f dB.\n", gain/10.0);
}
+ /* Set RTL automatic gain */
+ if (1 == use_rtlagc) {
+ /* Enable automatic RTL gain */
+ r = rtlsdr_set_agc_mode(dev, 1);
+ if (r < 0)
+ fprintf(stderr, "WARNING: Failed to enable RTL automatic gain.\n");
+ else
+ fprintf(stderr, "RTL automatic gain enabled.\n");
+ } else {
+ /* Disable automatic RTL gain */
+ r = rtlsdr_set_agc_mode(dev, 0);
+ if (r < 0)
+ fprintf(stderr, "WARNING: Failed to disable RTL automatic gain.\n");
+ }
+
if(strcmp(filename, "-") == 0) { /* Write samples to stdout */
file = stdout;
#ifdef _WIN32
@@ -263,7 +313,16 @@ int main(int argc, char **argv)
do_exit = 1;
}
- if (fwrite(buffer, 1, n_read, file) != (size_t)n_read) {
+ if (samp_mode) {
+ // For direct sampling mode we throw out each 2nd value,
+ // i.e., save only one channel data - I or Q.
+ for (i=0, p1=buffer, p2=buffer; i<n_read; i+=2, p2++)
+ *p1++ = *p2++;
+ r = (fwrite(buffer, 1, n_read/2, file)== n_read/2);
+ } else
+ r = (fwrite(buffer, 1, n_read, file) == n_read);
+
+ if (!r) {
fprintf(stderr, "Short write, samples lost, exiting!\n");
break;
}
I heard someone recently made rtl-sdr work on an n900. Is it just
working drivers, or is it actually usable? I ask, because the
processor may not be up to the job.
Hey all.
I've been shouting it all over /r/rtlsdr and ##rtlsdr, but just for
you fine folks that are only on the ML, here[1] is what I've been up
to the past week:
Overhauled scanning in rtl_fm. This fixed a number of issues, where
either scanning did not work at all and some brokenness on OpenBSD.
It also meant giving up on the async API entirely.
Released a whole new application, rtl_power. This is something I'd
had bouncing around on my hard drive for many months, half-unwritten
due to over-complexity. It'll generate CSV files of arbitrarily
slow/wide/detailed FFTs. Also a little visualization script[2] that
won't choke when you give it 50,000 columns of data.
In the process of testing rtl_power, two more things came up. First
was windows builds. I've got a half-finished mingw32 build script[3]
that'll let me produce windows binaries[4] on a linux host. These
have been confirmed to actually run and probably work. Only W32 for
now, but just because I was too lazy to build the W64 toolchain.
Second was the discovery[5] that scanning had gotten a whole lot
slower since my original experiments with rtl_fm. 85mS to retune is
unacceptably slow. Since the r820t driver is the slowest, I started
looking into figuring out what is going on. Still figuring that out
but I have done basic cleanups to the code (removing redundancy,
particularly around register writes) and the driver is 15% shorter
with no modifications to code behavior.
I would not mind talking to Steve or one of the other devs on IRC
about some of the more ambiguous aspects of the driver. (Like, why
some reg writes are backed up to R828_Arry[] and others aren't. And
is that array thread safe at all? If not I'll have to do some very
large changes to support multiple dongles in rtl_power.)
I would really like to get these changes merged, particularly the
rtl_fm stuff because the version in the official repo is rather
bit-rotten.
-Kyle
http://kmkeen.com
[1] https://github.com/keenerd/rtl-sdr
[2] http://www.reddit.com/r/RTLSDR/comments/1ktzwi/
[3] http://kmkeen.com/tmp/mingw32.sh.txt
[4] http://kmkeen.com/tmp/rtl-sdr-mingw32-2013-08-28.zip
[5] http://www.reddit.com/r/RTLSDR/comments/1l2vlx/
single_manchester() considers both i and i+1, but the loop only
tests that i is in bounds. This causes undefined behavior, including
but not limited to a SIGBUS-related crash on Mac OS X.
---
src/rtl_adsb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 44b62e2..3c353a0 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -258,6 +258,7 @@ void manchester(uint16_t *buf, int len)
uint16_t a=0, b=0;
uint16_t bit;
int i, i2, start, errors;
+ int maximum_i = len - 1; // len-1 since we look at i and i+1
// todo, allow wrap across buffers
i = 0;
while (i < len) {
@@ -275,7 +276,7 @@ void manchester(uint16_t *buf, int len)
i2 = start = i;
errors = 0;
/* mark bits until encoding breaks */
- for ( ; i < len; i+=2, i2++) {
+ for ( ; i < maximum_i; i+=2, i2++) {
bit = single_manchester(a, b, buf[i], buf[i+1]);
a = buf[i];
b = buf[i+1];
--
1.8.3.4
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
I heard someone recently made rtl-sdr work on an n900. Is it just
working drivers, or is it actually usable? I ask, because the
processor may not be up to the job.
I have had great help before from this list, so many thanks for that.
I am using an ezcap tuner with a raspberry pi running a Debian based linux
OS called Raspbian. I have built the drivers from the git hub and they
work fine. As an aside, I found the installation much easier than when I
tried it directly on my PC.
My question is that I find that if I plug the USB device in when linux is
running, it causes a re-boot of the whole OS. (btw, disconnection has no
effect). Is this the case with full blown linux systems, or just some
peculiarity of the more limited raspberry pi? Also, it is a bit of a
nuisance, so does anyone know of a way to stop this?
many thanks Richard
