From balint256 at gmail.com  Sun Apr  1 02:53:27 2012
From: balint256 at gmail.com (Balint Seeber)
Date: Sun, 1 Apr 2012 12:53:27 +1000
Subject: RTL-SDR: E4000 IF bandwidth (& Slashdot!)
In-Reply-To: <CAA3eFd7u+YxGb9BR_51F=sKhodzobhghOUUVry3YLGmVW9rKSA@mail.gmail.com>
References: <CAA3eFd7u+YxGb9BR_51F=sKhodzobhghOUUVry3YLGmVW9rKSA@mail.gmail.com>
Message-ID: <072001cd0fb2$a31a7d70$e94f7850$@com>

Hi Michal,
Thank you for asking the question - I was thinking about this too last night
(actually this morning) while I was trying to catch up on some sleep, but my
brain wouldn't stop ticking over :)

Can't be sure of the effect as datasheets aren't public, but I will
experiment with narrowing the bandwidth. The 'IFfilter' function in the
E4000 tuner code is made up of a massive if/else block that sets various
register values by checking the input IF-BW values from <= 2150 to > 5500,
so it appears to support a wide range (despite the convenience
'E4000_BANDWIDTH_HZ' enum in the header).

Will post findings a little later, unless someone beats me to it :)

Kind regards,
Balint

PS: "Software-Defined Radio For $11" on Slashdot!
http://hardware.slashdot.org/story/12/03/31/1914217/software-defined-radio-f
or-11

PPS: I've been working to improve the GNU Radio Source block and Windows
plugin with generous feedback from the community. Grab them here if you
wish:
http://wiki.spench.net/wiki/gr-baz#rtl_source_c
http://wiki.spench.net/wiki/USRP_Interfaces

> -----Original Message-----
> From: Micha? Rogala [mailto:michal.rogala at gmail.com]
> Sent: Sunday, 1 April 2012 4:36 AM
> To: balint256 at gmail.com; osmocom-sdr at lists.osmocom.org
> Subject: RTL-SDR: E4000 IF bandwidth
> 
> Hi!
> 
> I've just noticed one issue about E4000 driver that bothers me - IF
> bandwidth at the chip is set to 8 MHz, where maximum bandwidth of RTL2832U
> sampling is 3.2 MHz.
> 
> Wouldn't reducing IF bandwidth at tuner chip improve overall sensitivity
> (and maybe noise level)?
> 
> best regards
> 
> Michal Rogala




From michal.rogala at gmail.com  Sun Apr  1 12:21:50 2012
From: michal.rogala at gmail.com (=?ISO-8859-2?Q?Micha=B3_Rogala?=)
Date: Sun, 1 Apr 2012 14:21:50 +0200
Subject: RTL-SDR: E4000 IF bandwidth (& Slashdot!)
In-Reply-To: <072001cd0fb2$a31a7d70$e94f7850$@com>
References: <CAA3eFd7u+YxGb9BR_51F=sKhodzobhghOUUVry3YLGmVW9rKSA@mail.gmail.com>
	<072001cd0fb2$a31a7d70$e94f7850$@com>
Message-ID: <CAA3eFd5kXC-v8Q6-czdEcEJD6ifc6f2QTUbBZDYPTE_6sOyiNA@mail.gmail.com>

Hi!

Thanks, would be great if it turns out that those changes improve
reception :). What I've seen in source code FC0013  also has regulated
IF bandwidth filter, although in very limited steps - 8 MHz, 7 MHz, 6
MHz.

best regards and thank you for great work :)

Michal Rogala

W dniu 1 kwietnia 2012 04:53 u?ytkownik Balint Seeber
<balint256 at gmail.com> napisa?:
> Hi Michal,
> Thank you for asking the question - I was thinking about this too last night
> (actually this morning) while I was trying to catch up on some sleep, but my
> brain wouldn't stop ticking over :)
>
> Can't be sure of the effect as datasheets aren't public, but I will
> experiment with narrowing the bandwidth. The 'IFfilter' function in the
> E4000 tuner code is made up of a massive if/else block that sets various
> register values by checking the input IF-BW values from <= 2150 to > 5500,
> so it appears to support a wide range (despite the convenience
> 'E4000_BANDWIDTH_HZ' enum in the header).
>
> Will post findings a little later, unless someone beats me to it :)
>
> Kind regards,
> Balint
>
> PS: "Software-Defined Radio For $11" on Slashdot!
> http://hardware.slashdot.org/story/12/03/31/1914217/software-defined-radio-f
> or-11
>
> PPS: I've been working to improve the GNU Radio Source block and Windows
> plugin with generous feedback from the community. Grab them here if you
> wish:
> http://wiki.spench.net/wiki/gr-baz#rtl_source_c
> http://wiki.spench.net/wiki/USRP_Interfaces
>
>> -----Original Message-----
>> From: Micha? Rogala [mailto:michal.rogala at gmail.com]
>> Sent: Sunday, 1 April 2012 4:36 AM
>> To: balint256 at gmail.com; osmocom-sdr at lists.osmocom.org
>> Subject: RTL-SDR: E4000 IF bandwidth
>>
>> Hi!
>>
>> I've just noticed one issue about E4000 driver that bothers me - IF
>> bandwidth at the chip is set to 8 MHz, where maximum bandwidth of RTL2832U
>> sampling is 3.2 MHz.
>>
>> Wouldn't reducing IF bandwidth at tuner chip improve overall sensitivity
>> (and maybe noise level)?
>>
>> best regards
>>
>> Michal Rogala
>



