- osmocom-sdr - lists.osmocom.org

Trouble building on OS X 10.10.4
by Nils Guillermin 09 Aug '15

09 Aug '15

Hi there, I am having trouble building latest version of gr-osmosdr on my Mac. I am having identical issue with homebrew version (from chleggett tap) as with cloning from http://git.osmocom.org/gr-osmosdr/. `make` step always fails with linker error Undefined symbols for architecture x86_64: "_rtlsdr_get_index_by_serial", referenced from: rtl_source_c::rtl_source_c(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in rtl_source_c.cc.o "_rtlsdr_set_agc_mode", referenced from: rtl_source_c::rtl_source_c(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in rtl_source_c.cc.o rtl_source_c::set_gain_mode(bool, unsigned long) in rtl_source_c.cc.o non-virtual thunk to rtl_source_c::set_gain_mode(bool, unsigned long) in rtl_source_c.cc.o "_rtlsdr_set_direct_sampling", referenced from: rtl_source_c::rtl_source_c(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in rtl_source_c.cc.o "_rtlsdr_set_offset_tuning", referenced from: rtl_source_c::rtl_source_c(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in rtl_source_c.cc.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [lib/libgnuradio-osmosdr.0.1.5git.dylib] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 Trying to add -DCMAKE_CXX_FLAGS=-libstd=libstdc++ only results in even more undefined symbols on top of these. I'm not sure where to proceed from here. This is my first post to this list, so hello everyone! and Thanks for any help. Nils

1 0

Re: Problem building gr-osmosdr
by Calum 06 Aug '15

06 Aug '15

Hey Nikolay, Yes, that's what I thought although I'm not familiar enough with cmake to fix it. I'm happy to try out any changes though, if someone can suggest something that I can try? On 6 August 2015 at 10:57, Calum <caluml(a)gmail.com> wrote: > Hey Nikolay, > > Yes, that's what I thought although I'm not familiar enough with cmake to > fix it. > I'm happy to try out any changes though, if someone can suggest something > that I can try? > > On 6 August 2015 at 10:50, Nikolay Dimitrov <picmaster(a)mail.bg> wrote: > >> Hi Calum, >> >> On 08/06/2015 12:35 PM, Calum wrote: >> >>> For the record - the workaround >>> >>> mkdir /usr/lib64/lib64/ >>> cd /usr/lib64/lib64/ >>> ln -s ../libboost_system-mt.so.5 >>> ln -s ../libboost_thread-mt.so.5 >>> >>> allowed me to build it, although it's not ideal. >>> >> >> This looks like an issue with the cmake config file. >> >> On 6 August 2015 at 10:28, Calum <caluml(a)gmail.com >>> <mailto:caluml@gmail.com>> wrote: >>> >>> Hello all, >>> >>> I have a problem building gr-osmosdr. >>> Steps followed: >>> >>> git clone git://git.osmocom.org/gr-osmosdr >>> <http://git.osmocom.org/gr-osmosdr> (commit >>> >>> 86ad584204762eeb01f07daa683673f1ec3f1df5) >>> cd gr-osmosdr/ >>> mkdir build >>> cd build/ >>> ENABLE_FCD=ON ENABLE_FCDPP=ON cmake ../ >>> make >>> Scanning dependencies of target gnuradio-osmosdr >>> [ 10%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o >>> [ 20%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o >>> [ 30%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o >>> [ 40%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o >>> [ 50%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/time_spec.cc.o >>> [ 60%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o >>> [ 70%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o >>> [ 80%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_f.cc.o >>> [ 90%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o >>> [100%] Building CXX object >>> lib/CMakeFiles/gnuradio-osmosdr.dir/rfspace/rfspace_source_c.cc.o >>> make[2]: *** No rule to make target >>> `/usr/lib64/lib64/libboost_thread-mt.so.5', needed by >>> `lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0'. Stop. >>> make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> I wonder if anyone can help me with this? Looks like the path to >>> libboost_thread-mt.so.5 has two lib64s in it. >>> I'm running CentOS 6.6. >>> >>> C >>> >>> >>> >> Regards, >> Nikolay >> > >

1 0

Problem building gr-osmosdr
by Calum 06 Aug '15

06 Aug '15

Hello all, I have a problem building gr-osmosdr. Steps followed: git clone git://git.osmocom.org/gr-osmosdr (commit 86ad584204762eeb01f07daa683673f1ec3f1df5) cd gr-osmosdr/ mkdir build cd build/ ENABLE_FCD=ON ENABLE_FCDPP=ON cmake ../ make Scanning dependencies of target gnuradio-osmosdr [ 10%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o [ 20%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o [ 30%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o [ 40%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o [ 50%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/time_spec.cc.o [ 60%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o [ 70%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o [ 80%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_f.cc.o [ 90%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o [100%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rfspace/rfspace_source_c.cc.o make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_thread-mt.so.5', needed by `lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0'. Stop. make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 I wonder if anyone can help me with this? Looks like the path to libboost_thread-mt.so.5 has two lib64s in it. I'm running CentOS 6.6. C

