From picmaster at mail.bg  Sat Jul  4 12:42:22 2015
From: picmaster at mail.bg (Nikolay Dimitrov)
Date: Sat,  4 Jul 2015 15:42:22 +0300
Subject: [rtl-sdr][PATCH 1/2] rtl_fm: Add scanner progress
Message-ID: <1436013743-32758-1-git-send-email-picmaster@mail.bg>

Add scanner progress, including signal and squelch levels.
Rename demod_state->conseq_squelch to demod_state->squelch_conseq.

The scanner progress feature can be tested like this:

./rtl_fm -f 144.000M:146.000M:25k -M fm -s 48k -l 100 -t 5 | aplay \
	-r 48k -f S16_LE -t raw -c 1

Signed-off-by: Nikolay Dimitrov <picmaster at mail.bg>
---
 src/rtl_fm.c |   43 +++++++++++++++++++++++++++++--------------
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index e89e42d..04f08a2 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -131,7 +131,11 @@ struct demod_state
 	int      downsample;    /* min 1, max 256 */
 	int      post_downsample;
 	int      output_scale;
-	int      squelch_level, conseq_squelch, squelch_hits, terminate_on_squelch;
+	int      squelch_level;
+	int      squelch_conseq;
+	int      squelch_hits;
+	int      squelch_signal_rms;
+	int      terminate_on_squelch;
 	int      downsample_passes;
 	int      comp_fir_size;
 	int      custom_atan;
@@ -730,7 +734,6 @@ void arbitrary_resample(int16_t *buf1, int16_t *buf2, int len1, int len2)
 void full_demod(struct demod_state *d)
 {
 	int i, ds_p;
-	int sr = 0;
 	ds_p = d->downsample_passes;
 	if (ds_p) {
 		for (i=0; i < ds_p; i++) {
@@ -748,17 +751,20 @@ void full_demod(struct demod_state *d)
 	} else {
 		low_pass(d);
 	}
+
 	/* power squelch */
 	if (d->squelch_level) {
-		sr = rms(d->lowpassed, d->lp_len, 1);
-		if (sr < d->squelch_level) {
+		d->squelch_signal_rms = rms(d->lowpassed, d->lp_len, 1);
+		if (d->squelch_signal_rms < d->squelch_level) {
 			d->squelch_hits++;
-			for (i=0; i<d->lp_len; i++) {
+			for (i = 0; i < d->lp_len; i++) {
 				d->lowpassed[i] = 0;
 			}
 		} else {
-			d->squelch_hits = 0;}
+			d->squelch_hits = 0;
+		}
 	}
+
 	d->mode_demod(d);  /* lowpassed -> result */
 	if (d->mode_demod == &raw_demod) {
 		return;
@@ -814,6 +820,7 @@ static void *demod_thread_fn(void *arg)
 {
 	struct demod_state *d = arg;
 	struct output_state *o = d->output_target;
+
 	while (!do_exit) {
 		safe_cond_wait(&d->ready, &d->ready_m);
 		pthread_rwlock_wrlock(&d->rw);
@@ -822,17 +829,20 @@ static void *demod_thread_fn(void *arg)
 		if (d->exit_flag) {
 			do_exit = 1;
 		}
-		if (d->squelch_level && d->squelch_hits > d->conseq_squelch) {
-			d->squelch_hits = d->conseq_squelch + 1;  /* hair trigger */
+
+		if (d->squelch_level && d->squelch_hits > d->squelch_conseq) {
+			d->squelch_hits = d->squelch_conseq + 1;  /* hair trigger */
 			safe_cond_signal(&controller.hop, &controller.hop_m);
 			continue;
 		}
+
 		pthread_rwlock_wrlock(&o->rw);
 		memcpy(o->result, d->result, 2*d->result_len);
 		o->result_len = d->result_len;
 		pthread_rwlock_unlock(&o->rw);
 		safe_cond_signal(&o->ready, &o->ready_m);
 	}
+
 	return 0;
 }
 
@@ -909,9 +919,14 @@ static void *controller_thread_fn(void *arg)
 	while (!do_exit) {
 		safe_cond_wait(&s->hop, &s->hop_m);
 		if (s->freq_len <= 1) {
-			continue;}
+			continue;
+		}
+
 		/* hacky hopping */
 		s->freq_now = (s->freq_now + 1) % s->freq_len;
+		fprintf(stderr, "Frequency: %.3f MHz (signal: %d, squelch: %d)\r",
+			s->freqs[s->freq_now] / 1e6, demod.squelch_signal_rms,
+			demod.squelch_level);
 		optimal_settings(s->freqs[s->freq_now], demod.rate_in);
 		rtlsdr_set_center_freq(dongle.dev, dongle.freq);
 		dongle.mute = BUFFER_DUMP;
@@ -954,7 +969,7 @@ void demod_init(struct demod_state *s)
 	s->rate_in = DEFAULT_SAMPLE_RATE;
 	s->rate_out = DEFAULT_SAMPLE_RATE;
 	s->squelch_level = 0;
-	s->conseq_squelch = 10;
+	s->squelch_conseq = 10;
 	s->terminate_on_squelch = 0;
 	s->squelch_hits = 11;
 	s->downsample_passes = 0;
@@ -1027,7 +1042,7 @@ void sanity_checks(void)
 		exit(1);
 	}
 
-	if (controller.freq_len > 1 && demod.squelch_level == 0) {
+	if (controller.freq_len > 1 && !demod.squelch_level) {
 		fprintf(stderr, "Please specify a squelch level.  Required for scanning multiple frequencies.\n");
 		exit(1);
 	}
@@ -1085,9 +1100,9 @@ int main(int argc, char **argv)
 				fprintf(stderr, "Oversample must be between 1 and %i\n", MAXIMUM_OVERSAMPLE);}
 			break;
 		case 't':
-			demod.conseq_squelch = (int)atof(optarg);
-			if (demod.conseq_squelch < 0) {
-				demod.conseq_squelch = -demod.conseq_squelch;
+			demod.squelch_conseq = (int)atof(optarg);
+			if (demod.squelch_conseq < 0) {
+				demod.squelch_conseq = -demod.squelch_conseq;
 				demod.terminate_on_squelch = 1;
 			}
 			break;
-- 
1.7.10.4



From picmaster at mail.bg  Sat Jul  4 12:42:23 2015
From: picmaster at mail.bg (Nikolay Dimitrov)
Date: Sat,  4 Jul 2015 15:42:23 +0300
Subject: [rtl-sdr][PATCH 2/2] rtl_fm: Add squelch timeout
In-Reply-To: <1436013743-32758-1-git-send-email-picmaster@mail.bg>
References: <1436013743-32758-1-git-send-email-picmaster@mail.bg>
Message-ID: <1436013743-32758-2-git-send-email-picmaster@mail.bg>

The current squelch logic waits until the received signal drops below
the squelch value and then continues the frequency scan. If there's any
continuous transmission on the air, it will block the scanning process
forever. This patch adds support for squelch timeout to prevent the
scanner from locking forever to a single signal.

Signed-off-by: Nikolay Dimitrov <picmaster at mail.bg>
---
 src/rtl_fm.c |   21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index 04f08a2..51313d3 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -84,6 +84,8 @@
 
 #define FREQUENCIES_LIMIT		1000
 
+#define SQUELCH_TIMEOUT			100
+
 static volatile int do_exit = 0;
 static int lcm_post[17] = {1,1,1,3,1,5,3,7,1,9,5,11,3,13,7,15,1};
 static int ACTUAL_BUF_LENGTH;
@@ -135,6 +137,7 @@ struct demod_state
 	int      squelch_conseq;
 	int      squelch_hits;
 	int      squelch_signal_rms;
+	int      squelch_timer;
 	int      terminate_on_squelch;
 	int      downsample_passes;
 	int      comp_fir_size;
@@ -762,6 +765,7 @@ void full_demod(struct demod_state *d)
 			}
 		} else {
 			d->squelch_hits = 0;
+			d->squelch_timer++;
 		}
 	}
 
@@ -830,10 +834,18 @@ static void *demod_thread_fn(void *arg)
 			do_exit = 1;
 		}
 
-		if (d->squelch_level && d->squelch_hits > d->squelch_conseq) {
-			d->squelch_hits = d->squelch_conseq + 1;  /* hair trigger */
-			safe_cond_signal(&controller.hop, &controller.hop_m);
-			continue;
+		if (d->squelch_level) {
+			if (d->squelch_hits > d->squelch_conseq) {
+				d->squelch_hits = d->squelch_conseq + 1;  /* hair trigger */
+				safe_cond_signal(&controller.hop, &controller.hop_m);
+				continue;
+			}
+
+			if (d->squelch_timer >= SQUELCH_TIMEOUT) {
+				d->squelch_timer = 0;
+				safe_cond_signal(&controller.hop, &controller.hop_m);
+				continue;
+			}
 		}
 
 		pthread_rwlock_wrlock(&o->rw);
@@ -972,6 +984,7 @@ void demod_init(struct demod_state *s)
 	s->squelch_conseq = 10;
 	s->terminate_on_squelch = 0;
 	s->squelch_hits = 11;
+	s->squelch_timer = 0;
 	s->downsample_passes = 0;
 	s->comp_fir_size = 0;
 	s->prev_index = 0;
-- 
1.7.10.4



From la at tfc-server.de  Sun Jul  5 20:46:31 2015
From: la at tfc-server.de (ew)
Date: Sun, 05 Jul 2015 22:46:31 +0200
Subject: sdrangelove build issues on mipsel
In-Reply-To: <CAOkSjBhKcxDot8sugKiMor04fRHSwTa6X5vrHU6YJCHpxsSpVw@mail.gmail.com>
References: <CAOkSjBhKcxDot8sugKiMor04fRHSwTa6X5vrHU6YJCHpxsSpVw@mail.gmail.com>
Message-ID: <559997A7.20104@tfc-server.de>

I've pushed a change that should allow building on non-intel platforms, 
try building it from master.


From arturo.borrero.glez at gmail.com  Tue Jul  7 19:38:19 2015
From: arturo.borrero.glez at gmail.com (Arturo Borrero Gonzalez)
Date: Tue, 7 Jul 2015 21:38:19 +0200
Subject: sdrangelove build issues on mipsel
In-Reply-To: <559997A7.20104@tfc-server.de>
References: <CAOkSjBhKcxDot8sugKiMor04fRHSwTa6X5vrHU6YJCHpxsSpVw@mail.gmail.com>
 <559997A7.20104@tfc-server.de>
Message-ID: <CAOkSjBg0NerFXYm8iF-9UQuiZxNg84KZqWC68u+GNbtVr0Z+bw@mail.gmail.com>

On 5 July 2015 at 22:46, ew <la at tfc-server.de> wrote:
> I've pushed a change that should allow building on non-intel platforms, try
> building it from master.

This is what I get:

[...]
[ 21%] Building CXX object CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o
/usr/bin/c++   -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB
-DUSE_FFTW -Dsdrangelove_EXPORTS -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG
-fPIC -isystem /usr/include/mipsel-linux-gnu/qt5 -isystem
/usr/include/mipsel-linux-gnu/qt5/QtCore -isystem
/usr/lib/mipsel-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/mipsel-linux-gnu/qt5/QtWidgets -isystem
/usr/include/mipsel-linux-gnu/qt5/QtGui -isystem
/usr/include/mipsel-linux-gnu/qt5/QtOpenGL -isystem
/usr/include/mipsel-linux-gnu/qt5/QtMultimedia -isystem
/usr/include/mipsel-linux-gnu/qt5/QtNetwork
-I/tmp/buildd/sdrangelove-2test/obj-mipsel-linux-gnu
-I/tmp/buildd/sdrangelove-2test/include
-I/tmp/buildd/sdrangelove-2test/include-gpl    -fPIC -o
CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o -c
/tmp/buildd/sdrangelove-2test/sdrbase/dsp/interpolator.cpp
In file included from
/tmp/buildd/sdrangelove-2test/sdrbase/dsp/interpolator.cpp:4:0:
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h: In
member function 'void Interpolator::doInterpolate(int, Complex*)':
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:65:10:
error: '__m128' does not name a type
    const __m128* filter = (const __m128*)&m_alignedTaps[phase * m_nTaps * 2];
          ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:66:4:
error: '__m128' was not declared in this scope
    __m128 sum = _mm_setzero_ps();
    ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:70:5:
error: 'sum' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
     ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:70:54:
error: '_mm_loadu_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                      ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:70:58:
error: 'filter' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                          ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:70:64:
error: '_mm_mul_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                                ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:70:65:
error: '_mm_add_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                                 ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:19:
error: '__m64' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));
                   ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:25:
error: expected primary-expression before ')' token
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));
                         ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:45:
error: 'sum' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));
                                             ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:85:
error: '_mm_setzero_ps' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

              ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:110:
error: '_MM_SHUFFLE' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                       ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:111:
error: '_mm_shuffle_ps' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                        ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:112:
error: '_mm_add_ps' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                         ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:76:113:
error: '_mm_storel_pi' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                          ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:80:10:
error: '__m128' does not name a type
    const __m128* filter = (const __m128*)&m_alignedTaps[phase * m_nTaps * 2];
          ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:81:4:
error: '__m128' was not declared in this scope
    __m128 sum = _mm_setzero_ps();
    ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:89:5:
error: 'sum' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
     ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:89:54:
error: '_mm_loadu_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                      ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:89:58:
error: 'filter' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                          ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:89:64:
error: '_mm_mul_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                                ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:89:65:
error: '_mm_add_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                                 ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:95:5:
error: 'filter' was not declared in this scope
     filter = (const __m128*)&m_alignedTaps2[phase * m_nTaps * 2 +
todo * 4 - 4];
     ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:95:21:
error: ISO C++ forbids declaration of 'type name' with no type
[-fpermissive]
     filter = (const __m128*)&m_alignedTaps2[phase * m_nTaps * 2 +
todo * 4 - 4];
                     ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:95:15:
error: expected primary-expression before 'const'
     filter = (const __m128*)&m_alignedTaps2[phase * m_nTaps * 2 +
todo * 4 - 4];
               ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:95:15:
error: expected ')' before 'const'
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:102:5:
error: 'sum' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
     ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:102:54:
error: '_mm_loadu_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                      ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:102:58:
error: 'filter' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                          ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:102:64:
error: '_mm_mul_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                                ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:102:65:
error: '_mm_add_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadu_ps(src), *filter));
                                                                 ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:108:5:
error: 'sum' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadl_pi(_mm_setzero_ps(),
(const __m64*)src), filter[0]));
     ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:108:66:
error: '_mm_setzero_ps' was not declared in this scope
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadl_pi(_mm_setzero_ps(),
(const __m64*)src), filter[0]));
                                                                  ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:108:76:
error: ISO C++ forbids declaration of 'type name' with no type
[-fpermissive]
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadl_pi(_mm_setzero_ps(),
(const __m64*)src), filter[0]));
                                                                            ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:108:70:
error: expected primary-expression before 'const'
     sum = _mm_add_ps(sum, _mm_mul_ps(_mm_loadl_pi(_mm_setzero_ps(),
(const __m64*)src), filter[0]));
                                                                      ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:108:70:
error: expected ')' before 'const'
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:19:
error: '__m64' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));
                   ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:25:
error: expected primary-expression before ')' token
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));
                         ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:45:
error: 'sum' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));
                                             ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:85:
error: '_mm_setzero_ps' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

              ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:110:
error: '_MM_SHUFFLE' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                       ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:111:
error: '_mm_shuffle_ps' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                        ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:112:
error: '_mm_add_ps' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                         ^
/tmp/buildd/sdrangelove-2test/include-gpl/dsp/interpolator.h:112:113:
error: '_mm_storel_pi' was not declared in this scope
    _mm_storel_pi((__m64*)result, _mm_add_ps(sum, _mm_shuffle_ps(sum,
_mm_setzero_ps(), _MM_SHUFFLE(1, 0, 3, 2))));

                                          ^
CMakeFiles/sdrbase.dir/build.make:322: recipe for target
'CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o' failed
make[3]: *** [CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o] Error 1
make[3]: Leaving directory '/tmp/buildd/sdrangelove-2test/obj-mipsel-linux-gnu'
CMakeFiles/Makefile2:130: recipe for target 'CMakeFiles/sdrbase.dir/all' failed
make[2]: *** [CMakeFiles/sdrbase.dir/all] Error 2
make[2]: Leaving directory '/tmp/buildd/sdrangelove-2test/obj-mipsel-linux-gnu'
Makefile:78: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/tmp/buildd/sdrangelove-2test/obj-mipsel-linux-gnu'
[...]


-- 
Arturo Borrero Gonz?lez


From la at tfc-server.de  Tue Jul  7 20:31:51 2015
From: la at tfc-server.de (ew)
Date: Tue, 07 Jul 2015 22:31:51 +0200
Subject: sdrangelove build issues on mipsel
In-Reply-To: <CAOkSjBg0NerFXYm8iF-9UQuiZxNg84KZqWC68u+GNbtVr0Z+bw@mail.gmail.com>
References: <CAOkSjBhKcxDot8sugKiMor04fRHSwTa6X5vrHU6YJCHpxsSpVw@mail.gmail.com>
 <559997A7.20104@tfc-server.de>
 <CAOkSjBg0NerFXYm8iF-9UQuiZxNg84KZqWC68u+GNbtVr0Z+bw@mail.gmail.com>
Message-ID: <559C3737.80606@tfc-server.de>

Oops, looks like I managed to miss one define. Should be fixed now.



From h_ayguen at web.de  Tue Jul  7 22:24:16 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Wed, 8 Jul 2015 00:24:16 +0200
Subject: NBFM problem with rtl_fm on Raspberry Pi 2
Message-ID: <559C5190.8020101@web.de>


Hi,

i'm experiencing problems demodulating (NB)FM with rtl_fm, when
compiling directly on Raspberry Pi 2 with Raspbian: i just get noise!
WBFM does work. And i tested many things like calibration, frequency,
samplerate .. directly with a LPD (low power device).
rtl_tcp works nice with SDR# and i can verify the calibration with it.

In the end, i got paranoid and thought of compiler errors. So i tested
the same on a Raspberry Pi (1) B+ with same Raspbian image:
That works good. No problems!

Anyone else experiencing the same problem?
What is the solution?

kind regards,
Hayati





From picmaster at mail.bg  Tue Jul  7 23:23:10 2015
From: picmaster at mail.bg (Nikolay Dimitrov)
Date: Wed, 08 Jul 2015 02:23:10 +0300
Subject: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <559C5190.8020101@web.de>
References: <559C5190.8020101@web.de>
Message-ID: <559C5F5E.8060104@mail.bg>

Hi Hayati,

On 07/08/2015 01:24 AM, Hayati Ayguen wrote:
>
> Hi,
>
> i'm experiencing problems demodulating (NB)FM with rtl_fm, when
> compiling directly on Raspberry Pi 2 with Raspbian: i just get noise!
> WBFM does work. And i tested many things like calibration, frequency,
> samplerate .. directly with a LPD (low power device).
> rtl_tcp works nice with SDR# and i can verify the calibration with it.
>
> In the end, i got paranoid and thought of compiler errors. So i tested
> the same on a Raspberry Pi (1) B+ with same Raspbian image:
> That works good. No problems!
>
> Anyone else experiencing the same problem?
> What is the solution?
>
> kind regards,
> Hayati

Is the same code working OK on x86 machine for you?

Regards,
Nikolay


From h_ayguen at web.de  Tue Jul  7 23:29:42 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Wed, 8 Jul 2015 01:29:42 +0200
Subject: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <559C5F5E.8060104@mail.bg>
References: <559C5190.8020101@web.de> <559C5F5E.8060104@mail.bg>
Message-ID: <559C60E6.4020406@web.de>


