Just an idea, really, I don't know how complex the decoding is. Or rtl_fm for Android?
Just got an upconverter for my dongle, sitting here listening to music from faraway exotic places on HF. Using rtlsdr.dll with SDR#.
Alan
-----
Radio Astronomy - the ultimate DX
I am pleased to announce I have released an RTL2832U driver for android for
the benefit of all of the developers working on SDR.
The app could be found here
https://play.google.com/store/apps/details?id=marto.rtl_tcp_andro
And the sources are released under GPL2+ here
https://github.com/martinmarinov/rtl_tcp_andro-
So how do you use it in case you want to develop your own Android
application that uses rtl_tcp_andro?
It's quite simple, you need to add just one line of code to your existing
Android app (assuming the user has the driver installed).
*startActivityForResult(new
Intent(Intent.ACTION_VIEW).setData(Uri.parse("iqsrc://-a 127.0.0.1 -p 123",
START_REQ_CODE);*
Where START_REQ_CODE is a random number you assign. This will start
rtl_tcp_andro on the localhost at port 123. As you see the thing after
iqsrc:// is just the command line arguments you pass to a regular rtl_tcp.
If you want to be more fancy and do error capture, you should override this
method in your Android activity and perform error detection as so:
*@Override*
* protected void onActivityResult(final int requestCode, final int
resultCode, final Intent data) {*
*
*
* runOnUiThread(new Runnable() {*
*
*
* @Override*
* public void run() {*
* if (requestCode == START_REQ_CODE) {*
* if (resultCode == RESULT_OK) { // rtl_tcp_andro has been started
successfully!}*
* else {*
*
*
* try {*
* switch (data.getIntExtra("marto.rtl_tcp_andro.RtlTcpExceptionId", -1)) {*
* case 0:*
* // exception - permission denied*
* break;*
* case 1:*
* // exception - root required*
* break;*
* case 2:*
* // exception - no devices found*
* break;*
* case 4:*
* // exception - the user needs to reconnect the device*
* break;*
* default:*
* // unknown exception*
* break;*
* }*
* } catch (Exception e) {}*
* }*
* }*
* }*
* });*
* }*
It is that simple! rtl_tcp_andro will take care of showing different
dialogs to the user for device selection. It will also take care of
non-rooted devices by communicating with rtl_tcp_androi and sending the
appropriate file descriptors, etc. You don't need to worry about all of the
magic that is happening in the background - you only need to monitor the
result of your intent request.
If you get *RESULT_OK* then you are ready to go. Now what remains is to
implement your own TCP client that connects to the appropriate host/port
number and communicates using the *rtl_tcp* protocol. Make sure you send
the additional "exit" command that rtl_tcp_andro has in order not to leave
zombie services behind.
That's all if you have any questions, feel free to contact me! Sorry for
the bad state of the source code of rtl_tcp_andro, I will add comments as
time passes by.
Hope to see great new projects on the Android platform :)
Thanks,
Martin
Hi ben,
Thanks, glad you like the scanner although I realise it's a bit of a
pain to install all the dependencies under Windows or OS X.
I intended the software to be used to find interesting signals, which
you could then analyse in other software, never really as a spectrum
analyser (the thought of implementing all the maths gives me a
headache!). Once I've found something I often use sdrsharp to
investigate it and if I'm still interested I move onto GNU Radio.
I would really recommend you try GNU Radio, although you may find it has
a steep learning curve. For example you could use VirtualBox
(virtualbox.org) to run an Ubuntu machine on your desktop (compiling
under Windows can be tricky) . There's plenty of information on both
virtual machines and GNU Radio installation around.
Good luck,
Al
> Message: 2
> Date: Wed, 23 Jan 2013 00:45:08 +1100
> From: Ben Ryan <benryanau(a)hotmail.com>
> To: <osmocom-sdr(a)lists.osmocom.org>
> Subject: RE: RTL-SDR Scanner/Plotter (Al)
> Message-ID: <SNT139-W63EB2510A068891AA8A25B6160(a)phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hey mate this looks really great!
> I've dreamed about building something similar for an RTLSDR, but much fancier (ping-pong on 'interesting' chirps, yo-yo sweeps to find voice/burst comms, trended plots etc etc). A poor man's wideband spectrum analyser. But I can't code to save my life..
> However, wait long enough and funny things happen :) You've made a great start with this project, especially given there was NOTHING out there prior (that I've seen anyhow. Certainly for Win32.)
> All the module/package dependencies are a bit of a pain but hey, you've got a working app :)
> Love to try it soon when I get a chance, hope you develop it up into a full-bllown RTLSDR spectrum analyser / "interesting signal" finder!
>
> Cheers
> ben
>
>
>> Message: 1
>> Date: Mon, 21 Jan 2013 16:53:01 +0000
>> From: Al <al(a)eartoearoak.com>
>> To: osmocom-sdr(a)lists.osmocom.org
>> Subject: RTL-SDR Scanner/Plotter
>> Message-ID: <50FD726D.5010000(a)eartoearoak.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Hi,
>>
>> I thought you may be interested in a program I've written, it's a Python
>> GUI which scans a set of frequencies and plots the resulting levels,
>> which can be saved for later viewing or exported to a CSV file.
>>
>> Source: https://github.com/EarToEarOak/RTLSDR-Scanner
>> More info: http://www.eartoearoak.com/software/rtlsdr-scanner
>>
>> I wrote it to help me find signals over a wide bandwidth, to get a
>> better view of the RF space. I hope you find it useful.
>>
>> Al
Hi,
I thought you may be interested in a program I've written, it's a Python
GUI which scans a set of frequencies and plots the resulting levels,
which can be saved for later viewing or exported to a CSV file.
Source: https://github.com/EarToEarOak/RTLSDR-Scanner
More info: http://www.eartoearoak.com/software/rtlsdr-scanner
I wrote it to help me find signals over a wide bandwidth, to get a
better view of the RF space. I hope you find it useful.
Al
I have installed these using the procedures shown in the wiki. I didn’t see
any errors during the installation. The packages are on the computer but
they are not listed amongst the sources on GNU Radio Companion.
If I type in the terminal rtl_test –t I get:
Found 1 device(s):
0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
usb_open error -3
Failed to open rtlsdr device #0
Any suggestions?
Many thanks,
Al
Hi all,
I would like to congratulate you on the great job you did with rtl-sdr and
I am really admiring you work!
I am the developer of SDR Touch,
I received a copyright violation notice from one of the developers.
I wanted to point out that rtl_tcp_andro and SDR Touch are completely
separate binaries in the aggregate called SDRTouch.apk. They are never
linked together - neither before, nor after the unrar-ing of the apk onto
the user's Android device. They communicate via TCP. Once the installation
of the apk is over, the binaries and rtl_tcp_andro reside in completely
different directories on the Android device.
rtl_tcp_andro is a derivative work of rtl_tcp and is released under GPL2+ -
https://github.com/martinmarinov/rtl_tcp_andro- (In order to honour GPL you
can actually visit this webiste via the Help message that you see on SDR
Touch).
rtl_tcp_andro is merely started using Runtime.exec() command. It is never
linked - neither statically nor dynamically. Furthermore SDR Touch can
happily work without the local rtl_tcp and this is there only for user's
convenience. SDR Touch can function over the network without requiring a
local rtl_tcp.
Since SDR Touch and rtl_tcp are completely separate works, and the user is
aware of the license of rtl_tcp_andro and has access to its source code,
SDR Touch does not violate GPL2+. It is true they reside in the same
installer before being installed on the device, but this is allowed in GPL3
and is called an aggregate.
Does it make sense? Is there anything I can do so we can settle this issue
once and for all?
Thanks,
Martin
Hey mate this looks really great!
I've dreamed about building something similar for an RTLSDR, but much fancier (ping-pong on 'interesting' chirps, yo-yo sweeps to find voice/burst comms, trended plots etc etc). A poor man's wideband spectrum analyser. But I can't code to save my life..
However, wait long enough and funny things happen :) You've made a great start with this project, especially given there was NOTHING out there prior (that I've seen anyhow. Certainly for Win32.)
All the module/package dependencies are a bit of a pain but hey, you've got a working app :)
Love to try it soon when I get a chance, hope you develop it up into a full-bllown RTLSDR spectrum analyser / "interesting signal" finder!
Cheers
ben
> Message: 1
> Date: Mon, 21 Jan 2013 16:53:01 +0000
> From: Al <al(a)eartoearoak.com>
> To: osmocom-sdr(a)lists.osmocom.org
> Subject: RTL-SDR Scanner/Plotter
> Message-ID: <50FD726D.5010000(a)eartoearoak.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> I thought you may be interested in a program I've written, it's a Python
> GUI which scans a set of frequencies and plots the resulting levels,
> which can be saved for later viewing or exported to a CSV file.
>
> Source: https://github.com/EarToEarOak/RTLSDR-Scanner
> More info: http://www.eartoearoak.com/software/rtlsdr-scanner
>
> I wrote it to help me find signals over a wide bandwidth, to get a
> better view of the RF space. I hope you find it useful.
>
> Al
>
Hello,
I am using cygwin with Windows XP but I do not have a good
understanding of the Windows OS. I could do with some advice about how
the usb driver for the RTL2832U device is meant to be located by the
rtl_sdr.c program using the libusb library.
For me this program fails with a libusb_open() error of -12. Using the
debugger I can see this is due to no driver being found for the
RTL2832U device.
When the function get_api_type() in windows_usb.c is called it
consults the registry for a driver name for the device. In my case it
finds RTL2832UUSB and RTL2832UBDA but I suppose this just depends on
what is sitting in the registry. Subsequently the program checks to
see if the driver name is WINUSB or USBCCGP. Because it is not the
program cannot work.
Am I meant to ensure either WINUSB or USBGCCP drivers are installed on
my computer and must the registry entry for the RTL2832U device point
to one of these? If so, is there a recommended procedure to do that?
Thanks for any advice
Robert Durkacz
Hi,
You should know that the fw is being rewritten ( branch mci-rewrite ),
to use the MCI interface for data transfer, allowing up to 4 MHz
transfer.
But this will require a HW mod to be detailled later.
Cheers,
Sylvain
As a new user of GNU radio with a couple RTL2832 dongles to play with I
used the build-gnuradio script to install on Fedora 16 and Ubuntu
12.04. The Fedora install worked fine; but the Ubuntu one produced this:
lemur4[18]$ rtl_test
Found 1 device(s):
0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Elonics E4000 tuner
Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0
21.5 24.0 29.0 34.0 42.0
Reading samples in async mode...
cb transfer status: 1, canceling...
Library error 0, exiting...
Segmentation fault (core dumped)
The traceback showed the fault to occur in libusb1, and seemed similar
to the issue discussed at
http://lists.gnumonks.org/pipermail/osmocom-sdr/2012-August/000201.html
I noticed this patch at the head of master touched the same general part
of the code.
commit 3cbf1392612a0c6f02ec178f8e78568138f12b0a
Author: Hoernchen <la(a)tfc-server.de>
Date: Wed Jan 16 20:03:00 2013 +0100
exit if our usb device disappears
Reverting this change fixed the issue.
Peter
Hi,
In reading the directions for rtl-sdr installation, I'm curious if following line in the Software section (http://sdr.osmocom.org/trac/wiki/rtl-sdr#Softwarer):
"Please note: prior pulling a new version from git and compiling it,
please do a "make uninstall" first to properly remove the previous
version"
means to uninstall my gnuradio installation, or if I have one, just the rtl-sdr software?
I don't have any rtl-sdr software installed yet, but I do have a recent gnuradio installed (v3.6.?) on Ubuntu 12.10. Thanks for your help.
'73' Mike, KB1QVO
Sir:
If you look in the place where you built gr-osmosdr, you will find a
file called install_manifest.txt which contains where it put all the
files. The rtlsdr_source_c.xml and osmosdr_source_c.xml (which are
files that describe the sources, both of which produce streams of
complex numbers, which is what the naming convention means) are how the
gnuradio companion knows how to use those sources.
Do a "sudo make uninstall" where you built gr-osmosdr, and then start
over with gr-osmosdr. But this time, instead of just running "cmake"
with no options, use the command:
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
You "define" (that's what "-D" means) the value "CMAKE_INSTALL_PREFIX"
to be /usr. If you don't define it to be something, it will use the
default value of "/usr/local"
I have a Web page with partial instructions (it's not intended to be a
Linux introduction, although I will do my best to answer specific
questions if you have any) and some other stuff on it:
http://www.ka8kpn.org/sdr-dongle.html
Oh, and while I'm thinking about it, I really detest mailing lists whose
default action on a reply is to write directly to the person to whom you
are responding rather than to the list. To me, it is optimizing the
atypical case and it makes far more sense to optimize for what everyone
nearly always wants to do. That is, it may be technically correct, but
it is definitely the wrong thing to do. However, I know I've lost that
battle, so I'll not mention it again.
On 01/12/2013 03:24 PM, tokens(a)myranch.com wrote:
> Hi Jonathan,
>
> Please excuse my ignorant comments and questions but I am very much a
> Linux novice.
>
> I see that there are directories for gr-osmosdr, rtl-sdr, and uhd
> under home directory. Under usr/local/share/gnuradio/grc/blocks/ I
> find osmosdr_source_c.xml and rtlsdr_source_c.xml. Directories for
> gnuradio are under usr/etc and usr/include. I guess this is what you
> mean by some bits of gr-osmosdr and rtlsdr end up in usr/local. How do
> I force cmake to install the software into /usr.
>
> Thank you very much.
>
> Regards,
> Al
>
> -----Original Message----- From: Jonathan Guthrie
> Sent: Saturday, January 12, 2013 2:18 PM
> To: tokens(a)myranch.com
> Subject: Re: rtl-sdr and gr-osmosdr
>
> On 01/12/2013 09:03 AM, tokens(a)myranch.com wrote:
>> I have installed these using the procedures shown in the wiki. I
>> didn’t see any errors during the installation. The packages are on
>> the computer but they are not listed amongst the sources on GNU Radio
>> Companion.
>> If I type in the terminal rtl_test –t I get:
>> Found 1 device(s):
>> 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
>>
>> Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
>> usb_open error -3
>> Failed to open rtlsdr device #0
>>
>> Any suggestions?
>>
>
> I installed GNURadio as packaged by my distribution, and I did the
> "cmake; make; sudo make install" that I found, and I got the symptoms
> you described. The problem I had is that packaged software normally
> gets installed into /usr and the "cmake, etc" procedure installs it's
> software into /usr/local. That meant that grc was looking in the wrong
> place to find the gr-osmosdr bits.
>
> Telling cmake to install the software into /usr fixed my problem. Could
> it possibly fix yours?
>
>
Using Sudo, as suggested by two readers, takes care of the rtl_test problem.
However, I still don’t have the OsmoSDR and RTLSDR source blocks appearing in GNU Radio Companion.
Thank you.
Al
I like adsbScope under Windows, but is there anything similar for unix? Hopefully something free that takes a tcp feed.
Alan
-----
Radio Astronomy - the ultimate DX
Greetings,
I noticed today that rtl_source_c::get_freq_range() returns an empty
range for all but E4000 tuners. Is it due to lack of information? I
have dongles with R820T and FCI2580 tuners that I can measure the
usable ranges for if needed.
Alex
Is this from Windows or something? In unix it's sleep, not Sleep, and it only takes ints or something similar.
I have a native (OpenBSD) usleep so I ifdefed:
#ifdef _WIN32
#define usleep(x) Sleep(x/1000)
#endif
It didn't affect my problem but it made me feel better.
Alan
-----
Radio Astronomy - the ultimate DX
With rtl_fm, I get a tiny burst of audio about once a minute.
My dongle is a vendor ID 0x0bda, product ID0x2838 from http://www.amazon.com/gp/browse.html?ie=UTF8&marketplaceID=ATVPDKIKX0DER&me…
I did:
rtl_fm -f 88500000 - | play -t raw -r 24k -e signed-integer -b 16 -c 1 -V1 -
I got:
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
-: (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
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 88752000 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.68 [00:00:00.00] Out:16.4k [ =====|===== ] Clip:0
^CSignal caught, exiting!
The dongle works if I boot into Windows, but in OpenBSD I can't get anything out of it. I'm still trying to get dependencies for Gnuradio together. The only odd thing is that being OpenBSD, there's no -lrt when I link. Those functions are built into something else so I compile without the -lrt. There isn't an -lrt library.
I've tried writing little scripts to run it so I do it consistently. My wide FM one:
#!/bin/sh
rtl_fm -W -l 0 -f 88500000 - | play -t raw -r 32000 -e signed-integer -b 16 -c 1 -V4 -
Narrow:
#!/bin/sh
rtl_fm -N -l 0 -f 162550000 - | play -t raw -r 32k -e signed-integer -b 16 -c 1 -V4 -
I've played with various options. If I use -R it runs for a long time with lots of data by Sox's meter, but I don't hear anything. If I pipe it to a file (without -R) the file is very small and grows slowly, not what I would expect from audio. I just grabbed a fresh copy by git yesterday but it works about the same.
A fresh run:
freebie# rtl_fm -N -f 162550000 - | play -t raw -r 32k -e signed-integer -b 16 -c 1 -V 4 -
Found 1 device(s):
play: SoX v14.3.2
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.
Signal caught, exiting!
I don't have much idea what's going on, but I'm tempted to try opening it from a pipe (in C) to see if I can capture anything more.
Alan
-----
Radio Astronomy - the ultimate DX
Happy New Year to Everyone ....
I am thinking this may be more of an issue with rtl_tcp than with the
client software (SDR#) so I thought I would throw this out there and see
if anyone has any ideas.
I have a Ham-it-Up up converter connected to an EZcap 668 (e4000) dongle
and am using a random length long wire antenna all connected on a remote
linux server (with minimal OS install) where I am running rtl_tcp. I am
starting rtl_tcp using the following command: rtl_tcp -a
192.168.110.220 -p 1236 -d 2
When I connect to the remote dongle/converter using SDRSharp with
RTL-USB/TCP I get nothing but static / noise. If I put the converter in
bypass mode, then SDRSharp and my dongle perform with the typical
performance I have experienced in the past.
If I move the same dongle and up converter combo to the same pc running
SDRSharp and connect to the dongle using RTL-SDR/USB I am able to
receive many HF signals, as one would expect. For example, CHU Canada,
WWV, some local CB radio chatter and even our local airport's LF beacon
at 329 KHZ.
I also tried starting rtl_tcp with the -g option and setting a gain to
try to match the gain options available under RTL-SDR/USB but that had
no effect.
I am just wondering if I am not finding the correct settings so this
will work or if this is an issue with rtl_tcp?
BTW:
I actually have two other Ezcap 668's running simultaneously on the
remote linux server as device 0 / port 1234 and device 1 / port 1235
working just fine when connected to other remote instances of SDR Sharp.
73's - Dave
KD9GN