From alancorey at yahoo.com  Tue Jan  1 04:15:22 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Mon, 31 Dec 2012 20:15:22 -0800 (PST)
Subject: Trying to use rtl_fm, etc
In-Reply-To: <50E13085.5090901@shikadi.net>
References: <1356931764.86318.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<50E13085.5090901@shikadi.net>
Message-ID: <1357013722.80976.YahooMailNeo@web161502.mail.bf1.yahoo.com>

I've tried matching the sample rates, it doesn't seem to make much difference. I just didn't happen to have saved the text from one of those.

I've also tried the -r option, but I didn't hear anything and I wasn't sure it was sending "raw" audio and not I/Q signals.? It acted better, aside from that: the progress meter in Play was responding constantly like it was getting more audio and the file sizes were more like what I'd expect.? With the bursting, I get 16k every minute, which is way too short.

I wrote some C to import one of the files and export as ascii, then make a Gnuplot file to plot it.? There's a sample at:
http://ab1jx.webs.com/toys/dongle/wfm2_dat3.gif (The X axis labels are data point numbers.)
It looks like audio, but I see something in the output about a 6 millisecond sample buffer. That's possibly how much sound I get, and this sample is from the local NPR station so I don't know what they were doing at that instant, music or voice.? I also haven't tried plotting I/Q output so I don't know what that looks like.

Yes, my sound works and playing a wav file with Play (Sox) works.? I normally work at 8000 samples/second mono.? No Linux sound to get in the way here (OpenBSD). From reading, it doesn't make sense to have the RF sampling rate the same as the audio sampling rate (I think) but that's what it defaults to.


?OK, it helps to be reassured that somebody actually uses this and has it working.? I'll mess with sampling rates and raw mode.? Some real documentation for these programs would be a help.

? Alan

-----
Radio Astronomy - the ultimate DX



----- Original Message -----
> From: Adam Nielsen <a.nielsen at shikadi.net>
> To: Alan Corey <alancorey at yahoo.com>
> Cc: "osmocom-sdr at lists.osmocom.org" <osmocom-sdr at lists.osmocom.org>
> Sent: Monday, December 31, 2012 1:28 AM
> Subject: Re: Trying to use rtl_fm, etc
> 
>>  With rtl_fm, I get a tiny burst of audio about once a minute.
>> 
>>  A fresh run:
>>  freebie# rtl_fm -N -f 162550000 - | play -t raw -r 32k -e signed-integer -b 
> 16
>>  -c 1 -V 4 -
> 
> Just FYI, you can see here that:
> 
>>  Output at 24000 Hz.
> 
> However you have told 'play' to play the audio at a sampling rate of 
> 32kHz, even though the audio data is only arriving at 24kHz.? So you will get 
> stuttering as the audio buffer keeps running out and waiting for more data to 
> arrive.
> 
> For me (under Linux), I get best results using the -r option to rtl_fm to set 
> the output audio sampling rate to 48kHz, then tell play to play at 48kHz too.? 
> This way my system doesn't have to resample it to 48kHz before it can mix 
> the stream into the system-wide audio output.
> 
> Note that the -s option sets the signal bandwidth and -r sets the output audio 
> sampling rate.? A lot of people misunderstand the purpose of the -s option, 
> however you shouldn't need it unless you are trying to receive data signals. 
> -W and -N set -s to the correct values for voice transmissions.
> 
> I would also suggest playing a .wav file with the same 'play' options 
> just to make sure your system can play mono audio at low sampling rates.? I know 
> my sound card drivers won't (possibly because I am using a SPDIF connection 
> to an external amplifier) so I need the Linux audio system to upmix it to 48kHz 
> 16-bit stereo or I won't hear anything.
> 
> Cheers,
> Adam.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121231/5bb2588f/attachment.htm>

From absolut_ro at yahoo.com  Tue Jan  1 08:42:27 2013
From: absolut_ro at yahoo.com (ab ni)
Date: Tue, 1 Jan 2013 00:42:27 -0800 (PST)
Subject: RTL2832
Message-ID: <1357029747.19860.YahooMailNeo@web160106.mail.bf1.yahoo.com>

Hi,
Does anyone technical documentations about RTL2832U? ?

soso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130101/5b8dd2fa/attachment.htm>

From oz9aec at gmail.com  Tue Jan  1 19:42:59 2013
From: oz9aec at gmail.com (Alexandru Csete)
Date: Tue, 1 Jan 2013 20:42:59 +0100
Subject: gr-osmosdr frequency range for rtlsdr
Message-ID: <CAHG=S_dO-+yiK0Y8GL+r_mJRWw8-+ruBTvn6XUjpyo_oRMQfbA@mail.gmail.com>

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



From horiz0n at gmx.net  Tue Jan  1 20:45:02 2013
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Tue, 01 Jan 2013 21:45:02 +0100
Subject: gr-osmosdr frequency range for rtlsdr
In-Reply-To: <CAHG=S_dO-+yiK0Y8GL+r_mJRWw8-+ruBTvn6XUjpyo_oRMQfbA@mail.gmail.com>
References: <CAHG=S_dO-+yiK0Y8GL+r_mJRWw8-+ruBTvn6XUjpyo_oRMQfbA@mail.gmail.com>
Message-ID: <op.wp82lc0kvay7ep@wopr.artelis.net>

Hi Alex,

> 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

Yes, unfortunately.

> have dongles with R820T and FCI2580 tuners that I can measure the
> usable ranges for if needed.

If you can provide the numbers i will add them to the implementation. It  
seems that at least for the E4000 tuner these numbers will vary by some  
10MHz dependent on temperature.


Best regards,

Dimitri



From kd9gn at lolling.org  Tue Jan  1 20:58:43 2013
From: kd9gn at lolling.org (KD9GN)
Date: Tue, 01 Jan 2013 20:58:43 +0000
Subject: Remote SDR# connection to Ham-It-Up HF Converter using RTL-SDR/TCP
	- Receiver is Deaf
Message-ID: <50E34E03.8020403@lolling.org>

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





From steve at steve-m.de  Tue Jan  1 22:03:02 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Tue, 01 Jan 2013 23:03:02 +0100
Subject: gr-osmosdr frequency range for rtlsdr
In-Reply-To: <op.wp82lc0kvay7ep@wopr.artelis.net>
References: <CAHG=S_dO-+yiK0Y8GL+r_mJRWw8-+ruBTvn6XUjpyo_oRMQfbA@mail.gmail.com>
	<op.wp82lc0kvay7ep@wopr.artelis.net>
Message-ID: <50E35D16.9030203@steve-m.de>

Hi,

On 01.01.2013 21:45, Dimitri Stolnikov wrote:

> If you can provide the numbers i will add them to the implementation. It
> seems that at least for the E4000 tuner these numbers will vary by some
> 10MHz dependent on temperature.

For the E4K: Not only by temperature, also for each batch of chips, so
for the corner frequencies of the range you should just try to tune and
look at the return value if it suceeded.

As for the other tuners: We have list in the wiki, which we could
implement:
http://sdr.osmocom.org/trac/wiki/rtl-sdr#Specifications

Regards,
Steve



From alancorey at yahoo.com  Wed Jan  2 04:08:52 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Tue, 1 Jan 2013 20:08:52 -0800 (PST)
Subject: Trying to use rtl_fm, etc
In-Reply-To: <50E13085.5090901@shikadi.net>
References: <1356931764.86318.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<50E13085.5090901@shikadi.net>
Message-ID: <1357099732.21656.YahooMailNeo@web161504.mail.bf1.yahoo.com>

Still no luck.? If I use -R for raw mode a little more data gets through (as seen by file sizes or the Play progress meter) but it seems to be less intelligible if anything.?? When I write to a file, the size is always in chunks of 16384 bytes (0x4000 or 2^14).? At a sample rate of 24000 that's 1/3 second, which is about right compared to what I hear. Without using -R, this doesn't repeat for about a minute.? That 16384 must be some buffer size or something in the rtl_fm program, but I haven't found it yet.? I think this is supposed to repeat often enough to be continuous.? Could computer speed be an issue?? I'm on a single core P4 at 3.2 GHz.


From? rtl_fm -f 146970000 -f 146985000 -f 146910000 -f 146940000 scan2.dat I got this which looks like bursts of noise as rtl_fm is scanning, still all within about 1/3 second:

http://ab1jx.webs.com/toys/dongle/scan2.dat.gif

There's a curious ripple in the baseline which doesn't quite look like power supply ripple, more like something from some filter.

? Alan

-----
Radio Astronomy - the ultimate DX



----- Original Message -----
> From: Adam Nielsen <a.nielsen at shikadi.net>
> To: Alan Corey <alancorey at yahoo.com>
> Cc: "osmocom-sdr at lists.osmocom.org" <osmocom-sdr at lists.osmocom.org>
> Sent: Monday, December 31, 2012 1:28 AM
> Subject: Re: Trying to use rtl_fm, etc
> 
>>  With rtl_fm, I get a tiny burst of audio about once a minute.
>> 
>>  A fresh run:
>>  freebie# rtl_fm -N -f 162550000 - | play -t raw -r 32k -e signed-integer -b 
> 16
>>  -c 1 -V 4 -
> 
> Just FYI, you can see here that:
> 
>>  Output at 24000 Hz.
> 
> However you have told 'play' to play the audio at a sampling rate of 
> 32kHz, even though the audio data is only arriving at 24kHz.? So you will get 
> stuttering as the audio buffer keeps running out and waiting for more data to 
> arrive.
> 
> For me (under Linux), I get best results using the -r option to rtl_fm to set 
> the output audio sampling rate to 48kHz, then tell play to play at 48kHz too.? 
> This way my system doesn't have to resample it to 48kHz before it can mix 
> the stream into the system-wide audio output.
> 
> Note that the -s option sets the signal bandwidth and -r sets the output audio 
> sampling rate.? A lot of people misunderstand the purpose of the -s option, 
> however you shouldn't need it unless you are trying to receive data signals. 
> -W and -N set -s to the correct values for voice transmissions.
> 
> I would also suggest playing a .wav file with the same 'play' options 
> just to make sure your system can play mono audio at low sampling rates.? I know 
> my sound card drivers won't (possibly because I am using a SPDIF connection 
> to an external amplifier) so I need the Linux audio system to upmix it to 48kHz 
> 16-bit stereo or I won't hear anything.
> 
> Cheers,
> Adam.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130101/a6b7b6d2/attachment.htm>

From alancorey at yahoo.com  Wed Jan  2 04:19:03 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Tue, 1 Jan 2013 20:19:03 -0800 (PST)
Subject: Why is there Sleep() in rtl_fm?
Message-ID: <1357100343.73598.YahooMailNeo@web161501.mail.bf1.yahoo.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130101/053ac0b0/attachment.htm>

From oz9aec at gmail.com  Wed Jan  2 21:35:15 2013
From: oz9aec at gmail.com (Alexandru Csete)
Date: Wed, 2 Jan 2013 22:35:15 +0100
Subject: gr-osmosdr frequency range for rtlsdr
In-Reply-To: <50E35D16.9030203@steve-m.de>
References: <CAHG=S_dO-+yiK0Y8GL+r_mJRWw8-+ruBTvn6XUjpyo_oRMQfbA@mail.gmail.com>
	<op.wp82lc0kvay7ep@wopr.artelis.net> <50E35D16.9030203@steve-m.de>
Message-ID: <CAHG=S_dSwogBJMBwuEkWw_9MnZ9HwFw6m8L+5T62_1XuuvTCLg@mail.gmail.com>

On Tue, Jan 1, 2013 at 11:03 PM, Steve Markgraf <steve at steve-m.de> wrote:
> Hi,
>
> On 01.01.2013 21:45, Dimitri Stolnikov wrote:
>
>> If you can provide the numbers i will add them to the implementation. It
>> seems that at least for the E4000 tuner these numbers will vary by some
>> 10MHz dependent on temperature.
>
> For the E4K: Not only by temperature, also for each batch of chips, so
> for the corner frequencies of the range you should just try to tune and
> look at the return value if it suceeded.
>
> As for the other tuners: We have list in the wiki, which we could
> implement:
> http://sdr.osmocom.org/trac/wiki/rtl-sdr#Specifications
>

Dimitri made the changes yesterday according to the wiki and they work
great. Thanks for the quick response.
I came to think of what to do about direct sampling mode - one could
consider adding a "no tuner" option and return 0-28MHz range in that
case.

Thanks again!

Alex



From alancorey at yahoo.com  Sat Jan  5 05:14:11 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Fri, 4 Jan 2013 21:14:11 -0800 (PST)
Subject: Plane plotting software for unix?
Message-ID: <1357362851.62434.YahooMailNeo@web161501.mail.bf1.yahoo.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130104/66faf27d/attachment.htm>

From limaunion at fibertel.com.ar  Sat Jan  5 14:53:50 2013
From: limaunion at fibertel.com.ar (Limaunion)
Date: Sat, 05 Jan 2013 11:53:50 -0300
Subject: Plane plotting software for unix?
In-Reply-To: <1357362851.62434.YahooMailNeo@web161501.mail.bf1.yahoo.com>
References: <1357362851.62434.YahooMailNeo@web161501.mail.bf1.yahoo.com>
Message-ID: <50E83E7E.1000607@fibertel.com.ar>

On 01/05/2013 02:14 AM, Alan Corey wrote:
> 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

Hi, I'm using virtualradarserver with the mono framework and rtl_adsb 
under Debian, check this site:

http://www.virtualradarserver.co.uk/Mono.aspx

HTH
LU



From spinoinside at gmail.com  Sat Jan  5 17:53:14 2013
From: spinoinside at gmail.com (=?UTF-8?B?c3Bpbm9pbnNpZGXimI4=?=)
Date: Sat, 05 Jan 2013 18:53:14 +0100
Subject: Plane plotting software for unix?
In-Reply-To: <50E83E7E.1000607@fibertel.com.ar>
References: <1357362851.62434.YahooMailNeo@web161501.mail.bf1.yahoo.com>
	<50E83E7E.1000607@fibertel.com.ar>
Message-ID: <50E8688A.5020508@gmail.com>

Il 05/01/2013 15:53, Limaunion ha scritto:
> On 01/05/2013 02:14 AM, Alan Corey wrote:
>> 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
>
> Hi, I'm using virtualradarserver with the mono framework and rtl_adsb
> under Debian, check this site:
>
> http://www.virtualradarserver.co.uk/Mono.aspx
>
> HTH
> LU
>
>
watch this video:
https://www.youtube.com/watch?v=WLBW5gxrzI4

bye
Spinoinside



From alancorey at yahoo.com  Sun Jan  6 05:06:21 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Sat, 5 Jan 2013 21:06:21 -0800 (PST)
Subject: Plane plotting software for unix?
In-Reply-To: <50E83E7E.1000607@fibertel.com.ar>
References: <1357362851.62434.YahooMailNeo@web161501.mail.bf1.yahoo.com>
	<50E83E7E.1000607@fibertel.com.ar>
Message-ID: <1357448781.88229.YahooMailNeo@web161506.mail.bf1.yahoo.com>

Thanks, but frankly it sounds easier (and more fun) to start from scratch.? Using rtl_adsb as a demodulator, then working out how to get latitude and longitude out of the packets. I think maybe there's enough information in ADS-B For Dummies but I've only glanced through it.

?Alan


-----
Radio Astronomy - the ultimate DX



----- Original Message -----
> From: Limaunion <limaunion at fibertel.com.ar>
> To: osmocom-sdr at lists.osmocom.org
> Cc: 
> Sent: Saturday, January 5, 2013 9:53 AM
> Subject: Re: Plane plotting software for unix?
> 
> On 01/05/2013 02:14 AM, Alan Corey wrote:
>>  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
> 
> Hi, I'm using virtualradarserver with the mono framework and rtl_adsb 
> under Debian, check this site:
> 
> http://www.virtualradarserver.co.uk/Mono.aspx
> 
> HTH
> LU
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130105/96ecadac/attachment.htm>

From tokens at myranch.com  Sat Jan 12 15:03:53 2013
From: tokens at myranch.com (tokens at myranch.com)
Date: Sat, 12 Jan 2013 10:03:53 -0500
Subject: rtl-sdr and gr-osmosdr
Message-ID: <D0F5DFB61736461B8D0B18C896179089@AlPC>

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 




From tokens at myranch.com  Sat Jan 12 18:51:49 2013
From: tokens at myranch.com (tokens at myranch.com)
Date: Sat, 12 Jan 2013 13:51:49 -0500
Subject: rtl-sdr and gr-osmosdr
Message-ID: <CAEFD53EC34847D38D768309ECC57472@AlPC>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130112/abdc032e/attachment.htm>

From jguthrie at brokersys.com  Sun Jan 13 00:08:33 2013
From: jguthrie at brokersys.com (Jonathan Guthrie)
Date: Sat, 12 Jan 2013 18:08:33 -0600
Subject: rtl-sdr and gr-osmosdr
In-Reply-To: <C9ED2A0F09E340A4AF513C480D94D1AA@AlPC>
References: <D0F5DFB61736461B8D0B18C896179089@AlPC>
	<50F1B6F2.3060906@brokersys.com>
	<C9ED2A0F09E340A4AF513C480D94D1AA@AlPC>
Message-ID: <50F1FB01.1040600@brokersys.com>

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 at 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 at myranch.com
> Subject: Re: rtl-sdr and gr-osmosdr
>
> On 01/12/2013 09:03 AM, tokens at 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?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130112/024423d6/attachment.htm>

From peter at stuge.se  Sun Jan 13 07:31:08 2013
From: peter at stuge.se (Peter Stuge)
Date: Sun, 13 Jan 2013 08:31:08 +0100
Subject: rtl-sdr and gr-osmosdr
In-Reply-To: <50F1FB01.1040600@brokersys.com>
References: <D0F5DFB61736461B8D0B18C896179089@AlPC>
	<50F1B6F2.3060906@brokersys.com>
	<C9ED2A0F09E340A4AF513C480D94D1AA@AlPC>
	<50F1FB01.1040600@brokersys.com>
Message-ID: <20130113073108.12757.qmail@stuge.se>

Hi Jonathan,

Jonathan Guthrie wrote:
> Sir:

Thanks for the thorough response to a newbie question. I am sure that
the original poster and several others by way of the list archive
will appreciate 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.
..
> it may be technically correct, but it is definitely the wrong thing
> to do.

It's important to keep in mind that mailing lists are very much a
distinct use case for email. Using mailing lists is not like sending
direct person-to-person or person-to-group emails.

The reason that so many struggle to appreciate not abusing Reply-To
is perhaps that they consider mailing lists to be no different from
direct person-to-group emails. It is critical to realize that these
two ways of emailing are quite different, even though they accomplish
the same thing on the very highest level. (Send one message to many
recipients.)

This means that it is critical to be aware of the technology that
underpins this communication, in order to use it really successfully.

Needing to understand technology in order to use it is foreign for
most people. Needing to understand email is foreign for even more
people. It's not particularly fun to understand email, and I don't
blame anyone who doesn't want to.

Yet, successfully using mailing lists absolutely requires it.

And by extension, it becomes critical for effortless use of mailing
lists to have an email software which can model mailing lists in it's
user interface. Because - again - interacting with a mailing list is
different from interacting directly with recipients.

I have one reply keybinding for replying to the original author.
I have another group reply keybinding for replying to the author and
all recipients.
I have a third list reply keybinding for replying only to the list(s)
that were recipients in the email that I reply to, along with any
addresses in Mail-Followup-To headers.

This allows me to always be explicit about what I want, when I reply
to an email.

This requires me to know what I want. That is not a burden for me.

It would of course be possible to implement a heuristic for this
decision, but it would by definition make some false decisions, and
I don't really want to use a tool which is known to not do what I
want.

I'll trade the convenience of having only a single reply function
which randomly does the wrong thing for having three functions and
depending on myself to do the right thing as often as you like.

You mention that you know that not abusing Reply-To is technically
correct, perhaps per the "List Reply-To considered harmful" article.
If you haven't already read it then I would like to recommend also
reading "Reply-To Munging Still Considered Harmful. Really." [1]


Regards

//Peter

[1] http://woozle.org/~neale/papers/reply-to-still-harmful.html



From robert.durkacz at gmail.com  Sat Jan 12 04:03:48 2013
From: robert.durkacz at gmail.com (Robert Durkacz)
Date: Sat, 12 Jan 2013 15:03:48 +1100
Subject: Windows driver for RTL283 device
Message-ID: <CALDPARA+T0hC_U69XEz+kwZjZq5KFh+TBfQBvUC2Xxcu9vFytA@mail.gmail.com>

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



From moses.mason at gmail.com  Thu Jan 17 04:12:45 2013
From: moses.mason at gmail.com (Moses)
Date: Thu, 17 Jan 2013 12:12:45 +0800
Subject: Windows driver for RTL283 device
In-Reply-To: <CALDPARA+T0hC_U69XEz+kwZjZq5KFh+TBfQBvUC2Xxcu9vFytA@mail.gmail.com>
References: <CALDPARA+T0hC_U69XEz+kwZjZq5KFh+TBfQBvUC2Xxcu9vFytA@mail.gmail.com>
Message-ID: <CAAYZpmT+W0njpiiY30qPQGz+7vCAqXoxMKAr6TNAjHAA5s=saQ@mail.gmail.com>

I'm using Zadig (http://sourceforge.net/projects/libwdi/files/zadig/)
to replace the driver comes with the device with the WinUSB driver,
which is very easy to use and works fine for me. At the end of my
replacing, it maybe pop a error message box indicates the replacing is
failed, but in fact, after checking the hardware manager, the driver
is installed correctly and works very well.


On Sat, Jan 12, 2013 at 12:03 PM, Robert Durkacz
<robert.durkacz at gmail.com> wrote:
> 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
>



-- 
"I may not agree with what you say but I will defend to the death your
right to say it"



From mike_sousa at yahoo.com  Thu Jan 17 18:33:49 2013
From: mike_sousa at yahoo.com (Mike Sousa)
Date: Thu, 17 Jan 2013 10:33:49 -0800 (PST)
Subject: installing rtl-sdr and whether I need to reinstall gnuradio
Message-ID: <1358447629.64113.YahooMailNeo@web120203.mail.ne1.yahoo.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130117/9bc2ca1b/attachment.htm>

From f.gugliuzza at hacklabproject.org  Thu Jan 17 19:19:42 2013
From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza)
Date: Thu, 17 Jan 2013 20:19:42 +0100
Subject: installing rtl-sdr and whether I need to reinstall gnuradio
In-Reply-To: <1358447629.64113.YahooMailNeo@web120203.mail.ne1.yahoo.com>
References: <1358447629.64113.YahooMailNeo@web120203.mail.ne1.yahoo.com>
Message-ID: <CAFhpb2UBmkKcHfHRqzqgMkmL5WCEfBjUk_wr2Z_C4wqpn12ujA@mail.gmail.com>

Just the rtl-sdr software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130117/2143ec25/attachment.htm>

From pab at pabigot.com  Sun Jan 20 22:42:01 2013
From: pab at pabigot.com (Peter A. Bigot)
Date: Sun, 20 Jan 2013 16:42:01 -0600
Subject: segmentation fault on Ubuntu 12.04
Message-ID: <50FC72B9.2090604@pabigot.com>

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 at 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



From 246tnt at gmail.com  Sun Jan 20 23:51:41 2013
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 21 Jan 2013 00:51:41 +0100
Subject: Getting Started...
In-Reply-To: <01AC1393-66C4-415B-AF55-53F7A057DA73@digitalmunition.com>
References: <4C5A4E95-FF99-4413-979B-4BE1C7D67220@digitalmunition.com>
	<6BF28534-0235-4784-8AC6-731B001C61D1@digitalmunition.com>
	<6FAC4316-5446-4250-8CF9-5B6F5FA50C3F@digitalmunition.com>
	<01AC1393-66C4-415B-AF55-53F7A057DA73@digitalmunition.com>
Message-ID: <CAHL+j0-3oRmwspjHBoQvKGCpKtOoPWxSRqRhUAqGq5zGJDfMog@mail.gmail.com>

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



From steve at steve-m.de  Mon Jan 21 00:03:27 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 21 Jan 2013 01:03:27 +0100
Subject: segmentation fault on Ubuntu 12.04
In-Reply-To: <50FC72B9.2090604@pabigot.com>
References: <50FC72B9.2090604@pabigot.com>
Message-ID: <50FC85CF.4080203@steve-m.de>

Hi,

On 20.01.2013 23:42, Peter A. Bigot wrote:
> cb transfer status: 1, canceling...
> 
> Library error 0, exiting...
> Segmentation fault (core dumped)

Which version of libusb do you have installed? I just tried to
reproduce this behaviour on a Ubuntu 12.04 x86_64 machine with
libusb 1.0.9~rc3-2ubuntu1, but it works fine here.

Regards,
Steve



From pab at pabigot.com  Mon Jan 21 00:45:11 2013
From: pab at pabigot.com (Peter A. Bigot)
Date: Sun, 20 Jan 2013 18:45:11 -0600
Subject: segmentation fault on Ubuntu 12.04
In-Reply-To: <50FC85CF.4080203@steve-m.de>
References: <50FC72B9.2090604@pabigot.com> <50FC85CF.4080203@steve-m.de>
Message-ID: <50FC8F97.4030502@pabigot.com>

On 01/20/2013 06:03 PM, Steve Markgraf wrote:
> On 20.01.2013 23:42, Peter A. Bigot wrote:
>> cb transfer status: 1, canceling...
>>
>> Library error 0, exiting...
>> Segmentation fault (core dumped)
> Which version of libusb do you have installed? I just tried to
> reproduce this behaviour on a Ubuntu 12.04 x86_64 machine with
> libusb 1.0.9~rc3-2ubuntu1, but it works fine here.
>
> Regards,
> Steve

Info below.  FWIW, the problem did occur with two RTL2832U from 
different manufacturers (one E4000 one R820T, both from NooElec), 
plugged directly into a USB port on a System 76 laptop (no hub 
involved), and persisted over multiple reboots.   It was only reverting 
that patch that made it work at all.

The segfault makes sense, since the patch has the library detect a 
transfer error that used to be ignored and then set a flag that inhibits 
the wait for in-progress asynch actions to complete before shutting 
down: AFAICT libusb1 is known to get upset when this happens.  I'm 
guessing the error was transient or diagnostic of some other condition, 
and should not have been taken as a sign that the device had gone away 
and the library should shut down.

lemur4[3]$ dpkg-query -s libusb-1.0-0
Package: libusb-1.0-0
Status: install ok installed
Multi-Arch: same
Priority: optional
Section: libs
Installed-Size: 108
Maintainer: Ubuntu Developers <ubuntu-devel-discuss at lists.ubuntu.com>
Architecture: amd64
Source: libusb-1.0
Version: 2:1.0.9~rc3-2ubuntu1
Depends: libc6 (>= 2.14)
Pre-Depends: multiarch-support
Description: userspace USB programming library
  Library for programming USB applications without the knowledge
  of Linux kernel internals.
Homepage: http://www.linux-usb.org/
Original-Maintainer: Aurelien Jarno <aurel32 at debian.org>



From peter at stuge.se  Mon Jan 21 02:13:58 2013
From: peter at stuge.se (Peter Stuge)
Date: Mon, 21 Jan 2013 03:13:58 +0100
Subject: segmentation fault on Ubuntu 12.04
In-Reply-To: <50FC8F97.4030502@pabigot.com>
References: <50FC72B9.2090604@pabigot.com> <50FC85CF.4080203@steve-m.de>
	<50FC8F97.4030502@pabigot.com>
Message-ID: <20130121021358.22215.qmail@stuge.se>

Peter A. Bigot wrote:
> The segfault makes sense, since the patch has the library detect a transfer 
> error that used to be ignored and then set a flag that inhibits the wait 
> for in-progress asynch actions to complete before shutting down: AFAICT 
> libusb1 is known to get upset when this happens.

libusb gets upset because it is a usage error. You can't shut down
before cleaning up anything you have allocated/started/created for
the context.


//Peter



From robert.durkacz at gmail.com  Thu Jan 17 06:38:16 2013
From: robert.durkacz at gmail.com (Robert Durkacz)
Date: Thu, 17 Jan 2013 17:38:16 +1100
Subject: Windows driver for RTL283 device
In-Reply-To: <CAAYZpmT+W0njpiiY30qPQGz+7vCAqXoxMKAr6TNAjHAA5s=saQ@mail.gmail.com>
References: <CALDPARA+T0hC_U69XEz+kwZjZq5KFh+TBfQBvUC2Xxcu9vFytA@mail.gmail.com>
	<CAAYZpmT+W0njpiiY30qPQGz+7vCAqXoxMKAr6TNAjHAA5s=saQ@mail.gmail.com>
Message-ID: <CALDPARDAFqd82=tDQtkveRaNhEoyzCu101Ep1917Kxrs_1YMRA@mail.gmail.com>

It looks like this answers my question. The libusb documentation at
http://www.libusb.org/wiki/windows_backend also points to Zadig as the
way to control what driver is used.
Thanks.

On Thu, Jan 17, 2013 at 3:12 PM, Moses <moses.mason at gmail.com> wrote:
> I'm using Zadig (http://sourceforge.net/projects/libwdi/files/zadig/)
> to replace the driver comes with the device with the WinUSB driver,
> which is very easy to use and works fine for me. At the end of my
> replacing, it maybe pop a error message box indicates the replacing is
> failed, but in fact, after checking the hardware manager, the driver
> is installed correctly and works very well.
>
>
> On Sat, Jan 12, 2013 at 12:03 PM, Robert Durkacz
> <robert.durkacz at gmail.com> wrote:
>> 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
>>
>
>
>
> --
> "I may not agree with what you say but I will defend to the death your
> right to say it"



From al at eartoearoak.com  Mon Jan 21 16:53:01 2013
From: al at eartoearoak.com (Al)
Date: Mon, 21 Jan 2013 16:53:01 +0000
Subject: RTL-SDR Scanner/Plotter
In-Reply-To: <mailman.3.1358420403.28319.osmocom-sdr@lists.osmocom.org>
References: <mailman.3.1358420403.28319.osmocom-sdr@lists.osmocom.org>
Message-ID: <50FD726D.5010000@eartoearoak.com>

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




From kf_lists at digitalmunition.com  Tue Jan 22 08:20:19 2013
From: kf_lists at digitalmunition.com (Kevin Finisterre (lists))
Date: Tue, 22 Jan 2013 03:20:19 -0500
Subject: Getting Started...
In-Reply-To: <CAHL+j0-3oRmwspjHBoQvKGCpKtOoPWxSRqRhUAqGq5zGJDfMog@mail.gmail.com>
References: <4C5A4E95-FF99-4413-979B-4BE1C7D67220@digitalmunition.com>
	<6BF28534-0235-4784-8AC6-731B001C61D1@digitalmunition.com>
	<6FAC4316-5446-4250-8CF9-5B6F5FA50C3F@digitalmunition.com>
	<01AC1393-66C4-415B-AF55-53F7A057DA73@digitalmunition.com>
	<CAHL+j0-3oRmwspjHBoQvKGCpKtOoPWxSRqRhUAqGq5zGJDfMog@mail.gmail.com>
Message-ID: <E7713734-1AC2-4CD8-9AFE-52298DC36F63@digitalmunition.com>

Good to hear. I was also able to get my serial cable fixed so I can finally speak to the CLI on the hardware. 

 > ?
Supported commands:
tuner.init  --  Initialize the tuner
tuner.freq  --  Tune to the specified frequency
tuner.gain  --  Tune to the specified gain
tuner.flt_bw_mix  --  Filter bandwidth (Mixer)
tuner.flt_bw_chan  --  Filter bandwidth (Channel)
tuner.flt_bw_rc  --  Filter bandwidth (RC)
si570.freq  --  Change the SI570 clock frequency
si570.dump  --  Dump SI570 registers
fpga.dump  --  Dump FPGA registers
fpga.pwm1_div  --  PWM divider, Freq = 80MHz/(div+1)
fpga.pwm1_duty  --  PWM duty cycle
fpga.pwm2_div  --  PWM divider, Freq = 80MHz/(div+1)
fpga.pwm2_duty  --  PWM duty cycle
fpga.adc_clkdiv  --  FPGA Clock Divider for ADC (80 MHz/CLKDIV)
fpga.adc_acqlen  --  Num of SCK cycles nCS to AD7357 is held high betewen conversions
ssc.start  --  Start the SSC Receiver
ssc.stop  --  Start the SSC Receiver
ssc.stats  --  Statistics about the SSC
ssc.dump  --  Dump SSC DMA registers

-KF

On Jan 20, 2013, at 6:51 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

> 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




From peter at stuge.se  Tue Jan 22 12:58:41 2013
From: peter at stuge.se (Peter Stuge)
Date: Tue, 22 Jan 2013 13:58:41 +0100
Subject: Windows driver for RTL283 device
In-Reply-To: <CALDPARDAFqd82=tDQtkveRaNhEoyzCu101Ep1917Kxrs_1YMRA@mail.gmail.com>
References: <CALDPARA+T0hC_U69XEz+kwZjZq5KFh+TBfQBvUC2Xxcu9vFytA@mail.gmail.com>
	<CAAYZpmT+W0njpiiY30qPQGz+7vCAqXoxMKAr6TNAjHAA5s=saQ@mail.gmail.com>
	<CALDPARDAFqd82=tDQtkveRaNhEoyzCu101Ep1917Kxrs_1YMRA@mail.gmail.com>
Message-ID: <20130122125841.32094.qmail@stuge.se>

Hi from libusb land,

Robert Durkacz wrote:
> It looks like this answers my question. The libusb documentation at
> http://www.libusb.org/wiki/windows_backend also points to Zadig as
> the way to control what driver is used.

It's not the only way by any means, but it's a convenient GUI. If you
want to automate then look at the wdi-simple example in the libwdi
project (zadig also uses libwdi).


//Peter



From benryanau at hotmail.com  Tue Jan 22 13:45:08 2013
From: benryanau at hotmail.com (Ben Ryan)
Date: Wed, 23 Jan 2013 00:45:08 +1100
Subject: RTL-SDR Scanner/Plotter (Al)
In-Reply-To: <mailman.5.1358852402.31851.osmocom-sdr@lists.osmocom.org>
References: <mailman.5.1358852402.31851.osmocom-sdr@lists.osmocom.org>
Message-ID: <SNT139-W63EB2510A068891AA8A25B6160@phx.gbl>


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 at eartoearoak.com>
> To: osmocom-sdr at lists.osmocom.org
> Subject: RTL-SDR Scanner/Plotter
> Message-ID: <50FD726D.5010000 at 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
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130123/04547cfc/attachment.htm>

From leif at sm5bsz.com  Tue Jan 22 17:24:48 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Tue, 22 Jan 2013 18:24:48 +0100
Subject: mingw32
In-Reply-To: <D0F5DFB61736461B8D0B18C896179089@AlPC>
References: <D0F5DFB61736461B8D0B18C896179089@AlPC>
Message-ID: <20130122182448.334d7154.leif@sm5bsz.com>

Hi,

Attempts to link librtlsdr and libusb-1.0 with my project
Linrad gives these warning messages:
Warning: .drectve `-aligncomm:"__poll_fd",5 ' unrecognized
Warning: .drectve `-aligncomm:"_poll_fd",5' unrecognized
Warning: .drectve `-aligncomm:"_htab_filled",2 ' unrecognized
Warning: .drectve `-aligncomm:"_htab_size",2 ' unrecognized
Warning: .drectve `-aligncomm:"_timer_tp",2 ' unrecognized
Warning: .drectve `-aligncomm:"_autoclaim_lock",2 ' unrecognized
Warning: .drectve `-aligncomm:"_hires_ticks_to_ps",3 ' unrecognized
Warning: .drectve `-aligncomm:"_hires_frequency",3' unrecognized

I get an executable and it runs OK until to rtlsdr_read_async(....) 
is called from a separate thread.

Once async read is running the calls to libusb no longer work OK.
Windows crashes on call to libusb_control_transfer.

By issuing a wait in the thread that calls rtlsdr_read_async
I can assure that no calls will be made to libusb_control_transfer
after async is started.

The call to libusb_handle_events_timeout returns -1 which is
LIBUSB_ERROR_IO about 3 times more often than it returns zero. 
By ignoring this error I have a running system, it receives
the antenna signal fine from the dongle.

BUT if I try to change frequency or gain Windows crashes. Also
if I try to exit. It seems one must not call anything
else in libusb-1.0 after having started read.

I have used mingw32, the standard install under Ubuntu.
I was unable to use the configure script but made a simple
script to compile with /usr/bin/i586-mingw32msvc-gcc
and then create the library and install like this:

/usr/bin/i586-mingw32msvc-ar rc librtlsdr.a librtlsdr.o tuner_tuner_fc0013.o tuner_fc2580.o tuner_r820t.o

/usr/bin/i586-mingw32msvc-ranlib librtlsdr.a

cp librtlsdr.a /usr/i586-mingw32msvc/lib

The libusb-1.0.a file is from the MinGW32 directory
in libusbx-1.0.14-win.7z 

What can I do to fix the problem?

Regards

Leif




From jsalsburg at bellsouth.net  Tue Jan 22 23:17:40 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Tue, 22 Jan 2013 17:17:40 -0600
Subject: SARK-110 Antenna Analyzer [TES09211B] - $360.00 : Seeed Studio Bazaar,
	Boost ideas, extend the reach
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAACUZViFLAQFBhcwwU9jHZ0wBAAAAAA==@bellsouth.net>

http://www.seeedstudio.com/depot/preorder-sark110-antenna-analyzer-p-1270.ht
ml?cPath=174 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130122/6de734ea/attachment.htm>

From martintzvetomirov at gmail.com  Wed Jan 23 20:11:52 2013
From: martintzvetomirov at gmail.com (=?windows-1251?B?zODw8ujtIMzg8Ojt7uI=?=)
Date: Wed, 23 Jan 2013 20:11:52 +0000
Subject: SDR Touch and licensing
Message-ID: <CABDuwnC_O2UP=UKecOSsz4faOEnSBif1BHRhAHwxBgaZig-2fA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130123/f24a4b97/attachment.htm>

From 246tnt at gmail.com  Thu Jan 24 19:37:06 2013
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 24 Jan 2013 20:37:06 +0100
Subject: SDR Touch and licensing
In-Reply-To: <CABDuwnC_O2UP=UKecOSsz4faOEnSBif1BHRhAHwxBgaZig-2fA@mail.gmail.com>
References: <CABDuwnC_O2UP=UKecOSsz4faOEnSBif1BHRhAHwxBgaZig-2fA@mail.gmail.com>
Message-ID: <CAHL+j0_D8gudiYCvk0CG+7onFKvoiFkjtsgM_oiM41Eua=N5wQ@mail.gmail.com>

Hi,


> 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.

That's where our opinions differ. For me the way the package is currently
distributed doesn't qualify as an aggregate.

The fact they are separate binaries and that rtl_tcp_andro by itself
is properly released is of course a good part of the work toward
compliance, but it's not sufficient.

You compared the .apk to an "installer", but I really don't see it
that way (AFAIK .apk are not even uncompressed, some files might
be cached but they mostly stay bundled). It's not like you have two
independent packages that are pulled together, here you have a single
package.

And if you want to compare it to something, it's much closer to the
OSX way of distributing application where even though on the file system
the application is several files, the whole bundle only represent a
single larger "Application" and everything else is completely hidden from
the user.

I mean a single ELF file is split into sections and 'installed' into
distinct RAM pages but it'd be hard to argue it's not a single application
because that's just a technicality of the way that platform work.

Same thing for Android: For all intents and purposes, an APK _is_ a
single application.



Let's look at the relevant section covering "aggregation" in the GPL:


End of Section 2 of GPLv2:

> In addition, mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of
> a storage or distribution medium does not bring the other work under
> the scope of this License.


End of Section 5 of GPLv3

> A compilation of a covered work with other separate and independent
> works, which are not by their nature extensions of the covered work,
> and which are not combined with it such as to form a larger program,
> in or on a volume of a storage or distribution medium, is called an
> "aggregate" if the compilation and its resulting copyright are not
> used to limit the access or legal rights of the compilation's users
> beyond what the individual works permit.  Inclusion of a covered work
> in an aggregate does not cause this License to apply to the other
> parts of the aggregate.


So basically for this to apply, what's bundled with a GPL Program must not
be either "work based on the Program" or "not combined with the Program
to form a larger Program".

I really don't see how you could not describe the "SDR touch" application
in its whole as not a combination fully including the rtl-sdr code when
more than half the description on Google Play describes functionality
provided by the rtl-sdr code.

Theses clauses were meant for things like distributions or when shipping
installed systems that just happen to contains GPL part among many and
I really don't see its applicability here where you only have two parts:
 - The GPL covered work
 - A independent application that heavily relies on the GPL work to do
   what it's supposed to.



> Is there anything I can do so we can settle this issue once and for all?

As was suggested elsewhere, a good step towards compliance and gesture of
good faith would be:

 - Distribute rtl_tcp_andro as a separate Android application
 - Make sure that second application has the LICENSE both in the package
   and visible to the user through the interface somewhere.

This would also nicely allows other application to share the device and
would probably make it easier for the user to replace rtl_tcp_andro
with a self compiled / updated version or whatever. (after all the ability
of the user to use a modified version in place of the distributed one without
undue hassle, is also a requirement, 'anti-tivoization' stuff, but I'm
not familiar enough with android ecosystem to see if applicable here)

Now, this is not perfect and one could argue that the heavy reliance of
the java app on the rtl-sdr (contrary to some other application that
would support a lot more data source) could be construded as "derivative".
But when the application are really split in two independently installed
and distributed packages, this becomes a whole lot less clear to me and
a definitive answer could only be given by a judge in a court of law.



Cheers,

     Sylvain



Obligatory disclaimer:

Of course, IANAL, this doesn't constitute legal advice and the opinions
expressed here are my own, I have no right whatsoever to speak for anyone
else than myself ...



From leif at sm5bsz.com  Sat Jan 26 03:05:41 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Sat, 26 Jan 2013 04:05:41 +0100
Subject: librtlsdr.c suggestions
In-Reply-To: <D0F5DFB61736461B8D0B18C896179089@AlPC>
References: <D0F5DFB61736461B8D0B18C896179089@AlPC>
Message-ID: <20130126040541.2920e304.leif@sm5bsz.com>

Hi All,

In case buffer allocation fails there will be a crash.

I suggest something like this in rtlsdr_read_async:

        if(_rtlsdr_alloc_async_buffers(dev) < 0)
          {
          _rtlsdr_free_async_buffers(dev);
          return -1;
          }

The function _rtlsdr_alloc_async_buffers needs tests for
malloc returning NULL with an appropriate return of an
error code to make the above work.


Immediately below the suggested change it may be a good idea
to introduce a small delay. Without this delay 
libusb-1.0 crashes under Windows if the sampling rate is high
and the computer is a bit slow:

        for(i = 0; i < dev->xfer_buf_num; ++i) {
#ifdef _WIN32
                Sleep(1);
#else
                usleep(1000);
#endif

                libusb_fill_bulk_transfer(dev->xfer[i],
                                          dev->devh,   
                                          0x81,


A little further down one more change is desireable:
                        /*fprintf(stderr, "handle_events returned: %d\n", r);
                        if (r == LIBUSB_ERROR_INTERRUPTED || r==-1) /* stray 

The error code -1 occurs frequently but the data supplied to
the application callback is perfectly OK. On faster computers
there is never any error, but with a Centrino Duo at 900 kHz
there are 2 or 3 errors (-1) for each proper return in case
small buffers are selected.

Regards

Leif



From peter at stuge.se  Sat Jan 26 04:44:56 2013
From: peter at stuge.se (Peter Stuge)
Date: Sat, 26 Jan 2013 05:44:56 +0100
Subject: mingw32
In-Reply-To: <20130122182448.334d7154.leif@sm5bsz.com>
References: <D0F5DFB61736461B8D0B18C896179089@AlPC>
	<20130122182448.334d7154.leif@sm5bsz.com>
Message-ID: <20130126044457.30130.qmail@stuge.se>

Leif Asbrink wrote:
> Attempts to link librtlsdr and libusb-1.0 with my project

Please note that libusbx is not libusb. I'm the maintainer of libusb
at libusb.org and libusbx is a fork with some good additions but more
notably an overwhelming amount of questionable practises and changes,
by basically one developer who refuses to work with me. (He banned me
from the libusbx mailing list when I wrote that some of his code
which is both in libusb and libusbx had a bug.)

While I do pay attention to what happens in libusbx I don't know
exactly what the state is of that code. I haven't tested libusbx-1.0.14
in a while, and in particular not on Windows, where libusbx has crazy
changes compared to the original libusb-1.0 from libusb.org. (That's
the platform the main developer works on.)

I know of others who have had strange issues with libusbx-1.0.14,
while the latest libusb.git source code from libusb.org instead
worked as expected.

Please grab the latest code from http://git.libusb.org/libusb.git
and see if it works any better.


> BUT if I try to change frequency or gain Windows crashes. Also
> if I try to exit. It seems one must not call anything
> else in libusb-1.0 after having started read.

That would be a bug in the implementation. The API design very much
allows mixing sync and async transfers, and it works fine in
libusb-1.0.


> I have used mingw32, the standard install under Ubuntu.

Ok.


> I was unable to use the configure script

This is a HUGE alarm bell for me. Especially if you are just starting
out with learning cross-compiling it is critical that you make things
work exactly the way they are supposed to, or you are just setting
yourself up for endless unneccessary trouble.

If you tried to use configure and it did not work then why don't you
show what went wrong?

Please show the configure command that you ran, along with the
complete output that it produced. I assume that there were some
errors in the end, make sure to include those of course, and ideally
also attach the complete config.log file. Feel free to send that in
an email directly to me if the mailing list thinks that the
attachments are too large. Make sure to send the log file as plain
text, ie. either inline in the email, or attached with text/plain
MIME type.


> but made a simple script to compile with
> /usr/bin/i586-mingw32msvc-gcc
> and then create the library and install like this:
> 
> /usr/bin/i586-mingw32msvc-ar rc librtlsdr.a librtlsdr.o tuner_tuner_fc0013.o tuner_fc2580.o tuner_r820t.o
> /usr/bin/i586-mingw32msvc-ranlib librtlsdr.a
> cp librtlsdr.a /usr/i586-mingw32msvc/lib

It's a bad idea to store librtlsdr in the toolchain lib dir. The
correct approach is to use a so-called prefix directory, which as
it happens is taken caren of automatically by the configure script.


> What can I do to fix the problem?

I'm happy to help you sort things out with libusb-1.0, but you'll
have to work with the code from libusb.org.

configuring and building libusb with that ubuntu cross-compiler
should work without any issues..

git clone git://git.libusb.org/libusb.git && \
  cd libusb && \
  ./autogen.sh --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
  make install && \
  cd .. && \
git clone git://git.osmocom.org/rtl-sdr && \
  cd rtl-sdr && \
  autoreconf -fi && \
  PKG_CONFIG_LIBDIR=$(pwd)/../winlibs/lib/pkgconfig \
    ./configure --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
  make install && \
  cd .. && \
ls -l winlibs/bin winlibs/lib

..builds libusb and rtl-sdr using the cross-compiler and installs the
built files into the winlibs/ directory wherever you copypaste the
above commands.

But, I don't know if the rtl-sdr configure.ac works so well for
cross-compiling for Windows. The last time I tried to cross-compile
rtl-sdr for Windows I used cmake, and I had to work around several
issues to make that work.

If you want to focus on the USB communication then you can of course
continue bypassing the build system for rtl-sdr, but if it has
actually been fixed since I tried to cross-compile then you should
really use it.

The libusb that gets built above includes very verbose debug logging,
and will output lots of lines of useful information when you run a
program which uses it. When there are no more bugs to deal with you
will rebuild libusb without that debug logging:

cd libusb && \
  ./configure --host=i586-mingw32msvc --prefix=../winlibs \
    --disable-debug-log && \
  make install && \
  cd ..

I hope you already see the pattern for how configure works.


If something doesn't work, please send complete information to get a
useful response.


//Peter



From leif at sm5bsz.com  Sat Jan 26 13:25:45 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Sat, 26 Jan 2013 14:25:45 +0100
Subject: mingw32
In-Reply-To: <20130126044457.30130.qmail@stuge.se>
References: <D0F5DFB61736461B8D0B18C896179089@AlPC>
	<20130122182448.334d7154.leif@sm5bsz.com>
	<20130126044457.30130.qmail@stuge.se>
Message-ID: <20130126142545.5ff89b41.leif@sm5bsz.com>

Hello Peter,

This may not be the appropriate forum for libusb-1.0 discussions,
but since the library is essential for rtlsdr users I take the
liberty to post my findings here.

I already solved the problems when your posting appeared.
I will try the proper configure commands. That would make
things easier of course.

I am not a programmer. There is a lot of terminology that
I do not understand. I am limited to a small sub-set
of regular C and I am too old to learn big volumes of
new things. My interest is radio and signal processing.
The RTL dongle is a marvellous thing (with the e4k tuner)
and I want to make people aware of how it can be used.
Having to worry about drive routines is frustrating but
necessary for performance reasons.

I have been using simple hand-written Makefiles to 
compile and create the libraries. I will try the commands
that you have supplied to see what happens, but first
I will make a new version of Linrad available that will
use rtlsdr properly under Windows.

First of all, the Debian versions of mingw32 are broken. There
are two alternative (mutually excluding) mackages.
The package gcc-mingw32 runs the first step and produces
an assembly file that contains errors causing the second 
step to fail. (do not remember what routine)

The package mingw32 does compile but the linker can not
find the entry for vprintf. There are several .a files
containing a reference to it, if should be located
in libmingwex but it is not there.

The mingw package (5.1.6) for Windows works however so I can
compile on an XP platform. 

I have tested http://git.libusb.org/libusb.git (today, Jan 26)

As it turns out I have to make a couple of changes to allow
compilation. Those are:

--------------------------- core.c -----------------------------
/* Offset between 1/1/1601 and 1/1/1970 in 100 nanosec units */
// #define _W32_FT_OFFSET (116444736000000000)
// Jan 26 2013 Leif _sbrink SM5BSZ
// mingw32 does not accept this. Integer constant too large.
// define in 100 millisecond units.
// The routine is rewritten in a simple-minded fashion
#define _W32_FT_OFFSET (11644473600.0)


int usbi_gettimeofday(struct timeval *tp, void *tzp)
 {
 unsigned __int64 *ns100; /*time since 1 Jan 1601 in 100ns units */
 FILETIME ft;
 ns100=(__int64*)&ft;

  if(tp)
    {
      GetSystemTimeAsFileTime (&ft);
      tp->tv_usec=(long)((ns100[0] / 10) % 1000000 );
      ns100[0]/=10000000;
      ns100[0]-=_W32_FT_OFFSET;
      tp->tv_sec= (long)ns100[0];
    }
  /* Always return 0 as per Open Group Base Specifications Issue 6.
     Do not set errno on error.  */
  return 0;
}
// end of modified code Jan 26 2013
--------------------------------------------------------------------
-----------------------   threads_windows.c   ----------------------
// Jan 26 2013 Leif _sbrink SM5BSZ Line changed to coply with mingw 
// static int __inline usbi_cond_intwait(usbi_cond_t *cond,
static __inline int usbi_cond_intwait(usbi_cond_t *cond,
--------------------------------------------------------------------

The resulting library does not work however. It returns -12
to librtl during the initial setup.

I have also compiled libusb-1.0.9 which needed the same
modifications. The library runs, but behaves as all precompiled
versions available on the Internet. Crashes on a frequency change.

Having the library running from my own source code
allowed tracing the crash that occurs when the frequency
is changed while the callback is running. The culpit
is the call usbi_warn(NULL,.... that is issued when
something belonging to another thread is detected.
I have commented out all such calls and now libusb-1.0.9
runs fine on my Windows machine:-)

I have verified that usbi_warn is ok if a context is supplied.

Regards

Leif




On Sat, 26 Jan 2013 05:44:56 +0100
Peter Stuge <peter at stuge.se> wrote:

> Leif Asbrink wrote:
> > Attempts to link librtlsdr and libusb-1.0 with my project
> 
> Please note that libusbx is not libusb. I'm the maintainer of libusb
> at libusb.org and libusbx is a fork with some good additions but more
> notably an overwhelming amount of questionable practises and changes,
> by basically one developer who refuses to work with me. (He banned me
> from the libusbx mailing list when I wrote that some of his code
> which is both in libusb and libusbx had a bug.)
> 
> While I do pay attention to what happens in libusbx I don't know
> exactly what the state is of that code. I haven't tested libusbx-1.0.14
> in a while, and in particular not on Windows, where libusbx has crazy
> changes compared to the original libusb-1.0 from libusb.org. (That's
> the platform the main developer works on.)
> 
> I know of others who have had strange issues with libusbx-1.0.14,
> while the latest libusb.git source code from libusb.org instead
> worked as expected.
> 
> Please grab the latest code from http://git.libusb.org/libusb.git
> and see if it works any better.
> 
> 
> > BUT if I try to change frequency or gain Windows crashes. Also
> > if I try to exit. It seems one must not call anything
> > else in libusb-1.0 after having started read.
> 
> That would be a bug in the implementation. The API design very much
> allows mixing sync and async transfers, and it works fine in
> libusb-1.0.
> 
> 
> > I have used mingw32, the standard install under Ubuntu.
> 
> Ok.
> 
> 
> > I was unable to use the configure script
> 
> This is a HUGE alarm bell for me. Especially if you are just starting
> out with learning cross-compiling it is critical that you make things
> work exactly the way they are supposed to, or you are just setting
> yourself up for endless unneccessary trouble.
> 
> If you tried to use configure and it did not work then why don't you
> show what went wrong?
> 
> Please show the configure command that you ran, along with the
> complete output that it produced. I assume that there were some
> errors in the end, make sure to include those of course, and ideally
> also attach the complete config.log file. Feel free to send that in
> an email directly to me if the mailing list thinks that the
> attachments are too large. Make sure to send the log file as plain
> text, ie. either inline in the email, or attached with text/plain
> MIME type.
> 
> 
> > but made a simple script to compile with
> > /usr/bin/i586-mingw32msvc-gcc
> > and then create the library and install like this:
> > 
> > /usr/bin/i586-mingw32msvc-ar rc librtlsdr.a librtlsdr.o tuner_tuner_fc0013.o tuner_fc2580.o tuner_r820t.o
> > /usr/bin/i586-mingw32msvc-ranlib librtlsdr.a
> > cp librtlsdr.a /usr/i586-mingw32msvc/lib
> 
> It's a bad idea to store librtlsdr in the toolchain lib dir. The
> correct approach is to use a so-called prefix directory, which as
> it happens is taken caren of automatically by the configure script.
> 
> 
> > What can I do to fix the problem?
> 
> I'm happy to help you sort things out with libusb-1.0, but you'll
> have to work with the code from libusb.org.
> 
> configuring and building libusb with that ubuntu cross-compiler
> should work without any issues..
> 
> git clone git://git.libusb.org/libusb.git && \
>   cd libusb && \
>   ./autogen.sh --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
>   make install && \
>   cd .. && \
> git clone git://git.osmocom.org/rtl-sdr && \
>   cd rtl-sdr && \
>   autoreconf -fi && \
>   PKG_CONFIG_LIBDIR=$(pwd)/../winlibs/lib/pkgconfig \
>     ./configure --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
>   make install && \
>   cd .. && \
> ls -l winlibs/bin winlibs/lib
> 
> ..builds libusb and rtl-sdr using the cross-compiler and installs the
> built files into the winlibs/ directory wherever you copypaste the
> above commands.
> 
> But, I don't know if the rtl-sdr configure.ac works so well for
> cross-compiling for Windows. The last time I tried to cross-compile
> rtl-sdr for Windows I used cmake, and I had to work around several
> issues to make that work.
> 
> If you want to focus on the USB communication then you can of course
> continue bypassing the build system for rtl-sdr, but if it has
> actually been fixed since I tried to cross-compile then you should
> really use it.
> 
> The libusb that gets built above includes very verbose debug logging,
> and will output lots of lines of useful information when you run a
> program which uses it. When there are no more bugs to deal with you
> will rebuild libusb without that debug logging:
> 
> cd libusb && \
>   ./configure --host=i586-mingw32msvc --prefix=../winlibs \
>     --disable-debug-log && \
>   make install && \
>   cd ..
> 
> I hope you already see the pattern for how configure works.
> 
> 
> If something doesn't work, please send complete information to get a
> useful response.
> 
> 
> //Peter
> 



From edy555 at gmail.com  Mon Jan 28 14:59:51 2013
From: edy555 at gmail.com (TAKAHASHI Tomohiro)
Date: Mon, 28 Jan 2013 23:59:51 +0900
Subject: RTL-SDR Scanner/Plotter
In-Reply-To: <50FD726D.5010000@eartoearoak.com>
References: <mailman.3.1358420403.28319.osmocom-sdr@lists.osmocom.org>
	<50FD726D.5010000@eartoearoak.com>
Message-ID: <CAExemAoABj8bVRQJiTyOPUbBBcaS3piqC3FBrNr3i+jY==Mrug@mail.gmail.com>

Hi Al,

I have tried to run rtlsdr_scan.py on Mac OSX(10.6), and it seems works good.
I think this is very useful to view wide spectrum with rtl dongle.

While running rtlsdr_scan.py I had an problem related to wxwidgets
installed with brew,
but resolved as following article.
http://stackoverflow.com/questions/5121574/wxpython-import-error

Thanks a lot,

@edy555


On Tue, Jan 22, 2013 at 1:53 AM, Al <al at eartoearoak.com> wrote:
> 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
>
>



From al at eartoearoak.com  Mon Jan 28 20:51:32 2013
From: al at eartoearoak.com (Al)
Date: Mon, 28 Jan 2013 20:51:32 +0000
Subject: RTL-SDR Scanner/Plotter (Al)
In-Reply-To: <mailman.5.1358938806.17207.osmocom-sdr@lists.osmocom.org>
References: <mailman.5.1358938806.17207.osmocom-sdr@lists.osmocom.org>
Message-ID: <5106E4D4.3050802@eartoearoak.com>

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 at hotmail.com>
> To: <osmocom-sdr at lists.osmocom.org>
> Subject: RE: RTL-SDR Scanner/Plotter (Al)
> Message-ID: <SNT139-W63EB2510A068891AA8A25B6160 at 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 at eartoearoak.com>
>> To: osmocom-sdr at lists.osmocom.org
>> Subject: RTL-SDR Scanner/Plotter
>> Message-ID: <50FD726D.5010000 at 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



From martintzvetomirov at gmail.com  Wed Jan 30 12:37:53 2013
From: martintzvetomirov at gmail.com (=?windows-1251?B?zODw8ujtIMzg8Ojt7uI=?=)
Date: Wed, 30 Jan 2013 12:37:53 +0000
Subject: rtl_tcp port for Android
Message-ID: <CABDuwnAAkajdCExeB_cuG74K3TA10sEDMrOdUaqo6kcADwFK2Q@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130130/3ec0a501/attachment.htm>

From mikejamo at gmail.com  Wed Jan 30 12:53:42 2013
From: mikejamo at gmail.com (Mike Jameson)
Date: Wed, 30 Jan 2013 12:53:42 +0000
Subject: rtl_tcp port for Android
In-Reply-To: <CABDuwnAAkajdCExeB_cuG74K3TA10sEDMrOdUaqo6kcADwFK2Q@mail.gmail.com>
References: <CABDuwnAAkajdCExeB_cuG74K3TA10sEDMrOdUaqo6kcADwFK2Q@mail.gmail.com>
Message-ID: <CAJcjmiQQGgdUHh16xYg2SJAWj0K57droeWJDWrvu5cqH8JEJnw@mail.gmail.com>

Legend! Top man :)

Mike
M0MIK
 On 30 Jan 2013 12:50, "?????? ???????" <martintzvetomirov at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130130/21e80492/attachment.htm>

From 246tnt at gmail.com  Wed Jan 30 13:23:50 2013
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 30 Jan 2013 14:23:50 +0100
Subject: rtl_tcp port for Android
In-Reply-To: <CABDuwnAAkajdCExeB_cuG74K3TA10sEDMrOdUaqo6kcADwFK2Q@mail.gmail.com>
References: <CABDuwnAAkajdCExeB_cuG74K3TA10sEDMrOdUaqo6kcADwFK2Q@mail.gmail.com>
Message-ID: <CAHL+j097S_Sn5eguKbYAG4dnY0ndwMQRBY7UOeGRviMHkZuMBg@mail.gmail.com>

Hi,

> 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-

Nice.

Would you mind added the github link and a link to the sdr osmocom
page in the description of the app so it's visible from google play
web description directly ?

Cheers,

     Sylvain



From alancorey at yahoo.com  Thu Jan 31 06:23:06 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Wed, 30 Jan 2013 22:23:06 -0800 (PST)
Subject: how about: rtl_drm?
Message-ID: <1359613386.73869.YahooMailNeo@web161506.mail.bf1.yahoo.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130130/424a9622/attachment.htm>

From steve at steve-m.de  Thu Jan 31 15:42:56 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 31 Jan 2013 16:42:56 +0100
Subject: how about: rtl_drm?
In-Reply-To: <1359613386.73869.YahooMailNeo@web161506.mail.bf1.yahoo.com>
References: <1359613386.73869.YahooMailNeo@web161506.mail.bf1.yahoo.com>
Message-ID: <510A9100.5000708@steve-m.de>

Hi,

On 31.01.2013 07:23, Alan Corey wrote:
> Just an idea, really, I don't know how complex the decoding is.  Or
> rtl_fm for Android?

Well, there's Dream [1], which just works fine. Use the SDR software of
your choice (I just tried it with gqrx), select a USB demod and feed the
demodulated 'audio' to Dream. I was even able to receive an indian
DRM station here in Germany with the direct sampling mod and a long
wire (indoors).

http://steve-m.de/pics/drm_gos_iv.png
http://steve-m.de/pics/direct_sampling_drm.png

(the red MSC CRC was due to an unpatched version of libfaad)

Regards,
Steve

[1] http://drm.sourceforge.net/