From sdrguru1 at gmail.com  Mon Sep  2 09:12:31 2013
From: sdrguru1 at gmail.com (Sdr Guru)
Date: Mon, 2 Sep 2013 12:12:31 +0300
Subject: How to get IQ samples from multiple rtl-sdr dongles in a
	synchronized manner?
In-Reply-To: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
References: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
Message-ID: <CACR-secnUZst8GkZRa7QdWSA3nFSRBj0RP9Rdb9bzZ6iABhm4w@mail.gmail.com>

Hi

Use the IR input for synchronization.
1PPS IR pulse sender.

SG


On Sun, Aug 25, 2013 at 4:13 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:

> Hi,
>
> I want to use multiple rtl-sdr dongles to do some multi-antenna
> experiments.
>
> Is it possible to read IQ samples from multiple rtl-sdr dongles in a
> synchronized manner?
>
> I already have a glance at dump1090 codes, which is a project using
> rtl-sdr to decode aircraft broadcasting ADS-B messages in 1090MHz.
>
> Seems that I should use rtlsdr_read_async() instead of rtlsdr_read_sync(),
> because that if rtlsdr_read_sync() is used, I have to call it multiple
> times sequentially. That looks not synchronized.
>
> But rtlsdr_read_async() function only accept one rtl-sdr device as input
> parameter, and it will be blocked after it is called. So seems that it also
> can't be used for my purpose directly.
>
> Also welcome any opinion on how to improve rtl-sdr lib/driver to support
> this feature.
>
> Thank you.
>
> BR
>
> Jiao Xianjun
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130902/6e136644/attachment.htm>

From sylvain.azarian at gmail.com  Mon Sep  2 11:35:04 2013
From: sylvain.azarian at gmail.com (Sylvain AZARIAN)
Date: Mon, 2 Sep 2013 13:35:04 +0200
Subject: How to get IQ samples from multiple rtl-sdr dongles in a
	synchronized manner?
In-Reply-To: <CACR-secnUZst8GkZRa7QdWSA3nFSRBj0RP9Rdb9bzZ6iABhm4w@mail.gmail.com>
References: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
	<CACR-secnUZst8GkZRa7QdWSA3nFSRBj0RP9Rdb9bzZ6iABhm4w@mail.gmail.com>
Message-ID: <CAHZVKw3L3cGEcuzz-PXK5X6rqq=9HEwMFhzovc_izN+9X0mtTw@mail.gmail.com>

Hi,

Looks interesting! Can you give more details ? (specially on the processing
behind) ?

regards
sylvain

2013/9/2 Sdr Guru <sdrguru1 at gmail.com>

> 1PPS IR pulse sender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130902/fd29a2d7/attachment.htm>

From sdrguru1 at gmail.com  Mon Sep  2 12:11:09 2013
From: sdrguru1 at gmail.com (Sdr Guru)
Date: Mon, 2 Sep 2013 15:11:09 +0300
Subject: How to get IQ samples from multiple rtl-sdr dongles in a
	synchronized manner?
In-Reply-To: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
References: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
Message-ID: <CACR-seexrTBw2+Qz2Ds8OcLck6PVuc49=LdN63U1x0FSRn9ZWw@mail.gmail.com>

The second way, use MLAT enabled dump1090
https://github.com/antirez/dump1090/pull/23
http://www.satsignal.eu/raspberry-pi/dump1090.html


On Sun, Aug 25, 2013 at 4:13 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:

> Hi,
>
> I want to use multiple rtl-sdr dongles to do some multi-antenna
> experiments.
>
> Is it possible to read IQ samples from multiple rtl-sdr dongles in a
> synchronized manner?
>
> I already have a glance at dump1090 codes, which is a project using
> rtl-sdr to decode aircraft broadcasting ADS-B messages in 1090MHz.
>
> Seems that I should use rtlsdr_read_async() instead of rtlsdr_read_sync(),
> because that if rtlsdr_read_sync() is used, I have to call it multiple
> times sequentially. That looks not synchronized.
>
> But rtlsdr_read_async() function only accept one rtl-sdr device as input
> parameter, and it will be blocked after it is called. So seems that it also
> can't be used for my purpose directly.
>
> Also welcome any opinion on how to improve rtl-sdr lib/driver to support
> this feature.
>
> Thank you.
>
> BR
>
> Jiao Xianjun
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130902/c3559dd5/attachment.htm>

From sylvain.azarian at gmail.com  Mon Sep  2 12:23:29 2013
From: sylvain.azarian at gmail.com (Sylvain AZARIAN)
Date: Mon, 2 Sep 2013 14:23:29 +0200
Subject: How to get IQ samples from multiple rtl-sdr dongles in a
	synchronized manner?
In-Reply-To: <CACR-seexrTBw2+Qz2Ds8OcLck6PVuc49=LdN63U1x0FSRn9ZWw@mail.gmail.com>
References: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
	<CACR-seexrTBw2+Qz2Ds8OcLck6PVuc49=LdN63U1x0FSRn9ZWw@mail.gmail.com>
Message-ID: <CAHZVKw0Gv9eovgXuuQhqBtc2wW19YXSTLcSsTLn5=aPyqiGBBQ@mail.gmail.com>

Thanks.

sylvain


2013/9/2 Sdr Guru <sdrguru1 at gmail.com>

> The second way, use MLAT enabled dump1090
> https://github.com/antirez/dump1090/pull/23
> http://www.satsignal.eu/raspberry-pi/dump1090.html
>
>
> On Sun, Aug 25, 2013 at 4:13 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:
>
>> Hi,
>>
>> I want to use multiple rtl-sdr dongles to do some multi-antenna
>> experiments.
>>
>> Is it possible to read IQ samples from multiple rtl-sdr dongles in a
>> synchronized manner?
>>
>> I already have a glance at dump1090 codes, which is a project using
>> rtl-sdr to decode aircraft broadcasting ADS-B messages in 1090MHz.
>>
>> Seems that I should use rtlsdr_read_async() instead of
>> rtlsdr_read_sync(), because that if rtlsdr_read_sync() is used, I have to
>> call it multiple times sequentially. That looks not synchronized.
>>
>> But rtlsdr_read_async() function only accept one rtl-sdr device as input
>> parameter, and it will be blocked after it is called. So seems that it also
>> can't be used for my purpose directly.
>>
>>  Also welcome any opinion on how to improve rtl-sdr lib/driver to support
>> this feature.
>>
>> Thank you.
>>
>> BR
>>
>> Jiao Xianjun
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130902/dbcd925e/attachment.htm>

From r.ranson at ieee.org  Mon Sep  2 19:43:26 2013
From: r.ranson at ieee.org (Richard Ranson)
Date: Mon, 2 Sep 2013 20:43:26 +0100
Subject: Reset after hot insertion of USB tuner
Message-ID: <CAMJiz+iStfSp49NeQcqBUiW0euAQKAjWT3GnkzP4P1yYqa8xwA@mail.gmail.com>

I have had great help before from this list, so many thanks for that.

I am using an ezcap tuner with a raspberry pi running a Debian based linux
OS called Raspbian.  I have built the drivers from the git hub and they
work fine. As an aside, I found the installation much easier than when I
tried it directly on my PC.

My question is that I find that if I plug the USB device in when linux is
running, it causes a re-boot of the whole OS. (btw, disconnection has no
effect). Is this the case with full blown linux systems, or just some
peculiarity of the more limited raspberry pi?  Also, it is a bit of a
nuisance, so does anyone know of a way to stop this?

many thanks Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130902/22a36a65/attachment.htm>

From f.gugliuzza at hacklabproject.org  Mon Sep  2 20:27:31 2013
From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza)
Date: Mon, 2 Sep 2013 22:27:31 +0200
Subject: Reset after hot insertion of USB tuner
In-Reply-To: <CAMJiz+iStfSp49NeQcqBUiW0euAQKAjWT3GnkzP4P1yYqa8xwA@mail.gmail.com>
References: <CAMJiz+iStfSp49NeQcqBUiW0euAQKAjWT3GnkzP4P1yYqa8xwA@mail.gmail.com>
Message-ID: <CAFhpb2V0zfMuWXCacLhqST5VXujYx2RhGticq_UwHc4JF2na3A@mail.gmail.com>

It's a bug of the raspberry power section. The USB capacitor is too small
and 5V dips when inserting power hungry devices like tuners.
http://theiopage.blogspot.it/2012/06/increasing-raspberry-pis-usb-host.htmllook
at the voltage droop fix. Also, bridge the port polyfuses too if you
have them.


2013/9/2 Richard Ranson <r.ranson at ieee.org>

> I have had great help before from this list, so many thanks for that.
>
> I am using an ezcap tuner with a raspberry pi running a Debian based linux
> OS called Raspbian.  I have built the drivers from the git hub and they
> work fine. As an aside, I found the installation much easier than when I
> tried it directly on my PC.
>
> My question is that I find that if I plug the USB device in when linux is
> running, it causes a re-boot of the whole OS. (btw, disconnection has no
> effect). Is this the case with full blown linux systems, or just some
> peculiarity of the more limited raspberry pi?  Also, it is a bit of a
> nuisance, so does anyone know of a way to stop this?
>
> many thanks Richard
>



-- 
Francesco Gugliuzza
B.Sc. in Computer Engineering
HackLabProject.org Administrator
Linux user #374630
Tel (VoIP geographic number): +39 0921440446
Tel (Libera il VoIP number): 5125320
E-mail: f.gugliuzza at hacklabproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130902/54c275b5/attachment.htm>

From fritz at spamexpire-201309.rodent.frell.theremailer.net  Sun Sep  8 19:36:53 2013
From: fritz at spamexpire-201309.rodent.frell.theremailer.net (Fritz Wuehler)
Date: Sun, 08 Sep 2013 21:36:53 +0200
Subject: rtl-sdr on Nokia n900 phones
Message-ID: <8d3287e34dae6aa2e6bd1216bad59a77@msgid.frell.theremailer.net>

I heard someone recently made rtl-sdr work on an n900.  Is it just
working drivers, or is it actually usable?  I ask, because the
processor may not be up to the job.




From anonymous at foto.nl1.torservers.net  Sun Sep  8 20:21:41 2013
From: anonymous at foto.nl1.torservers.net (Anonymous)
Date: Sun,  8 Sep 2013 16:21:41 -0400 (EDT)
Subject: rtl-sdr on Nokia n900 phones
Message-ID: <8d3287e34dae6aa2e6bd1216bad59a77@foto.nl1.torservers.net>

I heard someone recently made rtl-sdr work on an n900.  Is it just
working drivers, or is it actually usable?  I ask, because the
processor may not be up to the job.



From friedtj at free.fr  Mon Sep  9 15:58:46 2013
From: friedtj at free.fr (friedtj)
Date: Mon, 9 Sep 2013 11:58:46 -0400
Subject: RTL based SDR article in IEEE Spectrum
In-Reply-To: <CAFXU+zE-bJ8+a2hh4L2UaVTdKxeuRqESfFmJ1FePd1FQ_jJ6bg@mail.gmail.com>
References: <CAFXU+zGq66O-nPDiPTMa-+xC1Y9_QE1sW9FrVS71Kdaa=UioUg@mail.gmail.com>
	<CAHZVKw2j_fmd1AYNuUwL7bhpfSqW1FNtNu=RdXJjLQvFCbbUUQ@mail.gmail.com>
	<CAFXU+zE-bJ8+a2hh4L2UaVTdKxeuRqESfFmJ1FePd1FQ_jJ6bg@mail.gmail.com>
Message-ID: <20130909115846.22df3049@debianjmf>

not sure if anyone is interested: I had this IEEE Spectrum article on the RTL receiver
lying on my desk for a while, for those who might want to read it
http://sequanux.org/jmfriedt/t/ieee_spectrum.pdf

JM

-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France



From alexander.huemer at xx.vu  Mon Sep  9 15:22:27 2013
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Mon, 9 Sep 2013 17:22:27 +0200
Subject: RTL based SDR article in IEEE Spectrum
In-Reply-To: <20130909115846.22df3049@debianjmf>
References: <CAFXU+zGq66O-nPDiPTMa-+xC1Y9_QE1sW9FrVS71Kdaa=UioUg@mail.gmail.com>
	<CAHZVKw2j_fmd1AYNuUwL7bhpfSqW1FNtNu=RdXJjLQvFCbbUUQ@mail.gmail.com>
	<CAFXU+zE-bJ8+a2hh4L2UaVTdKxeuRqESfFmJ1FePd1FQ_jJ6bg@mail.gmail.com>
	<20130909115846.22df3049@debianjmf>
Message-ID: <20130909152227.GG20679@yade.xx.vu>

On Mon, Sep 09, 2013 at 11:58:46AM -0400, friedtj wrote:
> not sure if anyone is interested: I had this IEEE Spectrum article on the RTL receiver
> lying on my desk for a while, for those who might want to read it
> http://sequanux.org/jmfriedt/t/ieee_spectrum.pdf

This article[1] is also available in digital form for free.

Kind regards,
-Alex

[1] 
http://spectrum.ieee.org/geek-life/hands-on/a-40-softwaredefined-radio



From jsalsburg at bellsouth.net  Wed Sep 11 14:55:17 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Wed, 11 Sep 2013 09:55:17 -0500
Subject: rtl-sdr on Nokia n900 phones
In-Reply-To: <8d3287e34dae6aa2e6bd1216bad59a77@msgid.frell.theremailer.net>
References: <8d3287e34dae6aa2e6bd1216bad59a77@msgid.frell.theremailer.net>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAKF5lBCZztNAg3TKzFnxeH8BAAAAAA==@bellsouth.net>

If it is true, someone has the rtl-sdr Tuner Sticks working on the n900,
this code would allow them to operate on the Beagleboard and Beaglebone,
Single board Computers, 2 very powerful and inexpensive platforms with
powerful DSPs, GPUs, and extensive Development System.

-----Original Message-----
From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Fritz Wuehler
Sent: Sunday, September 08, 2013 2:37 PM
To: osmocom-sdr at lists.osmocom.org
Subject: rtl-sdr on Nokia n900 phones

I heard someone recently made rtl-sdr work on an n900.  Is it just working
drivers, or is it actually usable?  I ask, because the processor may not be
up to the job.


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3222/6651 - Release Date: 09/09/13




From oz9aec at gmail.com  Wed Sep 11 15:42:04 2013
From: oz9aec at gmail.com (Alexandru Csete)
Date: Wed, 11 Sep 2013 17:42:04 +0200
Subject: rtl-sdr on Nokia n900 phones
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAKF5lBCZztNAg3TKzFnxeH8BAAAAAA==@bellsouth.net>
References: <8d3287e34dae6aa2e6bd1216bad59a77@msgid.frell.theremailer.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAKF5lBCZztNAg3TKzFnxeH8BAAAAAA==@bellsouth.net>
Message-ID: <CAHG=S_fLB8-fh_vbVvAC6+nxROmTPwpS7KJaAUXbszPLpTHxeA@mail.gmail.com>

Yes, this link was posted on Reddit today:
http://talk.maemo.org/showthread.php?t=91182
He even has gnuradio and gqrx running on the N900.

However, running rtl_sdr on a Beaglebone has been a piece of cake
since the beginning, even though the Beaglebone neither has DSP nor
powerful GPU - just a plain kick-ass FPU.

Alex

