osmocom-sdr September 2015

osmocom-sdr@lists.osmocom.org

6 participants
7 discussions

by Syed Karim

We have a need for a small sample rate on the rtl-sdr. We have been able to select a bandwidth of 250 kHz, but there is significant aliasing at that setting. At higher sample rates the aliasing no longer exists. We are using the dongle that is sold by the RTL-SDR.com blog: http://www.rtl-sdr.com/new-products-rtl-sdr-with-1ppm-tcxo-sma-f-connector-… Since a reduced sample rate would allow for a much less resource consumption by the CPU, we would gladly sponsor an open source bounty or pay for open source development work to address this problem. Our use case is reception of a 5 kHz channel from a geostationary L-band operator. We have found that the dongle gets very hot at 1550 MHz, so we will use an LNB to downconvert to ~400 MHz. The rest of the RF chain consists of a patch antenna with 8 dBi of gain and 17 dBW EIRP from the spacecraft. The demodulator will be running on a derivative of the Beagle Bone Black. The designs for this board are available here: https://github.com/outernet-project/lantern-compute-pcb You can learn more about Outernet through the following links. http://gizmodo.com/what-is-the-outernet-and-is-it-the-future-of-the-intern-… http://www.wired.com/2015/07/plan-beam-web-3-billion-unconnected-humans/ http://www.technologyreview.com/news/537411/startup-beams-the-webs-most-imp…

9 years, 1 month

Heatmap with unwanted vertical lines

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

9 years, 1 month

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

9 years, 1 month

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

by Nikolay Dimitrov

Oops, forgot to CC the mailing list. On 09/21/2015 12:47 PM, Nikolay Dimitrov wrote: > Hi Dimitri, > > On 07/04/2015 03:42 PM, Nikolay Dimitrov wrote: >> 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(-) > > Can you please take a look at this patch and decide whether it's worthy > of applying to the rtl-sdr tree? > > Thanks in advance. Regards, > Nikolay

9 years, 5 months

[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

9 years, 9 months

questions about gr-osmosdr

by Pavel Demin

Hello, I'm working on the gr-osmosdr blocks for the Red Pitaya SDR transceiver. They are based on the file block with some pieces borrowed from the rtl_tcp block. The new blocks are already working and the code can be found at: https://github.com/pavel-demin/gr-osmosdr/tree/master/lib/red_pitaya My notes about the Red Pitaya SDR transceiver can be found at: http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver I have two questions that I can't find an answer to: - What would be the best way to implement the push-to-talk (PTT) command? I don't see any method reserved for this kind of functionality in gr-osmosdr/lib/sink_impl.h. I can think of putting it to set_if_gain or set_bb_gain but I'm not sure if it's a good idea. - Once the PTT problem solved, what would be the best way to submit a patch with my modifications? Best regards, Pavel

9 years, 9 months

2 out of 3 gains function in Gnuradio for Airspy

by Martin Smith

Hi, There are three gains in the Airspy LNA,MIX and IF. With GQRX these are all accessible and function as expected (https://i.imgur.com/g11kehx.png?1 ). With osmocom_fft these are all accessible and function as expected ( osmocom_fft -a airspy=0 -f 88.5M -s 10M ) ( https://i.imgur.com/4Pu7sP9.png?1 ). But with Gnuradio the MIX gain is not accessible, or the set_bb_gain() in not linked to anything in the case of an Airspy ( https://i.imgur.com/KCTBmsu.jpg?1 ). I can turn "Ch0: BB gain" from its minimum to its maximum value and it changes nothing. If it was broken for all three I would assume that the problem was with the gr-osmosdr block. That it works correctly for two programs that use this block and not correctly for Gnuradio made me suspect that the problem is with Gnuradio. The ticket I logged ( http://gnuradio.org/redmine/issues/834 ) was closed. They let me know that my two out of three guess was wrong and that this is an issue with the gr-osmosdr block, so they kindly pointed me in the direction of this mailing list for help. I would try and debug it further but I have left my zone of knowledge to look any further. Thanks in advance for any help that you can provide, Martin

9 years, 9 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr September 2015