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...
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
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
Hi.
I noticed there is a 1 second delay in librtlsdr between calling
rtlsdr_cancel_async and releasing from rtlsdr_read_async. I'm writing a
radio scanner and this delay limits scanning speed considerably. I
tracked the delay down to this piece of code in librtlsdr.c:
while (RTLSDR_INACTIVE != dev->async_status) {
r = libusb_handle_events_timeout(dev->ctx, &tv);
[...]
if (RTLSDR_CANCELING == dev->async_status) {
next_status = RTLSDR_INACTIVE;
[...]
if (dev->dev_lost || RTLSDR_INACTIVE == next_status) {
>>>> libusb_handle_events_timeout(dev->ctx, &tv);
break;
}
The marked line is almost always(?) invoked when all the events are
already processed, hence it blocks for tv = 1 second. In fact I don't
understand what this `if' is supposed to do at all. I tried to modify
this line by changing the delay to 0 making it a non-blocking call
(leaving the timeout of 1 sec for the former
libusb_handle_events_timeout call). This worked with my project and the
1 second delay disappeared. So, I suppose, it's better to either a)
remove the whole `if' or b) make the latter libusb_handle_events_timeout
non-blocking as I did. I checked that b) works for me, and didn't test
a) yet.
The question is: what that `if (dev->dev_lost ...' is supposed to do?
And the two possible fixes for 1 second delay bug depending on the
answer are (diffs):
===
1630a1631
> struct timeval tv_nb = { 0, 0 };
1696c1697
< libusb_handle_events_timeout(dev->ctx, &tv);
---
> libusb_handle_events_timeout(dev->ctx, &tv_nb);
===
===
1694,1698d1693
<
< if (dev->dev_lost || RTLSDR_INACTIVE == next_status) {
< libusb_handle_events_timeout(dev->ctx, &tv);
< break;
< }
===
--
GPG fp: 6DFA 1186 7576 DE60 6CCB EB39 AD81 1733 EEBB 970A
I'm trying to write some code that uses a Raspberry Pi not just to capture
the samples, but also to do the DSP. The signal I'm working (aviation VOR)
is narrow and the DSP is not too hard-core, but it'll be easier if I can
sample at a lower rate.
Though rtlsdr_set_sample_rate returns no errors and rtlsdr_get_sample_rate
returns the same value I gave it (or quite close), it does not appear to be
working. I had been working at 250ksps but wanted to try 125ksps or even
62500sps, but none of those seem to work.
Is this just a limitation of the hardware?
I have a NooElec RTL2832 / R820T device if that matters.
Regards,
Dave J
Hello,
I heard a rumor from someone from industry that Realtek RTL2832u chip would soon be phased out and replaced by another chip (with lower sensitivity according to my contact).
Does anybody has more information about this ?
Regards
Mathias
Background:
Suppose you have four dongles. (That's easy for me. I do.) Suppose they
all identify as one of two types. (Three of one and one of the other.)
Suppose you want to load a specific dongle when you start the program.
And you don't want it to matter if you move the dongles around. How do I
do that?
Welllll, I hacked. Unfortunately rtlsdr.dll does not allow me to do this
even if I alter the serial numbers, at least not the way I want. There
is a fly in the rtlsdr ointment when fishing for the USB strings for
Manufacturer ID, product ID, and serial number. You must formally open
the device to read these values. The dongle can only be opened by one
opener at a time. Unfortunately SDRSharp is laid out inside such that
it searches for dongles whenever you open Config. And any time you open
Config you also have a dongle open. So far this is not too bad a problem.
If there's a dongle I cannot poll for strings, that's the one I have
open. Er, not so fast, Joanne. What if you have two or more copies open?
There will be more than one dongle you cannot poll.
I had to figure out how I could identify the dongle I have open even if
I move dongles. So I dug in and found some things libusb.dll can do. The
chief one is get the USB path for the dongle. And it can do that without
actually opening the dongle. Now when filling out the dialog if I cannot
read strings for a dongle I get the dongle's path from the device list
used and by cheating on the device handle rtlsdr.dll hands out for opened
dongles I extracted information I needed to get the path that way. If they
compare it's obviously my dongle. If they do not compare it's another
dongle that is already opened so I don't show it in the list.
Request:
Please implement two new entry points which expose the libusb_get_port_path
functionality, one by index (same as for strings) and one for rtlsdr
handle which I finessed to prove the technique above. The libusb_get_device
function will take the device handle and spit out the device list
entry that matches the handle.
Thanks for considering this.
{^_^} Joanne/W6MKU