On Wed, Sep 11, 2013 at 4:55 PM, Jay Salsburg <jsalsburg at bellsouth.net> wrote:
> If it is true, someone has the rtl-sdr Tuner Sticks working on the n900,
> this code would allow them to operate on the Beagleboard and Beaglebone,
> Single board Computers, 2 very powerful and inexpensive platforms with
> powerful DSPs, GPUs, and extensive Development System.
>
> -----Original Message-----
> From: osmocom-sdr-bounces at lists.osmocom.org
> [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Fritz Wuehler
> Sent: Sunday, September 08, 2013 2:37 PM
> To: osmocom-sdr at lists.osmocom.org
> Subject: rtl-sdr on Nokia n900 phones
>
> I heard someone recently made rtl-sdr work on an n900.  Is it just working
> drivers, or is it actually usable?  I ask, because the processor may not be
> up to the job.
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3392 / Virus Database: 3222/6651 - Release Date: 09/09/13
>
>



From will at willglynn.com  Fri Sep 13 01:28:31 2013
From: will at willglynn.com (Will Glynn)
Date: Fri, 13 Sep 2013 01:28:31 +0000
Subject: [PATCH] rtl_adsb: Fix invalid memory access
In-Reply-To: <1379034784-32633-1-git-send-email-will@willglynn.com>
References: <1379034784-32633-1-git-send-email-will@willglynn.com>
Message-ID: <1379035699-33668-1-git-send-email-will@willglynn.com>

single_manchester() considers both i and i+1, but the loop only
tests that i is in bounds. This causes undefined behavior, including
but not limited to a SIGBUS-related crash on Mac OS X.

(And also, we should not enter an infinite loop, caused by applying
an patch I sent that didn't also change the while condition.)
---
 src/rtl_adsb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 44b62e2..0845bf5 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -258,9 +258,10 @@ void manchester(uint16_t *buf, int len)
 	uint16_t a=0, b=0;
 	uint16_t bit;
 	int i, i2, start, errors;
+	int maximum_i = len - 1;        // len-1 since we look at i and i+1
 	// todo, allow wrap across buffers
 	i = 0;
-	while (i < len) {
+	while (i < maximum_i) {
 		/* find preamble */
 		for ( ; i < (len - preamble_len); i++) {
 			if (!preamble(buf, i)) {
@@ -275,7 +276,7 @@ void manchester(uint16_t *buf, int len)
 		i2 = start = i;
 		errors = 0;
 		/* mark bits until encoding breaks */
-		for ( ; i < len; i+=2, i2++) {
+		for ( ; i < maximum_i; i+=2, i2++) {
 			bit = single_manchester(a, b, buf[i], buf[i+1]);
 			a = buf[i];
 			b = buf[i+1];
-- 
1.8.3.4



From will at willglynn.com  Fri Sep 13 01:13:13 2013
From: will at willglynn.com (Will Glynn)
Date: Fri, 13 Sep 2013 01:13:13 +0000
Subject: [PATCH] rtl_adsb: Fix invalid memory access
Message-ID: <1379034784-32633-1-git-send-email-will@willglynn.com>

single_manchester() considers both i and i+1, but the loop only
tests that i is in bounds. This causes undefined behavior, including
but not limited to a SIGBUS-related crash on Mac OS X.
---
 src/rtl_adsb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 44b62e2..3c353a0 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -258,6 +258,7 @@ void manchester(uint16_t *buf, int len)
 	uint16_t a=0, b=0;
 	uint16_t bit;
 	int i, i2, start, errors;
+	int maximum_i = len - 1;        // len-1 since we look at i and i+1
 	// todo, allow wrap across buffers
 	i = 0;
 	while (i < len) {
@@ -275,7 +276,7 @@ void manchester(uint16_t *buf, int len)
 		i2 = start = i;
 		errors = 0;
 		/* mark bits until encoding breaks */
-		for ( ; i < len; i+=2, i2++) {
+		for ( ; i < maximum_i; i+=2, i2++) {
 			bit = single_manchester(a, b, buf[i], buf[i+1]);
 			a = buf[i];
 			b = buf[i+1];
-- 
1.8.3.4



From steve at steve-m.de  Fri Sep 13 16:39:47 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 13 Sep 2013 18:39:47 +0200
Subject: [PATCH] rtl_adsb: Fix invalid memory access
In-Reply-To: <1379034784-32633-1-git-send-email-will@willglynn.com>
References: <1379034784-32633-1-git-send-email-will@willglynn.com>
Message-ID: <52333FD3.60307@steve-m.de>

Hi,

On 13.09.2013 03:13, Will Glynn wrote:
> single_manchester() considers both i and i+1, but the loop only
> tests that i is in bounds. This causes undefined behavior, including
> but not limited to a SIGBUS-related crash on Mac OS X.

Thanks, merged it.

Regards,
Steve



From steve at steve-m.de  Fri Sep 13 16:58:43 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 13 Sep 2013 18:58:43 +0200
Subject: rtl_fm, rtl_power, mingw, r820t
In-Reply-To: <CAAKTTKPZ_uU2SxaXgVAf7EmzBD4grWoFgYh8zAtE_1d2dU040g@mail.gmail.com>
References: <CAAKTTKPZ_uU2SxaXgVAf7EmzBD4grWoFgYh8zAtE_1d2dU040g@mail.gmail.com>
Message-ID: <52334443.7090009@steve-m.de>

Hi,

sorry for the delay, I was on vacation.

On 28.08.2013 13:55, keenerd wrote:
> Overhauled scanning in rtl_fm.  This fixed a number of issues, where
> either scanning did not work at all and some brokenness on OpenBSD.
> It also meant giving up on the async API entirely.

Merged the patch, thanks.

> Released a whole new application, rtl_power.  This is something I'd
> had bouncing around on my hard drive for many months, half-unwritten
> due to over-complexity.  It'll generate CSV files of arbitrarily
> slow/wide/detailed FFTs.  Also a little visualization script[2] that
> won't choke when you give it 50,000 columns of data.

I'll take a look at it, although I'm not sure if we should pick up yet
another application in the rtl-sdr repository, or if it's better if you
just maintain it outside of the tree (like dump1090 for example). Any
opinions?

> Second was the discovery[5] that scanning had gotten a whole lot
> slower since my original experiments with rtl_fm.  85mS to retune is
> unacceptably slow.  Since the r820t driver is the slowest, I started
> looking into figuring out what is going on.  Still figuring that out
> but I have done basic cleanups to the code (removing redundancy,
> particularly around register writes) and the driver is 15% shorter
> with no modifications to code behavior.

Yeah, the r820t driver is really a mess. I've seen that the v4l-guys
have rewritten the driver [1], my goal for the next months is to use
that for rtl-sdr, merge back our gain code and make it thread-safe.

> I would not mind talking to Steve or one of the other devs on IRC
> about some of the more ambiguous aspects of the driver.  (Like, why
> some reg writes are backed up to R828_Arry[] and others aren't.  And
> is that array thread safe at all?  If not I'll have to do some very
> large changes to support multiple dongles in rtl_power.)

According some recent tests by patchvonbraun the array isn't
thread-safe.

Regards,
Steve

[1]
http://git.linuxtv.org/linux-2.6.git/blob/HEAD:/drivers/media/tuners/r820t.c



From jsalsburg at bellsouth.net  Fri Sep 13 17:43:21 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Fri, 13 Sep 2013 12:43:21 -0500
Subject: rtl-sdr on Nokia n900 phones
In-Reply-To: <CAHG=S_fLB8-fh_vbVvAC6+nxROmTPwpS7KJaAUXbszPLpTHxeA@mail.gmail.com>
References: <8d3287e34dae6aa2e6bd1216bad59a77@msgid.frell.theremailer.net>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAKF5lBCZztNAg3TKzFnxeH8BAAAAAA==@bellsouth.net>
	<CAHG=S_fLB8-fh_vbVvAC6+nxROmTPwpS7KJaAUXbszPLpTHxeA@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAG81lBDy8pZNpIDgwEAX/6ABAAAAAA==@bellsouth.net>

Yes, Alex: I have no experience with the Beaglebone but I do have a
Beagleboard. The Beaglebone has a GPU but runs the DSP Code in emulation,
whereas the Beagleboard has a Blizzard of Hardware options including a DSP
and 1080P GPU. What someone (like me) should do is create a daughterboard
for the Beagleboard, connecting a Tuner chip's I2C to one of the 3 I2C
controllers on the Beagleboard. Using an inexpensive 192 khz/24 bit (or
better) Audio Interface, the Beagleboard could make quite an intelligent
Radio/Spectrum Analyser/Oscilloscope, with a touch screen and
network/wireless connectivity; or just use the tuner stick's 8 bit A/D;
whatever.

-----Original Message-----
From: Alexandru Csete [mailto:oz9aec at gmail.com] 
Sent: Wednesday, September 11, 2013 10:42 AM
To: Jay Salsburg
Cc: osmocom-sdr at lists.osmocom.org
Subject: Re: rtl-sdr on Nokia n900 phones

Yes, this link was posted on Reddit today:
http://talk.maemo.org/showthread.php?t=91182
He even has gnuradio and gqrx running on the N900.

However, running rtl_sdr on a Beaglebone has been a piece of cake since the
beginning, even though the Beaglebone neither has DSP nor powerful GPU -
just a plain kick-ass FPU.

Alex

On Wed, Sep 11, 2013 at 4:55 PM, Jay Salsburg <jsalsburg at bellsouth.net>
wrote:
> If it is true, someone has the rtl-sdr Tuner Sticks working on the 
> n900, this code would allow them to operate on the Beagleboard and 
> Beaglebone, Single board Computers, 2 very powerful and inexpensive 
> platforms with powerful DSPs, GPUs, and extensive Development System.
>
> -----Original Message-----
> From: osmocom-sdr-bounces at lists.osmocom.org
> [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Fritz 
> Wuehler
> Sent: Sunday, September 08, 2013 2:37 PM
> To: osmocom-sdr at lists.osmocom.org
> Subject: rtl-sdr on Nokia n900 phones
>
> I heard someone recently made rtl-sdr work on an n900.  Is it just 
> working drivers, or is it actually usable?  I ask, because the 
> processor may not be up to the job.
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3392 / Virus Database: 3222/6651 - Release Date: 
> 09/09/13
>
>
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3222/6659 - Release Date: 09/12/13




From thunder.m at email.cz  Fri Sep 13 13:22:40 2013
From: thunder.m at email.cz (=?UTF-8?B?TWlyb3NsYXYgU2x1Z2XFiA==?=)
Date: Fri, 13 Sep 2013 15:22:40 +0200
Subject: Complex FIR and Stereo support for rtl_fm
Message-ID: <523311A0.3030900@email.cz>

Hi again,

I am working on my own SDR project for Stereo FM radio support, but i 
would like to also improve quality for rtl_fm application, i made 
unoficial patch to add:

Complex FIR - to filter strong signals close to wanted signal
Real FIR - to filter pilot from FM
Stereo FIR
Stereo Deemphasis
AGC support - it can give better resolution of IQ data

Some other improvments in FM radio code.

All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts, of 
course SSE is the fastest one and it should works on Intel Atoms, but 
not on ARM.

Feel free to use any part of code in any of you programs, I know that 
this code is little to much to add it into rtl_fm, but maybe it could 
somebody help to recieve HW stereo FM radio.

Speed of SSE code is much better than anything you can get around here, 
on Core i7 it consume only 5% of one CPU, so i could demodulate at least 
80 channels at the same time in stereo quality of course.

I tried this code only on AMD64 and GCC Linux, so i am not sure if it 
can be compiled under windows.

-- 
Miroslav Sluge?
+420 724 825 885

Teramos Multimedia s.r.o.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl_fm_stereo.diff
Type: text/x-diff
Size: 35340 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130913/e83868f2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl_fm.c
Type: text/x-csrc
Size: 48707 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130913/e83868f2/attachment-0001.bin>

From tom at trondeau.com  Sun Sep 15 14:27:25 2013
From: tom at trondeau.com (Tom Rondeau)
Date: Sun, 15 Sep 2013 10:27:25 -0400
Subject: Complex FIR and Stereo support for rtl_fm
In-Reply-To: <523311A0.3030900@email.cz>
References: <523311A0.3030900@email.cz>
Message-ID: <CA+SzT6gdKNymD2hjZ5r56SAhB5zSMGZTR5cT6aN-CY0TfUWVNw@mail.gmail.com>

On Fri, Sep 13, 2013 at 9:22 AM, Miroslav Sluge? <thunder.m at email.cz> wrote:
> Hi again,
>
> I am working on my own SDR project for Stereo FM radio support, but i would
> like to also improve quality for rtl_fm application, i made unoficial patch
> to add:
>
> Complex FIR - to filter strong signals close to wanted signal
> Real FIR - to filter pilot from FM
> Stereo FIR
> Stereo Deemphasis
> AGC support - it can give better resolution of IQ data
>
> Some other improvments in FM radio code.
>
> All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts, of
> course SSE is the fastest one and it should works on Intel Atoms, but not on
> ARM.

Nice work, Miroslav. I wanted to point out our VOLK project that's
part of GNU Radio. It's designed to abstract SIMD instructions. We
don't have that much support for NEON right now, but VOLK is designed
in such a way that if you're using VOLK kernels, it'll fall back to a
generic implementation until such time as the kernel is written for
the particular architecture. You can get more info on the project
here:

http://www.trondeau.com/blog/2013/6/12/nearly-50-minutes-of-volk.html
http://www.trondeau.com/blog/2012/2/13/volk-integration-to-gnu-radio.html

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13


> --
> Miroslav Sluge?
> +420 724 825 885
>
> Teramos Multimedia s.r.o.



From psbhlw at mail.ru  Sun Sep 15 20:07:08 2013
From: psbhlw at mail.ru (psb hlw)
Date: Mon, 16 Sep 2013 02:07:08 +0600
Subject: [PATCH] rtl_sdr: Direct sampling mode + RTL AGC
Message-ID: <5236136C.9090201@mail.ru>

Hi,

I didn't find rtl_sdr with implemented direct sampling mode, so I made the patch. Also it has an option to set RTL AGC on.

This feature allows to use tuners as cheap data loggers without changing the schematic of the tuners. You can just connect wires directly to pins 1-2 of RTL2832 (I channel, diff. input) or pins 3-4 (Q channel, diff. input). When direct sampling mode is on - tuner's chip outputs are disabled and doesn't affect external signal.

For example, this command will write 8 bit samples to file 'mydata' at 2.4 MHz sampling rate with automatic gain:

        rtl_sdr.exe -f 0 -s 2400000 -i -G mydata

Hope this will be useful for somebody as it was for me.

If you will accept the patch - please, update the windows binaries.

Thanks,
psb.

-------------------------------------------------------------------------------
diff --git a/src/rtl_sdr.c b/src/rtl_sdr.c
index eeb6dba..3564329 100644
--- a/src/rtl_sdr.c
+++ b/src/rtl_sdr.c
@@ -42,6 +42,7 @@
 static int do_exit = 0;
 static uint32_t bytes_to_read = 0;
 static rtlsdr_dev_t *dev = NULL;
+static int samp_mode = 0;
 
 void usage(void)
 {
@@ -54,6 +55,9 @@ void usage(void)
 		"\t[-b output_block_size (default: 16 * 16384)]\n"
 		"\t[-n number of samples to read (default: 0, infinite)]\n"
 		"\t[-S force sync output (default: async)]\n"
+		"\t[-i set direct sampling mode (I)]\n"
+		"\t[-q set direct sampling mode (Q)]\n"
+		"\t[-G use RTL automatic gain]\n"
 		"\tfilename (a '-' dumps samples to stdout)\n\n");
 	exit(1);
 }
@@ -81,6 +85,8 @@ static void sighandler(int signum)
 
 static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
 {
+	uint32_t i, r;
+	unsigned char *p1, *p2;
 	if (ctx) {
 		if (do_exit)
 			return;
@@ -91,7 +97,16 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
 			rtlsdr_cancel_async(dev);
 		}
 
-		if (fwrite(buf, 1, len, (FILE*)ctx) != len) {
+		if (samp_mode) {
+			// For direct sampling mode we throw out each 2nd value,
+			// i.e., save only one channel data - I or Q.
+			for (i=0, p1=buf, p2=buf; i<len; i+=2, p2++)
+				*p1++ = *p2++;
+			r = (fwrite(buf, 1, len/2, (FILE*)ctx) == len/2);
+		} else
+			r = (fwrite(buf, 1, len, (FILE*)ctx) == len);
+
+		if (!r) {
 			fprintf(stderr, "Short write, samples lost, exiting!\n");
 			rtlsdr_cancel_async(dev);
 		}
@@ -119,8 +134,10 @@ int main(int argc, char **argv)
 	uint32_t out_block_size = DEFAULT_BUF_LENGTH;
 	int device_count;
 	char vendor[256], product[256], serial[256];
+	uint32_t use_rtlagc = 0;
+	unsigned char *p1, *p2;
 
-	while ((opt = getopt(argc, argv, "d:f:g:s:b:n:S::")) != -1) {
+	while ((opt = getopt(argc, argv, "d:f:g:s:b:n:S::Gqi")) != -1) {
 		switch (opt) {
 		case 'd':
 			dev_index = atoi(optarg);
@@ -143,6 +160,15 @@ int main(int argc, char **argv)
 		case 'S':
 			sync_mode = 1;
 			break;
+		case 'q':
+			samp_mode = 2;
+			break;
+		case 'i':
+			samp_mode = 1;
+			break;
+		case 'G':
+			use_rtlagc = 1;
+			break;
 		default:
 			usage();
 			break;
@@ -205,6 +231,15 @@ int main(int argc, char **argv)
 	if (r < 0)
 		fprintf(stderr, "WARNING: Failed to set sample rate.\n");
 
+	/* Set direct sampling */
+	if (samp_mode) {
+		r = rtlsdr_set_direct_sampling(dev, samp_mode);
+		if (r < 0)
+			fprintf(stderr, "WARNING: Failed to set direct sampling mode.\n");
+		else
+			fprintf(stderr, "Tuner set to direct sampling mode (%c).\n", (samp_mode==1)?'I':'Q');
+	}
+
 	/* Set the frequency */
 	r = rtlsdr_set_center_freq(dev, frequency);
 	if (r < 0)
@@ -231,6 +266,21 @@ int main(int argc, char **argv)
 			fprintf(stderr, "Tuner gain set to %f dB.\n", gain/10.0);
 	}
 
+	/* Set RTL automatic gain */
+	if (1 == use_rtlagc) {
+		/* Enable automatic RTL gain */
+		r = rtlsdr_set_agc_mode(dev, 1);
+		if (r < 0)
+			fprintf(stderr, "WARNING: Failed to enable RTL automatic gain.\n");
+		else
+			fprintf(stderr, "RTL automatic gain enabled.\n");
+	} else {
+		/* Disable automatic RTL gain */
+		r = rtlsdr_set_agc_mode(dev, 0);
+		if (r < 0)
+			fprintf(stderr, "WARNING: Failed to disable RTL automatic gain.\n");
+	}
+
 	if(strcmp(filename, "-") == 0) { /* Write samples to stdout */
 		file = stdout;
 #ifdef _WIN32
@@ -263,7 +313,16 @@ int main(int argc, char **argv)
 				do_exit = 1;
 			}
 
-			if (fwrite(buffer, 1, n_read, file) != (size_t)n_read) {
+			if (samp_mode) {
+				// For direct sampling mode we throw out each 2nd value,
+				// i.e., save only one channel data - I or Q.
+				for (i=0, p1=buffer, p2=buffer; i<n_read; i+=2, p2++)
+					*p1++ = *p2++;
+				r = (fwrite(buffer, 1, n_read/2, file)== n_read/2);
+			} else
+				r = (fwrite(buffer, 1, n_read, file) == n_read);
+
+			if (!r) {
 				fprintf(stderr, "Short write, samples lost, exiting!\n");
 				break;
 			}



From ewan.meadows at gmail.com  Mon Sep 16 07:38:10 2013
From: ewan.meadows at gmail.com (Ewan Meadows)
Date: Mon, 16 Sep 2013 08:38:10 +0100
Subject: rtl_fm and multimon-ng issues
Message-ID: <CAGCfTUhSdOF8Gswi0XwNeVSeKpDO2EWPoEjugEgUayHFhR54Rg@mail.gmail.com>

Hi all,

I've been using rtl_fm piped into multimon-ng for a while now which
has been working pretty well for decoding POCSAG, I use this command
line:
rtl_fm -f 153.350M -r 22050 - | ./multimon-ng -t raw -a POCSAG512 -a
POCSAG1200 -a POCSAG2400 -f alpha -D pocsag.db -

I updated rtl_sdr today and now all I get is junk decodes
POCSAG2400-: Address: 1318769  Function: 255
POCSAG2400-: Alpha: KA^MA
POCSAG1200-: Address: 1700218  Function: 255
POCSAG1200-: Alpha: )"<DLE>'f
POCSAG1200-: Address:  143961  Function: 255


I rolled back to an earlier version using git checkout commit and it
appears the following commit broke it:
c4fcfbb46e0a432902a2b78db4951bd20f68b9b2

Commit 8c3a99c8f7a88d7d2a05845d4b20cfcdacac4054 works fine, whereas
the commit after causes multimon_ng to spit out garbage :-(



From michal.moranski at gmail.com  Mon Sep 16 09:36:12 2013
From: michal.moranski at gmail.com (=?UTF-8?B?TWljaGHFgiBNb3JhxYRza2k=?=)
Date: Mon, 16 Sep 2013 11:36:12 +0200
Subject: Complex FIR and Stereo support for rtl_fm
In-Reply-To: <523311A0.3030900@email.cz>
References: <523311A0.3030900@email.cz>
Message-ID: <5236D10C.5040009@gmail.com>

W dniu 2013-09-13 15:22, Miroslav Sluge? pisze:
> Hi again,
>
> I am working on my own SDR project for Stereo FM radio support, but i 
> would like to also improve quality for rtl_fm application, i made 
> unoficial patch to add:
>
> Complex FIR - to filter strong signals close to wanted signal
> Real FIR - to filter pilot from FM
> Stereo FIR
> Stereo Deemphasis
> AGC support - it can give better resolution of IQ data
>
> Some other improvments in FM radio code.
>
> All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts, 
> of course SSE is the fastest one and it should works on Intel Atoms, 
> but not on ARM.
>
> Feel free to use any part of code in any of you programs, I know that 
> this code is little to much to add it into rtl_fm, but maybe it could 
> somebody help to recieve HW stereo FM radio.
>
> Speed of SSE code is much better than anything you can get around 
> here, on Core i7 it consume only 5% of one CPU, so i could demodulate 
> at least 80 channels at the same time in stereo quality of course.
>
> I tried this code only on AMD64 and GCC Linux, so i am not sure if it 
> can be compiled under windows.
>
Hi! Very nice to hear, that someone working on Stereo FM reception. I'm 
building a small remote devices with rtl-dongles as fm stereo receivers. 
Now i'm using gnu-radio to decode fm-stereo, but as you all know, 
gnu-radio is a large and heavy project and it's wasting its 
capatibilities in that role.
It would be very nice if native rtl-sdr software can decode fm-stereo.

Which version of rtl-sdr was used as base version? I'm getting errors 
after applying the patch to last version:

patching file rtl_fm.c
Hunk #2 succeeded at 47 (offset 5 lines).
Hunk #3 succeeded at 87 (offset 9 lines).
Hunk #4 succeeded at 144 (offset 9 lines).
Hunk #5 succeeded at 169 (offset 9 lines).
Hunk #6 succeeded at 190 (offset 9 lines).
Hunk #7 FAILED at 239.
Hunk #8 FAILED at 258.
Hunk #9 succeeded at 314 (offset 13 lines).
Hunk #10 succeeded at 420 (offset 13 lines).
Hunk #11 succeeded at 994 (offset 13 lines).
Hunk #12 FAILED at 1106.
Hunk #13 succeeded at 1148 (offset 15 lines).
Hunk #14 succeeded at 1259 (offset 35 lines).
Hunk #15 succeeded at 1268 (offset 35 lines).
Hunk #16 succeeded at 1290 (offset 35 lines).
Hunk #17 succeeded at 1301 with fuzz 2 (offset 36 lines).
Hunk #18 succeeded at 1351 (offset 38 lines).
Hunk #19 succeeded at 1378 (offset 38 lines).
Hunk #20 succeeded at 1389 (offset 38 lines).
Hunk #21 succeeded at 1508 (offset 50 lines).
Hunk #22 succeeded at 1527 (offset 50 lines).
3 out of 22 hunks FAILED -- saving rejects to file rtl_fm.c.rej

P.S. Are you planning to add support for RDS in the future?

Regards, Micha?.




From michal.moranski at gmail.com  Mon Sep 16 12:09:31 2013
From: michal.moranski at gmail.com (=?UTF-8?B?TWljaGHFgiBNb3JhxYRza2k=?=)
Date: Mon, 16 Sep 2013 14:09:31 +0200
Subject: Complex FIR and Stereo support for rtl_fm
In-Reply-To: <5236D18A.2090706@email.cz>
References: <523311A0.3030900@email.cz> <5236D10C.5040009@gmail.com>
	<5236D18A.2090706@email.cz>
Message-ID: <5236F4FB.2040809@gmail.com>

W dniu 2013-09-16 11:38, Miroslav Sluge? pisze:
> Hi, i used git from 14.9.2013, if you get errors from actual git it 
> could be because some functions might go into upstream, i also add as 
> attachment just rtl_fm.c so just replace it your version with this 
> version and it should work.
Thanks for rapid answer. I just compiled your code.
First, i got this message when compiling:
/usr/lib/gcc/i486-linux-gnu/4.4.3/include/emmintrin.h:32:3: error: 
#error "SSE2 instruction set not enabled"
Then i've added line to CMakeLists.txt:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} "-msse -msse2 -msse3")
After that i was able to compile the code, but with some warnings:

/usr/src/rtl-sdr/src/rtl_fm.c: In function ?low_pass_complex?:
/usr/src/rtl-sdr/src/rtl_fm.c:451: warning: dereferencing pointer ?v_r? 
does break strict-aliasing rules
/usr/src/rtl-sdr/src/rtl_fm.c:436: note: initialized from here
/usr/src/rtl-sdr/src/rtl_fm.c:452: warning: dereferencing pointer ?v_i? 
does break strict-aliasing rules
/usr/src/rtl-sdr/src/rtl_fm.c:436: note: initialized from here
/usr/src/rtl-sdr/src/rtl_fm.c: In function ?low_pass_real?:
/usr/src/rtl-sdr/src/rtl_fm.c:769: warning: dereferencing pointer ?v_m? 
does break strict-aliasing rules
/usr/src/rtl-sdr/src/rtl_fm.c:755: note: initialized from here
/usr/src/rtl-sdr/src/rtl_fm.c:850: warning: dereferencing pointer ?v_m? 
does break strict-aliasing rules
/usr/src/rtl-sdr/src/rtl_fm.c:872: warning: dereferencing pointer ?v_m? 
does break strict-aliasing rules
/usr/src/rtl-sdr/src/rtl_fm.c:834: note: initialized from here
/usr/src/rtl-sdr/src/rtl_fm.c:851: warning: dereferencing pointer ?v_p? 
does break strict-aliasing rules
/usr/src/rtl-sdr/src/rtl_fm.c:834: note: initialized from here
/usr/src/rtl-sdr/src/rtl_fm.c:852: warning: dereferencing pointer ?v_s? 
does break strict-aliasing rules
/usr/src/rtl-sdr/src/rtl_fm.c:873: warning: dereferencing pointer ?v_s? 
does break strict-aliasing rules

Now i got segfaults when i try to run rtl_fm -X -f 90.4e6 :
root at dabplus:/usr/src/rtl-sdr# rtl_fm -X -f 90.4e6 -
Found 1 device(s):
   0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Lifeview LV5TDeluxe
Found Fitipower FC0013 tuner
Oversampling input by: 6x.
Oversampling output by: 1x.
Buffer size: 7.11ms
Tuned to 90704000 Hz.
Sampling at 1152000 Hz.
Output at 48000 Hz.
LP Complex: FIR hamming (SSE2), size: 32
LP Real: FIR hamming stereo (SSE2), size: 64
Tuner gain set to automatic.
Tuner AGC ON.
De-epmhasis IIR: 50.0 us
Segmentation fault

My processor:
root at dabplus:/usr/src/rtl-sdr# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU D525   @ 1.80GHz
.....
root at dabplus:/usr/src/rtl-sdr# cat /etc/issue
Ubuntu 10.04.4 LTS \n \l

root at dabplus:/usr/src/rtl-sdr# uname -r
2.6.32-38-generic-pae



>
> I have RDS decoder also, but it is very ugly and not all issues are 
> solved.
Wow :) If you searching for help with that you can count on me.

>
> Miroslav Sluge?
> +420 724 825 885
>
> Micha? Mora?ski napsal(a):
>> W dniu 2013-09-13 15:22, Miroslav Sluge? pisze:
>>> Hi again,
>>>
>>> I am working on my own SDR project for Stereo FM radio support, but i
>>> would like to also improve quality for rtl_fm application, i made
>>> unoficial patch to add:
>>>
>>> Complex FIR - to filter strong signals close to wanted signal
>>> Real FIR - to filter pilot from FM
>>> Stereo FIR
>>> Stereo Deemphasis
>>> AGC support - it can give better resolution of IQ data
>>>
>>> Some other improvments in FM radio code.
>>>
>>> All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts,
>>> of course SSE is the fastest one and it should works on Intel Atoms,
>>> but not on ARM.
>>>
>>> Feel free to use any part of code in any of you programs, I know that
>>> this code is little to much to add it into rtl_fm, but maybe it could
>>> somebody help to recieve HW stereo FM radio.
>>>
>>> Speed of SSE code is much better than anything you can get around
>>> here, on Core i7 it consume only 5% of one CPU, so i could demodulate
>>> at least 80 channels at the same time in stereo quality of course.
>>>
>>> I tried this code only on AMD64 and GCC Linux, so i am not sure if it
>>> can be compiled under windows.
>>>
>> Hi! Very nice to hear, that someone working on Stereo FM reception. I'm
>> building a small remote devices with rtl-dongles as fm stereo receivers.
>> Now i'm using gnu-radio to decode fm-stereo, but as you all know,
>> gnu-radio is a large and heavy project and it's wasting its
>> capatibilities in that role.
>> It would be very nice if native rtl-sdr software can decode fm-stereo.
>>
>> Which version of rtl-sdr was used as base version? I'm getting errors
>> after applying the patch to last version:
>>
>> patching file rtl_fm.c
>> Hunk #2 succeeded at 47 (offset 5 lines).
>> Hunk #3 succeeded at 87 (offset 9 lines).
>> Hunk #4 succeeded at 144 (offset 9 lines).
>> Hunk #5 succeeded at 169 (offset 9 lines).
>> Hunk #6 succeeded at 190 (offset 9 lines).
>> Hunk #7 FAILED at 239.
>> Hunk #8 FAILED at 258.
>> Hunk #9 succeeded at 314 (offset 13 lines).
>> Hunk #10 succeeded at 420 (offset 13 lines).
>> Hunk #11 succeeded at 994 (offset 13 lines).
>> Hunk #12 FAILED at 1106.
>> Hunk #13 succeeded at 1148 (offset 15 lines).
>> Hunk #14 succeeded at 1259 (offset 35 lines).
>> Hunk #15 succeeded at 1268 (offset 35 lines).
>> Hunk #16 succeeded at 1290 (offset 35 lines).
>> Hunk #17 succeeded at 1301 with fuzz 2 (offset 36 lines).
>> Hunk #18 succeeded at 1351 (offset 38 lines).
>> Hunk #19 succeeded at 1378 (offset 38 lines).
>> Hunk #20 succeeded at 1389 (offset 38 lines).
>> Hunk #21 succeeded at 1508 (offset 50 lines).
>> Hunk #22 succeeded at 1527 (offset 50 lines).
>> 3 out of 22 hunks FAILED -- saving rejects to file rtl_fm.c.rej
>>
>> P.S. Are you planning to add support for RDS in the future?
>>
>> Regards, Micha?.
>>
>>




From michal.moranski at gmail.com  Mon Sep 16 15:33:35 2013
From: michal.moranski at gmail.com (=?UTF-8?B?TWljaGHFgiBNb3JhxYRza2k=?=)
Date: Mon, 16 Sep 2013 17:33:35 +0200
Subject: Complex FIR and Stereo support for rtl_fm
In-Reply-To: <52370209.4040701@email.cz>
References: <523311A0.3030900@email.cz> <5236D10C.5040009@gmail.com>
	<5236D18A.2090706@email.cz> <5236F4FB.2040809@gmail.com>
	<52370209.4040701@email.cz>
Message-ID: <523724CF.5080000@gmail.com>

W dniu 2013-09-16 15:05, Miroslav Sluge? pisze:
> Thanks for testing, is it 32bit arch?
Right.
>
> All memory buffers used in SSE should be 16bit aligned, please try no 
> SSE version:
>
> rtl_fm -X -F 2 -J 5 -f yourfreq
>
> Also you can try modified rtl_fm version i send as attachment which 
> use memalign to allocate buffers instead of malloc, but it is only for 
> gcc.
Yeah! The code attached works perfectly! Thank you so much! :)
>
> On X86_64 platform all malloc are 16bit aligned so i missed this.
>
> Those errors when compiling are not important, but also in SSE part.
>
> Miroslav Sluge?
> +420 724 825 885
>
> Micha? Mora?ski napsal(a):
>> W dniu 2013-09-16 11:38, Miroslav Sluge? pisze:
>>> Hi, i used git from 14.9.2013, if you get errors from actual git it
>>> could be because some functions might go into upstream, i also add as
>>> attachment just rtl_fm.c so just replace it your version with this
>>> version and it should work.
>> Thanks for rapid answer. I just compiled your code.
>> First, i got this message when compiling:
>> /usr/lib/gcc/i486-linux-gnu/4.4.3/include/emmintrin.h:32:3: error:
>> #error "SSE2 instruction set not enabled"
>> Then i've added line to CMakeLists.txt:
>> set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} "-msse -msse2 -msse3")
>> After that i was able to compile the code, but with some warnings:
>>
>> /usr/src/rtl-sdr/src/rtl_fm.c: In function ?low_pass_complex?:
>> /usr/src/rtl-sdr/src/rtl_fm.c:451: warning: dereferencing pointer ?v_r?
>> does break strict-aliasing rules
>> /usr/src/rtl-sdr/src/rtl_fm.c:436: note: initialized from here
>> /usr/src/rtl-sdr/src/rtl_fm.c:452: warning: dereferencing pointer ?v_i?
>> does break strict-aliasing rules
>> /usr/src/rtl-sdr/src/rtl_fm.c:436: note: initialized from here
>> /usr/src/rtl-sdr/src/rtl_fm.c: In function ?low_pass_real?:
>> /usr/src/rtl-sdr/src/rtl_fm.c:769: warning: dereferencing pointer ?v_m?
>> does break strict-aliasing rules
>> /usr/src/rtl-sdr/src/rtl_fm.c:755: note: initialized from here
>> /usr/src/rtl-sdr/src/rtl_fm.c:850: warning: dereferencing pointer ?v_m?
>> does break strict-aliasing rules
>> /usr/src/rtl-sdr/src/rtl_fm.c:872: warning: dereferencing pointer ?v_m?
>> does break strict-aliasing rules
>> /usr/src/rtl-sdr/src/rtl_fm.c:834: note: initialized from here
>> /usr/src/rtl-sdr/src/rtl_fm.c:851: warning: dereferencing pointer ?v_p?
>> does break strict-aliasing rules
>> /usr/src/rtl-sdr/src/rtl_fm.c:834: note: initialized from here
>> /usr/src/rtl-sdr/src/rtl_fm.c:852: warning: dereferencing pointer ?v_s?
>> does break strict-aliasing rules
>> /usr/src/rtl-sdr/src/rtl_fm.c:873: warning: dereferencing pointer ?v_s?
>> does break strict-aliasing rules
>>
>> Now i got segfaults when i try to run rtl_fm -X -f 90.4e6 :
>> root at dabplus:/usr/src/rtl-sdr# rtl_fm -X -f 90.4e6 -
>> Found 1 device(s):
>> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>>
>> Using device 0: Lifeview LV5TDeluxe
>> Found Fitipower FC0013 tuner
>> Oversampling input by: 6x.
>> Oversampling output by: 1x.
>> Buffer size: 7.11ms
>> Tuned to 90704000 Hz.
>> Sampling at 1152000 Hz.
>> Output at 48000 Hz.
>> LP Complex: FIR hamming (SSE2), size: 32
>> LP Real: FIR hamming stereo (SSE2), size: 64
>> Tuner gain set to automatic.
>> Tuner AGC ON.
>> De-epmhasis IIR: 50.0 us
>> Segmentation fault
>>
>> My processor:
>> root at dabplus:/usr/src/rtl-sdr# cat /proc/cpuinfo
>> processor : 0
>> vendor_id : GenuineIntel
>> cpu family : 6
>> model : 28
>> model name : Intel(R) Atom(TM) CPU D525 @ 1.80GHz
>> .....
>> root at dabplus:/usr/src/rtl-sdr# cat /etc/issue
>> Ubuntu 10.04.4 LTS \n \l
>>
>> root at dabplus:/usr/src/rtl-sdr# uname -r
>> 2.6.32-38-generic-pae
>>
>>
>>
>>>
>>> I have RDS decoder also, but it is very ugly and not all issues are
>>> solved.
>> Wow :) If you searching for help with that you can count on me.
>>
>>>
>>> Miroslav Sluge?
>>> +420 724 825 885
>>>
>>> Micha? Mora?ski napsal(a):
>>>> W dniu 2013-09-13 15:22, Miroslav Sluge? pisze:
>>>>> Hi again,
>>>>>
>>>>> I am working on my own SDR project for Stereo FM radio support, but i
>>>>> would like to also improve quality for rtl_fm application, i made
>>>>> unoficial patch to add:
>>>>>
>>>>> Complex FIR - to filter strong signals close to wanted signal
>>>>> Real FIR - to filter pilot from FM
>>>>> Stereo FIR
>>>>> Stereo Deemphasis
>>>>> AGC support - it can give better resolution of IQ data
>>>>>
>>>>> Some other improvments in FM radio code.
>>>>>
>>>>> All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts,
>>>>> of course SSE is the fastest one and it should works on Intel Atoms,
>>>>> but not on ARM.
>>>>>
>>>>> Feel free to use any part of code in any of you programs, I know that
>>>>> this code is little to much to add it into rtl_fm, but maybe it could
>>>>> somebody help to recieve HW stereo FM radio.
>>>>>
>>>>> Speed of SSE code is much better than anything you can get around
>>>>> here, on Core i7 it consume only 5% of one CPU, so i could demodulate
>>>>> at least 80 channels at the same time in stereo quality of course.
>>>>>
>>>>> I tried this code only on AMD64 and GCC Linux, so i am not sure if it
>>>>> can be compiled under windows.
>>>>>
>>>> Hi! Very nice to hear, that someone working on Stereo FM reception. 
>>>> I'm
>>>> building a small remote devices with rtl-dongles as fm stereo 
>>>> receivers.
>>>> Now i'm using gnu-radio to decode fm-stereo, but as you all know,
>>>> gnu-radio is a large and heavy project and it's wasting its
>>>> capatibilities in that role.
>>>> It would be very nice if native rtl-sdr software can decode fm-stereo.
>>>>
>>>> Which version of rtl-sdr was used as base version? I'm getting errors
>>>> after applying the patch to last version:
>>>>
>>>> patching file rtl_fm.c
>>>> Hunk #2 succeeded at 47 (offset 5 lines).
>>>> Hunk #3 succeeded at 87 (offset 9 lines).
>>>> Hunk #4 succeeded at 144 (offset 9 lines).
>>>> Hunk #5 succeeded at 169 (offset 9 lines).
>>>> Hunk #6 succeeded at 190 (offset 9 lines).
>>>> Hunk #7 FAILED at 239.
>>>> Hunk #8 FAILED at 258.
>>>> Hunk #9 succeeded at 314 (offset 13 lines).
>>>> Hunk #10 succeeded at 420 (offset 13 lines).
>>>> Hunk #11 succeeded at 994 (offset 13 lines).
>>>> Hunk #12 FAILED at 1106.
>>>> Hunk #13 succeeded at 1148 (offset 15 lines).
>>>> Hunk #14 succeeded at 1259 (offset 35 lines).
>>>> Hunk #15 succeeded at 1268 (offset 35 lines).
>>>> Hunk #16 succeeded at 1290 (offset 35 lines).
>>>> Hunk #17 succeeded at 1301 with fuzz 2 (offset 36 lines).
>>>> Hunk #18 succeeded at 1351 (offset 38 lines).
>>>> Hunk #19 succeeded at 1378 (offset 38 lines).
>>>> Hunk #20 succeeded at 1389 (offset 38 lines).
>>>> Hunk #21 succeeded at 1508 (offset 50 lines).
>>>> Hunk #22 succeeded at 1527 (offset 50 lines).
>>>> 3 out of 22 hunks FAILED -- saving rejects to file rtl_fm.c.rej
>>>>
>>>> P.S. Are you planning to add support for RDS in the future?
>>>>
>>>> Regards, Micha?.
>>>>
>>>>
>>
>>




From olof.tangrot at gmail.com  Mon Sep 16 16:43:32 2013
From: olof.tangrot at gmail.com (Olof Tangrot)
Date: Mon, 16 Sep 2013 18:43:32 +0200
Subject: rtl_fm and multimon-ng issues
In-Reply-To: <CAGCfTUhSdOF8Gswi0XwNeVSeKpDO2EWPoEjugEgUayHFhR54Rg@mail.gmail.com>
References: <CAGCfTUhSdOF8Gswi0XwNeVSeKpDO2EWPoEjugEgUayHFhR54Rg@mail.gmail.com>
Message-ID: <CAG0+6kmyyN58VcNs+gk9n0PiysvcWZ7yROMbupzsZG8NM8jYqQ@mail.gmail.com>

I am not sure this is the right list for bug reports for multimon-ng. There
is a tracker on github where it is possible submit issues though.
Hi all,

I've been using rtl_fm piped into multimon-ng for a while now which
has been working pretty well for decoding POCSAG, I use this command
line:
rtl_fm -f 153.350M -r 22050 - | ./multimon-ng -t raw -a POCSAG512 -a
POCSAG1200 -a POCSAG2400 -f alpha -D pocsag.db -

I updated rtl_sdr today and now all I get is junk decodes
POCSAG2400-: Address: 1318769  Function: 255
POCSAG2400-: Alpha: KA^MA
POCSAG1200-: Address: 1700218  Function: 255
POCSAG1200-: Alpha: )"<DLE>'f
POCSAG1200-: Address:  143961  Function: 255


I rolled back to an earlier version using git checkout commit and it
appears the following commit broke it:
c4fcfbb46e0a432902a2b78db4951bd20f68b9b2

Commit 8c3a99c8f7a88d7d2a05845d4b20cfcdacac4054 works fine, whereas
the commit after causes multimon_ng to spit out garbage :-(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130916/c6faf449/attachment.htm>

From ewan.meadows at gmail.com  Mon Sep 16 17:17:47 2013
From: ewan.meadows at gmail.com (Ewan Meadows)
Date: Mon, 16 Sep 2013 18:17:47 +0100
Subject: rtl_fm and multimon-ng issues
In-Reply-To: <CAG0+6kmyyN58VcNs+gk9n0PiysvcWZ7yROMbupzsZG8NM8jYqQ@mail.gmail.com>
References: <CAGCfTUhSdOF8Gswi0XwNeVSeKpDO2EWPoEjugEgUayHFhR54Rg@mail.gmail.com>
	<CAG0+6kmyyN58VcNs+gk9n0PiysvcWZ7yROMbupzsZG8NM8jYqQ@mail.gmail.com>
Message-ID: <CAGCfTUhwkfhQrpu9kGdYeYQHisFbzaMWEprvrMz_vtLCO9V=Dw@mail.gmail.com>

The problem is with the recent changes to rtl_fm, as I can roll back
to the commit before scanning was fixed and it works fine.

On 16 September 2013 17:43, Olof Tangrot <olof.tangrot at gmail.com> wrote:
> I am not sure this is the right list for bug reports for multimon-ng. There
> is a tracker on github where it is possible submit issues though.
>
> Hi all,
>
> I've been using rtl_fm piped into multimon-ng for a while now which
> has been working pretty well for decoding POCSAG, I use this command
> line:
> rtl_fm -f 153.350M -r 22050 - | ./multimon-ng -t raw -a POCSAG512 -a
> POCSAG1200 -a POCSAG2400 -f alpha -D pocsag.db -
>
> I updated rtl_sdr today and now all I get is junk decodes
> POCSAG2400-: Address: 1318769  Function: 255
> POCSAG2400-: Alpha: KA^MA
> POCSAG1200-: Address: 1700218  Function: 255
> POCSAG1200-: Alpha: )"<DLE>'f
> POCSAG1200-: Address:  143961  Function: 255
>
>
> I rolled back to an earlier version using git checkout commit and it
> appears the following commit broke it:
> c4fcfbb46e0a432902a2b78db4951bd20f68b9b2
>
> Commit 8c3a99c8f7a88d7d2a05845d4b20cfcdacac4054 works fine, whereas
> the commit after causes multimon_ng to spit out garbage :-(
>



From thunder.m at email.cz  Mon Sep 16 09:38:18 2013
From: thunder.m at email.cz (=?UTF-8?B?TWlyb3NsYXYgU2x1Z2XFiA==?=)
Date: Mon, 16 Sep 2013 11:38:18 +0200
Subject: Complex FIR and Stereo support for rtl_fm
In-Reply-To: <5236D10C.5040009@gmail.com>
References: <523311A0.3030900@email.cz> <5236D10C.5040009@gmail.com>
Message-ID: <5236D18A.2090706@email.cz>

Hi, i used git from 14.9.2013, if you get errors from actual git it 
could be because some functions might go into upstream, i also add as 
attachment just rtl_fm.c so just replace it your version with this 
version and it should work.

I have RDS decoder also, but it is very ugly and not all issues are solved.

Miroslav Sluge?
+420 724 825 885

Micha? Mora?ski napsal(a):
> W dniu 2013-09-13 15:22, Miroslav Sluge? pisze:
>> Hi again,
>>
>> I am working on my own SDR project for Stereo FM radio support, but i
>> would like to also improve quality for rtl_fm application, i made
>> unoficial patch to add:
>>
>> Complex FIR - to filter strong signals close to wanted signal
>> Real FIR - to filter pilot from FM
>> Stereo FIR
>> Stereo Deemphasis
>> AGC support - it can give better resolution of IQ data
>>
>> Some other improvments in FM radio code.
>>
>> All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts,
>> of course SSE is the fastest one and it should works on Intel Atoms,
>> but not on ARM.
>>
>> Feel free to use any part of code in any of you programs, I know that
>> this code is little to much to add it into rtl_fm, but maybe it could
>> somebody help to recieve HW stereo FM radio.
>>
>> Speed of SSE code is much better than anything you can get around
>> here, on Core i7 it consume only 5% of one CPU, so i could demodulate
>> at least 80 channels at the same time in stereo quality of course.
>>
>> I tried this code only on AMD64 and GCC Linux, so i am not sure if it
>> can be compiled under windows.
>>
> Hi! Very nice to hear, that someone working on Stereo FM reception. I'm
> building a small remote devices with rtl-dongles as fm stereo receivers.
> Now i'm using gnu-radio to decode fm-stereo, but as you all know,
> gnu-radio is a large and heavy project and it's wasting its
> capatibilities in that role.
> It would be very nice if native rtl-sdr software can decode fm-stereo.
>
> Which version of rtl-sdr was used as base version? I'm getting errors
> after applying the patch to last version:
>
> patching file rtl_fm.c
> Hunk #2 succeeded at 47 (offset 5 lines).
> Hunk #3 succeeded at 87 (offset 9 lines).
> Hunk #4 succeeded at 144 (offset 9 lines).
> Hunk #5 succeeded at 169 (offset 9 lines).
> Hunk #6 succeeded at 190 (offset 9 lines).
> Hunk #7 FAILED at 239.
> Hunk #8 FAILED at 258.
> Hunk #9 succeeded at 314 (offset 13 lines).
> Hunk #10 succeeded at 420 (offset 13 lines).
> Hunk #11 succeeded at 994 (offset 13 lines).
> Hunk #12 FAILED at 1106.
> Hunk #13 succeeded at 1148 (offset 15 lines).
> Hunk #14 succeeded at 1259 (offset 35 lines).
> Hunk #15 succeeded at 1268 (offset 35 lines).
> Hunk #16 succeeded at 1290 (offset 35 lines).
> Hunk #17 succeeded at 1301 with fuzz 2 (offset 36 lines).
> Hunk #18 succeeded at 1351 (offset 38 lines).
> Hunk #19 succeeded at 1378 (offset 38 lines).
> Hunk #20 succeeded at 1389 (offset 38 lines).
> Hunk #21 succeeded at 1508 (offset 50 lines).
> Hunk #22 succeeded at 1527 (offset 50 lines).
> 3 out of 22 hunks FAILED -- saving rejects to file rtl_fm.c.rej
>
> P.S. Are you planning to add support for RDS in the future?
>
> Regards, Micha?.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl_fm.c
Type: text/x-csrc
Size: 48703 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130916/6aee5898/attachment.bin>

From thunder.m at email.cz  Mon Sep 16 09:50:49 2013
From: thunder.m at email.cz (=?UTF-8?B?TWlyb3NsYXYgU2x1Z2XFiA==?=)
Date: Mon, 16 Sep 2013 11:50:49 +0200
Subject: Complex FIR and Stereo support for rtl_fm
In-Reply-To: <5236D18A.2090706@email.cz>
References: <523311A0.3030900@email.cz> <5236D10C.5040009@gmail.com>
	<5236D18A.2090706@email.cz>
Message-ID: <5236D479.6090507@email.cz>

I also forget to add that you can now use:

-W for FM radio in USA (deemphasis 75us)
-X for FM radio in other countries (deemphasis 50us)

This mode is designed for 48kHz reception, i know it is not necessary 
(fm radio has only 16kHz, so 32kHz shouhld be enough), but it is because 
of good multiplications, othervise we have to use complicated resampler.

Usage for FM reception will be now:
rtl_fm -X -f 97400000 - | aplay -r 48k -f S16_LE -t raw -c 2

Mirek

Miroslav Sluge? napsal(a):
> Hi, i used git from 14.9.2013, if you get errors from actual git it
> could be because some functions might go into upstream, i also add as
> attachment just rtl_fm.c so just replace it your version with this
> version and it should work.
>
> I have RDS decoder also, but it is very ugly and not all issues are solved.
>
> Miroslav Sluge?
> +420 724 825 885
>
> Micha? Mora?ski napsal(a):
>> W dniu 2013-09-13 15:22, Miroslav Sluge? pisze:
>>> Hi again,
>>>
>>> I am working on my own SDR project for Stereo FM radio support, but i
>>> would like to also improve quality for rtl_fm application, i made
>>> unoficial patch to add:
>>>
>>> Complex FIR - to filter strong signals close to wanted signal
>>> Real FIR - to filter pilot from FM
>>> Stereo FIR
>>> Stereo Deemphasis
>>> AGC support - it can give better resolution of IQ data
>>>
>>> Some other improvments in FM radio code.
>>>
>>> All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts,
>>> of course SSE is the fastest one and it should works on Intel Atoms,
>>> but not on ARM.
>>>
>>> Feel free to use any part of code in any of you programs, I know that
>>> this code is little to much to add it into rtl_fm, but maybe it could
>>> somebody help to recieve HW stereo FM radio.
>>>
>>> Speed of SSE code is much better than anything you can get around
>>> here, on Core i7 it consume only 5% of one CPU, so i could demodulate
>>> at least 80 channels at the same time in stereo quality of course.
>>>
>>> I tried this code only on AMD64 and GCC Linux, so i am not sure if it
>>> can be compiled under windows.
>>>
>> Hi! Very nice to hear, that someone working on Stereo FM reception. I'm
>> building a small remote devices with rtl-dongles as fm stereo receivers.
>> Now i'm using gnu-radio to decode fm-stereo, but as you all know,
>> gnu-radio is a large and heavy project and it's wasting its
>> capatibilities in that role.
>> It would be very nice if native rtl-sdr software can decode fm-stereo.
>>
>> Which version of rtl-sdr was used as base version? I'm getting errors
>> after applying the patch to last version:
>>
>> patching file rtl_fm.c
>> Hunk #2 succeeded at 47 (offset 5 lines).
>> Hunk #3 succeeded at 87 (offset 9 lines).
>> Hunk #4 succeeded at 144 (offset 9 lines).
>> Hunk #5 succeeded at 169 (offset 9 lines).
>> Hunk #6 succeeded at 190 (offset 9 lines).
>> Hunk #7 FAILED at 239.
>> Hunk #8 FAILED at 258.
>> Hunk #9 succeeded at 314 (offset 13 lines).
>> Hunk #10 succeeded at 420 (offset 13 lines).
>> Hunk #11 succeeded at 994 (offset 13 lines).
>> Hunk #12 FAILED at 1106.
>> Hunk #13 succeeded at 1148 (offset 15 lines).
>> Hunk #14 succeeded at 1259 (offset 35 lines).
>> Hunk #15 succeeded at 1268 (offset 35 lines).
>> Hunk #16 succeeded at 1290 (offset 35 lines).
>> Hunk #17 succeeded at 1301 with fuzz 2 (offset 36 lines).
>> Hunk #18 succeeded at 1351 (offset 38 lines).
>> Hunk #19 succeeded at 1378 (offset 38 lines).
>> Hunk #20 succeeded at 1389 (offset 38 lines).
>> Hunk #21 succeeded at 1508 (offset 50 lines).
>> Hunk #22 succeeded at 1527 (offset 50 lines).
>> 3 out of 22 hunks FAILED -- saving rejects to file rtl_fm.c.rej
>>
>> P.S. Are you planning to add support for RDS in the future?
>>
>> Regards, Micha?.
>>
>>



From thunder.m at email.cz  Mon Sep 16 13:05:13 2013
From: thunder.m at email.cz (=?UTF-8?B?TWlyb3NsYXYgU2x1Z2XFiA==?=)
Date: Mon, 16 Sep 2013 15:05:13 +0200
Subject: Complex FIR and Stereo support for rtl_fm
In-Reply-To: <5236F4FB.2040809@gmail.com>
References: <523311A0.3030900@email.cz> <5236D10C.5040009@gmail.com>
	<5236D18A.2090706@email.cz> <5236F4FB.2040809@gmail.com>
Message-ID: <52370209.4040701@email.cz>

Thanks for testing, is it 32bit arch?

All memory buffers used in SSE should be 16bit aligned, please try no 
SSE version:

rtl_fm -X -F 2 -J 5 -f yourfreq

Also you can try modified rtl_fm version i send as attachment which use 
memalign to allocate buffers instead of malloc, but it is only for gcc.

On X86_64 platform all malloc are 16bit aligned so i missed this.

Those errors when compiling are not important, but also in SSE part.

Miroslav Sluge?
+420 724 825 885

Micha? Mora?ski napsal(a):
> W dniu 2013-09-16 11:38, Miroslav Sluge? pisze:
>> Hi, i used git from 14.9.2013, if you get errors from actual git it
>> could be because some functions might go into upstream, i also add as
>> attachment just rtl_fm.c so just replace it your version with this
>> version and it should work.
> Thanks for rapid answer. I just compiled your code.
> First, i got this message when compiling:
> /usr/lib/gcc/i486-linux-gnu/4.4.3/include/emmintrin.h:32:3: error:
> #error "SSE2 instruction set not enabled"
> Then i've added line to CMakeLists.txt:
> set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} "-msse -msse2 -msse3")
> After that i was able to compile the code, but with some warnings:
>
> /usr/src/rtl-sdr/src/rtl_fm.c: In function ?low_pass_complex?:
> /usr/src/rtl-sdr/src/rtl_fm.c:451: warning: dereferencing pointer ?v_r?
> does break strict-aliasing rules
> /usr/src/rtl-sdr/src/rtl_fm.c:436: note: initialized from here
> /usr/src/rtl-sdr/src/rtl_fm.c:452: warning: dereferencing pointer ?v_i?
> does break strict-aliasing rules
> /usr/src/rtl-sdr/src/rtl_fm.c:436: note: initialized from here
> /usr/src/rtl-sdr/src/rtl_fm.c: In function ?low_pass_real?:
> /usr/src/rtl-sdr/src/rtl_fm.c:769: warning: dereferencing pointer ?v_m?
> does break strict-aliasing rules
> /usr/src/rtl-sdr/src/rtl_fm.c:755: note: initialized from here
> /usr/src/rtl-sdr/src/rtl_fm.c:850: warning: dereferencing pointer ?v_m?
> does break strict-aliasing rules
> /usr/src/rtl-sdr/src/rtl_fm.c:872: warning: dereferencing pointer ?v_m?
> does break strict-aliasing rules
> /usr/src/rtl-sdr/src/rtl_fm.c:834: note: initialized from here
> /usr/src/rtl-sdr/src/rtl_fm.c:851: warning: dereferencing pointer ?v_p?
> does break strict-aliasing rules
> /usr/src/rtl-sdr/src/rtl_fm.c:834: note: initialized from here
> /usr/src/rtl-sdr/src/rtl_fm.c:852: warning: dereferencing pointer ?v_s?
> does break strict-aliasing rules
> /usr/src/rtl-sdr/src/rtl_fm.c:873: warning: dereferencing pointer ?v_s?
> does break strict-aliasing rules
>
> Now i got segfaults when i try to run rtl_fm -X -f 90.4e6 :
> root at dabplus:/usr/src/rtl-sdr# rtl_fm -X -f 90.4e6 -
> Found 1 device(s):
> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>
> Using device 0: Lifeview LV5TDeluxe
> Found Fitipower FC0013 tuner
> Oversampling input by: 6x.
> Oversampling output by: 1x.
> Buffer size: 7.11ms
> Tuned to 90704000 Hz.
> Sampling at 1152000 Hz.
> Output at 48000 Hz.
> LP Complex: FIR hamming (SSE2), size: 32
> LP Real: FIR hamming stereo (SSE2), size: 64
> Tuner gain set to automatic.
> Tuner AGC ON.
> De-epmhasis IIR: 50.0 us
> Segmentation fault
>
> My processor:
> root at dabplus:/usr/src/rtl-sdr# cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 28
> model name : Intel(R) Atom(TM) CPU D525 @ 1.80GHz
> .....
> root at dabplus:/usr/src/rtl-sdr# cat /etc/issue
> Ubuntu 10.04.4 LTS \n \l
>
> root at dabplus:/usr/src/rtl-sdr# uname -r
> 2.6.32-38-generic-pae
>
>
>
>>
>> I have RDS decoder also, but it is very ugly and not all issues are
>> solved.
> Wow :) If you searching for help with that you can count on me.
>
>>
>> Miroslav Sluge?
>> +420 724 825 885
>>
>> Micha? Mora?ski napsal(a):
>>> W dniu 2013-09-13 15:22, Miroslav Sluge? pisze:
>>>> Hi again,
>>>>
>>>> I am working on my own SDR project for Stereo FM radio support, but i
>>>> would like to also improve quality for rtl_fm application, i made
>>>> unoficial patch to add:
>>>>
>>>> Complex FIR - to filter strong signals close to wanted signal
>>>> Real FIR - to filter pilot from FM
>>>> Stereo FIR
>>>> Stereo Deemphasis
>>>> AGC support - it can give better resolution of IQ data
>>>>
>>>> Some other improvments in FM radio code.
>>>>
>>>> All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts,
>>>> of course SSE is the fastest one and it should works on Intel Atoms,
>>>> but not on ARM.
>>>>
>>>> Feel free to use any part of code in any of you programs, I know that
>>>> this code is little to much to add it into rtl_fm, but maybe it could
>>>> somebody help to recieve HW stereo FM radio.
>>>>
>>>> Speed of SSE code is much better than anything you can get around
>>>> here, on Core i7 it consume only 5% of one CPU, so i could demodulate
>>>> at least 80 channels at the same time in stereo quality of course.
>>>>
>>>> I tried this code only on AMD64 and GCC Linux, so i am not sure if it
>>>> can be compiled under windows.
>>>>
>>> Hi! Very nice to hear, that someone working on Stereo FM reception. I'm
>>> building a small remote devices with rtl-dongles as fm stereo receivers.
>>> Now i'm using gnu-radio to decode fm-stereo, but as you all know,
>>> gnu-radio is a large and heavy project and it's wasting its
>>> capatibilities in that role.
>>> It would be very nice if native rtl-sdr software can decode fm-stereo.
>>>
>>> Which version of rtl-sdr was used as base version? I'm getting errors
>>> after applying the patch to last version:
>>>
>>> patching file rtl_fm.c
>>> Hunk #2 succeeded at 47 (offset 5 lines).
>>> Hunk #3 succeeded at 87 (offset 9 lines).
>>> Hunk #4 succeeded at 144 (offset 9 lines).
>>> Hunk #5 succeeded at 169 (offset 9 lines).
>>> Hunk #6 succeeded at 190 (offset 9 lines).
>>> Hunk #7 FAILED at 239.
>>> Hunk #8 FAILED at 258.
>>> Hunk #9 succeeded at 314 (offset 13 lines).
>>> Hunk #10 succeeded at 420 (offset 13 lines).
>>> Hunk #11 succeeded at 994 (offset 13 lines).
>>> Hunk #12 FAILED at 1106.
>>> Hunk #13 succeeded at 1148 (offset 15 lines).
>>> Hunk #14 succeeded at 1259 (offset 35 lines).
>>> Hunk #15 succeeded at 1268 (offset 35 lines).
>>> Hunk #16 succeeded at 1290 (offset 35 lines).
>>> Hunk #17 succeeded at 1301 with fuzz 2 (offset 36 lines).
>>> Hunk #18 succeeded at 1351 (offset 38 lines).
>>> Hunk #19 succeeded at 1378 (offset 38 lines).
>>> Hunk #20 succeeded at 1389 (offset 38 lines).
>>> Hunk #21 succeeded at 1508 (offset 50 lines).
>>> Hunk #22 succeeded at 1527 (offset 50 lines).
>>> 3 out of 22 hunks FAILED -- saving rejects to file rtl_fm.c.rej
>>>
>>> P.S. Are you planning to add support for RDS in the future?
>>>
>>> Regards, Micha?.
>>>
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl_fm.c
Type: text/x-csrc
Size: 48789 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130916/63d11836/attachment.bin>

From jm.polard at kermaz.com  Thu Sep 19 06:38:22 2013
From: jm.polard at kermaz.com (Jean Marie POLARD)
Date: Thu, 19 Sep 2013 08:38:22 +0200
Subject: rtl-sdr offset tuning and other questions
In-Reply-To: <op.wxb2dilwvay7ep@wopr.artelis.net>
References: <op.wxb2dilwvay7ep@wopr.artelis.net>
Message-ID: <523A9BDE.6000404@kermaz.com>


-- 
Hello to all, I am interested to decode the VOR signals. If anyone has a 
trick I will be pleased to exchange emails.

thanks and best regards





Jean Marie POLARD
F5VLB
1, Boutil
22540 Louargat (France)

IN88IN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130919/81f93daa/attachment.htm>

From sylvain.azarian at gmail.com  Thu Sep 19 13:10:09 2013
From: sylvain.azarian at gmail.com (Sylvain AZARIAN)
Date: Thu, 19 Sep 2013 15:10:09 +0200
Subject: rtl-sdr offset tuning and other questions
In-Reply-To: <523A9BDE.6000404@kermaz.com>
References: <op.wxb2dilwvay7ep@wopr.artelis.net> <523A9BDE.6000404@kermaz.com>
Message-ID: <CAHZVKw2j=1zeWL9iJD4vK0UR6oQUEc_9K1a9sMuC86E0soignQ@mail.gmail.com>

Jean-Marie, group (and french readers)

Please find attached to this email a report from a student explaining how
to decode the VOR signals

regards
sylvain F4GKR


2013/9/19 Jean Marie POLARD <jm.polard at kermaz.com>

>
> --
> Hello to all, I am interested to decode the VOR signals. If anyone has a
> trick I will be pleased to exchange emails.
>
> thanks and best regards
>
>
>
>
>
> Jean Marie POLARD
> F5VLB
> 1, Boutil
> 22540 Louargat (France)
>
> IN88IN
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130919/2407a458/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vor_dsp.pdf
Type: application/pdf
Size: 256568 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130919/2407a458/attachment.pdf>

From olof.tangrot at gmail.com  Thu Sep 19 14:09:12 2013
From: olof.tangrot at gmail.com (Olof Tangrot)
Date: Thu, 19 Sep 2013 16:09:12 +0200
Subject: rtl_fm and multimon-ng issues
In-Reply-To: <CAGCfTUhwkfhQrpu9kGdYeYQHisFbzaMWEprvrMz_vtLCO9V=Dw@mail.gmail.com>
References: <CAGCfTUhSdOF8Gswi0XwNeVSeKpDO2EWPoEjugEgUayHFhR54Rg@mail.gmail.com>
	<CAG0+6kmyyN58VcNs+gk9n0PiysvcWZ7yROMbupzsZG8NM8jYqQ@mail.gmail.com>
	<CAGCfTUhwkfhQrpu9kGdYeYQHisFbzaMWEprvrMz_vtLCO9V=Dw@mail.gmail.com>
Message-ID: <CAG0+6kka1VH0JyCOAdqaNDfOFuzeooxT9xTYUjLr+gThzpf+qg@mail.gmail.com>

Ok, what kind of excuse can I make up for such a stupid reply?

Anyway, I read in some blog post about DC-offset issues when piping data
between mulitimon and rtl_fm. The author claimed to fix the problem by
adding a pole-zero filter inbetween. So it a surpirse to read about using
the programs without removing DC.

Could the new version of rtl_fm apply some offset that previously was not
preset?

It might be possible for you to compare the outputs to get a better
understaning of why your commande pipeline hase ceased to work.

Olof


2013/9/16 Ewan Meadows <ewan.meadows at gmail.com>

> The problem is with the recent changes to rtl_fm, as I can roll back
> to the commit before scanning was fixed and it works fine.
>
> On 16 September 2013 17:43, Olof Tangrot <olof.tangrot at gmail.com> wrote:
> > I am not sure this is the right list for bug reports for multimon-ng.
> There
> > is a tracker on github where it is possible submit issues though.
> >
> > Hi all,
> >
> > I've been using rtl_fm piped into multimon-ng for a while now which
> > has been working pretty well for decoding POCSAG, I use this command
> > line:
> > rtl_fm -f 153.350M -r 22050 - | ./multimon-ng -t raw -a POCSAG512 -a
> > POCSAG1200 -a POCSAG2400 -f alpha -D pocsag.db -
> >
> > I updated rtl_sdr today and now all I get is junk decodes
> > POCSAG2400-: Address: 1318769  Function: 255
> > POCSAG2400-: Alpha: KA^MA
> > POCSAG1200-: Address: 1700218  Function: 255
> > POCSAG1200-: Alpha: )"<DLE>'f
> > POCSAG1200-: Address:  143961  Function: 255
> >
> >
> > I rolled back to an earlier version using git checkout commit and it
> > appears the following commit broke it:
> > c4fcfbb46e0a432902a2b78db4951bd20f68b9b2
> >
> > Commit 8c3a99c8f7a88d7d2a05845d4b20cfcdacac4054 works fine, whereas
> > the commit after causes multimon_ng to spit out garbage :-(
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130919/80cc65c1/attachment.htm>

From gisle.vanem at gmail.com  Thu Sep 19 15:56:48 2013
From: gisle.vanem at gmail.com (Gisle Vanem)
Date: Thu, 19 Sep 2013 17:56:48 +0200
Subject: LIBUSB_ERROR_PIPE?
Message-ID: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>

Since my last Windows Update (not sure that's the cause), I'm having 
a hell to regain access to my Terratec DVB-Tstick with ther Elonics E4000
tuner. I've modified librtlsrc.c to include some more traces and relinked rtl_test 
with it. All I'm getting is LIBUSB_ERROR_PIPE trying to read/write the I2C-bus:

Osmocom-SDR\src\rtl_test.exe
Found 1 device(s):
  0:  Terratec T Stick PLUS

Using device 0: Terratec T Stick PLUS
librtlsdr.c(392): I2C addr C8: got 00, rd_len: -9, wr_len: -9
librtlsdr.c(394): Read error: LIBUSB_ERROR_PIPE, Pipe error
librtlsdr.c(396): Write error: LIBUSB_ERROR_PIPE, Pipe error
librtlsdr.c(392): I2C addr C6: got 00, rd_len: -9, wr_len: -9
...
No supported tuner found
Enabled direct sampling mode, input 1
Supported gain values (1): 0.0

----------------

What could be the reason for this? What else should I try?

--gv



From jsalsburg at bellsouth.net  Thu Sep 19 17:20:53 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Thu, 19 Sep 2013 12:20:53 -0500
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>

I just received a Product Announcement from SILICON LABS. There new TV Tuner Chip, the Si2177, appears to be able to demodulate Analog TV directly on the chip without software. If I am not mistaken, this function is a new feature in TV Tuner Chips, which may provide a much better SDR than current TV Tuner Chip Dongles, especially when it comes to noise performance. It also eliminates almost all external components. RF Input Frequency Range - 42 to 870 MHz

Si2177 5th Generation Silicon TV Tuner ICs

http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2177-short.pdf





From sylvain.azarian at gmail.com  Thu Sep 19 17:35:25 2013
From: sylvain.azarian at gmail.com (Sylvain AZARIAN)
Date: Thu, 19 Sep 2013 19:35:25 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
Message-ID: <CAHZVKw05_Ws-YiOfjb3d4rCWb5XNcL8UjRgOLzfJHXX2me4Bhg@mail.gmail.com>

It seems the chip does not output the raw I and Q values... It means there
is nothing to do with it except watching tv, exactly the converse of
existing tuners ;-)

regards
sylvain


2013/9/19 Jay Salsburg <jsalsburg at bellsouth.net>

> I just received a Product Announcement from SILICON LABS. There new TV
> Tuner Chip, the Si2177, appears to be able to demodulate Analog TV directly
> on the chip without software. If I am not mistaken, this function is a new
> feature in TV Tuner Chips, which may provide a much better SDR than current
> TV Tuner Chip Dongles, especially when it comes to noise performance. It
> also eliminates almost all external components. RF Input Frequency Range -
> 42 to 870 MHz
>
> Si2177 5th Generation Silicon TV Tuner ICs
>
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2177-short.pdf
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130919/17b8b5d2/attachment.htm>

From 246tnt at gmail.com  Thu Sep 19 19:18:44 2013
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 19 Sep 2013 21:18:44 +0200
Subject: gr-iqbalance documentation build problem
In-Reply-To: <sig.2929a0791f.20130806011444.600yhyvj9cwow44k@www.ire.pw.edu.pl>
References: <sig.2929a0791f.20130806011444.600yhyvj9cwow44k@www.ire.pw.edu.pl>
Message-ID: <CAHL+j09yv7ogomu9eEAQF00OmGF2S=FF5skG7TcdNeca5NX2sg@mail.gmail.com>

Damnit, sorry this patch slipped my mind. Now applied.

On Tue, Aug 6, 2013 at 1:14 AM,  <wk at ire.pw.edu.pl> wrote:
> Hello.
> I have some build problem with building gr-igbalance with documentation
> enabled. Build fails with a message saying that shell interpreter can't
> execute Doxyfile. It is the same as I noticed some time ago while
> building gr-osmosdr (see
> http://lists.osmocom.org/pipermail/osmocom-sdr/2013-April/000553.html
> ). It was solved by the patch by Jaroslav ?karvada (
> http://cgit.osmocom.org/gr-osmosdr/commit/?id=2f6592566bd60d2539f5b976dcf6119876a0e0
> ).
>
> Similar patch, attached, help for gr-iqbalance. It moves doxygen
> detection test to toplevel CMakeLists.txt. Please add it to git
> repository.
>
> Wojciech Kazubski
>
>



From citizenr at gmail.com  Fri Sep 20 01:21:31 2013
From: citizenr at gmail.com (Rasz)
Date: Fri, 20 Sep 2013 03:21:31 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
Message-ID: <CAH1afDvj1ToZiY4EXL_=6hfywpXzZhp5MQjkrTvYbaUpOoSX+Q@mail.gmail.com>

On 9/19/13, Jay Salsburg <jsalsburg at bellsouth.net> wrote:
> demodulate Analog TV directly on the chip without software.

this is a bad thing

-- 
Who logs in to gdm? Not I, said the duck.



From jsalsburg at bellsouth.net  Fri Sep 20 18:05:46 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Fri, 20 Sep 2013 13:05:46 -0500
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>

OK, for those who do not grasp the principle of On-chip Demodulation, SILICON LABS is manufacturing a spectrum of advanced Tuners, one of which may suit the mindset of those who buck the idea of a Demodulator on chip. There is one that demodulates Analog TV alone, one that demodulates Digital TV alone, and one that does both. Ask yourself this question... Why is there an A/D converter chip on the current Tuner Dongles? Would it not be better to convert the unadulterated demodulated Digital stream directly into a 192k/24bit audio card (or just 48k/16bit)? This new capability tells my Engineering mind that the noise floor would go way down, which is the main deficiency with the current cheap TV Tuner Dongles, keeping them from being used for low level narrowband reception.

http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2157-short.pdf


-----Original Message-----
From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Jay Salsburg
Sent: Thursday, September 19, 2013 12:21 PM
To: osmocom-sdr at lists.osmocom.org
Subject: new TV Tuner Chip, the Si2177

I just received a Product Announcement from SILICON LABS. There new TV Tuner Chip, the Si2177, appears to be able to demodulate Analog TV directly on the chip without software. If I am not mistaken, this function is a new feature in TV Tuner Chips, which may provide a much better SDR than current TV Tuner Chip Dongles, especially when it comes to noise performance. It also eliminates almost all external components. RF Input Frequency Range - 42 to 870 MHz

Si2177 5th Generation Silicon TV Tuner ICs

http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2177-short.pdf



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6680 - Release Date: 09/19/13




From citizenr at gmail.com  Fri Sep 20 21:50:38 2013
From: citizenr at gmail.com (Rasz)
Date: Fri, 20 Sep 2013 23:50:38 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
Message-ID: <CAH1afDuKdc0z6fUi8Wnmoi7sY6RoNm97qXTrA2aMQkPV0uZ6bg@mail.gmail.com>

On 9/20/13, Jay Salsburg <jsalsburg at bellsouth.net> wrote:
> OK, for those who do not grasp the principle of On-chip Demodulation,

other way around

> There is one that demodulates Analog TV alone, one that demodulates Digital
> TV alone, and one that does both.

RF --> black box --> video pixels

while we want

RF --> A/D --> data stream
or fancy
RF --> A/D --> DSP --> data stream

> Ask yourself this question... Why is there
> an A/D converter chip on the current Tuner Dongles?

because we forgot how to do magic

> Would it not be better
> to convert the unadulterated

umm what?

> demodulated

demodulated by what? from what modulation? this is what SDR is about
(flexibility)

> Digital stream directly into a 192k/24bit audio card (or just 48k/16bit)?

why would you want to analog sample digital stream?


> This new capability tells my
> Engineering mind

no

-- 
Who logs in to gdm? Not I, said the duck.



From leif at sm5bsz.com  Sat Sep 21 00:43:14 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Sat, 21 Sep 2013 02:43:14 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
Message-ID: <20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>

The bandwidth of the I/Q pair is too large to be transmitted 
over USB for the reception of TV signals. After demodulation
the bandwidth is lower so it would (marginally) fit an USB 
interface if we talk about traditional analogue TV. For digital
TV the bandwidth reduction by the decoder is much larger.

I would not be surprised if the Si Labs chips have an option to
send unprocessed I/Q data to the USB. Somebody should approach them
and ask:-)

73

Leif / SM5BSZ


> OK, for those who do not grasp the principle of On-chip Demodulation, SILICON LABS is manufacturing a spectrum of advanced Tuners, one of which may suit the mindset of those who buck the idea of a Demodulator on chip. There is one that demodulates Analog TV alone, one that demodulates Digital TV alone, and one that does both. Ask yourself this question... Why is there an A/D converter chip on the current Tuner Dongles? Would it not be better to convert the unadulterated demodulated Digital stream directly into a 192k/24bit audio card (or just 48k/16bit)? This new capability tells my Engineering mind that the noise floor would go way down, which is the main deficiency with the current cheap TV Tuner Dongles, keeping them from being used for low level narrowband reception.
> 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2157-short.pdf
> 
> 
> -----Original Message-----
> From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Jay Salsburg
> Sent: Thursday, September 19, 2013 12:21 PM
> To: osmocom-sdr at lists.osmocom.org
> Subject: new TV Tuner Chip, the Si2177
> 
> I just received a Product Announcement from SILICON LABS. There new TV Tuner Chip, the Si2177, appears to be able to demodulate Analog TV directly on the chip without software. If I am not mistaken, this function is a new feature in TV Tuner Chips, which may provide a much better SDR than current TV Tuner Chip Dongles, especially when it comes to noise performance. It also eliminates almost all external components. RF Input Frequency Range - 42 to 870 MHz
> 
> Si2177 5th Generation Silicon TV Tuner ICs
> 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2177-short.pdf
> 
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3408 / Virus Database: 3222/6680 - Release Date: 09/19/13
> 
> 



From zaitcev at kotori.zaitcev.us  Sat Sep 21 05:17:12 2013
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Fri, 20 Sep 2013 23:17:12 -0600
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
Message-ID: <20130920231712.713ecf29@lembas.zaitcev.lan>

On Sat, 21 Sep 2013 02:43:14 +0200
Leif Asbrink <leif at sm5bsz.com> wrote:

> The bandwidth of the I/Q pair is too large to be transmitted 
> over USB for the reception of TV signals. After demodulation
> the bandwidth is lower so it would (marginally) fit an USB 
> interface if we talk about traditional analogue TV. For digital
> TV the bandwidth reduction by the decoder is much larger.

How much is actually needed? You know there's USB 3 these days,
which can transmit about a megabit with some change (due to
overhead).

-- Pete



From a.nielsen at shikadi.net  Sat Sep 21 07:11:54 2013
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Sat, 21 Sep 2013 17:11:54 +1000
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130920231712.713ecf29@lembas.zaitcev.lan>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
Message-ID: <20130921171154.21e3eaa1@korath.teln.shikadi.net>

> > The bandwidth of the I/Q pair is too large to be transmitted 
> > over USB for the reception of TV signals. After demodulation
> > the bandwidth is lower so it would (marginally) fit an USB 
> > interface if we talk about traditional analogue TV. For digital
> > TV the bandwidth reduction by the decoder is much larger.

Is that correct?  From what I can find, an analogue TV signal has a
bandwidth of around 6-8MHz.  The HackRF is an SDR that works over
USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
should be ample for one analogue (or even digital) TV signal, perhaps
even two if the channels are close enough together.

> How much is actually needed? You know there's USB 3 these days,
> which can transmit about a megabit with some change (due to
> overhead).

A megabit? :-)  USB3.0 has a signalling rate of 5Gbps and according to
Wikipedia, a usable data rate of up to 4Gbps.  If you can fit 20MHz of
RF over USB2.0 at 480Mbps, you should be able to start approaching
200MHz of bandwidth with a USB3.0 SDR!

Cheers,
Adam.



From sdrguru1 at gmail.com  Sat Sep 21 07:37:12 2013
From: sdrguru1 at gmail.com (Sdr Guru)
Date: Sat, 21 Sep 2013 10:37:12 +0300
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
Message-ID: <CACR-secNQQ2bGo1Y_rhuA5zX9pTYw6L+xD6UyVkyFRGQPG1EdQ@mail.gmail.com>

On Sat, Sep 21, 2013 at 3:43 AM, Leif Asbrink <leif at sm5bsz.com> wrote:

> The bandwidth of the I/Q pair is too large to be transmitted
> over USB for the reception of TV signals.


This is not quite correct claim.
See Mirics MSi3101 chipset for example.

SG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130921/4c3d945c/attachment.htm>

From citizenr at gmail.com  Sat Sep 21 15:39:34 2013
From: citizenr at gmail.com (Rasz)
Date: Sat, 21 Sep 2013 17:39:34 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921171154.21e3eaa1@korath.teln.shikadi.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
Message-ID: <CAH1afDvKSnE8S_6PKYj2vwbysbLKHVq1DSdS67+tU+nKztPnkQ@mail.gmail.com>

On 9/21/13, Adam Nielsen <a.nielsen at shikadi.net> wrote:
> From what I can find, an analogue TV signal has a
> bandwidth of around 6-8MHz.  The HackRF is an SDR that works over
> USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
> should be ample for one analogue (or even digital) TV signal, perhaps
> even two if the channels are close enough together.

USB 2.0 has no problem with 30MB/s, and if you take care of all the
quirks (only 1 device, no programs running, "turbo mode" aka >1MB bulk
transfers) you can go up to ~40MB/s

>> How much is actually needed? You know there's USB 3 these days,
>> which can transmit about a megabit with some change (due to
>> overhead).
>
> A megabit? :-)  USB3.0 has a signalling rate of 5Gbps and according to
> Wikipedia, a usable data rate of up to 4Gbps.  If you can fit 20MHz of
> RF over USB2.0 at 480Mbps, you should be able to start approaching
> 200MHz of bandwidth with a USB3.0 SDR!

Cypress FX3 does 360MB/s in real life.


-- 
Who logs in to gdm? Not I, said the duck.



From jsalsburg at bellsouth.net  Sat Sep 21 16:12:05 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Sat, 21 Sep 2013 11:12:05 -0500
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAIWMjbhllZNPvhjuj6tiPcQBAAAAAA==@bellsouth.net>

Digital TV reception is the target App for these new Tuner Chips, the target
platform is the Smart Phone. If you read the Preliminary Datasheet, SILICON
LABS conspicuously mentions their new Tuner exhibits immunity to
interference from Wi-Fi and LTE. Since Smart Phone and Tablet technology is
accelerating at WARP speed with a Moore Iteration every few months (not 18
months like he envisioned), it is logical that Technology Convergence in
Smart Phones is not over, designers will probably put TV Receivers in Smart
Phones and Tablets, and LTE in Set Top Boxes and TVs.

I remember, in the 1980s SILICON LABS was the first to produce Multi Op-Amp
DIPs, I still have some of them in my Chip Stash. If Memory serves me, their
designation was L144.

I apologize for substituting terms in the previous messages, it did get some
of you going. Not since I was a Wafer Fab Engineer at Western Digital has
that annoying practice gotten me in trouble when I openly referred to my
Employer as Western Vegetable.

-----Original Message-----
From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink
Sent: Friday, September 20, 2013 7:43 PM
To: osmocom-sdr at lists.osmocom.org
Subject: Re: new TV Tuner Chip, the Si2177

The bandwidth of the I/Q pair is too large to be transmitted over USB for
the reception of TV signals. After demodulation the bandwidth is lower so it
would (marginally) fit an USB interface if we talk about traditional
analogue TV. For digital TV the bandwidth reduction by the decoder is much
larger.

I would not be surprised if the Si Labs chips have an option to send
unprocessed I/Q data to the USB. Somebody should approach them and ask:-)

73

Leif / SM5BSZ


> OK, for those who do not grasp the principle of On-chip Demodulation,
SILICON LABS is manufacturing a spectrum of advanced Tuners, one of which
may suit the mindset of those who buck the idea of a Demodulator on chip.
There is one that demodulates Analog TV alone, one that demodulates Digital
TV alone, and one that does both. Ask yourself this question... Why is there
an A/D converter chip on the current Tuner Dongles? Would it not be better
to convert the unadulterated demodulated Digital stream directly into a
192k/24bit audio card (or just 48k/16bit)? This new capability tells my
Engineering mind that the noise floor would go way down, which is the main
deficiency with the current cheap TV Tuner Dongles, keeping them from being
used for low level narrowband reception.
> 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2157-short.p
> df
> 
> 
> -----Original Message-----
> From: osmocom-sdr-bounces at lists.osmocom.org 
> [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Jay 
> Salsburg
> Sent: Thursday, September 19, 2013 12:21 PM
> To: osmocom-sdr at lists.osmocom.org
> Subject: new TV Tuner Chip, the Si2177
> 
> I just received a Product Announcement from SILICON LABS. There new TV 
> Tuner Chip, the Si2177, appears to be able to demodulate Analog TV 
> directly on the chip without software. If I am not mistaken, this 
> function is a new feature in TV Tuner Chips, which may provide a much 
> better SDR than current TV Tuner Chip Dongles, especially when it 
> comes to noise performance. It also eliminates almost all external 
> components. RF Input Frequency Range - 42 to 870 MHz
> 
> Si2177 5th Generation Silicon TV Tuner ICs
> 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2177-short.p
> df
> 
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3408 / Virus Database: 3222/6680 - Release Date: 
> 09/19/13
> 
> 

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6684 - Release Date: 09/20/13




From leif at sm5bsz.com  Sat Sep 21 21:37:54 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Sat, 21 Sep 2013 23:37:54 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921171154.21e3eaa1@korath.teln.shikadi.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
Message-ID: <20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>

Hi Adam,

> > > The bandwidth of the I/Q pair is too large to be transmitted 
> > > over USB for the reception of TV signals. After demodulation
> > > the bandwidth is lower so it would (marginally) fit an USB 
> > > interface if we talk about traditional analogue TV. For digital
> > > TV the bandwidth reduction by the decoder is much larger.
> 
> Is that correct?  From what I can find, an analogue TV signal has a
> bandwidth of around 6-8MHz.
Yes.

> The HackRF is an SDR that works over
> USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
> should be ample for one analogue (or even digital) TV signal, perhaps
> even two if the channels are close enough together.

I was under the impression that the USB channel was the reason that
the highest sampling rate I was aware of in continous mode is 4 MHz
(QS1R) Now, I did not think of the fact that for the dongle we need 
only 8 bit while normal SDRs use 16 bit so with my assumption the 
maximum sampling speed would be 8 MHz. To receive 6-8 MHz bandwidth 
one would need to sample quite a bit higher. Surely one could apply 
digital filters but even so a, substantial amount of oversampling 
is needed.

Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
continously? Where did you find that info? (Seems I should try to
push SDR manufacturers who use USB 2.0 to supply modes with higher 
sampling rates...)

73

Leif



From bistromath at gmail.com  Sat Sep 21 22:26:06 2013
From: bistromath at gmail.com (Nick Foster)
Date: Sat, 21 Sep 2013 15:26:06 -0700
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
Message-ID: <CA+JMMq-ZShSJEmdXb+Cf_8tmGKdX6SVxsRne9_7rfo0Oo3aGTA@mail.gmail.com>

HackRF sends 8bit samples, same as the RTL dongle. 20Msps * 8bits * 2
(complex sampling) = 320Mbit/s, or 67% utilization. The Ettus B100 gets
10.6Msps on most USB host controllers, sometimes 12.8Msps if you have a
really nice USB host controller with nothing else on the bus -- 71-85%
utilization with 16bit samples. You can double that if you select 8 bit
sampling mode for the B100, for 21.3-25.6Msps, at the cost of dynamic
range. The RTL dongle appears not to be able to continuously sample above
2.4Msps for reasons that are unclear to me, but certainly not due to a
USB2.0 limitation.

--n


On Sat, Sep 21, 2013 at 2:37 PM, Leif Asbrink <leif at sm5bsz.com> wrote:

> Hi Adam,
>
> > > > The bandwidth of the I/Q pair is too large to be transmitted
> > > > over USB for the reception of TV signals. After demodulation
> > > > the bandwidth is lower so it would (marginally) fit an USB
> > > > interface if we talk about traditional analogue TV. For digital
> > > > TV the bandwidth reduction by the decoder is much larger.
> >
> > Is that correct?  From what I can find, an analogue TV signal has a
> > bandwidth of around 6-8MHz.
> Yes.
>
> > The HackRF is an SDR that works over
> > USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
> > should be ample for one analogue (or even digital) TV signal, perhaps
> > even two if the channels are close enough together.
>
> I was under the impression that the USB channel was the reason that
> the highest sampling rate I was aware of in continous mode is 4 MHz
> (QS1R) Now, I did not think of the fact that for the dongle we need
> only 8 bit while normal SDRs use 16 bit so with my assumption the
> maximum sampling speed would be 8 MHz. To receive 6-8 MHz bandwidth
> one would need to sample quite a bit higher. Surely one could apply
> digital filters but even so a, substantial amount of oversampling
> is needed.
>
> Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
> continously? Where did you find that info? (Seems I should try to
> push SDR manufacturers who use USB 2.0 to supply modes with higher
> sampling rates...)
>
> 73
>
> Leif
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130921/02ac3624/attachment.htm>

From jsalsburg at bellsouth.net  Sat Sep 21 22:34:57 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Sat, 21 Sep 2013 17:34:57 -0500
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>	<20130920231712.713ecf29@lembas.zaitcev.lan>	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>

What is all this talk about USB. High-end Audio Interfaces digitize/quantize
at 192KHz/24bit. Since these new Tuners are almost naked on a surface mount
board, all that is needed other than a good audio card is a BusPirate to
control the I2C to get one of these new Analog TV tuner Chips to work as a
SDR. Since most "Intelligence" in radio is narrow band typically a Voice
Channel, all that a wideband A/D gives you is a view from 50,000 feet of the
spectrum which is OK for Test and Measurement. I cannot use my TV Dongles
for most of my (Forward Scatter RADAR) applications because of their low
resolution, I must use a conventional Scanner because it converts the signal
to Audio. What I need is high definition and narrow band, the current
Dongles are typically Wide Band low resolution (2Mhz/8bit). This is why a
Tuner Chip with low noise and demodulated analog output is attractive to me,
it is a complete solution.

-----Original Message-----
From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink
Sent: Saturday, September 21, 2013 4:38 PM
To: osmocom-sdr at lists.osmocom.org
Subject: Re: new TV Tuner Chip, the Si2177

Hi Adam,

> > > The bandwidth of the I/Q pair is too large to be transmitted over 
> > > USB for the reception of TV signals. After demodulation the 
> > > bandwidth is lower so it would (marginally) fit an USB interface 
> > > if we talk about traditional analogue TV. For digital TV the 
> > > bandwidth reduction by the decoder is much larger.
> 
> Is that correct?  From what I can find, an analogue TV signal has a 
> bandwidth of around 6-8MHz.
Yes.

> The HackRF is an SDR that works over
> USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which 
> should be ample for one analogue (or even digital) TV signal, perhaps 
> even two if the channels are close enough together.

I was under the impression that the USB channel was the reason that the
highest sampling rate I was aware of in continous mode is 4 MHz
(QS1R) Now, I did not think of the fact that for the dongle we need only 8
bit while normal SDRs use 16 bit so with my assumption the maximum sampling
speed would be 8 MHz. To receive 6-8 MHz bandwidth one would need to sample
quite a bit higher. Surely one could apply digital filters but even so a,
substantial amount of oversampling is needed.

Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
continously? Where did you find that info? (Seems I should try to push SDR
manufacturers who use USB 2.0 to supply modes with higher sampling rates...)

73

Leif

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13




From a.nielsen at shikadi.net  Sat Sep 21 22:42:59 2013
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Sun, 22 Sep 2013 08:42:59 +1000
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
Message-ID: <20130922084259.7d889278@korath.teln.shikadi.net>

> Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
> continously? Where did you find that info? (Seems I should try to
> push SDR manufacturers who use USB 2.0 to supply modes with higher 
> sampling rates...)

I can't find any specific examples now, but most pages discussing the
HackRF (including those from people who have a prototype) say there is
no problem receiving 20Msps from the device.  I find this quite
believable, as one of the aims for the project was to be able to
monitor a 20MHz wi-fi channel at 5.8GHz, so that the 802.11 protocol
could be implemented entirely in software.

The only reason the RTL devices are limited to smaller bandwidths seems
to be a limitation in the performance of the RTL2832 chip itself -
something not entirely surprising to anyone familiar with the
performance of other Realtek products ;-)

Cheers,
Adam.



From bistromath at gmail.com  Sat Sep 21 23:40:22 2013
From: bistromath at gmail.com (Nick Foster)
Date: Sat, 21 Sep 2013 16:40:22 -0700
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
Message-ID: <CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>

As others have tried to explain, this chip does not provide an analog
output for you to digitize with your soundcard. It turns RF into H.264
digital video. That's all. There's nothing to digitize and no place to plug
your soundcard into.

--n
What is all this talk about USB. High-end Audio Interfaces digitize/quantize
at 192KHz/24bit. Since these new Tuners are almost naked on a surface mount
board, all that is needed other than a good audio card is a BusPirate to
control the I2C to get one of these new Analog TV tuner Chips to work as a
SDR. Since most "Intelligence" in radio is narrow band typically a Voice
Channel, all that a wideband A/D gives you is a view from 50,000 feet of the
spectrum which is OK for Test and Measurement. I cannot use my TV Dongles
for most of my (Forward Scatter RADAR) applications because of their low
resolution, I must use a conventional Scanner because it converts the signal
to Audio. What I need is high definition and narrow band, the current
Dongles are typically Wide Band low resolution (2Mhz/8bit). This is why a
Tuner Chip with low noise and demodulated analog output is attractive to me,
it is a complete solution.

-----Original Message-----
From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink
Sent: Saturday, September 21, 2013 4:38 PM
To: osmocom-sdr at lists.osmocom.org
Subject: Re: new TV Tuner Chip, the Si2177

Hi Adam,

> > > The bandwidth of the I/Q pair is too large to be transmitted over
> > > USB for the reception of TV signals. After demodulation the
> > > bandwidth is lower so it would (marginally) fit an USB interface
> > > if we talk about traditional analogue TV. For digital TV the
> > > bandwidth reduction by the decoder is much larger.
>
> Is that correct?  From what I can find, an analogue TV signal has a
> bandwidth of around 6-8MHz.
Yes.

> The HackRF is an SDR that works over
> USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
> should be ample for one analogue (or even digital) TV signal, perhaps
> even two if the channels are close enough together.

I was under the impression that the USB channel was the reason that the
highest sampling rate I was aware of in continous mode is 4 MHz
(QS1R) Now, I did not think of the fact that for the dongle we need only 8
bit while normal SDRs use 16 bit so with my assumption the maximum sampling
speed would be 8 MHz. To receive 6-8 MHz bandwidth one would need to sample
quite a bit higher. Surely one could apply digital filters but even so a,
substantial amount of oversampling is needed.

Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
continously? Where did you find that info? (Seems I should try to push SDR
manufacturers who use USB 2.0 to supply modes with higher sampling rates...)

73

Leif

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130921/03def453/attachment.htm>

From bwojtowi at gmail.com  Sun Sep 22 16:14:10 2013
From: bwojtowi at gmail.com (Ben Wojtowicz)
Date: Sun, 22 Sep 2013 11:14:10 -0500
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
Message-ID: <CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>

All,

I am using hackrf currently to receive LTE downlink at 15.36Msps.  I have
not specifically tried it at 20Msps, but I believe it should work.  USB2.0
is certainly not the limiting factor for the rtl dongles' sample rate.

Ben
On Sep 21, 2013 5:05 PM, "Nick Foster" <bistromath at gmail.com> wrote:

> As others have tried to explain, this chip does not provide an analog
> output for you to digitize with your soundcard. It turns RF into H.264
> digital video. That's all. There's nothing to digitize and no place to plug
> your soundcard into.
>
> --n
> What is all this talk about USB. High-end Audio Interfaces
> digitize/quantize
> at 192KHz/24bit. Since these new Tuners are almost naked on a surface mount
> board, all that is needed other than a good audio card is a BusPirate to
> control the I2C to get one of these new Analog TV tuner Chips to work as a
> SDR. Since most "Intelligence" in radio is narrow band typically a Voice
> Channel, all that a wideband A/D gives you is a view from 50,000 feet of
> the
> spectrum which is OK for Test and Measurement. I cannot use my TV Dongles
> for most of my (Forward Scatter RADAR) applications because of their low
> resolution, I must use a conventional Scanner because it converts the
> signal
> to Audio. What I need is high definition and narrow band, the current
> Dongles are typically Wide Band low resolution (2Mhz/8bit). This is why a
> Tuner Chip with low noise and demodulated analog output is attractive to
> me,
> it is a complete solution.
>
> -----Original Message-----
> From: osmocom-sdr-bounces at lists.osmocom.org
> [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink
> Sent: Saturday, September 21, 2013 4:38 PM
> To: osmocom-sdr at lists.osmocom.org
> Subject: Re: new TV Tuner Chip, the Si2177
>
> Hi Adam,
>
> > > > The bandwidth of the I/Q pair is too large to be transmitted over
> > > > USB for the reception of TV signals. After demodulation the
> > > > bandwidth is lower so it would (marginally) fit an USB interface
> > > > if we talk about traditional analogue TV. For digital TV the
> > > > bandwidth reduction by the decoder is much larger.
> >
> > Is that correct?  From what I can find, an analogue TV signal has a
> > bandwidth of around 6-8MHz.
> Yes.
>
> > The HackRF is an SDR that works over
> > USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
> > should be ample for one analogue (or even digital) TV signal, perhaps
> > even two if the channels are close enough together.
>
> I was under the impression that the USB channel was the reason that the
> highest sampling rate I was aware of in continous mode is 4 MHz
> (QS1R) Now, I did not think of the fact that for the dongle we need only 8
> bit while normal SDRs use 16 bit so with my assumption the maximum sampling
> speed would be 8 MHz. To receive 6-8 MHz bandwidth one would need to sample
> quite a bit higher. Surely one could apply digital filters but even so a,
> substantial amount of oversampling is needed.
>
> Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
> continously? Where did you find that info? (Seems I should try to push SDR
> manufacturers who use USB 2.0 to supply modes with higher sampling
> rates...)
>
> 73
>
> Leif
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130922/66d0c277/attachment.htm>

From sylvain.azarian at gmail.com  Sun Sep 22 16:50:23 2013
From: sylvain.azarian at gmail.com (Sylvain AZARIAN)
Date: Sun, 22 Sep 2013 18:50:23 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
Message-ID: <CAHZVKw0oKvasAoSev4P2SOTkSjUE2ReS-ZcGzYuVmh1W9SAa4g@mail.gmail.com>

My personal tests on usb2 with Windows or Linux show a limit around 35
mbytes/sec (tested with Cypress fx2 or fx3)

Sylvain
Le 22 sept. 2013 18:36, "Ben Wojtowicz" <bwojtowi at gmail.com> a ?crit :

> All,
>
> I am using hackrf currently to receive LTE downlink at 15.36Msps.  I have
> not specifically tried it at 20Msps, but I believe it should work.  USB2.0
> is certainly not the limiting factor for the rtl dongles' sample rate.
>
> Ben
> On Sep 21, 2013 5:05 PM, "Nick Foster" <bistromath at gmail.com> wrote:
>
>> As others have tried to explain, this chip does not provide an analog
>> output for you to digitize with your soundcard. It turns RF into H.264
>> digital video. That's all. There's nothing to digitize and no place to plug
>> your soundcard into.
>>
>> --n
>> What is all this talk about USB. High-end Audio Interfaces
>> digitize/quantize
>> at 192KHz/24bit. Since these new Tuners are almost naked on a surface
>> mount
>> board, all that is needed other than a good audio card is a BusPirate to
>> control the I2C to get one of these new Analog TV tuner Chips to work as a
>> SDR. Since most "Intelligence" in radio is narrow band typically a Voice
>> Channel, all that a wideband A/D gives you is a view from 50,000 feet of
>> the
>> spectrum which is OK for Test and Measurement. I cannot use my TV Dongles
>> for most of my (Forward Scatter RADAR) applications because of their low
>> resolution, I must use a conventional Scanner because it converts the
>> signal
>> to Audio. What I need is high definition and narrow band, the current
>> Dongles are typically Wide Band low resolution (2Mhz/8bit). This is why a
>> Tuner Chip with low noise and demodulated analog output is attractive to
>> me,
>> it is a complete solution.
>>
>> -----Original Message-----
>> From: osmocom-sdr-bounces at lists.osmocom.org
>> [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink
>> Sent: Saturday, September 21, 2013 4:38 PM
>> To: osmocom-sdr at lists.osmocom.org
>> Subject: Re: new TV Tuner Chip, the Si2177
>>
>> Hi Adam,
>>
>> > > > The bandwidth of the I/Q pair is too large to be transmitted over
>> > > > USB for the reception of TV signals. After demodulation the
>> > > > bandwidth is lower so it would (marginally) fit an USB interface
>> > > > if we talk about traditional analogue TV. For digital TV the
>> > > > bandwidth reduction by the decoder is much larger.
>> >
>> > Is that correct?  From what I can find, an analogue TV signal has a
>> > bandwidth of around 6-8MHz.
>> Yes.
>>
>> > The HackRF is an SDR that works over
>> > USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
>> > should be ample for one analogue (or even digital) TV signal, perhaps
>> > even two if the channels are close enough together.
>>
>> I was under the impression that the USB channel was the reason that the
>> highest sampling rate I was aware of in continous mode is 4 MHz
>> (QS1R) Now, I did not think of the fact that for the dongle we need only 8
>> bit while normal SDRs use 16 bit so with my assumption the maximum
>> sampling
>> speed would be 8 MHz. To receive 6-8 MHz bandwidth one would need to
>> sample
>> quite a bit higher. Surely one could apply digital filters but even so a,
>> substantial amount of oversampling is needed.
>>
>> Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
>> continously? Where did you find that info? (Seems I should try to push SDR
>> manufacturers who use USB 2.0 to supply modes with higher sampling
>> rates...)
>>
>> 73
>>
>> Leif
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130922/7c52b4f9/attachment.htm>

From leif at sm5bsz.com  Sun Sep 22 17:01:30 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Sun, 22 Sep 2013 19:01:30 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
Message-ID: <20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>

Hi Ben!

> I am using hackrf currently to receive LTE downlink at 15.36Msps.  I have
> not specifically tried it at 20Msps, but I believe it should work.  USB2.0
> is certainly not the limiting factor for the rtl dongles' sample rate.

Very interesting. Is there somewhere one can buy the hackrf hardware?

Leif




From jsalsburg at bellsouth.net  Sun Sep 22 18:36:17 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Sun, 22 Sep 2013 13:36:17 -0500
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>	<20130920231712.713ecf29@lembas.zaitcev.lan>	<20130921171154.21e3eaa1@korath.teln.shikadi.net>	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAP2LGM9bBf5PgLODuY1mT5EBAAAAAA==@bellsouth.net>

You are correct that the 2177/78 are not the chip of choice, but SiLABs
offers some very interesting choices like the 2158 which does sport an
analog output. I should be more careful in my exuberance.

 

http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2158-short.pdf

 

Pictures of a simple effective modification to an EzTV645. This modification
made a big improvement in its (noise) performance.

 

http://www.salsburg.com/ezcap/

 

 

From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Nick Foster
Sent: Saturday, September 21, 2013 6:40 PM
To: Jay Salsburg
Cc: osmocom-sdr at lists.osmocom.org
Subject: RE: new TV Tuner Chip, the Si2177

 

As others have tried to explain, this chip does not provide an analog output
for you to digitize with your soundcard. It turns RF into H.264 digital
video. That's all. There's nothing to digitize and no place to plug your
soundcard into.

--n

What is all this talk about USB. High-end Audio Interfaces digitize/quantize
at 192KHz/24bit. Since these new Tuners are almost naked on a surface mount
board, all that is needed other than a good audio card is a BusPirate to
control the I2C to get one of these new Analog TV tuner Chips to work as a
SDR. Since most "Intelligence" in radio is narrow band typically a Voice
Channel, all that a wideband A/D gives you is a view from 50,000 feet of the
spectrum which is OK for Test and Measurement. I cannot use my TV Dongles
for most of my (Forward Scatter RADAR) applications because of their low
resolution, I must use a conventional Scanner because it converts the signal
to Audio. What I need is high definition and narrow band, the current
Dongles are typically Wide Band low resolution (2Mhz/8bit). This is why a
Tuner Chip with low noise and demodulated analog output is attractive to me,
it is a complete solution.

-----Original Message-----
From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink
Sent: Saturday, September 21, 2013 4:38 PM
To: osmocom-sdr at lists.osmocom.org
Subject: Re: new TV Tuner Chip, the Si2177

Hi Adam,

> > > The bandwidth of the I/Q pair is too large to be transmitted over
> > > USB for the reception of TV signals. After demodulation the
> > > bandwidth is lower so it would (marginally) fit an USB interface
> > > if we talk about traditional analogue TV. For digital TV the
> > > bandwidth reduction by the decoder is much larger.
>
> Is that correct?  From what I can find, an analogue TV signal has a
> bandwidth of around 6-8MHz.
Yes.

> The HackRF is an SDR that works over
> USB2.0 and can capture a chunk of RF spectrum up to 20MHz, which
> should be ample for one analogue (or even digital) TV signal, perhaps
> even two if the channels are close enough together.

I was under the impression that the USB channel was the reason that the
highest sampling rate I was aware of in continous mode is 4 MHz
(QS1R) Now, I did not think of the fact that for the dongle we need only 8
bit while normal SDRs use 16 bit so with my assumption the maximum sampling
speed would be 8 MHz. To receive 6-8 MHz bandwidth one would need to sample
quite a bit higher. Surely one could apply digital filters but even so a,
substantial amount of oversampling is needed.

Are you sure HackRF really can send 20 MHz of bandwidth over USB 2.0
continously? Where did you find that info? (Seems I should try to push SDR
manufacturers who use USB 2.0 to supply modes with higher sampling rates...)

73

Leif

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13



  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6688 - Release Date: 09/21/13

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130922/1f8d85e4/attachment.htm>

From a.nielsen at shikadi.net  Sun Sep 22 20:34:59 2013
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Mon, 23 Sep 2013 06:34:59 +1000
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
Message-ID: <20130923063459.40de90ff@korath.teln.shikadi.net>

> Very interesting. Is there somewhere one can buy the hackrf hardware?

Probably not until sometime after Jan/Feb 2014 when all the units
ordered through the Kickstarter campaign have hopefully shipped.

Cheers,
Adam.



From scott at scottcutler.net  Sun Sep 22 20:59:47 2013
From: scott at scottcutler.net (Scott Cutler)
Date: Sun, 22 Sep 2013 13:59:47 -0700
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130923063459.40de90ff@korath.teln.shikadi.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
Message-ID: <523F5A43.9030106@scottcutler.net>

There is also the bladeRF hardware, which is available and in stock.  I 
have a unit and it is a very nice piece of kit.  It achieves 40 MS/s @ 
12 bit over USB 3.0.  It uses a Cypress FX3, so even on USB 2 it should 
be able to saturate the bus.  Unfortunately, the price went way up after 
their Kickstarter ended.  Also, the SW is still in development and not 
polished yet.

-Scott


On 9/22/2013 1:34 PM, Adam Nielsen wrote:
>> Very interesting. Is there somewhere one can buy the hackrf hardware?
> Probably not until sometime after Jan/Feb 2014 when all the units
> ordered through the Kickstarter campaign have hopefully shipped.
>
> Cheers,
> Adam.
>




From a.nielsen at shikadi.net  Mon Sep 23 01:11:50 2013
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Mon, 23 Sep 2013 11:11:50 +1000
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <523F5A43.9030106@scottcutler.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
Message-ID: <20130923111150.4e411ea1@teln.shikadi.net>

> There is also the bladeRF hardware, which is available and in stock.
> I have a unit and it is a very nice piece of kit.  It achieves 40
> MS/s @ 12 bit over USB 3.0.  It uses a Cypress FX3, so even on USB 2
> it should be able to saturate the bus.  Unfortunately, the price went
> way up after their Kickstarter ended.  Also, the SW is still in
> development and not polished yet.

Just to confirm, are you saying you can use the bladeRF as a proper SDR
like the RTL devices?  I did look at it a while back, but to me it
looked like it required all the SDR processing to happen within an
onboard FPGA, so I assumed it wasn't a PC-based SDR.

Cheers,
Adam.



From leif at sm5bsz.com  Mon Sep 23 02:05:43 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Mon, 23 Sep 2013 04:05:43 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130923111150.4e411ea1@teln.shikadi.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
Message-ID: <20130923040543.29c40041209858594c5ca407@sm5bsz.com>

Hi Adam,

The bladeRF can be configured to send I/Q data at the
desired bandwidth to the PC. Surely it can be configured to do
many other things also.

It all depends on how clever software designers are and to
what extent help is available.

I will order a unit. Maybe I will be able to get it running
in Linrad. If so, it would probably allow the widest bandwidth of all
harwdare currently supported.

73

Leif / SM5BSZ



> > There is also the bladeRF hardware, which is available and in stock.
> > I have a unit and it is a very nice piece of kit.  It achieves 40
> > MS/s @ 12 bit over USB 3.0.  It uses a Cypress FX3, so even on USB 2
> > it should be able to saturate the bus.  Unfortunately, the price went
> > way up after their Kickstarter ended.  Also, the SW is still in
> > development and not polished yet.
> 
> Just to confirm, are you saying you can use the bladeRF as a proper SDR
> like the RTL devices?  I did look at it a while back, but to me it
> looked like it required all the SDR processing to happen within an
> onboard FPGA, so I assumed it wasn't a PC-based SDR.
> 
> Cheers,
> Adam.
> 



From scott at scottcutler.net  Mon Sep 23 03:20:14 2013
From: scott at scottcutler.net (Scott Cutler)
Date: Sun, 22 Sep 2013 20:20:14 -0700
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130923111150.4e411ea1@teln.shikadi.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
Message-ID: <CAN=zT1ahqxfqOHC1_0yZ-g4BybQBUbQZwXoNLTXrs=WYbpJ7cw@mail.gmail.com>

Yes, as Leif says, the unit works just fine as a passthru device.  I
already have it working with my own SDR program.  It supports TX as well,
though I haven't tested that aspect yet.  I doubt I'll make use of the FPGA
personally; while cool, I want my program to be compatible with "dumb"
devices like the the RTL units and so there's not a lot of value in
special-casing the bladeRF.

-Scott


On Sun, Sep 22, 2013 at 6:11 PM, Adam Nielsen <a.nielsen at shikadi.net> wrote:

> > There is also the bladeRF hardware, which is available and in stock.
> > I have a unit and it is a very nice piece of kit.  It achieves 40
> > MS/s @ 12 bit over USB 3.0.  It uses a Cypress FX3, so even on USB 2
> > it should be able to saturate the bus.  Unfortunately, the price went
> > way up after their Kickstarter ended.  Also, the SW is still in
> > development and not polished yet.
>
> Just to confirm, are you saying you can use the bladeRF as a proper SDR
> like the RTL devices?  I did look at it a while back, but to me it
> looked like it required all the SDR processing to happen within an
> onboard FPGA, so I assumed it wasn't a PC-based SDR.
>
> Cheers,
> Adam.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130922/900754ed/attachment.htm>

From juergen.kahrs at googlemail.com  Mon Sep 23 08:29:58 2013
From: juergen.kahrs at googlemail.com (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=)
Date: Mon, 23 Sep 2013 10:29:58 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130923040543.29c40041209858594c5ca407@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
Message-ID: <523FFC06.1020006@googlemail.com>

Hello Leif,


> I will order a unit. Maybe I will be able to get it running
> in Linrad. If so, it would probably allow the widest bandwidth of all
> harwdare currently supported.


How useful is such a "wide bandwidth" for users ?
How many of them really need such a wide bandwidth ?
Up to now it always looked like users were mostly interested in single channels.
I am new to this list and don't know what others are doing.

The other reason I am asking is because I have got a very
different device with a bandwidth of 100 MHz running and
I wonder if I am the only one playing with such things.
My device is an ADLINK digitizer PCIe-9842:

  http://www.adlinktech.com/PD/photo/display/PCIe-9842/PCIe-9842_bimg_1.jpg

This digitizer can sample at 200 MHz on a single input channel.
So this is very different from the other devices that are discussed
here: No antenna amplifier, no mixer, no AGC. At 200 MS/s it is
hard to emulate all the missing hardware parts in software.
Since there is no mixer, the software can demodulate only
frequencies in the range of public radio stations (short wave).
Would it make sense to have Linrad support such a device ?
Or is this device just too limited to be of interest ?



From a.nielsen at shikadi.net  Mon Sep 23 09:09:06 2013
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Mon, 23 Sep 2013 19:09:06 +1000
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <523FFC06.1020006@googlemail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
Message-ID: <20130923190906.0cf5b274@korath.teln.shikadi.net>

> How useful is such a "wide bandwidth" for users ?

It depends what you are trying to examine.  If you want to look at TV
signals you need 8MHz, if you want to look at 802.11n you need
40-80MHz, 160MHz for 802.11ac, etc.  Many people are interested in
implementing these protocols entirely in software for many reasons,
many revolving around security.

> How many of them really need such a wide bandwidth ?

The wider the better, simply for flexibility.  The wider the bandwidth
the less the need for frequency hopping if you can receive all relevant
frequencies at once.  This is why there are relatively frequent
questions about combining multiple devices to extend the available
bandwidth.  It looks like the HackRF's external clock input will make
it one of the first low cost devices that can do this.

> Up to now it always looked like users were mostly interested in
> single channels. I am new to this list and don't know what others are
> doing.

Up to now it was only really practical to listen to a single channel.
The Realtek 2832 dongles are the first to make it practical to listen
to multiple channels, but a lot of SDR software still needs to catch up.

> My device is an ADLINK digitizer PCIe-9842:

That is very interesting!  I will leave others to comment on the
viability of devices like this for SDR purposes.

Cheers,
Adam.



From leif at sm5bsz.com  Mon Sep 23 19:46:35 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Mon, 23 Sep 2013 21:46:35 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <523FFC06.1020006@googlemail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAD+WSCQylGNPmUxj41RAW8oBAAAAAA==@bellsouth.net>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
Message-ID: <20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>

Hi J?rgen,

> How useful is such a "wide bandwidth" for users ?
It allows efficient removal of strong static rain QRN.

> How many of them really need such a wide bandwidth ?
On VHF bands I would say 80% or more, but only a during
rain summertime, and only when the raindrops are charged.

Have a look at the lower left corner of figure 1 here:
http://www.sm5bsz.com/lir/recordings/static-rain.htm

There you can see the sequence of pulses that originate from
one raindrop hitting one of the elements of a yagi array.
The sampling speed is 2 MHz and it is not quite enough.
The pulses immediately after the first discharge are not 
resolved.

At a speed of 96 kHz the entire time period is a noise burst
that can only be removed by gating out the entire time span.
When the number of raindrops increases, 96 kHz does not work
because the noise bursts would overlap. I would think 5 MHz
would be about optimum (with todays computer hardware and
Linrad.) It would allow removal of S9+20 dB noise from static 
rain and give the normal noise floor with no adverse effect
on weak or strong signals.

With the very high bandwidth one might discover that there
is (removable) noise from charged dust whenever winds are 
high in dry weather. I do not know, but the static rain 
statement is based on solid experience with an equivalent 
wideband blanker (5 or 10 MHz wide) that I was using many
years ago:
http://www.sm5bsz.com/rtblnk/rt0669.htm

> Up to now it always looked like users were mostly interested in single channels.
> I am new to this list and don't know what others are doing.
> 
> The other reason I am asking is because I have got a very
> different device with a bandwidth of 100 MHz running and
> I wonder if I am the only one playing with such things.
> My device is an ADLINK digitizer PCIe-9842:
> 
>   http://www.adlinktech.com/PD/photo/display/PCIe-9842/PCIe-9842_bimg_1.jpg
> 
> This digitizer can sample at 200 MHz on a single input channel.
> So this is very different from the other devices that are discussed
> here: No antenna amplifier, no mixer, no AGC. At 200 MS/s it is
> hard to emulate all the missing hardware parts in software.
> Since there is no mixer, the software can demodulate only
> frequencies in the range of public radio stations (short wave).
> Would it make sense to have Linrad support such a device ?
> Or is this device just too limited to be of interest ?
Yes:-) I did not know about this card although it seems to come
from a Swedish company. I will call them tomorrow:-)

73

Leif / SM5BSZ



From juergen.kahrs at googlemail.com  Tue Sep 24 08:26:58 2013
From: juergen.kahrs at googlemail.com (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=)
Date: Tue, 24 Sep 2013 10:26:58 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
	<20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>
Message-ID: <52414CD2.4020901@googlemail.com>

Hello Leif,

>> How useful is such a "wide bandwidth" for users ?
> It allows efficient removal of strong static rain QRN.

This is an aspect that is completely new to me.
I was guessing more in the direction of recording hundreds
of channels simultaneously.

>
>> How many of them really need such a wide bandwidth ?
> On VHF bands I would say 80% or more, but only a during
> rain summertime, and only when the raindrops are charged.
>
> Have a look at the lower left corner of figure 1 here:
> http://www.sm5bsz.com/lir/recordings/static-rain.htm
>
> There you can see the sequence of pulses that originate from
> one raindrop hitting one of the elements of a yagi array.
> The sampling speed is 2 MHz and it is not quite enough.
> The pulses immediately after the first discharge are not 
> resolved.

That's funny. Charged raindrops causing pulses.
But it makes sense that a higher sampling rate can simply
removal of such disturbances. A sampling rate of 5 to 10 MHz
is easily implemented with the PCIe-9842. My first trials with my
own software used 5 and later 20 MHz. At the moment, my
recordings use 200 MHz by default. Thanks to the PCI express
interface and a good driver software, the transfer of 400 MB/s
puts no load onto the CPU. It is only the signal processing that
causes a high computational burden onto the hardware.

Up to now I have processed the data from the PCIe-9842 with
my own channelizer software. For example, in the medium wave
range of radio stations between 522 kHz and 1656 kHz there are
127 channels spaced in a 9 kHz raster. My software demodulates
all of them simultaneously (AM) and saves the data of all channels
into one .wav file. This .wav file can be processed later with the
Audacity sound editor, the only editor I know that can handle 127
channels with PCM data. The signal processing of the channelizer
runs on my graphics card (nvidia GTX 660TI with 1344 GPU cores).
I guess that the noise removal for the raindrops can also be done
on the graphics card, even with 200 MHz.

>
>> My device is an ADLINK digitizer PCIe-9842:
>>
>>   http://www.adlinktech.com/PD/photo/display/PCIe-9842/PCIe-9842_bimg_1.jpg
>>
>> This digitizer can sample at 200 MHz on a single input channel.
>> So this is very different from the other devices that are discussed
>> here: No antenna amplifier, no mixer, no AGC. At 200 MS/s it is
>> hard to emulate all the missing hardware parts in software.
>> Since there is no mixer, the software can demodulate only
>> frequencies in the range of public radio stations (short wave).
>> Would it make sense to have Linrad support such a device ?
>> Or is this device just too limited to be of interest ?
> Yes:-) I did not know about this card although it seems to come
> from a Swedish company. I will call them tomorrow:-)
>

ADLINK is a taiwanese company, as far as I know.
The Swedish company you mean is probably Strategic Test in Stockholm.
They offer excellent cards with Linux support, but too expensive for me.

I have downloaded the source code of Linrad and had a short look at it.
Why don't you put the source code into a Subversion repository at SourceForge ?
Storing the source code there costs nothing and simplifies access.
It looks like there is a systematic way of integrating new devices into
the Linrad source code. If I tried to integrate the PCIe-9842, would
you consider my source code for acceptance to  into Linrad ?



From a.nielsen at shikadi.net  Tue Sep 24 09:01:56 2013
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Tue, 24 Sep 2013 19:01:56 +1000
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <52414CD2.4020901@googlemail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
	<20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>
	<52414CD2.4020901@googlemail.com>
Message-ID: <20130924190156.3e156c21@korath.teln.shikadi.net>

> The signal processing of the channelizer
> runs on my graphics card (nvidia GTX 660TI with 1344 GPU cores).
> I guess that the noise removal for the raindrops can also be done
> on the graphics card, even with 200 MHz.

This is something I am *very* interested in.  How do you do the
processing on the GPU?  Do you use OpenGL, OpenCL, CUDA, etc?  Did you
write the code yourself or are you using an existing GPGPU library?

What sort of performance do you get?

> Why don't you put the source code into a Subversion repository at
> SourceForge ? Storing the source code there costs nothing and
> simplifies access.

Or you could use GitHub - having used SourceForge and GitHub, GitHub
is a lot easier to set up, providing you are already familiar with Git
of course!

Cheers,
Adam.



From juergen.kahrs at googlemail.com  Tue Sep 24 10:32:33 2013
From: juergen.kahrs at googlemail.com (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=)
Date: Tue, 24 Sep 2013 12:32:33 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130924190156.3e156c21@korath.teln.shikadi.net>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
	<20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>
	<52414CD2.4020901@googlemail.com>
	<20130924190156.3e156c21@korath.teln.shikadi.net>
Message-ID: <52416A41.9080309@googlemail.com>

Hello Adam,
 
>> The signal processing of the channelizer
>> runs on my graphics card (nvidia GTX 660TI with 1344 GPU cores).
>> I guess that the noise removal for the raindrops can also be done
>> on the graphics card, even with 200 MHz.
> This is something I am *very* interested in.  How do you do the
> processing on the GPU?  Do you use OpenGL, OpenCL, CUDA, etc?  Did you
> write the code yourself or are you using an existing GPGPU library?

I use OpenCL (no OpenGL), only the C level API, not the C++ level API.
I have tested my software against the OpenCL- implementations of
nvidia, AMD, and also Intel (). This was hard work but the channelizer
is really portable now. When I began, I hoped that I could use an
existing GPGPU library, but such libraries usually suplly some kind of
FFT and that's all about signal processing they offer. There is no library
available for channelizer or filtering with FIR or IIR that I am aware of.
Therefore I wrote the source code myself and decided to do it with
real-valued signals (since I sample the antenna directly) and not with
complex-valued signals that are commonplace in the SDR community.

> What sort of performance do you get?

This is hard to tell in numbers since there are so many parameters
that can be tuned. One example: The demodulated short-wave signals
are saved in a .wav file with all audio channels with 16 bit PCM at 8 kHz.
I have tested increasing the audio output sample rate to 44.1 kHz.
The sound quality improved significantly and I liked this quality.
But this sound quality comes at a high price: a 5 fold increase in GPU load.

My channelizer uses real-valued Goertzel filters and not the usual FFT.
Therefore the GPU load increases with the number of channels used.
Channelizers based on the usual FFT would be faster whenever the
number of channels is known in advance to be a power of 2.
There are many other design decisions like this that influence performance.

As a rough estimate about what the graphics card can do:
With an input sample rate of 200 MHz (1 channel, 16 bit) and an
audio output sample rate of 8 kHz (for each channel, 16 bit)
the channelizer can process more than 120 channels. At that
rate there is no buffer overflow.

>
>> Why don't you put the source code into a Subversion repository at
>> SourceForge ? Storing the source code there costs nothing and
>> simplifies access.
> Or you could use GitHub - having used SourceForge and GitHub, GitHub
> is a lot easier to set up, providing you are already familiar with Git
> of course!
>

Indeed, "providing you are already familiar with Git" is usually an obstacle.
Most developers don't want to learn repo management.
Therefore I prefer Subversion. But this thread is not the right place
for discussing personal preferences about SCM systems.

My main point is this: Is there an existing SDR tool fit for handling
data that comes in at 200 MS/s ?

Thanks for your comments and suggestions.



From leif at sm5bsz.com  Tue Sep 24 13:57:24 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Tue, 24 Sep 2013 15:57:24 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <52414CD2.4020901@googlemail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAANVK5stU7axFhobG4oTNWxABAAAAAA==@bellsouth.net>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
	<20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>
	<52414CD2.4020901@googlemail.com>
Message-ID: <20130924155724.f12e81fc70909f98be2f31e4@sm5bsz.com>

Hello J?rgen,


> That's funny. Charged raindrops causing pulses.
> But it makes sense that a higher sampling rate can simply
> removal of such disturbances. A sampling rate of 5 to 10 MHz
> is easily implemented with the PCIe-9842. My first trials with my
> own software used 5 and later 20 MHz. At the moment, my
> recordings use 200 MHz by default. Thanks to the PCI express
> interface and a good driver software, the transfer of 400 MB/s
> puts no load onto the CPU. It is only the signal processing that
> causes a high computational burden onto the hardware.
Very interesting:-)

Linrad can process 8 MHz bandwidth when run without the noise 
blanker on my now old super-computer, an Intel D5400XS board
with two 2 Xeon E5410 CPUs and 8 cpu cores while producing decent
filtering.

With the noise blanker enabled it can do 4 MHz. 
If I apply less good filters Linrad can do at least twice 
the bandwidths.

The limitation is the time to do FFT. I guess that could be 
moved to a GPU but I have no idea about how difficult it might be.

Linrad goes back and forth between the time and the frequency
domain. Four FFT computations are done after one another
for the noise blanker and they are placed in separate threads.
The blanker FFTs are double but placed in the same thread
and for that reason the blanker fills up a core at half the bandwidth.
That should not be too difficult to fix but I never had any reason.
I have not yet had access to any high speed hardware... 

> ADLINK is a taiwanese company, as far as I know.
> The Swedish company you mean is probably Strategic Test in Stockholm.
> They offer excellent cards with Linux support, but too expensive for me.
No, it was another Swedish company. I called them today but
the price they asked was pretty expensive so I did not order.

> I have downloaded the source code of Linrad and had a short look at it.
> Why don't you put the source code into a Subversion repository at SourceForge ?
> Storing the source code there costs nothing and simplifies access.
That is because I have no idea how to do it.
I do not want to spend time on learning those kinds of things.
I have several far more exciting things on my agenda:-)