Yes, same code works fine on x86_64 (LinuxMint).
But i want it to run on Raspberry Pi 2 for 24/7.
The Raspi B+ is just borrowed from a friend for testing .. and has less
CPU power to do other things in parallel :-(

kind regards,
Hayati

Am 08.07.2015 um 01:23 schrieb Nikolay Dimitrov:
> Hi Hayati,
>
> Is the same code working OK on x86 machine for you?
>
> Regards,
> Nikolay



From marcus.mueller at ettus.com  Wed Jul  8 06:30:26 2015
From: marcus.mueller at ettus.com (=?UTF-8?B?TWFyY3VzIE3DvGxsZXI=?=)
Date: Wed, 08 Jul 2015 08:30:26 +0200
Subject: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <559C60E6.4020406@web.de>
References: <559C5190.8020101@web.de> <559C5F5E.8060104@mail.bg>
 <559C60E6.4020406@web.de>
Message-ID: <559CC382.6080702@ettus.com>

Hi Hayati,

I'm totally not used to development on Raspbian, but:
It's really strange that running the same software on the same distro
with the same RF device would give different results.

So, debugging is on :/ I'd say you should use rtl_sdr to get raw IQ
samples, and then have a look at them on your PC. If they are ok, one
would have to look a bit deeper into rtl_fm, if not, something goes
wrong on the librtlsdr side of things.

Best regards,
Marcus

On 07/08/2015 01:29 AM, Hayati Ayguen wrote:
> Yes, same code works fine on x86_64 (LinuxMint).
> But i want it to run on Raspberry Pi 2 for 24/7.
> The Raspi B+ is just borrowed from a friend for testing .. and has less
> CPU power to do other things in parallel :-(
>
> kind regards,
> Hayati
>
> Am 08.07.2015 um 01:23 schrieb Nikolay Dimitrov:
>> Hi Hayati,
>>
>> Is the same code working OK on x86 machine for you?
>>
>> Regards,
>> Nikolay



From h_ayguen at web.de  Wed Jul  8 07:38:45 2015
From: h_ayguen at web.de (=?UTF-8?Q?=22Hayati_Ayg=C3=BCn=22?=)
Date: Wed, 8 Jul 2015 09:38:45 +0200
Subject: Aw: Re: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <559CC382.6080702@ettus.com>
References: <559C5190.8020101@web.de> <559C5F5E.8060104@mail.bg>
 <559C60E6.4020406@web.de>, <559CC382.6080702@ettus.com>
Message-ID: <trinity-51cb14fb-b49c-4546-9533-55c3891e9a7e-1436341125854@3capp-webde-bs27>

An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150708/b7ec6f0a/attachment.htm>

From mtologlu at hotmail.com  Wed Jul  8 07:54:36 2015
From: mtologlu at hotmail.com (Murat Tologlu)
Date: Wed, 8 Jul 2015 10:54:36 +0300
Subject: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <trinity-51cb14fb-b49c-4546-9533-55c3891e9a7e-1436341125854@3capp-webde-bs27>
References: <559C5190.8020101@web.de> <559C5F5E.8060104@mail.bg>
 <559C60E6.4020406@web.de>, <559CC382.6080702@ettus.com>
 <trinity-51cb14fb-b49c-4546-9533-55c3891e9a7e-1436341125854@3capp-webde-bs27>
Message-ID: <DUB123-DS1894C73BB92E33B3ADEA8DC4910@phx.gbl>

Hi Hayati,

 

Could you please mention which commit are you using from here: http://cgit.osmocom.org/rtl-sdr/log/ 

 

I am doing experiments with rtlsdr codebase on both RPi and X86 Ubuntu 14.04; I can check the NBFM issue you?ve mentioned.

 

Kind regards,

Murat, TA1DB 

 

From: osmocom-sdr [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of "Hayati Ayg?n"
Sent: Wednesday, July 08, 2015 10:39 AM
To: osmocom-sdr at lists.osmocom.org
Subject: Aw: Re: NBFM problem with rtl_fm on Raspberry Pi 2

 

 

Hi Marcus,

 

librtlsdr is OK, because rtl_tcp works fine, which transfers full I/Q spectrum of ~ 1.4 MHz to SDR# on Windows/PC.

The problem must lie in rtl_fm. By the way, the I/Q demodulation "raw" mode is erroneous, too, when having compiled on Raspberry Pi 2.

Something else i could try: use the binary compiled on Raspi 1 B+ on the Raspi 2. I'll check this, this evening.

 

Before going for painful debugging, it would be fine if someone else could reproduce the problem .. or say that it works fine.

 

kind regards,

Hayati

 

  

Gesendet: Mittwoch, 08. Juli 2015 um 08:30 Uhr
Von: "Marcus M?ller" <marcus.mueller at ettus.com>
An: osmocom-sdr at lists.osmocom.org
Betreff: Re: NBFM problem with rtl_fm on Raspberry Pi 2

Hi Hayati,

I'm totally not used to development on Raspbian, but:
It's really strange that running the same software on the same distro
with the same RF device would give different results.

So, debugging is on :/ I'd say you should use rtl_sdr to get raw IQ
samples, and then have a look at them on your PC. If they are ok, one
would have to look a bit deeper into rtl_fm, if not, something goes
wrong on the librtlsdr side of things.

Best regards,
Marcus

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

From h_ayguen at web.de  Wed Jul  8 09:39:56 2015
From: h_ayguen at web.de (=?UTF-8?Q?=22Hayati_Ayg=C3=BCn=22?=)
Date: Wed, 8 Jul 2015 11:39:56 +0200
Subject: Aw: RE: Re: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <DUB123-DS1894C73BB92E33B3ADEA8DC4910@phx.gbl>
References: <559C5190.8020101@web.de> <559C5F5E.8060104@mail.bg>
 <559C60E6.4020406@web.de>, <559CC382.6080702@ettus.com>
 <trinity-51cb14fb-b49c-4546-9533-55c3891e9a7e-1436341125854@3capp-webde-bs27>, 
 <DUB123-DS1894C73BB92E33B3ADEA8DC4910@phx.gbl>
Message-ID: <trinity-043c439b-39da-4e4f-b793-4a743af7f7c1-1436348396871@3capp-webde-bs27>

An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150708/55c51277/attachment.htm>

From arturo.borrero.glez at gmail.com  Wed Jul  8 17:55:18 2015
From: arturo.borrero.glez at gmail.com (Arturo Borrero Gonzalez)
Date: Wed, 8 Jul 2015 19:55:18 +0200
Subject: sdrangelove build issues on mipsel
In-Reply-To: <559C3737.80606@tfc-server.de>
References: <CAOkSjBhKcxDot8sugKiMor04fRHSwTa6X5vrHU6YJCHpxsSpVw@mail.gmail.com>
 <559997A7.20104@tfc-server.de>
 <CAOkSjBg0NerFXYm8iF-9UQuiZxNg84KZqWC68u+GNbtVr0Z+bw@mail.gmail.com>
 <559C3737.80606@tfc-server.de>
Message-ID: <CAOkSjBjrfSMqQrKGiFXrfWasrGksHzY0VTk-wktZ4+eQoUOevA@mail.gmail.com>

On 7 July 2015 at 22:31, ew <la at tfc-server.de> wrote:
> Oops, looks like I managed to miss one define. Should be fixed now.
>

Ok, tried again with no luck:

[...]
[ 38%] Building CXX object CMakeFiles/sdrbase.dir/sdrbase/gui/glspectrum.cpp.o
/usr/bin/c++   -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB
-DUSE_FFTW -Dsdrangelove_EXPORTS -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG
-fPIC -isystem /usr/include/mipsel-linux-gnu/qt5 -isystem
/usr/include/mipsel-linux-gnu/qt5/QtCore -isystem
/usr/lib/mipsel-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/mipsel-linux-gnu/qt5/QtWidgets -isystem
/usr/include/mipsel-linux-gnu/qt5/QtGui -isystem
/usr/include/mipsel-linux-gnu/qt5/QtOpenGL -isystem
/usr/include/mipsel-linux-gnu/qt5/QtMultimedia -isystem
/usr/include/mipsel-linux-gnu/qt5/QtNetwork
-I/tmp/buildd/sdrangelove-2test2/obj-mipsel-linux-gnu
-I/tmp/buildd/sdrangelove-2test2/include
-I/tmp/buildd/sdrangelove-2test2/include-gpl    -fPIC -o
CMakeFiles/sdrbase.dir/sdrbase/gui/glspectrum.cpp.o -c
/tmp/buildd/sdrangelove-2test2/sdrbase/gui/glspectrum.cpp
/tmp/buildd/sdrangelove-2test2/sdrbase/gui/glspectrum.cpp: In member
function 'void GLSpectrum::applyChanges()':
/tmp/buildd/sdrangelove-2test2/sdrbase/gui/glspectrum.cpp:1154:1:
error: insn does not satisfy its constraints:
 }
 ^
(call_insn 846 845 2999 73 (parallel [
            (call (mem:SI (reg:SI 1005) [0 setRange S4 A32])
                (const_int 16 [0x10]))
            (clobber (reg:SI 31 $31))
        ]) /tmp/buildd/sdrangelove-2test2/sdrbase/gui/glspectrum.cpp:915
594 {call_internal}
     (expr_list:REG_DEAD (reg:SI 1005)
        (expr_list:REG_DEAD (reg:SF 7 $7)
            (expr_list:REG_DEAD (reg:SF 6 $6)
                (expr_list:REG_DEAD (reg:SI 5 $5)
                    (expr_list:REG_DEAD (reg:SI 4 $4)
                        (expr_list:REG_EH_REGION (const_int 2 [0x2])
                            (nil)))))))
    (expr_list (use (reg:SI 79 $fakec))
        (expr_list (use (reg:SI 28 $28))
            (expr_list:SF (use (reg:SF 7 $7))
                (expr_list:SF (use (reg:SF 6 $6))
                    (expr_list:SI (use (reg:SI 5 $5))
                        (expr_list:SI (use (reg:SI 4 $4))
                            (nil))))))))
/tmp/buildd/sdrangelove-2test2/sdrbase/gui/glspectrum.cpp:1154:1:
internal compiler error: in extract_constrain_insn_cached, at
recog.c:2117
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
CMakeFiles/sdrbase.dir/build.make:713: recipe for target
'CMakeFiles/sdrbase.dir/sdrbase/gui/glspectrum.cpp.o' failed
make[3]: *** [CMakeFiles/sdrbase.dir/sdrbase/gui/glspectrum.cpp.o] Error 1
make[3]: Leaving directory '/tmp/buildd/sdrangelove-2test2/obj-mipsel-linux-gnu'
CMakeFiles/Makefile2:130: recipe for target 'CMakeFiles/sdrbase.dir/all' failed
[...]

-- 
Arturo Borrero Gonz?lez


From la at tfc-server.de  Wed Jul  8 19:08:48 2015
From: la at tfc-server.de (ew)
Date: Wed, 08 Jul 2015 21:08:48 +0200
Subject: sdrangelove build issues on mipsel
In-Reply-To: <CAOkSjBjrfSMqQrKGiFXrfWasrGksHzY0VTk-wktZ4+eQoUOevA@mail.gmail.com>
References: <CAOkSjBhKcxDot8sugKiMor04fRHSwTa6X5vrHU6YJCHpxsSpVw@mail.gmail.com>
 <559997A7.20104@tfc-server.de>
 <CAOkSjBg0NerFXYm8iF-9UQuiZxNg84KZqWC68u+GNbtVr0Z+bw@mail.gmail.com>
 <559C3737.80606@tfc-server.de>
 <CAOkSjBjrfSMqQrKGiFXrfWasrGksHzY0VTk-wktZ4+eQoUOevA@mail.gmail.com>
Message-ID: <559D7540.3040404@tfc-server.de>

Your compiler is broken, there is nothing I can do about that, but you 
could try clang or a newer version of gcc.


From h_ayguen at web.de  Wed Jul  8 19:17:26 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Wed, 8 Jul 2015 21:17:26 +0200
Subject: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <trinity-51cb14fb-b49c-4546-9533-55c3891e9a7e-1436341125854@3capp-webde-bs27>
References: <559C5190.8020101@web.de> <559C5F5E.8060104@mail.bg>
 <559C60E6.4020406@web.de> <559CC382.6080702@ettus.com>
 <trinity-51cb14fb-b49c-4546-9533-55c3891e9a7e-1436341125854@3capp-webde-bs27>
Message-ID: <559D7746.9040308@web.de>


Hello,

now tested the binary compiled on RPi 1 on the RPi 2 - after copying the
full source including build directory of cmake and executing "sudo make
install" on the RPi 2.

The result: this works fine!
Do i have to conclude, that Raspbian's g++/gcc compiler does produce
wrong code when executed on RPi 2 ?!
gcc/g++ (Debian 4.6.3-14+rpi1) 4.6.3

OK, now verify: make clean, rebuild and install new binary (from the
build directory copied from RPi 1):
this works!  but, i don't understand why!
Now reboot, so that kernel module reloads:  still works!

In the end, i'm happy that it works "somehow". But, i've no idea where
the problem lies!

kind regards,
Hayati


Am 08.07.2015 um 09:38 schrieb "Hayati Ayg?n":
>  
> Hi Marcus,
>  
> librtlsdr is OK, because rtl_tcp works fine, which transfers full I/Q
> spectrum of ~ 1.4 MHz to SDR# on Windows/PC.
> The problem must lie in rtl_fm. By the way, the I/Q demodulation "raw"
> mode is erroneous, too, when having compiled on Raspberry Pi 2.
> Something else i could try: use the binary compiled on Raspi 1 B+ on
> the Raspi 2. I'll check this, this evening.
>  
> Before going for painful debugging, it would be fine if someone else
> could reproduce the problem .. or say that it works fine.
>  
> kind regards,
> Hayati
>  
>  
> *Gesendet:* Mittwoch, 08. Juli 2015 um 08:30 Uhr
> *Von:* "Marcus M?ller" <marcus.mueller at ettus.com>
> *An:* osmocom-sdr at lists.osmocom.org
> *Betreff:* Re: NBFM problem with rtl_fm on Raspberry Pi 2
> Hi Hayati,
>
> I'm totally not used to development on Raspbian, but:
> It's really strange that running the same software on the same distro
> with the same RF device would give different results.
>
> So, debugging is on :/ I'd say you should use rtl_sdr to get raw IQ
> samples, and then have a look at them on your PC. If they are ok, one
> would have to look a bit deeper into rtl_fm, if not, something goes
> wrong on the librtlsdr side of things.
>
> Best regards,
> Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150708/2908af7a/attachment.htm>

From uhakansson at tecore.com  Tue Jul 14 16:11:59 2015
From: uhakansson at tecore.com (Urban Hakansson)
Date: Tue, 14 Jul 2015 12:11:59 -0400 (EDT)
Subject: osmocom app GUIs don't look correct
In-Reply-To: <1003959607.2968474.1436889254934.JavaMail.root@tecore.com>
Message-ID: <904728263.2969231.1436890319665.JavaMail.root@tecore.com>

Hi everybody, 

I have a problem. 

Yesterday I installed Fedora 20 (x86_64) laptop the following, bladeRF from nuand, and UHD + GnuRadio + gr-osmosdr + gr-iqbal etc... using Marcus Leech's build-gnuradio script. 
"$ wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && ./build-gnuradio" 

I know have installed the following versions. 

1) bladeRF: 
libbladeRF 1.4.0 
bladeRF-cli 1.2.0 
FPGA: 0.3.0 
Firmware: 1.8.0 

GnuRadio 3.7.7 
UHD 3.9.0 

I am running the osmocom_fft utility on both the Ettus B210 and the bladeRF. 

osmocom_fft -a bladerf=0 -s 1M -f 947M 
osmocom_fft -a uhd -s 1M -f 947M 

Both seem to be running fine except that the GUI does not look correct. 

Please see attached images showing two screen shots of the osmocom_fft GUI. 

Nuand bladeRF: Center Frequency and Gain Settings are messed up. Text and sliders missing, and the boxes with the actual values are not in the right location. 

Ettus B210: Center Frequency and RX Gain are messed up.Text and sliders missing, and the boxes with the actual values are not in the right location. 

Side note: uhd_fft runs without any problems (on the B210) and the GUI looks correct. Nothing is missing or in a strange location on the screen. 

What can be causing this? How can I fix it? 

Thank you for your consideration 

Reagards, 


Urban Hakansson 
Senior Software Engineer 
Tecore Networks 
Phone: +1 410 872 6315 
Fax: +1 410 872 6010 
Email: uhakansson at tecore.com 


                                                                                                                                                                                                                                       This e-mail may contain privileged, confidential, copyrighted or other legally protected information, and is intended exclusively for the intended recipient.  If you are not the intended recipient (even if the e-mail address above is yours), you may not review, store, use, copy, disclose or retransmit it in any form.  If you are not the intended recipient or otherwise have received this by mistake, please immediately notify the sender by return e-mail (or sysadmin at tecore.com), then delete the message in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150714/04c87962/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 57.png
Type: image/png
Size: 77886 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150714/04c87962/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 13.png
Type: image/png
Size: 78893 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150714/04c87962/attachment-0001.png>

From h_ayguen at web.de  Wed Jul 15 06:26:29 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Wed, 15 Jul 2015 08:26:29 +0200
Subject: NBFM problem with rtl_fm on Raspberry Pi 2
In-Reply-To: <559D7746.9040308@web.de>
References: <559C5190.8020101@web.de> <559C5F5E.8060104@mail.bg>
 <559C60E6.4020406@web.de> <559CC382.6080702@ettus.com>
 <trinity-51cb14fb-b49c-4546-9533-55c3891e9a7e-1436341125854@3capp-webde-bs27>
 <559D7746.9040308@web.de>
Message-ID: <55A5FD15.6030203@web.de>


Hello,

there's no NBFM demodulation problem when using Debian Jessie on Raspi2
http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/

and compiling everything necessary on thr Raspi2 itself.
This distri comes with gcc 4.9.2.
Thanks to Murat for his tip to try Jessie.

Now i get useful audio - with some noise in the background, what i have
to check with raw mode.
But it's now understandable audio, what wasn't the case with Raspbian
(based on Debian Wheezy, coming with gcc 4.6.3).

kind regards,
Hayati


Am 08.07.2015 um 21:17 schrieb Hayati Ayguen:
>
> Hello,
>
> now tested the binary compiled on RPi 1 on the RPi 2 - after copying
> the full source including build directory of cmake and executing "sudo
> make install" on the RPi 2.
>
> The result: this works fine!
> Do i have to conclude, that Raspbian's g++/gcc compiler does produce
> wrong code when executed on RPi 2 ?!
> gcc/g++ (Debian 4.6.3-14+rpi1) 4.6.3
>
> OK, now verify: make clean, rebuild and install new binary (from the
> build directory copied from RPi 1):
> this works!  but, i don't understand why!
> Now reboot, so that kernel module reloads:  still works!
>
> In the end, i'm happy that it works "somehow". But, i've no idea where
> the problem lies!
>
> kind regards,
> Hayati
>
>
> Am 08.07.2015 um 09:38 schrieb "Hayati Ayg?n":
>>  
>> Hi Marcus,
>>  
>> librtlsdr is OK, because rtl_tcp works fine, which transfers full I/Q
>> spectrum of ~ 1.4 MHz to SDR# on Windows/PC.
>> The problem must lie in rtl_fm. By the way, the I/Q demodulation
>> "raw" mode is erroneous, too, when having compiled on Raspberry Pi 2.
>> Something else i could try: use the binary compiled on Raspi 1 B+ on
>> the Raspi 2. I'll check this, this evening.
>>  
>> Before going for painful debugging, it would be fine if someone else
>> could reproduce the problem .. or say that it works fine.
>>  
>> kind regards,
>> Hayati
>>  
>>  
>> *Gesendet:* Mittwoch, 08. Juli 2015 um 08:30 Uhr
>> *Von:* "Marcus M?ller" <marcus.mueller at ettus.com>
>> *An:* osmocom-sdr at lists.osmocom.org
>> *Betreff:* Re: NBFM problem with rtl_fm on Raspberry Pi 2
>> Hi Hayati,
>>
>> I'm totally not used to development on Raspbian, but:
>> It's really strange that running the same software on the same distro
>> with the same RF device would give different results.
>>
>> So, debugging is on :/ I'd say you should use rtl_sdr to get raw IQ
>> samples, and then have a look at them on your PC. If they are ok, one
>> would have to look a bit deeper into rtl_fm, if not, something goes
>> wrong on the librtlsdr side of things.
>>
>> Best regards,
>> Marcus
>

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

From john at tonebridge.com  Wed Jul 15 11:52:47 2015
From: john at tonebridge.com (John)
Date: Wed, 15 Jul 2015 06:52:47 -0500
Subject: Heatmap with unwanted vertical lines
Message-ID: <55A6498F.1050802@tonebridge.com>

Hello,

When I use heatmap.py with output from rtl_power I get regularly spaced 
vertical lines that do not appear to be related to any signal.  They 
look they like repeat at the dongle bandwidth (2048000Hz in this case).  
The crop option for rtl_power reduces the presence but I am not sure f 
that is intended by that option.  Even at -c of 70% they are still there 
(see attachment).

Is this because of small bin width?  If I use a larger bin (32k) they 
are still there.  In this case there is no frequency legend along top so 
can't compare if they happen more often.

Are these lines expected?  Can they be removed?

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: airband2_16k_d0_i2_c70.jpg
Type: image/jpeg
Size: 156132 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150715/aff5f502/attachment.jpg>

From picmaster at mail.bg  Wed Jul 15 13:03:43 2015
From: picmaster at mail.bg (Nikolay Dimitrov)
Date: Wed, 15 Jul 2015 16:03:43 +0300
Subject: Heatmap with unwanted vertical lines
In-Reply-To: <55A6498F.1050802@tonebridge.com>
References: <55A6498F.1050802@tonebridge.com>
Message-ID: <55A65A2F.40009@mail.bg>

Hi John,

Put a 50- or 75-ohm termination on the rtl-sdr antenna connector and
redo the plot, to see whether the beat-frequencies are generated inside
or outside your dongle.

Next you can put a bandpass filter in front of your rtl-sdr dongle, in
order to reduce the out-of-band signals that probably overload your
front-end. In practice, we shouldn't be using any RF device without
input and output bandpass filters.

Next, you can also try putting an rf choke/ferrite (a common-mode
transformer) on the USB cable, in order to reduce the noise coming from
the USB-host and through the cable.

Next, putting the dongle inside a metallic enclosure will help
screening the RF circuits, and will allow it to receive signals only
through the input connector (and preferably through an input bandpass
filter). You can create an effective "poor man's enclosure" by cutting
and soldering pieces of double-sided PCB.

Finally, you can test your dongle with Linrad with its patched version
of librtlsdr. Linrad uses a different gain distribution and there's a
big chance that it can satisfy your needs. You can do similar
experiments by reducing the RF gain and AGC on rtl_power and see
whether it influences positively your measurements. Please try these
and share your experience.

Regards,
Nikolay


On 07/15/2015 02:52 PM, John wrote:
> Hello,
>
> When I use heatmap.py with output from rtl_power I get regularly spaced
> vertical lines that do not appear to be related to any signal.  They
> look they like repeat at the dongle bandwidth (2048000Hz in this case).
> The crop option for rtl_power reduces the presence but I am not sure f
> that is intended by that option.  Even at -c of 70% they are still there
> (see attachment).
>
> Is this because of small bin width?  If I use a larger bin (32k) they
> are still there.  In this case there is no frequency legend along top so
> can't compare if they happen more often.
>
> Are these lines expected?  Can they be removed?
>
> John


From john at tonebridge.com  Wed Jul 15 14:45:41 2015
From: john at tonebridge.com (John)
Date: Wed, 15 Jul 2015 09:45:41 -0500
Subject: Heatmap with unwanted vertical lines
In-Reply-To: <55A65A2F.40009@mail.bg>
References: <55A6498F.1050802@tonebridge.com>
	<55A65A2F.40009@mail.bg>
Message-ID: <CANUwEqkEQQapVjmXDKNYXWO=GvExfmHnEcHk0mUqKA8wgJYr+A@mail.gmail.com>

Thanks for the steps!  I will post results.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150715/6fbea087/attachment.htm>

From h_ayguen at web.de  Fri Jul 17 23:02:18 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Sat, 18 Jul 2015 01:02:18 +0200
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
Message-ID: <55A9897A.7020305@web.de>


Hi,

after i got rtl_fm run on Raspi 2 with Debian Jessie .. now i have some
additional noise in the FM demodulated audio!

With a "raw" recording (see attachment) i can see an additional carrier
at the DC frequency of the demodulated output. That corresponds to the
tuned frequency (= 433.25 MHz) parametrized to rtl_fm.
Due to calibration error, the FM carrier has some offset: ~ -1.3 kHz as
visible in screenshot.
The DC carrier does demodulate to some distortion!

Option "-E dc" does not help, cause that removes a DC in the demodulated
output. An additional option to filter DC before demodulation does help
a bit .. but does not solve the problem, which looks to be introduced
earlier ..

I would not have expected such a DC, cause IMHO it's produced whilst
downconversion or filtering.
It's not the RTL dongle's DC, which should be far far away by 1/4 of the
high samplerate.

Someone else seen this problem?
Does anyone have a useful solution?

kind regards,
Hayati

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl_fm_raw_mode_with_LPD.png
Type: image/png
Size: 101946 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150718/370739d8/attachment.png>

From mtologlu at hotmail.com  Sat Jul 18 06:45:13 2015
From: mtologlu at hotmail.com (Murat Tologlu)
Date: Sat, 18 Jul 2015 09:45:13 +0300
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
In-Reply-To: <55A9897A.7020305@web.de>
References: <55A9897A.7020305@web.de>
Message-ID: <DUB123-DS20EA6E7C0F6AADF68BF50AC4870@phx.gbl>

Dear Hayati,

I am glad to see that my Debian-Jessie suggestion helped you to progress.

Regarding your recent question: If I don't understand wrong, This is a well-known problem called as DC Spike which exist more or less in all SDR receivers. . Dr. Wickert of UCCS has an excellent laboratory note on RTL-SDR also explains this nature (see page 7) :  http://www.eas.uccs.edu/wickert/ece4670/lecture_notes/Lab6.pdf You can reach Dr. Wickert's other DSP notes from here: http://www.eas.uccs.edu/wickert/index.shtml 

DC Spike comes from analog front end of the RTL-SDR dongle and we can talk about several solutions. First and the easiest solution is to move the center frequency a bit up and down to avoid interference with DC spike (this is called as offset tuning). Some hardware manufacturer claim that they manufacture better quality thus lower DC spike sdr chips and boards. You may also consider a software "notch filter" to reduce the DC spike !

Kind regards,
Murat 

-----Original Message-----
From: osmocom-sdr [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Hayati Ayguen
Sent: Saturday, July 18, 2015 2:02 AM
To: osmocom-sdr at lists.osmocom.org
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?


Hi,

after i got rtl_fm run on Raspi 2 with Debian Jessie .. now i have some additional noise in the FM demodulated audio!

With a "raw" recording (see attachment) i can see an additional carrier at the DC frequency of the demodulated output. That corresponds to the tuned frequency (= 433.25 MHz) parametrized to rtl_fm.
Due to calibration error, the FM carrier has some offset: ~ -1.3 kHz as visible in screenshot.
The DC carrier does demodulate to some distortion!

Option "-E dc" does not help, cause that removes a DC in the demodulated output. An additional option to filter DC before demodulation does help a bit .. but does not solve the problem, which looks to be introduced earlier ..

I would not have expected such a DC, cause IMHO it's produced whilst downconversion or filtering.
It's not the RTL dongle's DC, which should be far far away by 1/4 of the high samplerate.

Someone else seen this problem?
Does anyone have a useful solution?

kind regards,
Hayati




From h_ayguen at web.de  Sat Jul 18 08:54:48 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Sat, 18 Jul 2015 10:54:48 +0200
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
In-Reply-To: <DUB123-DS20EA6E7C0F6AADF68BF50AC4870@phx.gbl>
References: <55A9897A.7020305@web.de>
 <DUB123-DS20EA6E7C0F6AADF68BF50AC4870@phx.gbl>
Message-ID: <55AA1458.2060205@web.de>


Hi Murat and all others,

what i have hear is definitely NOT the DC spike coming from the analog
front-end!

Whilst my experiments, trying to get rtl_fm run on Raspi 2, i added an
option to rtl_fm to be verbose ("-v 1"). See
https://github.com/hayguen/librtlsdr

When calling rtl_fm with "-s 24000 -f 433.25M -M raw" i get following
outputs:
"capture_rate = 42 * 24000 = 1008000"
"capture_freq = freq + capture_rate / 4 = 433502000"


>From capture_rate you see, that the RTL's ADC works at a samplerate of
1.008 MHz. And the RTL is parametrized to 433.502 MHz.
So, the RTL's DC is at 433.502 MHz - far away from the desired 433.25 MHz.
On digital signal preprocessing the rtl_fm mixes the desired frequency
up to baseband 0 Hz and the does low pass filtering and decimation to
the samplerate of 24 kHz.
This result is what i recorded in my previous mail and had a look with
SDR#, the screenshot.

At the moment, I had no look into the source of low pass filter. I
suppose that the DC is introduced here.

kind regards,
Hayati



Am 18.07.2015 um 08:45 schrieb Murat Tologlu:
> Dear Hayati,
> 
> I am glad to see that my Debian-Jessie suggestion helped you to progress.
> 
> Regarding your recent question: If I don't understand wrong, This is a well-known problem called as DC Spike which exist more or less in all SDR receivers. . Dr. Wickert of UCCS has an excellent laboratory note on RTL-SDR also explains this nature (see page 7) :  http://www.eas.uccs.edu/wickert/ece4670/lecture_notes/Lab6.pdf You can reach Dr. Wickert's other DSP notes from here: http://www.eas.uccs.edu/wickert/index.shtml 
> 
> DC Spike comes from analog front end of the RTL-SDR dongle and we can talk about several solutions. First and the easiest solution is to move the center frequency a bit up and down to avoid interference with DC spike (this is called as offset tuning). Some hardware manufacturer claim that they manufacture better quality thus lower DC spike sdr chips and boards. You may also consider a software "notch filter" to reduce the DC spike !
> 
> Kind regards,
> Murat 
> 
> -----Original Message-----
> From: osmocom-sdr [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Hayati Ayguen
> Sent: Saturday, July 18, 2015 2:02 AM
> To: osmocom-sdr at lists.osmocom.org
> Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
> 
> 
> Hi,
> 
> after i got rtl_fm run on Raspi 2 with Debian Jessie .. now i have some additional noise in the FM demodulated audio!
> 
> With a "raw" recording (see attachment) i can see an additional carrier at the DC frequency of the demodulated output. That corresponds to the tuned frequency (= 433.25 MHz) parametrized to rtl_fm.
> Due to calibration error, the FM carrier has some offset: ~ -1.3 kHz as visible in screenshot.
> The DC carrier does demodulate to some distortion!
> 
> Option "-E dc" does not help, cause that removes a DC in the demodulated output. An additional option to filter DC before demodulation does help a bit .. but does not solve the problem, which looks to be introduced earlier ..
> 
> I would not have expected such a DC, cause IMHO it's produced whilst downconversion or filtering.
> It's not the RTL dongle's DC, which should be far far away by 1/4 of the high samplerate.
> 
> Someone else seen this problem?
> Does anyone have a useful solution?
> 
> kind regards,
> Hayati
> 
> 


From picmaster at mail.bg  Sat Jul 18 10:03:25 2015
From: picmaster at mail.bg (Nikolay Dimitrov)
Date: Sat, 18 Jul 2015 13:03:25 +0300
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
In-Reply-To: <55A9897A.7020305@web.de>
References: <55A9897A.7020305@web.de>
Message-ID: <55AA246D.2050700@mail.bg>

Hi Hayati,

On 07/18/2015 02:02 AM, Hayati Ayguen wrote:
>
> Hi,
>
> after i got rtl_fm run on Raspi 2 with Debian Jessie .. now i have some
> additional noise in the FM demodulated audio!
>
> With a "raw" recording (see attachment) i can see an additional carrier
> at the DC frequency of the demodulated output. That corresponds to the
> tuned frequency (= 433.25 MHz) parametrized to rtl_fm.
> Due to calibration error, the FM carrier has some offset: ~ -1.3 kHz as
> visible in screenshot.
> The DC carrier does demodulate to some distortion!
>
> Option "-E dc" does not help, cause that removes a DC in the demodulated
> output. An additional option to filter DC before demodulation does help
> a bit .. but does not solve the problem, which looks to be introduced
> earlier ..
>
> I would not have expected such a DC, cause IMHO it's produced whilst
> downconversion or filtering.
> It's not the RTL dongle's DC, which should be far far away by 1/4 of the
> high samplerate.
>
> Someone else seen this problem?
> Does anyone have a useful solution?

You need IQ calibration.

When calibrated, spectrum should look much cleaner, signals should
appear only on 1 place of the waterfall/spectrum display, and the LO
carrier (the so-called DC) will be much better suppressed, although not
completely removed (that's why the -dc option exists for the baseband
processing).

Regards,
Nikolay


From h_ayguen at web.de  Sat Jul 18 10:15:25 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Sat, 18 Jul 2015 12:15:25 +0200
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
In-Reply-To: <55AA246D.2050700@mail.bg>
References: <55A9897A.7020305@web.de> <55AA246D.2050700@mail.bg>
Message-ID: <55AA273D.9060204@web.de>


Hi Nikolay,

i don't see any option to do IQ calibration in rtl_fm !?

As i wrote to Murat, the DC is NOT the LO !
The spectrum already looks clean. I don't have a problem with the symmetry.
The "dc" option does work too late: after demodulation.

kind regards,
Hayati


Am 18.07.2015 um 12:03 schrieb Nikolay Dimitrov:
>
> You need IQ calibration.
>
> When calibrated, spectrum should look much cleaner, signals should
> appear only on 1 place of the waterfall/spectrum display, and the LO
> carrier (the so-called DC) will be much better suppressed, although not
> completely removed (that's why the -dc option exists for the baseband
> processing).
>
> Regards,
> Nikolay




From h_ayguen at web.de  Sat Jul 18 14:06:53 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Sat, 18 Jul 2015 16:06:53 +0200
Subject: how/where to merge code
Message-ID: <55AA5D7D.9060606@web.de>


Hi,

just wanted to ask, what to do, so that my changes on
https://github.com/hayguen/librtlsdr  get  merged into
https://github.com/steve-m/librtlsdr  ?

Just now, in this moment, i realize, that there's alos
git://git.osmocom.org/rtl-sdr.git referenced at
http://sdr.osmocom.org/trac/wiki/rtl-sdr

Ok, which is the real origin for rtl-sdr?
What is needed to get the changes there?


Besides the changes on rtl_fm i've developed a small tool, i called
"stdin2wav". It's used by piping rtl_fm's output into stdin2wav, which
then saves the output into wave files using libsndfile.
Besides saving, it can be combined with the squelch function of rtl_fm.
stdin2wav closes the wave file when no more data comes from stdin .. and
re-opens a new wave file when new data arrives, cause the squelch opened ..

Can/should this small tool also merged to rtl-sdr? Someone has a better
place?
By the way: someone has a better name?


kind regards,
Hayati



From marcus.mueller at ettus.com  Sat Jul 18 14:26:16 2015
From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=)
Date: Sat, 18 Jul 2015 16:26:16 +0200
Subject: how/where to merge code
In-Reply-To: <55AA5D7D.9060606@web.de>
References: <55AA5D7D.9060606@web.de>
Message-ID: <55AA6208.6050700@ettus.com>

Hi Hayati,

I'm pretty sure git.osmocom.org is the upstream; to ask steve-m to merge 
your changes into his repository, just log on to github, go to 
https://github.com/hayguen/librtlsdr, and you should see something like
"This branch is 2 commits ahead of steve-m:master    Pull Request"
right at the top, just under the header where you can select your branch.

The Impressum of osmocom.org said to send in patches via this mailing 
list, so that's what I did once, and that worked too :), so assuming 
steve-m's repo is called "steve-m" in your git ("git remote -v" will 
tell), and the modified master branch being currently checked out

git format-patch steve-m/master

will generate a patch file for each commit between your master's HEAD 
and steve-m/master.

Greetings,
Marcus


On 18.07.2015 16:06, Hayati Ayguen wrote:
> Hi,
>
> just wanted to ask, what to do, so that my changes on
> https://github.com/hayguen/librtlsdr  get  merged into
> https://github.com/steve-m/librtlsdr  ?
>
> Just now, in this moment, i realize, that there's alos
> git://git.osmocom.org/rtl-sdr.git referenced at
> http://sdr.osmocom.org/trac/wiki/rtl-sdr
>
> Ok, which is the real origin for rtl-sdr?
> What is needed to get the changes there?
>
>
> Besides the changes on rtl_fm i've developed a small tool, i called
> "stdin2wav". It's used by piping rtl_fm's output into stdin2wav, which
> then saves the output into wave files using libsndfile.
> Besides saving, it can be combined with the squelch function of rtl_fm.
> stdin2wav closes the wave file when no more data comes from stdin .. and
> re-opens a new wave file when new data arrives, cause the squelch opened ..
>
> Can/should this small tool also merged to rtl-sdr? Someone has a better
> place?
> By the way: someone has a better name?
>
>
> kind regards,
> Hayati
>



From h_ayguen at web.de  Sat Jul 18 15:12:24 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Sat, 18 Jul 2015 17:12:24 +0200
Subject: how/where to merge code: patch files
In-Reply-To: <55AA6208.6050700@ettus.com>
References: <55AA5D7D.9060606@web.de> <55AA6208.6050700@ettus.com>
Message-ID: <55AA6CD8.4020307@web.de>


Hi Osmocom guys,

please consider merging the 2 attached patches.

The first patch:

added option -L to print current level values
added option -c to configure de-emphasis time constant for wbfm
added option -v to print verbose (debug) output
added alias modulation names nbfm, nfm, wfm

now the options in detail:

option -L:
"rtl_fm -L 10 -M fm": prints current level to stderr, every 10th
calculation. This allows monitoring of the noise (or signal) level, to
help setting an optimal squelch threshold.

option -c:
"rtl_fm -M wbfm -c 50" uses de-emphasis time constant for europe.
One might also write "-c us" to use the north american 75 microSec standard.
"-c eu" will use the european 50 microSec standard.

option -v:
"rtl_fm -v 1 -f 99.3M" displays verbose debug information on calculation
of frequency, so that user might understand how/what frequency is tuned to.

modulation names:
found myself writing "wfm" instead of "wbfm". now the aliases are also
accepted.



The second patch:

added dc filter on raw data (after decimation) with option "-E rdc"
added option "-q" for setting averaging speed for "rdc"
added option "-E adc" in addition to "-E dc"

Please have a look in my previous mail with subject
"rtl_fm: degraded demodulation caused by self-introduced DC !?"
to understand the reason for a second dc filter.


kind regards,
Hayati



Am 18.07.2015 um 16:26 schrieb Marcus M?ller:
> Hi Hayati,
> 
> I'm pretty sure git.osmocom.org is the upstream; to ask steve-m to merge
> your changes into his repository, just log on to github, go to
> https://github.com/hayguen/librtlsdr, and you should see something like
> "This branch is 2 commits ahead of steve-m:master    Pull Request"
> right at the top, just under the header where you can select your branch.
> 
> The Impressum of osmocom.org said to send in patches via this mailing
> list, so that's what I did once, and that worked too :), so assuming
> steve-m's repo is called "steve-m" in your git ("git remote -v" will
> tell), and the modified master branch being currently checked out
> 
> git format-patch steve-m/master
> 
> will generate a patch file for each commit between your master's HEAD
> and steve-m/master.
> 
> Greetings,
> Marcus
> 
> 
> On 18.07.2015 16:06, Hayati Ayguen wrote:
>> Hi,
>>
>> just wanted to ask, what to do, so that my changes on
>> https://github.com/hayguen/librtlsdr  get  merged into
>> https://github.com/steve-m/librtlsdr  ?
>>
>> Just now, in this moment, i realize, that there's alos
>> git://git.osmocom.org/rtl-sdr.git referenced at
>> http://sdr.osmocom.org/trac/wiki/rtl-sdr
>>
>> Ok, which is the real origin for rtl-sdr?
>> What is needed to get the changes there?
>>
>>
>> Besides the changes on rtl_fm i've developed a small tool, i called
>> "stdin2wav". It's used by piping rtl_fm's output into stdin2wav, which
>> then saves the output into wave files using libsndfile.
>> Besides saving, it can be combined with the squelch function of rtl_fm.
>> stdin2wav closes the wave file when no more data comes from stdin .. and
>> re-opens a new wave file when new data arrives, cause the squelch
>> opened ..
>>
>> Can/should this small tool also merged to rtl-sdr? Someone has a better
>> place?
>> By the way: someone has a better name?
>>
>>
>> kind regards,
>> Hayati
>>
> 
-------------- next part --------------
From 4a0e25ba41fc81f29ddd84aa5dbf2bbc1358dbbb Mon Sep 17 00:00:00 2001
From: Hayati Ayguen <h_ayguen at web.de>
Date: Sun, 14 Jun 2015 02:17:40 +0200
Subject: [PATCH 1/2] added option -L to print current level values added
 option -c to configure de-emphasis time constant for wbfm added option -v to
 print verbose (debug) output added alias modulation names nbfm, nfm, wfm