2 2

Flashing AT91SAM3
by chrysh 03 Aug '15

03 Aug '15

Hi everyone, the new SIMtrace board will be available soon. It is equipped with an Atmel AT91SAM3 instead of a AT91SAM7 (both chips are pin compatible, so upgrading by hand by unsoldering the old processor and attaching the new AT91SAM3 is also possible). Just for the record, if you want to flash an AT91SAM3, this solution worked for me: Comment out osmoSDRDetect() return -1 in osmosdr.c, so that osmoSDRDetect always returns 0. Further adjustment in terms of addresses: % diff -Naur src/sam3u.c src/sam3s.c5 --- src/sam3u.c 2015-05-29 15:59:51.697208630 +0200 +++ src/sam3s.c 2015-05-29 15:39:34.331493312 +0200 @@ -139,12 +139,8 @@ switch(bank) { case 0: - regBase = 0x400e0800; - flashBase = 0x80000; - break; - case 1: regBase = 0x400e0a00; - flashBase = 0x100000; + flashBase = 0x400000; break; default: fprintf(stderr, "illegal flash bank"); @@ -192,12 +188,8 @@ switch(bank) { case 0: - regBase = 0x400e0800; - flashBase = 0x80000; - break; - case 1: regBase = 0x400e0a00; - flashBase = 0x100000; + flashBase = 0x400000; break; default: fprintf(stderr, "illegal flash bank"); After adjusting the addresses, compile sam3s.c in the Makefile instead of sam3u.c. Please also find attached a diff of my locally applied change, which might illustrate the adjustments needed in more clarity. Regards, Christina

1 0

osmocom_fft "peak hold" patch
by Stefan `Sec` Zehl 03 Aug '15

03 Aug '15

Hi, I needed osmocom_fft to start in "peak hold" mode, so I added the commandline option necessary for it. Maybe this patch could be included in the official osmocom_fft :) --- /home/sec/Projects/gnuradio/gr-osmosdr/apps/osmocom_fft 2015-07-26 13:22:47.743207885 +0200 +++ /usr/local/bin/osmocom_fft 2015-08-03 15:07:23.977849575 +0200 @@ -91,6 +91,8 @@ help="Set fftsink averaging factor, default=[%default]") parser.add_option("", "--averaging", action="store_true", default=False, help="Enable fftsink averaging, default=[%default]") + parser.add_option("", "--peak-hold", action="store_true", default=False, + help="Enable fftsink peak hold, default=[%default]") parser.add_option("", "--ref-scale", type="eng_float", default=1.0, help="Set dBFS=0dB input value, default=[%default]") parser.add_option("", "--fft-size", type="int", default=1024, @@ -242,6 +244,7 @@ ref_level=20.0, y_divs = 12, average=options.averaging, + peak_hold=options.peak_hold, avg_alpha=options.avg_alpha, fft_rate=options.fft_rate) Thanks, Sec -- When in doubt, invent a chinese proverb.

1 0

Heatmap with unwanted vertical lines
by John 02 Aug '15

02 Aug '15

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

4 4

Re: Running but nothing on FFT display
by Murat Tologlu 31 Jul '15

31 Jul '15

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

1 0

Device to add
by Mauro Castaldi 28 Jul '15

28 Jul '15

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

1 0

Running but nothing on FFT display
by Jose Perez Junior 21 Jul '15

21 Jul '15

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

1 0

RE: rtl_fm: degraded demodulation caused by self-introduced DC !?
by Murat Tologlu 19 Jul '15

19 Jul '15

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 >> >>

1 0