> It looks like there is a systematic way of integrating new devices into
> the Linrad source code. If I tried to integrate the PCIe-9842, would
> you consider my source code for acceptance to  into Linrad ?
Absolutely. I would be delighted:-)
If you report sucess I would also want to buy such a card even
if I would have to pay more than I really want for it. On the
Internet I find the price to be something like 2000 Euro. 

Regards

Leif




From juergen.kahrs at googlemail.com  Tue Sep 24 19:41:43 2013
From: juergen.kahrs at googlemail.com (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=)
Date: Tue, 24 Sep 2013 21:41:43 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <20130924155724.f12e81fc70909f98be2f31e4@sm5bsz.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
	<20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>
	<52414CD2.4020901@googlemail.com>
	<20130924155724.f12e81fc70909f98be2f31e4@sm5bsz.com>
Message-ID: <5241EAF7.1060900@googlemail.com>

Hello Leif,

 
> The limitation is the time to do FFT. I guess that could be 
> moved to a GPU but I have no idea about how difficult it might be.

Using the GPU to do only the FFT would be a gentle way
to introduce the GPU into Linrad. But only if the interface
to the FFT is clean enough.

>> I have downloaded the source code of Linrad and had a short look at it.
>> Why don't you put the source code into a Subversion repository at SourceForge ?
>> Storing the source code there costs nothing and simplifies access.
> That is because I have no idea how to do it.
> I do not want to spend time on learning those kinds of things.
> I have several far more exciting things on my agenda:-)

Ok, setting up a repo is something that I could do.
But after setting it up it must be clear that the primary
source code is now in the repo and not on your local disk.
The repo is a safe place where to get the latest/primary
source code and also each earlier revision (if needed).

>
>> It looks like there is a systematic way of integrating new devices into
>> the Linrad source code. If I tried to integrate the PCIe-9842, would
>> you consider my source code for acceptance to  into Linrad ?
> Absolutely. I would be delighted:-)
> If you report sucess I would also want to buy such a card even
> if I would have to pay more than I really want for it. On the
> Internet I find the price to be something like 2000 Euro. 

2000 Euro + VAT is what I paid here in Germany.
Much money but still inexpensive in comparison to the industry.



From retzlerandras at gmail.com  Wed Sep 25 10:14:01 2013
From: retzlerandras at gmail.com (=?ISO-8859-1?Q?Andr=E1s_Retzler?=)
Date: Wed, 25 Sep 2013 12:14:01 +0200
Subject: LabVIEW support for rtl_tcp
Message-ID: <CABrNoDBOQ9D5THt3tNibwDp193i9FOhQ54v1sFxn_9nHzC2mEg@mail.gmail.com>

Hi,

I've made some SubVIs for LabVIEW to support rtl_tcp.

http://ha5kfu.sch.bme.hu/sites/default/files/public/sdrlab-rtl_tcp-interface-v0.1.zip

I hope that someone will find it useful.

More information and screenshot:

http://ha5kfu.sch.bme.hu/sdrlab

--

I'd like to say thanks for your work on the RTL-SDR project, it's something
really cool :-)

Regards,

Andr?s Retzler
HA7ILM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130925/f725f338/attachment.htm>

From leif at sm5bsz.com  Wed Sep 25 17:01:29 2013
From: leif at sm5bsz.com (Leif Asbrink)
Date: Wed, 25 Sep 2013 19:01:29 +0200
Subject: new TV Tuner Chip, the Si2177
In-Reply-To: <5241EAF7.1060900@googlemail.com>
References: <8BED69ED59944EE3A439F6FB78C75D49@dev.null>
	<20130921024314.d50f5f7cb3b8eecfa427ef36@sm5bsz.com>
	<20130920231712.713ecf29@lembas.zaitcev.lan>
	<20130921171154.21e3eaa1@korath.teln.shikadi.net>
	<20130921233754.e1d57a3ab6a8f378d4d26f2c@sm5bsz.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAL/9dtjk7fdPkKqSwEECXPkBAAAAAA==@bellsouth.net>
	<CA+JMMq85tsvKsi8XV6HvPDuU7QXAt496cfGguZPJRO9vwa_cow@mail.gmail.com>
	<CAF9-9qnTx2AwuvKQ+wOHW4xvzk0JyDAQ-sFkH2Bw4DntS4wXdA@mail.gmail.com>
	<20130922190130.4241c5a0769a1d43740252a2@sm5bsz.com>
	<20130923063459.40de90ff@korath.teln.shikadi.net>
	<523F5A43.9030106@scottcutler.net>
	<20130923111150.4e411ea1@teln.shikadi.net>
	<20130923040543.29c40041209858594c5ca407@sm5bsz.com>
	<523FFC06.1020006@googlemail.com>
	<20130923214635.3507d0e81b820b711f52a657@sm5bsz.com>
	<52414CD2.4020901@googlemail.com>
	<20130924155724.f12e81fc70909f98be2f31e4@sm5bsz.com>
	<5241EAF7.1060900@googlemail.com>
Message-ID: <20130925190129.cc69c7e60d3407b63483ee3d@sm5bsz.com>

Hello J?rgen!
 
> Using the GPU to do only the FFT would be a gentle way
> to introduce the GPU into Linrad. But only if the interface
> to the FFT is clean enough.
It would have to be rewritten. There is a large number of
FFT implementations depending on the input format. It will
be easy to add more and to select the GPU if available.


> >> I have downloaded the source code of Linrad and had a short look at it.
> >> Why don't you put the source code into a Subversion repository at SourceForge ?
> >> Storing the source code there costs nothing and simplifies access.
> > That is because I have no idea how to do it.
> > I do not want to spend time on learning those kinds of things.
> > I have several far more exciting things on my agenda:-)
> 
> Ok, setting up a repo is something that I could do.
> But after setting it up it must be clear that the primary
> source code is now in the repo and not on your local disk.
> The repo is a safe place where to get the latest/primary
> source code and also each earlier revision (if needed).
This would be perfectly fine with me.

The worries I have are about a new build system with CMake.
I do not know the implications...
 
> 2000 Euro + VAT is what I paid here in Germany.
> Much money but still inexpensive in comparison to the industry.
OK. I ordered one today. Delivery time 3 or 4 weeks.

 - Leif -



From alancorey at yahoo.com  Fri Sep 27 04:49:18 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Thu, 26 Sep 2013 21:49:18 -0700 (PDT)
Subject: rtl_? for radio control?
Message-ID: <1380257358.80662.YahooMailBasic@web161501.mail.bf1.yahoo.com>

OK, so you plug a $20 dongle into a Raspberry Pi, hook some stuff to the GPIO connector and with probably minor tweaks to something like RTL_FM you can use it as a radio in radio-controlled model planes, cars, boats.  Add the Pi's $25 camera and you could have a radio-controlled camera, useful for sending up in a radio-controlled plane or doing wildlife photography.  If you've got some analog (pulse position) channels those would be good for rudder, flaps, various camera settings.  This can be done in the 27 MHz CB band or with a ham license in something like the 6 meter ham band.  I had no trouble getting RTL_FM running on my Pi but it probably doesn't have enough CPU horsepower to do a lot of processing on the dongle side and on the imaging side at the same time.

Anybody done this?

  Alan
-----
Radio Astronomy - the ultimate DX