---
 src/rtl_fm.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 74 insertions(+), 8 deletions(-)

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index 0f7ac38..8cf95f0 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2012 by Hoernchen <la at tfc-server.de>
  * Copyright (C) 2012 by Kyle Keen <keenerd at gmail.com>
  * Copyright (C) 2013 by Elias Oenal <EliasOenal at gmail.com>
+ * Copyright (C) 2015 by Hayati Ayguen <h_ayguen at web.de>
  *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -92,6 +93,13 @@ static int *atan_lut = NULL;
 static int atan_lut_size = 131072; /* 512 KB */
 static int atan_lut_coef = 8;
 
+static int verbosity = 0;
+static int printLevels = 0;
+static int printLevelNo = 1;
+static int levelMax = 0;
+static int levelMaxMax = 0;
+static double levelSum = 0.0;
+
 struct dongle_state
 {
 	int      exit_flag;
@@ -187,16 +195,21 @@ void usage(void)
 		"\t-f frequency_to_tune_to [Hz]\n"
 		"\t    use multiple -f for scanning (requires squelch)\n"
 		"\t    ranges supported, -f 118M:137M:25k\n"
+		"\t[-v verbosity (default: 0)]\n"
 		"\t[-M modulation (default: fm)]\n"
-		"\t    fm, wbfm, raw, am, usb, lsb\n"
+		"\t    fm or nbfm or nfm, wbfm or wfm, raw or iq, am, usb, lsb\n"
 		"\t    wbfm == -M fm -s 170k -o 4 -A fast -r 32k -l 0 -E deemp\n"
 		"\t    raw mode outputs 2x16 bit IQ pairs\n"
 		"\t[-s sample_rate (default: 24k)]\n"
 		"\t[-d device_index (default: 0)]\n"
 		"\t[-g tuner_gain (default: automatic)]\n"
 		"\t[-l squelch_level (default: 0/off)]\n"
+		"\t[-L N  prints levels every N calculations]\n"
+		"\t    output are comma separated values (csv):\n"
+		"\t    mean since last output, max since last output, overall max, squelch\n"
+		"\t[-c de-emphasis_time_constant in us for wbfm. 'us' or 'eu' for 75/50 us (default: us)]\n"
 		//"\t    for fm squelch is inverted\n"
-		//"\t[-o oversampling (default: 1, 4 recommended)]\n"
+		"\t[-o oversampling (default: 1, 4 recommended)]\n"
 		"\t[-p ppm_error (default: 0)]\n"
 		"\t[-E enable_option (default: none)]\n"
 		"\t    use multiple -E to enable multiple options\n"
@@ -759,6 +772,24 @@ void full_demod(struct demod_state *d)
 		} else {
 			d->squelch_hits = 0;}
 	}
+
+	if (printLevels) {
+		if (!sr)
+			sr = rms(d->lowpassed, d->lp_len, 1);
+		--printLevelNo;
+		if (printLevels) {
+			levelSum += sr;
+			if (levelMax < sr)		levelMax = sr;
+			if (levelMaxMax < sr)	levelMaxMax = sr;
+			if  (!printLevelNo) {
+				printLevelNo = printLevels;
+				fprintf(stderr, "%f, %d, %d, %d\n", (levelSum / printLevels), levelMax, levelMaxMax, d->squelch_level );
+				levelMax = 0;
+				levelSum = 0;
+			}
+		}
+	}
+
 	d->mode_demod(d);  /* lowpassed -> result */
 	if (d->mode_demod == &raw_demod) {
 		return;
@@ -864,9 +895,16 @@ static void optimal_settings(int freq, int rate)
 	}
 	capture_freq = freq;
 	capture_rate = dm->downsample * dm->rate_in;
+	if (verbosity)
+		fprintf(stderr, "capture_rate = dm->downsample * dm->rate_in = %d * %d = %d\n", dm->downsample, dm->rate_in, capture_rate );
 	if (!d->offset_tuning) {
-		capture_freq = freq + capture_rate/4;}
+		capture_freq = freq + capture_rate/4;
+		if (verbosity)
+			fprintf(stderr, "optimal_settings(freq = %d): capture_freq = freq + capture_rate/4 = %d\n", freq, capture_freq );
+	}
 	capture_freq += cs->edge * dm->rate_in / 2;
+	if (verbosity)
+		fprintf(stderr, "optimal_settings(freq = %d): capture_freq +=  cs->edge * dm->rate_in / 2 = %d * %d / 2 = %d\n", freq, cs->edge, dm->rate_in, capture_freq );
 	dm->output_scale = (1<<15) / (128 * dm->downsample);
 	if (dm->output_scale < 1) {
 		dm->output_scale = 1;}
@@ -874,6 +912,8 @@ static void optimal_settings(int freq, int rate)
 		dm->output_scale = 1;}
 	d->freq = (uint32_t)capture_freq;
 	d->rate = (uint32_t)capture_rate;
+	if (verbosity)
+		fprintf(stderr, "optimal_settings(freq = %d) delivers freq %.0f, rate %.0f\n", freq, (double)d->freq, (double)d->rate );
 }
 
 static void *controller_thread_fn(void *arg)
@@ -884,6 +924,8 @@ static void *controller_thread_fn(void *arg)
 	struct controller_state *s = arg;
 
 	if (s->wb_mode) {
+		if (verbosity)
+			fprintf(stderr, "wbfm: adding 16000 Hz to every intput frequency\n");
 		for (i=0; i < s->freq_len; i++) {
 			s->freqs[i] += 16000;}
 	}
@@ -896,6 +938,10 @@ static void *controller_thread_fn(void *arg)
 		verbose_offset_tuning(dongle.dev);}
 
 	/* Set the frequency */
+	if (verbosity) {
+		fprintf(stderr, "verbose_set_frequency(%.0f Hz)\n", (double)dongle.freq);
+		fprintf(stderr, "  frequency is away from parametrized one, to avoid negative impact from dc\n");
+	}
 	verbose_set_frequency(dongle.dev, dongle.freq);
 	fprintf(stderr, "Oversampling input by: %ix.\n", demod.downsample);
 	fprintf(stderr, "Oversampling output by: %ix.\n", demod.post_downsample);
@@ -903,6 +949,8 @@ static void *controller_thread_fn(void *arg)
 		1000 * 0.5 * (float)ACTUAL_BUF_LENGTH / (float)dongle.rate);
 
 	/* Set the sample rate */
+	if (verbosity)
+		fprintf(stderr, "verbose_set_sample_rate(%.0f Hz)\n", (double)dongle.rate);
 	verbose_set_sample_rate(dongle.dev, dongle.rate);
 	fprintf(stderr, "Output at %u Hz.\n", demod.rate_in/demod.post_downsample);
 
@@ -1042,12 +1090,13 @@ int main(int argc, char **argv)
 	int r, opt;
 	int dev_given = 0;
 	int custom_ppm = 0;
+	int timeConstant = 75; /* default: U.S. 75 uS */
 	dongle_init(&dongle);
 	demod_init(&demod);
 	output_init(&output);
 	controller_init(&controller);
 
-	while ((opt = getopt(argc, argv, "d:f:g:s:b:l:o:t:r:p:E:F:A:M:h")) != -1) {
+	while ((opt = getopt(argc, argv, "d:f:g:s:b:l:L:o:t:r:p:E:F:A:M:c:v:h")) != -1) {
 		switch (opt) {
 		case 'd':
 			dongle.dev_index = verbose_device_search(optarg);
@@ -1070,6 +1119,9 @@ int main(int argc, char **argv)
 		case 'l':
 			demod.squelch_level = (int)atof(optarg);
 			break;
+		case 'L':
+			printLevels = (int)atof(optarg);
+			break;
 		case 's':
 			demod.rate_in = (uint32_t)atofs(optarg);
 			demod.rate_out = (uint32_t)atofs(optarg);
@@ -1121,9 +1173,9 @@ int main(int argc, char **argv)
 				demod.custom_atan = 2;}
 			break;
 		case 'M':
-			if (strcmp("fm",  optarg) == 0) {
+			if (strcmp("nbfm",  optarg) == 0 || strcmp("nfm",  optarg) == 0 || strcmp("fm",  optarg) == 0) {
 				demod.mode_demod = &fm_demod;}
-			if (strcmp("raw",  optarg) == 0) {
+			if (strcmp("raw",  optarg) == 0 || strcmp("iq",  optarg) == 0) {
 				demod.mode_demod = &raw_demod;}
 			if (strcmp("am",  optarg) == 0) {
 				demod.mode_demod = &am_demod;}
@@ -1131,7 +1183,7 @@ int main(int argc, char **argv)
 				demod.mode_demod = &usb_demod;}
 			if (strcmp("lsb", optarg) == 0) {
 				demod.mode_demod = &lsb_demod;}
-			if (strcmp("wbfm",  optarg) == 0) {
+			if (strcmp("wbfm",  optarg) == 0 || strcmp("wfm",  optarg) == 0) {
 				controller.wb_mode = 1;
 				demod.mode_demod = &fm_demod;
 				demod.rate_in = 170000;
@@ -1142,6 +1194,17 @@ int main(int argc, char **argv)
 				demod.deemph = 1;
 				demod.squelch_level = 0;}
 			break;
+		case 'c':
+			if (strcmp("us",  optarg) == 0)
+				timeConstant = 75;
+			else if (strcmp("eu", optarg) == 0)
+				timeConstant = 50;
+			else
+				timeConstant = (int)atof(optarg);
+			break;
+		case 'v':
+			verbosity = (int)atof(optarg);
+			break;
 		case 'h':
 		default:
 			usage();
@@ -1194,7 +1257,10 @@ int main(int argc, char **argv)
 #endif
 
 	if (demod.deemph) {
-		demod.deemph_a = (int)round(1.0/((1.0-exp(-1.0/(demod.rate_out * 75e-6)))));
+		double tc = (double)timeConstant * 1e-6;
+		demod.deemph_a = (int)round(1.0/((1.0-exp(-1.0/(demod.rate_out * tc)))));
+		if (verbosity)
+			fprintf(stderr, "using wbfm deemphasis filter with time constant %d us\n", timeConstant );
 	}
 
 	/* Set the tuner gain */
-- 
1.9.5.msysgit.1

-------------- next part --------------
From f5c7ad917134cdf7961ad801685d120521ab1d3d Mon Sep 17 00:00:00 2001
From: Hayati Ayguen <h_ayguen at web.de>
Date: Sat, 18 Jul 2015 15:40:33 +0200
Subject: [PATCH 2/2] added dc filter on raw data (after decimation) with
 option "-E rdc"   added option "-q" for setting averaging speed   added
 option "-E adc" in addition to "-E dc"

---
 src/rtl_fm.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 51 insertions(+), 11 deletions(-)

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index 8cf95f0..f607e4e 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -146,7 +146,8 @@ struct demod_state
 	int      deemph, deemph_a;
 	int      now_lpr;
 	int      prev_lpr_index;
-	int      dc_block, dc_avg;
+	int      dc_block_audio, dc_avg, adc_block_const;
+	int      dc_block_raw, dc_avgI, dc_avgQ, rdc_block_const;
 	void     (*mode_demod)(struct demod_state*);
 	pthread_rwlock_t rw;
 	pthread_cond_t ready;
@@ -214,10 +215,13 @@ void usage(void)
 		"\t[-E enable_option (default: none)]\n"
 		"\t    use multiple -E to enable multiple options\n"
 		"\t    edge:   enable lower edge tuning\n"
-		"\t    dc:     enable dc blocking filter\n"
+		"\t    rdc:     enable dc blocking filter on raw I/Q data\n"
+		"\t    adc:     enable dc blocking filter on demodulated audio\n"
+		"\t    dc:      same as adc\n"
 		"\t    deemp:  enable de-emphasis filter\n"
 		"\t    direct: enable direct sampling\n"
 		"\t    offset: enable offset tuning\n"
+		"\t[-q dc_avg_factor for option rdc (default: 9)]\n"
 		"\tfilename ('-' means stdout)\n"
 		"\t    omitting the filename also uses stdout\n\n"
 		"Experimental options:\n"
@@ -623,7 +627,7 @@ void deemph_filter(struct demod_state *fm)
 	}
 }
 
-void dc_block_filter(struct demod_state *fm)
+void dc_block_audio_filter(struct demod_state *fm)
 {
 	int i, avg;
 	int64_t sum = 0;
@@ -631,13 +635,37 @@ void dc_block_filter(struct demod_state *fm)
 		sum += fm->result[i];
 	}
 	avg = sum / fm->result_len;
-	avg = (avg + fm->dc_avg * 9) / 10;
+	avg = (avg + fm->dc_avg * fm->adc_block_const) / ( fm->adc_block_const + 1 );
 	for (i=0; i < fm->result_len; i++) {
 		fm->result[i] -= avg;
 	}
 	fm->dc_avg = avg;
 }
 
+void dc_block_raw_filter(struct demod_state *fm)
+{
+	/* derived from dc_block_audio_filter,
+		running over the raw I/Q components
+	*/
+	int16_t *lp = fm->lowpassed;
+	int i, avgI, avgQ;
+	int64_t sumI = 0;
+	int64_t sumQ = 0;
+	for (i = 0; i < fm->lp_len; i += 2) {
+		sumI += lp[i];
+		sumQ += lp[i+1];
+	}
+	avgI = sumI / ( fm->lp_len / 2 );
+	avgQ = sumQ / ( fm->lp_len / 2 );
+	avgI = (avgI + fm->dc_avgI * fm->rdc_block_const) / ( fm->rdc_block_const + 1 );
+	avgQ = (avgQ + fm->dc_avgQ * fm->rdc_block_const) / ( fm->rdc_block_const + 1 );
+	for (i = 0; i < fm->lp_len; i += 2) {
+		lp[i] -= avgI;
+		lp[i+1] -= avgQ;
+	}
+	fm->dc_avgI = avgI;
+	fm->dc_avgQ = avgQ;
+}
 int mad(int16_t *samples, int len, int step)
 /* mean average deviation */
 {
@@ -789,7 +817,9 @@ void full_demod(struct demod_state *d)
 			}
 		}
 	}
-
+	if (d->dc_block_raw) {
+		dc_block_raw_filter(d);
+	}
 	d->mode_demod(d);  /* lowpassed -> result */
 	if (d->mode_demod == &raw_demod) {
 		return;
@@ -800,8 +830,8 @@ void full_demod(struct demod_state *d)
 		d->result_len = low_pass_simple(d->result, d->result_len, d->post_downsample);}
 	if (d->deemph) {
 		deemph_filter(d);}
-	if (d->dc_block) {
-		dc_block_filter(d);}
+	if (d->dc_block_audio) {
+		dc_block_audio_filter(d);}
 	if (d->rate_out2 > 0) {
 		low_pass_real(d);
 		//arbitrary_resample(d->result, d->result, d->result_len, d->result_len * d->rate_out2 / d->rate_out);
@@ -1017,8 +1047,13 @@ void demod_init(struct demod_state *s)
 	s->prev_lpr_index = 0;
 	s->deemph_a = 0;
 	s->now_lpr = 0;
-	s->dc_block = 0;
+	s->dc_block_audio = 0;
 	s->dc_avg = 0;
+	s->adc_block_const = 9;
+	s->dc_block_raw = 0;
+	s->dc_avgI = 0;
+	s->dc_avgQ = 0;
+	s->rdc_block_const = 9;
 	pthread_rwlock_init(&s->rw, NULL);
 	pthread_cond_init(&s->ready, NULL);
 	pthread_mutex_init(&s->ready_m, NULL);
@@ -1096,7 +1131,7 @@ int main(int argc, char **argv)
 	output_init(&output);
 	controller_init(&controller);
 
-	while ((opt = getopt(argc, argv, "d:f:g:s:b:l:L:o:t:r:p:E:F:A:M:c:v:h")) != -1) {
+	while ((opt = getopt(argc, argv, "d:f:g:s:b:l:L:o:t:r:p:E:q:F:A:M:c:v:h")) != -1) {
 		switch (opt) {
 		case 'd':
 			dongle.dev_index = verbose_device_search(optarg);
@@ -1150,8 +1185,10 @@ int main(int argc, char **argv)
 		case 'E':
 			if (strcmp("edge",  optarg) == 0) {
 				controller.edge = 1;}
-			if (strcmp("dc", optarg) == 0) {
-				demod.dc_block = 1;}
+			if (strcmp("dc", optarg) == 0 || strcmp("adc", optarg) == 0) {
+				demod.dc_block_audio = 1;}
+			if (strcmp("rdc", optarg) == 0) {
+				demod.dc_block_raw = 1;}
 			if (strcmp("deemp",  optarg) == 0) {
 				demod.deemph = 1;}
 			if (strcmp("direct",  optarg) == 0) {
@@ -1159,6 +1196,9 @@ int main(int argc, char **argv)
 			if (strcmp("offset",  optarg) == 0) {
 				dongle.offset_tuning = 1;}
 			break;
+		case 'q':
+			demod.rdc_block_const = atoi(optarg);
+			break;
 		case 'F':
 			demod.downsample_passes = 1;  /* truthy placeholder */
 			demod.comp_fir_size = atoi(optarg);
-- 
1.9.5.msysgit.1


From h_ayguen at web.de  Sun Jul 19 11:15:07 2015
From: h_ayguen at web.de (Hayati Ayguen)
Date: Sun, 19 Jul 2015 13:15:07 +0200
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
In-Reply-To: <55AA1458.2060205@web.de>
References: <55A9897A.7020305@web.de>
 <DUB123-DS20EA6E7C0F6AADF68BF50AC4870@phx.gbl> <55AA1458.2060205@web.de>
Message-ID: <55AB86BB.3020206@web.de>


Hi,

i could find the problem last night.

The problem was caused by the DC spike, from the analog front-end!
In my prior mail(s), i rejected this explanation .. but now i found out,
that the digital anti-alias filter is such bad quality (a simple
averaging), that the DC is folded into the receive band when decimating
samplerate!

I could fix the problem my moving the new DC filter ("-E rdc") to full
input at capture_rate. That eliminates the DC problem completely and
therefor also removes the extra noise produced on demodulation.

For being able to apply DC filter before mixing, i had to do conversion
of captured 8 bit samples to 16 bit first, before mixing up the desired
band to zero with rotate_90. Therefore i also changed rotate_90 to work
with 16 bit samples.

The above works fine with default parameters (-F 0). It does NOT work
when using option "-F 9". Could not figure out why!?

Find attached the patch file. Please consider merging it upstream.

kind regards,
Hayati



Am 18.07.2015 um 10:54 schrieb Hayati Ayguen:
> 
> Hi Murat and all others,
> 
> what i have hear is definitely NOT the DC spike coming from the analog
> front-end!
> 
> Whilst my experiments, trying to get rtl_fm run on Raspi 2, i added an
> option to rtl_fm to be verbose ("-v 1"). See
> https://github.com/hayguen/librtlsdr
> 
> When calling rtl_fm with "-s 24000 -f 433.25M -M raw" i get following
> outputs:
> "capture_rate = 42 * 24000 = 1008000"
> "capture_freq = freq + capture_rate / 4 = 433502000"
> 
> 
> From capture_rate you see, that the RTL's ADC works at a samplerate of
> 1.008 MHz. And the RTL is parametrized to 433.502 MHz.
> So, the RTL's DC is at 433.502 MHz - far away from the desired 433.25 MHz.
> On digital signal preprocessing the rtl_fm mixes the desired frequency
> up to baseband 0 Hz and the does low pass filtering and decimation to
> the samplerate of 24 kHz.
> This result is what i recorded in my previous mail and had a look with
> SDR#, the screenshot.
> 
> At the moment, I had no look into the source of low pass filter. I
> suppose that the DC is introduced here.
> 
> kind regards,
> Hayati
> 
> 
> 
> Am 18.07.2015 um 08:45 schrieb Murat Tologlu:
>> Dear Hayati,
>>
>> I am glad to see that my Debian-Jessie suggestion helped you to progress.
>>
>> Regarding your recent question: If I don't understand wrong, This is a well-known problem called as DC Spike which exist more or less in all SDR receivers. . Dr. Wickert of UCCS has an excellent laboratory note on RTL-SDR also explains this nature (see page 7) :  http://www.eas.uccs.edu/wickert/ece4670/lecture_notes/Lab6.pdf You can reach Dr. Wickert's other DSP notes from here: http://www.eas.uccs.edu/wickert/index.shtml 
>>
>> DC Spike comes from analog front end of the RTL-SDR dongle and we can talk about several solutions. First and the easiest solution is to move the center frequency a bit up and down to avoid interference with DC spike (this is called as offset tuning). Some hardware manufacturer claim that they manufacture better quality thus lower DC spike sdr chips and boards. You may also consider a software "notch filter" to reduce the DC spike !
>>
>> Kind regards,
>> Murat 
>>
>> -----Original Message-----
>> From: osmocom-sdr [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Hayati Ayguen
>> Sent: Saturday, July 18, 2015 2:02 AM
>> To: osmocom-sdr at lists.osmocom.org
>> Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
>>
>>
>> Hi,
>>
>> after i got rtl_fm run on Raspi 2 with Debian Jessie .. now i have some additional noise in the FM demodulated audio!
>>
>> With a "raw" recording (see attachment) i can see an additional carrier at the DC frequency of the demodulated output. That corresponds to the tuned frequency (= 433.25 MHz) parametrized to rtl_fm.
>> Due to calibration error, the FM carrier has some offset: ~ -1.3 kHz as visible in screenshot.
>> The DC carrier does demodulate to some distortion!
>>
>> Option "-E dc" does not help, cause that removes a DC in the demodulated output. An additional option to filter DC before demodulation does help a bit .. but does not solve the problem, which looks to be introduced earlier ..
>>
>> I would not have expected such a DC, cause IMHO it's produced whilst downconversion or filtering.
>> It's not the RTL dongle's DC, which should be far far away by 1/4 of the high samplerate.
>>
>> Someone else seen this problem?
>> Does anyone have a useful solution?
>>
>> kind regards,
>> Hayati
>>
>>
-------------- next part --------------
From 5e063d82042922d7620e48e4e1a805d383412cc9 Mon Sep 17 00:00:00 2001
From: Hayati Ayguen <h_ayguen at web.de>
Date: Sun, 19 Jul 2015 12:43:04 +0200
Subject: [PATCH 3/3] "rdc" filter in rtl_fm now at capture rate, before mixing
 or filtering:   DC is now totally removed, when not using option "-F 9"   due
 to bad anti-alias rejection the RTL dongle's DC folded into the decimated
 band   therefore swapped conversion to 16 bit and up-mixing by fs/4
 (rotate_90)

---
 src/rtl_fm.c | 65 +++++++++++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 47 insertions(+), 18 deletions(-)

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index f607e4e..2b98f5f 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -109,7 +109,7 @@ struct dongle_state
 	uint32_t freq;
 	uint32_t rate;
 	int      gain;
-	uint16_t buf16[MAXIMUM_BUF_LENGTH];
+	int16_t  buf16[MAXIMUM_BUF_LENGTH];
 	uint32_t buf_len;
 	int      ppm_error;
 	int      offset_tuning;
@@ -215,7 +215,7 @@ void usage(void)
 		"\t[-E enable_option (default: none)]\n"
 		"\t    use multiple -E to enable multiple options\n"
 		"\t    edge:   enable lower edge tuning\n"
-		"\t    rdc:     enable dc blocking filter on raw I/Q data\n"
+		"\t    rdc:     enable dc blocking filter on raw I/Q data at capture rate\n"
 		"\t    adc:     enable dc blocking filter on demodulated audio\n"
 		"\t    dc:      same as adc\n"
 		"\t    deemp:  enable de-emphasis filter\n"
@@ -295,6 +295,27 @@ double log2(double n)
 }
 #endif
 
+void rotate16_90(int16_t *buf, uint32_t len)
+/* 90 rotation is 1+0j, 0+1j, -1+0j, 0-1j
+   or [0, 1, -3, 2, -4, -5, 7, -6] */
+{
+	uint32_t i;
+	int16_t tmp;
+	for (i=0; i<len; i+=8) {
+		tmp = - buf[i+3];
+		buf[i+3] = buf[i+2];
+		buf[i+2] = tmp;
+
+		buf[i+4] = - buf[i+4];
+		buf[i+5] = - buf[i+5];
+
+		tmp = - buf[i+6];
+		buf[i+6] = buf[i+7];
+		buf[i+7] = tmp;
+	}
+}
+
+
 void rotate_90(unsigned char *buf, uint32_t len)
 /* 90 rotation is 1+0j, 0+1j, -1+0j, 0-1j
    or [0, 1, -3, 2, -4, -5, 7, -6] */
@@ -642,26 +663,25 @@ void dc_block_audio_filter(struct demod_state *fm)
 	fm->dc_avg = avg;
 }
 
-void dc_block_raw_filter(struct demod_state *fm)
+void dc_block_raw_filter(struct demod_state *fm, int16_t *buf, int len)
 {
 	/* derived from dc_block_audio_filter,
 		running over the raw I/Q components
 	*/
-	int16_t *lp = fm->lowpassed;
 	int i, avgI, avgQ;
 	int64_t sumI = 0;
 	int64_t sumQ = 0;
-	for (i = 0; i < fm->lp_len; i += 2) {
-		sumI += lp[i];
-		sumQ += lp[i+1];
+	for (i = 0; i < len; i += 2) {
+		sumI += buf[i];
+		sumQ += buf[i+1];
 	}
-	avgI = sumI / ( fm->lp_len / 2 );
-	avgQ = sumQ / ( fm->lp_len / 2 );
+	avgI = sumI / ( len / 2 );
+	avgQ = sumQ / ( len / 2 );
 	avgI = (avgI + fm->dc_avgI * fm->rdc_block_const) / ( fm->rdc_block_const + 1 );
 	avgQ = (avgQ + fm->dc_avgQ * fm->rdc_block_const) / ( fm->rdc_block_const + 1 );
-	for (i = 0; i < fm->lp_len; i += 2) {
-		lp[i] -= avgI;
-		lp[i+1] -= avgQ;
+	for (i = 0; i < len; i += 2) {
+		buf[i] -= avgI;
+		buf[i+1] -= avgQ;
 	}
 	fm->dc_avgI = avgI;
 	fm->dc_avgQ = avgQ;
@@ -817,9 +837,6 @@ void full_demod(struct demod_state *d)
 			}
 		}
 	}
-	if (d->dc_block_raw) {
-		dc_block_raw_filter(d);
-	}
 	d->mode_demod(d);  /* lowpassed -> result */
 	if (d->mode_demod == &raw_demod) {
 		return;
@@ -853,10 +870,19 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
 			buf[i] = 127;}
 		s->mute = 0;
 	}
-	if (!s->offset_tuning) {
-		rotate_90(buf, len);}
+	/* 1st: convert to 16 bit - to allow easier calculation of DC */
 	for (i=0; i<(int)len; i++) {
-		s->buf16[i] = (int16_t)buf[i] - 127;}
+		s->buf16[i] = ( (int16_t)buf[i] - 127 );
+	}
+	/* 2nd: do DC filtering BEFORE up-mixing */
+	if (d->dc_block_raw) {
+		dc_block_raw_filter(d, s->buf16, (int)len);
+	}
+	/* 3rd: up-mixing */
+	if (!s->offset_tuning) {
+		rotate16_90(s->buf16, (int)len);
+		/* rotate_90(buf, len); */
+	}
 	pthread_rwlock_wrlock(&d->rw);
 	memcpy(d->lowpassed, s->buf16, 2*len);
 	d->lp_len = len;
@@ -923,6 +949,9 @@ static void optimal_settings(int freq, int rate)
 		dm->downsample_passes = (int)log2(dm->downsample) + 1;
 		dm->downsample = 1 << dm->downsample_passes;
 	}
+	if (verbosity) {
+		fprintf(stderr, "downsample_passes = %d (= # of fifth_order() iterations), downsample = %d\n", dm->downsample_passes, dm->downsample );
+	}
 	capture_freq = freq;
 	capture_rate = dm->downsample * dm->rate_in;
 	if (verbosity)
-- 
1.9.5.msysgit.1


From mtologlu at hotmail.com  Sun Jul 19 19:20:51 2015
From: mtologlu at hotmail.com (Murat Tologlu)
Date: Sun, 19 Jul 2015 22:20:51 +0300
Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
In-Reply-To: <000801d0c256$08db4c30$1a91e490$@web.de>
References: <55A9897A.7020305@web.de>
 <DUB123-DS20EA6E7C0F6AADF68BF50AC4870@phx.gbl> <55AA1458.2060205@web.de>
 <000801d0c256$08db4c30$1a91e490$@web.de>
Message-ID: <DUB123-DS1504B21E373FCFBEAD6A47C4860@phx.gbl>

Hi Hayati,

You're doing great contribution to RtlSdr works; Congratulations.
I really appreciate and get benefit from your efforts.

Regards,
Murat

-----Original Message-----
From: osmocom-sdr [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Hayati Ayguen
Sent: Sunday, July 19, 2015 2:15 PM
To: osmocom-sdr at lists.osmocom.org
Subject: Re: rtl_fm: degraded demodulation caused by self-introduced DC !?


Hi,

i could find the problem last night.

The problem was caused by the DC spike, from the analog front-end!
In my prior mail(s), i rejected this explanation .. but now i found out, that the digital anti-alias filter is such bad quality (a simple averaging), that the DC is folded into the receive band when decimating samplerate!

I could fix the problem my moving the new DC filter ("-E rdc") to full input at capture_rate. That eliminates the DC problem completely and therefor also removes the extra noise produced on demodulation.

For being able to apply DC filter before mixing, i had to do conversion of captured 8 bit samples to 16 bit first, before mixing up the desired band to zero with rotate_90. Therefore i also changed rotate_90 to work with 16 bit samples.

The above works fine with default parameters (-F 0). It does NOT work when using option "-F 9". Could not figure out why!?

Find attached the patch file. Please consider merging it upstream.

kind regards,
Hayati



Am 18.07.2015 um 10:54 schrieb Hayati Ayguen:
> 
> Hi Murat and all others,
> 
> what i have hear is definitely NOT the DC spike coming from the analog 
> front-end!
> 
> Whilst my experiments, trying to get rtl_fm run on Raspi 2, i added an 
> option to rtl_fm to be verbose ("-v 1"). See 
> https://github.com/hayguen/librtlsdr
> 
> When calling rtl_fm with "-s 24000 -f 433.25M -M raw" i get following
> outputs:
> "capture_rate = 42 * 24000 = 1008000"
> "capture_freq = freq + capture_rate / 4 = 433502000"
> 
> 
> From capture_rate you see, that the RTL's ADC works at a samplerate of
> 1.008 MHz. And the RTL is parametrized to 433.502 MHz.
> So, the RTL's DC is at 433.502 MHz - far away from the desired 433.25 MHz.
> On digital signal preprocessing the rtl_fm mixes the desired frequency 
> up to baseband 0 Hz and the does low pass filtering and decimation to 
> the samplerate of 24 kHz.
> This result is what i recorded in my previous mail and had a look with 
> SDR#, the screenshot.
> 
> At the moment, I had no look into the source of low pass filter. I 
> suppose that the DC is introduced here.
> 
> kind regards,
> Hayati
> 
> 
> 
> Am 18.07.2015 um 08:45 schrieb Murat Tologlu:
>> Dear Hayati,
>>
>> I am glad to see that my Debian-Jessie suggestion helped you to progress.
>>
>> Regarding your recent question: If I don't understand wrong, This is 
>> a well-known problem called as DC Spike which exist more or less in 
>> all SDR receivers. . Dr. Wickert of UCCS has an excellent laboratory 
>> note on RTL-SDR also explains this nature (see page 7) :  
>> http://www.eas.uccs.edu/wickert/ece4670/lecture_notes/Lab6.pdf You 
>> can reach Dr. Wickert's other DSP notes from here: 
>> http://www.eas.uccs.edu/wickert/index.shtml
>>
>> DC Spike comes from analog front end of the RTL-SDR dongle and we can talk about several solutions. First and the easiest solution is to move the center frequency a bit up and down to avoid interference with DC spike (this is called as offset tuning). Some hardware manufacturer claim that they manufacture better quality thus lower DC spike sdr chips and boards. You may also consider a software "notch filter" to reduce the DC spike !
>>
>> Kind regards,
>> Murat
>>
>> -----Original Message-----
>> From: osmocom-sdr [mailto:osmocom-sdr-bounces at lists.osmocom.org] On 
>> Behalf Of Hayati Ayguen
>> Sent: Saturday, July 18, 2015 2:02 AM
>> To: osmocom-sdr at lists.osmocom.org
>> Subject: rtl_fm: degraded demodulation caused by self-introduced DC !?
>>
>>
>> Hi,
>>
>> after i got rtl_fm run on Raspi 2 with Debian Jessie .. now i have some additional noise in the FM demodulated audio!
>>
>> With a "raw" recording (see attachment) i can see an additional carrier at the DC frequency of the demodulated output. That corresponds to the tuned frequency (= 433.25 MHz) parametrized to rtl_fm.
>> Due to calibration error, the FM carrier has some offset: ~ -1.3 kHz as visible in screenshot.
>> The DC carrier does demodulate to some distortion!
>>
>> Option "-E dc" does not help, cause that removes a DC in the demodulated output. An additional option to filter DC before demodulation does help a bit .. but does not solve the problem, which looks to be introduced earlier ..
>>
>> I would not have expected such a DC, cause IMHO it's produced whilst downconversion or filtering.
>> It's not the RTL dongle's DC, which should be far far away by 1/4 of the high samplerate.
>>
>> Someone else seen this problem?
>> Does anyone have a useful solution?
>>
>> kind regards,
>> Hayati
>>
>>



From joseperezjunior at gmail.com  Tue Jul 21 15:32:53 2015
From: joseperezjunior at gmail.com (Jose Perez Junior)
Date: Tue, 21 Jul 2015 12:32:53 -0300
Subject: Running but nothing on FFT display
Message-ID: <CAOHfAXnrNCVuxm9_6+Y=e8QJH5Mi26JyduWuzPajbDfq2Axv3Q@mail.gmail.com>

Hi,

I have one RTL-SDR and in my home computer it is working well. Now I am
tryint to run in my office.
Here is Ubuntu 14.04 and GNU Radio 3.7.8... For a simple flowgraph just
with RTL-SDR Source and a FFT Sink I can't vizualise nothing in FM (88 -
108 MHz). I have also here a USRP and a BlackRF and both oof then are
working well. Is there something to solve this?

This is the output of Terminal to rtl_test -t

Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6
19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9
44.5 48.0 49.6
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.



And this is the output of GNU Radio.
[image: Imagem inline 1]




Thanks so much,
-- 
.: Jos? Perez Jr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150721/b958b4f6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 218634 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150721/b958b4f6/attachment.png>

From mtologlu at hotmail.com  Fri Jul 31 01:30:01 2015
From: mtologlu at hotmail.com (Murat Tologlu)
Date: Fri, 31 Jul 2015 04:30:01 +0300
Subject: Running but nothing on FFT display
In-Reply-To: <006401d0c43d$bbb561e0$332025a0$@gmail.com>
References: <006401d0c43d$bbb561e0$332025a0$@gmail.com>
Message-ID: <BLU437-SMTP48C03A3B6584C68062AFA9C48A0@phx.gbl>

Hi Jose,
It looks like working; what is problem? Did you check the antenna?
I did the same in my setup Ubuntu 14.04 with GNU 3.7.7.1 and mine worked 
same with bigger signal.
Regards,
Murat

On 07/21/2015 06:32 PM, Jose Perez Junior wrote:
> Hi,
>
> I have one RTL-SDR and in my home computer it is working well. Now I 
> am tryint to run in my office.
> Here is Ubuntu 14.04 and GNU Radio 3.7.8... For a simple flowgraph 
> just with RTL-SDR Source and a FFT Sink I can't vizualise nothing in 
> FM (88 - 108 MHz). I have also here a USRP and a BlackRF and both oof 
> then are working well. Is there something to solve this?
>
> This is the output of Terminal to rtl_test -t
>
> Found 1 device(s):
>   0:  Realtek, RTL2838UHIDIR, SN: 00000001
>
> Using device 0: Generic RTL2832U OEM
> Found Rafael Micro R820T tuner
> Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 
> 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 
> 43.4 43.9 44.5 48.0 49.6
> Sampling at 2048000 S/s.
> No E4000 tuner found, aborting.
>
>
>
> And this is the output of GNU Radio.
> Imagem inline 1
>
>
>
>
> Thanks so much,
> -- 
> .: Jos? Perez Jr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150731/04a267ce/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 218634 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150731/04a267ce/attachment.png>

From john at tonebridge.com  Sat Jul 11 17:29:55 2015
From: john at tonebridge.com (John)
Date: Sat, 11 Jul 2015 17:29:55 -0000
Subject: Heatmap with unwanted vertical lines
Message-ID: <55A1528E.5000207@tonebridge.com>

Hello,

When I use heatmap.py with output from rtl_power I get regularly spaced 
vertical lines that do not appear to be related to any signal.  They 
look they like repeat at the dongle bandwidth (2048000Hz in this case).  
The crop option for rtl_power reduces the presence but I am not sure f 
that is intended by that option.  Even at -c of 70% they are still there 
(see attachment).

Is this because of small bin width?  If I use a larger bin (32k) they 
are still there.  In this case there is no frequency legend along top so 
can't compare if they happen more often.

Are these lines to be expected?

John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: airband2_16k_d0_i2_c70.png
Type: image/png
Size: 438254 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150711/b92f1672/attachment.png>

From kastaldi at hotmail.com  Tue Jul 28 20:54:06 2015
From: kastaldi at hotmail.com (Mauro Castaldi)
Date: Tue, 28 Jul 2015 20:54:06 -0000
Subject: Device to add
Message-ID: <BLU436-SMTP1118F9BD78601BFF9575008C28D0@phx.gbl>

Hi.

I have this usb dongle and rtl_test says it is unsupported:

ID 1b80:d396 Afatech UB396-T [RTL2832U]

Thank you.

Mauro Castaldi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150728/10c602a4/attachment.htm>