Re: [Discuss-gnuradio] gr-osmocom make failing

[Ron Economos]

That's usually a sign of the remnants of some previous installation 
still being present.


Ron

On 09/21/2017 05:34 PM, Tom McDermott wrote:

Many thanks for your help Ron.  I did a git checkout of cf954948
That resolved the rtl-sdr compiler error but introduced a blade rf 
compile error.

I then re-did the cmake with -DENABLE_BLADERF=OFF and
got a clean make and clean make install.

However now at runtime I get the error:

traceback (most recent call last):
  File "/home/tom/Desktop/GRC Flowgraphs/RTL2832 + DSTAR NOAA 
etc/top_block.py", line 31, in 

    import osmosdr
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/__init__.py", 
line 26, in 

    from osmosdr_swig import *
  File 
"/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 
28, in 

    _osmosdr_swig = swig_import_helper()
  File 
"/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 
24, in swig_import_helper

    _mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: libboost_date_time.so.1.54.0: cannot open shared object 
file: No such file or directory



I have boost 1.58 installed.  Is boost 1.54 date_time something 
different that needs to be in addition to boost 1.58 ?
If so, how would one install just a part of the boost library from a 
previous version?


-- Tom






On Thu, Sep 21, 2017 at 12:05 PM, Ron Economos > wrote:


It's due to a mismatch between gr-osmosdr and the Ubuntu 16.04
rtlsdr library. There are a few different solutions to this problem.

1) If you're not using RTL-SDR dongles, then just purge the rtlsdr
packages (librtlsdr-dev and librtlsdr0). Then rebuild gr-osmosdr
and Osmocom RTLSDR should end up in the disabled components during
the cmake phase.

2) Checkout a previous version of gr-osmosdr from before this
change. git checkout cf954948 should work.

3) The correct solution is to build the rtl-sdr library from
source and make sure gr-osmosdr links to that.

https://github.com/osmocom/rtl-sdr


Ron


On 09/21/2017 11:40 AM, Tom McDermott wrote:

Using Ubuntu 16.04, Have guradio 3.7.12git-231  master branch
gnuradio runs fine.

The old version of Osmocom no longer runs (after some years), so
I started rebuild of gr-osmocom from scratch by cloning from
git.osmocom.org/gr-osmosdr 
my current appliation is to get rtl-sdr running using Osmocom.

Are there  packages I must install to allow gr-osmocom to compile?


Running CMAKE succeeds, with some missing packages:


-- ##
-- # Gnuradio enabled components
-- ##
--   * Python support
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle
--   * IQ File Source & Sink
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * Ettus USRP Devices
--   * HackRF & rad1o Badge
--   * nuand bladeRF
--   * RFSPACE Receivers
--   * Red Pitaya SDR
-- 
-- ##

-- # Gnuradio disabled components
-- ##
--   * sysmocom OsmoSDR
--   * FUNcube Dongle Pro+
--   * Osmocom MiriSDR
--   * AIRSPY Receiver
--   * SoapySDR support
--   * FreeSRP support
-- 
-- Building for version: v0.1.4-98-gc653754d / 0.1.5git

-- Using install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tom/gr-osmosdr/build



MAKE then fails:

tom@tom-XPS-8500:~/gr-osmosdr/build$ make
Scanning dependencies of target gnuradio-osmosdr
[  2%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o
[  4%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o
[  6%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o
[  8%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o
[ 11%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/time_spec.cc.o
[ 13%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o
[ 15%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o
[ 17%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_sink_c.cc.o
[ 20%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc: In constructor
‘rtl_source_c::rtl_source_c(const string&)’:
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc:224:43: error:
‘rtlsdr_set_bias_tee’ was not declared in this scope
   ret = rtlsdr_set_bias_tee(_dev, bias_tee);
^
lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:254: recipe 

Re: [Discuss-gnuradio] Energy Detection output incorrect

[Tellrell White]

Sorry for the confusing explanation, but yes, I'm trying to find the
average energy over frequencies.

1. What I'm doing, at least as a start, is signal detection of 802.15.4
waveform using energy detection focusing on the O-QPSK PHY operating at the
2.4 Ghz band. The O-QPSK PHY uses a 32 bit chip sequence for spreading the
signal.

2. From research, I can see that other forms of detection such as matched
filter detection would be a lot better for an application of this sort.
However, energy detection was chosen to start with because of its lack of
complexity. The focus at the moment is more on the feasibility of this
approach. In the future, other approaches or methods will be considered
also.

Tellrell

On Thu, Sep 21, 2017 at 8:40 PM, Tellrell White  wrote:

> Thanks Marcus
>
> Sorry for the confusing explanation, but yes, I'm trying to find the
> average energy over frequencies.
>
> 1. What I'm doing, at least as a start, is signal detection of 802.15.4
> waveform using energy detection focusing on the O-QPSK PHY operating at the
> 2.4 Ghz band. The O-QPSK PHY uses a 32 bit chip sequence for spreading the
> signal.
>
> 2. From research, I can see that other forms of detection such as matched
> filter detection would be a lot better for an application of this sort.
> However, energy detection was chosen to start with because of its lack of
> complexity. The focus at the moment is more on the feasibility of this
> approach. In the future, other approaches or methods will be considered
> also.
>
> Tellrell
>
>
> On Thu, Sep 21, 2017 at 5:36 PM, Marcus Müller 
> wrote:
>
>> Hi Tellrell,
>>
>> I know you can find the PSD
>>
>> Ah, so you're actually after a PSD estimate – It wasn't clear to me what
>> you were looking for, because the FFT-> frequency sink flowgraph didn't
>> make sense. And you just said "average energy" (not "average energy over
>> frequencies"), so I was kind of confused; sorry!
>>
>> So, ultimately, if the way that I'm implementing the algorithm is correct
>> thus far, I'm looking for a way to display(graphically or otherwise) my
>> result or the avg power.
>>
>> It's impossible to say whether an algorithm is correct without specifying
>> what it should be doing - so maybe we need to take a step back:
>>
>> 1. you want to do detection of IEEE 802.15.4 signals. Which PHY are we
>> talking about? There's multiple physical layers for that standard. The DSSS
>> types aren't really … friendly towards energy detection at all.
>> 2. pure DFT-bases spectral estimation without preprocessing or
>> postprocessing is usually not the optimum method for signals that don't
>> have a spectral sinc shape; they're just easy to implement. Usually, you'd
>> try to detect using as much info about what the signal of interest is as
>> possible – especially in the presence of other systems.
>>
>> Best regards,
>>
>> Marcus
>> On 09/21/2017 11:32 AM, Tellrell White wrote:
>>
>> Thanks for the replies guys
>>
>> Marcus I know you can find the PSD of a signal in both the time and
>> frequency domain. The only reason I'm choosing to use the frequency domain
>> is because it was one of the earlier methods that I learned about. That's
>> really all. From the archives I've read about people trying to implement
>> energy detectors in GNU Radio for various applications but I never saw
>> anybody display the results in any way or form. They mostly just send the
>> statistics to a file sink and export to matlab or some other software for
>> further processing. So, ultimately, if the way that I'm implementing the
>> algorithm is correct thus far, I'm looking for a way to display(graphically
>> or otherwise) my result or the avg power.
>>
>> Nathan would you remove the vector to stream block as well? And, why
>> would you have to remove the stream to vector block? Isn't that the format
>> that I want the data in? Also, how do you go about adding "vector modes" to
>> the remaining blocks?
>>
>> Tellrell
>>
>> On Thu, Sep 21, 2017 at 1:30 PM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>> You can use the qt gui vector plot to plot a vector. That means removing
>>> the stream to vector block. You might have to add "vector" modes to some
>>> blocks to do the other operations you want.
>>>
>>> On Wed, Sep 20, 2017 at 6:31 PM, Tellrell White 
>>> wrote:
>>>
 Hello Marcus
 You are absolutely correct. Is there an existing sink that would allow
 me to display avg power given some threshold ?

 Tellrell


 On Wednesday, September 20, 2017 5:54 PM, Marcus Müller <
 marcus.muel...@ettus.com> wrote:


 Hi Tellrell!
 Why should both plots show the same? You send in completely different
 signals!
 Best regards,
 Marcus

 On 09/20/2017 09:27 AM, Tellrell White wrote:

 Hello All
 I'm working on a project involving signal detection of an IEEE 802.15.4
 waveform using energy 

Re: [Discuss-gnuradio] gr-osmocom make failing

[Tom McDermott]

Many thanks for your help Ron.  I did a git checkout of cf954948
That resolved the rtl-sdr compiler error but introduced a blade rf compile
error.
I then re-did the cmake with -DENABLE_BLADERF=OFF and
got a clean make and clean make install.

However now at runtime I get the error:

traceback (most recent call last):
  File "/home/tom/Desktop/GRC Flowgraphs/RTL2832 + DSTAR NOAA
etc/top_block.py", line 31, in 
import osmosdr
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/__init__.py", line
26, in 
from osmosdr_swig import *
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py",
line 28, in 
_osmosdr_swig = swig_import_helper()
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: libboost_date_time.so.1.54.0: cannot open shared object file:
No such file or directory


I have boost 1.58 installed.  Is boost 1.54 date_time something different
that needs to be in addition to boost 1.58 ?
If so, how would one install just a part of the boost library from a
previous version?

-- Tom






On Thu, Sep 21, 2017 at 12:05 PM, Ron Economos  wrote:

> It's due to a mismatch between gr-osmosdr and the Ubuntu 16.04 rtlsdr
> library. There are a few different solutions to this problem.
>
> 1) If you're not using RTL-SDR dongles, then just purge the rtlsdr
> packages (librtlsdr-dev and librtlsdr0). Then rebuild gr-osmosdr and
> Osmocom RTLSDR should end up in the disabled components during the cmake
> phase.
>
> 2) Checkout a previous version of gr-osmosdr from before this change. git
> checkout cf954948 should work.
>
> 3) The correct solution is to build the rtl-sdr library from source and
> make sure gr-osmosdr links to that.
>
> https://github.com/osmocom/rtl-sdr
>
> Ron
>
>
> On 09/21/2017 11:40 AM, Tom McDermott wrote:
>
> Using Ubuntu 16.04, Have guradio 3.7.12git-231  master branch
> gnuradio runs fine.
>
> The old version of Osmocom no longer runs (after some years), so
> I started rebuild of gr-osmocom from scratch by cloning from
> git.osmocom.org/gr-osmosdr
> my current appliation is to get rtl-sdr running using Osmocom.
>
> Are there  packages I must install to allow gr-osmocom to compile?
>
>
> Running CMAKE succeeds, with some missing packages:
>
>
> -- ##
> -- # Gnuradio enabled components
> -- ##
> --   * Python support
> --   * Osmocom IQ Imbalance Correction
> --   * FUNcube Dongle
> --   * IQ File Source & Sink
> --   * Osmocom RTLSDR
> --   * RTLSDR TCP Client
> --   * Ettus USRP Devices
> --   * HackRF & rad1o Badge
> --   * nuand bladeRF
> --   * RFSPACE Receivers
> --   * Red Pitaya SDR
> --
> -- ##
> -- # Gnuradio disabled components
> -- ##
> --   * sysmocom OsmoSDR
> --   * FUNcube Dongle Pro+
> --   * Osmocom MiriSDR
> --   * AIRSPY Receiver
> --   * SoapySDR support
> --   * FreeSRP support
> --
> -- Building for version: v0.1.4-98-gc653754d / 0.1.5git
> -- Using install prefix: /usr/local
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/tom/gr-osmosdr/build
>
>
>
> MAKE then fails:
>
> tom@tom-XPS-8500:~/gr-osmosdr/build$ make
> Scanning dependencies of target gnuradio-osmosdr
> [  2%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/source_impl.cc.o
> [  4%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/sink_impl.cc.o
> [  6%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o
> [  8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o
> [ 11%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/time_spec.cc.o
> [ 13%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/fcd/fcd_source_c.cc.o
> [ 15%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/file/file_source_c.cc.o
> [ 17%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/file/file_sink_c.cc.o
> [ 20%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/rtl/rtl_source_c.cc.o
> /home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc: In constructor
> ‘rtl_source_c::rtl_source_c(const string&)’:
> /home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc:224:43: error:
> ‘rtlsdr_set_bias_tee’ was not declared in this scope
>ret = rtlsdr_set_bias_tee(_dev, bias_tee);
>^
> lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:254: recipe for target
> 'lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o]
> Error 1
> CMakeFiles/Makefile2:135: recipe for target 
> 'lib/CMakeFiles/gnuradio-osmosdr.dir/all'
> failed
> make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
> Makefile:138: recipe for target 

Re: [Discuss-gnuradio] Energy Detection output incorrect

[Marcus Müller]

Hi Tellrell,

> I know you can find the PSD
Ah, so you're actually after a PSD estimate – It wasn't clear to me what
you were looking for, because the FFT-> frequency sink flowgraph didn't
make sense. And you just said "average energy" (not "average energy over
frequencies"), so I was kind of confused; sorry!

> So, ultimately, if the way that I'm implementing the algorithm is
> correct thus far, I'm looking for a way to display(graphically or
> otherwise) my result or the avg power. 
It's impossible to say whether an algorithm is correct without
specifying what it should be doing - so maybe we need to take a step back:

1. you want to do detection of IEEE 802.15.4 signals. Which PHY are we
talking about? There's multiple physical layers for that standard. The
DSSS types aren't really … friendly towards energy detection at all.
2. pure DFT-bases spectral estimation without preprocessing or
postprocessing is usually not the optimum method for signals that don't
have a spectral sinc shape; they're just easy to implement. Usually,
you'd try to detect using as much info about what the signal of interest
is as possible – especially in the presence of other systems.

Best regards,

Marcus

On 09/21/2017 11:32 AM, Tellrell White wrote:
> Thanks for the replies guys
>
> Marcus I know you can find the PSD of a signal in both the time and
> frequency domain. The only reason I'm choosing to use the frequency
> domain is because it was one of the earlier methods that I learned
> about. That's really all. From the archives I've read about people
> trying to implement energy detectors in GNU Radio for various
> applications but I never saw anybody display the results in any way or
> form. They mostly just send the statistics to a file sink and export
> to matlab or some other software for further processing. So,
> ultimately, if the way that I'm implementing the algorithm is correct
> thus far, I'm looking for a way to display(graphically or otherwise)
> my result or the avg power.
>
> Nathan would you remove the vector to stream block as well? And, why
> would you have to remove the stream to vector block? Isn't that the
> format that I want the data in? Also, how do you go about adding
> "vector modes" to the remaining blocks?
>
> Tellrell
>
> On Thu, Sep 21, 2017 at 1:30 PM, West, Nathan
> > wrote:
>
> You can use the qt gui vector plot to plot a vector. That means
> removing the stream to vector block. You might have to add
> "vector" modes to some blocks to do the other operations you want.
>
> On Wed, Sep 20, 2017 at 6:31 PM, Tellrell White
> > wrote:
>
> Hello Marcus
> You are absolutely correct. Is there an existing sink that
> would allow me to display avg power given some threshold ?
>
> Tellrell
>
>
> On Wednesday, September 20, 2017 5:54 PM, Marcus Müller
> >
> wrote:
>
>
> Hi Tellrell!
> Why should both plots show the same? You send in completely
> different signals!
> Best regards,
> Marcus
>
> On 09/20/2017 09:27 AM, Tellrell White wrote:
> Hello All
> I'm working on a project involving signal detection of an IEEE
> 802.15.4 waveform using energy detection.
> The algorithm for energy detection goes as follows:
>
>   A/D conversion ->  FFT -> mag^2 -> (1/N) ^ M ->
> threshold comparison
>
> Currently, I'm doing simulations in gnuradio companion with a
> focus of just trying to construct the the algorithm and get an
> output. Below I've attached the current flowgraph i'm using
> along with screen shots of the flowgraph and the outputs from
> the fft sinks.
>
> In the flowgraph i'm using gaussian noise as my source. I send
> this noise to both an FFT sink and also through the energy
> detection algorithm. My expectation is that both sinks will
> give me the same result, however, the output coming from the
> algorithm doesn't match the other sink and I'm currently now
> sure why this is. Are there some blocks I'm currently missing
> and/or is the FFT sink an incorrect way of trying to display
> the power coming from the energy detection algorithm?
>
> Any suggestions are welcome.
>
> Regards
> Tellrell
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>
> ___
> Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
> 

[Discuss-gnuradio] cppunit not displaying any messages

[Miklos Maroti]

Hi All,

I am not that familiar with cppunit, but my understanding is that it
should print out a message when CPPUNIT_ASSERT or
CPPUNIT_ASSERT_MESSAGE failes. I have deliberately added failures, and
indeed the test fails with ctest but no output is produced. I am using
"ctest -VV". I am getting all outputs from python based QA errors.
Does anyone know why this is happening?

Best,
Miklos

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-osmocom make failing

[Ron Economos]

It's due to a mismatch between gr-osmosdr and the Ubuntu 16.04 rtlsdr 
library. There are a few different solutions to this problem.


1) If you're not using RTL-SDR dongles, then just purge the rtlsdr 
packages (librtlsdr-dev and librtlsdr0). Then rebuild gr-osmosdr and 
Osmocom RTLSDR should end up in the disabled components during the cmake 
phase.


2) Checkout a previous version of gr-osmosdr from before this change. 
git checkout cf954948 should work.


3) The correct solution is to build the rtl-sdr library from source and 
make sure gr-osmosdr links to that.


https://github.com/osmocom/rtl-sdr

Ron

On 09/21/2017 11:40 AM, Tom McDermott wrote:

Using Ubuntu 16.04, Have guradio 3.7.12git-231 master branch
gnuradio runs fine.

The old version of Osmocom no longer runs (after some years), so
I started rebuild of gr-osmocom from scratch by cloning from 
git.osmocom.org/gr-osmosdr 

my current appliation is to get rtl-sdr running using Osmocom.

Are there  packages I must install to allow gr-osmocom to compile?


Running CMAKE succeeds, with some missing packages:


-- ##
-- # Gnuradio enabled components
-- ##
--   * Python support
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle
--   * IQ File Source & Sink
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * Ettus USRP Devices
--   * HackRF & rad1o Badge
--   * nuand bladeRF
--   * RFSPACE Receivers
--   * Red Pitaya SDR
--
-- ##
-- # Gnuradio disabled components
-- ##
--   * sysmocom OsmoSDR
--   * FUNcube Dongle Pro+
--   * Osmocom MiriSDR
--   * AIRSPY Receiver
--   * SoapySDR support
--   * FreeSRP support
--
-- Building for version: v0.1.4-98-gc653754d / 0.1.5git
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tom/gr-osmosdr/build



MAKE then fails:

tom@tom-XPS-8500:~/gr-osmosdr/build$ make
Scanning dependencies of target gnuradio-osmosdr
[  2%] Building CXX object 
lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o
[  4%] Building CXX object 
lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o

[  6%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o
[  8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o
[ 11%] Building CXX object 
lib/CMakeFiles/gnuradio-osmosdr.dir/time_spec.cc.o
[ 13%] Building CXX object 
lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o
[ 15%] Building CXX object 
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o
[ 17%] Building CXX object 
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_sink_c.cc.o
[ 20%] Building CXX object 
lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc: In constructor 
‘rtl_source_c::rtl_source_c(const string&)’:
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc:224:43: error: 
‘rtlsdr_set_bias_tee’ was not declared in this scope

   ret = rtlsdr_set_bias_tee(_dev, bias_tee);
   ^
lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:254: recipe for target 
'lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o' failed
make[2]: *** 
[lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o] Error 1
CMakeFiles/Makefile2:135: recipe for target 
'lib/CMakeFiles/gnuradio-osmosdr.dir/all' failed

make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
tom@tom-XPS-8500:~/gr-osmosdr/build$




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-osmocom make failing

[Tom McDermott]

Using Ubuntu 16.04, Have guradio 3.7.12git-231  master branch
gnuradio runs fine.

The old version of Osmocom no longer runs (after some years), so
I started rebuild of gr-osmocom from scratch by cloning from
git.osmocom.org/gr-osmosdr
my current appliation is to get rtl-sdr running using Osmocom.

Are there  packages I must install to allow gr-osmocom to compile?


Running CMAKE succeeds, with some missing packages:


-- ##
-- # Gnuradio enabled components
-- ##
--   * Python support
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle
--   * IQ File Source & Sink
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * Ettus USRP Devices
--   * HackRF & rad1o Badge
--   * nuand bladeRF
--   * RFSPACE Receivers
--   * Red Pitaya SDR
-- 
-- ##
-- # Gnuradio disabled components
-- ##
--   * sysmocom OsmoSDR
--   * FUNcube Dongle Pro+
--   * Osmocom MiriSDR
--   * AIRSPY Receiver
--   * SoapySDR support
--   * FreeSRP support
-- 
-- Building for version: v0.1.4-98-gc653754d / 0.1.5git
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tom/gr-osmosdr/build



MAKE then fails:

tom@tom-XPS-8500:~/gr-osmosdr/build$ make
Scanning dependencies of target gnuradio-osmosdr
[  2%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o
[  4%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o
[  6%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o
[  8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o
[ 11%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/time_spec.cc.o
[ 13%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o
[ 15%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o
[ 17%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_sink_c.cc.o
[ 20%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc: In constructor
‘rtl_source_c::rtl_source_c(const string&)’:
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc:224:43: error:
‘rtlsdr_set_bias_tee’ was not declared in this scope
   ret = rtlsdr_set_bias_tee(_dev, bias_tee);
   ^
lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:254: recipe for target
'lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o]
Error 1
CMakeFiles/Makefile2:135: recipe for target
'lib/CMakeFiles/gnuradio-osmosdr.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
tom@tom-XPS-8500:~/gr-osmosdr/build$
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Energy Detection output incorrect

[Tellrell White]

Thanks for the replies guys

Marcus I know you can find the PSD of a signal in both the time and
frequency domain. The only reason I'm choosing to use the frequency domain
is because it was one of the earlier methods that I learned about. That's
really all. From the archives I've read about people trying to implement
energy detectors in GNU Radio for various applications but I never saw
anybody display the results in any way or form. They mostly just send the
statistics to a file sink and export to matlab or some other software for
further processing. So, ultimately, if the way that I'm implementing the
algorithm is correct thus far, I'm looking for a way to display(graphically
or otherwise) my result or the avg power.

Nathan would you remove the vector to stream block as well? And, why would
you have to remove the stream to vector block? Isn't that the format that I
want the data in? Also, how do you go about adding "vector modes" to the
remaining blocks?

Tellrell

On Thu, Sep 21, 2017 at 1:30 PM, West, Nathan 
wrote:

> You can use the qt gui vector plot to plot a vector. That means removing
> the stream to vector block. You might have to add "vector" modes to some
> blocks to do the other operations you want.
>
> On Wed, Sep 20, 2017 at 6:31 PM, Tellrell White 
> wrote:
>
>> Hello Marcus
>> You are absolutely correct. Is there an existing sink that would allow me
>> to display avg power given some threshold ?
>>
>> Tellrell
>>
>>
>> On Wednesday, September 20, 2017 5:54 PM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>
>> Hi Tellrell!
>> Why should both plots show the same? You send in completely different
>> signals!
>> Best regards,
>> Marcus
>>
>> On 09/20/2017 09:27 AM, Tellrell White wrote:
>>
>> Hello All
>> I'm working on a project involving signal detection of an IEEE 802.15.4
>> waveform using energy detection.
>> The algorithm for energy detection goes as follows:
>>
>>   A/D conversion ->  FFT -> mag^2 -> (1/N) ^ M -> threshold
>> comparison
>>
>> Currently, I'm doing simulations in gnuradio companion with a focus of
>> just trying to construct the the algorithm and get an output. Below I've
>> attached the current flowgraph i'm using along with screen shots of the
>> flowgraph and the outputs from the fft sinks.
>>
>> In the flowgraph i'm using gaussian noise as my source. I send this noise
>> to both an FFT sink and also through the energy detection algorithm. My
>> expectation is that both sinks will give me the same result, however, the
>> output coming from the algorithm doesn't match the other sink and I'm
>> currently now sure why this is. Are there some blocks I'm currently missing
>> and/or is the FFT sink an incorrect way of trying to display the power
>> coming from the energy detection algorithm?
>>
>> Any suggestions are welcome.
>>
>> Regards
>> Tellrell
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio build swig code fail on USB

[David]

Now very embarrassed,
Issue was the mount, I created a "hello world" executable, and couldn't 
run that either, massive clue!
Mount options in fstab included "user" which mounts 
(rw,nosuid,nodev,noexec,noatime,data=ordered,user).

Remove "user"... mount then shows:
/dev/sda1 on /home/odroid type ext4 (rw,noatime,data=ordered)
from fstab entry:
UUID=eb5f2347-4e3c-459d-9f58-ef87e6428a25 /home/odroid ext4 
nofail,x-systemd.device-timeout=1,noatime  0  2

which works,
Many thanks all for your input, my bad at the end of the day...
All the best, sorry for the waste of time,
Dave

On 21/09/17 05:40, Cinaed Simson wrote:

On 09/19/2017 09:50 AM, David wrote:

Many Thanks Cinaed for going to this trouble :-).

My USB drive partitions:

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa18426f3

Device Boot Start   End   Sectors   Size Id Type
/dev/sda12048 976773167 976771120 465.8G 83 Linux

Yes, quite big, but was using it for Windows backup :-).
I should add, it's USB2, and is connected via a USB3 hub to the Odroid
USB3.
No idea if that make a difference.

I feel now I need to continue, I can build now on the USB2 (once a make
install is
done from the sd card!).

My guess is you have path problems.

Multiple installs of the same program is tricky business.

The test will be to uninstall gnuradio from the sdcard after the
installation on the usb, and see if the usb install works.

-- Cinaed



Thanks again ALL for you input,
Dave




On 19/09/17 01:08, Cinaed Simson wrote:

It works for me - but my setup is slightly different.

I have a odroid-xu4 using emmc for the internal drive and it's running
Debian 8.8.

Ubuntu is a fork of Debian so typically (system wise) what works on
Debian should work on Ubuntu.

I started building gnuradio on a 64 GByte USB2 thumb drive plugged into
one of USB3 ports.

I killed the build after it reached 50%.

First, make sure the USB drive is mounted.

Then look at the partitions on your USB drive - they should look similar
to the following - I'm using the entire USB drive as a single partition:

root@poynting:/home/cinaed# fdisk -l /dev/sda

Disk /dev/sda: 59.2 GiB, 63518539776 bytes, 124059648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x

Device Boot Start   End   Sectors  Size Id Type
dev/sda1  32 124059647 124059616 59.2G 83 Linux

Make sure mounting of the USB drive is what you expect:

root@poynting:/home/cinaed# mount | grep mnt
/dev/sda1 on /mnt type ext4 (rw,relatime,data=ordered)

A make on SDCARD shouldn't impact a make on the USB drive.

-- Cinaed


On 09/18/2017 09:18 AM, David wrote:

oops,

USB mount should be

# mount /dev/sda1 /mnt


On 18/09/17 17:09, David wrote:

Hi Cinaed,

OS is installed on SD card (no emmc).

I built UHD, as odroid user, on the USB drive, cmake, make, sudo make
install. Works fine.

Then try to build GNURadio, as odroid user, on USB drive, cmake,
make... then the permission denied.
Tried building as root (after blowing away the build dir contents),
cmake, make, then the permission denied.

Then build GNURadio, as odroid user, on SD card, cmake, make, sudo
make install. Works fine.

Weird thing is, then I can then do make OK on the USB drive.
Is there some persistent info stored in odroid home dir, or elsewhere?
Because if I do make uninstall on the SD card, I can't then do a make
on the USB drive for same reason (after blowing the build dir away).

I want to build on the USB drive so that I have all the build-able
source on the USB, in case I have to re-instate the OS, flexibility,
and reduced download time (as I have had to do several times due to
power issues causing corruptions on the SD card. This is probably
sorted now I have a good PSU, but also to reduce wear on the SD card.

fstab mount:
UUID=eb5f2117-4e3c-459d-9f58-ef87e6428a25 /home/odroid ext4
defaults,noatime,user  0  2

yet mounting as
# mount /dev/sdd1 /mnt
make no difference.

Thank you,
Dave


On 18/09/17 07:02, Cinaed Simson wrote:

On 09/17/2017 06:29 AM, David wrote:

Hi Cinaed,
Sorry no, USB build was first, after clean install of OS, then UHD.

Just to be clear, you re-installed the os on the odroid and not the
usb
drive?

Have you built the UHD software on the usb drive?

Blow away the build directory and try it again.

If it fails, try it as root.

Look at the log files

  dmesg
  /var/log/messages
  /var/log/syslog


Only "cmake .. " disabled component left was gr-comedi.

Type

 apt-get install libcomedi-dev


I think this may be a file-system thing, maybe how it is mounted?
Dave

How did you mount it?

Type

 mount

Are you using usb drive, sdcard and emmc card 

Re: [Discuss-gnuradio] Energy Detection output incorrect

[West, Nathan]

You can use the qt gui vector plot to plot a vector. That means removing
the stream to vector block. You might have to add "vector" modes to some
blocks to do the other operations you want.

On Wed, Sep 20, 2017 at 6:31 PM, Tellrell White  wrote:

> Hello Marcus
> You are absolutely correct. Is there an existing sink that would allow me
> to display avg power given some threshold ?
>
> Tellrell
>
>
> On Wednesday, September 20, 2017 5:54 PM, Marcus Müller <
> marcus.muel...@ettus.com> wrote:
>
>
> Hi Tellrell!
> Why should both plots show the same? You send in completely different
> signals!
> Best regards,
> Marcus
>
> On 09/20/2017 09:27 AM, Tellrell White wrote:
>
> Hello All
> I'm working on a project involving signal detection of an IEEE 802.15.4
> waveform using energy detection.
> The algorithm for energy detection goes as follows:
>
>   A/D conversion ->  FFT -> mag^2 -> (1/N) ^ M -> threshold
> comparison
>
> Currently, I'm doing simulations in gnuradio companion with a focus of
> just trying to construct the the algorithm and get an output. Below I've
> attached the current flowgraph i'm using along with screen shots of the
> flowgraph and the outputs from the fft sinks.
>
> In the flowgraph i'm using gaussian noise as my source. I send this noise
> to both an FFT sink and also through the energy detection algorithm. My
> expectation is that both sinks will give me the same result, however, the
> output coming from the algorithm doesn't match the other sink and I'm
> currently now sure why this is. Are there some blocks I'm currently missing
> and/or is the FFT sink an incorrect way of trying to display the power
> coming from the energy detection algorithm?
>
> Any suggestions are welcome.
>
> Regards
> Tellrell
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Energy Detection output incorrect

[Marcus Müller]

Hi Tellrell,

if you just need average power, why go to the frequency domain at all?
That doesn't make sense to me, but maybe I'm not getting the whole picture.


Best regards,

Marcus



On 09/20/2017 03:31 PM, Tellrell White wrote:
> Hello Marcus
> You are absolutely correct. Is there an existing sink that would allow
> me to display avg power given some threshold ?
>
> Tellrell
>
>
> On Wednesday, September 20, 2017 5:54 PM, Marcus Müller
>  wrote:
>
>
> Hi Tellrell!
> Why should both plots show the same? You send in completely different
> signals!
> Best regards,
> Marcus
>
> On 09/20/2017 09:27 AM, Tellrell White wrote:
> Hello All
> I'm working on a project involving signal detection of an IEEE
> 802.15.4 waveform using energy detection.
> The algorithm for energy detection goes as follows:
>
>   A/D conversion ->  FFT -> mag^2 -> (1/N) ^ M -> threshold
> comparison
>
> Currently, I'm doing simulations in gnuradio companion with a focus of
> just trying to construct the the algorithm and get an output. Below
> I've attached the current flowgraph i'm using along with screen shots
> of the flowgraph and the outputs from the fft sinks.
>
> In the flowgraph i'm using gaussian noise as my source. I send this
> noise to both an FFT sink and also through the energy detection
> algorithm. My expectation is that both sinks will give me the same
> result, however, the output coming from the algorithm doesn't match
> the other sink and I'm currently now sure why this is. Are there some
> blocks I'm currently missing and/or is the FFT sink an incorrect way
> of trying to display the power coming from the energy detection algorithm?
>
> Any suggestions are welcome.
>
> Regards
> Tellrell
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Matplotlib and GNU Radio: Dynamic plot

[Marcus Müller]

Interesting!

So, my approach in this case would be:

1. Write a block that takes the data from your flow graph, and converts
it to a format (e.g. JSON, KML, GPX,…) that makes sense for the
receiving end. This data should be emitted as messages (not python
variables).
2. use a UDP or ZeroMQ (I recommend the latter) to send these messages out
3. Write a really minimal web application that receives the things from
2. and updates a browser visualization. Use your own images or simply
OpenStreetMap as base layer.

You can of course also write your own visualization block. That's
absolutely feasible; it's just that matplotlib is really not the tool of
choice for that here. But it's definitely not the software you need,
either, to draw points on an image. There's literally dozens of python
toolkits that can display images and modify them.

Writing visualization blocks will require you to think about how to
thread them. And since it'll be hard for the block to interact with the
main thread, but that would be necessary for GUI blocks to work, I don't
know whether that is an entry level project. Anyway, do have a look at
Tim O'Shea gr-pyqt ; it contains python visualization blocks, and I
don't think it'll be hard to understand and modify them. Look at the
raster_plot.py for example.

Best regards,

Marcus

On 09/20/2017 10:21 PM, Ali wrote:
> Hi,
>
> Actually I want to draw coordinates on a map. So I want to upload a
> map(a png file, like using imshow function in MATLAB, matplotlib) and
> then draw points on this map. I think it is not possible by just using
> QT instruments. 
>
> Regards,
> Ali
>
> 2017-09-20 21:14 GMT+03:00 Marcus Müller  >:
>
> Dear Ali,
>
> don't convert data streams to Python variables. Just use the Qt
> instrumentation plots that directly come with GNU Radio, they are
> actually meant for this.
>
> Matplotlib is *definitely* not what you want to use for live
> plots. Far too slow.
>
> Best regards,
>
> Marcus
>
>
> On 09/20/2017 01:29 AM, Ali wrote:
>> Hi everyone,
>>
>> I have a flowchart in which USRP's are running and after some
>> blocks 2 variables are produced at the output.
>>
>> As the inputs change, outputs change. I want to _dynamically_
>> plot these two variables on x and y axis. I am willing to use
>> matplotlib.
>>
>> What do you suggest to plot these variables?
>>
>> 1- Write them to a .txt file and read by matplotlib at the same time,
>> 2- Without writing the variable anywhere, directly use in
>> matplotlib(somehow)
>> 3- Write a python block and use in GRC directly
>>
>> I don't know whether these can be applied or not. I am open to
>> any ideas.
>>
>> Regards,
>> Ali
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Send bytes using BPSK modulation with USRP N210

[Marcus Müller]

How are you determining that they are shifted?

So, you don't have framing, so there's simply no knowing for the
receiver which one was the first bit. You'll need to add a framer of sorts.

Best regards,

Marcus


On 09/21/2017 01:33 AM, Kurniawan Dwi Irianto wrote:
> Hi guys,
>
> I am trying to send bytes from sender to receiver using BPSK
> modulation and USRP N210. The receiver can get the bytes from sender
> but somehow its bits are shifted one or two bit to the right. The
> devices I am using are USRP N210. They are connected to my computer
> through a switch and the distance between USRPs is only 1 meter. The
> flowgraph I made can be seen in the attachment.
>
> Does anybody know how to make it right? I really appreciate any
> suggestions. Thanks.
>
> Best regards,
> Kirianto
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to resize qtgui spectrum display widget (qtgui::sink_c)

[Adrian Musceac]

Hello,

I'm trying to get the qtgui sink_c widget to display with a custom
size based on window coordinates. I am calling
fft_gui->qwidget()->resize(700,350) but the only thing that gets
resized is the parent widget (returned by qwidget() ) which holds the
FFT and waterfall. Unfortunately the FFT widget gets clipped and
displayed with an incorrect size making it useless.
Is there any way to control the FFT widget directly or get it to
automatically follow the size of the parent widget?

Attaching screenshot for reference.

Thanks,
Adrian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio