osmocom-sdr July 2015

osmocom-sdr@lists.osmocom.org

10 participants
13 discussions

by John

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

8 years

sdrangelove build issues on mipsel

by Arturo Borrero Gonzalez

Hi there, In debian, sdrangelove is having some build issues on mipsel [0]. At first, there was an issue regarding the '-msse2' switch. If I delete the switch, then another build error happens: ======== 8< ======== [...] [ 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-0.0.1.20140824/obj-mipsel-linux-gnu -I/tmp/buildd/sdrangelove-0.0.1.20140824/include -I/tmp/buildd/sdrangelove-0.0.1.20140824/include-gpl -fPIC -o CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o -c /tmp/buildd/sdrangelove-0.0.1.20140824/sdrbase/dsp/interpolator.cpp In file included from /tmp/buildd/sdrangelove-0.0.1.20140824/sdrbase/dsp/interpolator.cpp:4:0: /tmp/buildd/sdrangelove-0.0.1.20140824/include-gpl/dsp/interpolator.h:4:23: fatal error: immintrin.h: No such file or directory #include <immintrin.h> ^ compilation terminated. [...] ======== 8< ======== Do you have any hint for this? Thanks, best regards. PS: Please keep me in CC, i'm not subscribed. [0] https://buildd.debian.org/status/fetch.php?pkg=sdrangelove&arch=mipsel&ver=… -- Arturo Borrero González

8 years

[rtl-sdr][PATCH 1/2] rtl_fm: Add scanner progress

by Nikolay Dimitrov

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(a)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

8 years, 8 months

Heatmap with unwanted vertical lines

by John

8 years, 9 months

Re: Running but nothing on FFT display

by Murat Tologlu

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

8 years, 9 months

Device to add

by Mauro Castaldi

Hi. I have this usb dongle and rtl_test says it is unsupported: ID 1b80:d396 Afatech UB396-T [RTL2832U] Thank you. Mauro Castaldi

8 years, 9 months

Running but nothing on FFT display

by Jose Perez Junior

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

8 years, 10 months

RE: rtl_fm: degraded demodulation caused by self-introduced DC !?

by Murat Tologlu

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@lists.osmocom.org] On Behalf Of Hayati Ayguen Sent: Sunday, July 19, 2015 2:15 PM To: osmocom-sdr(a)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@lists.osmocom.org] On >> Behalf Of Hayati Ayguen >> Sent: Saturday, July 18, 2015 2:02 AM >> To: osmocom-sdr(a)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 >> >>

8 years, 10 months

rtl_fm: degraded demodulation caused by self-introduced DC !?

by Hayati Ayguen

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

8 years, 10 months

how/where to merge code

by Hayati Ayguen

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

8 years, 10 months

NBFM problem with rtl_fm on Raspberry Pi 2

by Hayati Ayguen

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

8 years, 10 months

osmocom app GUIs don't look correct

by Urban Hakansson

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(a)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(a)tecore.com), then delete the message in its entirety. Thank you.

8 years, 10 months

sdrangelove build issues on mipsel

by Arturo Borrero Gonzalez

8 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr July 2015