From heikkiyp at gmail.com  Mon Apr  2 07:21:26 2012
From: heikkiyp at gmail.com (Heikki Ylipiessa)
Date: Mon, 2 Apr 2012 10:21:26 +0300
Subject: Si5170 replaceable with SI514 ????
Message-ID: <CAEyudiUFDDZeBdrRQVY_o+k+SGcPiHbP5iFWv3qga4EsWgg8Jw@mail.gmail.com>

Hi.

I know that the Si570 is high precision oscilator ...
And it mainly covers the frequencies quite well .
But .. the 10MHz lower limit cuts the possibility of using it for
1.8MHz and 3.6Mhz and 7.0 MHz HAM radio bands ...
The SI514 would possibly cover the need ..
As I don't know how solidly the design has been made ...
I'm asking if the Si570 can be replaced with SI514 and if so
does the device firmware also need adjusting ???


-- 
Regards , Heikki Ylipiessa
Home: heikki at ylipiessa.fi
Work: heikki.ylipiessa at fi.ibm.com



From laforge at gnumonks.org  Mon Apr  2 08:45:26 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 2 Apr 2012 10:45:26 +0200
Subject: Si5170 replaceable with SI514 ????
In-Reply-To: <CAEyudiUFDDZeBdrRQVY_o+k+SGcPiHbP5iFWv3qga4EsWgg8Jw@mail.gmail.com>
References: <CAEyudiUFDDZeBdrRQVY_o+k+SGcPiHbP5iFWv3qga4EsWgg8Jw@mail.gmail.com>
Message-ID: <20120402084526.GG9076@prithivi.gnumonks.org>

Hi,

On Mon, Apr 02, 2012 at 10:21:26AM +0300, Heikki Ylipiessa wrote:
> But .. the 10MHz lower limit cuts the possibility of using it for
> 1.8MHz and 3.6Mhz and 7.0 MHz HAM radio bands ...
> The SI514 would possibly cover the need ..
> As I don't know how solidly the design has been made ...
> I'm asking if the Si570 can be replaced with SI514 and if so
> does the device firmware also need adjusting ???

The limitation of 64MHz lowest input frequency is a result of the E4000
tuner, not of the oscillator.  So no, it is not possible to receive the
low frequency short wave bands that you have indicated, sorry.

Also, I'm not sure what kind of signals you would find on those bands
which would require the 1MHz band-width of the OsmoSDR.  Typically the
signals there are quite narrow-band, i.e. much simpler receiver design.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From steve at steve-m.de  Mon Apr  2 09:08:56 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 02 Apr 2012 11:08:56 +0200
Subject: Si5170 replaceable with SI514 ????
In-Reply-To: <20120402084526.GG9076@prithivi.gnumonks.org>
References: <CAEyudiUFDDZeBdrRQVY_o+k+SGcPiHbP5iFWv3qga4EsWgg8Jw@mail.gmail.com>
	<20120402084526.GG9076@prithivi.gnumonks.org>
Message-ID: <4F796CA8.1030906@steve-m.de>

On 02.04.2012 10:45, Harald Welte wrote:

> The limitation of 64MHz lowest input frequency is a result of the E4000
> tuner, not of the oscillator.  So no, it is not possible to receive the
> low frequency short wave bands that you have indicated, sorry.

An option would be building an upconverter, like this one:
http://www.ct1ffu.com/site/hf-converter.pdf

Regards,
Steve



From schwandre at gmx.net  Mon Apr  2 14:18:48 2012
From: schwandre at gmx.net (schwandre at gmx.net)
Date: Mon, 02 Apr 2012 16:18:48 +0200
Subject: rtl-sdr with airprobe
Message-ID: <20120402141848.257420@gmx.net>

Hi!

I tried to use the recorded capture.bin of several arfcn with aiprobe.
Checked the arfcn before with cell-log of osmocom.

I converted the capture.bin to the cfile format with the
rtl2832-cfile gnuradio block.
checked the converted recordings with fft-gui of gnuradio.
Seems to be fine.

Now i used gsm-receiver with the follwing option to decode the broadcast
traffic that is in ts0:
GSM/airprobe/gsm-receiver/src/python$ ./go_usrp2.sh capture.cfile 174 0b

with the downloaded samplefile of srlabs it works fine, but with mine not.
i also tried to change the dezimation rate, did not help.

i recorded the bin file with 1.8MS/s also did some tests with 200kS/s.

How do i calculate the dezimation rate for the different MS/s ?

I think it should work when i use 1.8MS/s and decimation rate of 174.
What i am doing wrong?

I am using the Hama Nano and the terratec noxon, both are working fine,
tested it on radio-broadcast 88-108 MHz and 433 MHz ISM-Band.

Will be thankful for any hint.

Bye!

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



From 246tnt at gmail.com  Mon Apr  2 14:51:43 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 2 Apr 2012 16:51:43 +0200
Subject: rtl-sdr with airprobe
In-Reply-To: <20120402141848.257420@gmx.net>
References: <20120402141848.257420@gmx.net>
Message-ID: <CAHL+j0-wiqWat5025RKyjwG+CHbeDqqm+RCBV7YsdsrRuLxsNg@mail.gmail.com>

Hi,



> I think it should work when i use 1.8MS/s and decimation rate of 174.

I'd like to know what was the reasoning behind that statement ?

To me it shows a deep lack of understanding on how that script works ...

Try actually reading the sources, and hopefully you'll figure it out.



Cheers,

    Sylvain



From oliver.goldenstein at googlemail.com  Mon Apr  2 14:58:10 2012
From: oliver.goldenstein at googlemail.com (Oliver Goldenstein)
Date: Mon, 2 Apr 2012 16:58:10 +0200
Subject: librtlsdr - Terratec Cinergy T Stick Black (rev 1) works
Message-ID: <CAAUWWMEr-1D1Kg0Ceo_BhDHhsVo0GFOFuetAQ8C9uzsZn_EiUQ@mail.gmail.com>

Please add:

 { 0x0ccd, 0x00a9, "Terratec Cinergy T Stick Black (rev 1)" },

just tested with gnuradio.

lsusb shows this:

Bus 002 Device 005: ID 0ccd:00a9 TerraTec Electronic GmbH RTL2838
DVB-T COFDM Demodulator [TerraTec Cinergy T Stick Black]

Works good. Stick uses rtl2832u/fc0012

-- 
Oliver, DL6KBG, JO61UB
Blog: http://dl6kbg.blogspot.com



From steve at steve-m.de  Mon Apr  2 16:30:47 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 02 Apr 2012 18:30:47 +0200
Subject: librtlsdr - Terratec Cinergy T Stick Black (rev 1) works
In-Reply-To: <CAAUWWMEr-1D1Kg0Ceo_BhDHhsVo0GFOFuetAQ8C9uzsZn_EiUQ@mail.gmail.com>
References: <CAAUWWMEr-1D1Kg0Ceo_BhDHhsVo0GFOFuetAQ8C9uzsZn_EiUQ@mail.gmail.com>
Message-ID: <4F79D437.5080405@steve-m.de>

On 02.04.2012 16:58, Oliver Goldenstein wrote:
> Please add:
> 
>  { 0x0ccd, 0x00a9, "Terratec Cinergy T Stick Black (rev 1)" },
> 
> just tested with gnuradio.

Thanks, added.

Regards,
Steve



From davidb-sdr at rcpt.to  Mon Apr  2 16:31:10 2012
From: davidb-sdr at rcpt.to (David Basden)
Date: Tue,  3 Apr 2012 02:31:10 +1000
Subject: [PATCH] Correctly switch UHF and VHF filters for FC0012
In-Reply-To: <1333384270-8352-1-git-send-email-davidb-sdr@rcpt.to>
References: <1333384270-8352-1-git-send-email-davidb-sdr@rcpt.to>
Message-ID: <1333384270-8352-2-git-send-email-davidb-sdr@rcpt.to>

From: David Basden <davidb-git at rcpt.to>

---
 include/tuner_fc0012.h |    3 +++
 src/rtl-sdr.c          |    8 +++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/tuner_fc0012.h b/include/tuner_fc0012.h
index aa1d5e9..b4b669b 100644
--- a/include/tuner_fc0012.h
+++ b/include/tuner_fc0012.h
@@ -12,6 +12,9 @@
 #define FC0012_BANDWIDTH_7MHZ	7
 #define FC0012_BANDWIDTH_8MHZ	8
 
+/* Border between VHF and UHF filter bands: 300MHz */
+#define FC0012_BORDER_FREQ	300000000
+
 #define FC0012_LNA_GAIN_LOW	0x00
 #define FC0012_LNA_GAIN_MID	0x08
 #define FC0012_LNA_GAIN_HI	0x17
diff --git a/src/rtl-sdr.c b/src/rtl-sdr.c
index 52adec1..e825dc7 100644
--- a/src/rtl-sdr.c
+++ b/src/rtl-sdr.c
@@ -43,6 +43,8 @@ typedef struct rtlsdr_tuner {
 	int gain; /* dB */
 } rtlsdr_tuner_t;
 
+void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val);
+
 /* generic tuner interface functions, shall be moved to the tuner implementations */
 int e4k_init(void *dev) { return e4000_Initialize(dev); }
 int e4k_exit(void *dev) { return 0; }
@@ -53,9 +55,12 @@ int e4k_set_gain(void *dev, int gain) { return 0; }
 int fc0012_init(void *dev) { return FC0012_Open(dev); }
 int fc0012_exit(void *dev) { return 0; }
 int fc0012_tune(void *dev, int freq) {
-	/* TODO set GPIO6 accordingly */
 	unsigned int bw = 6;
+	
+	/* Set UHF/VHF filters through gpio6 */
+	rtlsdr_set_gpio_bit(dev, 6, (freq > FC0012_BORDER_FREQ)); 
 	return FC0012_SetFrequency(dev, freq/1000, bw & 0xff);
+
 }
 int fc0012_set_bw(void *dev, int bw) {
 	unsigned long freq = ((rtlsdr_tuner_t *)dev)->freq;
@@ -660,6 +665,7 @@ rtlsdr_dev_t *rtlsdr_open(uint32_t index)
 
 	/* initialise GPIOs */
 	rtlsdr_set_gpio_output(dev, 5);
+	rtlsdr_set_gpio_output(dev, 6);
 
 	/* reset tuner before probing */
 	rtlsdr_set_gpio_bit(dev, 5, 1);
-- 
1.7.9.5




From davidb-sdr at rcpt.to  Mon Apr  2 16:31:09 2012
From: davidb-sdr at rcpt.to (David Basden)
Date: Tue,  3 Apr 2012 02:31:09 +1000
Subject: [PATCH] Fix FC0012 tuner filters for librtlsdr
Message-ID: <1333384270-8352-1-git-send-email-davidb-sdr@rcpt.to>

Thanks to Steve for finding the bug in my GPIO code. This patch
should have the FC0012 using it's VHF/UHF filters correctly. 

The difference in the UHF band is pretty stunning: http://imgur.com/a/gEutK

Cheers,

David


David Basden (1):
  Correctly switch UHF and VHF filters for FC0012

 include/tuner_fc0012.h |    3 +++
 src/rtl-sdr.c          |    8 +++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

-- 
1.7.9.5




From steve at steve-m.de  Mon Apr  2 16:35:47 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 02 Apr 2012 18:35:47 +0200
Subject: [PATCH] Fix FC0012 tuner filters for librtlsdr
In-Reply-To: <1333384270-8352-1-git-send-email-davidb-sdr@rcpt.to>
References: <1333384270-8352-1-git-send-email-davidb-sdr@rcpt.to>
Message-ID: <4F79D563.7020101@steve-m.de>

On 02.04.2012 18:31, David Basden wrote:
> Thanks to Steve for finding the bug in my GPIO code. This patch
> should have the FC0012 using it's VHF/UHF filters correctly. 
> 
> The difference in the UHF band is pretty stunning: http://imgur.com/a/gEutK

Ah, thanks.. just committed my change a few minutes ago, thanks anyway!

Regards,
Steve



From schwandre at gmx.net  Mon Apr  2 21:33:04 2012
From: schwandre at gmx.net (schwandre at gmx.net)
Date: Mon, 02 Apr 2012 23:33:04 +0200
Subject: rtl-sdr with airprobe
Message-ID: <20120402213304.190290@gmx.net>

> I'd like to know what was the reasoning behind that statement ?

> To me it shows a deep lack of understanding on how that script works ...

the reason for this statement was, that i read somewhere,
that the example-file was recorded with 1,8 MS/s and decimation of 174.

yes, you are right, i don't know how that script works,
i read the sources and understood maybe 5% of it, because
this is all really new for me, as i am not a professional
and my last programm i wrote, was for the 6510 about 20 years ago....

now i did some more readings and found, that to have needed bandwith
of 200 khz with 1,8 MS/s is a decimation rate of 9 ?
decimation=MS/bw ?

guess i have to read a lot more, thanks for your info!

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a



From coinchon at yahoo.com  Thu Apr  5 13:05:51 2012
From: coinchon at yahoo.com (Mathias Coinchon)
Date: Thu, 5 Apr 2012 06:05:51 -0700 (PDT)
Subject: Tuner performance for rtl-sdr
Message-ID: <1333631151.85679.YahooMailNeo@web39306.mail.mud.yahoo.com>

Hi,

Does anybody have some hints, experiences on the performance difference (filtering, sensitivity, IQ imbalance, DC offset,..) between fc0012, fc0013 and e4000 tuners ?

I could not get my hands on an e4000 yet but just fc0012 and fc0013. On FM band I see quite a number of mirror images from strong signals.

Mathias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120405/c82e390d/attachment.htm>

From andrew at montefusco.com  Wed Apr  4 21:02:57 2012
From: andrew at montefusco.com (Andrea Montefusco)
Date: Wed, 04 Apr 2012 23:02:57 +0200
Subject: Buffer length in  rtlsdr_wait_async
Message-ID: <4F7CB701.2010309@montefusco.com>

Hi all,

together with Oliver  DL6KBG (that really provides me with all the hardware needed, thanks !), we 
are attempting to write a server suitable for use with ghpsdr3-alex SDR software.

A first attempt using the a home built code was quite successfully, albeit some defect is yet there.

Now we are trying to use the librtlsdr: first off, many thanks to developers.


We are stucked into  rtlsdr_wait_async that is using a fixed quite large buffer, as per

#define BUF_LENGTH     (16 * 16384)

now that is quite inconvenient in ghpsdr3-alex, because, at low sample rate (250000) we use, we are 
unable to cope with the large delay that this large buffer introduces.
So, just as crude workaround, we simply patched the value into the lib.
What would be ideal is an additional parameter in rtlsdr_wait_async that allow us to reduce the 
buffer to a more suitable size for our needs.

Thanks in advance

       *am*

---------------------------------------------------------
Andrea Montefusco iw0hdv        http://www.montefusco.com
tel: +393356992791                     fax: +390623318709
---------------------------------------------------------



From horiz0n at gmx.net  Sun Apr  8 21:27:36 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 08 Apr 2012 23:27:36 +0200
Subject: Buffer length in  rtlsdr_wait_async
In-Reply-To: <4F7CB701.2010309@montefusco.com>
References: <4F7CB701.2010309@montefusco.com>
Message-ID: <op.wcgtwap0vay7ep@thinkpad.artelis.net>

Hi Andrew,

thank you for the feedback. We've added a new function that allows to  
specify buffer size as well as the number of buffers used inside the  
library. Please give it a try.


Best regards,

Dimitri



From simeon.miteff at gmail.com  Wed Apr 11 21:46:14 2012
From: simeon.miteff at gmail.com (Simeon Miteff)
Date: Wed, 11 Apr 2012 23:46:14 +0200
Subject: rtl-sdr with Compro Videomate U620F
Message-ID: <4F85FBA6.6050002@gmail.com>

Hi All

The Compro Videomate U620F has the magic RTL2832+E4000 combination.

rtl-sdr recognises it with the patch:

https://gist.github.com/2362895

Regards,
Simeon.



From steve at steve-m.de  Wed Apr 11 23:09:49 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 12 Apr 2012 01:09:49 +0200
Subject: rtl-sdr with Compro Videomate U620F
In-Reply-To: <4F85FBA6.6050002@gmail.com>
References: <4F85FBA6.6050002@gmail.com>
Message-ID: <4F860F3D.8070400@steve-m.de>

Hi,

On 11.04.2012 23:46, Simeon Miteff wrote:
> The Compro Videomate U620F has the magic RTL2832+E4000 combination.

Thanks a lot, added it.

Regards,
Steve



From zn000h at gmail.com  Sun Apr 15 12:02:00 2012
From: zn000h at gmail.com (Benedikt Heinz)
Date: Sun, 15 Apr 2012 14:02:00 +0200
Subject: RTL-SDR ghost signal at center frequency & hangs in GR spectrum view
Message-ID: <CAFXU+zFtOjpM8_9ZxOEx1hf+9DHZkbmz3MbbZaK4N1sXnspY5A@mail.gmail.com>

Hi everyone,

can someone explain to me, what the origin of the ghost signal close
to center frequency is?
It can be seen at [1] and [2] - both are EzTV668 with no antenna connected.
It seems to me, that the higher the frequency, the more one can see
the "burst-like" nature
of this signal. Is this some mixer artefact from the E4k tuner?
The best workaround is probably tuning a bit off the actual target
frequency and using frequency xlate?

Also, in [3] (german) the blind spot at 0Hz due to the coupling
capacitors between E4k & RTL is mentioned.
Is it possible to replace the capacitors with 0-Ohm resistors to work
around this issue, or will this cause
other unwanted side-effects?
Or does this make no sense at all since one should always tune a bit
off and use xlate due to the ghost signal?

I guess it should also be possible (w/ some hot glue & wires) to
insert some jumpers (like OsmoSDR)
instead, so one can use the ADCs directly for LF/MF with some extra
analog stuff?

Regarding the OsmoSDR source - I also gave the RTL-source from gr-baz
a try and noticed,
that with averaging enabled in the spectrum view in GR, the top-block
GUI usually won't react to user input
any longer when using OsmoSDR, but this doesn't happen with the gr-baz
RTL source, although I used
the same sample rate in both cases. Does anyone understand why it
doesn't hang with the gr-baz source?

Thanks for your answers!

Regards,

hunz

[1] http://hackdaworld.org/~hunz/rtl-sdr/wo_ant_2m_osmo.png
[2] http://hackdaworld.org/~hunz/rtl-sdr/wo_ant_70cm_osmo.png
[3] http://www.mikrocontroller.net/topic/253371#2610540

--
Benedikt Heinz
hunz at jabber.berlin.ccc.de



From jsalsburg at bellsouth.net  Mon Apr 16 04:58:59 2012
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Sun, 15 Apr 2012 23:58:59 -0500
Subject: RTL-SDR ghost signal at center frequency & hangs in GR spectrum
	view
In-Reply-To: <CAFXU+zFtOjpM8_9ZxOEx1hf+9DHZkbmz3MbbZaK4N1sXnspY5A@mail.gmail.com>
References: <CAFXU+zFtOjpM8_9ZxOEx1hf+9DHZkbmz3MbbZaK4N1sXnspY5A@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAAAQkU5B//hJuZh2bbp+1t/CgAAAEAAAANgsclgOQSZGqYaHL9HurZ4BAAAAAA==@bellsouth.net>

Without direct examination, I would say, the peak shown in [1] is energy
from the Local Oscillator being directly converted. Many receivers that use
direct conversion suffer from the oscillator coming through the mixer. If
you were to build a Direct Conversion Tuner from scratch with the option of
suppressing the "birdie" at the conversion frequency, the mixer would have
to designed as a Double-Balanced Demodulator, that suppresses the carrier
wave frequency.

It appears you are using GNU RADIO. Not being completely familiar with its
operation, I can guess that this software can be configured to suppress the
CW energy before the I/Q stream is decoded.

It is advised not to connect the Tuner's RF input directly to an antenna
without a coupling capacitor, there will is a DC component and may damage
the LNA in the Tuner chip. Coupling Capacitors on the Differential I/Q
outputs are to isolate DC paths between the Tuner and the Converter Chip,
also advisable not to directly connect them for the same reason. 

-----Original Message-----
From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Benedikt Heinz
Sent: Sunday, April 15, 2012 7:02 AM
To: osmocom-sdr at lists.osmocom.org
Subject: RTL-SDR ghost signal at center frequency & hangs in GR spectrum
view

Hi everyone,

can someone explain to me, what the origin of the ghost signal close to
center frequency is?
It can be seen at [1] and [2] - both are EzTV668 with no antenna connected.
It seems to me, that the higher the frequency, the more one can see the
"burst-like" nature of this signal. Is this some mixer artefact from the E4k
tuner?
The best workaround is probably tuning a bit off the actual target frequency
and using frequency xlate?

Also, in [3] (german) the blind spot at 0Hz due to the coupling capacitors
between E4k & RTL is mentioned.
Is it possible to replace the capacitors with 0-Ohm resistors to work around
this issue, or will this cause other unwanted side-effects?
Or does this make no sense at all since one should always tune a bit off and
use xlate due to the ghost signal?

I guess it should also be possible (w/ some hot glue & wires) to insert some
jumpers (like OsmoSDR) instead, so one can use the ADCs directly for LF/MF
with some extra analog stuff?

Regarding the OsmoSDR source - I also gave the RTL-source from gr-baz a try
and noticed, that with averaging enabled in the spectrum view in GR, the
top-block GUI usually won't react to user input any longer when using
OsmoSDR, but this doesn't happen with the gr-baz RTL source, although I used
the same sample rate in both cases. Does anyone understand why it doesn't
hang with the gr-baz source?

Thanks for your answers!

Regards,

hunz

[1] http://hackdaworld.org/~hunz/rtl-sdr/wo_ant_2m_osmo.png
[2] http://hackdaworld.org/~hunz/rtl-sdr/wo_ant_70cm_osmo.png
[3] http://www.mikrocontroller.net/topic/253371#2610540

--
Benedikt Heinz
hunz at jabber.berlin.ccc.de




From cd at maintech.de  Thu Apr 19 14:01:48 2012
From: cd at maintech.de (Christian Daniel -- maintech GmbH)
Date: Thu, 19 Apr 2012 16:01:48 +0200
Subject: OsmoSDR - they're on final approach
Message-ID: <4F901ACC.6020600@maintech.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everybody,

just as a short heads up: The new boards have arrived and the first
batch of 20 is assembled. Since we did changes to the layout we will
verify them before we do the other 80. This should take no more than a
few days. Stay tuned!

BTW: The new pre-amp/lnb really does add 18dB :)

Best regards,
Christian

- -- 
- ---------------------------------------------------
| maintech #      Dipl. Inf (FH) Christian Daniel |
|   GmbH ### Otto-Hahn-Str. 15 ? D-97204 H?chberg |
- ---------------------------------------------------
| AG W?rzburg, HRB 8790        Tax-ID DE242279645 |
- ---------------------------------------------------
| http://www.maintech.de           cd at maintech.de |
- ---------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPkBrEAAoJEHkgzUIsAWritBgH/RqDZuLRLQ/22msTdvZ+EIqk
6Y98xDBrDcXSkTSsFBQvLwdKANUxxi3dVvTjknBw3lnrWzT8fo2uVMg97c/R6Eov
fGOvALbXckgrmvz0n/IZdROu8x38zs/ro0uweN0oxb14+U/2CW5VVeJusqcQoBL6
Ug4XAtzXpyR04pmjjq6jzxtsmsXuv42KToG7R9UvkiNz8WXhxlaaUmA+ccJGM+8+
FCITzYY9ZMfFo2IekXDGkZNsKwux37B8cQxYIlcSlPxlSrPzusFyyqEq2AmM1iIn
SbuRnmjzeUQbsgGVINmVP1B3EDOczeYWyeKC/5myXbr+Ogpp9/PD9K9aJG/sKYM=
=KY1W
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmocom.jpg
Type: image/jpeg
Size: 132001 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120419/3bb757f9/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmocom.jpg.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120419/3bb757f9/attachment.obj>

From michael.feilen at tum.de  Thu Apr 19 13:35:46 2012
From: michael.feilen at tum.de (Feilen, Michael)
Date: Thu, 19 Apr 2012 13:35:46 +0000
Subject: Real-time DRM+ receiver chain using the NOXON stick
Message-ID: <33377D03FACB744A9E776A6B011C37FD37543473@BADWLRZ-SWMBX1.ads.mwn.de>

Dear Osmocon-SDR People,

Thank you so much for providing the information on the RTL-SDR USB sticks on your webpage!
I've used the stick to get a DRM+ receiver implementation running and the stick seems to work quite well: http://www.youtube.com/watch?v=zeGs7CQlvRg

I've had to twiddle around with the tuner parameters of the FC0013 to get it running stable. However, I've never reached more than 25 dB SNR for the in-band OFDM signal (which has a bw of 100 kHz and I'm resampling from 1 MS/s to 120 kS/s). I wonder if the tuner is the limiting factor or the RTL chip. With a resolution of 8 bit, I would have expected more. Hmm, maybe it's the phase noise of the tuner or the IQ correction routines of the RTL chip? Has anybody of you guys a meaningful measure for the quality of the different tuners for the RTL stick? I know that the E4000 supports a higher bandwidth but does it provide a better IQ signal with less distortion?

Cheers,
Michael



From steve at steve-m.de  Fri Apr 20 21:43:46 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 20 Apr 2012 23:43:46 +0200
Subject: RTL-SDR ghost signal at center frequency & hangs in GR spectrum
	view
In-Reply-To: <CAFXU+zFtOjpM8_9ZxOEx1hf+9DHZkbmz3MbbZaK4N1sXnspY5A@mail.gmail.com>
References: <CAFXU+zFtOjpM8_9ZxOEx1hf+9DHZkbmz3MbbZaK4N1sXnspY5A@mail.gmail.com>
Message-ID: <4F91D892.20203@steve-m.de>

Hi,

On 15.04.2012 14:02, Benedikt Heinz wrote:
> can someone explain to me, what the origin of the ghost signal close
> to center frequency is?

This was caused by the automatic DC offset correction of the E4000,
which I disabled in the last commit.

That's how it looked on the scope, pretty bad:
http://steve-m.de/pictures/e4k_dc.png

Regards,
Steve



From michal.demin at gmail.com  Mon Apr 23 16:51:01 2012
From: michal.demin at gmail.com (Michal Demin)
Date: Mon, 23 Apr 2012 18:51:01 +0200
Subject: Detach kernel driver
In-Reply-To: <CAA5WxY3sykvtxkdDSLZnsocxYiejsenMXwinV-nr7qPA4t23tA@mail.gmail.com>
References: <CAA5WxY3sykvtxkdDSLZnsocxYiejsenMXwinV-nr7qPA4t23tA@mail.gmail.com>
Message-ID: <CAA5WxY00hDhf82cR6NF6ZFs=YBUxZGyzPkALc7L9iOuPsUUCEw@mail.gmail.com>

Hello,

Attached are 2 patches:
1 - Try to detach kernel driver from device, when kernel driver present.
2 - add rtl_tcp binary to gitignore.


?Michal Demin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Detach-the-device-kernel-driver-when-kernel-driver-l.patch
Type: application/octet-stream
Size: 1483 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120423/aeb550be/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-rtl_tcp-binary-to-gitignore.patch
Type: application/octet-stream
Size: 509 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120423/aeb550be/attachment-0001.obj>

From peter at stuge.se  Mon Apr 23 17:11:23 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 23 Apr 2012 19:11:23 +0200
Subject: Detach kernel driver
In-Reply-To: <CAA5WxY00hDhf82cR6NF6ZFs=YBUxZGyzPkALc7L9iOuPsUUCEw@mail.gmail.com>
References: <CAA5WxY3sykvtxkdDSLZnsocxYiejsenMXwinV-nr7qPA4t23tA@mail.gmail.com>
	<CAA5WxY00hDhf82cR6NF6ZFs=YBUxZGyzPkALc7L9iOuPsUUCEw@mail.gmail.com>
Message-ID: <20120423171123.16616.qmail@stuge.se>

Michal Demin wrote:
> Subject: [PATCH 1/2] Detach the device kernel driver when kernel driver loaded.
..
> @@ -689,6 +690,15 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
>  
>  	libusb_free_device_list(list, 0);
>  
> +	if (libusb_kernel_driver_active(dev->devh, 0)) {
> +		// reattach later
> +		dev->reattach = 1;
> +		if (libusb_detach_kernel_driver(dev->devh, 0)) {
> +			fprintf(stderr, "Error detaching kernel driver \n");
> +			goto err;
> +		}
> +	}
> +
>  	r = libusb_claim_interface(dev->devh, 0);
>  	if (r < 0) {
>  		fprintf(stderr, "usb_claim_interface error %d\n", r);

This is racy. It's better to call libusb_detach_kernel_driver() when
libusb_claim_interface() returns an error.


//Peter



From michal.demin at gmail.com  Mon Apr 23 20:25:44 2012
From: michal.demin at gmail.com (Michal Demin)
Date: Mon, 23 Apr 2012 22:25:44 +0200
Subject: Detach kernel driver
In-Reply-To: <20120423171123.16616.qmail@stuge.se>
References: <CAA5WxY3sykvtxkdDSLZnsocxYiejsenMXwinV-nr7qPA4t23tA@mail.gmail.com>
	<CAA5WxY00hDhf82cR6NF6ZFs=YBUxZGyzPkALc7L9iOuPsUUCEw@mail.gmail.com>
	<20120423171123.16616.qmail@stuge.se>
Message-ID: <CAA5WxY3M4hJUGx8FSBRWRHAL65jvxCSMxr=fTaQyvNTY9UrXAQ@mail.gmail.com>

Hi Peter,

I don't really see the problem.

Ether kernel had the driver loaded, or there is other app. If there is
kernel I detach the kernel driver and the device is claimed.
If other app is using the device then I will only try to claim. (Which
will fail)

I can only see the "racy" when 2 applications are concurrently trying
to claim the device, in which case not even your solution
is perfect :-)

Could you please be more specific with the problem?

 Md

On Mon, Apr 23, 2012 at 7:11 PM, Peter Stuge <peter at stuge.se> wrote:
> Michal Demin wrote:
>> Subject: [PATCH 1/2] Detach the device kernel driver when kernel driver loaded.
> ..
>> @@ -689,6 +690,15 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
>>
>> ? ? ? libusb_free_device_list(list, 0);
>>
>> + ? ? if (libusb_kernel_driver_active(dev->devh, 0)) {
>> + ? ? ? ? ? ? // reattach later
>> + ? ? ? ? ? ? dev->reattach = 1;
>> + ? ? ? ? ? ? if (libusb_detach_kernel_driver(dev->devh, 0)) {
>> + ? ? ? ? ? ? ? ? ? ? fprintf(stderr, "Error detaching kernel driver \n");
>> + ? ? ? ? ? ? ? ? ? ? goto err;
>> + ? ? ? ? ? ? }
>> + ? ? }
>> +
>> ? ? ? r = libusb_claim_interface(dev->devh, 0);
>> ? ? ? if (r < 0) {
>> ? ? ? ? ? ? ? fprintf(stderr, "usb_claim_interface error %d\n", r);
>
> This is racy. It's better to call libusb_detach_kernel_driver() when
> libusb_claim_interface() returns an error.
>
>
> //Peter
>



From peter at stuge.se  Mon Apr 23 20:57:11 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 23 Apr 2012 22:57:11 +0200
Subject: Detach kernel driver
In-Reply-To: <CAA5WxY3M4hJUGx8FSBRWRHAL65jvxCSMxr=fTaQyvNTY9UrXAQ@mail.gmail.com>
References: <CAA5WxY3sykvtxkdDSLZnsocxYiejsenMXwinV-nr7qPA4t23tA@mail.gmail.com>
	<CAA5WxY00hDhf82cR6NF6ZFs=YBUxZGyzPkALc7L9iOuPsUUCEw@mail.gmail.com>
	<20120423171123.16616.qmail@stuge.se>
	<CAA5WxY3M4hJUGx8FSBRWRHAL65jvxCSMxr=fTaQyvNTY9UrXAQ@mail.gmail.com>
Message-ID: <20120423205711.2091.qmail@stuge.se>

Michal Demin wrote:
> I don't really see the problem.

Between the time you check for a driver and claim there's a window of
opportunity for another driver (usbfs or other) to attach. Best just
try to claim and on suitable error try to detach, then try to claim
again.


> If other app is using the device then I will only try to claim.
> (Which will fail)

False and false. :) If another app is using the device, the kernel
driver "usbfs" is active, and you will detach it, kicking the other
app out. Then you will claim successfully if the other app does not
try to claim again.

If you try to claim without first detaching, the claim will fail.


//Peter



From michal.demin at gmail.com  Mon Apr 23 22:22:57 2012
From: michal.demin at gmail.com (Michal Demin)
Date: Tue, 24 Apr 2012 00:22:57 +0200
Subject: Detach kernel driver
In-Reply-To: <20120423205711.2091.qmail@stuge.se>
References: <CAA5WxY3sykvtxkdDSLZnsocxYiejsenMXwinV-nr7qPA4t23tA@mail.gmail.com>
	<CAA5WxY00hDhf82cR6NF6ZFs=YBUxZGyzPkALc7L9iOuPsUUCEw@mail.gmail.com>
	<20120423171123.16616.qmail@stuge.se>
	<CAA5WxY3M4hJUGx8FSBRWRHAL65jvxCSMxr=fTaQyvNTY9UrXAQ@mail.gmail.com>
	<20120423205711.2091.qmail@stuge.se>
Message-ID: <CAA5WxY0HpezjyK=4nwX-pf1bUVoG30+ZcX8__1O8gR+-WfCkwg@mail.gmail.com>

On Mon, Apr 23, 2012 at 10:57 PM, Peter Stuge <peter at stuge.se> wrote:
> Michal Demin wrote:
>> I don't really see the problem.
>
> Between the time you check for a driver and claim there's a window of
> opportunity for another driver (usbfs or other) to attach. Best just
> try to claim and on suitable error try to detach, then try to claim
> again.

There is no way to differentiate between errors. In my test I always get
error -6 - LIBUSB_ERROR_BUSY. So no such thing as "suitable error"
exists.

>
>
>> If other app is using the device then I will only try to claim.
>> (Which will fail)
>
> False and false. :) If another app is using the device, the kernel
> driver "usbfs" is active, and you will detach it, kicking the other
> app out. Then you will claim successfully if the other app does not
> try to claim again.
>
> If you try to claim without first detaching, the claim will fail.
>
>
> //Peter
>

