From john at tonebridge.com Sat Aug 1 23:03:58 2015 From: john at tonebridge.com (john) Date: Sat, 1 Aug 2015 18:03:58 -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: <55BD505E.7010803@tonebridge.com> Update: Termination: My dongle has 75 ohm antenna connection so I used 75 ohm terminator. The lines remained. The lines are much diminished or it could be due to fact "background" signal is very prevalent. I have attached this one image for reference. I was expecting to see no signal at all (or no single where the lines are not). Bandpass filter: ave not done this. I have a broadcast FM notch filter I could try. RF Chokes: Tried these on 8" usb cables feeding this RTL dongle, another RTL dongle and an 802.11 dongle. No apparent change in lines. Enclosure: The RTL dongles were already in aluminum enclosures. They are right next to an Odroid single board commuter that has no case. All of this is in a tin box. Linrad: Have not tried this. All my debugging was air band. When I switched to 450-470Mhz the problem goes away. Since this is my range of interest I will not be working on debugging this anymore. I can provide other images if someone is interested themselves. Thanks again, John On 07/15/2015 08:03 AM, Nikolay Dimitrov wrote: > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: airband_g28_i2_terminated.jpg Type: image/jpeg Size: 238969 bytes Desc: not available URL: From leif at sm5bsz.com Sun Aug 2 03:25:22 2015 From: leif at sm5bsz.com (Leif Asbrink) Date: Sun, 2 Aug 2015 05:25:22 +0200 Subject: Heatmap with unwanted vertical lines In-Reply-To: <55BD505E.7010803@tonebridge.com> References: <55A6498F.1050802@tonebridge.com> <55A65A2F.40009@mail.bg> <55BD505E.7010803@tonebridge.com> Message-ID: <20150802052522.23b40277a3a453c4fdb217e6@sm5bsz.com> Hi John, Heatmap steps the frequency of the dongle and places spectra with a bandwidth of about 2 MHz side by side. Depending on hardware and how you configure it you might have a center spur that repeats. You cover 118 to 137 MHz which is nearly a factor of 10 above the bandwidth of the dongle so you loose 90% of the data on each frequency with an associated higer noise floor (5 dB perhaps) that makes weak signals more difficult to find. It seems you have 10 sub-bands (based on the regions of low loise level.) I have not followed this thread so I do not know what tuner you are using. The image does not give any hint. All the dongles have many things that can be controlled by software. As a first step I suggest you use a "normal" SDR software that uses a single center frequency. SDRsharp, Linrad, HDSDR or whatever. Look at the spectrum and play with available settings. Regards Leif > Update: > > Termination: My dongle has 75 ohm antenna connection so I used 75 ohm > terminator. The lines remained. The lines are much diminished or it > could be due to fact "background" signal is very prevalent. I have > attached this one image for reference. I was expecting to see no signal > at all (or no single where the lines are not). > > Bandpass filter: ave not done this. I have a broadcast FM notch filter > I could try. > > RF Chokes: Tried these on 8" usb cables feeding this RTL dongle, > another RTL dongle and an 802.11 dongle. No apparent change in lines. > > Enclosure: The RTL dongles were already in aluminum enclosures. They > are right next to an Odroid single board commuter that has no case. All > of this is in a tin box. > > Linrad: Have not tried this. > > All my debugging was air band. When I switched to 450-470Mhz the > problem goes away. Since this is my range of interest I will not be > working on debugging this anymore. > > I can provide other images if someone is interested themselves. > > Thanks again, > > John > > On 07/15/2015 08:03 AM, Nikolay Dimitrov wrote: > > 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 sec at 42.org Mon Aug 3 14:38:43 2015 From: sec at 42.org (Stefan `Sec` Zehl) Date: Mon, 3 Aug 2015 16:38:43 +0200 Subject: osmocom_fft "peak hold" patch Message-ID: <20150803143843.GA16119@ice.42.org> 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. From caluml at gmail.com Thu Aug 6 09:28:15 2015 From: caluml at gmail.com (Calum) Date: Thu, 6 Aug 2015 10:28:15 +0100 Subject: Problem building gr-osmosdr Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From caluml at gmail.com Thu Aug 6 09:35:01 2015 From: caluml at gmail.com (Calum) Date: Thu, 6 Aug 2015 10:35:01 +0100 Subject: Problem building gr-osmosdr In-Reply-To: References: Message-ID: 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. On 6 August 2015 at 10:28, Calum wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From picmaster at mail.bg Thu Aug 6 09:50:13 2015 From: picmaster at mail.bg (Nikolay Dimitrov) Date: Thu, 06 Aug 2015 12:50:13 +0300 Subject: Problem building gr-osmosdr In-Reply-To: References: Message-ID: <55C32DD5.5090002@mail.bg> 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 > wrote: > > 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 > > Regards, Nikolay From caluml at gmail.com Thu Aug 6 09:58:26 2015 From: caluml at gmail.com (Calum) Date: Thu, 6 Aug 2015 10:58:26 +0100 Subject: Problem building gr-osmosdr In-Reply-To: References: <55C32DD5.5090002@mail.bg> Message-ID: 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 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 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 >> > wrote: >>> >>> 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 >>> >>> >>> >> Regards, >> Nikolay >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.guillermin at gmail.com Sun Aug 9 21:33:19 2015 From: nils.guillermin at gmail.com (Nils Guillermin) Date: Sun, 9 Aug 2015 17:33:19 -0400 Subject: Trouble building on OS X 10.10.4 Message-ID: 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, std::__1::allocator > const&) in rtl_source_c.cc.o "_rtlsdr_set_agc_mode", referenced from: rtl_source_c::rtl_source_c(std::__1::basic_string, std::__1::allocator > 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, std::__1::allocator > const&) in rtl_source_c.cc.o "_rtlsdr_set_offset_tuning", referenced from: rtl_source_c::rtl_source_c(std::__1::basic_string, std::__1::allocator > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From caluml at gmail.com Wed Aug 19 14:24:43 2015 From: caluml at gmail.com (Calum) Date: Wed, 19 Aug 2015 15:24:43 +0100 Subject: Build problem after updating boost Message-ID: Hello all, I had a problem building gr-osmosdr a few days ago (it was looking in /usr/lib64/lib64), which I worked around by symlinking a couple of files to where they were being looked for. However, since an update of boost yesterday, I now get an error complaining about a boost file I don't have on my system. "/usr/lib64/lib64/libboost_date_time-d.a" Any ideas what's going wrong here? Centos 6.6 Previous boost version: 1.41.0-25 New boost version: 1.41.0-27 $ git clone git://git.osmocom.org/gr-osmosdr Initialized empty Git repository in /home/calum/src/gr-osmosdr/.git/ remote: Counting objects: 3818, done. remote: Compressing objects: 100% (2510/2510), done. remote: Total 3818 (delta 2736), reused 1888 (delta 1270) Receiving objects: 100% (3818/3818), 926.14 KiB | 1.13 MiB/s, done. Resolving deltas: 100% (2736/2736), done. $ cd gr-osmosdr $ mkdir build ; cd build $ cmake .. -- The CXX compiler identification is GNU 4.4.7 -- The C compiler identification is GNU 4.4.7 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Build type not specified: defaulting to release. -- Found Git: /usr/bin/git (found version "1.7.1") -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... CMake Error at /usr/lib64/boost/Boost.cmake:536 (message): The imported target "boost_date_time-static-debug" references the file "/usr/lib64/lib64/libboost_date_time-d.a" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib64/boost/Boost.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib64/boost/BoostConfig.cmake:28 (include) /usr/share/cmake/Modules/FindBoost.cmake:177 (find_package) CMakeLists.txt:122 (find_package) -- Configuring incomplete, errors occurred! See also "/home/calum/src/gr-osmosdr/build/CMakeFiles/CMakeOutput.log". $ -------------- next part -------------- An HTML attachment was scrubbed... URL: From caluml at gmail.com Wed Aug 19 14:55:23 2015 From: caluml at gmail.com (Calum) Date: Wed, 19 Aug 2015 15:55:23 +0100 Subject: Build problem after updating boost In-Reply-To: References: Message-ID: Just noticed that the update yesterday took me from CentOS 6.6 to 6.7, so more than just boost was updated. However, it still seems like a strange file it's searching for - I can't find any reference to it anywhere. On 19 August 2015 at 15:24, Calum wrote: > Hello all, > > I had a problem building gr-osmosdr a few days ago (it was looking in > /usr/lib64/lib64), which I worked around by symlinking a couple of files to > where they were being looked for. > > However, since an update of boost yesterday, I now get an error > complaining about a boost file I don't have on my system. > "/usr/lib64/lib64/libboost_date_time-d.a" > > Any ideas what's going wrong here? > Centos 6.6 > Previous boost version: 1.41.0-25 > New boost version: 1.41.0-27 > > $ git clone git://git.osmocom.org/gr-osmosdr > Initialized empty Git repository in /home/calum/src/gr-osmosdr/.git/ > remote: Counting objects: 3818, done. > remote: Compressing objects: 100% (2510/2510), done. > remote: Total 3818 (delta 2736), reused 1888 (delta 1270) > Receiving objects: 100% (3818/3818), 926.14 KiB | 1.13 MiB/s, done. > Resolving deltas: 100% (2736/2736), done. > $ cd gr-osmosdr > $ mkdir build ; cd build > $ cmake .. > -- The CXX compiler identification is GNU 4.4.7 > -- The C compiler identification is GNU 4.4.7 > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Build type not specified: defaulting to release. > -- Found Git: /usr/bin/git (found version "1.7.1") > -- Extracting version information from git describe... > -- Configuring Boost C++ Libraries... > CMake Error at /usr/lib64/boost/Boost.cmake:536 (message): > The imported target "boost_date_time-static-debug" references the file > > "/usr/lib64/lib64/libboost_date_time-d.a" > > but this file does not exist. Possible reasons include: > > * The file was deleted, renamed, or moved to another location. > > * An install or uninstall procedure did not complete successfully. > > * The installation package was faulty and contained > > "/usr/lib64/boost/Boost.cmake" > > but not all the files it references. > > Call Stack (most recent call first): > /usr/lib64/boost/BoostConfig.cmake:28 (include) > /usr/share/cmake/Modules/FindBoost.cmake:177 (find_package) > CMakeLists.txt:122 (find_package) > > > -- Configuring incomplete, errors occurred! > See also "/home/calum/src/gr-osmosdr/build/CMakeFiles/CMakeOutput.log". > $ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrysh at mailbox.tu-berlin.de Mon Aug 3 17:40:42 2015 From: chrysh at mailbox.tu-berlin.de (chrysh) Date: Mon, 03 Aug 2015 17:40:42 -0000 Subject: Flashing AT91SAM3 In-Reply-To: <55BF9F13.4010903@mailbox.tu-berlin.de> References: <55BF9F13.4010903@mailbox.tu-berlin.de> Message-ID: <55BFA29F.3030202@mailbox.tu-berlin.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: sam3s_addition.patch Type: text/x-patch Size: 7842 bytes Desc: not available URL: From martins10101 at outlook.com Mon Aug 17 08:30:28 2015 From: martins10101 at outlook.com (Martin 10101) Date: Mon, 17 Aug 2015 08:30:28 -0000 Subject: hackrf_sink_c.cc bug on ARM Message-ID: Hello! Long story short: hackrf sink code to convert from GR complex to hackrf 8-bit format fails by generating wrong bits on ARM when I do TX on Raspberry PI 2 . Evil hides here: lib/hackrf/hackrf_sink_c.cc outbuf[i] = inbuf[i]*127; Since on ARM GCC treats all "char" as unsigned(this is chosen implementation) it generates wrong bits, so my advice is to compile on ARM gr-osmocom with flag -fsigned-char. This is probably most effective way to solve this, it solved my TX problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: