From 246tnt at gmail.com  Thu Nov  1 20:34:44 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 1 Nov 2012 21:34:44 +0100
Subject: 4Mbps hack wiring & 48 MHz spurs
Message-ID: <CAHL+j09=4ZqnE9tgCN8W7K0QZx2s6zJW+OiA6ja4cMMG4+4xvA@mail.gmail.com>

Just fyi, here's how I did the 4msps wiring hack :

http://i.imgur.com/TODkU.png

Basically use resistors (I used 270R which is a bit high ,between 20 and
10R would bwe better) on the back side on the PCB.

I initially started with wire jumpers on the pins, then moved to resisors
on the top but that created a huge loop area with the ground return (there
is no gnd on those connection) which was heavily radiating.

Mounting on the back like that dropped it significantely for me (especially
on baseband), but you still clearly see it.

I think the FPGA drive strength on the data pins is still way too high and
should be reduced.

Maybe using spread spectrum on the MCI would be another idea ?

Cheers,

    Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121101/a8a0c2b5/attachment.htm>

From james at peroulas.com  Sun Nov  4 01:21:36 2012
From: james at peroulas.com (James Peroulas)
Date: Sat, 3 Nov 2012 20:21:36 -0500
Subject: Latest Ubuntu update
In-Reply-To: <CA+XcqA7fJArA-kwZM7Ve+7gTei1Fj+4gpS4X4cPxeMX9pL98BA@mail.gmail.com>
References: <CA+XcqA46eF3gOWTd8=bjOidGLjUbwZ6xYDnkB=n4g3oTX6PWMw@mail.gmail.com>
	<508DA833.90306@steve-m.de>
	<CA+XcqA7fJArA-kwZM7Ve+7gTei1Fj+4gpS4X4cPxeMX9pL98BA@mail.gmail.com>
Message-ID: <CA+XcqA4S6wqV8UThv+_4rEm1JCrGWiDioWUSmYs62v0xQc-nFg@mail.gmail.com>

Just a FYI, I went to 32 bit Ubuntu and now I can terminate captures just
fine.

JP



On Sun, Oct 28, 2012 at 10:46 PM, James Peroulas <james at peroulas.com> wrote:

> On Sun, Oct 28, 2012 at 4:48 PM, Steve Markgraf <steve at steve-m.de> wrote:
>
>> Strange. I just tried it with both Ubuntu 12.04 and 12.10 with all
>> updates installed, and it works just fine...
>>
>
> Hmm... So I just re-installed Ubuntu 12.04 from scratch and am still
> having the same problem... Are you using the 64 or 32 bit version of
> Ubuntu? I'm using 64 bits.
>
> BR,
> James
>
> --
> *Integrity is a binary state - **either you have it or you don?t.* - John
> Doerr
>



-- 
*Integrity is a binary state - **either you have it or you don?t.* - John
Doerr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121103/1769aeee/attachment.htm>

From zaitcev at kotori.zaitcev.us  Tue Nov  6 05:44:08 2012
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Mon, 5 Nov 2012 22:44:08 -0700
Subject: Small thinko in testing for clock_gettime
Message-ID: <20121105224408.340948ac@lembas.zaitcev.lan>

This appears to be not tested with autoconf (cmake works). The assignment
to $LIBS changes nothing, which cannot possibly be the intent.

---

cc-ing to original patch author and sign-off

diff --git a/configure.ac b/configure.ac
index 1b94701..c760787 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,7 +40,7 @@ dnl libmath (for rtl_fm)
 AC_CHECK_LIB(m, atan2, [LIBS="$LIBS -lm"])
 
 dnl librealtime (for rtl_test)
-AC_CHECK_LIB(rt, clock_gettime, [LIBS="$LIBS"])
+AC_CHECK_LIB(rt, clock_gettime, [LIBS="$LIBS -lrt"])
 
 # The following test is taken from WebKit's webkit.m4
 saved_CFLAGS="$CFLAGS"



From horiz0n at gmx.net  Wed Nov  7 19:24:11 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Wed, 07 Nov 2012 20:24:11 +0100
Subject: Small thinko in testing for clock_gettime
In-Reply-To: <20121105224408.340948ac@lembas.zaitcev.lan>
References: <20121105224408.340948ac@lembas.zaitcev.lan>
Message-ID: <op.wne36lxovay7ep@wopr.artelis.net>

Hi Pete,

thanks for bringing this up, it's fixed now.

Best regards,

Dimitri

On Tue, 06 Nov 2012 06:44:08 +0100, Pete Zaitcev  
<zaitcev at kotori.zaitcev.us> wrote:

> This appears to be not tested with autoconf (cmake works). The assignment
> to $LIBS changes nothing, which cannot possibly be the intent.
>
> ---
>
> cc-ing to original patch author and sign-off
>
> diff --git a/configure.ac b/configure.ac
> index 1b94701..c760787 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -40,7 +40,7 @@ dnl libmath (for rtl_fm)
>  AC_CHECK_LIB(m, atan2, [LIBS="$LIBS -lm"])
> dnl librealtime (for rtl_test)
> -AC_CHECK_LIB(rt, clock_gettime, [LIBS="$LIBS"])
> +AC_CHECK_LIB(rt, clock_gettime, [LIBS="$LIBS -lrt"])
> # The following test is taken from WebKit's webkit.m4
>  saved_CFLAGS="$CFLAGS"



From mngc at citromail.hu  Wed Nov  7 20:25:35 2012
From: mngc at citromail.hu (=?UTF-8?B?SMO2c3MgTGFqb3Mg?=)
Date: Wed, 7 Nov 2012 21:25:35 +0100
Subject: =?UTF-8?B?UlRMLVNEUiB3aXRoIE1TSSBESUdJVk9YIE1pY3JvIEhEIHN1cHBvcnQ=?=
Message-ID: <20121107212535.7993@citromail.hu>

Hi,

Good news with MSI DIGIVOX Micro HD (1d19:1104) DVB-T tuner. Now the tuner working. Succesfully received analague UHF TV sound channel 80 kilometer distance from transmitter, taxi driver (164 Mhz) and one frequency from 70cm radio amateur band. 

The tuner is FCI FC2580 from debug message. I see on http://sdr.osmocom.org/trac/wiki/rtl-sdr great new info for this tuner 146 - 308 MHz and 438 - 924 MHz (gap in between). Not have any wideband generator for check this, but for example with strong local FM radio station 87.5-108MHz tunable, but received only noise. I think the frequency range possibly same. All rtl-sdr DVB-T tuner with fc2850 has a same frequency range? I interesting for not working frequiency, working frequiency or working freq. but poor receiver quality, or any gap. I interesting also for 2 meter radio amateur band, only max. 2 MHz lower. 144-146MHZ only noise received, i not know my antenna bad, or this is not possible.

mngc



From sq5bpf at lipkowski.org  Thu Nov  8 22:09:18 2012
From: sq5bpf at lipkowski.org (Jacek Lipkowski)
Date: Thu, 8 Nov 2012 23:09:18 +0100 (CET)
Subject: removing the L-band gap on E4000
Message-ID: <Pine.LNX.4.64.1211082257550.6321@paranoid.lipkowski.org>

Hello

I've tried to remove the L-band gap on my E4000 tuner by changing the 
divisors. Please see the patch below. I don't have a signal source to test 
today, so i'm not sure if it works, but the pll locks. I will try to test 
tomorrow.

Without my hack: E4K L-band gap: 1093 to 1233 MHz

With my hack:

sq5bpf at dellix:~/gnuradio/rtl-sdr/src$ ./rtl_test -t
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
Benchmarking E4000 PLL...
[E4K] PLL not locked for 51000000 Hz!
[E4K] PLL not locked for 2186000000 Hz!
E4K range: 52 to 2185 MHz
E4K L-band gap: 0 to 0 MHz


Regards

Jacek / SQ5BPF



--- tuner_e4k.c.orig	2012-11-08 22:08:07.000000000 +0100
+++ tuner_e4k.c	2012-11-08 23:01:05.000000000 +0100
@@ -35,6 +35,7 @@
  /* If this is defined, the limits are somewhat relaxed compared to what the
   * vendor claims is possible */
  #define OUT_OF_SPEC
+#define HACKED_DIVISORS

  #define MHZ(x)	((x)*1000*1000)
  #define KHZ(x)	((x)*1000)
@@ -357,7 +358,14 @@
  	{KHZ(350000),	(1 << 3) | 1,	8},
  	{KHZ(432000),	(0 << 3) | 3,	8},
  	{KHZ(667000),	(0 << 3) | 2,	6},
-	{KHZ(1200000),	(0 << 3) | 1,	4}
+#ifdef HACKED_DIVISORS
+/* the original settings seem to be ripped from some Elonics driver,
+ * however changing them a bit removes the L-band gap 
+ * change this to a bit more then the end of your L-band gap --sq5bpf */
+	{KHZ(1270000),	(0 << 3) | 1,	3} 
+#else
+	{KHZ(1200000),  (0 << 3) | 1,   4}
+#endif
  };

  static int is_fvco_valid(uint32_t fvco_z)



From steve at steve-m.de  Thu Nov  8 22:45:34 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 08 Nov 2012 23:45:34 +0100
Subject: removing the L-band gap on E4000
In-Reply-To: <Pine.LNX.4.64.1211082257550.6321@paranoid.lipkowski.org>
References: <Pine.LNX.4.64.1211082257550.6321@paranoid.lipkowski.org>
Message-ID: <509C360E.8050507@steve-m.de>

Hi,

On 08.11.2012 23:09, Jacek Lipkowski wrote:

> I've tried to remove the L-band gap on my E4000 tuner by changing the
> divisors. Please see the patch below. I don't have a signal source to
> test today, so i'm not sure if it works, but the pll locks. I will try
> to test tomorrow.

Sorry, that won't work.
Did you even bother to take a look at the datasheet?

> +    {KHZ(1270000),    (0 << 3) | 1,    3}

You are using /R = 3 as output divider, which can't be programmed. See
"Table 2: Output divider" for possible values.

Regards,
Steve



From sq5bpf at lipkowski.org  Thu Nov  8 22:51:55 2012
From: sq5bpf at lipkowski.org (Jacek Lipkowski)
Date: Thu, 8 Nov 2012 23:51:55 +0100 (CET)
Subject: removing the L-band gap on E4000
In-Reply-To: <509C360E.8050507@steve-m.de>
References: <Pine.LNX.4.64.1211082257550.6321@paranoid.lipkowski.org>
	<509C360E.8050507@steve-m.de>
Message-ID: <Pine.LNX.4.64.1211082347090.6321@paranoid.lipkowski.org>

On Thu, 8 Nov 2012, Steve Markgraf wrote:

> Sorry, that won't work.
> Did you even bother to take a look at the datasheet?

Sorry, last i checked there was none avaliable (now i found it).
I've made an idiot out of myself.

Thanks

Jacek



From a.nielsen at shikadi.net  Sun Nov 11 01:52:52 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Sun, 11 Nov 2012 11:52:52 +1000
Subject: E4000 undocumented registers?
Message-ID: <509F04F4.10402@shikadi.net>

Hi all,

I've been looking at the E4000 tuner code and I have a couple of questions 
that aren't answered in the datasheet.  I'm hoping someone here might have 
some insight.

In the Elonics-supplied code[1] when setting the frequency (around line 1339), 
they always write a 1 into register 0x07 (Synth1), which is the "PLL locked" 
register.  Does this affect anything?  The datasheet says it's read only and 
librtlsdr only ever reads this value, it never writes to it.

Then, beginning at 82.9MHz and continuing at every multiple of 28.8MHz above 
this, the first 7MHz is tuned differently, but the rest of the 21.8MHz in that 
"channel" is set normally.  This stops between 233.9MHz and 485.6MHz, then 
resumes again at 8MHz increments instead of 7MHz up until 868MHz.

When tuned differently, register 0x05 (Input clock) gets set to 3, which isn't 
listed in the datasheet (and also says 'do not write to this register').

Mostly (but not always) when this happens (i.e. first 7-8MHz of the channel), 
register 0x07 bits 3-4 are also set to various arbitrary values.  The 
datasheet says 0 means "16-32MHz input clock freq range" but this code writes 
1 and 2 into this field as well.  It seems to write approximately these values:

   1 up to 89.9MHz
   0 up to 118.7MHz
   1 up to 205.1MHz
   2 up to 233.9MHz
   0 up to 551.2MHz
   1 up to 752.8MHz
   2 up to 868MHz
   0 after 868MHz

After the first 7-8MHz the rest of the 28.8MHz channel has the default 0 value 
set.

Does anyone know what these values control?

As a side note, register 0x08 (Synth2) appears to do something even though 
it's listed as reserved.  By setting particular bits I can get the rtl_test 
program to not lock on to any frequency, but oddly enough rtl_fm still works 
fine.  I'm not sure what to make of this yet.  I don't suppose this register 
is documented anywhere else?  I'm just wondering whether the datasheets 
supplied by Elonics are different to the one that is now public.

Thanks,
Adam.

[1]: One of many copies is at 
https://github.com/mbarbon/rtl2832/blob/master/tuners/tuner_e4000.c



From lazzaroleonardo at gmail.com  Mon Nov 12 19:28:42 2012
From: lazzaroleonardo at gmail.com (Leonardo Lazzaro)
Date: Mon, 12 Nov 2012 16:28:42 -0300
Subject: Compilation issue
Message-ID: <CADgJ7oN9Gxhi2VxwjbortyYz0Ly=23HWX+GoKrRHH7kkmxxvSA@mail.gmail.com>

Hi!

I was trying to compile the osmocom sdr project and also trying to report a
compilation error.
I will like to have an account to contribute.

this was the error I got:

In file included from
/home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.h:23:0,
                 from
/home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:30:
/home/llazzaro/tmp/gr-osmosdr/include/osmosdr/osmosdr_source_c.h: In
constructor ?osmosdr_source_c::osmosdr_source_c()?:
/home/llazzaro/tmp/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:57:19:
error: no matching function for call to ?gr_hier_block2::gr_hier_block2()?
/home/llazzaro/tmp/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:57:19:
note: candidates are:
/usr/include/gnuradio/gr_hier_block2.h:57:3: note:
gr_hier_block2::gr_hier_block2(const string&, gr_io_signature_sptr,
gr_io_signature_sptr)
/usr/include/gnuradio/gr_hier_block2.h:57:3: note:   candidate expects 3
arguments, 0 provided
/usr/include/gnuradio/gr_hier_block2.h:43:7: note:
gr_hier_block2::gr_hier_block2(const gr_hier_block2&)
/usr/include/gnuradio/gr_hier_block2.h:43:7: note:   candidate expects 1
argument, 0 provided
/home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In constructor
?osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)?:
/home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:83:35: note:
synthesized method ?osmosdr_source_c::osmosdr_source_c()? first required
here
make[2]: ***
[lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
make: *** [all] Error 2

-- 
http://www.lazzaroleonardo.com.ar/
twitter @llazzaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121112/76cf3e93/attachment.htm>

From horiz0n at gmx.net  Mon Nov 12 20:15:56 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Mon, 12 Nov 2012 21:15:56 +0100
Subject: Compilation issue
In-Reply-To: <CADgJ7oN9Gxhi2VxwjbortyYz0Ly=23HWX+GoKrRHH7kkmxxvSA@mail.gmail.com>
References: <CADgJ7oN9Gxhi2VxwjbortyYz0Ly=23HWX+GoKrRHH7kkmxxvSA@mail.gmail.com>
Message-ID: <op.wnofwu0avay7ep@wopr.artelis.net>

Hi Leonardo,

you should have provided a little more information than this, like what is  
your gr version (there are *many* of them out there) and which compiler  
are you using?


Best regards,

Dimitri


On Mon, 12 Nov 2012 20:28:42 +0100, Leonardo Lazzaro  
<lazzaroleonardo at gmail.com> wrote:

> Hi!
>
> I was trying to compile the osmocom sdr project and also trying to  
> report a
> compilation error.
> I will like to have an account to contribute.
>
> this was the error I got:
>
> In file included from
> /home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.h:23:0,
>                  from
> /home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:30:
> /home/llazzaro/tmp/gr-osmosdr/include/osmosdr/osmosdr_source_c.h: In
> constructor ?osmosdr_source_c::osmosdr_source_c()?:
> /home/llazzaro/tmp/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:57:19:
> error: no matching function for call to  
> ?gr_hier_block2::gr_hier_block2()?
> /home/llazzaro/tmp/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:57:19:
> note: candidates are:
> /usr/include/gnuradio/gr_hier_block2.h:57:3: note:
> gr_hier_block2::gr_hier_block2(const string&, gr_io_signature_sptr,
> gr_io_signature_sptr)
> /usr/include/gnuradio/gr_hier_block2.h:57:3: note:   candidate expects 3
> arguments, 0 provided
> /usr/include/gnuradio/gr_hier_block2.h:43:7: note:
> gr_hier_block2::gr_hier_block2(const gr_hier_block2&)
> /usr/include/gnuradio/gr_hier_block2.h:43:7: note:   candidate expects 1
> argument, 0 provided
> /home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In  
> constructor
> ?osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)?:
> /home/llazzaro/tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:83:35: note:
> synthesized method ?osmosdr_source_c::osmosdr_source_c()? first required
> here
> make[2]: ***
> [lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1
> make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
> make: *** [all] Error 2



From lazzaroleonardo at gmail.com  Mon Nov 12 20:31:59 2012
From: lazzaroleonardo at gmail.com (Leonardo Lazzaro)
Date: Mon, 12 Nov 2012 17:31:59 -0300
Subject: Compilation issue
In-Reply-To: <op.wnofwu0avay7ep@wopr.artelis.net>
References: <CADgJ7oN9Gxhi2VxwjbortyYz0Ly=23HWX+GoKrRHH7kkmxxvSA@mail.gmail.com>
	<op.wnofwu0avay7ep@wopr.artelis.net>
Message-ID: <CADgJ7oO7KGh+gX=ELb2sGYzSkPNM4XWDhj3aqrzz2+qR55sgzA@mail.gmail.com>

yes sure!
gnurario is 3.6.2

gr version is the master from git repo. (Building for version: cf807398 /
0.0.1git)

compiler : gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1


I followed this guide : http://sdr.osmocom.org/trac/wiki/rtl-sdr

Thanks!

On Mon, Nov 12, 2012 at 5:15 PM, Dimitri Stolnikov <horiz0n at gmx.net> wrote:

> Hi Leonardo,
>
> you should have provided a little more information than this, like what is
> your gr version (there are *many* of them out there) and which compiler are
> you using?
>
>
> Best regards,
>
> Dimitri
>
>
>
> On Mon, 12 Nov 2012 20:28:42 +0100, Leonardo Lazzaro <
> lazzaroleonardo at gmail.com> wrote:
>
>  Hi!
>>
>> I was trying to compile the osmocom sdr project and also trying to report
>> a
>> compilation error.
>> I will like to have an account to contribute.
>>
>> this was the error I got:
>>
>> In file included from
>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.h:**23:0,
>>                  from
>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.cc:**30:
>> /home/llazzaro/tmp/gr-osmosdr/**include/osmosdr/osmosdr_**source_c.h: In
>> constructor ?osmosdr_source_c::osmosdr_**source_c()?:
>> /home/llazzaro/tmp/gr-osmosdr/**include/osmosdr/osmosdr_**
>> source_c.h:57:19:
>> error: no matching function for call to ?gr_hier_block2::gr_hier_**
>> block2()?
>> /home/llazzaro/tmp/gr-osmosdr/**include/osmosdr/osmosdr_**
>> source_c.h:57:19:
>> note: candidates are:
>> /usr/include/gnuradio/gr_hier_**block2.h:57:3: note:
>> gr_hier_block2::gr_hier_**block2(const string&, gr_io_signature_sptr,
>> gr_io_signature_sptr)
>> /usr/include/gnuradio/gr_hier_**block2.h:57:3: note:   candidate expects
>> 3
>> arguments, 0 provided
>> /usr/include/gnuradio/gr_hier_**block2.h:43:7: note:
>> gr_hier_block2::gr_hier_**block2(const gr_hier_block2&)
>> /usr/include/gnuradio/gr_hier_**block2.h:43:7: note:   candidate expects
>> 1
>> argument, 0 provided
>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.cc: In
>> constructor
>> ?osmosdr_source_c_impl::**osmosdr_source_c_impl(const string&)?:
>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.cc:**83:35:
>> note:
>> synthesized method ?osmosdr_source_c::osmosdr_**source_c()? first
>> required
>> here
>> make[2]: ***
>> [lib/CMakeFiles/gnuradio-**osmosdr.dir/osmosdr_source_c_**impl.cc.o]
>> Error 1
>> make[1]: *** [lib/CMakeFiles/gnuradio-**osmosdr.dir/all] Error 2
>> make: *** [all] Error 2
>>
>


-- 
http://www.lazzaroleonardo.com.ar/
twitter @llazzaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121112/163d4a85/attachment.htm>

From horiz0n at gmx.net  Mon Nov 12 21:26:41 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Mon, 12 Nov 2012 22:26:41 +0100
Subject: Compilation issue
In-Reply-To: <CADgJ7oO7KGh+gX=ELb2sGYzSkPNM4XWDhj3aqrzz2+qR55sgzA@mail.gmail.com>
References: <CADgJ7oN9Gxhi2VxwjbortyYz0Ly=23HWX+GoKrRHH7kkmxxvSA@mail.gmail.com>
	<op.wnofwu0avay7ep@wopr.artelis.net>
	<CADgJ7oO7KGh+gX=ELb2sGYzSkPNM4XWDhj3aqrzz2+qR55sgzA@mail.gmail.com>
Message-ID: <op.wnoi6rscvay7ep@wopr.artelis.net>

Now this is strange, using gr v3.6.2-112-gfa4f1c2f here myself. Others  
have confirmed it builds fine on recent Ubuntu as well (didn't try that  
myself).

Can you check if there are any leftovers from the package version of gr  
and then delete build directory & retry from scratch?

Best regards,

Dimitri

On Mon, 12 Nov 2012 21:31:59 +0100, Leonardo Lazzaro  
<lazzaroleonardo at gmail.com> wrote:

> yes sure!
> gnurario is 3.6.2
>
> gr version is the master from git repo. (Building for version: cf807398 /
> 0.0.1git)
>
> compiler : gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
>
>
> I followed this guide : http://sdr.osmocom.org/trac/wiki/rtl-sdr
>
> Thanks!
>
> On Mon, Nov 12, 2012 at 5:15 PM, Dimitri Stolnikov <horiz0n at gmx.net>  
> wrote:
>
>> Hi Leonardo,
>>
>> you should have provided a little more information than this, like what  
>> is
>> your gr version (there are *many* of them out there) and which compiler  
>> are
>> you using?
>>
>>
>> Best regards,
>>
>> Dimitri
>>
>>
>>
>> On Mon, 12 Nov 2012 20:28:42 +0100, Leonardo Lazzaro <
>> lazzaroleonardo at gmail.com> wrote:
>>
>>  Hi!
>>>
>>> I was trying to compile the osmocom sdr project and also trying to  
>>> report
>>> a
>>> compilation error.
>>> I will like to have an account to contribute.
>>>
>>> this was the error I got:
>>>
>>> In file included from
>>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.h:**23:0,
>>>                  from
>>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.cc:**30:
>>> /home/llazzaro/tmp/gr-osmosdr/**include/osmosdr/osmosdr_**source_c.h:  
>>> In
>>> constructor ?osmosdr_source_c::osmosdr_**source_c()?:
>>> /home/llazzaro/tmp/gr-osmosdr/**include/osmosdr/osmosdr_**
>>> source_c.h:57:19:
>>> error: no matching function for call to ?gr_hier_block2::gr_hier_**
>>> block2()?
>>> /home/llazzaro/tmp/gr-osmosdr/**include/osmosdr/osmosdr_**
>>> source_c.h:57:19:
>>> note: candidates are:
>>> /usr/include/gnuradio/gr_hier_**block2.h:57:3: note:
>>> gr_hier_block2::gr_hier_**block2(const string&, gr_io_signature_sptr,
>>> gr_io_signature_sptr)
>>> /usr/include/gnuradio/gr_hier_**block2.h:57:3: note:   candidate  
>>> expects
>>> 3
>>> arguments, 0 provided
>>> /usr/include/gnuradio/gr_hier_**block2.h:43:7: note:
>>> gr_hier_block2::gr_hier_**block2(const gr_hier_block2&)
>>> /usr/include/gnuradio/gr_hier_**block2.h:43:7: note:   candidate  
>>> expects
>>> 1
>>> argument, 0 provided
>>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.cc: In
>>> constructor
>>> ?osmosdr_source_c_impl::**osmosdr_source_c_impl(const string&)?:
>>> /home/llazzaro/tmp/gr-osmosdr/**lib/osmosdr_source_c_impl.cc:**83:35:
>>> note:
>>> synthesized method ?osmosdr_source_c::osmosdr_**source_c()? first
>>> required
>>> here
>>> make[2]: ***
>>> [lib/CMakeFiles/gnuradio-**osmosdr.dir/osmosdr_source_c_**impl.cc.o]
>>> Error 1
>>> make[1]: *** [lib/CMakeFiles/gnuradio-**osmosdr.dir/all] Error 2
>>> make: *** [all] Error 2
>>>
>>
>



From lazzaroleonardo at gmail.com  Tue Nov 13 13:59:23 2012
From: lazzaroleonardo at gmail.com (Leonardo Lazzaro)
Date: Tue, 13 Nov 2012 10:59:23 -0300
Subject: Compilation issue
In-Reply-To: <op.wnoi6rscvay7ep@wopr.artelis.net>
References: <CADgJ7oN9Gxhi2VxwjbortyYz0Ly=23HWX+GoKrRHH7kkmxxvSA@mail.gmail.com>
	<op.wnofwu0avay7ep@wopr.artelis.net>
	<CADgJ7oO7KGh+gX=ELb2sGYzSkPNM4XWDhj3aqrzz2+qR55sgzA@mail.gmail.com>
	<op.wnoi6rscvay7ep@wopr.artelis.net>
Message-ID: <CADgJ7oNAZPTe2XMrJMsediXnBxHSqVuZdbRKFo9wjUTek3L5Rw@mail.gmail.com>

Ok I tried to clone the gnuradio repo and it worked!!

It was failing with the gnuradio 3.6.2 that I downloaded from
http://gnuradio.org/releases/gnuradio/

Thanks!!

On Mon, Nov 12, 2012 at 6:26 PM, Dimitri Stolnikov <horiz0n at gmx.net> wrote:

> Now this is strange, using gr v3.6.2-112-gfa4f1c2f here myself. Others
> have confirmed it builds fine on recent Ubuntu as well (didn't try that
> myself).
>
> Can you check if there are any leftovers from the package version of gr
> and then delete build directory & retry from scratch?
>
> Best regards,
>
> Dimitri
>
>
> On Mon, 12 Nov 2012 21:31:59 +0100, Leonardo Lazzaro <
> lazzaroleonardo at gmail.com> wrote:
>
>  yes sure!
>> gnurario is 3.6.2
>>
>> gr version is the master from git repo. (Building for version: cf807398 /
>> 0.0.1git)
>>
>> compiler : gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
>>
>>
>> I followed this guide : http://sdr.osmocom.org/trac/**wiki/rtl-sdr<http://sdr.osmocom.org/trac/wiki/rtl-sdr>
>>
>> Thanks!
>>
>> On Mon, Nov 12, 2012 at 5:15 PM, Dimitri Stolnikov <horiz0n at gmx.net>
>> wrote:
>>
>>  Hi Leonardo,
>>>
>>> you should have provided a little more information than this, like what
>>> is
>>> your gr version (there are *many* of them out there) and which compiler
>>> are
>>> you using?
>>>
>>>
>>> Best regards,
>>>
>>> Dimitri
>>>
>>>
>>>
>>> On Mon, 12 Nov 2012 20:28:42 +0100, Leonardo Lazzaro <
>>> lazzaroleonardo at gmail.com> wrote:
>>>
>>>  Hi!
>>>
>>>>
>>>> I was trying to compile the osmocom sdr project and also trying to
>>>> report
>>>> a
>>>> compilation error.
>>>> I will like to have an account to contribute.
>>>>
>>>> this was the error I got:
>>>>
>>>> In file included from
>>>> /home/llazzaro/tmp/gr-osmosdr/****lib/osmosdr_source_c_impl.h:****23:0,
>>>>                  from
>>>> /home/llazzaro/tmp/gr-osmosdr/****lib/osmosdr_source_c_impl.**cc:**30:
>>>> /home/llazzaro/tmp/gr-osmosdr/****include/osmosdr/osmosdr_****source_c.h:
>>>> In
>>>> constructor ?osmosdr_source_c::osmosdr_****source_c()?:
>>>> /home/llazzaro/tmp/gr-osmosdr/****include/osmosdr/osmosdr_**
>>>> source_c.h:57:19:
>>>> error: no matching function for call to ?gr_hier_block2::gr_hier_**
>>>> block2()?
>>>> /home/llazzaro/tmp/gr-osmosdr/****include/osmosdr/osmosdr_**
>>>>
>>>> source_c.h:57:19:
>>>> note: candidates are:
>>>> /usr/include/gnuradio/gr_hier_****block2.h:57:3: note:
>>>> gr_hier_block2::gr_hier_****block2(const string&, gr_io_signature_sptr,
>>>> gr_io_signature_sptr)
>>>> /usr/include/gnuradio/gr_hier_****block2.h:57:3: note:   candidate
>>>> expects
>>>> 3
>>>> arguments, 0 provided
>>>> /usr/include/gnuradio/gr_hier_****block2.h:43:7: note:
>>>> gr_hier_block2::gr_hier_****block2(const gr_hier_block2&)
>>>> /usr/include/gnuradio/gr_hier_****block2.h:43:7: note:   candidate
>>>> expects
>>>> 1
>>>> argument, 0 provided
>>>> /home/llazzaro/tmp/gr-osmosdr/****lib/osmosdr_source_c_impl.**cc: In
>>>> constructor
>>>> ?osmosdr_source_c_impl::****osmosdr_source_c_impl(const string&)?:
>>>> /home/llazzaro/tmp/gr-osmosdr/****lib/osmosdr_source_c_impl.**
>>>> cc:**83:35:
>>>> note:
>>>> synthesized method ?osmosdr_source_c::osmosdr_****source_c()? first
>>>>
>>>> required
>>>> here
>>>> make[2]: ***
>>>> [lib/CMakeFiles/gnuradio-****osmosdr.dir/osmosdr_source_c_***
>>>> *impl.cc.o]
>>>> Error 1
>>>> make[1]: *** [lib/CMakeFiles/gnuradio-****osmosdr.dir/all] Error 2
>>>>
>>>> make: *** [all] Error 2
>>>>
>>>>
>>>
>>


-- 
http://www.lazzaroleonardo.com.ar/
twitter @llazzaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121113/fefeadec/attachment.htm>

From coolchevy at gmail.com  Wed Nov 14 18:01:02 2012
From: coolchevy at gmail.com (Vitaliy Kulchevych)
Date: Wed, 14 Nov 2012 20:01:02 +0200
Subject: rtl_fm problem with capture audio
Message-ID: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>

HI!

I want grab audio from my sdr-device and convert it to h264.

I use rtl_fm, check any options, but I can't listen any good sound :(

For example: rtl_fm -f 10000000 -s 44100  - | mplayer - -quiet
-rawaudio rate=8000:bitrate=44100 -demuxer rawaudio

Can you help me?
May be anybody know any software for me?

Thank you!


--
live free or die;



From keenerd at gmail.com  Wed Nov 14 19:19:44 2012
From: keenerd at gmail.com (keenerd)
Date: Wed, 14 Nov 2012 14:19:44 -0500
Subject: rtl_fm problem with capture audio
Message-ID: <CAAKTTKOcviQf6zPF7v0Ws8+snzCJo9FeS-pSRZGedpxZ8CL4Eg@mail.gmail.com>

> Vitaliy Kulchevych coolchevy at gmail.com
> Wed Nov 14 19:01:02 CET 2012
>
> I want grab audio from my sdr-device and convert it to h264.
>
> I use rtl_fm, check any options, but I can't listen any good sound :(
>
> For example: rtl_fm -f 10000000 -s 44100  - | mplayer - -quiet
> -rawaudio rate=8000:bitrate=44100 -demuxer rawaudio

My apologies for breaking threading on this message - just signed up
to the ML today.

I can't help you without a lot more information. Is this a narrow band
or a wide band FM signal?  Do you want to save the audio to a file or
a network stream?  What operating system are you using?  Why are you
trying to compress an audio stream with a video codec?

-Kyle
http://kmkeen.com



From coolchevy at gmail.com  Wed Nov 14 20:02:53 2012
From: coolchevy at gmail.com (Vitaliy Kulchevych)
Date: Wed, 14 Nov 2012 22:02:53 +0200
Subject: rtl_fm problem with capture audio
In-Reply-To: <CAAKTTKOcviQf6zPF7v0Ws8+snzCJo9FeS-pSRZGedpxZ8CL4Eg@mail.gmail.com>
References: <CAAKTTKOcviQf6zPF7v0Ws8+snzCJo9FeS-pSRZGedpxZ8CL4Eg@mail.gmail.com>
Message-ID: <CAH-F8DFfoxshUp0e1HFGsB6i2Pc28L2mgBO73Dq19JCHd85qMQ@mail.gmail.com>

Hi, Kyle!

Thank you for reply.
I tested and developed on my Mac (Darwin), but I want put this
solution on my dedicated server Debian Linux.
I need broadcast UHF 430?440 MHz (ham ? 70 cm band) to internet. Only
audio stream.

Something like this:
DVB-T tuner -> Linux -> sdr grabber -> mencoder | ffmpeg | vlc | etc..
-> icecast (mp3, acc, ogg, etc.)

May be you know any another way to resolve my goal?

And another my idea create something like using websdr.org software,
but main developer does not give the source code to anyone.


On Wed, Nov 14, 2012 at 9:19 PM, keenerd <keenerd at gmail.com> wrote:
>> Vitaliy Kulchevych coolchevy at gmail.com
>> Wed Nov 14 19:01:02 CET 2012
>>
>> I want grab audio from my sdr-device and convert it to h264.
>>
>> I use rtl_fm, check any options, but I can't listen any good sound :(
>>
>> For example: rtl_fm -f 10000000 -s 44100  - | mplayer - -quiet
>> -rawaudio rate=8000:bitrate=44100 -demuxer rawaudio
>
> My apologies for breaking threading on this message - just signed up
> to the ML today.
>
> I can't help you without a lot more information. Is this a narrow band
> or a wide band FM signal?  Do you want to save the audio to a file or
> a network stream?  What operating system are you using?  Why are you
> trying to compress an audio stream with a video codec?
>
> -Kyle
> http://kmkeen.com
>



-- 
live free or die;



From a.nielsen at shikadi.net  Wed Nov 14 21:39:46 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Thu, 15 Nov 2012 07:39:46 +1000
Subject: rtl_fm problem with capture audio
In-Reply-To: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
Message-ID: <50A40FA2.1000501@shikadi.net>

> I use rtl_fm, check any options, but I can't listen any good sound :(
>
> For example: rtl_fm -f 10000000 -s 44100  - | mplayer - -quiet
> -rawaudio rate=8000:bitrate=44100 -demuxer rawaudio

-s means you are setting the RF bandwidth to 44.1kHz.  Maybe you meant -r to 
set the output sampling rate to 44.1k?

Either way your -rawaudio option is setting the input sampling rate to 8kHz, 
so the audio is going to sound like it has been slowed down.

You may want to add the "-l 0" option to rtl_fm to disable squelch while 
you're testing, just to see whether you are getting any audio at all.  If the 
signal isn't that strong the default squelch value will cause you to only hear 
silence.

Cheers,
Adam.




From coolchevy at gmail.com  Wed Nov 14 23:37:16 2012
From: coolchevy at gmail.com (Vitaliy Kulchevych)
Date: Thu, 15 Nov 2012 01:37:16 +0200
Subject: rtl_fm problem with capture audio
In-Reply-To: <50A40FA2.1000501@shikadi.net>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
Message-ID: <CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>

Thanks, realy -l 0 help me. Problem with correct frequency.
Why it is not correct?
When I set -f434500000 -> Tuned to 434753575 Hz
                 -f100000000 -> Tuned to 100253575 Hz

Can you explain this?
How I can calculate right frequency?

On Wed, Nov 14, 2012 at 11:39 PM, Adam Nielsen <a.nielsen at shikadi.net> wrote:
>> I use rtl_fm, check any options, but I can't listen any good sound :(
>>
>> For example: rtl_fm -f 10000000 -s 44100  - | mplayer - -quiet
>> -rawaudio rate=8000:bitrate=44100 -demuxer rawaudio
>
>
> -s means you are setting the RF bandwidth to 44.1kHz.  Maybe you meant -r to
> set the output sampling rate to 44.1k?
>
> Either way your -rawaudio option is setting the input sampling rate to 8kHz,
> so the audio is going to sound like it has been slowed down.
>
> You may want to add the "-l 0" option to rtl_fm to disable squelch while
> you're testing, just to see whether you are getting any audio at all.  If
> the signal isn't that strong the default squelch value will cause you to
> only hear silence.
>
> Cheers,
> Adam.
>



-- 
live free or die;



From a.nielsen at shikadi.net  Wed Nov 14 23:57:50 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Thu, 15 Nov 2012 09:57:50 +1000
Subject: rtl_fm problem with capture audio
In-Reply-To: <CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
Message-ID: <50A42FFE.3080701@shikadi.net>

> Thanks, realy -l 0 help me. Problem with correct frequency.
> Why it is not correct?
> When I set -f434500000 -> Tuned to 434753575 Hz
>                   -f100000000 -> Tuned to 100253575 Hz
>
> Can you explain this?
> How I can calculate right frequency?

I think it's because it tunes to an offset, to avoid the centre spike. 
The frequency you use on the command line is what is actually decoded.

I thought this is what the -E option was for, but WBFM reception sounds 
really bad when I use -E.

Cheers,
Adam.



From keenerd at gmail.com  Thu Nov 15 00:25:01 2012
From: keenerd at gmail.com (keenerd)
Date: Wed, 14 Nov 2012 19:25:01 -0500
Subject: rtl_fm problem with capture audio
In-Reply-To: <50A42FFE.3080701@shikadi.net>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
	<50A42FFE.3080701@shikadi.net>
Message-ID: <CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>

On 11/14/12, Adam Nielsen <a.nielsen at shikadi.net> wrote:
> I think it's because it tunes to an offset, to avoid the centre spike.
> The frequency you use on the command line is what is actually decoded.
>
> I thought this is what the -E option was for, but WBFM reception sounds
> really bad when I use -E.

Correct on the offset.  -E is something else entirely though.  When
you are working with waterfalls, it is very easy to see the
center/carrier and estimate the bandwidth.  But usually radio
transmitters report their frequency as the lower edge of the spectrum.
 -E is for tuning this way.

So, lets say I have a NBFM transmitter tuned to 80MHz with 12kHz
bandwidth.  If you look at it on the waterfall, you will see the
carrier centered on 80.06MHz.  You could tune to it with either

-f 80e6 -s 12e3 -E
-f 80.06e6 -s 12e3

Both of those do the same thing.  -E can save some typing but center
tuning is easier if you don't know the bandwidth in advance.

With WBFM this all falls apart, because they use 200kHz of bandwidth
(stereo and digital modes) but are offset 16kHz from their official
frequency.  (Because at one point wbfm was mono with 32kHz of
bandwidth.) Use -W for wbfm, it takes all that into account.

-Kyle
http://kmkeen.com



From a.nielsen at shikadi.net  Thu Nov 15 05:13:02 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Thu, 15 Nov 2012 15:13:02 +1000
Subject: rtl_fm problem with capture audio
In-Reply-To: <CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
	<50A42FFE.3080701@shikadi.net>
	<CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>
Message-ID: <50A479DE.40300@shikadi.net>

> Correct on the offset.  -E is something else entirely though.

Very interesting!  Thanks for the explanation.

I had been wondering whether it was related to the new librtlsdr code 
which appears to use a non-zero IF with the E4000 to avoid the centre 
spike, so it's good to know what it's really for.

Cheers,
Adam.



From kd9gn at lolling.org  Thu Nov 15 06:01:21 2012
From: kd9gn at lolling.org (KD9GN)
Date: Thu, 15 Nov 2012 06:01:21 +0000
Subject: rtl_fm problem with capture audio
In-Reply-To: <50A479DE.40300@shikadi.net>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
	<50A42FFE.3080701@shikadi.net>
	<CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>
	<50A479DE.40300@shikadi.net>
Message-ID: <50A48531.4070304@lolling.org>

On 11/15/2012 05:13 AM, Adam Nielsen wrote:
>> Correct on the offset.  -E is something else entirely though.
>
> Very interesting!  Thanks for the explanation.
>
> I had been wondering whether it was related to the new librtlsdr code 
> which appears to use a non-zero IF with the E4000 to avoid the centre 
> spike, so it's good to know what it's really for.
>
> Cheers,
> Adam.
>

I am not sure if this helps anyone at all but I was playing around with 
the command line options available with rtl_fm while trying to listen to 
my favorite local FM Broadcast radio station and had pretty good audio 
results with this ....

rtl_fm -f 88.9e6 -N -s 170e3 -o 4 -A -r 32e3 -l 0 - | play -t raw -r 32k 
-e signed-integer -b 16 -c 1 -V1 -

as you probably already know, when you run rtl_fm without any options 
you get a list of all of the command line switches as well as some 
example commands.

I couldn't tell much difference between using the -A option or not using it.

By the way, I am using an eZcap 668 (E4000/rtl2832u)

Hope this helps.
73 - Dave
KD9GN




From rsenykoff at gmail.com  Thu Nov 15 20:11:06 2012
From: rsenykoff at gmail.com (Ron Senykoff)
Date: Thu, 15 Nov 2012 15:11:06 -0500
Subject: R820T and Gnuradio
Message-ID: <CAAiVu1aZXa_bQun=D4dbzxbD93TsCtaLPYM_goC-NMbk0jZu6g@mail.gmail.com>

I have gnuradio running with the R820D DVB. Latest GQRX has the nice rf
gain inside which REALLY helps. Has this been merged over to gr-osmosdr ? I
recompiled probably just a few days, both from source.

I'm trying to figure out how to set gain from within gnuradio (is there a
argument I can pass the device in the source block?).

I've been successfully decoding AFSK1200 APRS using gqrx and am trying to
figure out how to set up an ultracheap iGate for APRS, maybe with gnuradio
in the mix.

Also using the OSMOSDR block I still see an LO like spike right in the
middle.

Here's my output starting GQRX. Interesting it's saying gr-osmosdr
supported device types...

ron at tripel:~$ startGqrx.sh
ron at tripel:~$ gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd
>>> gr_fir_ccf: using 3DNow!
>>> gr_fir_ccc: using 3DNow!Ext
>>> gr_fir_fff: using 3DNow!
gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd
Using device #0: Generic RTL2832U (e.g. hama nano)
Found Rafael Micro R820T tuner

TIA!
-Ron / KB1UMH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121115/703d7395/attachment.htm>

From steve at steve-m.de  Thu Nov 15 20:47:16 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 15 Nov 2012 21:47:16 +0100
Subject: R820T and Gnuradio
In-Reply-To: <CAAiVu1aZXa_bQun=D4dbzxbD93TsCtaLPYM_goC-NMbk0jZu6g@mail.gmail.com>
References: <CAAiVu1aZXa_bQun=D4dbzxbD93TsCtaLPYM_goC-NMbk0jZu6g@mail.gmail.com>
Message-ID: <50A554D4.30103@steve-m.de>

Hi,

On 15.11.2012 21:11, Ron Senykoff wrote:
> I have gnuradio running with the R820D DVB. Latest GQRX has the nice rf
> gain inside which REALLY helps. Has this been merged over to gr-osmosdr
> ? I recompiled probably just a few days, both from source.

gqrx uses gr-osmosdr as source block, so it's identical.

> I'm trying to figure out how to set gain from within gnuradio (is there
> a argument I can pass the device in the source block?).

Yes, the 'Gain' argument.

> Also using the OSMOSDR block I still see an LO like spike right in the
> middle.

gqrx uses an internal DC offset correction algorithm, which you'd need
to implement in your flowgraph as well if you want to remove the
spike.

Regards,
Steve



From olof.tangrot at gmail.com  Sat Nov 17 14:18:18 2012
From: olof.tangrot at gmail.com (Olof Tangrot)
Date: Sat, 17 Nov 2012 15:18:18 +0100
Subject: rtl-fm yet another audio cature problem
Message-ID: <CAG0+6kkukDfemvyi+Nd6b5VfYDGFpR7gOrkEbGaknJbDA_-JTg@mail.gmail.com>

Hi.
I have tried (in a bash shell):
rtl_fm -f 96.3e6 -s 48000 - | aplay -r raw -f dat -c 1

That was proposed somewhere as an example to listen to an FM station. But
everything terminates with:
aplay: main:576: bad speed value 0
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 21x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 96552000 Hz.
Sampling at 1008000 Hz.
Output at 48000 Hz.
Exact sample rate is: 1008000.009613 Hz
Tuner gain set to automatic.
Signal caught, exiting!

User cancel, exiting...

I run Fedora 16 on a 64-bit AMD machine. aplay version is 1.0.26

If I break the command apart and generates a intermediate file it works but
using a pipe does not.

So is there some other shell that I where this might work or is there some
better why to do this?

Regards

Olof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121117/fa37fe50/attachment.htm>

From a.nielsen at shikadi.net  Sat Nov 17 14:58:46 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Sun, 18 Nov 2012 00:58:46 +1000
Subject: rtl-fm yet another audio cature problem
In-Reply-To: <CAG0+6kkukDfemvyi+Nd6b5VfYDGFpR7gOrkEbGaknJbDA_-JTg@mail.gmail.com>
References: <CAG0+6kkukDfemvyi+Nd6b5VfYDGFpR7gOrkEbGaknJbDA_-JTg@mail.gmail.com>
Message-ID: <50A7A626.3090509@shikadi.net>

> I have tried (in a bash shell):
> rtl_fm -f 96.3e6 -s 48000 - | aplay -r raw -f dat -c 1

For rtl_fm, -s sets the station bandwidth, you probably want -r to set the 
output sample rate instead.  You probably also want -W for wideband FM mode.

For aplay, -r sets the input sample rate, and "raw" isn't a valid sample rate. 
  You probably mean -t instead.  This works for me:

   rtl_fm -f 105.3e6 -W -r 48000 - | aplay -t raw -f dat -c 1

Cheers,
Adam.




From zaitcev at kotori.zaitcev.us  Sat Nov 17 14:59:42 2012
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Sat, 17 Nov 2012 07:59:42 -0700
Subject: rtl-fm yet another audio cature problem
In-Reply-To: <CAG0+6kkukDfemvyi+Nd6b5VfYDGFpR7gOrkEbGaknJbDA_-JTg@mail.gmail.com>
References: <CAG0+6kkukDfemvyi+Nd6b5VfYDGFpR7gOrkEbGaknJbDA_-JTg@mail.gmail.com>
Message-ID: <20121117075942.4dc6b0ff@lembas.zaitcev.lan>

On Sat, 17 Nov 2012 15:18:18 +0100
Olof Tangrot <olof.tangrot at gmail.com> wrote:

> rtl_fm -f 96.3e6 -s 48000 - | aplay -r raw -f dat -c 1

> aplay: main:576: bad speed value 0

Set the speed and format with   aplay -r 48k -f S16_LE -t raw
as the help message of rtl_fm suggests. That works (on Fedora too).
Apparently -f dat shorthand is not enough for pipes.

-- Pete



From peter at stuge.se  Sat Nov 17 14:59:44 2012
From: peter at stuge.se (Peter Stuge)
Date: Sat, 17 Nov 2012 15:59:44 +0100
Subject: rtl-fm yet another audio cature problem
In-Reply-To: <CAG0+6kkukDfemvyi+Nd6b5VfYDGFpR7gOrkEbGaknJbDA_-JTg@mail.gmail.com>
References: <CAG0+6kkukDfemvyi+Nd6b5VfYDGFpR7gOrkEbGaknJbDA_-JTg@mail.gmail.com>
Message-ID: <20121117145944.7830.qmail@stuge.se>

Olof Tangrot wrote:
> aplay: main:576: bad speed value 0

The error message indicates that aplay does not function.


> If I break the command apart and generates a intermediate file it
> works but using a pipe does not.

And your testing confirms beyond doubt that your problem is
completely with playback, and not with capture.


> So is there some other shell that I where this might work or is
> there some better why to do this?

Just provide aplay the information that it wants. Or patch it to
discover the information automatically, though that may be difficult.


//Peter



From rsenykoff at gmail.com  Sat Nov 17 17:23:43 2012
From: rsenykoff at gmail.com (Ron Senykoff)
Date: Sat, 17 Nov 2012 12:23:43 -0500
Subject: R820T and Gnuradio
In-Reply-To: <50A554D4.30103@steve-m.de>
References: <CAAiVu1aZXa_bQun=D4dbzxbD93TsCtaLPYM_goC-NMbk0jZu6g@mail.gmail.com>
	<50A554D4.30103@steve-m.de>
Message-ID: <CAAiVu1YUhAhP9vdeC4C1DGMWM5zFmFqjNgh+3zX2yQ7ZJXsAkw@mail.gmail.com>

Sorry I had been looking online for a list of all the arguments, then
smacked my forehead after hitting rtl_fm --help.... not sure if the same
-args apply via gnuradio but I'll see what I can do. I think something I
did has helped as the AGC pumping effect isn't happening to me any more.

Thanks,
-Ron


On Thu, Nov 15, 2012 at 3:47 PM, Steve Markgraf <steve at steve-m.de> wrote:

> Hi,
>
> On 15.11.2012 21:11, Ron Senykoff wrote:
> > I have gnuradio running with the R820D DVB. Latest GQRX has the nice rf
> > gain inside which REALLY helps. Has this been merged over to gr-osmosdr
> > ? I recompiled probably just a few days, both from source.
>
> gqrx uses gr-osmosdr as source block, so it's identical.
>
> > I'm trying to figure out how to set gain from within gnuradio (is there
> > a argument I can pass the device in the source block?).
>
> Yes, the 'Gain' argument.
>
> > Also using the OSMOSDR block I still see an LO like spike right in the
> > middle.
>
> gqrx uses an internal DC offset correction algorithm, which you'd need
> to implement in your flowgraph as well if you want to remove the
> spike.
>
> Regards,
> Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121117/4541eaf2/attachment.htm>

From james at peroulas.com  Sun Nov 18 04:40:55 2012
From: james at peroulas.com (James Peroulas)
Date: Sat, 17 Nov 2012 22:40:55 -0600
Subject: LTE-Tracker
Message-ID: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>

Hi! I just released a major update to the LTE code. There's a new program
called LTE-Tracker that camps on a certain frequency and tracks, any LTE
cells that it finds.

Interesting features (all are in realtime):

   - You can see cells popping in and dropping off as the receiver is moved
   around the coverage area of the different cells.
   - You can see the actual transfer function of the wireless channel
   plotted on the screen.

I've also made a small change to CellSearch so that now, it also displays
the number of antennas (ports) on the basestation.

Please let me know of any comments or suggestions!

http://www.evrytania.com/lte-tools/lte-tracker

James

-- 
*Integrity is a binary state - either you have it or you don?t.* - John
Doerr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121117/18c37220/attachment.htm>

From horiz0n at gmx.net  Sun Nov 18 09:05:29 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 18 Nov 2012 10:05:29 +0100
Subject: LTE-Tracker
In-Reply-To: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>
References: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>
Message-ID: <op.wnyovfsrvay7ep@wopr.artelis.net>

Hi James,

On Sun, 18 Nov 2012 05:40:55 +0100, James Peroulas <james at peroulas.com>  
wrote:

> Hi! I just released a major update to the LTE code. There's a new program
> called LTE-Tracker that camps on a certain frequency and tracks, any LTE
> cells that it finds.
>
> Interesting features (all are in realtime):
>
>    - You can see cells popping in and dropping off as the receiver is  
> moved
>    around the coverage area of the different cells.
>    - You can see the actual transfer function of the wireless channel
>    plotted on the screen.
>
> I've also made a small change to CellSearch so that now, it also displays
> the number of antennas (ports) on the basestation.

Cool!

>
> Please let me know of any comments or suggestions!

I had to apply the attached patch for it to compile on my machine.

Unfortunately i wasn't able to test the tools, as both of them segfaulted  
in xc_peak_freq? Backtrace fragment attached.

LTE Tracker v1.0.0 (release) beginning
   Search frequency: 1815 MHz
   PPM: 120
   correction: 1
Found Elonics E4000 tuner
Calibrating local oscillator.
Segmentation fault

LTE CellSearch v1.0.0 (release) beginning
   Search frequency: 1815 MHz
   PPM: 120
   correction: 1
Found Elonics E4000 tuner
Examining center frequency 1815 MHz ...
Segmentation fault

The old copy of commit ef8474ed5d9213c494e8e17b8436208a04844b1a works just  
fine at the same time:

C: CP type ; P: PHICH duration ; PR: PHICH resource type
CID      fc   foff RXPWR C nRB P  PR CrystalCorrectionFactor
262   1815M   595h -24.6 N 100 N one 1.0000447970890209426
263   1815M   595h -25.3 N 100 N one 1.0000447969528891701

Also, i noticed that you calculate the expected tuning frequency for e4k  
tuners in order to make your calculations more exact. Can you tell us  
which tuning errors you get from the e4k driver usually and how this  
affects your application?

>
> http://www.evrytania.com/lte-tools/lte-tracker

Nice documentation & videos! Linked the page on the rtl-sdr wiki.



Best regards,

Dimitri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lte-tools.patch
Type: text/x-diff
Size: 792 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121118/dbc8aa35/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cellscan-segfault.txt
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121118/dbc8aa35/attachment.txt>

From james at peroulas.com  Sun Nov 18 16:09:37 2012
From: james at peroulas.com (James Peroulas)
Date: Sun, 18 Nov 2012 10:09:37 -0600
Subject: LTE-Tracker
In-Reply-To: <op.wnyovfsrvay7ep@wopr.artelis.net>
References: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>
	<op.wnyovfsrvay7ep@wopr.artelis.net>
Message-ID: <CA+XcqA5RVFE5L0jLP8nmNyQ7-4J8C7AXyNQYBDJV0RmACFzphw@mail.gmail.com>

On Sun, Nov 18, 2012 at 3:05 AM, Dimitri Stolnikov <horiz0n at gmx.net> wrote:

> I had to apply the attached patch for it to compile on my machine.
>

Thanks for the patch! cmake is something very new to me :)


> Unfortunately i wasn't able to test the tools, as both of them segfaulted
> in xc_peak_freq? Backtrace fragment attached.
>

Fixed (and pushed)! That was an easy bug to find and was related to the
fact that LTE cells in your area were at such a high frequency (1.8GHz).
The one's I've worked on were in the 700MHz band.


> Also, i noticed that you calculate the expected tuning frequency for e4k
> tuners in order to make your calculations more exact. Can you tell us which
> tuning errors you get from the e4k driver usually and how this affects your
> application?
>

Well, it's like this. Since the LO and sampling clock are derived from the
same reference, if I can figure out the frequency error of the LO, I will
know the frequency error of the ADC and I can use the frequency error of
the ADC to predict where I should be sampling the data. That way, in
LTE-Tracker, when the dongle's chrystal output stabilizes, the time offset
of the tracked basestations should not change (as long as the dongle itself
is not moving). I needed to calculate the actual LO and sampling
frequencies used by the dongle in order to remove the small time offset
drift I was observing.

As a new feature request, it would be nice for the library to return the
actual frequency that was programmed into the dongle in floating point
(fractions of a Hz sometimes matter). So, if I request 739,000,000Hz, the
library would be able to tell me that the actual programmed frequency was
739000025.5123... Hz. Similarly for the sampling rate.


>  http://www.evrytania.com/lte-**tools/lte-tracker<http://www.evrytania.com/lte-tools/lte-tracker>
>>
>
> Nice documentation & videos! Linked the page on the rtl-sdr wiki.
>

Thanks for the comments and the link!

James

-- 
*Integrity is a binary state - either you have it or you don?t.* - John
Doerr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121118/aea27897/attachment.htm>

From alexander.chemeris at gmail.com  Mon Nov 19 09:22:23 2012
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 19 Nov 2012 13:22:23 +0400
Subject: LTE-Tracker
In-Reply-To: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>
References: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>
Message-ID: <CABmJbFUKrPq=f977Hq3GGwM8ZrT6PVQ_-fWx8gcW1+VYKHv16w@mail.gmail.com>

Hi James,

Looks like a great software!

Do you plan to support UHD to support USRPs? In my area (Moscow) we
have LTE in 2500/2600 FDD band and I can't tune to that frequency with
rtl-sdr.

On Sun, Nov 18, 2012 at 8:40 AM, James Peroulas <james at peroulas.com> wrote:
> Hi! I just released a major update to the LTE code. There's a new program
> called LTE-Tracker that camps on a certain frequency and tracks, any LTE
> cells that it finds.
>
> Interesting features (all are in realtime):
>
> You can see cells popping in and dropping off as the receiver is moved
> around the coverage area of the different cells.
> You can see the actual transfer function of the wireless channel plotted on
> the screen.
>
> I've also made a small change to CellSearch so that now, it also displays
> the number of antennas (ports) on the basestation.
>
> Please let me know of any comments or suggestions!
>
> http://www.evrytania.com/lte-tools/lte-tracker
>
> James
>
> --
> Integrity is a binary state - either you have it or you don?t. - John Doerr
>



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From james at peroulas.com  Tue Nov 20 03:03:56 2012
From: james at peroulas.com (James Peroulas)
Date: Mon, 19 Nov 2012 21:03:56 -0600
Subject: LTE-Tracker
In-Reply-To: <CABmJbFUKrPq=f977Hq3GGwM8ZrT6PVQ_-fWx8gcW1+VYKHv16w@mail.gmail.com>
References: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>
	<CABmJbFUKrPq=f977Hq3GGwM8ZrT6PVQ_-fWx8gcW1+VYKHv16w@mail.gmail.com>
Message-ID: <CA+XcqA77ZOBmmTuzU=s7TuYfwTnPTngSvSHrCYCc0iAvvD7LUw@mail.gmail.com>

On Mon, Nov 19, 2012 at 3:22 AM, Alexander Chemeris <
alexander.chemeris at gmail.com> wrote:

> Do you plan to support UHD to support USRPs? In my area (Moscow) we
> have LTE in 2500/2600 FDD band and I can't tune to that frequency with
> rtl-sdr.
>

Well, it's 'planned', but I don't have any specific schedule for it... I
don't even have a USRP yet :)

James

-- 
*Integrity is a binary state - either you have it or you don?t.* - John
Doerr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121119/22728acb/attachment.htm>

From alexander.chemeris at gmail.com  Tue Nov 20 03:52:49 2012
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Tue, 20 Nov 2012 07:52:49 +0400
Subject: LTE-Tracker
In-Reply-To: <CA+XcqA77ZOBmmTuzU=s7TuYfwTnPTngSvSHrCYCc0iAvvD7LUw@mail.gmail.com>
References: <CA+XcqA7mLwukSBF15LnDT_2irRfpnLB7OTme4MZ2+SE-ooNmNA@mail.gmail.com>
	<CABmJbFUKrPq=f977Hq3GGwM8ZrT6PVQ_-fWx8gcW1+VYKHv16w@mail.gmail.com>
	<CA+XcqA77ZOBmmTuzU=s7TuYfwTnPTngSvSHrCYCc0iAvvD7LUw@mail.gmail.com>
Message-ID: <CABmJbFV7qz6+o3wgrezqnBgFAieS26-G0uFtNjj7zzDN92Efcg@mail.gmail.com>

On Tue, Nov 20, 2012 at 7:03 AM, James Peroulas <james at peroulas.com> wrote:
>
> On Mon, Nov 19, 2012 at 3:22 AM, Alexander Chemeris
> <alexander.chemeris at gmail.com> wrote:
>>
>> Do you plan to support UHD to support USRPs? In my area (Moscow) we
>> have LTE in 2500/2600 FDD band and I can't tune to that frequency with
>> rtl-sdr.
>
>
> Well, it's 'planned', but I don't have any specific schedule for it... I
> don't even have a USRP yet :)

Fair enough :)

--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From laforge at gnumonks.org  Tue Nov 20 07:26:51 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 20 Nov 2012 08:26:51 +0100
Subject: News from the OsmoSDR frontier
In-Reply-To: <50803047.5090203@maintech.de>
References: <507EE30E.6000102@maintech.de> <507F892C.7080304@gmx.de>
	<50803047.5090203@maintech.de>
Message-ID: <20121120072651.GL8595@prithivi.gnumonks.org>

Hi Christian,

On Thu, Oct 18, 2012 at 06:37:27PM +0200, Christian Daniel -- maintech GmbH wrote:
> right now I have exactly one prototype. But we have more PCBs and we
> will populate them to fix the boards in the wild. When I have them
> ready, I will post it here.

is there any update on those upgrade boards?  We have some people
interested in buying OsmoSDR boards from the sysmocom shop, but
obviously they would want to  buy it in a bundle with the upgrade board,
rather than buy/order them separetely.

Also, we have the existing users/owners who would appreciate an option
to upgrade.

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 coolchevy at gmail.com  Tue Nov 20 09:59:19 2012
From: coolchevy at gmail.com (Vitaliy Kulchevych)
Date: Tue, 20 Nov 2012 11:59:19 +0200
Subject: rtl_fm problem with capture audio
In-Reply-To: <50A48531.4070304@lolling.org>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
	<50A42FFE.3080701@shikadi.net>
	<CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>
	<50A479DE.40300@shikadi.net> <50A48531.4070304@lolling.org>
Message-ID: <CAH-F8DG5kYPprgaNTPd-70SqSXvSJmpOGX-P=kQsUOA9M1BNOQ@mail.gmail.com>

Hi, KD9GN

I'm tried your example

$ rtl_fm -f 100.0e6 -N -s 170e3 -o 4 -A -r 32e3 -l 0 - | play -t raw
-r 32k -e signed-integer -b 16 -c 1 -V1 -

-: (raw)

  Encoding: Signed PCM
  Channels: 1 @ 16-bit
Samplerate: 32000Hz
Replaygain: off
  Duration: unknown

In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]
Clip:0    Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 2x.
Oversampling output by: 4x.
Buffer size: 6.02ms
Tuned to 100340000 Hz.
Sampling at 1360000 Hz.
Output at 32000 Hz.
Exact sample rate is: 1360000.050439 Hz
Tuner gain set to automatic.
In:0.00% 00:00:01.02 [00:00:00.00] Out:49.1k [!=====|=====!] Hd:0.0 Clip:39


But I listen only QRM, there are not music)

What I'm do wrong?


Kyle, thank you for explanation -E option

73! UT4UAZ

On Thu, Nov 15, 2012 at 8:01 AM, KD9GN <kd9gn at lolling.org> wrote:
> On 11/15/2012 05:13 AM, Adam Nielsen wrote:
>>>
>>> Correct on the offset.  -E is something else entirely though.
>>
>>
>> Very interesting!  Thanks for the explanation.
>>
>> I had been wondering whether it was related to the new librtlsdr code
>> which appears to use a non-zero IF with the E4000 to avoid the centre spike,
>> so it's good to know what it's really for.
>>
>> Cheers,
>> Adam.
>>
>
> I am not sure if this helps anyone at all but I was playing around with the
> command line options available with rtl_fm while trying to listen to my
> favorite local FM Broadcast radio station and had pretty good audio results
> with this ....
>
> rtl_fm -f 88.9e6 -N -s 170e3 -o 4 -A -r 32e3 -l 0 - | play -t raw -r 32k -e
> signed-integer -b 16 -c 1 -V1 -
>
> as you probably already know, when you run rtl_fm without any options you
> get a list of all of the command line switches as well as some example
> commands.
>
> I couldn't tell much difference between using the -A option or not using it.
>
> By the way, I am using an eZcap 668 (E4000/rtl2832u)
>
> Hope this helps.
> 73 - Dave
> KD9GN
>
>



-- 
live free or die;



From zaitcev at kotori.zaitcev.us  Thu Nov 29 17:12:35 2012
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Thu, 29 Nov 2012 10:12:35 -0700
Subject: rtl_fm problem with capture audio
In-Reply-To: <CAH-F8DG5kYPprgaNTPd-70SqSXvSJmpOGX-P=kQsUOA9M1BNOQ@mail.gmail.com>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
	<50A42FFE.3080701@shikadi.net>
	<CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>
	<50A479DE.40300@shikadi.net> <50A48531.4070304@lolling.org>
	<CAH-F8DG5kYPprgaNTPd-70SqSXvSJmpOGX-P=kQsUOA9M1BNOQ@mail.gmail.com>
Message-ID: <20121129101235.06980aff@lembas.zaitcev.lan>

On Tue, 20 Nov 2012 11:59:19 +0200
Vitaliy Kulchevych <coolchevy at gmail.com> wrote:

> $ rtl_fm -f 100.0e6 -N -s 170e3 -o 4 -A -r 32e3 -l 0 - | play -t raw
> -r 32k -e signed-integer -b 16 -c 1 -V1 -

I found that Dave had the right idea about jacking up the sample rate.

But another thing is that rtl_fm just won't work until the signal is
strong enough. With my dongle I saw a decent FM out of the box on
the waterfall display, but rtl_fm just would not grab: outputted
noise and small fragments of corrupt sound that resembled the
transmissions.

Then, I replaced the stock antenna and its long cable with a basic
monopole designed for 1GHz -- way outside of FM radio band! But
immediately rtl_fm started working. Apparently the cable attenuation
was too bad.

Final command line was this:
rtl_fm -l 0 -f 99.5e6 -N -s 170e3 -o 4 -A -r 24e3 - | \
aplay -r 24k -f S16_LE -t raw -c 1

-- Pete



From keenerd at gmail.com  Thu Nov 29 18:28:05 2012
From: keenerd at gmail.com (keenerd)
Date: Thu, 29 Nov 2012 13:28:05 -0500
Subject: rtl_fm problem with capture audio
In-Reply-To: <20121129101235.06980aff@lembas.zaitcev.lan>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
	<50A42FFE.3080701@shikadi.net>
	<CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>
	<50A479DE.40300@shikadi.net> <50A48531.4070304@lolling.org>
	<CAH-F8DG5kYPprgaNTPd-70SqSXvSJmpOGX-P=kQsUOA9M1BNOQ@mail.gmail.com>
	<20121129101235.06980aff@lembas.zaitcev.lan>
Message-ID: <CAAKTTKP+8HTJAomw1X8dQje8iOc7u4udbAL+1qY7mx7qhrgUaA@mail.gmail.com>

On 11/29/12, Pete Zaitcev <zaitcev at kotori.zaitcev.us> wrote:
> But another thing is that rtl_fm just won't work until the signal is
> strong enough.

Maybe you should try increasing the gain.

> Final command line was this:
> rtl_fm -l 0 -f 99.5e6 -N -s 170e3 -o 4 -A -r 24e3 - | \
> aplay -r 24k -f S16_LE -t raw -c 1

Really, much smarter to use -W instead.  You are losing a moderate
amount of the signal.  First, wbfm is slightly off center pushing 10%
of the signal out of range.  Second, it carries audio information up
to 16kHz and resampling at 24ks/s discards another 25%.

rtl_fm -W -f 99.5e6 -g 49 | aplay -r 32k -f S16_LE -t raw -c 1

will work better.  No reason to spell it out the long way.

-Kyle



From rsenykoff at gmail.com  Fri Nov 30 15:04:17 2012
From: rsenykoff at gmail.com (Ron Senykoff)
Date: Fri, 30 Nov 2012 10:04:17 -0500
Subject: rtl_fm problem with capture audio
In-Reply-To: <CAAKTTKP+8HTJAomw1X8dQje8iOc7u4udbAL+1qY7mx7qhrgUaA@mail.gmail.com>
References: <CAH-F8DFwvhtE6+AQP7qh8Zcz2YCWXCYza_hzMkz=COQPpP=BEg@mail.gmail.com>
	<50A40FA2.1000501@shikadi.net>
	<CAH-F8DEaex9kFnEs7_W1Rziou8j0FP9Cv1DfeUOSwMq1RfZC5Q@mail.gmail.com>
	<50A42FFE.3080701@shikadi.net>
	<CAAKTTKP=xPS3g8o9JbDJu0pN1BDNVY_hd6UZfbF=gGmD7SJZiw@mail.gmail.com>
	<50A479DE.40300@shikadi.net> <50A48531.4070304@lolling.org>
	<CAH-F8DG5kYPprgaNTPd-70SqSXvSJmpOGX-P=kQsUOA9M1BNOQ@mail.gmail.com>
	<20121129101235.06980aff@lembas.zaitcev.lan>
	<CAAKTTKP+8HTJAomw1X8dQje8iOc7u4udbAL+1qY7mx7qhrgUaA@mail.gmail.com>
Message-ID: <CAAiVu1Y+aRAYMPkovj1q8wnVVwahkt=hFC=2CoRHx-NoadeZmw@mail.gmail.com>

My experience was that several commands / examples I've seen gave me
stutters here on a pretty beefy computer. It took playing around and I
didn't document everything, but so far what I've got that 'works'
stutter-free, although maybe is not so great... but it does work anyways. I
know it isn't a rasbpi but it showed me that a lot of times it isn't the
hardware causing the stutters.

ron at tripel:~$ rtl_fm -W -f 96.9e6 -W -s 200000 -r 48000 - | aplay -r 48k -f
S16_LE -t raw -c 1
Found 1 device(s):
  0:  Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U (e.g. hama nano)
Found Rafael Micro R820T tuner
Oversampling input by: 2x.
Oversampling output by: 4x.
Buffer size: 5.12ms
Tuned to 97315000 Hz.
Sampling at 1600000 Hz.
Output at 48000 Hz.
Tuner gain set to automatic.
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono





On Thu, Nov 29, 2012 at 1:28 PM, keenerd <keenerd at gmail.com> wrote:

> On 11/29/12, Pete Zaitcev <zaitcev at kotori.zaitcev.us> wrote:
> > But another thing is that rtl_fm just won't work until the signal is
> > strong enough.
>
> Maybe you should try increasing the gain.
>
> > Final command line was this:
> > rtl_fm -l 0 -f 99.5e6 -N -s 170e3 -o 4 -A -r 24e3 - | \
> > aplay -r 24k -f S16_LE -t raw -c 1
>
> Really, much smarter to use -W instead.  You are losing a moderate
> amount of the signal.  First, wbfm is slightly off center pushing 10%
> of the signal out of range.  Second, it carries audio information up
> to 16kHz and resampling at 24ks/s discards another 25%.
>
> rtl_fm -W -f 99.5e6 -g 49 | aplay -r 32k -f S16_LE -t raw -c 1
>
> will work better.  No reason to spell it out the long way.
>
> -Kyle
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20121130/08edad64/attachment.htm>