If i do it the other way around:

if (libsusb_claim_error()) {
  libusb_detach()
  libusb_claim_again();
}

There is the same "window of opportunity" for different application to jump in.
Between detaching and claiming the device. (as the system is fully
preemptive, etc etc ...)

The API of libusb-1.0 doesn't provide facility to test whether "usbfs" is
using the device or other driver (there used to be way to read driver name
in libusb 0.1).

The only solution to this problem is not to have the DVB-t module present
or have the module blacklisted and load it when necessary.

 MD



From peter at stuge.se  Mon Apr 23 23:03:42 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 24 Apr 2012 01:03:42 +0200
Subject: Detach kernel driver
In-Reply-To: <CAA5WxY0HpezjyK=4nwX-pf1bUVoG30+ZcX8__1O8gR+-WfCkwg@mail.gmail.com>
References: <CAA5WxY3sykvtxkdDSLZnsocxYiejsenMXwinV-nr7qPA4t23tA@mail.gmail.com>
	<CAA5WxY00hDhf82cR6NF6ZFs=YBUxZGyzPkALc7L9iOuPsUUCEw@mail.gmail.com>
	<20120423171123.16616.qmail@stuge.se>
	<CAA5WxY3M4hJUGx8FSBRWRHAL65jvxCSMxr=fTaQyvNTY9UrXAQ@mail.gmail.com>
	<20120423205711.2091.qmail@stuge.se>
	<CAA5WxY0HpezjyK=4nwX-pf1bUVoG30+ZcX8__1O8gR+-WfCkwg@mail.gmail.com>
Message-ID: <20120423230342.15032.qmail@stuge.se>

Michal Demin wrote:
> If i do it the other way around:
> 
> if (libsusb_claim_error()) {
>   libusb_detach()
>   libusb_claim_again();
> }
> 
> There is the same "window of opportunity" for different application
> to jump in. Between detaching and claiming the device. (as the
> system is fully preemptive, etc etc ...)

Yes, it's not perfect. But if claim fails twice I think it's
acceptable to error out and let the user sort out her system.


> The API of libusb-1.0 doesn't provide facility to test whether "usbfs"
> is using the device or other driver (there used to be way to read
> driver name in libusb 0.1).

Yes. libusb does not offer a very comprehensive API for kernel driver
management and I can't help but feel that this is a good thing. It's
not really the problem libusb wants to solve. But I also recognize
that the current state of affairs is not so convenient with devices
which can bounce between different kernel and userspace drivers. I
think libusb can't really solve the problem all on it's own, I think
that it also needs some rethinking of what kernels do, but making
significant improvements in this area requires a competent and
dedicated engineering effort..


> The only solution to this problem is not to have the DVB-t module
> present or have the module blacklisted and load it when necessary.

I disagree: Using the code you outline above you will have success if
the module is loaded but the interface is not being used and you have
rights to detach the module driver. (Use udev to give your user
these, so the application doesn't have to run as root.) You will also
have success if no driver at all is currently bound to the interface,
as is the case if a program calls libusb_release_interface() and then
exits (without _attach_kernel_driver()).


//Peter