Open Workshop on Machine Learning in Communications @ IEEE ICC 2020 (Call for Contributions)

[West, Nathan]

Hi all,

Please consider contributing your work or demonstration proposals to the
workshop at IEEE ICC if you are working at the intersection of
communications systems and machine learning. Please see the CFP below for
details.

-Nathan

Call for Papers:

IEEE ICC 2020 Open Workshop on Machine Learning in Communications

7-11 June 2020, Dublin, Ireland

** Submission deadline: January 27, 2020 **

https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications/

===
Call For Papers
===
Machine Learning in Communications is a rapidly growing field within
networking and communications with the potential to substantially transform
wireless, optical, and other modes of networking and communications
engineering in a wide range of future systems by leveraging measurement,
data, feedback, domain knowledge, and learning to achieve optimality for a
wide range of performance metrics. By directly exploiting real data,
representation learning, end-to-end learning, reinforcement learning,
concurrent neuromorphic processing, and a wide range of concepts which have
advanced rapidly in the machine learning community in recent years,
ML-Comms holds the promise to discover alternative and superior ways for
information processing in practical application scenarios where deficient
or inaccurate models limit present development. `
Openness and Reproducibility are two essential components in conducting
rigorous machine learning driven research, and this workshop seeks to
highlight and encourage both of these to help further increase the maturity
of communications as a data science.
· Authors are strongly encouraged to utilize open tools such as
pre-publication (e.g. ArXiv), providing reference code, data, simulations,
GNU Radio modules, etc. openly (e.g. Github), and fully describe their
methodologies in an open and re-producible way such that others can easily
validate, leverage and build upon their work.
· For accepted workshop papers meeting such criterion, IEEE ComSoc is
willing to provide as Open-Access publications at no additional fee to the
authors!

MLC Dataset Challenge: In this year’s ICC 2020 Open Workshop, we are also
excited to announce an open-dataset challenge focused on the unique task of
Vision-Aided Beam Tracking for mmWave Systems. This challenge will adopt
the recently developed ViWi dataset. Additional details of the competition
and submission will be provided in early February 2020 via the workshop
webpage:
https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications.
The workshop expects to announce results at the ICC’2020 on a hold-out test
set and invite competitors to share their approaches and experiences.

We invite submissions of unpublished works on the application and theory of
machine learning to communications. The workshop shall not restrict the
type of machine learning techniques and applications but does provide the
following list is a non-exhaustive list of suggested topics.
· Machine learning driven design and optimization of modulation and coding
schemes
· Machine learning techniques for channel estimation, channel modeling, and
channel prediction.
· Machine learning based enhancements for difficult to model communications
channels such as molecular, biological, multi-scale, and other
non-traditional communications mediums
· Transceiver design and channel decoding using deep learning
· Machine learning driven techniques for radio environment awareness and
decision making
· Machine learning for Internet of things (IoT) and massive connectivity.
· Machine learning for ultra-reliable and low latency communications
(URLLC).
· Machine learning for Massive MIMO, active and passive Large Intelligent
Surfaces (LIS).
· Distributed learning approaches for distributed communications problems
· (Deep) Reinforcement Learning and Policy learning for resource management
& optimization
· Reinforcement Learning for self-organized networks and AP/BTS optimization
· Machine learning techniques for non-linear signal processing
· Low-complexity and approximate learning techniques and power reduction
applications
· Machine learning for edge Intelligence, sensing platforms, and sense
making
· Algorithmic advances in machine learning for communication systems
· Advancing the joint understanding of information theory, capacity,
complexity and machine learning communications systems
· Machine learning methods for exploiting complex spatial, traffic,
channel, traffic, power and other distributions more effectively using
measurement vs idealized distributions.
· Compression of neural networks for low-complexity hardware implementation
· Unsupervised, semi-supervised and self-supervised learning approaches to
communications

===
Important Dates
===
Paper submission deadline: January 27, 2020
Notification of acceptance: February 20, 202
Camera-ready papers: March 1, 2020
===
Paper 

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

[West, Nathan]

If you decide to go that route I'm happy to discuss possible re-use of
libsigmf and/or lessons learned from the trenches offline (I happen to be
using it a *lot*). It's not *really* specific to SigMF. It's really just
about getting c++ struct types easily converted to/from python. External
dependencies are flatbuffers and Modern Json (nlohmann/json on github). It
doesn't care much about the binary serialization but does make working with
json-namespaced objects and moving between the c++ struct types and json
real nice. In a truly ideal world we actually wouldn't need libsigmf
because flatbuffers would include this parsing + namespace handling out of
the box and that may be possible if flatbuffers devs woulf find this
functionality valuable.

Nathan

On Sun, Sep 29, 2019 at 10:04 AM Marcus Müller 
wrote:

> Wow, thanks. Yeah, that clearly reinforces flatbuffers as tool of
> choice.
>
> Tbh, I'd just assume that in all these formats, being tight-packing by
> default, std::complex can just be represented by the equivalent
> of struct {float re; float im;} complex;.
>
>
> On Sun, 2019-09-29 at 09:32 -0500, West, Nathan wrote:
> > While developing libsigmf (https://github.com/deepsig/libsigmf) I
> > went through a similar experience. The objective was to have painless
> > json file/string <-> real c++ type (this means the serialization
> > thing had to generate a slimmed down type that is effectively a
> > struct of vector, int, float, etc). I looked at cap'n proto,
> > flatbuffers, protobuf, and some others that weren't as
> > mature/supported. I actually started with cap'n proto and had to
> > switch to flatbuffers.
> >
> > Other bonuses I encountered were the whole "zero-time serialization"
> > (In my experience people love making fun of cap'n proto for this, but
> > it's true for all of the popular architectures and then you pay for
> > shuffling bytes on more exotic architectures) and the sort of random-
> > access parsing. A big perk of cap'n proto was it actually came with
> > json-parsing to flatbuffer type *and* had the ability to generate a
> > sane struct definition.
> >
> > I eventually switched to flatbuffers. Here's a randomly-ordered list
> > of why
> >
> > * cap'n proto's author is no doubt an incredible programmer. However,
> > he made some really weird choices. Like wrote his own string class in
> > libkj and made all of cap'n proto depend on it. And it's not all that
> > friendly with c++ string. So you wind up having to convert every
> > single string in to a kj::string just for serialization (and vice
> > versa)
> > * libkj also implements its own memory allocators, filesystem library
> > (ala boost filesystem / c++ filesystem), mutexes, and threads. I'm
> > not capable of vetting those implementation but beg to be asked a big
> > old "WHY?!"
> > * cap'n proto is incredibly strict (in CS parlance I guess you can
> > call it opinionated) on protocol description language. It enforces
> > things such as FirstletterMustBeCapital
> > * I also felt the syntax of moving around these objects was a bit
> > awkward
> >
> > I think there may be some other less appalling things that I've
> > struck from my memory as "writing your own string that's incompatible
> > with the rest of c++" is a big enough grievance that I'm only just
> > now starting to forgive gcc dual abi for (but at least even that is
> > at the ABI level which is always hard to get right). Flatbuffers
> > offered pretty much the same promises as cap'n proto but without the
> > "reinvent the standard library first" mindset and let's you make your
> > own choices about how to name your fields, etc. I will say cap'n
> > proto had a nice-looking extension capability to their parsing which
> > I haven't found a good alternative for.
> >
> > The downside is flatbuffers is released by google/android's
> > benevolence and somewhat competes with protobufs which is clearly
> > their darling. I can't tell how much anyone else cares about
> > flatbuffers although the *major* advantage to flatbuffers that I
> > couldn't find in protobuf (which made me choose flatbuffers) is the
> > struct code generator so you get out pretty normal struct's from
> > their code generator that look like something you would write if you
> > did it by hand.
> >
> > The downside is I don't know what complex support looks like in
> > any of these things.
> >
> > Cheers,
> > Nathan
> >
> > On Sun, Sep 29, 2019 at 5:21 AM Marcus Müller 
> > wrote:
> > > Hi Nick,
> > >
> > >
> > > On

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

[West, Nathan]

While developing libsigmf (https://github.com/deepsig/libsigmf) I went
through a similar experience. The objective was to have painless json
file/string <-> real c++ type (this means the serialization thing had to
generate a slimmed down type that is effectively a struct of vector, int,
float, etc). I looked at cap'n proto, flatbuffers, protobuf, and some
others that weren't as mature/supported. I actually started with cap'n
proto and had to switch to flatbuffers.

Other bonuses I encountered were the whole "zero-time serialization" (In my
experience people love making fun of cap'n proto for this, but it's true
for all of the popular architectures and then you pay for shuffling bytes
on more exotic architectures) and the sort of random-access parsing. A big
perk of cap'n proto was it actually came with json-parsing to flatbuffer
type *and* had the ability to generate a sane struct definition.

I eventually switched to flatbuffers. Here's a randomly-ordered list of why

* cap'n proto's author is no doubt an incredible programmer. However, he
made some really weird choices. Like wrote his own string class in libkj
and made all of cap'n proto depend on it. And it's not all that friendly
with c++ string. So you wind up having to convert every single string in to
a kj::string just for serialization (and vice versa)
* libkj also implements its own memory allocators, filesystem library (ala
boost filesystem / c++ filesystem), mutexes, and threads. I'm not capable
of vetting those implementation but beg to be asked a big old "WHY?!"
* cap'n proto is incredibly strict (in CS parlance I guess you can call it
opinionated) on protocol description language. It enforces things such as
FirstletterMustBeCapital
* I also felt the syntax of moving around these objects was a bit awkward

I think there may be some other less appalling things that I've struck from
my memory as "writing your own string that's incompatible with the rest of
c++" is a big enough grievance that I'm only just now starting to forgive
gcc dual abi for (but at least even that is at the ABI level which is
always hard to get right). Flatbuffers offered pretty much the same
promises as cap'n proto but without the "reinvent the standard library
first" mindset and let's you make your own choices about how to name your
fields, etc. I will say cap'n proto had a nice-looking extension capability
to their parsing which I haven't found a good alternative for.

The downside is flatbuffers is released by google/android's benevolence and
somewhat competes with protobufs which is clearly their darling. I can't
tell how much anyone else cares about flatbuffers although the *major*
advantage to flatbuffers that I couldn't find in protobuf (which made me
choose flatbuffers) is the struct code generator so you get out pretty
normal struct's from their code generator that look like something you
would write if you did it by hand.

The downside is I don't know what complex support looks like in any of
these things.

Cheers,
Nathan

On Sun, Sep 29, 2019 at 5:21 AM Marcus Müller  wrote:

> Hi Nick,
>
>
> On Sat, 2019-09-28 at 15:54 -0700, Nick Foster wrote:
> > I think it's wise to avoid hitching our metaphorical horse to any
> > software project we can't absolutely depend on; questionable
> > dependency choices have bit us, as you mention, many times.
>
> Sad but true.
>
> > With that (somewhat) in mind, what about Flatbuffers as an
> > alternative to Cap'n Proto? Seems much more actively maintained, more
> > widely used, and designed with the same goals in mind. No parsing
> > step required, so performance is good. Memory use seems to be
> > similarly efficient.
>
> See, that's the kind of input I was looking for!
> So, what I don't like about flatbuffers was the lack of field IDs in
> the schema; relying on new fields only being added to the end of a
> structure.
>
> However, thanks to your encouragement I've revisited that and:
> Flatbuffers *does* do IDs, if you want (it's slightly awkward, but all
> formal structure definition languages are, aside from ASN.1 ;) ).
>
> Regarding efficiency: https://github.com/thekvs/cpp-serializers seems
> to agree with your assessment.
>
> What flatbuffers really got going for it compared to the Cap'n is that
> docs are structured instead of "cool feature-oriented". What Cap'n
> Proto has is the more sympathetic code base, but maybe I shouldn't be
> applying too many human qualities to code bases. gnuradio-runtime/lib/
> gets jealous everytime I do that.
>
> Best regards,
> Marcus
>
> >
> > Now, I haven't actually used Flatbuffers before, so anyone who has
> > experience with them (or your other favorite serialization library!),
> > please chime in here.
> >
> > Nick
> >
> > On Sat, Sep 28, 2019 at 2:02 PM Marcus Müller 
> > wrote:
> > > To avoid the setting in of post-Conference downs:
> > >
> > > Dearest SDR Community with the Highest count of "Awesome" in the
> > > Universe,
> > >
> > > discussions at GRCon have made it abundantly 

[Discuss-gnuradio] VOLK v1.3.1 and v1.4

[West, Nathan]

Hi all,

After a long time, new Volk releases are out. Release notes and downloads
are in the normal places on libvolk.org with md5sums and signatures signed
by me (nathan.w...@gnuradio.org).

v1.3.1 is a support release with bug fixes. I've switched to the "merge
back" model for this release where everything goes in to master and I
cherry-pick commits back to a support branch. I think this makes it easier
to keep all of the changes in one place-- but I'd like to know what kind of
support users would like. If you care about stable APIs for a long time I'd
like to hear about it so that I can develop a sense of how long or how many
"stable" branches I should keep around.

v1.4 has a ton of new stuff... It builds with python3, has new kernels, new
protokernels with lots of AVX support, and some added NEON support. I'm
pretty excited about this release since it adds a good bit of fast code!

Call for development:
v1.5 is not out yet (or started), but I imagine that it will add support
for AVX512 and purge boost (that might make it in to a v1.4.1) as a
dependency and maybe replace some verbose support code with c++11. Right
now there are 2 remaining lines that require boost. If you care about that
kind of thing check out the boost::filesystem use in volk_profile. I have
heard of someone adding AVX512 support, but I don't have a machine that
supports it-- continue down that path if you have a machine with support!

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

Re: [Discuss-gnuradio] Gnuradio installs with pybombs on Windows 7 computer with VMWare 10 but not on Windows 10 computer with VMWare 12 Ubuntu 17.04

[West, Nathan]

As the error says, that's an internal error to the compiler. That usually
means that you ran out of memory. The quick-and-dirty method to resolve
this is to add swap. The better solution may be apt-get install gnuradio

On Mon, Sep 25, 2017 at 12:55 PM, Ed Troy  wrote:

> I've been trying to get gnuradio up and running on 2 computers. Both run
> Ubuntu 17.04. In both cases, I started with a clean install of Ubuntu
> followed by the instructions on https://www.gnuradio.org/blog/
> pybombs-the-what-the-how-and-the-why/
> In the case of the Windows 7 machine using VMWare 10, it went fine. No
> problems. Now, I need to figure out how to install GQRX without messing up
> gnuradio-companion.
> But, on the other computer, which is a notebook running Windows 10 and
> VMWare version 12, the installation failed. It actually looked like it
> would work. But, after an hour or so, I got the following error lines:
> Scanning dependencies of target _blocks_swig2
> [ 30%] Building CXX object gr-blocks/swig/CMakeFiles/_
> blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o
> [ 31%] Linking CXX shared module _blocks_swig2.so
> [ 31%] Built target _blocks_swig2
> [ 31%] Built target blocks_swig0_swig_doc
> [ 31%] Built target _blocks_swig0_swig_tag
> [ 31%] Built target blocks_swig0_gr_blocks_swig_a6e57
> Scanning dependencies of target _blocks_swig0
> [ 31%] Building CXX object gr-blocks/swig/CMakeFiles/_
> blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o
> c++: internal compiler error: Killed (program cc1plus)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/build.make:70: recipe for
> target 
> 'gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o'
> failed
> make[2]: *** 
> [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
> Error 4
> CMakeFiles/Makefile2:2907: recipe for target 
> 'gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all'
> failed
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
> messages.
> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
> gnuradio:
> Build failed.
> PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
> Aborting.
>
> the last command issued was pybombs prefix init -a default
> prefix/default/ -R gnuradio-default
>
> Like I said, this worked perfectly on the other computer using the same
> commands. And, I got this same problem last week when I was trying to load
> gnuradio onto the notebook. I think I was using a different version of
> Ubuntu that time, but I am not sure.
> ED
>
> --
> RF, Microwave, Antenna, and Analog Design,
> Development,Simulation, and Research Consultinghttp://aeroconsult.com
> Aerospace Consulting LLC
> P.O. Box 536
> Buckingham, Pa. 18912(215) 345-7184(215) 345-1309 FAX
>
>
> ___
> 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

[West, Nathan]

Re: vector mode
This kind of code is what you're looking for
https://github.com/gnuradio/gnuradio/pull/1462#discussion_r140610909

On Thursday, September 21, 2017, Tellrell White <rell...@gmail.com> 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
> <javascript:_e(%7B%7D,'cvml','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 <t_whit...@yahoo.com
>> <javascript:_e(%7B%7D,'cvml','t_whit...@yahoo.com');>> 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
>>> <javascript:_e(%7B%7D,'cvml','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-gnura...@gnu.org 
>>> <javascript:_e(%7B%7D,'cvml','Discuss-gnuradio@gnu.org');>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> <javascript:_e(%7B%7D,'cvml','Discuss-gnuradio@gnu.org');>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> <javascript:_e(%7B%7D,'cvml','Discuss-gnuradio@gnu.org');>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> <javascript:_e(%7B%7D,'cvml','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

[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] Vectorized Python code overflows faster

[West, Nathan]

When you are "testing" is that on a desktop PC? It seems likely that there
are numpy optimizations for your desktop processor, but not for the E310.

I've been able to write VOLK wrapped python code to easily do some
operations 10x faster than numpy code. Since there's a bunch of NEON stuff
in VOLK, that would probably translate well. Or you could just write your
code in C++ if it's really a concern and get the python runtime out of the
way of signal processing (but that's not much fun)

nw


On Fri, Jun 16, 2017 at 3:18 PM, Zach Morris 
wrote:

> I would like to know what interferer signals occur at different
> frequencies in a spectrum. Since I want to get an idea of the average
> behaviour of the spectrum, I'd like to look at the spectrum over a long
> period of time (hours?).
>
> This would be too much data to store, so I wrote a custom Python block. It
> updates power statistics (specifically the Rayleigh parameter) while the
> magnitude squared of an FFT is above a threshold, then writes the power
> statistics and the time to a file whenever an element drops below the
> threshold. This cuts down the data from tens of MBs to kBs per second.
>
> I got an overflow (the 0 character) about once every five seconds on the
> Ettus 310, running at 4MHz and 1024 vector length. To speed up the Python
> code, I vectorized the threshold and update code with numpy, and switched
> from write_line to numpy's save_txt to save the power statistics. In
> testing the new code chewed through 10,000 x 1024 vectors about thirty
> times faster than the old code. Feeling very clever, I ran the new code on
> the E310, only for it to overflow twice a second.
>
> In short, my "optimized" Python code seems to run faster in testing, but
> overflow more in practice. Could you help me understand why this happens? I
> copied some of the relevant code below, and attached a picture of my
> flowgraph. I'm new to Python and GNU Radio, so I apologize if my code is
> particularly un-Pythonic, or if I've missed something basic. :)
>
> ### Old code ###
> def write_line(self, bin, theta, n):
> now = time.time()
>
> line = str(now) + ',' + str(bin) + ',' + str(theta) + ',' + str(n)
> + '\n'
>
> self.f.write(line)
>
> def general_work(self, input_items, output_items):
> in0 = input_items[0]
>
> for i in range(len(in0[0])):
> if in0[0, i] > self.threshold:
> self.last_state[0, i] += 1
> self.theta[0, i] += in0[0, i] ** 2
> elif (self.last_state[0, i] > 0).any():
> self.write_line(i, self.theta[0, i], self.last_state[0, i])
> self.last_state[0, i] = 0
> self.theta[0, i] = 0
>
> will_consume = len(input_items)
>
> self.consume(0, will_consume)
> return len(input_items)
>
> ### Vectorized code ###
> def write_line(self, bin, theta, count):
> np.savetxt(self.f, self.fft_num, fmt='%i', newline='\n')
> np.savetxt(self.f, np.transpose([bin, theta, count]), fmt='%i
> %0.7f %i', newline='\n')
>
> # Update fft_num
> self.fft_num += 1
>
> def general_work(self, input_items, output_items):
> curr_input = input_items[0][0]
>
> # Find entries that just dropped below the threshold
> just_dropped = (self.last_state > 0) & (curr_input <=
> self.threshold)
>
> # Update theta and count
> self.last_state[0, curr_input > self.threshold] += 1
> self.theta[0, curr_input > self.threshold] +=
> curr_input[curr_input > self.threshold]**2
>
> # Write bins, thetas and counts for this vector
> self.write_line(np.nonzero(just_dropped[0])[0],
> self.theta[just_dropped], self.last_state[just_dropped])
>
> # Reset last_state and theta if below threshold
> self.last_state[0, curr_input <= self.threshold] = 0
> self.theta[0, curr_input <= self.threshold] = 0
>
> will_consume = len(input_items)
>
> self.consume(0, will_consume)
> return len(input_items)
>
> ___
> 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] Channelizer mapping

[West, Nathan]

It works kind of like an fftshift. The center channel is 0, the lowest
channel is nchannels/2 + 1 or so... I think your mapping could have 4 on
the end to get the whole sequence.

On Fri, Jun 2, 2017 at 11:25 AM, John Ackermann N8UR  wrote:

> Is there a basic rule for how to assign channel numbers to the PFB
> channelizer output?  I seem to be too dense to figure it out from the
> docs.  I just want to pull the channels out in order of their RF frequency,
> low to high.
>
> I currently have a 7 channel channelizer which seems to work properly
> after I farted around to get this map: [5,6,7,0,1,2,3] using a "Channels"
> value of 8 (note that channel 4 is thrown away).
>
> Now I want to extend the number of channels, and the number may be even or
> odd.  From Tom Rondeu's tutorial, I get the sense that the mapping changes
> based on even or odd channel count.
>
> Is there a basic rule to develop the map for the case of RFch0 = ch0,
> RFch1 = ch1, etc.?
>
> Thanks,
> John
>
> ___
> 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] Attribute Error

[West, Nathan]

My guess is that you have a block you've named "cc". It's not linked
against some external library properly.

On Mon, May 15, 2017 at 1:52 AM, Ayan Chatterjee  wrote:

> Hi all,
>
> I have made an out-of-tree module for a switch. But I am getting this
> error while executing -> AttributeError: 'module' object has no attribute
> 'cc'
>
> Any suggestions on how to get rid of this.
>
> Thanks.
>
> Regards,
> Ayan
>
> ___
> 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] OOT: Output does not update fast. Buffer size?

[West, Nathan]

Sample rate in software is just a number used in some equations to get
meaningful signals. It is *not* the rate that things are going through the
flowgraph. There are 8192 items because 8192 items happens to make a nicely
aligned buffer size.


You're not working on a real-time system or with real-time software, so you
can't expect things like "1 input per second".

On Thu, May 11, 2017 at 6:12 AM, Ali <03do...@gmail.com> wrote:

> Hi to all,
>
> I created my own OOT block. It has 6 inputs and 2 outputs and all are type
> of float. I am using Signal Source block and sending constant signals with
> different amplitudes at each input port.
>
> When I run, the the GRC file and change the one of the inputs, outputs
> changes after some time(~5 seconds). To examine the problem, I am printing
> the following variables on the screen:
>
> noutput_items, input1[1], input1[noutput_items], output1[1],
> output1[noutput_items]
>
> ...
> 8192, 44, 44, 1, 1   >>> Input1 is 44 and outputs are 1
> 8192, 44, 44, 1, 1   >>> Input 1 is still 44
>
> 8192, 44, 26, 1, 1   >>> I changed the input1 to 26. Note that input[1] is
> still 44. input[noutput_items] is 26 but output[noutput_items] is also 1!
>
> 8192, 26, 26, 1, 1   >>> The content of input1 is all 26, but the output
> is still 1!
> 8192, 26, 26, 1, 1   >>> The output is still 1!
> 8192, 26, 26, 2, 2   >>> Now the correct output is found!
> 
>
> First of all, why the dimension of input and output is 8192(sometimes
> 8191)?
>
> samp_rate defined for Signal Source block is smaller than 8192. I am using
> 1, 100 or 1000. But as you can see noutput_items is 8192. How there can be
> 8192 inputs if the sample rate is for example 10?
>
> My module content is like the following:
>
> 
> int myfunction_impl::*general_work*(...)
> {
> const float *input1 = ..
> ..
>
> for (int i=; i {
> *my_function*(input1[i],...,[i],[i])
> }
>
> consume_each(noutput_items);
> return noutput_items;
> }
> --
>
> In short, I want that one input comes per second(sampling rate 1) and one
> output is out and displayed.
>
> 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

Re: [Discuss-gnuradio] OOT Module using external function

[West, Nathan]

I don't know what a .obj file from matlab coder is but completely
ingoring that file it sounds like you need to tell cmake that the .cpp file
from matlab needs to be built.

On Fri, May 5, 2017 at 9:38 AM, Ali <03do...@gmail.com> wrote:

> Hi,
>
> Under gr-TUTORIAL/lib there is myfunction_impl and myfunction_impl.cc
> files which gr_modtool itself created.
> MATLAB Coder gives .h, .cpp and .obj files. I put them under the same
> directory(gr-TUTORIAL/lib).
> Then what I do is including all .h files that MATLAB generated inside two
> files that gr_modtool generated(I wrote #include ... in both .h and .cc
> file).
>
> In the following part of the .cc file I tried to use the function that
> MATLAB generated.
>
> --
>
> int myfunction_impl::*general_work*(...)
> {
> const float *input1 = ..
> ..
>
> for (int i=; i<noutput_items; i++)
> {
> *my_function*(...)
> }
>
> consume_each(noutput_items);
> return noutput_items;
> }
>
> 
>
> I don't know how to link .obj files to my module? Could you suggest a
> piece of code?
>
> Or after the things that I told now, is there any major mistake that I am
> doing?
>
> Thanks,
> Ali
>
>
>
>
>
> 2017-05-04 17:12 GMT+03:00 West, Nathan <n...@ostatemail.okstate.edu>:
>
>> You have an external object that you need to link your module to. That
>> cpp file from matlab gets compiled to an object file somehow-- you haven't
>> specified how. Then you need to link your block to that object.
>>
>> On Wed, May 3, 2017 at 2:39 AM, do ber <03do...@gmail.com> wrote:
>>
>>> Hi to all,
>>>
>>> I am trying to create my own GNURadio block(OOT). I will use an external
>>> function generated by MATLAB Coder. MATLAB Coder gives the necessary .cpp
>>> and .h files. In the main module .cc file, which gr_modtool automatically
>>> creates I am including all the header files created by MATLAB Coder. Then
>>> under the work function of module I am just using my main function
>>> generated from MATLAB.
>>>
>>> Input/output declarations are ok, so there is no error during make,
>>> cmake, make install processes. When I open the GNURadio I see my block. Bu
>>> there are some problems:
>>>
>>> When I comment my external function (i.e. when I did not use my external
>>> function) block works(do  nothing but works) and there is information in
>>> "Documentation tab" as all the normal blocks have.
>>> But when I uncomment my external function (i.e. when I used my external
>>> function under work function) I get the following error in GNURadio and
>>> there is no information on "Documentation page", there is only a blank page.
>>>
>>> self.TUTORIAL_myblock_0 = TUTORIAL.myblock(6)
>>> AttributeError:'module' object has no attribute 'myblock'
>>>
>>> Here, 6 is the antenna number in my project. It is the only argument
>>> that I enter into my block.
>>>
>>> So, I searched the literature but* I could not find any project using
>>> functions from external file.* For example, there is an example
>>> "My_QPSK_Demodulator" which is using get_minimum_distance function but it
>>> is a small function and is also defined inside the main module code.
>>>
>>> ** In short, I have myblock.cc and myblock.h files. Also, I have
>>> function .cpp and .h files. I want to use that function inside myblock.cc
>>>
>>> What are your suggestions? Is there any example using this approach?
>>> That would be awesome.
>>>
>>> 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] OOT Module using external function

[West, Nathan]

You have an external object that you need to link your module to. That cpp
file from matlab gets compiled to an object file somehow-- you haven't
specified how. Then you need to link your block to that object.

On Wed, May 3, 2017 at 2:39 AM, do ber <03do...@gmail.com> wrote:

> Hi to all,
>
> I am trying to create my own GNURadio block(OOT). I will use an external
> function generated by MATLAB Coder. MATLAB Coder gives the necessary .cpp
> and .h files. In the main module .cc file, which gr_modtool automatically
> creates I am including all the header files created by MATLAB Coder. Then
> under the work function of module I am just using my main function
> generated from MATLAB.
>
> Input/output declarations are ok, so there is no error during make, cmake,
> make install processes. When I open the GNURadio I see my block. Bu there
> are some problems:
>
> When I comment my external function (i.e. when I did not use my external
> function) block works(do  nothing but works) and there is information in
> "Documentation tab" as all the normal blocks have.
> But when I uncomment my external function (i.e. when I used my external
> function under work function) I get the following error in GNURadio and
> there is no information on "Documentation page", there is only a blank page.
>
> self.TUTORIAL_myblock_0 = TUTORIAL.myblock(6)
> AttributeError:'module' object has no attribute 'myblock'
>
> Here, 6 is the antenna number in my project. It is the only argument that
> I enter into my block.
>
> So, I searched the literature but* I could not find any project using
> functions from external file.* For example, there is an example
> "My_QPSK_Demodulator" which is using get_minimum_distance function but it
> is a small function and is also defined inside the main module code.
>
> ** In short, I have myblock.cc and myblock.h files. Also, I have function
> .cpp and .h files. I want to use that function inside myblock.cc
>
> What are your suggestions? Is there any example using this approach? That
> would be awesome.
>
> 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

Re: [Discuss-gnuradio] What value is in in[noutput_items+1]?

[West, Nathan]

That block calls set_history(2), so in[0] is actually the last sample in
'in' from the previous call to work.

On Mon, May 1, 2017 at 2:09 PM, Ghost Op  wrote:

> I was looking back over the Quadrature Demod code and I happened to
> notice something unusual.  The call to the Volk multiply conjugate
> routine appears to use in[noutput_items+1] on the last calculation.
>
> Here's the call:
> volk_32fc_x2_multiply_conjugate_32fc([0], [1], [0],
> noutput_items);
>
> It obviously works correctly, and the buffer's bigger than
> noutput_items so it doesn't seem to cause a memory access issue.
>
> So my question is: when volk uses the memory at in[noutput_items+1]
> what value is it using?  Is it using a zeroed byte, something from a
> history buffer, or whatever happened to be there?
>
> Would anyone have any insight?
>
> Thanks!
>
> ___
> 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] Error building gr-burst in Ubuntu 16.04 and Volk 1.2.1

[West, Nathan]

This was fixed a while ago. Use VOLK version 1.2.3 or 1.3.

On Fri, Apr 28, 2017 at 8:34 AM, katutxakurra  wrote:

> Hi,
> I'm trying to compile gr-burst and I'm getting an error. I've opened an
> issue in Github but I'm hoping to get a wider audience here.
> https://github.com/gr-vt/gr-burst
>
> I'm using Ubuntu 16.04 with GNURadio 3.7.9, Volk 1.2.1, SWIG 3.0.8 and
> libgsl2 2.1.
> I have installed python-bitarray and build/install gr-mapper.
> In gr-burst, I made
> cmake CMakeLists.txt
> There are some warnings about policies and not finding gsl-config.
> user@pc ~/s/g/gr-burst> make
> [ 4%] Building CXX object lib/CMakeFiles/gnuradio-burst.
> dir/interp_cpdu_impl.cc.o
> [ 8%] Building CXX object lib/CMakeFiles/gnuradio-burst.
> dir/correlator_filter_impl.cc.o
> [ 12%] Building CXX object lib/CMakeFiles/gnuradio-burst.
> dir/length_detect_c_impl.cc.o
> /home/usr/src/gnuradio/gr-burst/lib/length_detect_c_impl.cc: In member
> function ‘void gr::burst::length_detect_c_impl::handler(pmt::pmt_t)’:
> /home/user/src/gnuradio/gr-burst/lib/length_detect_c_impl.cc:105:67:
> error: cannot convert ‘uint16_t* {aka short unsigned int*}’ to ‘unsigned
> int*’ in argument passing
> volk_32f_index_max_16u(_idx, [0], magavg.size());
> ^
> lib/CMakeFiles/gnuradio-burst.dir/build.make:110: recipe for target
> 'lib/CMakeFiles/gnuradio-burst.dir/length_detect_c_impl.cc.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-burst.dir/length_detect_c_impl.cc.o]
> Error 1
> CMakeFiles/Makefile2:137: recipe for target 
> 'lib/CMakeFiles/gnuradio-burst.dir/all'
> failed
> make[1]: *** [lib/CMakeFiles/gnuradio-burst.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
> It looks like the error is with Volk and similar to the one described here
> git-artes/gr-isdbt#18 
>
> Does anyone know how could I fix or work around this problem?
>
>
> ___
> 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] pybombs install with a space in directory name

[West, Nathan]

Where do you actually get stuck? Try Research\ Projects

On Tue, Apr 25, 2017 at 12:20 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> I am trying to do an install of gnuradio into a directory on my company's
> share that I don't have the ability to change.  I thought it was working
> until it hung for a while.  After looking at it a bit, I have a feeling
> that the issue is that there is a folder called "Research Projects" in my
> directory structure.  I am thinking that pybombs is having an issue with
> the space (which I try to never use in Linux myself).  Is there a way to
> work around that issue? (I tried putting the folder name in double quotes,
> but that didn't helps any).
>
> ___
> 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] Speed test went wrong.

[West, Nathan]

I'm not familiar with that exact flowgraph, but nothing will "break down"
in a CPU only flowgraph. Drag the ctrl port perf monitor block on to the
flowgraph and look for the avg throughput counter for a block you care
about. It'll give you items/sec. PS - the throttle block only gives you an
approximate amount of throughput. The actual rate has nothing to do with
whether the flowgraph works/breaks.

On Tue, Apr 25, 2017 at 6:18 AM, Booth  wrote:

> Dear all,
>  I wondered what would be the maximum sample rate that my PC can handle for
> a basic psk mod-demod. I have used the “prbs_test.grc” from gr-mapper as it
> contains all the necessary blocks. I changed the sample rate for the
> throttle to 32k, 320k,10M, 100M even 10G but the system did not break down.
> I repeated the experiment using different examples but the result was the
> same.
> What went wrong and do you know any appropriate projects for speed
> measurements.
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.
> com/Speed-test-went-wrong-tp63632.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] anyone used ZeroMQ together with own server part written in c# or vb?

[West, Nathan]

Not .net, but getting samples from gr-zeromq blocks isn't hard. Just get
the matching socket type, then you'll have to deserialize the PMT wrapper,
which mostly means you need PMTs swigged to your language. Good luck with
that part...

On Mon, Apr 24, 2017 at 8:22 AM,  wrote:

> Hi Group,
>
> Did anyone used ZeroMQ .net libraries together with gnuradio before?
>
> I'm looking to get a quick-start.
>
> thanks
>
>
> ___
> 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] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

[West, Nathan]

As Seth pointed out such samples is a great model for this proposal is a
good time to make that same functionality work with in-tree blocks. The QT
sinks mostly accept PDUs already. What's missing is a file source that can
output PDUs. Since no one is really using sigmf yet (I think?) it's hard to
tell if a capture segment makes sense as a PDU since it could be some
unbounded number of samples. Having a file source with fseek-like
functionality controlled by async message port makes a lot of sense though.
Even better if there could be some introspection to fields in the sigmf
file.

I'm currently moving some more in-tree blocks to accept/output PDUs and a
file source that gives such samples functions is on the list. Would be
great if that comes in through a sigmf GSOC project.

On Fri, Mar 24, 2017 at 12:17 PM, Bastian Bloessl  wrote:

> Hi Ben,
>
> On 03/24/2017 05:01 PM, Ben Hilburn wrote:
> >
> > - I wonder what would be the workflow when creating a SigMF
> recording.
> > An issue might be that you cannot immediately write the SigMF meta
> file
> > during recording. (For example, the hash has to be calculated after
> the
> > recording. Or the annotations have to be written after the capture
> > segments.). Did you plan to create the meta data in memory and write
> the
> > file when the flow graph shuts down (which might cause data loss when
> > you experience a segfault) or do you write meta data to disk in an
> > intermediate format that you have to post-process manually to create
> the
> > final SigMF files.
> >
> >
> > So the SigMF spec is designed specifically to enable writing the
> > metadata and dataset files in a streaming manner.
>
> Can annotations and capture segments be interleaved or how is it
> possible to write the metadata in a streaming manner?
>
> Best,
> Bastian
>
> ___
> 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] Newbie trying to follow OOT module tutorial

[West, Nathan]

Keep reading the tutorial and read the errors. The code that comes out of
gr_modtool isn't really valid c++ yet, but it's close.

"""
/home/pi/gr-howto/lib/square_ff_impl.cc:43:38: error: expected
primary-expression before ‘<’ token
   gr::io_signature::make(<+MIN_IN+>, <+MAX_IN+>,
sizeof(<+ITYPE+>)),
  ^
/home/pi/gr-howto/lib/square_ff_impl.cc:43:40: error: ‘MIN_IN’ was not
declared in this scope
   gr::io_signature::make(<+MIN_IN+>, <+MAX_IN+>,
sizeof(<+ITYPE+>)),
^
/home/pi/gr-howto/lib/square_ff_impl.cc:43:47: error: expected
primary-expression before ‘>’ token
   gr::io_signature::make(<+MIN_IN+>, <+MAX_IN+>,
sizeof(<+ITYPE+>)),
   ^
/home/pi/gr-howto/lib/square_ff_impl.cc:43:48: error: expected
primary-expression before ‘,’ token
   gr::io_signature::make(<+MIN_IN+>, <+MAX_IN+>,
sizeof(<+ITYPE+>)),
"""

That's telling you that the code isn't valid C++. It's filler from a
template with hints as to what goes there.I also suggest not working off of
a raspberry pi immediately. You'll be more comfortable and  iterate faster
on a laptop or desktop.

On Sun, Mar 5, 2017 at 11:38 AM, Honcho41  wrote:

> Hi, I'm a complete novice to GNURadio but I'm trying to follow the gnu
> tutorial for creating a OOT block.  When I get to the CMake part I keep
> getting these error codes.  I'm sure I'm just missing a dependancy or
> something simple but I'm also pretty new to RPi too.  I'm trying to create
> a
> project for a university degree and I'm getting a bit stumped.  Any help is
> appreciated.
>
> pi@raspberrypi:~/gr-howto/build $ cmake
> -DCMAKE_INSTALL_PREFIX=/usr/share/gnuradio ../
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.55.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.8")
> Checking for GNU Radio Module: RUNTIME
>  * INCLUDES=/usr/include
>  *
> LIBS=/usr/lib/arm-linux-gnueabihf/libgnuradio-runtime.
> so;/usr/lib/arm-linux-gnueabihf/libgnuradio-pmt.so
> GNURADIO_RUNTIME_FOUND = TRUE
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>   Run "cmake --help-policy CMP0026" for policy details.  Use the
> cmake_policy
>   command to set the policy and suppress this warning.
>
>   The LOCATION property should not be read from target "test-howto".  Use
> the
>   target name directly with add_custom_command, or use the generator
>   expression $, as appropriate.
>
> Call Stack (most recent call first):
>   lib/CMakeLists.txt:79 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>   Run "cmake --help-policy CMP0026" for policy details.  Use the
> cmake_policy
>   command to set the policy and suppress this warning.
>
>   The LOCATION property should not be read from target "gnuradio-howto".
> Use
>   the target name directly with add_custom_command, or use the generator
>   expression $, as appropriate.
>
> Call Stack (most recent call first):
>   python/CMakeLists.txt:44 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0045 is not set: Error on non-existent target in
>   get_target_property.  Run "cmake --help-policy CMP0045" for policy
> details.
>   Use the cmake_policy command to set the policy and suppress this warning.
>
>   get_target_property() called with non-existent target "/usr/bin/python2".
> Call Stack (most recent call first):
>   python/CMakeLists.txt:44 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0045 is not set: Error on non-existent target in
>   get_target_property.  Run "cmake --help-policy CMP0045" for policy
> details.
>   Use the cmake_policy command to set the policy and suppress this warning.
>
>   get_target_property() called with non-existent target
>   "/home/pi/gr-howto/python/qa_square_ff.py".
> Call Stack (most recent call first):
>   python/CMakeLists.txt:44 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/pi/gr-howto/build
> pi@raspberrypi:~/gr-howto/build $ make
> [  6%] Building CXX object
> lib/CMakeFiles/gnuradio-howto.dir/square_ff_impl.cc.o
> 

Re: [Discuss-gnuradio] PMT: vector of vectors of ints

[West, Nathan]

AFAIK that's only used for coloring and sanity checking sizes before
running a flowgraph. You should be able to use your matrix datatype with a
vlen of  your total matrix size.

float
N*M

On Wed, Mar 1, 2017 at 4:04 PM, devin kelly  wrote:

> Is there any way to create a vector of vectors of ints with the PMT
> library?
>
> I'm trying to make a C++ GR block that takes in an NxM matrix.  For GRC
> all the types are listed at the link below, none really fit my model.
>
> https://github.com/gnuradio/gnuradio/blob/d4bb541ec1ec93446ecfa53948a1a6
> f995fffb64/grc/core/Param.py#L303
>
> What are my options for passing a matrix into the block?
>
> Thanks,
> Devin
>
> ___
> 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] Upcoming GR tutorial and meetup (Dyspan in Baltimore, MD)

[West, Nathan]

Hi all,

Once again, I expect there will be a lot of GNU Radio use at DySPAN next
week in Baltimore, MD.
Let me know (you can reply to just me) if you're interested in a meet up
with other GNU Radio minded people after a conference day. I'm currently
thinking Tuesday night.

Also, be sure to check out the GNU Radio Tutorial on Monday afternoon. The
content is all brand new and covers using GNU Radio for some spectrum
sensing and machine learning topics.

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

Re: [Discuss-gnuradio] Cross compile for ARM with GCC 4.9

[West, Nathan]

This is the dual ABI problem. See
https://gcc.gnu.org/onlinedocs/libstdc%2B%2B/manual/using_dual_abi.html

It was first reported to me June of last year (
https://github.com/gnuradio/volk/issues/92). I tried to play around with
the macro they define, but I could never get anything working (I think
boost et al would need to be compiled with the macro to use the old ABI).
For you I think you might be in luck... just compile GNU Radio with
that _GLIBCXX_USE_CXX11_ABI=0.
The downside is that you might need to recompile *everything* that touches
a string, list, and vector with that macro defined.

I've found the best solution on a desktop OS is to install gcc5 and use it
to build everything. If you really need gcc4 (for example, I keep it around
for CUDA) then you should use Debian's alternatives system:

sudo update-alternatives --config gcc
sudo update-alternatives --config g++
sudo update-alternatives --config cc
sudo update-alternatives --config c++

And just switch back and forth between gcc4 and gcc5 depending on what
you're doing that hour. It's annoying, but c'est la vie.

On Sat, Feb 25, 2017 at 8:48 PM, Cinaed Simson 
wrote:

> On 02/25/2017 07:56 AM, Bradley Conn (RIT Student) wrote:
> > Hello,
> >
> > I am trying to add Gnu Radio as a static library to a Xilinx SDSoC
> > project. SDSoC uses a special compiler and linker which is based off of
> > gcc 4.9. The issue is  when it goes to link there are a bunch of errors
> > like this
> > /
> > /
> > /undefined reference to `std::__cxx11:: /.../
> > /
> > /
> > /
> > because when I cross compiled GnuRadio it used gcc 5.2 which includes
> > the __cxx11 namespace to be more compatible with the c++ 11 standard. I
> > was wondering if there was a way to compile the library (and its
> > dependencies) with gcc 4.9. Or possibly some other workaround anyone
> > knew about?
>
> Possible work around:
>
> 1) build the gcc 4.9 cross compiler from source on your machine - see
>
>http://wiki.osdev.org/Building_GCC
>
> 2) use a VM and install Debian Jessie 8 which uses gcc-4.9. I presume
> you're using Ubuntu - which is a fork of Debian - and very similar to
> Ubuntu.
>
> >
> > When I compiled I used the openembedded environments provided here.
> > http://gnuradio.org/data/sdk/
>
> When I went to this URL it indicated there were no matching records found.
>
>
> >
> > Thank you!
> >
> >
> >
> > ___
> > 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] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

Typo in there count can never be less than 0.

The other thing that I think makes sense is that we might need some history
to scroll back to, but I don't think it's necessarily bounded how much
history... Are you using an upstream block that provides time_est tags?
Also, what parameters are you providing to the clock sync? number of
filters/filter size is the most interesting parameter here, but others
might be useful too.

Nathan

On Wed, Dec 7, 2016 at 12:00 PM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> Some sanity appears!
>
> From what I can tell, count is keeping track of how many input samples
> have been processed, which can never be 0. My proposed fix would be to
> clamp count to 0 somewhere after line 462, but it would be nice for someone
> to confirm this makes sense.
>
> Nathan
>
> On Wed, Dec 7, 2016 at 10:18 AM, devin kelly <dwwke...@gmail.com> wrote:
>
>> I rebuilt GR with CMAKE_BUILD_TYPE=Debug.  The al and ar vairables got
>> optimized out, what's the compiler option to prevent that?
>>
>> I think I've found part of the problem:
>>
>> Looking here (on frame 2 in gdb):
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/
>> lib/pfb_clock_sync_ccf_impl.cc#L465
>>
>> This is the line where filter is called (which is where the segfault
>> occurs):
>>
>> d_filters[d_filtnum]->filter([count+d_out_idx])
>>
>> From GDB I can see
>>
>> d_filtnum = 0
>> count = -67108696
>> d_out_idx = 0
>>
>> (gdb) bt
>> #0  0x7fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic
>> (result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at
>> /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_
>> 32fc_32f_dot_prod_32fc.h:83
>> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter
>> _ccf::filter(std::complex const*) (this=0x53af290,
>> input=input@entry=0x7fed94b925a0) at /local_disk/spectrum_challenge
>> _src/gnuradio/gr-filter/lib/fir_filter.cc:232
>> #2  0x7fedbe22e041 in 
>> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
>> std::vector<int, std::allocator >&, std::vector> std::allocator >&, std::vector<void*, std::allocator<void*>
>> >&) (this=
>> 0x53a1800, noutput_items=256, ninput_items=..., input_items=...,
>> output_items=std::vector of length 1, capacity 1 = {...})
>> at /local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/
>> pfb_clock_sync_ccf_impl.cc:465
>> #3  0x7fedd1bbdd17 in gr::block_executor::run_one_iteration()
>> (this=this@entry=0x7fedafffedb0)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/block_executor.cc:451
>> #4  0x7fedd1bfc6aa in gr::tpb_thread_body::tpb_threa
>> d_body(boost::shared_ptr, int) (this=0x7fedafffedb0,
>> block=..., max_noutput_items=)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/tpb_thread_body.cc:122
>> #5  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0<gr::thread::thread_body_wrapper,
>> void>::invoke(boost::detail::function::function_buffer&)
>> (this=0x53ddc90, this=)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/scheduler_tpb.cc:44
>> #6  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0<gr::thread::thread_body_wrapper,
>> void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/include/gnuradio/thread/thread_body_wrapper.h:51
>> #7  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0<gr::thread::thread_body_wrapper,
>> void>::invoke(boost::detail::function::function_buffer&)
>> (function_obj_ptr=...)
>> at /usr/include/boost/function/function_template.hpp:153
>> #8  0x7fedd1ba5050 in boost::detail::thread_data<boost::function0
>> >::run() (this=)
>> at /usr/include/boost/function/function_template.hpp:767
>> #9  0x7fedd1ba5050 in boost::detail::thread_data<boost::function0
>> >::run() (this=)
>> at /usr/include/boost/thread/detail/thread.hpp:117
>> #10 0x7fedd06a527a in thread_proxy () at
>> /lib64/libboost_thread-mt.so.1.53.0
>> #11 0x7fedec395dc5 in start_thread () at /lib64/libpthread.so.0
>> #12 0x7fedeb9bb73d in clone () at /lib64/libc.so.6
>> (gdb) f 1
>> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter
>> (this=0x53af290, input=input@entry=0x7fed94b925a0)
>> a

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

ctrum_challenge_src/volk/kernels/volk/volk_
>> 32fc_32f_dot_prod_32fc.h:83
>> 83  *realpt += ((*aPtr++) * (*bPtr));
>> (gdb) info locals
>> res = {0, 0}
>> realpt = 0x7f114680f570
>> imagpt = 0x7f114680f574
>> aPtr = 0x7f1126cac684
>> bPtr = 0x56ea860
>> number = 0
>> (gdb) print realpt
>> $1 = (float *) 0x7f114680f570
>> (gdb) print *realpt
>> $2 = 0
>> (gdb) print aPtr
>> $3 = (const float *) 0x7f1126cac684
>> (gdb) print *aPtr
>> Cannot access memory at address 0x7f1126cac684
>> (gdb) print bPtr
>> $4 = (const float *) 0x56ea860
>> (gdb) print *bPtr
>> $5 = 0.000685208186
>>
>>
>> The fault happens here:
>>
>> https://github.com/gnuradio/volk/blob/master/kernels/volk/vo
>> lk_32fc_32f_dot_prod_32fc.h#L83
>>
>>
>> Since aPtr is just
>>
>> const float* aPtr = (float*)input;
>>
>> Maybe the issue is with pfb_clock_sync_ccf_impl?  I'm not sure.
>>
>> Devin
>>
>> On Tue, Dec 6, 2016 at 1:06 PM, devin kelly <dwwke...@gmail.com> wrote:
>>
>>> It's a bit of both.  The segfault usually happens on packet between
>>> packets 2 and 3 (I send one packet per second on my transmitter) but
>>> sometimes will happen a few packets later.  It also always segfaults, I've
>>> gotten it to segfault about 20 times or so.
>>>
>>> On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan <
>>> n...@ostatemail.okstate.edu> wrote:
>>>
>>>> Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but
>>>> that's a separate topic.
>>>>
>>>> You can configure VOLK to not use this protokernel and there's some
>>>> documentation on how to do it here: http://gnuradio.org/doc/
>>>> doxygen/volk_guide.html#volk_tuning
>>>>
>>>> This is fairly concerning though... are you able to consistently
>>>> trigger a segfault or is it a seemingly random event that you can't 
>>>> trigger?
>>>>
>>>> On Tue, Dec 6, 2016 at 11:48 AM, devin kelly <dwwke...@gmail.com>
>>>> wrote:
>>>>
>>>>> OK, I tried a brand new GR/Volk install and still had the same
>>>>> problem.  So no problem with re-linking Volk to GR.  Could this be an 
>>>>> issue
>>>>> with Volk on GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old,
>>>>> though the newest for Red Hat 7.  Is there any way to reconfigure volk to
>>>>> not use volk_32fc_32f_dot_prod_32fc_a_avx?
>>>>>
>>>>> Here's volk-config-info:
>>>>>
>>>>> $ volk-config-info --all --prefix --cc --cflags --avail-machines
>>>>> --machine --alignment --malloc
>>>>> /local_disk/spectrum_challenge
>>>>> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>>> This is free software see the source for copying conditions.  There is
>>>>> NO
>>>>> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>>>> PURPOSE.
>>>>> /usr/bin/cc:::  -Wall
>>>>> /usr/bin/c++:::  -Wall
>>>>> generic_orc:::GNU:::-g  -Wall
>>>>> sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
>>>>> sse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>>>>> ssse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>>>>> -mssse3
>>>>> sse4_a_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>>>>> -msse4a -mpopcnt
>>>>> sse4_1_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>>>>> -mssse3 -msse4.1
>>>>> sse4_2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>>>>> -mssse3 -msse4.1 -msse4.2 -mpopcnt
>>>>> avx_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>>>>> -mssse3 -msse4.1 -msse4.2 -mpopcnt -mavx
>>>>> avx2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>>>>> -mssse3 -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
>>>>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc
>>>>> ;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_6
>>>>> 4_mmx_orc;avx2_64_mmx_orc;
>>>>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc
>>>>> ;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
>>>>> 

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

On Tue, Dec 6, 2016 at 1:24 PM, devin kelly  wrote:

> I changed my volk_config like so
>
> volk_32fc_32f_dot_prod_32fc generic generic
>
> And I still get a segfault:
>
> gdb python core.8035
>
>  .
>
> Program terminated with signal 11, Segmentation fault.
> #0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860,
> num_points=45) at /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> 83  *realpt += ((*aPtr++) * (*bPtr));
> Missing separate debuginfos, use: debuginfo-install
> python-2.7.5-48.el7.x86_64
> (gdb) bt
> #0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> #1  0x7f11474f in 
> gr::filter::kernel::fir_filter_ccf::filter(std::complex
> const*) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> filter-3.7.10.1.so.0.0.0
> #2  0x7f1150356b41 in 
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector
> >&) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> digital-3.7.10.1.so.0.0.0
> #3  0x7f1163d14d80 in gr::block_executor::run_one_iteration() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #4  0x7f1163d56090 in gr::tpb_thread_body::tpb_
> thread_body(boost::shared_ptr, int) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #5  0x7f1163d49791 in boost::detail::function::void_
> function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #6  0x7f1163cfae60 in boost::detail::thread_data >::run() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #7  0x7f11627f927a in thread_proxy () at /lib64/libboost_thread-mt.so.
> 1.53.0
> #8  0x7f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
> #9  0x7f117dafe73d in clone () at /lib64/libc.so.6
> (gdb) f 0
> #0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> 83  *realpt += ((*aPtr++) * (*bPtr));
> (gdb) info locals
> res = {0, 0}
> realpt = 0x7f114680f570
> imagpt = 0x7f114680f574
> aPtr = 0x7f1126cac684
> bPtr = 0x56ea860
> number = 0
> (gdb) print realpt
> $1 = (float *) 0x7f114680f570
> (gdb) print *realpt
> $2 = 0
> (gdb) print aPtr
> $3 = (const float *) 0x7f1126cac684
> (gdb) print *aPtr
> Cannot access memory at address 0x7f1126cac684
> (gdb) print bPtr
> $4 = (const float *) 0x56ea860
> (gdb) print *bPtr
> $5 = 0.000685208186
>

If I'm doing the arithmetic correctly aPtr is pointing to memory that the
caller claimed was valid and we aren't doing anything so funny here that I
would expect a segfault. It does appear that this might be a bug you are
triggering, but the question is why.

What are your parameters for the clock sync?
Are you able to get a small snapshot of data that will consistently cause
this? For example, file source -> pfb clock sync -> null sink which will
consistently fail.
Does this occur only with the one modem/data pattern+channel you're working
on?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but
that's a separate topic.

You can configure VOLK to not use this protokernel and there's some
documentation on how to do it here:
http://gnuradio.org/doc/doxygen/volk_guide.html#volk_tuning

This is fairly concerning though... are you able to consistently trigger a
segfault or is it a seemingly random event that you can't trigger?

On Tue, Dec 6, 2016 at 11:48 AM, devin kelly  wrote:

> OK, I tried a brand new GR/Volk install and still had the same problem.
> So no problem with re-linking Volk to GR.  Could this be an issue with Volk
> on GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the
> newest for Red Hat 7.  Is there any way to reconfigure volk to not use
> volk_32fc_32f_dot_prod_32fc_a_avx?
>
> Here's volk-config-info:
>
> $ volk-config-info --all --prefix --cc --cflags --avail-machines --machine
> --alignment --malloc
> /local_disk/spectrum_challenge
> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software see the source for copying conditions.  There is NO
> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> /usr/bin/cc:::  -Wall
> /usr/bin/c++:::  -Wall
> generic_orc:::GNU:::-g  -Wall
> sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
> sse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
> ssse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> sse4_a_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -msse4a
> -mpopcnt
> sse4_1_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1
> sse4_2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1 -msse4.2 -mpopcnt
> avx_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1 -msse4.2 -mpopcnt -mavx
> avx2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
> -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_
> orc;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;
> avx_64_mmx_orc;avx2_64_mmx_orc;
> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_
> orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
> avx2_64_mmx_orc
> Alignment in bytes: 32
> Used malloc implementation: posix_memalign
>
>
> Thanks again for any help,
> Devin
>
>
> On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller 
> wrote:
>
>> Oh, that's pretty interesting! Well, no misconfiguration should segfault,
>> so I'm a bit stumped at the moment.
>>
>> On 12/01/2016 06:14 PM, devin kelly wrote:
>>
>> Marcus,
>>
>> Thanks for taking the time.  It is possible I re-installed a new version
>> of VOLK.  I'll try a fresh build and see what that gets me.
>>
>> I also should have mentioned that the filter works OK for a while then
>> segfaults.  A couple of packets always pass through the clock sync block
>> I'm using before I get the segfault.  Finally, the segfault occurs in the
>> polyphase clock sync block, do you think I could have mis-configured the
>> block in some way that will get me this error?  I think the PF clock sync
>> block is pretty popular so if there's a bug in that block that's causing
>> this I'd be surprised.
>>
>> Devin
>>
>> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller 
>> wrote:
>>
>>> Hi Devin,
>>>
>>> I don't think it's a kernel problem – all your calculations happen in
>>> userland, and the kernel has not much to say with respect to the
>>> instructions used.
>>>
>>> The most common reason for this kind of misbehaviour is in fact a
>>> problem with how the application (in this case, your GNU Radio
>>> application's block) calls into the library function (in this case the VOLK
>>> dot product).
>>>
>>> Is it possible that for some reason, GNU Radio used a previous version
>>> of VOLK when you linked it, and then the new version of VOLK was installed?
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 12/01/2016 05:23 PM, devin kelly wrote:
>>>
>>> Hello,
>>>
>>> I'm having a problem with the above VOLK function segfaulting.  I don't
>>> think I'm passing any incorrect values to VOLK.  My problem could be that
>>> I'm on RHEL7 with (obviously) an older kernel:
>>>
>>> $ uname -a
>>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
>>> EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> I'm on VOLK 1.3 and GR 3.7.10.1.
>>>
>>> it segfaults here:
>>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol
>>> k_32fc_32f_dot_prod_32fc.h#L119
>>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes
>>> this pointer to VOLK so maybe it's a GR problem?
>>>
>>> I've copied the output of a GDB session and my CPU info below.
>>>
>>> Thanks for any help,
>>> Devin
>>>
>>>
>>>
>>> Program terminated with signal 11, Segmentation fault.
>>> #0  0x7fea7b1bd8b7 in 

Re: [Discuss-gnuradio] GNU Radio on the cloud

[West, Nathan]

There are a few. Fraida Fund talked about using WItest at GRcon this year
and also mentioned a couple of other related testbeds that might be
accessible (Orbit, Nitos)

Here's the talk:
https://drive.google.com/file/d/0B6ccrJyAZaq3OFpPRTVjZzVpSUE/view
and video:https://www.youtube.com/watch?v=feWPAnkM08Q

On Tue, Nov 15, 2016 at 12:31 PM, Yahia Tachwali 
wrote:

> Hello everyone,
>
> Does anyone know a cloud based gnu radio platform? I have read few years
> before some universities have made such setup and made them accessible to
> public.
>
> Does anyone know one that is still active?
>
> --
> Kind regards,
> Yahia Tachwali
>
> ___
> 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] Flow control with message ports

[West, Nathan]

I'm not sure I understand. There was once a proof of concept flowgraph
called pmt_smasher that would effectively keep publishing messages and the
queue grows without bounds which was generally considered a low-priority
issue (having no back pressure/flow control on message ports).

You're describing different behavior than I understand the message ports to
have. Is the queue that's overflowing some custom queue in your block that
you dump new messages on to? If so just make that queue grow as more
messages come in.

Nathan

On Tue, Nov 8, 2016 at 7:27 PM, Michael Wentz  wrote:

> Hi,
>
> I've made a block in Python that has one message port out and no other
> ports. What the block does is simple: read from a file, parse data into a
> dict, convert to a PMT, and publish as a message. The port is connected to
> a sync_block that is acting on these messages when it deems fit. My desired
> behavior is for the publisher to fill up the queue as fast as possible and
> block if the queue is full (waiting for room to open up). What I've
> observed is that the queue will instead overflow and messages will be
> dropped. Is there any way to have a blocking call to message_port_pub()?
>
> Looking through the code I do see a method in basic_block to get the
> number of messages in the queue, which I could use to decide to publish a
> message or not - but this isn't brought out in the SWIG interface. Is there
> a reason why? If not, I was thinking about re-defining the SWIG interface
> for basic_block in my OOT with additional methods, but was wondering if
> that would create conflicts/weird issues.
>
> Any other ideas for how to do this would be appreciated. I realize I could
> parse the file in my sync_block, but that's my last resort here.
>
> -Michael
>
> ___
> 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] Some Detailed Questions about GNURadio GrRxFM Project On Android

[West, Nathan]

Hi Charlie,

It's been a while since I've touched Java/Android stuff, but those are
ControlPort functions (part of the GNU Radio API). To use them they have to
be wrapped by the JNI which looks like it was done with
https://github.com/trondeau/GrRxFM/blob/master/controlport/src/main/java/gnuradio.thrift#L103
They are RPC service calls that Thrift should build actual code for as part
of your app build process.

My guess from what I remember working with this is that you have to set up
your gradle/whatever the "project" build system is called now correctly so
that your app gui/main thread can see those service definitions.

On Mon, Oct 17, 2016 at 10:10 PM, Charlie Von  wrote:

> Hello every friend,
>
> Could I spare you a few minutes? :) My Teammates and I have learned to
> develop an application using B200mini on Android. We followed Mr.Trondeau
> instructions on http://gnuradio.org/redmine/projects/gnuradio/wiki/Android
> that very helpful for our work. Thank you very much.
> Here are some questions to ask. I would be greatly appreciated if you can
> reply them.
>
> We study the code of GrRxFM project which download from
> https://github.com/trondeau/GrRxFM and find that some lines of codes in
> OnDraw() function in SampleView.java are commented. We guess these codes
> can realize the function that get raw data from flowgraph. However, we
> cannot find the implementation of some key functions. Could you please give
> some explanations or some details about these functions and variables.
>
>
> /
> Extracted from SampleView.java
>
> mGraph.postGetKnob(a);
>
> RunGraph.CPHandlerGet h = mGraph.mControlPortThread.getHandlerGet();
>
> HashMap k = h.getKnobs();
>
> 
>
> Rungraph.CPHandleGet, how to define this class?
> mGraph.mControlPortThread.getHandlerGet() how to realize this member
> function?
> and h.getKnobs()  how to realize this member function?
>
>
> We confused by these questions for some weeks and we would be greatly
> appreciated if you can reply them.
>
>
> Thank you very much!
>
> sincerely Charlie
> 2016 1018 1010
>
>
> ___
> 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] problem with a fresh pybombs build

[West, Nathan]

I once had several mysterious issues with 16.04 and a custom shell-wrapped
sudo installed by some IT guys to the point that I installed "stock" 16.04
and *not* the IT guys' provisioned stuff. After using the stock install
*without* specially provisioned software things worked much better (like
they are supposed to!)

I think it makes sense to try this out on a stock install without mucked up
versions of system utilities. It's possible that these are in fact bugs in
pybombs as a result of corner cases, but without being able to reliably
reproduce the corner cases it's pretty difficult to fix those bugs. In my
case attempting to use pybombs with the specially provisioned software
exposed bugs in the specially provisioned software (which was a good
indicator to avoid using it).

Cheers,
nw

On Wed, Oct 12, 2016 at 10:35 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> > Hi Marcus, The reason I went with sudo was because it was erroring out if
> I didn't:
>
> > $ pip install -I --user pybombs
> > Collecting pybombs
> >   Using cached PyBOMBS-2.2.0.tar.gz
> > Complete output from command python setup.py egg_info:
>
> > /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'entry_points'
>
> >   warnings.warn(msg)
>
> > /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'install_requires'
>
> >   warnings.warn(msg)
> > usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
> >or: -c --help [cmd1 cmd2 ...]
> >or: -c --help-commands
> >or: -c cmd --help
> >
> > error: invalid command 'egg_info'
> >
> > 
>
> > Command "python setup.py egg_info" failed with error code 1 in
> /tmp/pip-build-FJfz9W/pybombs/
>
> I am still stuck at this stage. Assuming I am dead in the water, what is
> the next best (approved) way of installing GnuRadio?  Doing it by hand from
> the github clone?
>
> ___
> 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] Getting the Count of FFTs

[West, Nathan]

Do you really need the count, or do you just need some code to process FFTs
as the block computes them? I suspect a little bit more understanding of
GNU Radio will help you achieve what you want.

Assuming that I have some DSP stuff I want to operate on an FFT output, I
would go about this in one of the following ways:

Option 1) Write my DSP stuff in GNU Radio blocks in my own out of tree
module. This is the GNU Radio way to do things. The GNU Radio scheduler
will call my code to process FFT chunks as they are available.

Option 2) Connect the output of the GNU Radio FFT block to something like a
gr-zeromq block or TCP block and write a receiver for this on my
application. This is better than a file (but can actually *look* like a
file if I use a something like zeromq's ipc:// protocol or a FD block
because an actual file flushes buffers (actually commits the write to disk)
at unknown times, so it may not actually be particularly close to
real-time. Then instead of reopening a file and seeking to the end every
time I can just read from the socket/icp FD to get all of the latest stuff.

There's no way to get a count of FFTs that are written to the file because
the FFT block and the file block are not deterministicly scheduled. You
could use the performance counters to see how many items the file block has
read, but that's a horrible abuse of that counter and still doesn't
guarantee the number actually written to disk because you don't know when
the file buffer is actually being flushed. Rethinking the problem is likely
the best way forward.

I highly recommend option 1 and option 2 as a last resort. Option 2 is
better for when you're no longer doing DSP and passing something like bits
to another process that's great at handling bits.

On Mon, Sep 19, 2016 at 9:07 PM, Hasini Abeywickrama <hva...@gmail.com>
wrote:

> Hi Nathan,
>
> That's not quite what I want. I do not want the file to have a certain
> number of FFTs. I want to have a counter which is dynamically updated as
> the FFTs are written to a file. Ideally I want to know when a new FFT is
> written to the file so I can trigger another function to process it. I need
> this to be done real time and that's why I'm looking for the most efficient
> way.
>
> Regards,
> Hasini
>
> On Tue, Sep 20, 2016 at 10:34 AM, West, Nathan <
> n...@ostatemail.okstate.edu> wrote:
>
>>
>> On Mon, Sep 19, 2016 at 6:57 AM, Hasini Abeywickrama <hva...@gmail.com>
>> wrote:
>>
>>> Hi Marcus,
>>>
>>> That's what I'm currently doing. It's not very efficient as I have to
>>> constantly check the file size. If I can have a counter that is increments
>>> each time an FFT is written to the file by the flow graph I would be able
>>> to trigger an event based on the counter value. That was my concern.
>>>
>>> Regards,
>>> Hasini
>>>
>>> On Sep 19, 2016, at 3:29 PM, Marcus Müller <marcus.muel...@ettus.com>
>>> wrote:
>>>
>>> If you need to do that externally, I'd just watch the file size and
>>> divide it by the item size (4B per floating point number) and by the FFT
>>> length.
>>>
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 09/18/2016 11:21 PM, Hasini Abeywickrama wrote:
>>>
>>> Hi Marcus,
>>>
>>> It's like I need to start reading and processing the file after a
>>> certain number of FFTs are being written to the file. For that I would need
>>> to maintain a counter and I'm trying to figure out how to do it.
>>>
>>> Regards,
>>> Hasini
>>>
>>>
>> You can do this with the head block. It let's N number of items through
>> and then stops the flowgraph. Set N to your certain number and then the
>> file will have N FFTs.
>>
>>
>>
>>>
>>> On Mon, Sep 19, 2016 at 2:58 PM, Marcus Müller <marcus.muel...@ettus.com
>>> > wrote:
>>>
>>>> What would you need that counter for? There's the 1/(FFT length) fixed
>>>> relation between samples processed and numbers of FFTs done, so this is
>>>> pretty much a redundant piece of info, but maybe I'm just missing the use
>>>> case.
>>>>
>>>> Best regards,
>>>>
>>>> Marcus
>>>>
>>>> On 09/18/2016 10:23 PM, Hasini Abeywickrama wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have a GNU Radio flowgraph which uses a USRP to receive a signal,
>>>> converts it to log power FFT and then writes the result to a file, using
>>>> File Sink. I want to have a counter which increments with each FFT written
>&

Re: [Discuss-gnuradio] Getting the Count of FFTs

[West, Nathan]

On Mon, Sep 19, 2016 at 6:57 AM, Hasini Abeywickrama 
wrote:

> Hi Marcus,
>
> That's what I'm currently doing. It's not very efficient as I have to
> constantly check the file size. If I can have a counter that is increments
> each time an FFT is written to the file by the flow graph I would be able
> to trigger an event based on the counter value. That was my concern.
>
> Regards,
> Hasini
>
> On Sep 19, 2016, at 3:29 PM, Marcus Müller 
> wrote:
>
> If you need to do that externally, I'd just watch the file size and divide
> it by the item size (4B per floating point number) and by the FFT length.
>
>
> Best regards,
>
> Marcus
>
> On 09/18/2016 11:21 PM, Hasini Abeywickrama wrote:
>
> Hi Marcus,
>
> It's like I need to start reading and processing the file after a certain
> number of FFTs are being written to the file. For that I would need to
> maintain a counter and I'm trying to figure out how to do it.
>
> Regards,
> Hasini
>
>
You can do this with the head block. It let's N number of items through and
then stops the flowgraph. Set N to your certain number and then the file
will have N FFTs.



>
> On Mon, Sep 19, 2016 at 2:58 PM, Marcus Müller 
> wrote:
>
>> What would you need that counter for? There's the 1/(FFT length) fixed
>> relation between samples processed and numbers of FFTs done, so this is
>> pretty much a redundant piece of info, but maybe I'm just missing the use
>> case.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 09/18/2016 10:23 PM, Hasini Abeywickrama wrote:
>>
>> Hi all,
>>
>> I have a GNU Radio flowgraph which uses a USRP to receive a signal,
>> converts it to log power FFT and then writes the result to a file, using
>> File Sink. I want to have a counter which increments with each FFT written
>> to the file.
>>
>> Is there a way of maintaining and increasing count of the FFTs written to
>> the file, while the flowgraph is still running?
>>
>>
>> ___
>> 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] Getting Time Stamps From an x310 in C++

[West, Nathan]

As of v3.7.10 there is a command port handler for forcing a new time tag.

https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_source_impl.cc#L465

It's not strictly necessary since you can always count time yourself, but
it can be useful for some things.

On Wed, Jul 6, 2016 at 8:58 PM, Martin Braun  wrote:

> USRPs will only output timestamps at the beginning of streaming, or when
> time skips (e.g. after an overrun). You can keep track of time by
> counting samples in between timestamp tags.
>
> See the header_payload_demux block for an example of how to keep track
> of time. Also, check out the gr-uhd manual for an explanation of the
> tags it uses, e.g.
> http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html.
> M
>
> On 07/06/2016 04:27 PM, Robert Kraml wrote:
> > I have a C++ implemented flow-graph that acquires 3 channels at a sample
> > rate of 5 MHz.  There are a couple of decimation stages with the
> > resultant n a number of 250 Hz output channels.  How is the best way to
> > access the associated time stamps.  I wouldn't need every time stamp,
> > just perhaps one every second or so and the rest would be interpolated.
> > Might there be some c++ examples of how this would be best done?
> >
> > -Bob
> >
> >
> > ___
> > 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] Pending feature freeze for GNU Radio Release v3.7.10

[West, Nathan]

Hi all,

I want to give a heads up that we're actively planning the v3.7.10 release
of GNU Radio for a couple of weeks from now. We'll go in to a feature
freeze within a few days. If you have work you want in the release please
wrap it up and submit PRs or at least let us know about it.

Related, the big merge coming in is a new "packet3" branch that's available
from the gnuradio.org git remote as well as the Github mirror. This branch
has a pretty hefty overhaul of packetized modem work from Tom. If you have
vested interests in that please review and test that branch.

That's all for now. Cheers,
Nathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IMSI Catcher Catcher?

[West, Nathan]

Deep in to this thread there has been no relevant discussion of GNU Radio
or even technically interesting DSP/SDR. Based on that I think this is
off-topic for this list and perhaps interested parties should find another
forum for future discussion.

Cheers,
Nathan West

On Tue, Jun 21, 2016 at 4:56 PM, Ronald F. Guilmette 
wrote:

>
> In message <01cb01d1cb9f$bb416a00$31c43e00$@schmid.xxx>,
> "Ralph A. Schmid, dk5ras"  wrote:
>
> >> Thank you!!!
> >>
> >> That's exactly the kind of information I've been looking for.
> >
> >These few words?!
>
> Yes.  I was only seeking information that would allow me to make
> contact with people who have already done this stuff.  Now I have
> that.  (I see no reason for me personally to try to re-invent the
> wheel here, especially given how utterly unqualified I am to do so
> in this case, as well as that fact that I now know of at least
> FOUR groups that seem to have already done the necessary engineering
> to create such things, i.e. (1) Aftenposten... a Norwegian newspaper,
> (2) the group of researchers at  the Vienna-based SBA Research, and
> (3) the guy at Privacy International who appears in the Youtube video,
> and (4) the California guy who is going to be giving a talk on this
> at DEFCON.)
>
> >In fact all you need already exists, software to decode GSM network data
> >already exists; you just need to put the pieces of information together.
>
> I may be wrong, but I think that the same could be said of nuclear weapons.
>
> Nontheless, even if I had the requsite materials I would have no immediate
> plans to personally attempt to construct one in my basement.  It's just
> too complicated for me, I have zero experience in this area, and as Clint
> Eastwood (playing "Dirty Harry") once astutely said "A man's got to know
> his limitations."
>
> Likewise, I personally also have very nearly zero experience with and/or
> knowledge of cellular data communications technology and/or standards.
>
> >Means, look for MCCs/MNCs and ARFCNs, compare if they fit into the
> official
> >band plan, check the LAC and cell IDs and T3212 and other timers and flags
> >and have a look if they follow the official scheme...
>
> No offense intended, but I had to giggle a little bit when I read the
> above,
> just because it exemplifies what I said at the outset of this thread:  I
> personally have zero knowledge of "radio" generally, except for the
> trivial kinds of knowledge that anybody who took and passed a High School
> physics class 40 years ago would have.  Thus, I'm 100% ignorant of
> literally every single one of the acronyms you mentioned.  It's all
> Greek to me!  (I *do* understand the trivial concept of a "cell tower ID",
> but only because it was mentioned in the paper by the Vienna researchers,
> and only because I have a ready analogy to draw on, i.e. the SSID of my
> own local WiFi router.)
>
> >Means, it is not only a matter of building some fancy device and writing
> >some fancy code, you have to take the local network situation into
> account.
> >The technical side is one thing, but intelligence is the main factor.
> There
> >won't be a device to tell for sure that a tower is rogue, there must be
> some
> >heuristics or some human that evaluates the data and knows the local
> >network, knows how it should look like, to determine what may be wrong.
>
> Yes.  Thanks.  I did at least understand this part, based on what I had
> read already regarding the Oslo incidents, and also that Youtube video
> where they tried to detect stingrays at a London protest demonstration.
>
> In short, I understand that even with the best equipment and software,
> all that can be said, at most, is that something in the air looks very
> odd and/or exceptionally fishy.  That's enough for me.  Certainly, if
> I can see that 3G and 4G signals appear to be being locally jammed
> (thus forcing phones in the area to downshift to the far-less-secure 2G),
> and/or if an alleged tower in a metropolitain area is claiming that
> it belongs to a major carrier, but that it only supports 2G, then as I
> understand it, those are fairly definitive signs that something extremely
> fishy is going on.  And also, as I understand it, there are a few other
> telltale indicators that could be looked for as well.
>
> (I was interested also to see that the upcoming DEFCON presentation will
> lay out, not only how to detect such anomalies, but also how to triangulate
> the (exact?) locations from which they emmanate.  Although one might not
> ever be able to assert 100% proof of the existance and operation of a
> stingray within some specific aarea, just based on the signals floating
> through the air, if one could actually triangulate the thing, one might
> be able to take an actual pictures of it, and that, I think, would go
> a long ay towards definitively proving that such a device was in fact
> operating in the area at around the time that the signals in the air
> 

Re: [Discuss-gnuradio] divide_cc_impl.cc error in ::blocks

[West, Nathan]

The issue is the VOLK submodule pointer is out of date. Pybombs update
doesn't currently update the submodule recursively. The issue has been
identified and reported to proper people.

For now go to src/gnuradio/volk and type git pull origin master.

nw

On Tue, Jun 21, 2016 at 2:27 PM, Cinaed Simson 
wrote:

> Check your disk space and make sure you have enough memory. On a VM you
> may not have 2 GB of free memory.
>
> I had 2 GB of total memory and I had to add 1 GB of swap to ensure the
> build completed.
>
> The build failed and it gave a weird error which didn't make any sense.
>
> Blow away the build directory and run it again - monitor the build with
> htop if you're not sure how much memory you have free.
>
> On 06/21/2016 09:05 AM, Gregory W. Ratcliff wrote:
> > Greetings,
> >
> > I did a quick list search for this, but didn't see anything.
> >
> > Today I fired up a 64 bit Ubuntu 15.04 vm; let it does its normal
> > updates, then "sourced" the shell script and ran pybombs update
> >
> > About an hour later after MUCH success the build failed.
> > Anyone notice this recently?
> >
> > [ 12%] Building CXX object
> > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/divide_cc_impl.cc.o
> > /home/gratcliff/gnuradio/src/gnuradio/gr-blocks/lib/divide_cc_impl.cc:
> > In member function ‘virtual int gr::blocks::divide_cc_impl::work(int,
> > gr_vector_const_void_star&, gr_vector_void_star&)’:
> >
> /home/gratcliff/gnuradio/src/gnuradio/gr-blocks/lib/divide_cc_impl.cc:58:105:
> > error: ‘volk_32fc_x2_divide_32fc’ was not declared in this scope
> >  _32fc(optr, numerator, (gr_complex*) input_items[inp], noutput_items *
> > d_vlen);
> >
> >   ^
> > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/build.make:4216: recipe for
> > target
> > 'gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/divide_cc_impl.cc.o' failed
> > make[2]: ***
> > [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/divide_cc_impl.cc.o] Error
> 1
> > CMakeFiles/Makefile2:1957: recipe for target
> > 'gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all' failed
> > make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
> > Makefile:146: recipe for target 'all' failed
> > make: *** [all] Error 2
> > PyBombs.Packager.source - ERROR - Build failed. See output above for
> > error messages.
> > PyBombs.Packager.source - ERROR - Problem occurred while building
> > package gnuradio:
> > Build failed.
> > PyBombs.update - ERROR - Error updating package gnuradio. Aborting.
> >
> >
> > Gregory W. Ratcliff
> >
> >
> >
> >
> >
> >
> >
> > ___
> > 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] divide_cc_impl.cc error in ::blocks

[West, Nathan]

It's not 100% clear how you have everything installed or what you did for
the upgrades, but probably updating your VOLK submodule pointer will work.

On Tue, Jun 21, 2016 at 12:05 PM, Gregory W. Ratcliff  wrote:

> Greetings,
>
> I did a quick list search for this, but didn't see anything.
>
> Today I fired up a 64 bit Ubuntu 15.04 vm; let it does its normal updates,
> then "sourced" the shell script and ran pybombs update
>
> About an hour later after MUCH success the build failed.
> Anyone notice this recently?
>
> [ 12%] Building CXX object
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/divide_cc_impl.cc.o
> /home/gratcliff/gnuradio/src/gnuradio/gr-blocks/lib/divide_cc_impl.cc: In
> member function ‘virtual int gr::blocks::divide_cc_impl::work(int,
> gr_vector_const_void_star&, gr_vector_void_star&)’:
> /home/gratcliff/gnuradio/src/gnuradio/gr-blocks/lib/divide_cc_impl.cc:58:105:
> error: ‘volk_32fc_x2_divide_32fc’ was not declared in this scope
>  _32fc(optr, numerator, (gr_complex*) input_items[inp], noutput_items *
> d_vlen);
>
> ^
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/build.make:4216: recipe for
> target 'gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/divide_cc_impl.cc.o'
> failed
> make[2]: ***
> [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/divide_cc_impl.cc.o] Error 1
> CMakeFiles/Makefile2:1957: recipe for target
> 'gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all' failed
> make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
> Makefile:146: recipe for target 'all' failed
> make: *** [all] Error 2
> PyBombs.Packager.source - ERROR - Build failed. See output above for error
> messages.
> PyBombs.Packager.source - ERROR - Problem occurred while building package
> gnuradio:
> Build failed.
> PyBombs.update - ERROR - Error updating package gnuradio. Aborting.
>
>
> Gregory W. Ratcliff
>
>
>
>
>
>
> ___
> 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] Alignment bug fix

[West, Nathan]

On Fri, May 27, 2016 at 12:59 PM, Philip Balister 
wrote:

> On 05/27/2016 09:43 AM, Robert McGwier wrote:
> > Recently a kernel alignment bug was fixed (ugly) and this repaired the
> > polyphase synthesis engine in the main code.
>
> A fix in the Linux kernel? Or somewhere else. A reference to the commit
> would be handy for people running across this issue.
>
> Philip
>
>
> >
> > My PhD student, Bill Clark (Amateur Radio call KK4EWQ) at Virginia Tech,
> > has suffered with and pointed out this problem with the synthesizer for
> > some time.
> >
> > He wrote an out of tree module to correct the difficulty he was
> > experiencing but we now believe this work is no longer needed.
> >
> > Thanks for fixing the bug and thanks to Bill for his hard work at VT.
> >
> > Bob McGwier
> > Professor Electrical and Computer Engineering, VT
> > N4HY
> >
> >
>
>
It sounds like Bob might be referring to this commit:
https://github.com/gnuradio/gnuradio/commit/6baa4c86c5e1f5889e44a4e8e38750b0de3bf061.
It
existed for a longer time than necessary because it only impacts people
with AVX using binary builds of libfftw that aren't built with AVX. Someone
with the issue pointed it out and a small group of us pretty quickly
recognized what was happening. From proper bug report to a merged fix was
pretty quick.

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

Re: [Discuss-gnuradio] Why add d_nbits two times at ofdm_mapper_bcv ?

[West, Nathan]

On Thu, May 26, 2016 at 12:06 PM, Marcus Müller 
wrote:

> That's pretty much what I wanted to stress:
>
> Dear SangHyuk,
>
> as you've been told you multiple times:
> > Martin, 25. March 2016:
> > you're not using the more recent OFDM blocks, so you won't get a lot of
> > support here -- I recommend moving to the tx_ofdm and rx_ofdm stuff
> > instead.
> > I, 10. April 2016:
> > Also, we have already discussed with you multiple times that
> > benchmark_tx is not what you should be using, and that you should have
> > a look at the ofdm_{rx,tx,loopback}.grc examples.
> > I, 7. April 2016
> > As said on numerous occassions, go ahead and try the rx_ofdm.grc and
> > tx_ofdm.grc examples from gr-digital. They are much more modern.
>
> So really, migrate to the examples Martin, I and others have pointed out
> multiple times. You *will not* get competent help with the things you use.
>
> Best regards,
> Marcus
>
>
> On 26.05.2016 17:52, Martin Braun wrote:
> > Also, that block is going away soon.
> >
> > I recommend looking at the carrier allocator block instead.
> >
> > M
> >
> > On 05/25/2016 10:20 PM, SangHyuk Kim wrote:
> >> Dear all,
> >>
> >> Sorry, my source code was wrong.
> >>
> >> There is only one /d_bit_offset += d_nbits;
> >>
> >> /
> >> /Thanks .
> >> /
> >>
> >> 2016-05-26 10:38 GMT+09:00 SangHyuk Kim  >> >:
> >>
> >> Hi all,
> >>
> >> I'm tracing how OFDM modulation is done by /ofdm/benchmark_tx.py.
> >>
> >> The file, ofdm.py indicates ofdm modulation is composed of like :
> >>
> >> modulation - mapper - preamble - IFFT - CP - scale
> >> |- mapper - preamble -|
> >>
> >> And I have a question at ofdm_mapper_bcv.
> >>
> >> In ofdm_mapper_bcv_impl::work, I can find making symbol part :
> >>
> >> /while(..){
> >> /
> >> /if((8-d_bit_offset) >= d_nbits) {
> >> /
> >> /bits = ((1 << d_nbits)-1) & (d_msgbytes >> d_bit_offset);
> >> d_bit_offset += d_nbits;
> >> d_bit_offset += d_nbits;
> >> out[d_subcarrier_map[i]] = d_constellation[bits];
> >> /
> >> /}
> >> /
> >> /}
> >>
> >> /
> >> For example, using BPSK :
> >> - d_nbits = 1
> >> - d_msgbytes = 94 (0101 1110)
> >>
> >> 1st loop:
> >> - bits = ( 0001) & (0101 1110) = 0  // takes right-most bit
> >> - d_bit_offset = 2
> >> - out[..] = d_constellation[0]
> >>
> >> 2nd loop:
> >> - bits = ( 0001) & (0001 0111) = 1
> >> - d_bit_offset = 4
> >> - out[..] = d_constellation[1]
> >>
> >> 3rd & 4th same like above.
> >>
> >> In this example, it just takes odd parts of byte (0, 1, 1, 1).
> >>
> >> How can receiver deduce even part (1, 1, 0, 0) ?
> >>
> >> I don't know why /d_bit_offset += d_nbits/ double times, not an one.
> >>
> >> Is this related with two mapping & preamble blocks ? (I/Q ch?)
> >>
> >> If right, these two mapping handle even or odd part of byte
> >> respectively ?
> >>
> >> Thanks.
> >>
> >>
>
>
This is admittedly frustrating from a new-user perspective that we have
"examples" of how to do a thing and then we tell you  not to use it when
you ask about it. Hopefully as we get more serious about 3.8 we can start
to revamp examples in our next branch to show off better ways.

For now Marcus and Martin have given pretty good suggestions for this
particular case.

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

Re: [Discuss-gnuradio] [VOLK] VOLK website license

[West, Nathan]

Indeed.

I updated the footer to point to the correct license and clarified that the
logo is copyright Marcus. Obviously he has licensed it for purposes of this
website. We had a brief conversation about it a few minutes ago in which I
don't think we had an agreement on what the license for the logo should be.

I'll update again with a proper license statement for the logo once we have
clarification on his intent.

-Nathan

On Tue, May 24, 2016 at 4:06 PM, Marcus Müller 
wrote:

> As it happens, I designed that logo; it's not necessarily under the same
> license as the website.
>
> Now I'm curious: what's your plan? What do you want to do with that logo?
>
> Best regards,
> Marcus
>
>
> On 24.05.2016 21:38, Raj Bhattacharjea wrote:
>
> The VOLK website claims it's contents are licensed under "Creative Commons
> Attribution-NoDerivs 4.0 International", however, the license link actually
> takes you to the text of the "Attribution-NonCommercial-NoDerivatives 4.0
> International".
>
> These are different licenses and the difference is whether the license
> allows others to use the content for commercial purposes. I was trying to
> cite a copy of the VOLK logo when I came across this. I hope the VOLK
> website maintainer watches this list and clarifies which license the site
> is under.
>
> --
> Raj Bhattacharjea, PhD
> Georgia Tech Research Institute
> Information and Communications Laboratory
> http://www.prism.gatech.edu/~rb288/
> 404.407.6622
>
>
> ___
> 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

Re: [Discuss-gnuradio] Cannot run FM radio either

[West, Nathan]

Keep track of your sampling rates.

Input is 5e6. Filter decimates to 1e6. Rational resampler goes to 2.4e6,
then you've told the wbfm rx to expect input at 480e3. In the rational
resampler try setting interpolation to 480e3 and decimation to 1e6.

Hopefully that gets you some sound. By the way, where is this tutorial? Can
you provide a link?

Cheers,
-nathan


On Tue, May 10, 2016 at 10:04 PM, Vinit Shah <tug14...@temple.edu> wrote:

> Well, Thank you for pointing that out.. but still without multiply block I
> still have trouble with listening to music on FM radio..
> Now I can see the peaks where there are stations but still all I here is
> noise in my output..
> Any suggestions would be highly appreciable
> -Vinit
>
> On Tue, May 10, 2016 at 5:48 PM, West, Nathan <n...@ostatemail.okstate.edu
> > wrote:
>
>> You're misunderstanding sampling. A couple of things:
>>
>> 1) Your signal source has a "sampling frequency" of 5MHz and you are
>> asking it to generate a cosine with frequency 96.5 MHz. If you've had a DSP
>> or linear systems class thing back to nyquist (damn kentucky derby means
>> googling for nyquist is now full of horses)
>> 2) Let's say you tune the USRP to 96.5MHz and there's a station there.
>> What do you expect the received spectrum to look like? For a hint look up
>> complex baseband.
>>
>> Also, it helps people help you if you explain what you expected and what
>> actually happened.
>>
>> On Tue, May 10, 2016 at 4:50 PM, Vinit Shah <tug14...@temple.edu> wrote:
>>
>>> hi,
>>> I have been trying to run basic FM radio tutorial using USRP n200 but I
>>> cannot even do that. Attached is the png file of my flow graph, I do not
>>> understand what is wrong here.
>>>
>>> I also tried to check spectrum using  waterfall sink but no significant
>>> results
>>> Please guide me here.
>>>
>>> -Vinit Shah
>>>
>>> ___
>>> 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] Cannot run FM radio either

[West, Nathan]

You're misunderstanding sampling. A couple of things:

1) Your signal source has a "sampling frequency" of 5MHz and you are asking
it to generate a cosine with frequency 96.5 MHz. If you've had a DSP or
linear systems class thing back to nyquist (damn kentucky derby means
googling for nyquist is now full of horses)
2) Let's say you tune the USRP to 96.5MHz and there's a station there. What
do you expect the received spectrum to look like? For a hint look up
complex baseband.

Also, it helps people help you if you explain what you expected and what
actually happened.

On Tue, May 10, 2016 at 4:50 PM, Vinit Shah  wrote:

> hi,
> I have been trying to run basic FM radio tutorial using USRP n200 but I
> cannot even do that. Attached is the png file of my flow graph, I do not
> understand what is wrong here.
>
> I also tried to check spectrum using  waterfall sink but no significant
> results
> Please guide me here.
>
> -Vinit Shah
>
> ___
> 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] Fwd: Re: Sigh - 16.04 build failure

[West, Nathan]

On Mon, May 9, 2016 at 5:28 PM, Mike  wrote:

> Found it ! I discovered a duplicate set of headers in /usr/local/include
> and /usr/include, fixing this didn't fix the problem.
>
> After several hours wondering what was wrong with the headers I found
> there were two versions of libcppunit. This must have been a leftover of
> the upgrade to 16.04 as it should surely have been deleted when replaced by
> the updated version.
>
> The older libcppunit-1.12 in /usr/lib/ and the newer, libcppunit-1.13 was
> in /usr/lib/x86_64-linux-gnu/ - why in different directory I have no idea.


Is this three different versions of libcppunit?

Worth pointing out that the Ubuntu changelog (
http://changelogs.ubuntu.com/changelogs/pool/universe/c/cppunit/cppunit_1.13.2-2.1/changelog)
has a change of starting multi-arch installs from Sept 2012. The multi-arch
install is the different directory that you have no idea about and it helps
keep multi-arch and cross compiling sane.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Introducing the New GNU Radio Website

[West, Nathan]

The development link is intended for keeping developer focused content
which is highly dynamic. It will always go to a wiki. It won't always be
redmine, but I'll leave that as a teaser so you listen to the monthly dev
calls ;-)

-Nathan

On Tue, May 3, 2016 at 7:26 PM, Richard Bell 
wrote:

> I like the new style, it feels fresh and modern.
>
> I've noticed that depending on the link you click, you may end up on a
> page in the old style. For example, clicking the development link does
> this. Will the entire website eventually get the makeover?
>
> Rich
>
> On Tue, May 3, 2016 at 1:44 PM, Ben Hilburn  wrote:
>
>> Hi all -
>>
>> I am happy to share that primary development on the user-facing GNU Radio
>> website has been wrapped up! You can check out the new site in action at
>> gnuradio.org.
>>
>> There is still a lot of content work to do as we migrate away from
>> Redmine (you may notice that many of the links on the website take you to
>> Redmine-hosted content, at the moment), but initial development on the site
>> infrastructure itself has wrapped up. There are some items we would still
>> like to get to eventually (like integrating the site Events Calendar
>>  with the Org GCal
>> ),
>> so if you have any ideas for further improvement, feel free to send them my
>> way. Also, if you are into web development and would like to get involved,
>> please let me know!
>>
>> Going forward, community & project News  and
>> Events  will be posted on the website (in
>> addition to the mailing list, as usual), and developers will be sharing
>> articles in the Blog  area of the site. If
>> you have an idea for content that you would like to share with the broader
>> community on the site, just get in touch. And, of course, if you spot any
>> issues, please send me a note.
>>
>> A special thanks to Marcus Mueller, who did a ton of work on most of the
>> images that appear on the site, and to Johnathan Corgan, who manages our
>> server infrastructure in addition to everything else he is doing for the
>> project.
>>
>> Cheers,
>> Ben
>>
>> ___
>> 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] ORC support on armhf w/ embedded SDK

[West, Nathan]

ORC is still in VOLK, but it doesn't give you much.

On Tue, May 3, 2016 at 11:32 AM, Philip Balister 
wrote:

> On 05/03/2016 10:47 AM, Sean Nowlan wrote:
> > According to the wiki [1], ORC support was disabled on armhf due to a
> bug,
> > which has apparently since been resolved [2]. Was ORC support added back
> > for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki
> > page just out of date?
> >
> > Thanks,
> > Sean
> >
> > [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
> > [3] http://gnuradio.org/data/sdk/
>
> I feel like we've replaced all the places we used orc, so we
> (uhd/gnuradio/volk) are not really using it anymore.
>
> It tends to show up in images, just that it may not be used by gnuradio
> and friends.
>
> Philip
>
> >
> >
> >
> > ___
> > 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] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

[West, Nathan]

On Thu, Apr 28, 2016 at 1:31 PM, Lamar Owen  wrote:

> The EPEL repository for RHEL and its rebuilds currently has a slightly
> older version of GNUradio in the repo, a 3.7.5.
>
> I filed a bug in the EPEL bugzilla as an RFE to update to 3.7.9, but I got
> an answer back that it is EPEL policy (much like RHEL) to not update to
> latest version unless it 'can't be avoided.'  The link to the policy
> document:
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy
>
> Does anyone know of any fixes since 3.7.5 that might be considered 'can't
> avoid?'
>

Personal opinion incoming:
Normally I strongly advocate for working off of the latest release
possible, but this is my exception. Two thoughts:
1) If you don't know of a good reason to move from 3.7.5, why are you
pressuring an entire distribution to go against their policy?
2) A major selling point (I think) of RHEL and by extension Fedora is the
lng stable cycle. If they upgrade to latest versions just because they
are shinier then that goes against the distro philosophy. I think it makes
more sense to either upgrade to the latest release of the distribution or
build from source
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[West, Nathan]

This was a bug that's been fixed recently.
https://github.com/gnuradio/pybombs/commit/38ed9d169ed67ef090e6015b07c4918f7c112209

On Thu, Apr 21, 2016 at 11:23 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>
> I ran it, but it thinks that -v is a recipe and it errors out there.  If
> instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, i
> get:
> 
> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
> PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '',
> 'builddir': '/home/jmat/gnuradio/src/uhd/build'}
> PyBombs.Packager.source - DEBUG - In cwd -
> /home/jmat/gnuradio/src/uhd/build
> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
> CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" does not
> appear to contain CMakeLists.txt.
> Specify --help for usage, or press the help button on the CMake GUI.
> PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
> PyBombs.monitor_process() - DEBUG - Return value: 1
> PyBombs.Packager.source - ERROR - Problem occurred while building package
> uhd:
> Process returned value: 1
> PyBombs.install - ERROR - Error installing package uhd. Aborting.
> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
> 
>
>
> ___
> 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] GNU Radio Overwrites UHD With Old Version

[West, Nathan]

On Thu, Apr 21, 2016 at 9:25 AM, Hughes, Jeremy Jay 
wrote:

> I am trying to install GNU Radio and UHD on a Raspberry Pi 2 so that it
> will work with a USRP B200MIni. I am using the newest version of
> Raspbian-Jessie on the Raspberry Pi. I can get GNU Radio installed using
>
> > sudo apt-get install gnuradio
>
> The problem is that the UHD provided with this is too old.  Will there be
> a updated package added to apt-get anytime soon?
>
This is a question for whoever packages GNU Radio for Raspbian. I would
guess not. I recommend reading up on packaging practices of whatever
distribution you use (in this case Raspbian, based on Debian). Most distros
including Debian "freeze" packaged software at the version that was current
whenever the distro's release freeze date is, and will update bug fixes,
but not do wholesale release changes (essentially maintaining a stablei ABI
so *everything* doesn't need to recompile). This avoids a *ton* of head
aches.


> The next thing I tried was installing UHD from source first and then
> installing GNU Radio after. I can get the UHD driver installed so that it
> will see the B200Mini but once I install GNU Radio it overwrites the UHD I
> installed from source.
>
This is ambiguous. Did you apt-get install gnuradio? Again, this is a
packaging thing for sanity. Your distribution's binary build of GNU Radio
depends on your distribution's binary build of UHD and it will be installed.


> The next thing I tried was using pybombs to install uhd and gnuradio but
> once again, I ended up with a UHD version that was too old to use with my
> B200Mini.
>
Now that's not supposed to happen.


> Is there a way to get GNU Radio and a new version of UHD to work on the
> Raspberry Pi 2?  Any help would be greatly appreciated.
>

Make sure you remove *everything* you've done to date, then start over from
scratch with pybombs. apt-get remove gnuradio and uhd. remove your source
install of UHD, remove your pybombs install of everything. Clear out your
pybombs prefix and try again with pybombs. In general don't mix source and
binary installs.

>
> Thank you for your time,
>
>
> Jeremy Hughes
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????

[West, Nathan]

On Mon, Apr 18, 2016 at 3:27 AM, Douglas Geiger <
doug.gei...@bioradiation.net> wrote:

> I know I'm a little late to this party, but I thought I'd point this out:
> the output "VOLK: Error allocating memory (posix_memalign: 22)" suggests
> you are running into this known issue:
> http://gnuradio.org/redmine/issues/692
>
> If this is indeed a rPi Rev B, then this is the known/old issue of
> volk_get_alignment() returning a value on 1 on that arch, which then breaks
> posix_memalign. I believe this has been fixed in more recent releases, so
> perhaps jessie-backports can help you there?
>

Indeed.
https://github.com/gnuradio/volk/commit/cc1abd2ea27c7f303efaa6466e97970915ed
has been in VOLK since before v1.0


>
>  Good luck,
>   Doug
>
> On Wed, Apr 13, 2016 at 4:45 AM, Rob Roschewsk  wrote:
>
>> Marcus,
>>
>> Thanks for responding.
>>
>> I'm looking to build a headless FM receiver to record and stream public
>> service communication (fire, police, etc.). We will stream as many channels
>> as possible that fall into a given passband.
>>
>> I already have a system running on a PC and now would like to port it to
>> the PI.
>>
>> I understand it maybe an "up hill" path, but the thought is to deploy
>> multiple inexpensive units around a geographic area all feeding a central
>> streaming server.
>>
>> The Pi is running Raspian Jesse  I started with the distribution
>> packages but ran into problems right out of the blocks and thought it would
>> be best to use the latest code before asking questions :)
>>
>> I understand cross compiling is the way to go.
>>
>> Since I brought it up, here was the error I saw when I tried to run the
>> script that runs on the PC but fails spectacularly on the raspberry pi with
>> the precompiled packages 
>>
>> roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py -s 49 noaa.xml
>> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0
>> <0030070030>-unknown
>>
>> high=16250 low=16240 span=10
>> center=16245
>> gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
>> bladerf rfspace airspy
>> Using device #0 Realtek RTL2838UHIDIR SN: 0108
>> Found Elonics E4000 tuner
>> Exact sample rate is: 100.026491 Hz
>> Using Volk machine: generic_orc
>> VOLK: Error allocating memory (posix_memalign: 22)
>> VOLK: Error allocating memory (posix_memalign: 22)
>> VOLK: Error allocating memory (posix_memalign: 22)
>> Segmentation fault
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Doug Geiger
> doug.gei...@bioradiation.net
>
> ___
> 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] In progress VOLK work -- supporting Jazelle / accelerating Java in VOLK

[West, Nathan]

Hi all,

I've been working on ARM platforms and supporting VOLK for a while now, and
I've wanted to support accelerating Android (and therefore Java)  as
devices become smaller and lower power. The obvious answer to accelerating
this code is to take advantage of ARM's Jazelle mode which is direct
bytecode execution (basically a hardware implementation of the JVM).

Current progress is sitting on the Jazelle branch on my github:
https://github.com/n-west/volk/tree/jazelle. I suggest you browse through
the last few commits there to get a sense of what this entails.

Hopefully I can get this to a mergeable state soon. Patches welcome.

Cheers and happy april 1 (sorry to those who have not yet had the
misfortune of reaching this date),
-Nathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

[West, Nathan]

I'm in the habit of not downloading and extracting tarballs from strangers
on the internet, so I don't know what Tom's latest issue is, but the
problem you refer to is an issue revealed by the release of cmake 3.5.

cmake 3.5 was released after the latest VOLK and GNU Radio release. That
bug has since been fixed on the maint and master branches of git and will
be available in the next release if you're the kind of person to like
releases. One of the listed sed scripts would also work around this
problem, so that's not the latest issue Tom is having.

Cheers,
-nathan

On Wed, Mar 30, 2016 at 3:43 PM, Frederick E. Stevens  wrote:

> Hi,
>
> Just tried building on my machine.  Slackware64-14.1 with cmake 3.5.1
> built from Slackware64-current.  I would have tried this on a 32 bit
> machine but I don't have any running any more.  What I found is that cmake
> 3.5 fails with errors when configuring gnuradio 3.7.9.1 build.  I modified
> the gnuradio.SlackBuild so that ccmake is executed instead of cmake.  That
> way I could see what was configured before trying to compile.  With cmake
> 3.5.1 on the first configure pass I receive the following error messages:
>
> CMake Error at volk/lib/CMakeLists.txt:134 (list):
>list sub-command REMOVE_ITEM requires list to be present.
>  Call Stack (most recent call first):
>volk/lib/CMakeLists.txt:159 (OVERRULE_ARCH)
>
>
>
>  CMake Error at volk/lib/CMakeLists.txt:134 (list):
>list sub-command REMOVE_ITEM requires list to be present.
>  Call Stack (most recent call first):
>volk/lib/CMakeLists.txt:188 (OVERRULE_ARCH)
>
>
>
>  CMake Error at volk/lib/CMakeLists.txt:134 (list):
>list sub-command REMOVE_ITEM requires list to be present.
>  Call Stack (most recent call first):
>volk/lib/CMakeLists.txt:258 (OVERRULE_ARCH)
>
> On the second pass:
>
> CMake Error at
> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
> (CMAKE_PARSE_ARGUMENTS):
>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>  Call Stack (most recent call first):
>/usr/share/cmake-3.5/Modules/FindPythonLibs.cmake:265
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>CMakeLists.txt:234 (find_package)
>
> Eventually, I went to cmake 3.4.3 and gnuradio is building right now.  You
> might want to check your cmake and go to pre 3.5 to see if that is the
> issue that you are having.
>
> Hope this helps,
>
> Cheers,
>
> Fred
>
>
> On 03/30/2016 11:28 AM, tp...@mklab.ph.rhul.ac.uk wrote:
>
>> Dear All,
>>   I am attempting to build Gnuradio on a 32-bit x86 Slackware-current
>> system but without success.  I have tried several approaches.
>>
>> o Using the Slackbuilds scripts at
>> https://slackbuilds.org/repository/14.1/development/gnuradio/ which
>> builds gnuradio-3.7.8.1.
>> o Using the Slackbuilds scripts to build the current release
>> gnuradio-3.7.9.1
>> o Unpacking gnuradio-3.7.9.1 and following the minimal instructions at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
>> o Downloading the default branch from git and following the minimal
>> instructions at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
>>
>>
>> Firstly I found and fixed/worked-around 3 compiler problems encountered
>> with gcc 5.3.0;
>>
>> (1) -lpthread needed to be added to CMAKE_C_FLAGS and/or
>> CMAKE_CXX_FLAGS.  I added it to both.
>> (2) This fix "sed -i 's/(intrin.h/(x86intrin.h/g'
>> ../volk/lib/CMakeLists.txt" gets around intrin.h not being present.
>> (3) This fix "sed -i 's/.\+Werror=unused\-command-line\-argument.\+//g'
>> ../volk/lib/CMakeLists.txt" gets around this Warning option not being
>> available.
>>
>> Then I was able to start the cmake configuration process.  However I get
>> errors like this,
>>
>> /usr/bin/python2: can't open file
>> '/tmp/SBo/gnuradio-3.7.9.1/gen/volk_compile_utils.py': [Errno 2] No such
>> file or directory
>>
>> This script is present but in the volk sub-directory, ie. in
>> /tmp/SBo/gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py.
>>
>> Checking the source tarball, eg.
>>
>> $ tar -tzvf gnuradio-3.7.9.1.tar.gz | grep volk_compile_utils.py
>> -rw-rw-r-- root/root  2165 2016-02-07 17:09
>> gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py
>>
>> confirms this is where it gets unpacked.
>>
>> I tried a couple of work-arounds,
>>
>> (1) Symlinking the volk/* directories into the top-level directory before
>> the cmake stage and then repeating this
>> symlinking in the build directory.  Doing this got me some distance (23%)
>> into the make procedure before it failed.  See files
>> gnuradio.SlackBuild.try6 &
>> gnuradio.SlackBuild.try6.log.  Some of these directories already exist in
>> the top level & build directories and so can't be symlinked from below.
>> I can't believe this should be necessary and I presume must be an
>> artifact of something else being amiss...
>>
>> (2) Editing the volk/lib/CMakeLists.txt list before running cmake and
>> following the Wiki BuildGuide.  The following edits/hacks 

[Discuss-gnuradio] Embedding qtgui widgets inside QFrame

[West, Nathan]

I've got a really dumb UI made from qt4-designer, pythonized with pyuic4,
and an app that imports and creates the ui. Inside this app I make a
qtgui.time_sink_c and a qtgui.freq_sink_c. My UI has empty frames that I
place a sip-wrapped instance of the qtgui widgets in.

On one machine, let's call it pepper (running i3), the qtgui widgets load
up and the whole things displays/behaves nicely. On another machine, let's
call it saffron (running KDE), the UI shows up blank and I can't exit (have
to kill it from terminal).

Both machines have GNU Radio v3.7.9.1 on Debian 8.3 with the only major
software difference being KDE vs i3.

As a sanity check I use a third machine (let's not call it anything
special) also running Debian 8.3 and KDE which has the same issue as
saffron (no widgets displayed). Switching to gnome shows the same behavior.
Switching to i3 works (all widgets show up and qtgui widgets are
displayed). If I never create the qtgui widgets in KDE/Gnome then the other
widgets will show up. If I create the qtgui widgets, but don't do anything
with the I have the same issue (no other widgets show up)

Has anyone run in to this and if so how did you solve it? Does anyone know
what KDE/Gnome is doing to make qtgui widgets kill my UI? Run this script
to try it: https://github.com/n-west/gr-vsg/blob/master/vsg.py

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

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[West, Nathan]

Yes. See twisted, python-zmq, and sip for similar types of packages.

On Wed, Mar 23, 2016 at 3:44 PM, Laur Joost <darem...@gmail.com> wrote:

> To be clear: since there's no networkx recipe, should I just create one,
> and add it to gnuradio dependencies?
>
> Laur
>
> 2016-03-23 20:45 GMT+02:00 Laur Joost <darem...@gmail.com>:
>
>> Martin: I'm rebuilding from scratch this night. I'll modify the recipe
>> for networkx before starting, and if it works, I'll.. what? submit a pull
>> request? Well, first time for everything.
>>
>> Nathan: As in, installing graphviz and pygraphviz should have been
>> dependencies for networkx, not something we should need to worry about?
>> Yeah, probably makes sense.
>>
>> All the best
>> Laur
>>
>> 2016-03-23 19:50 GMT+02:00 West, Nathan <n...@ostatemail.okstate.edu>:
>>
>>> It sounds like networkx is only part of the issue and maybe there's an
>>> upstream bug that Tom has patched over locally. Is this something we should
>>> report upstream to the distros?
>>>
>>>
>>> On Wednesday, March 23, 2016, Martin Braun <martin.br...@ettus.com>
>>> wrote:
>>>
>>>> Laur,
>>>>
>>>> can you please submit a recipe to gr-recipes for networkx?
>>>>
>>>> Thanks,
>>>> Martin
>>>>
>>>> On 03/23/2016 01:50 AM, Laur Joost wrote:
>>>> > Thanks for the responses, and damned be the timezones.
>>>> >
>>>> > Nathan: gr-perf-monitorx needs python-networkx (which is installed by
>>>> > pybombs, or at least, existed for me), but python-networkx needs
>>>> > python-pygraphviz, at least for how it's used by gr-perf-monitorx.
>>>> >
>>>> > Tom: Yes, the errors popped up when networkx called agraph-something.
>>>> > Sadly, I managed to blow up my installation, so can't get a traceback
>>>> > for you (was able to reproduce by simply doing apt-get uninstall
>>>> graphviz).
>>>> >
>>>> > On another note (the blowing up), I had an issue with gr-uhd ABI
>>>> versions:
>>>> > When trying to use USRP on the same install, I got:
>>>> >
>>>> > Traceback (most recent call last):
>>>> >   File "/home/ec/Tests/top_block.py", line 167, in 
>>>> > main()
>>>> >   File "/home/ec/Tests/top_block.py", line 155, in main
>>>> > tb = top_block_cls()
>>>> >   File "/home/ec/Tests/top_block.py", line 69, in __init__
>>>> > channels=range(1),
>>>> >   File
>>>> >
>>>> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>>>> line
>>>> > 122, in constructor_interceptor
>>>> > return old_constructor(*args)
>>>> >   File
>>>> >
>>>> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>>>> line
>>>> > 1973, in make
>>>> > return _uhd_swig.usrp_source_make(*args)
>>>> > RuntimeError:
>>>> > GR-UHD detected ABI compatibility mismatch with UHD library.
>>>> > GR-UHD was build against ABI: 3.9.0-0,
>>>> > but UHD library reports ABI: 3.10.0-0
>>>> > Suggestion: install an ABI compatible version of UHD,
>>>> > or rebuild GR-UHD component against this ABI version.
>>>> >
>>>> > However, install log shows:
>>>> >
>>>> > Configuring gr-uhd support...
>>>> > --   Dependency Boost_FOUND = 1
>>>> > --   Dependency UHD_FOUND = TRUE
>>>> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>>>> > --   Dependency ENABLE_GR_FILTER = ON
>>>> > --   Dependency ENABLE_GR_BLOCKS = ON
>>>> > --   Dependency ENABLE_GR_ANALOG = ON
>>>> > --   Enabling gr-uhd support.
>>>> > --   Override with -DENABLE_GR_UHD=ON/OFF
>>>> > --   UHD Version: 3.10.git
>>>> >
>>>> > I had UHD 3.9.1 installed via package manager (wasn't as thorough as
>>>> I'd
>>>> > hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
>>>> > version in the log was 3.10, I would've thought that that would be the
>>>> > version built against. I guess its mostly PEBKAC, but still, weird.
>>>> >
>>>> > I'll t

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[West, Nathan]

It sounds like networkx is only part of the issue and maybe there's an
upstream bug that Tom has patched over locally. Is this something we should
report upstream to the distros?

On Wednesday, March 23, 2016, Martin Braun <martin.br...@ettus.com> wrote:

> Laur,
>
> can you please submit a recipe to gr-recipes for networkx?
>
> Thanks,
> Martin
>
> On 03/23/2016 01:50 AM, Laur Joost wrote:
> > Thanks for the responses, and damned be the timezones.
> >
> > Nathan: gr-perf-monitorx needs python-networkx (which is installed by
> > pybombs, or at least, existed for me), but python-networkx needs
> > python-pygraphviz, at least for how it's used by gr-perf-monitorx.
> >
> > Tom: Yes, the errors popped up when networkx called agraph-something.
> > Sadly, I managed to blow up my installation, so can't get a traceback
> > for you (was able to reproduce by simply doing apt-get uninstall
> graphviz).
> >
> > On another note (the blowing up), I had an issue with gr-uhd ABI
> versions:
> > When trying to use USRP on the same install, I got:
> >
> > Traceback (most recent call last):
> >   File "/home/ec/Tests/top_block.py", line 167, in 
> > main()
> >   File "/home/ec/Tests/top_block.py", line 155, in main
> > tb = top_block_cls()
> >   File "/home/ec/Tests/top_block.py", line 69, in __init__
> > channels=range(1),
> >   File
> >
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line
> > 122, in constructor_interceptor
> > return old_constructor(*args)
> >   File
> >
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line
> > 1973, in make
> > return _uhd_swig.usrp_source_make(*args)
> > RuntimeError:
> > GR-UHD detected ABI compatibility mismatch with UHD library.
> > GR-UHD was build against ABI: 3.9.0-0,
> > but UHD library reports ABI: 3.10.0-0
> > Suggestion: install an ABI compatible version of UHD,
> > or rebuild GR-UHD component against this ABI version.
> >
> > However, install log shows:
> >
> > Configuring gr-uhd support...
> > --   Dependency Boost_FOUND = 1
> > --   Dependency UHD_FOUND = TRUE
> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> > --   Dependency ENABLE_GR_FILTER = ON
> > --   Dependency ENABLE_GR_BLOCKS = ON
> > --   Dependency ENABLE_GR_ANALOG = ON
> > --   Enabling gr-uhd support.
> > --   Override with -DENABLE_GR_UHD=ON/OFF
> > --   UHD Version: 3.10.git
> >
> > I had UHD 3.9.1 installed via package manager (wasn't as thorough as I'd
> > hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
> > version in the log was 3.10, I would've thought that that would be the
> > version built against. I guess its mostly PEBKAC, but still, weird.
> >
> > I'll try building again this night, this time without 3.9 installed. If
> > the issue persists, I'll make another thread.
> >
> > 2016-03-23 1:30 GMT+02:00 Tom Rondeau <t...@trondeau.com <javascript:;>
> > <mailto:t...@trondeau.com <javascript:;>>>:
> >
> > On Tue, Mar 22, 2016 at 7:05 PM, West, Nathan
> > <n...@ostatemail.okstate.edu <javascript:;>  n...@ostatemail.okstate.edu <javascript:;>>>
> > wrote:
> >
> > Sorry, may or may not be talking about the same thing here.
> > gr-perf-monitorx requires python-networkx, which (I think) is an
> > untracked dependency.
> >
> >
> >
> > For utilities like this, we have not previously made Python modules
> > a required dependency of GNU Radio. We could, but that would put an
> > extra burden on just building the project even if you don't use the
> > particular app or example. Generally, we try to provide a friendly
> > message explaining the problem. PyBOMBS probably should add these
> > dependencies, though. At least scipy.
> >
> > Also, I believe I ran into this issue recently new versions of
> > networkx that broke out a dependency that used to not be required as
> > a separate install, which I think is what the OP's problem is
> > related to. See PR #768:
> >
> > https://github.com/gnuradio/gnuradio/pull/768
> >
> > Tom
> >
> >
> >
> >
> > On Tue, Mar 22, 2016 at 7:04 PM, West, Nathan
> > <n...@ostatemail.okstate.edu <javascript:;>
> > <mailto:n...@ostatemail.okstate.edu <javascript:;>>> wrote:
&g

Re: [Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[West, Nathan]

Looking through the proposal I mostly see your translation of the idea from
the GSoC ideas list to a proposal format. All of that is fine, but we've
already decided this is a reasonable idea and the proposal should convince
us that you're the right person to work on it.

You've provided the right evidence that you've read some of the GSoC pages,
but my current criticism boils down to missing information that we ask for
here: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo

I'll point out *some* specifics but please don't just list responses to
these things in the proposal. Rather reshape it to giving us an idea of
what you want to do (which you have) and why you're the right person. The
list I'm providing is not meant to be exhaustive, and I'm not suggesting
that you're not the right person to do this, just that you haven't
addressed that (or your eligibility for GSoC in your proposal. It's also
possible I am being dense and missed some of this information.

>From the page I linked you're missing:
* Proof of your coding capabilities (this is the big one)
* University and student status (more of a formality)
* why do you want to do *this* project? (this is not critical, but if
you've done any classes or work in areas related to your proposal idea than
that looks very good)

Ideally this is all more than a single sentence that says "I did a matlab
simulation once in a class and it was cool", but much less than a college
admissions essay on why DSP will save the world.

Looking forward to the next draft (and hopefully faster turnaround),
-Nathan

PS - most of this email can be copy and pasted as feedback for several
other proposals I've read so far.


On Wed, Mar 23, 2016 at 6:19 AM, Usman Haider 
wrote:

> I have not get any feedback on this yet. I hope I have not missed anything
> important? Please, provide feedback on this.
>
>
> Regards,
> Usman
>
>
> On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider 
> wrote:
>
>> I have added lambda expression in deliverables based on Tim's comments.
>> This will allow user to enter lambda expression in GUI. That expression
>> will be then evaluated on samples and result will be displayed. Rather than
>> providing fixed mathematical function (scale/normalize), user  can apply
>> anonymous functions, they want, on samples using Lambda construct. This
>> will give user more flexibility. I have updated my proposal. You can see it
>> on following link
>>
>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>
>> Awaiting feedback.
>>
>> Regards,
>> Usman
>>
>> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider 
>> wrote:
>>
>>> Hi Community,
>>>
>>> I have made my proposal for the subject GSoC idea. Please have a look
>>> and give feedback. Thanks for your time.
>>>
>>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>>
>>> Regards,
>>> Usman
>>>
>>
>>
>
> ___
> 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] PYBOMBS CtrlPort pygraphviz dependency

[West, Nathan]

Sorry, may or may not be talking about the same thing here.
gr-perf-monitorx requires python-networkx, which (I think) is an untracked
dependency.

On Tue, Mar 22, 2016 at 7:04 PM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> gr-perf-monitorx. It's just been the kind of thing that everyone that uses
> it already has and no one tracks it. There's a couple of minor deps for
> utilities like this that sneak through the cracks, but they're very hard to
> keep track of until you run this on a brand new image.
>
> nw
>
> On Tue, Mar 22, 2016 at 6:46 PM, Martin Braun <martin.br...@ettus.com>
> wrote:
>
>> Who is calling pygraphviz? If we need this for GNU Radio, we probably
>> need to update some recipes.
>>
>> M
>>
>> On 03/22/2016 12:12 PM, Laur Joost wrote:
>> > Hi all!
>> >
>> > Fresh install of gnuradio-3.7.9.1 via PyBOMBS-2.0.1 on Ubuntu 15.10
>> >
>> > When trying to run CrtlPort Performance Monitor on a fresh 3.7.9.1
>> > install, I got errors about missing pygraphviz.
>> >
>> > sudo apt-get python-pygraphviz
>> >
>> > solved it for me. The supposedly equivalent
>> >
>> > sudo apt-get install graphviz
>> > [sudo apt-get install graphviz-dev libgraphviz-dev]
>> > pip install pygraphviz
>> >
>> > threw a bunch of errors and claimed to be successful, but didn't work.
>> > So beware PyPI, in this case.
>> >
>> >
>> > ___
>> > 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] PYBOMBS CtrlPort pygraphviz dependency

[West, Nathan]

gr-perf-monitorx. It's just been the kind of thing that everyone that uses
it already has and no one tracks it. There's a couple of minor deps for
utilities like this that sneak through the cracks, but they're very hard to
keep track of until you run this on a brand new image.

nw

On Tue, Mar 22, 2016 at 6:46 PM, Martin Braun 
wrote:

> Who is calling pygraphviz? If we need this for GNU Radio, we probably
> need to update some recipes.
>
> M
>
> On 03/22/2016 12:12 PM, Laur Joost wrote:
> > Hi all!
> >
> > Fresh install of gnuradio-3.7.9.1 via PyBOMBS-2.0.1 on Ubuntu 15.10
> >
> > When trying to run CrtlPort Performance Monitor on a fresh 3.7.9.1
> > install, I got errors about missing pygraphviz.
> >
> > sudo apt-get python-pygraphviz
> >
> > solved it for me. The supposedly equivalent
> >
> > sudo apt-get install graphviz
> > [sudo apt-get install graphviz-dev libgraphviz-dev]
> > pip install pygraphviz
> >
> > threw a bunch of errors and claimed to be successful, but didn't work.
> > So beware PyPI, in this case.
> >
> >
> > ___
> > 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] GSoC 2016 Proposal - Speed Optimizations using Viterbi Decoders

[West, Nathan]

Hi Josh,

First, review it for grammar and spelling.

Second, I'd like to see a little bit more technical content on the viterbi
decoder. To be clear, I'm not looking for theory behind trellis coding or
the viterbi algorithm as much as demonstration of understanding what is
happening in the code.

I suggest putting the new VOLK kernel/optimized add block on hold and
dedicating that energy to picking up some understanding of the code you're
proposing to work with.

Finally, you're proposing to have lots of commitments. Make sure that if
you're accepted you definitely have the time and energy to dedicate the
expected full-time work week for GSoC.

-Nathan

On Tue, Mar 15, 2016 at 1:14 AM, Joshua Lilly  wrote:

> Good Evening,
> I recently drafted a proposal to work on GNU radio this summer through
> Google Summer of Code. If possible could anyone take a look at my draft and
> provide any type of feedback? Any help is much appreciated.
>
> Here
> 
> is a link to my draft.
>
> Thank you for your time,
> Josh
>
> ___
> 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] Exception : Could not connect to ControlPort endpoint

[West, Nathan]

This is definitely a case where the application is not nearly as
user-friendly as it could be. gr-ctrlport-monitor takes two arguments: an
address/hostname and a port. A controlport server must already be running
at that host:port, otherwise there's nothing to connect to.

On Thu, Mar 17, 2016 at 1:50 PM, raf raf  wrote:

> Hello all,
>
> I am trying to run gr-ctrlport-monitor.
>
> I get this error when I lunch a command gr-ctrlport-monitor
>
> ~/.gnuradio$ gr-ctrlport-monitor
> Could not connect to ControlPort endpoint at None:9090.
>
> Exception socket.error: (32, 'Broken pipe') in  ThriftRadioClient.__del__ of
>  0x7f43f4a8cb48>> ignored
>
>
> Can you help me please to fix this error
>
> ___
> 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] benchmark_tx and rx : too many FALSE packet

[West, Nathan]

There's been some subtle miscues in this thread. Let's start over from the
fundamentals.

First, think about what the flowgraph is. You must understand the transmit
and receive chains to do meaningful work with GNU Radio flowgraphs.

This is a rather old example of sending packetized data that doesn't use
error correction. There is a function that checks the CRC of packets. If a
single bit is wrong the packet fails. (As a side note building
packetized/bursty modems in the way these flowgraphs work is NOT
recommended).

Given this information, for the same SNR and channel what would you expect
to happen to bit error rates (and therefor packet error rates) as you
change modulations from GMSK, BPSK, etc to QAM?

Finally, as I mentioned these flowgraphs are sort of deprecated. Maybe you
can tell us what you're really going for and someone can suggest a better
tool.

Cheers,
Nathan

On Sun, Mar 13, 2016 at 4:22 AM, SangHyuk Kim  wrote:

> Hi all.
>
> I'm using benchmark_tx(rx).py example
>
> I experimented variety modulation schemes and GMSK, BPSK, QPSK modulation
> worked well
>
> However, when I used QAM modulation, most of received packet were
> corrupted (FALSE)
>
> ENV)
> both TX and RX uses USRP N210 with ANT500 and CBX 40MHz
> distance between TX and RX is shorter than 3m
>
> TX)
> ./benchmark_tx.py -f 1.5G -m qam -S 8 --tx-gain=30
>
> RX)
> ./benchmark_rx.py -f 1.5G -m qam -S 8
>
> RESULTS ON RX)
> ok = FALSE  pktno = 1  n_rcvd = 1  n_right = 0
> ok = FALSE  pktno = 2  n_rcvd = 2  n_right = 0
> ok = FALSE  pktno = 3  n_rcvd = 3  n_right = 0
> ...
> ok = TRUE  pktno = N  n_rcvd = N  n_right = 1
> ...
>
> Is this normal case of qam modulation ?
> How can I get more TRUE packet using QAM modulation ?
>
> Thanks.
>
> ___
> 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] How to measure throughput (data rate)

[West, Nathan]

Every block has a throughput performance counter:
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a78a27917edcd3b32f10b2166f3362a68

The output is items/sec.

On Mon, Mar 14, 2016 at 1:47 PM, Diyar Muhammed 
wrote:

> Dear All,
> I have made a transceiver in gnuradio software with using usrp B210, and I
> would like to measure data transmission between Tx and Rx, is there any way
> to measure that?
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
> ___
> 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] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

Good news!

That branch now belongs in GNU Radio.

Cheers,
Nathan

On Wed, Mar 9, 2016 at 8:45 AM, devin kelly <dwwke...@gmail.com> wrote:

> Thanks for the help, I don't think I could have figured this out on my own.
>
> This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
> references to AVX. For me there are a couple of options for fixing this:
>
> 1) Use Nathan's branch.
> 2) Rebuild fftw with AVX support
> 3) Rebuild GR and Volk without AVX.
>
> I tried 2) first and noticed this in the spec file that was in the source
> RPM I was trying to rebuild:
>
> %ifarch %{ix86} x86_64
> # Enable SSE2 support for x86 and x86_64
> # (no avx as it is claimed to drastically slower)
> for((i=0;i<2;i++)); do
>  prec_flags[i]+=" --enable-sse2"
> done
> %endif
>
> Is the spec file author right?  Now I'm a little confused about the
> approach I should take.  I'll probably just go with 1) in the mean time.
>
> Thanks again Nathan,
> Devin
>
> On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan <n...@ostatemail.okstate.edu>
> wrote:
>
>> The a and c vectors come from gr:fft objects' internal buffers. These are
>> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
>> fftwf_malloc is obviously not generating buffers with proper alignment so
>> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
>> is also only an issue with fftwf buffers when fftwf isn't built with AVX
>> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>>
>> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
>> ago with a QT sink.
>>
>> I have a branch that should fix this (
>> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
>> suggest you look in to getting a version of fftwf built with AVX. I don't
>> know if there's a good way to tell, but if I run readelf -a on my
>> libfftw3.so I see some functions with avx in the name.
>>
>> Cheers,
>> nw
>>
>>
>> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly <dwwke...@gmail.com> wrote:
>>
>>> OK, here's my C program:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main() {
>>>
>>> size_t alignment = volk_get_alignment();
>>>
>>> uint8_t* ptr;
>>>
>>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>>> *ptr);
>>> volk_free((void*)ptr);
>>> ptr = NULL;
>>>
>>>
>>> return 0;
>>> }
>>>
>>>
>>> Compile:
>>>
>>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>>
>>> It's output:
>>>
>>> $ ./volk_test
>>> Using Volk machine: avx2_64_mmx_orc
>>> alignment = 32, ptr = 151b040, *ptr = 00
>>>
>>> Also, I've attached the output from the preprocessor, this command:
>>>
>>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>>> -I/local_disk/gr_3.7.9_src/volk/include
>>> -I/local_disk/gr_3.7.9_src/volk/kernels
>>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>>> volk_malloc_preprocessed   -c
>>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>>
>>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>>> well.
>>>
>>> It looks like this is my volk_malloc():
>>>
>>>
>>> void *volk_malloc(size_t size, size_t alignment)
>>> {
>>>   void *ptr;
>>>
>>>
>>>
>>>
>>>   if (alignment == 1)
>>> return malloc(size);
>>>
>>>   int err = posix_memalign(, alignment, size);
>>>   if(err == 0) {
>>> return ptr;
>>>   }
>>>   else {
>>> fprintf(stderr,
>>> "VOLK: Error allocating memory "
>>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>>> return ((void *)0);
>>>   }
>>> }
>>>
>>>
>>>
>>> Devin
>>>
>>>
&

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

The a and c vectors come from gr:fft objects' internal buffers. These are
internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
fftwf_malloc is obviously not generating buffers with proper alignment so
you're seeing a 50% (per buffer) that this segfaults. I'll note that this
is also only an issue with fftwf buffers when fftwf isn't built with AVX
support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).

Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
ago with a QT sink.

I have a branch that should fix this (
https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also suggest
you look in to getting a version of fftwf built with AVX. I don't know if
there's a good way to tell, but if I run readelf -a on my libfftw3.so I see
some functions with avx in the name.

Cheers,
nw


On Tue, Mar 8, 2016 at 1:31 PM, devin kelly <dwwke...@gmail.com> wrote:

> OK, here's my C program:
>
> #include 
> #include 
> #include 
> #include 
>
> int main() {
>
> size_t alignment = volk_get_alignment();
>
> uint8_t* ptr;
>
> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr, *ptr);
> volk_free((void*)ptr);
> ptr = NULL;
>
>
> return 0;
> }
>
>
> Compile:
>
> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>
> It's output:
>
> $ ./volk_test
> Using Volk machine: avx2_64_mmx_orc
> alignment = 32, ptr = 151b040, *ptr = 00
>
> Also, I've attached the output from the preprocessor, this command:
>
> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
> -I/local_disk/gr_3.7.9_src/volk/include
> -I/local_disk/gr_3.7.9_src/volk/kernels
> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
> volk_malloc_preprocessed   -c
> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>
> I just found the compiler step from from doing 'VERBOSE=1 make' then
> changed the output and added -E.  I attached volk_malloc_preprocessed as
> well.
>
> It looks like this is my volk_malloc():
>
>
> void *volk_malloc(size_t size, size_t alignment)
> {
>   void *ptr;
>
>
>
>
>   if (alignment == 1)
> return malloc(size);
>
>   int err = posix_memalign(, alignment, size);
>   if(err == 0) {
> return ptr;
>   }
>   else {
> fprintf(stderr,
> "VOLK: Error allocating memory "
> "(posix_memalign: error %d: %s)\n", err, strerror(err));
> return ((void *)0);
>   }
> }
>
>
>
> Devin
>
>
>
> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <n...@ostatemail.okstate.edu
> > wrote:
>
>>
>> On Tue, Mar 8, 2016 at 10:58 AM, devin kelly <dwwke...@gmail.com> wrote:
>>
>>> Calling 'info variables' (or args or locals) the last few frames didn't
>>> give me any real info so I built a copy of GR/Volk with debug symbols.  I
>>> ran the FG again, this time from GDB, here's my back trace.  In this
>>> backtrace you can see the arguments passed in each call.  I have an
>>> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>>>
>>
>> Excellent. Thanks for going through that extra step. It really helps.
>>
>>
>>>
>>> Here's are the links for the relevant code:
>>>
>>>
>>> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>>>
>>> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>>>
>>> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>>>
>>> Could the problem be that nitems is 257 and num_points is 512?  Or
>>> should nitems really be 256 and not 257?
>>>
>>
>> I don't think so. I'm not familiar with the details of the fft_filter
>> implementations, but usually these things will take in some history if they
>> don't have enough points to operate on (in this case 512).
>>
>> The much more worrying thing is your vector addresses.
>>
>>
>>>
>>> Thanks,
>>> Devin
>>>
>>> (gdb) bt
>>> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
>>> (__P=0x3b051b0)
>>> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avx

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

On Tue, Mar 8, 2016 at 10:58 AM, devin kelly  wrote:

> Calling 'info variables' (or args or locals) the last few frames didn't
> give me any real info so I built a copy of GR/Volk with debug symbols.  I
> ran the FG again, this time from GDB, here's my back trace.  In this
> backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>

Excellent. Thanks for going through that extra step. It really helps.


>
> Here's are the links for the relevant code:
>
>
> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>
> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>
> Could the problem be that nitems is 257 and num_points is 512?  Or should
> nitems really be 256 and not 257?
>

I don't think so. I'm not familiar with the details of the fft_filter
implementations, but usually these things will take in some history if they
don't have enough points to operate on (in this case 512).

The much more worrying thing is your vector addresses.


>
> Thanks,
> Devin
>
> (gdb) bt
> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (__P=0x3b051b0)
> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> #1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
>

0x3b1f770 % 32 = 16 (bad)
0x3b051b0 % 32 = 16 (bad)
0x3b240e0 % 32 = 0 (good)

Unfortunately it looks like volk_get_alignment is returning the wrong thing
or there's a bug in volk_malloc. Can you tell us what volk_get_alignment
returns? The easiest thing is probably to write a simple C program that
prints out the result (hmm, I should add that to volk-config-info). I'd
also like to know which volk_malloc implementation you're using.
Unfortunately I don't think we have an easy way to discover that (hmm,
something else that should be added to volk-config-info). I think the best
way might be to look at volk_malloc.c intermediate files after the
preprocessor has done its work.

If you want to move on while we figure this out then you can edit
~/.volk/volk_config and replace the avx2_fma with sse3 on the line that has
this kernel name on it.


> at
> /local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
> #2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
> at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
> #3  0x7fffd3f8e360 in gr::filter::kernel::fft_filter_ccc::filter(int,
> std::complex const*, std::complex*) (this=0x3b02f40,
> nitems=nitems@entry=257, input=input@entry=0x7fffc9cc7000,
> output=output@entry=0x3b36460)
> at /local_disk/gr_3.7.9_src/gnuradio/gr-filter/lib/fft_filter.cc:323
> #4  0x7fffd42910df in gr::digital::corr_est_cc_impl::work(int,
> std::vector >&, std::vector std::allocator >&) (this=0x3b01560, noutput_items=257,
> input_items=..., output_items=std::vector of length 1, capacity 1 = {...})
> at
> /local_disk/gr_3.7.9_src/gnuradio/gr-digital/lib/corr_est_cc_impl.cc:237
> #5  0x7fffdd064907 in gr::sync_block::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector
> >&) (this=0x3b015b8, noutput_items=, ninput_items=...,
> input_items=..., output_items=...) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/sync_block.cc:66
> #6  0x7fffdd02f70f in gr::block_executor::run_one_iteration()
> (this=this@entry=0x7fff83ffedb0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/block_executor.cc:438
> #7  0x7fffdd06da8a in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int)
> (this=0x7fff83ffedb0, block=..., max_noutput_items=) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
> #8  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
> #9  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
> #10 0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&)
> (function_obj_ptr=...) at
> /usr/include/boost/function/function_template.hpp:153
> #11 

Re: [Discuss-gnuradio] GSOC 2016 - Cyclostationary Tools

[West, Nathan]

Hi,

To make a really good proposal for this you're going to have to come up
with the specifics on your own. Once you have those in mind feel free to
write them up in to a draft proposal for comment.

What cyclostationary algorithms are you interested in working on? Do you
want a particular visualization to be added?

In your other thread you mention interest in signal intelligence as well.
These two projects are pretty similar, so you clearly have a general idea
of your interests. Perhaps you don't have a specific algorithm in mind, but
you have an application. If you tell us about that maybe that can turn in
to your project or people can suggest algorithms.

Nathan

On Tue, Mar 8, 2016 at 10:20 AM, Ilie-Ablachim Denis 
wrote:

> Hi,
>
> My name is Ilie-Ablachim Constantin-Denis and I am a 3rd year student in
> Automatic Control and Computer Science at Politehnica University of
> Bucharest. I am really interested on working with this organization for the
> "Cyclostationary Tools" project.
>
> I am an Undergraded Teaching Assistant at my university, teaching "Signal
> ans Systems" and "Automated System Theory". I have strong knowledge in
> signal and image processing.
>
> I also improved in the past 7 years my skill in programming, especially:
> C/C++ and Matlab and developed for a research center from my university
> some applications in : face detection, face recognition, based on signal
> processing.
>
> I would be more than happy to work on this project or even submit a demo
> or patch for my future proposal assestment. Also I started doing research
> on this project, but I would really appreciate if you could give me some
> extra documentation and information on this.
>
> Thank you in advance!
>
> Yours sincerely, Ilie-Ablachim Constantin-Denis.
>
>
> ___
> 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] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

On Mon, Mar 7, 2016 at 10:18 PM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> On Mon, Mar 7, 2016 at 2:32 PM, devin kelly <dwwke...@gmail.com> wrote:
>
>> Hello,
>>
>> I've built a flowgraph (grc, python attached) that usually (but not
>> always) produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma.  The
>> segfault occurs in the FFT filter in correlation estimator block.  I'm not
>> sure if it's the Volk code that's causing the segfault or the GR code
>> calling it or what I'm putting into GR.  I've got a back trace below if
>> that helps.
>>
>> Also, at the tag gate in my flowgraph I would usually have a USRP
>> transmitter and a USRP receiver in a before the Correlation Estimate in a
>> separate flowgraph but since I can re-create the segfault in the flowgraph
>> I simplified.
>>
>> I'm using GR 3.7.9, Volk 1.2.1 and UHD 3.9.2 (though I don't call any UHD
>> code here).
>>
>> Thanks for any help,
>> Devin
>>
>> $ gdb /usr/bin/python core.13408
>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/bin/python2.7...Reading symbols from
>> /usr/bin/python2.7...(no debugging symbols found)...done.
>> (no debugging symbols found)...done.
>>
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>> Core was generated by `python2 ./segfault_test.py'.
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () from
>> /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
>> Missing separate debuginfos, use: debuginfo-install
>> python-2.7.5-34.el7.x86_64
>> (gdb) bt
>> #0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () at
>> /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
>> #1  0x7f119c1d0006 in gr::filter::kernel::fft_filter_ccc::filter(int,
>> std::complex const*, std::complex*) ()
>> at /local_disk/gr_3.7.9/lib64/libgnuradio-filter-3.7.9.so.0.0.0
>> #2  0x7f119c4d724f in gr::digital::corr_est_cc_impl::work(int,
>> std::vector >&, std::vector<void*,
>> std::allocator<void*> >&) () at
>> /local_disk/gr_3.7.9/lib64/libgnuradio-digital-3.7.9.so.0.0.0
>> #3  0x7f11a52b1f57 in gr::sync_block::general_work(int,
>> std::vector<int, std::allocator >&, std::vector> std::allocator >&, std::vector<void*, std::allocator<void*>
>> >&) () at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
>> #4  0x7f11a527a6bd in gr::block_executor::run_one_iteration() () at
>> /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
>> #5  0x7f11a52baf60 in
>> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
>> at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
>> #6  0x7f11a52aebc1 in
>> boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper,
>> void>::invoke(boost::detail::function::function_buffer&) () at
>> /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
>> #7  0x7f11a5260910 in
>> boost::detail::thread_data<boost::function0 >::run() ()
>> at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
>> #8  0x7f11a40b824a in thread_proxy () at
>> /lib64/libboost_thread-mt.so.1.53.0
>> #9  0x7f11bfa38dc5 in start_thread () at /lib64/libpthread.so.0
>> #10 0x7f11bf05d28d in clone () at /lib64/libc.so.6
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> I couldn't reproduce this on my machine with avx2. Your GRC flowgraph
> didn't draw anything, so I replaced your FG with random source(0,255) ->
> const. modulator -> correlation est -> sinks.
>
> I'm wondering if a bad vector length is getting passed in by accident. Can
> you get the parameters to the VOLK call when it crashes? If you're not
> familiar with gdb do something like the following:
> gdb> f 0
> gdb> info variables
>


Also, I'd like to know what processor you have. I don't think it has
anything to do with this bug, but my processor (i7-4700MQ) doesn't
generally see much benefit from AVX much less AVX2. What were the times
volk_profile gives you for this kernel? (use volk_profile -R
32fc_x2_multiply)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

On Mon, Mar 7, 2016 at 2:32 PM, devin kelly  wrote:

> Hello,
>
> I've built a flowgraph (grc, python attached) that usually (but not
> always) produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma.  The
> segfault occurs in the FFT filter in correlation estimator block.  I'm not
> sure if it's the Volk code that's causing the segfault or the GR code
> calling it or what I'm putting into GR.  I've got a back trace below if
> that helps.
>
> Also, at the tag gate in my flowgraph I would usually have a USRP
> transmitter and a USRP receiver in a before the Correlation Estimate in a
> separate flowgraph but since I can re-create the segfault in the flowgraph
> I simplified.
>
> I'm using GR 3.7.9, Volk 1.2.1 and UHD 3.9.2 (though I don't call any UHD
> code here).
>
> Thanks for any help,
> Devin
>
> $ gdb /usr/bin/python core.13408
> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/bin/python2.7...Reading symbols from
> /usr/bin/python2.7...(no debugging symbols found)...done.
> (no debugging symbols found)...done.
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `python2 ./segfault_test.py'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () from
> /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
> Missing separate debuginfos, use: debuginfo-install
> python-2.7.5-34.el7.x86_64
> (gdb) bt
> #0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () at
> /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
> #1  0x7f119c1d0006 in gr::filter::kernel::fft_filter_ccc::filter(int,
> std::complex const*, std::complex*) ()
> at /local_disk/gr_3.7.9/lib64/libgnuradio-filter-3.7.9.so.0.0.0
> #2  0x7f119c4d724f in gr::digital::corr_est_cc_impl::work(int,
> std::vector >&, std::vector std::allocator >&) () at
> /local_disk/gr_3.7.9/lib64/libgnuradio-digital-3.7.9.so.0.0.0
> #3  0x7f11a52b1f57 in gr::sync_block::general_work(int,
> std::vector&, std::vector std::allocator >&, std::vector
> >&) () at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
> #4  0x7f11a527a6bd in gr::block_executor::run_one_iteration() () at
> /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
> #5  0x7f11a52baf60 in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
> at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
> #6  0x7f11a52aebc1 in
> boost::detail::function::void_function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&) () at
> /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
> #7  0x7f11a5260910 in
> boost::detail::thread_data::run() ()
> at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
> #8  0x7f11a40b824a in thread_proxy () at
> /lib64/libboost_thread-mt.so.1.53.0
> #9  0x7f11bfa38dc5 in start_thread () at /lib64/libpthread.so.0
> #10 0x7f11bf05d28d in clone () at /lib64/libc.so.6
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
I couldn't reproduce this on my machine with avx2. Your GRC flowgraph
didn't draw anything, so I replaced your FG with random source(0,255) ->
const. modulator -> correlation est -> sinks.

I'm wondering if a bad vector length is getting passed in by accident. Can
you get the parameters to the VOLK call when it crashes? If you're not
familiar with gdb do something like the following:
gdb> f 0
gdb> info variables
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSoC 2016 Application Request with Theme: Burst Radio Support with Tim O'Shea

[West, Nathan]

Hi Daniel,

Glad to hear of your interest. Do you have a particular burst modem
standard you'd like to work on? Tell us about it and how you might make a
mod/demod chain in GNU Radio. It doesn't have to be perfect and you'll
likely get some feedback to improve your application.

I also suggest taking a look at the linked github branch and what new
features it adds to GNU Radio that make bursty modems less awkward.

-nw

On Fri, Mar 4, 2016 at 10:07 PM, Daniel Ndzo  wrote:

> Hi
> I'm Daniel Ndzo
>
> Freenode : DanielNdzo
>
> I'm a 4th year computer engineer with skills in telecommunications from
> the Faculty of Engineering and Technology, University of Buea, Cameroon.
> Went through software development related courses within the first and
> second years, then switched to telecommunications in the third year. I have
> worked on arduino and FTDI based projects, windows app projects and web app
> projects.
>
> Was nominated for an arduino-based project (
> innovation.cm/index.php/preselection); item number 7 .
>
> Sole Developer of GREENWING.(a cost free communication system using LoRa
> technology). Link:
> https://drive.google.com/file/d/0B2S90x7jXOF9WUVBSEh1YldkMXc/view?usp=sharing
>
> Though the GREENWING software was written in C#, C and C++ are languages I
> hve worked with.
>
> Also developed a web app for NEHSUFOODS(nehsufoods.orgfree.com); see home
> page bottom for developer/webmaster contact link.
>
> I consider a computer engineer as not only a software developer, but a
> hardware developer as well. reason for which I switched to
> telecommunications to broaden my scope of notion
>
> As i request to work on the  Burst Radio Support project  mentored by Mr.
> Tim O'Shea
> I will appreciate any response of  any form
>
> Thanks
>
> Daniel
>
> ___
> 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] GSoC 2016 - Improve and Integrate PyBOMBS & CGRAN

[West, Nathan]

Hi Ravi,

I like this. My only qualm is that I'd personally like this project to
include some more pybombs work to round out the still missing features. I'm
not really a Qt person, so I don't know how much effort doing the app store
is and if that leaves much room, but I know that the CGRAN stuff won't take
you all summer if you work full time ;-)

nw

On Mon, Mar 7, 2016 at 5:40 AM, Ravi Sharan <
bhagavathula.ravisha...@gmail.com> wrote:

> Hello,
>
> I am Ravi Sharan, currently pursuing MTech from IIT Hyderabad. I am
> looking forward to participate in GSoC 2016 by improving and integrating
> CGRAN and the newer PyBOMBS. I have earlier worked on redesigning the
> current version of CGRAN with the help of Nathan West. Here's a brief
> description of things I would like to contribute to the GNU Radio project:
>
> *- Qt based GUI app store - *
> Develop a simple, usable Qt based GUI app store to install GNU Radio and
> OOT modules. This sub-idea covers fixing the existing bugs in new PyBOMBS
> as well.
>
> *- Integrate PyBOMBS & CGRAN -* Enable installing OOT modules from CGRAN
> site
> This is an idea which Martin Braun put forward during the initial
> discussions while developing the CGRAN 2.0. The idea is similar to Ubuntu's
> AptURL , where you can install
> the packages from a web browser. Clicking the 'apt' (#pun) URL, the browser
> redirects to the package manager to install the package.
>
> *- Enhance CGRAN  -* (from current level to level awesome?)
> I intend to implement this sub-idea in two-fold -
> *** Add features like clickable tags and grouping the OOT Modules (to
> name a few) etc., according to their functionality for better usability of
> the site. [Code Contributions]
> *** Since the relaunch of CGRAN in April 2015, very few OOT Modules have
> surfaced on the site. I would like to add more documentation to the
> individual modules (like what works and what doesn't, compatibility with
> the current GNU Radio API, etc.,), thus populating CGRAN with modules
> listed out on the site. This idea is more of documentation, but is a little
> time consuming.
>
> I will document the above mentioned ideas in the form of proposal based on
> the feedback I receive and would like to work with Martin Braun and Nathan
> West during the GSoC period. Apart from the ideas listed above, I am open
> for suggestions on what could make a good proposal and better summer of
> coding.
>
> Thanks,
> Ravi Sharan B A G
>
> ___
> 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] GSoC Interest in Project: Offline Analysis and Visualization Tools

[West, Nathan]

Hi Usman,

Since you've been using GNU Radio for 3 years now and you have an interest
in this project hopefully you have some offline tools that you personally
want to see or personal issues with the current offline tools. Perhaps you
can explain those a little bit along with some general approaches to how
you would do it. This might spark an interesting conversation here that
would refine your application. As an example, say you're looking at some
signal in this offline tool and you want to apply a filter to it and see
what happens. What do you imagine is required to do this both from a
behind-the-scenes perspective and from a user perspective?

Don't feel restricted to answering my specific question. Pick whatever
visualization/analysis is most interesting to you and publicly brainstorm.
Someone will probably have commentary or feedback on it.

Cheers,
Nathan

On Sat, Mar 5, 2016 at 1:13 AM, Usman Haider 
wrote:

> Hi,
>
> After going through all the GSoC project ideas and relevant GSoC pages. I
> concluded that I should apply for the following project because it matches
> my skills most. In this way, I can make my contribution to GnuRadio
> maximum.
>
>
>
> *Offline Analysis and Visualization Tools ( Mentor Tim O'Shea)*
>
> I know C++, Python, and QT, so I fulfill the prerequisite criteria. I am
> using Gnuradio for more than 3 years now. I am on mailing  list (Bob) since
> quite some time. As a first step I made my account on github.
>
> https://github.com/UHaider/hello-world
>
> Next, I am going to work on my application/proposal. I'll keep visiting
> mailing list and GSoC pages so that I do not miss anything.
>
> Regards,
> Usman
>
>
>
> ___
> 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] Using volk kernels on basic operations of gr_complex, in my own custom blocks.

[West, Nathan]

I don't find valgrind useful for profiling speed because it is pretty
invasive (I actually love it as a tool, just not for this use and maybe I'm
using it wrong). People have done stuff with oprofile before... results are
overall pretty similar to what you get with linux perf tools, and (I think)
it's mostly a matter of opinion.

On Mon, Mar 7, 2016 at 4:30 PM, Gonzalo Arcos <gonzaloarco...@gmail.com>
wrote:

> Thanks for your answer.
>
>  I installed perf top but i am not sure how to use it.. I will investigate
> it. However, does the program need to be compiled in debug mode for the
> performance counters to have effect?
>
> As a side question... Has anyone managed to profile a gnuradio application
> with valgrind / oprofile? I am very interested in getting this to work,
> since when i tried profiling it with those tools, and then opening
> KCacheGrind, the displayed graph did not contain information about each
> block, let alone functions inside blocks. It has been several months since
> i tried this, but i remember that the result was like 99.9% of the time
> running the start() function of the block, and i could not get any more
> information than that, which of course was not helpful at all.
>
>
>
>
> 2016-02-29 6:28 GMT-03:00 West, Nathan <n...@ostatemail.okstate.edu>:
>
>> It won't give you time spent, but 'perf top' is a nice tool that gives
>> function-level performance counters for all running code. It comes with
>> linux-tools and uses performance counters built in to the kernel. There's
>> also a couple of other perf subtools you can explore.
>>
>>
>> Regarding your full buffers, I think that's a result of GNU Radio's
>> scheduler.
>>  If you have a flowgraph with A->B and B takes a very long time to
>> process all of its samples then A will always have full output buffers
>> since it operates much faster. It's not necessarily bad or cause for
>> concern, but performance improvements should focus on B.
>>
>> -nathan
>>
>> On Sun, Feb 28, 2016 at 10:48 PM, Gonzalo Arcos <gonzaloarco...@gmail.com
>> > wrote:
>>
>>> Thanks to all of you for your very informative answers.
>>>
>>> Douglas, i feel good now because you have described perfectly all the
>>> things i did / thought on how to improve the performance :), i also agree
>>> that merging blocks should be a last time resort. I have used the
>>> performance monitor and managed to improve the perofrmance of the most
>>> expensive blocks. What i could not achieve though, is profiling the program
>>> with a mainstream profiler, like valgrind or oprofile, or some other
>>> profilers for python. I remember than when visualizing the data, all the
>>> time was spent in the start() of the top block, and i could not get
>>> information pertaining each blocks general work, let alone functions
>>> executed within the block. After discovering the performance monitor, i
>>> used it in conjuntion with calls to clock() to determine the time spent in
>>> each function within each block, to get a rough measurement. But if it is
>>> possible to get this information automatically, i am very interested in
>>> learning how to do it. Could you help me?
>>>
>>> There is also another interesting aspect of improving performance, which
>>> is blocks being blocked due to the output buffer being full. Ive tried
>>> playing around a bit with the min and max output buffer sizes, but the
>>> performance did not seem to be affected.
>>> After using the performance monitor to analyze the buffer average full
>>> %, i see that most of them are relatively full, however, i do not know if
>>> they are full enough to make an upstream block to have to wait to push data
>>> into the buffer.
>>>
>>>
>>> 2016-02-28 19:39 GMT-03:00 Douglas Geiger <doug.gei...@bioradiation.net>
>>> :
>>>
>>>> The phenomenon Sylvain is pointing at is basically the fact that as
>>>> compilers improve, you should expect the 'optimized' proto-kernels to no
>>>> longer have as dramatic an improvement compared with the generic ones. As
>>>> to your question of 'is it worth it' - that comes down to a couple of
>>>> things: for example - how much of an improvement do you require to be
>>>> 'worth it' (i.e., how much is your time worth and/or how much of an
>>>> performance improvement do you require for your application). Similarly, is
>>>> it worth it to you to get cross-platform improvements (which is one of the
>>>> features of VOLK)? Or, pe

Re: [Discuss-gnuradio] Speed Optimization and Application for ATSC Receivers

[West, Nathan]

I think that's a result of those add blocks being used in trellises (could
be wrong on that assumption).

If we add saturating adds we should follow most architecture conventions
and explicitly call it saturating.

On Sunday, March 6, 2016, Andy Walls <a...@silverblocksystems.net> wrote:

> On Sun, 2016-03-06 at 16:33 -0500, West, Nathan wrote:
>
>
>
> > By the way, if you choose to do this please don't be afraid to ask
> > questions; this is a pretty well defined problem, but [...]
>
> Hi Nathan,
>
> Since you mentioned it, a question popped to my mind:
>
> The current add_const blocks let integer overflow happen, so that
> integer numbers wrap around.  In DSP, saturation math is often what is
> desired, not overflow. We'd rather the numbers clip at the max or min
> value, rather than experience some huge jump.  SIMD instruction sets
> provide instructions that perform saturation math, e.g. the MMX
> intrinsic __m64 _m_paddsw(__m64 a, __m64 b) for adding 4 sets of 16 bit
> integers.
>
> Should the new volk routines, meant to speed up the integer version of
> add_const blocks, perform saturation math, or stick with the current
> overflow behavior?
>
> > Cheers,
> >
> > Nathan
>
> Regards,
> Andy
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Speed Optimization and Application for ATSC Receivers

[West, Nathan]

Hi Josh,

Glad you're interested in GSoC and GNU Radio.  These suggestions from Andy
are pretty good, and any work that you've done on or with GNU Radio by the
time we make decisions definitely improves the credibility and strength of
your application (that's true for *all* students by the way... it really
helps to show us that you've done *anything* with GNU Radio). Now I will
add some commentary :-).

Valgrind is a really fantastic debugging tool, but I've found it to be
mostly useless for performance profiling (maybe I'm using it wrong and
someone can school me) because it runs everything in this slow environment
that traces all memory accesses and whatever else valgrind does. oprofile
is pretty good, but I'm a huge fan of the perf-tools that come with the
kernel like perf top and perf record.

On Sun, Mar 6, 2016 at 4:08 PM, Andy Walls 
wrote:

> On Sun, 2016-03-06 at 08:49 -0500, discuss-gnuradio-requ...@gnu.org
> wrote:
> > Message: 5
> > Date: Sun, 06 Mar 2016 06:45:13 + (GMT)
> > From: Joshua Lilly
>
>
> > Hello,
> > My name is Josh and I am interested in getting involved in GNU radio.
> > Specifically, I would like to work on the above project idea for
> > google summer of code 2016 by implementing Viterbi and demux
> > algorithms in volk and testing the speed improvements. I have
> > experience with python, c/c++, boost, and profiling with valgrind. I
> > currently have read the getting involved page, compiled the code, I am
> > working my way through some of the tutorials, and I have read through
> > the code in volk. Even if I don't get accepted to google summer of
> > code, I would still like to get involved in fixing bugs, or something
> > since this seems like a really awesome project.
>
> 4. Create volk kernels to replace the main operations in the work()
> functions of these blocks, if you can.  Since adding a constant is so
> simple, and ORC is very good about optimizing simple things, the volk
> implementations should include an ORC implementation if possible.  Odds
> are the ORC implementation will beat hand-written SIMD versions for x86
> processors.  Use volk_profile to prove my guess about ORC right or
> wrong. :)
>

I disagree to that point that the next time ORC makes me sad I'm going to
rage-delete it from ORC (kidding). It's an OK starting point for some
kernels, but comes with it's own learning curve on top of everything else
in VOLK.


>
>
> 5. Create volk-ized versions of the add_const blocks and remeasure their
> performance.  How much improvement did you get?
>
>
> 6. Don't forget to add QA tests for the new volk functions.
>
>

> As an alternate to the above:
>
> 1. Improve the performance of the nlog10_ff block by using log2,
> algebra, volk, and skipping the add of k at the end, if k == 0.0.
>
> 2. Create a new approx_nlog10_ff block by taking advantage of the fact
> that the log2 exponent in IEEE floats can be obtained with a mask and
> shift operation.  Don't forget to add a GRC .xml file for the block and
> QA test code.
>
> Regards,
> Andy
>

By the way, if you choose to do this please don't be afraid to ask
questions; this is a pretty well defined problem, but also very dense with
GNU Radio and VOLK assumed knowledge (it's sometimes hard to talk about
such things without doing this). Take a look at the VOLK docs, especially
the top-level pages, to get started http://libvolk.org/doxygen/index.html

Also, now that I mention that link, I noticed a very simple bug! The polar
{de,en}coder kernels didn't get listed in the kernels page so they show up
in the top level page listing.

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

Re: [Discuss-gnuradio] Pybombs 2.0 woes

[West, Nathan]

On Sat, Mar 5, 2016 at 10:45 AM, Marcus Müller 
wrote:

> Hi Mike,
>
> Following advice here I descended down a rabbit hole and tried to start
> again “pip uninstall pybombs”. Pip was not found.
>
> Uninstalling pybombs via pip only makes sense if you've installed it via
> pip ("pip install pybombs"). Seemingly, you've either gotten PyBombs
> through different means, so investigating pip doesn't really make sense, or
> something uninstalled pip after you've installed it, and installed Pybombs
> with it. That would be strange.
>

I don't think that's true. It's unintuitive, but pip is the generally
accepted way to uninstall anything installed through setup.py. See
http://stackoverflow.com/questions/1550226/python-setup-py-uninstall


> That has fixed the pip problem but not the UHD installation crash, but as
> a by product the error messages have become more verbose – and guess what?
> The problem is an undeclared type. *THIS SAME ISSUE WITH UNDEFINED TYPES*
> (shout so it sinks in, then repeat because it didn’t) *THIS SAME ISSUE
> WITH UNDEFINED TYPES*  that has been around for over a YEAR in UHD and in
> this case rx_dsp_core_200.cpp.
>
> There is no such issue I know of. Now, that doesn't mean there's no issue,
> it just means that none of the other users I've talked to nor myself
> encountered it. However, probabilistically speaking, that's indicative of
> something being wrong with your system...
>
> Every so often I point it out and someone fixes it and later on someone
> else (I wonder if this is the same person who broke it last time) then adds
> some new code somewhere else recreating the same errors. In this case its
> uintptr_t that is not declared.
>
> Um, sorry, I don't even see uintptr_t in rx_dsp_core_200.cpp, and I've
> searched through its file history: It never occurred there. So to research
> this issue, I'll need your full "make" output. Maybe your version of Ubuntu
> fell off the testing bandwagon: which version of Ubuntu are you using?
>
> A good motto is to assume nothing and please make sure you declare
> everything.
>
> uintptr_t is a standard type. See "man stdint.h".
>
>
Looks potentially familiar... Two things might be going on. 1) If you have
a UHD installed and the current build picks up on it things might get messy
in non-intuitive ways. Make sure you remove any stray UHD installations.
That seems likely in this case. 2) There's a similar issue with some
versions of glibc and boost. See
https://github.com/gnuradio/gr-recipes/pull/4#issuecomment-181188909 (seems
unlikely in this case). BTW, if you see a problem in the code that keeps
coming back you don't have to wonder who does it... you can use git to
know. Anyway, indeed without errors/build logs I'm not sure what you expect
anyone to do here.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using volk kernels on basic operations of gr_complex, in my own custom blocks.

[West, Nathan]

It won't give you time spent, but 'perf top' is a nice tool that gives
function-level performance counters for all running code. It comes with
linux-tools and uses performance counters built in to the kernel. There's
also a couple of other perf subtools you can explore.


Regarding your full buffers, I think that's a result of GNU Radio's
scheduler.
 If you have a flowgraph with A->B and B takes a very long time to process
all of its samples then A will always have full output buffers since it
operates much faster. It's not necessarily bad or cause for concern, but
performance improvements should focus on B.

-nathan

On Sun, Feb 28, 2016 at 10:48 PM, Gonzalo Arcos 
wrote:

> Thanks to all of you for your very informative answers.
>
> Douglas, i feel good now because you have described perfectly all the
> things i did / thought on how to improve the performance :), i also agree
> that merging blocks should be a last time resort. I have used the
> performance monitor and managed to improve the perofrmance of the most
> expensive blocks. What i could not achieve though, is profiling the program
> with a mainstream profiler, like valgrind or oprofile, or some other
> profilers for python. I remember than when visualizing the data, all the
> time was spent in the start() of the top block, and i could not get
> information pertaining each blocks general work, let alone functions
> executed within the block. After discovering the performance monitor, i
> used it in conjuntion with calls to clock() to determine the time spent in
> each function within each block, to get a rough measurement. But if it is
> possible to get this information automatically, i am very interested in
> learning how to do it. Could you help me?
>
> There is also another interesting aspect of improving performance, which
> is blocks being blocked due to the output buffer being full. Ive tried
> playing around a bit with the min and max output buffer sizes, but the
> performance did not seem to be affected.
> After using the performance monitor to analyze the buffer average full %,
> i see that most of them are relatively full, however, i do not know if they
> are full enough to make an upstream block to have to wait to push data into
> the buffer.
>
>
> 2016-02-28 19:39 GMT-03:00 Douglas Geiger :
>
>> The phenomenon Sylvain is pointing at is basically the fact that as
>> compilers improve, you should expect the 'optimized' proto-kernels to no
>> longer have as dramatic an improvement compared with the generic ones. As
>> to your question of 'is it worth it' - that comes down to a couple of
>> things: for example - how much of an improvement do you require to be
>> 'worth it' (i.e., how much is your time worth and/or how much of an
>> performance improvement do you require for your application). Similarly, is
>> it worth it to you to get cross-platform improvements (which is one of the
>> features of VOLK)? Or, perhaps, is it worth it to you just to learn how to
>> use VOLK?
>>
>> A couple of thoughts here: in general, when I have a flowgraph that is
>> not meeting my performance requirements, my first step is to do some course
>> profiling (i.e. via gr-perf-monitorx) to determine if there is a single
>> block that is my primary performance bottleneck. If so - that is the block
>> I will concentrate on for optimizations (both via VOLK, and/or any
>> algorithmic improvements - e.g. can I turn any run-time calculations into a
>> look-up table calculated either at compile-time, or within the constructor).
>>  If there is not a clear bottleneck, then next I look a little deeper
>> using perf/oprofile to look at what functions my flowgraph is spending a
>> lot of time in: can I e.g. create a faster version of some primitive
>> calculation that all my blocks use a lot, and therefore get a speed-up
>> across many blocks which should translate into a fast over-all application.
>>
>>  Finally, if I still need more improvements I would look at collecting
>> many blocks together into a single, larger block. This is generally less
>> desirable, since you now have a (more) application-specific block, and it
>> becomes harder to re-use in later projects, but if you have performance
>> requirements that drive you there, then it absolutely is an option. At this
>> point you likely have multiple operations being done to your incoming
>> samples, and it becomes easy to collect all of those into a single larger
>> VOLK call (and from there, create a SIMD-ized proto-kernel that targets
>> your particular platform). So, while re-usability of code drives you away
>> from this scenario, it offers the greatest potential for performance
>> improvements, and thus is where many applications with high performance
>> requirements tend to gravitate towards. Ideally you can strike a balance
>> between the two: i.e. have widely re-usable blocks, but with a set of
>> operations inside them that you can take advantage 

Re: [Discuss-gnuradio] Using volk kernels on basic operations of gr_complex, in my own custom blocks.

[West, Nathan]

On Sun, Feb 28, 2016 at 5:39 PM, Douglas Geiger <
doug.gei...@bioradiation.net> wrote:

> The phenomenon Sylvain is pointing at is basically the fact that as
> compilers improve, you should expect the 'optimized' proto-kernels to no
> longer have as dramatic an improvement compared with the generic ones. As
> to your question of 'is it worth it' - that comes down to a couple of
> things: for example - how much of an improvement do you require to be
> 'worth it' (i.e., how much is your time worth and/or how much of an
> performance improvement do you require for your application). Similarly, is
> it worth it to you to get cross-platform improvements (which is one of the
> features of VOLK)? Or, perhaps, is it worth it to you just to learn how to
> use VOLK?
>
> A couple of thoughts here: in general, when I have a flowgraph that is not
> meeting my performance requirements, my first step is to do some course
> profiling (i.e. via gr-perf-monitorx) to determine if there is a single
> block that is my primary performance bottleneck. If so - that is the block
> I will concentrate on for optimizations (both via VOLK, and/or any
> algorithmic improvements - e.g. can I turn any run-time calculations into a
> look-up table calculated either at compile-time, or within the constructor).
>  If there is not a clear bottleneck, then next I look a little deeper
> using perf/oprofile to look at what functions my flowgraph is spending a
> lot of time in: can I e.g. create a faster version of some primitive
> calculation that all my blocks use a lot, and therefore get a speed-up
> across many blocks which should translate into a fast over-all application.
>
>  Finally, if I still need more improvements I would look at collecting
> many blocks together into a single, larger block. This is generally less
> desirable, since you now have a (more) application-specific block, and it
> becomes harder to re-use in later projects, but if you have performance
> requirements that drive you there, then it absolutely is an option. At this
> point you likely have multiple operations being done to your incoming
> samples, and it becomes easy to collect all of those into a single larger
> VOLK call (and from there, create a SIMD-ized proto-kernel that targets
> your particular platform). So, while re-usability of code drives you away
> from this scenario, it offers the greatest potential for performance
> improvements, and thus is where many applications with high performance
> requirements tend to gravitate towards. Ideally you can strike a balance
> between the two: i.e. have widely re-usable blocks, but with a set of
> operations inside them that you can take advantage of e.g. SIMD-ized
> function calls to make them high-performance. If you can craft the block to
> be widely re-usable for a certain class of things (e.g. look at how the
> OFDM blocks are setup to be easily re-configurable for the many ways an
> OFDM waveform can be crafted). In the long-run having more knobs to turn to
> customize your existing code base to deal with whatever new scenario you
> are looking at in 1/2/10 years from now is always better than a brittle
> solution that solves today's problem, but is difficult to re-use to deal
> with tomorrow's.
>
> Hope that was helpful. If you are interested in learning more about how to
> use VOLK - certainly have a look at libvolk.org - the documentation is (I
> think) fairly good at introducing the concepts and intent, as well as how
> the API looks/works.
>

Aww, thanks :-)


> And certainly don't be shy about asking more questions here.
>
>  Good luck,
>   Doug
>
> On Sun, Feb 28, 2016 at 1:58 AM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> > Just wanted to ask the more experienced users if you think this idea is
>> > worth a shot, or the performance improvement will be marginal.
>>
>> Performance improvement is vastly dependent of the operation you're doing.
>>
>> You can get an idea of the improvement by comparing the volk-profile
>> output for the generic kernel (coded in pure C) and the sse/avx ones.
>>
>> For instance, on my laptop : for some very simple one (like float
>> add), the generic is barely slower than simd. Most likely because it's
>> so simple than even the compiler itself was able to simdize it by
>> itself.
>> But for other things (like complex multiply), the SIMD version is 10x
>> faster ...
>>
>>
>> Cheers,
>>
>>Sylvain
>>
>>
I agree with everything that's been said, but wanted to chime in with a
slightly different perspective.

Let's take an example of doing y[t] = sum(a[i]*x[t-i]). The first approach
will always be to write a loop to iterate over samples doing the point by
point multiply and add them up.


There's a couple of VOLK kernels that are "relevant" to this (Let's assume
everything is complex). You could do volk_32fc_x2_multiply_32fc(y, x, a,
i). Now you need to sum y. This is not going to be much better than not
using the VOLK call (depending on your compiler and CPU 

Re: [Discuss-gnuradio] FOSDEM videos

[West, Nathan]

On Tue, Feb 23, 2016 at 9:53 AM,  wrote:

> The videos of the FOSDEM talks are now available at
> https://video.fosdem.org/2016/aw1125/
>
> Status:
> OK: 'Building Self-Optimizing Radios using DEAP'
> OK: 'Embedded SDR'
> OK: 'News from the OAI Community'
> OK: 'Prototyping the 5G Air Interface in GNU Radio: An FBMC Primer'
> OK: 'Radio Machine Learning with FOSS'
> OK: 'RFNoC -- Evolving SDR toolkits to the FPGA platform'
> OK: 'SDR Track Panel'
> OK: 'srsUE: A high-performance software radio LTE UE'
> OK: 'Synchronization in distributed SDR for localization applications'
> OK: 'The GNU Radio Companion Changelog'
> OK: 'The rad1o badge'
> OK: 'Using Red Pitaya for radio applications (from LF to HF)'
> OK: 'Wideband measurement strategies: from RADAR to passive wireless
> sensors'
> PARTIAL: (no slides) 'Introduction to the SDR Track'
> PARTIAL: (no slides) 'The GNU Radio Toolkit'
> PARTIAL: 'Signal Intelligence Challenges'
>
> JM
>
>
Are these final?

Sebastian's talk (
http://bofh.nikhef.nl/events/FOSDEM/2016/aw1125/the-gnu-radio-companion-changelog.mp4)
has the wrong slides showing.

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

[Discuss-gnuradio] GNU Radio release v3.7.9.1 available

[West, Nathan]

GNU Radio release v3.7.9.1 and corresponding live SDR environment is now
available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9.1.tar.gz
http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9.1.tar.gz.asc
http://s3-dist.gnuradio.org/ubuntu-14.04.3-desktop-amd64-gnuradio-3.7.9.1.torrent

MD5 sums:

653155499bcefb1478b1963f11841434  gnuradio-3.7.9.1.tar.gz
d712141f1e11584a29566713a58c79a1
ubuntu-14.04.3-desktop-amd64-gnuradio-3.7.9.1.torrent

Contributors

The following list of people directly contributed code to this release. As
an added bonus this is the first contribution for three of these authors!

   - Andrej Rode m...@andrejro.de
   - Paul David puda...@fastmail.com
   - Derek Kozel derekko...@nameloop.com
   - Johannes Schmitz johannes.schmi...@gmail.com
   - Johnathan Corgan johnat...@corganlabs.com
   - Marcus Müller marcus.muel...@ettus.com
   - Martin Braun martin.br...@ettus.com
   - Philip Balister phi...@balister.org
   - Ron Economos w...@comcast.net
   - Sebastian Koslowski koslow...@kit.edu
   - Sylvain Munaut t...@246tnt.com
   - Tim O'Shea tim.oshea...@gmail.com
   - Tom Rondeau t...@trondeau.com

Closed issues

   - #528 
   - #719 
   - #768 
   - #831 
   - #864 
   - #868 
   - #876 
   - #879 
   - #882 
   - #883 

Code

This release includes a number of minor typos and miscellaneous rewording
of error messages. The following sections summarize substantial changes.
GRC

   - the 'Parser errors' menu item wasn't correctly enabled
   - embedded python blocks: message ports are now optionial and show the
   correct label
   - custom run command now accounts for filepaths that need escaping
   - virtual sink/source message connections were dropped when opening a
   flow graph
   - tooltips in block library are truncated if too long
   - not all tooltips in block library were updated after docstring
   extraction finished
   - some expressions were wrongfully marked invalid after opening a flow
   graph
   - move random uniform source from analog to waveform generators in GRC

Scheduler and Runtime fixes

A new unit test is available to test a bug reported on stack overflow where
blocks (such as the delay block) would drop tags. Paul David stepped in
with his first contribution to GNU Radio with a fix.

Fix an issue with flat_flowgraph calculating alignment by misinterpreting
units of write and read indices. This was only apparent when these indices
are non-zero (a flowgraph has stopped and restarted).

Fix exceptions thrown in hier_block2 constructors.

Check d_ninput_items_required for overflow and shut down if overflow is
detected.

Allow hier_block2's to change I/O signature in the constructor, which was
previously allowed by the API, but broken.
gr-blocks

Use unsigned char rather than char in add_const_bb. This was the legacy
behavior with the older add_const_XX and was accidentally replaced with
char when replacing the templated version.

Fix vector length units from bytes to number of items in PDU to tagged
stream and tagged stream to PDU blocks.
gr-filter

Add a check to the rational resampler to stop working after we've operated
on all input items (closed issue #831
)

Throw an error when pfb clock sync is given constant taps which results in
a derivative of 0 (calculated as NaN). (closed issue #812
 and 734). Added a reset_taps
function to externally set taps which should be used in place of set_taps

Fix a memory leak in pfb decimator (closed issue #882
)
gr-analog

Maximum Deviation parameter for NBFM transmitter exposed to GRC
gr-digital

Change the constellation receiver to inherit from control_loop publically
rather than the impl to better support the control port interface. (closed
issue #876 )
gr-fec

TLC to puncture/depuncture GRC files in gr-fec
gr-zeromq

Major performance and correctness fixes to gr-zeromq
Builds

Fix cross compiling on for 64-bit architectures by not setting DEBIAN,
REDHAT, and SLACKWARE. OOT modules created with modtool should update their
cmake/Modules/GrPlatform.cmake to support cross 64-bit builds.


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

Re: [Discuss-gnuradio] GNU Radio Architecture and Implementation ?

[West, Nathan]

On Wed, Feb 10, 2016 at 7:47 PM, Abhinav Jadon 
wrote:

> Hi ,
> I was reading up about the architecture of GNU Radio. Its primarily an
> inheritance based architecture, the blocks that pass data to other block
> are actually implemented as subclass and superclass pair. Am I right about
> this?
> Also whats the need for the flowgraph to be a subclass of the top_block.
> Also, whats the difference between top_block and block ?
>
> Regards
>
>
Someone may come and explain this better, but at a super high level there
are the following important classes: basic_block, block, hier_block2,
top_block. They all inherit from basic_block which provides an API for
message handling, input and output signatures, name, and some other core
features. From basic_block you can get a hier_block2 or a block.
hier_block2 mostly provides an API for connecting blocks. top_block
inherits from hier_block2 and provides start and stop functionality which
creates buffers and runs other blocks in the flow (blocks that have been
->connect()'ed).

On the other fork of basic_block you have block, which provides an API for
providing information about how this block likes to do work (alignment,
relative_rate, history, noutput_items, ninput_items, forecast and more) and
also contains the block_detail. All signal processing blocks inherit from
block and are connected in a flowgraph through a top_block. Signal
processing blocks could just inherit from block if they need some special
cases, but most of the time you want a sync_block, sync_interpolator,
sync_decimator which inherit from block and reduce some of the API for you
based on different assumptions of relative_rate that you provide.

These are somewhat advanced questions though, and probably working through
the tutorials, making flowgraphs, and writing blocks while reading the
doxygen manual make some of this more apparent.

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

Re: [Discuss-gnuradio] SIGSEGV in volk_32fc_x2_multiply_32fc_neon (was: running bastibl's IEEE802.11 in the USRP E310)

[West, Nathan]

On Mon, Feb 1, 2016 at 2:39 PM, Marcus Müller 
wrote:

> Hi Gabriel,
> aha! That's in GNU Radio's multiply block, using libVOLK, so this is
> something that we might actually hunt down.
> I remember there being awareness of a similar error not too long ago, put
> Philip Balister in CC:; he had a problem with the neonasm implementation of
> dot product, so he used neon instead.
>

https://github.com/gnuradio/volk/issues/25#event-351452447
relevant commit for multiply:
https://github.com/gnuradio/volk/commit/92a7251bc9b26ab7bd03cd4fbbd6ee2f0c6f3cef


>
> to help me debug this: the output of "volk-config-info -v --all-machines"
> would be helpful, and also whether "volk_config -b" runs (that will
> definitely take a while!) without segfault.
>

You may just be on an 'old' version of volk. If so either upgrade or set
volk_config appropriately.


>
> Best regards,
> Marcus
>
>
> On 01.02.2016 20:25, Gabriel Pechiarovich wrote:
>
> After receiving SIGSEGV, i've used backtrace and got this:
>
> Press Enter to quit:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x9a4ff460 (LWP 3392)]
> .tailcase ()
> at
> /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36
> 36 vld1.32d0, [r2]! @ s0, s1 = br, bi
> (gdb) backtrace
> #0  .tailcase ()
> at
> /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36
> #1  0xb6992774 in gr::blocks::multiply_cc_impl::work (this= out>,
> noutput_items=4096, input_items=..., output_items=...)
> at
> /usr/src/debug/gnuradio/3.7.7-r0/git/gr-blocks/lib/multiply_cc_impl.cc:60
> #2  0x9a4fede4 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
>
> 2016-02-01 14:18 GMT-05:00 Marcus Müller :
>
>> ah sorry, that was confusing:
>> after SIGILL, please "continue", untill you get SIGSEGV, then type
>> "backtrace".
>>
>> Best regards,
>> Marcus
>>
>>
>> On 01.02.2016 20:08, Gabriel Pechiarovich wrote:
>>
>> Hi, this is the full output:
>>
>>
>> set_min_output_buffer on block 10 to 96000
>> set_min_output_buffer on block 12 to 96000
>> set_min_output_buffer on block 14 to 96000
>> set_min_output_buffer on block 15 to 96000
>> set_min_output_buffer on block 18 to 96000
>> set_min_output_buffer on block 29 to 96000
>> [New Thread 0xa48e5460 (LWP 3255)]
>> [New Thread 0xa40e5460 (LWP 3256)]
>> [New Thread 0xa36ff460 (LWP 3258)]
>> [New Thread 0xa2eff460 (LWP 3257)]
>> [New Thread 0xa24ff460 (LWP 3259)]
>> [New Thread 0xa1cff460 (LWP 3260)]
>> [New Thread 0xa14ff460 (LWP 3261)]
>> [New Thread 0xa0cff460 (LWP 3262)]
>> [New Thread 0xa04ff460 (LWP 3263)]
>> [New Thread 0x9fcff460 (LWP 3264)]
>> [New Thread 0x9f4ff460 (LWP 3265)]
>> [New Thread 0x9ecff460 (LWP 3266)]
>> [New Thread 0x9e4ff460 (LWP 3267)]
>> [New Thread 0x9dcff460 (LWP 3268)]
>> [New Thread 0x9d4ff460 (LWP 3269)]
>> [New Thread 0x9ccff460 (LWP 3270)]
>> [New Thread 0x9c4ff460 (LWP 3271)]
>> [New Thread 0x9bcff460 (LWP 3272)]
>> [New Thread 0x9b4ff460 (LWP 3273)]
>> [New Thread 0x9acff460 (LWP 3274)]
>> [New Thread 0x9a4ff460 (LWP 3275)]
>> [New Thread 0x99cff460 (LWP 3276)]
>> [New Thread 0x994ff460 (LWP 3277)]
>> [New Thread 0x98cff460 (LWP 3278)]
>> [New Thread 0x984ff460 (LWP 3279)]
>> [New Thread 0x97cff460 (LWP 3280)]
>> [New Thread 0x974ff460 (LWP 3281)]
>> [New Thread 0x96cff460 (LWP 3282)]
>> [New Thread 0x964ff460 (LWP 3283)]
>> [New Thread 0x95cff460 (LWP 3284)]
>> [New Thread 0x954ff460 (LWP 3285)]
>> [New Thread 0x94cff460 (LWP 3286)]
>> [New Thread 0x944ff460 (LWP 3287)]
>> [New Thread 0x93cff460 (LWP 3288)]
>> [New Thread 0x934ff460 (LWP 3289)]
>> [New Thread 0x92cff460 (LWP 3290)]
>> [New Thread 0x924ff460 (LWP 3291)]
>> [New Thread 0x91cff460 (LWP 3292)]
>> [New Thread 0x914ff460 (LWP 3293)]
>> [New Thread 0x90cff460 (LWP 3294)]
>>
>> Press Enter to quit:
>> Program received signal *SIGSEGV*, Segmentation fault.
>> [Switching to Thread 0x9a4ff460 (LWP 3275)]
>> .tailcase ()
>> at
>> /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36
>> 36 vld1.32d0, [r2]! @ s0, s1 = br, bi
>>
>> (gdb) continue
>> Continuing.
>> [Thread 0x90cff460 (LWP 3294) exited]
>> [Thread 0x914ff460 (LWP 3293) exited]
>> [Thread 0x91cff460 (LWP 3292) exited]
>> [Thread 0x924ff460 (LWP 3291) exited]
>> [Thread 0x92cff460 (LWP 3290) exited]
>> [Thread 0x934ff460 (LWP 3289) exited]
>> [Thread 0x93cff460 (LWP 3288) exited]
>>
>> [Thread 0x93cff460 (LWP 3288) exited]
>> [Thread 0x944ff460 (LWP 3287) exited]
>> [Thread 0x94cff460 (LWP 3286) exited]
>> [Thread 0x954ff460 (LWP 3285) exited]
>> [Thread 0x95cff460 (LWP 3284) exited]
>> [Thread 0x964ff460 (LWP 3283) exited]
>> [Thread 0x96cff460 (LWP 3282) exited]
>> [Thread 0x974ff460 (LWP 3281) exited]
>> [Thread 0x97cff460 (LWP 3280) exited]
>> [Thread 0x984ff460 (LWP 3279) exited]
>> [Thread 0x98cff460 (LWP 3278) exited]

Re: [Discuss-gnuradio] Moving Average Block

[West, Nathan]

Chiming in that this is also a great opportunity to contribute improved
documentation after you've figured out your answer.

In addition to Marcus' comment, looking at the code helps (and in this case
is pretty easy):

   set_history(d_length);
  // skipping some stuff
  @I_TYPE@ sum = 0;
  int num_iter = (noutput_items>d_max_iter) ? d_max_iter :
noutput_items;
  for(int i = 0; i < d_length-1; i++) {
sum += in[i];
  }

  for(int i = 0; i < num_iter; i++) {
sum += in[i+d_length-1];
out[i] = sum * d_scale;
sum -= in[i];
  }

The first loop builds up an "initial" sum, the second loop does the grunt
work of generating output samples. You'll always get the sum of the last
n_length samples scaled by some factor (n_length for arithmetic mean).



On Thu, Jan 7, 2016 at 1:23 PM, Pedro Gabriel Adami <
pedrogabriel.ad...@gmail.com> wrote:

> Dear all,
>
> The documentation of the Moving Average block made me feel confuse about
> its functionality. It says: "output is the moving sum of the last N
> samples". If I need a sum of 100 samples, this block will sum the 100
> samples that I need and after that it will get another different samples?
> For example: 1+2+3+...+100 and 101+102+...200. Or it will do this:
> 1+2+...+100 and 2+3+...+101 and 3+4+...+102.
>
> I know it seems a little confuse, but I didn't find a better way to
> explain this, sorry.
>
> Thanks in advance.
>
> --
> Atenciosamente,
> Pedro Gabriel Adami
> Graduando do 5º período de Engenharia de Controle e Automação no Instituto
> Nacional de Telecomunicações - Inatel
>
> ___
> 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] GNU Radio Release v3.7.9

[West, Nathan]

GNU Radio releases v3.7.9 and v3.7.8.2 are available for download.
Tarball (and PGP signature):
http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9.tar.gz
http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9.tar.gz.asc

Md5sum:

bf1a2abd0abc492c7f67cba1080ceb8c  gnuradio-3.7.9.tar.gz

A corresponding Live DVD Environment is available. For information please
see:

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD

Release notes for GNU Radio are available below:

Contributors

   - Bill Clark 
   - Bogdan Diaconescu 
   - Chris Kuethe 
   - Doug Geiger 
   - Eric Statzer 
   - Felix Wunsch 
   - Glenn Richardson 
   - Jiří Pinkava 
   - Johannes Demel 
   - Johannes Schmitz 
   - Johnathan Corgan 
   - Marcus Müller 
   - Martin Braun 
   - Matt Ettus 
   - Mike Walters 
   - Paul David 
   - Ron Economos 
   - Sebastian Koslowski 
   - Seth Hitefield 
   - Stefan 
   - Tom Rondeau 
   - Tracie Perez 


Major Changes

The git log is always the authoritative list of changes, but the following
provides a high level overview of major changes since v3.7.8 (excluding
changes already included in maintenance releases). v3.7.9 introduces
improved documentation, new features, and a few examples. The bulk of
features revolve around message passing and integrating message ports with
Control Port.

GNU Radio Companion

GRC changes improve start-up time and flowgraph loading by asynchronously
reading block docstrings. Loading flowgraphs with missing hier_blocks
results in auto-generated hier_blocks so the top-level flowgraph remains
viewable.

GRC menus are slightly reorganized to include submenus for new and recently
used flowgraphs. A new option to include custom run commands (which is
intended to assist remote deployments and starting applications related to
a flowgraph) is available. A new easter egg in the menus will display
flowgraph-complexity in Balints.

The GRC file format includes the following improvements:
- select default and per-flowgraph QSS themes for QT GUI.
- embedded python blocks: create and edit Python Blocks straight from
GRC using your favorite editor. Automatic wrapper generation. Stored in
the grc file.
- grc file format: minimizes diffs when changing flowgraphs
- embedded python modules: save custom python code directly in grc files
and edit it directly from grc.

Analog

New uniform integer distribution source Added a new message port to the
signal source to change frequency tag propagation fix with QA
Add complex matrix multiply block.
New Complex to Imaginary char block (complex to IChar) with GRC support
Add blocks to convert between complex representations and magnitude/phase
representations

DTV

A new DVB-T receiver flowgraph is available in tree. DVB-T is widely used
in European television broadcasts. gr-dvt also saw major work on resolving
coverity issues.

FEC

GNU Radio participated in the ESA SoC with Johannes Demel implementing
polar codes. This work has been merged in and uses Johannes' VOLK kernels
to accelerate en/decoding.
Tracie has continue work on LDPC codes from GSoC 2013. Much of the work in
this release has been examples and improved documentation.

FFT

Windowing operations in fft_vcc_fftw were replaced with VOLK calls for
improved performance.

Filter

The center frequency message port handles a dict as well as the pair that
currently used pair which matches conventions used in other message
handlers.

QT-GUI

Expose trigger callbacks for GUI sinks to GRC.
Add a Qt style sheet for projectors and presentations as well as better
color scaling and better coloring in general for sharing plots.
QT GUI plotting widgets have added support for control and data message
ports. The GUIs can only plot data from messages or streams, but not both
at once. These come with documentation and an example in
gr-qtgui/examples/qtgui_message_inputs.grc
Documentation
Added documentation for quadrature demod blocks and exposed through GRC.
ControlPort

Expose constant parameter of the multiply_const_ff and add_const_XX blocks
through control port. As part of this the add_const_XX blocks are now
implemented separately rather than templates.

Message Handlers are now all exposed through ControlPort which allows
passing arbitrary messages in to a flow graph through ControlPort. For an
example see gr-blocks/examples/ctrlport/simple_copy.grc and
gr-blocks/examples/ctrlport/usrp_source_controller.py
ackRegister the average throughput performance counter.

gr-uhd

Rearranged tabs for USRP blocks in 

Re: [Discuss-gnuradio] [VOLK] GPU acceleration -> OpenCL integration?

[West, Nathan]

Hi Stefan,

First of all I'm really happy to see this done. Using opencl in VOLK has
come up once in a while and the general consensus was that transport /
granularity of work in VOLK would not make it worth doing in VOLK, but we
never knew for sure.

Another wrinkle is where that tradeoff between GPUs and processor work is
for each pair of processor and GPU which is impossible to know without some
kind of benchmark/wisdom generation. VOLK doesn't have any mechanism for
doing that and recording it. It's interesting work if that's what you're
looking to do.

>From a VOLK perspective if we can build up that wisdom ability and add that
ability to a dispatcher it's probably going to be useful, especially for
people that are developing some opencl code in a workflow, but don't know
for sure where code should run. I think the best way to develop this might
be in a VOLK OOT unless you're fine working off a long-lived branch looking
at this stuff.

I'm happy to continue discussing this, especially on the list

Nathan


On Thu, Dec 17, 2015 at 8:53 PM, Douglas Geiger <
doug.gei...@bioradiation.net> wrote:

> Stefan,
>  First off I definitely want to encourage investigations of this sort: so
> even though I have some thoughts similar to Sylvains/Tom's about whether
> VOLK is the right place to do this, I definitely want to encourage *trying*
> this, since you never know - we could be entirely wrong about whether or
> not this will work. The only way to know for sure is to try it.
>
>  That said: I do think there are way *within* VOLK to deal with the issue
> of the input size (i.e. vector size) having a large impact on performance -
> namely the custom dispatcher. This is a concept that exists in VOLK, but
> has larger gone unnoticed because by in the large the default dispatcher
> does a good (or at least, good-enough) job at selecting the proper
> proto-kernel. For off-loading concepts such as utilizing GPU's via OpenCL,
> a custom dispatcher *could* select the appropriate proto-kernel (including
> directing the OpenCL implemention to select a CPU vs. GPU-based
> implementation, if multiple OpenCL implementations are available) on a
> per-'work()' call from the GNURadio scheduler. In other words, instead of
> relying on volk_profile to select the best proto-kernel for all calls to
> that particular volk kernel, the dispatcher could have something more akin
> to the FFTW 'wisdom' where for different sizes of matrices/vectors,
> different proto-kernels are called (including the CPU SIMDized call,
> instead of the OpenCL call for smaller input sizes, etc.).
>
>  Anyways - I definitely think this is something that should be looked into
> more, and if you are interested in pursuing this as - either as a GSoC
> project or otherwise, I would definitely encourage it, as well as offer
> assistance/advice where I can.
>
>  Doug
>
>
> On Thu, Dec 17, 2015 at 7:58 PM, Stefan Wunsch <
> stefan.wun...@student.kit.edu> wrote:
>
>>
>>
>> On 12/18/2015 12:30 AM, Tom Rondeau wrote:
>> > On Thu, Dec 17, 2015 at 1:14 PM, Sylvain Munaut <246...@gmail.com>
>> wrote:
>> >
>> >> Hi,
>> >>
>> >>> RUN_VOLK_TESTS: volk_32f_x2_matrix_nxn_multiply_puppet_32f(100,10)
>> >>> generic completed in 28482ms
>> >>> a_opencl completed in 13364.3ms
>> >>
>> >> Question is how does that number change for smaller problem sizes ?
>> >> And what would be the average problem size encountered in real env.
>> >>
>> >> For SIMD optimization the result of "who's the fastest" doesn't vary
>> >> too much depending on problem size because they don't have much setup
>> >> / teardown size.
>> >> For OpenCL I very much doubt that would be the case and if you end up
>> >> with an app making a lot of "smallish" (and given the default buffer
>> >> size of GR, I feel the calls to volk aren't processing millions of
>> >> samples at a time in a single call)
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> Sylvain
>> >>
>> >
>> >
>> > Stefan,
>> >
>> > This is a great start. But Sylvain makes good points about the data
>> > transfer issue. That's definitely a problem we have to think about. It's
>> > why we have avoided pursuing GPU support in VOLK in the past. Now, if
>> > heterogeneous processor technologies change, so might this problem.
>> >
>> > On the other hand, Doug Geiger has made progress on building OpenCL
>> support
>> > into the buffer structure of the scheduler. What you've done here might
>> > work better as a block designed around this concept.
>> >
>> > Tom
>> >
>>
>> Hi,
>>
>> I just wondered why it has not been done yet, but I see the problems now
>> (Sylvain made the point).
>> If a proper device selection and initialization is integrated into VOLK,
>> probably the same processings could be used for the scheduler (e.g.,
>> with a generic fallback). But as well, I think that I don't know enough
>> about all of this ;)
>>
>> Greetings
>> Stefan
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Segmentation fault

[West, Nathan]

We're short on information to actually determine what's wrong here. It
looks like you're still using pdb, but I see different output/problem areas
from  your screenshots. The first one looks like it crashed in tb.start,
and the second one looks like it crashed just creating the channel model
block. Can you confirm what line is actually crashing, and report your
gnuradio + volk version?

If it's at runtime and you're using an older ettus image (rel3? rel2? I
haven't kept up with versions and dates) you might be getting bit by this
https://github.com/gnuradio/volk/issues/25 which can be fixed by either
adding some lines to volk_config or by upgrading to that latest release.

On Tue, Nov 24, 2015 at 9:40 AM, chai E  wrote:

> hi marcus
> i use the gdb as you said,the i debug the python file again
> run the fie step by step
> i found that the there is some problem with ‘channel model’,just like
>
> ​ you can see that
> self.channels_channel_model_0 = channels.channel_model(
> function is init the channel model block
> and the noise_voltage =0.0001 ,frequency_offset=0 and so on is the
> parameter of 'channel model'
> after the parameter is inited,the program should call the
>  Subroutine to pass this parameters,but you can see that the program
> aborted,
>
> then i use command p to view the value of
> self.channels_channel_model_0,but i got the output
> there is no attribute of this ,in other words
> i think that there is some problem with the channel model in the
> pre-installed gnuradio.
>
> hope you can confirm this problem
>
> --Ekko
>
> ___
> 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] A note to owners of existing VOLK modules

[West, Nathan]

In August VOLK changed an ifdef guard for complex.h that results in
breaking builds for OOT modules when VOLK is installed because of some
redefinitions. This has already broken and been fixed in a couple of OOT
modules.

This is just a public heads up to anyone who might be maintaining a VOLK
OOT module. To work with both pre v1.1.1 and post v1.1.1 you should do one
of the following in your
include/volk_/volk__complex.h:

1) replace the current ifdef guard with
#if !defined(INCLUDED_VOLK_COMPLEX_H) && !defined(INCLUDE_VOLK_COMPLEX_H)

2) add the following ifdef guard to the existing one (do not replace to
maintain backwards compatibility)

#ifndef INCLUDED_VOLK_COMPLEX_H
#define INCLUDED_VOLK_COMPLEX_H

And in both cases of course close off the guard at the end of the file.

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

Re: [Discuss-gnuradio] GRC Building Block Internals

[West, Nathan]

Hi John,

There's some python embedded in the GRC xml.
The  block is a python command: 'from gnuradio import analog'
The  block is another python command: 'analog.wfm_rcv(...)' that
uses the analog module that was imported from gnuradio.

That python code can come from two places: native python (hierarchical)
blocks or C++ blocks that have been wrapped in to python by SWIG. In this
case it's a python hierarchical block. Look in
gnuradio/gr-analog/python/analog/ and you'll see 'wfm_rcv.py'

This file is a hierarchical block that connects input
->analog.quadrature_demod_cf -> filter.fir_filter_fff (and audio-rate LPF)
-> deemph -> output. The analog.quadrature_demod_cf is in gr-analog/lib as
quadrature_demod_cf_impl.{h,cc}. The filter.fir_filter_fff is in
gr-filter/lib. deemph is in gr-analog/python/analog/fm_emph as a
hierachical block that does some convenience math to set up an IIR filter
in gr-filter.

All of the blocks that come with GNU Radio at some point go down to a C++
implementation. You can use the GRC xml files to figure out where to look
for the blocks, and sometimes there's an intermediate python hierarchical
block. Look at the import statements to figure out which component to look
in. After spending some time with the framework you develop some knowledge
and sense of where things belong so you no longer have to look around as
much.

A potentially faster approach to find the C++ implementations when going in
blind is to use python to dump of the graph with top_block.dump(). You can
edit the python to do that; not sure if there's a button in GRC to do it.

-Nathan

On Tue, Nov 10, 2015 at 9:53 AM, John B. Wood 
wrote:

> Hello, everyone, and I trust most of you will indulge a GRC newbie.  After
> reading some of the online Gnuradio docs, I'm puzzled by what's inside
> building blocks that appear in the GRC block tree panel.  If I select "WBFM
> Receive" from the "Modulators" tab, for example, I know this defined by the
> analog_wfm_rcv.xml file in my /usr/local/share/gnuradio/grc/blocks
> directory.  When I examine this 672 byte file with a text editor, the what
> entries are there make sense but how can this block define an entire FM
> receiver (Filters, FM detector, etc) from I & Q signal inputs to baseband
> audio?  It doesn't seem possible.  What am I overlooking?
>
> The other question is whether any of these building blocks were themselves
> created using GRC signal flow graphs and how to display them as such.
> Thanks for your time and comment.  Sincerely,
>
> ___
> 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] Timer

[West, Nathan]

Spin off a thread inside your block that counts and calls the appropriate
function. Boost bind might help abstract away a specific function.

On Tuesday, November 10, 2015, Roee Bar  wrote:

> Hello,
>
> I have written a OOT module (in python) that receives and send PMT
> messages according to some state machine.
>
> However, I need a timer so that the block will transmit a message after
> some timeout. I.e., if nothing happens for x seconds, a function is called.
>
> Is there any built-in mechanism in gnuradio for this?
> If not - I thought I should implement another block that act as a timer
> (i.e., it receives a message "wait x seconds" so it goes to sleep for x
> seconds and sends a message back when it wakes up). But there must by an
> easier way than this.
>
> Thanks in advance,
> Roee
>
>
>
> ___
> 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] the block “complex to Arg” in gnuradio

[West, Nathan]

I think it's more of a testament to how good Intel (and modern) processors
are at branching.

An adventurous soul is welcome to try putting that table lookup in to an
avx2 protokernel with the new gather instructions. I'll reward with beer
next time I see the author. If you write a generic table look up I'll
reward with at least two beers :-)

Nathan

On Tuesday, November 10, 2015, Marcus Müller 
wrote:

> Hi Johannes, Hi xd,
>
> complex_to_arg uses GNU Radio's fast_atan2f function, which is an
> approximation [1].
> Between the 255 values of the lookup table, it uses linear interpolation,
> hence your 0.4 error factor.
>
> As Johannes said, that's not really surprising for a look up table-based
> approach.
> I do think using this approximation is justified, but I also think that
> the codebase it uses has been obsolete for a bit now:
> gr::fast_atan2 could be replaced by volk's volk_32fc_s32f_atan2_32f, which
> has been around since 2012, but hasn't seen any use in GNU Radio, as far as
> I can tell.
>
> Now, I went ahead and had a benchmark [2] which showed that gr::fast_atan2
> is actually quite fast -- but that's only twice as fast as the standard
> been-around-forever libc implementation and the volk implementation (which,
> admittedly, also does a multiplication with 1.0, and by the way: the
> generic volk kernel (which does libc atan2 + multiplication) is exactly as
> fast as the SSE4 one on my machine), and everything is pretty much in the
> same range as C++ 's std::arg :
>
> For 2²⁵ complex numbers, of which at least half have small angles:
>
> 1: .fast:
> 1:  0.397261s wall, 0.37s user + 0.02s system = 0.39s CPU
> (98.2%)
> 1:
> 1: .volk:  0.780515s wall, 0.76s user + 0.02s system = 0.78s
> CPU (99.9%)
> 1:
> 1: .libc:  0.38s wall, 0.76s user + 0.02s system = 0.78s
> CPU (100.3%)
> 1:
> 1: .c++ complex arg:  0.815700s wall, 0.78s user + 0.03s system =
> 0.81s CPU (99.3%)
>
> But: this is on an Intel i7. Things might look different on your average
> android phone or even worse, your raspberry Pi (so if you wanna test, [2]
> ).
>
> Conclusion: If you're after small angles, the current complex_to_arg's
> factor 2 speedup might not be what your after.
> That is probably not the case if you use complex_to_arg in an
> quadrature_demod inside an FM audio receiver running on an embedded device
> -- small angle errors don't make the least difference here.
> The question is, like it was with gr::random, whether we still prefer
> performance over preciseness, or if we excercise exactness.
>
> Also, I was pretty amazed how fast fast_atan2 really is –  its dependence
> on branching suggests it's pretty hard to vectorize and optimize as a
> compiler.
>
> Best regards,
> Marcus
>
> [1]
> https://gnuradio.org/doc/doxygen/group__misc.html#ga6c1470346a3524989b7a8a3639aa79a7
> [2]
> On 10.11.2015 10:45, Johannes Demel wrote:
>
> Hi,
>
> Could you extend a test case for this block with Python? This might
> reveal issues with the implementation more easily. Also, others might
> benefit from it.
> For your specific problem, I guess the GR block result is as close as
> it gets for a LUT-based calculation. And it's not off by a lot but by
> some 10^-x.
>
> Cheers
> Johannes
>
> On 10.11.2015 10:29, w xd wrote:
> > Hi all,
>
> > Thank you very much in advance.
>
> > I find the result of the block "complex to Arg" is same to the
> > result in matlab most of the time,while sometimes the results is
> > different from the result in matlab.
>
> > For example, a=1.646236600879293e+03 + 8.043715071772031e+00i I use
> > the command  atan2 or angle to calculate the result. It return
> > 0.004886084452240.
>
> > While i calculate the result using the gnuradio. It return
> > 0.002944485750049.
>
> > Can someone explain it?
>
> > The version of gnuradio:3.7.5. Best regards, xd
>
>
>
> > ___ 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] CGRAN future discussion

[West, Nathan]

Hi all,

Ravi and I will be getting together tomorrow (Tuesday) morning (for me)
around 10:15 EST (15:15 UTC Tuesday).

We'll be reviewing the setup of CGRAN, how things have gone since launch,
and what to do next. If you're interested in volunteering some time or
effort to help CGRAN please join or let me know if you can't make it.

If you have some amazing idea for CGRAN then holler, but don't feel
obligated to join the call-- this will mostly be us reorganizing our effort
and I don't want the outcome to be a long feature list that no one is going
to work on :-)

Cheers!
-Nathan

PS - sorry for the late notice.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] On the "right" approach for developing applications to be run on an E310

[West, Nathan]

You can compile simple programs very similarly to how you normally use
gcc/g++. Source the OE SDK, then call CC or CXX. The environment script
exports these variables the way you would expect if you're familiar with
cross compiling at all. You *could* just call arm-oe-linue-gnueabi, but you
probably shouldn't.

For simple applications it's not too bad. Beyond a toy program or two
you'll really want to start using cmake. It's also important to note that
when you run a command line like that yourself you're probably missing out
on a bunch of optimizations and options that you otherwise take for granted.

On Fri, Nov 6, 2015 at 10:45 AM, Daniele Disco <
daniele.di...@telecomitalia.it> wrote:

> Thank you Philip but I was thinking to a "simpler" procedure like
> gcc-arm app.cpp -luhd -letc. -letc. -o app
>
> It is possible avoid the cmake passage?
>
> Daniele
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p56786.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] VOLK Release v1.1.1 available

[West, Nathan]

The VOLK v1.1.1 release was tagged on October 31st to coincide with GNU
Radio v3.7.8.1, but I didn't get around to updating the VOLK assets until
tonight.

Tarball: http://libvolk.org/releases/volk-1.1.1.tar.gz
Md5sum: 6cb181580aed067f23beff2373d008ed

Summary of changes since v1.1 is available in the usual places:
rendered: http://libvolk.org/release-v111.html
raw markdown: http://libvolk.org/news_raw/release-1.1.1.md
git tag: git show v1.1.1
and here:

Release v1.1.1

This is the first maintenance release with only bug fixes since v1.1

Contributors


The following authors have contributed code to this release:

 * Ben Hilburn 
 * Marcus Müller 
 * Nathan West 
 * Pascal Giard 

Changes
===

Coverity


Ben spent the post-GRcon hackfest fixing a few errors that the GNU Radio
coverity
scan reported. The critical fix was a potential buffer overflow in the
profiler while
reading existing results.

Builds
--

Based on feedback from packagers VOLK has made strides towards reproducible
builds.
The latest effort is removing the builddate.

Several header includes and ifdef guards have been shuffled around to make
VOLK
out of tree modules easier to work with and ARM builds more robust to
compiler whims.

---


Enjoy, and thanks to all contributors (and users!)

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

Re: [Discuss-gnuradio] Adding project info to CGRAN

[West, Nathan]

Hi Carles,

I looked at it when I saw your first email. The scripts are picking up
gnss-sdr with a version that includes the manifest file. I also glanced at
your manifest file and it *seems* ok. I'll check on it again today;
hopefully I just missed something obvious. Also, sorry for not responding
with an update the first time around.

-Nathan

On Mon, Nov 2, 2015 at 9:28 AM, Carles Fernandez  wrote:

> Hi,
>
> any news on this? We included the MANIFEST.md file in our repo some days
> ago, but the information is still not reflected at CGRAN. Any help would be
> appreciated.
>
> Best regards,
> Carles
>
>
>
>
> On Tue, Oct 27, 2015 at 3:15 PM, Carles Fernandez <
> carles.fernan...@gmail.com> wrote:
>
>> Dear all,
>>
>> a few days ago we uploaded the MANIFEST.md file to gnss-sdr at
>> https://github.com/gnss-sdr/gnss-sdr
>>
>> The project already appears at CGRAN, but the associated information does
>> not.
>>
>> Is there any other required step in order to upload the project info to
>> CGRAN?
>>
>> Thanks in advance,
>> Carles
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Adding project info to CGRAN

[West, Nathan]

gnss-sdr wasn't getting picked up properly because the category is 'app'
and all of my scripts look for 'common'. That's been fixed and gnss-sdr now
shows up on CGRAN. This caused a few other OOT modules to be picked up that
weren't noticed before, so thanks for the report.

-nathan

On Mon, Nov 2, 2015 at 9:53 AM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> Hi Carles,
>
> I looked at it when I saw your first email. The scripts are picking up
> gnss-sdr with a version that includes the manifest file. I also glanced at
> your manifest file and it *seems* ok. I'll check on it again today;
> hopefully I just missed something obvious. Also, sorry for not responding
> with an update the first time around.
>
> -Nathan
>
> On Mon, Nov 2, 2015 at 9:28 AM, Carles Fernandez <
> carles.fernan...@gmail.com> wrote:
>
>> Hi,
>>
>> any news on this? We included the MANIFEST.md file in our repo some days
>> ago, but the information is still not reflected at CGRAN. Any help would be
>> appreciated.
>>
>> Best regards,
>> Carles
>>
>>
>>
>>
>> On Tue, Oct 27, 2015 at 3:15 PM, Carles Fernandez <
>> carles.fernan...@gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> a few days ago we uploaded the MANIFEST.md file to gnss-sdr at
>>> https://github.com/gnss-sdr/gnss-sdr
>>>
>>> The project already appears at CGRAN, but the associated information
>>> does not.
>>>
>>> Is there any other required step in order to upload the project info to
>>> CGRAN?
>>>
>>> Thanks in advance,
>>> Carles
>>>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Release v.3.7.8.1

[West, Nathan]

GNU Radio release v.3.7.8.1 is available for download.

Tarball:
http://gnuradio.org/releases/gnuradio/gnuradio-3.7.8.1.tar.gz

MD5sum:
961d5ba5089f409f0c9e5e5b7f6ee0f2

The Live SDR has been updated with this release. Please see:

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD

...for details on how to obtain and use the Live SDR environment.

Release notes for v.3.7.8.1 follow:

Contributors


 * Ben Hilburn 
 * Doug Geiger 
 * Gwenhael Goavec-Merou 
 * Johannes Demel 
 * Johannes Schmitz 
 * Johnathan Corgan 
 * Martin Braun 
 * Nathan West 
 * Paul Cercueil 
 * Philip Balister 
 * Sean Nowlan 
 * Sebastian Koslowski 
 * Jan Krämer 
 * Sylvain Munaut 
 * Tom Rondeau 

Ben Hilburn  (6):

  Fixes Coverity Defect 1229872: Memory leak in `atsci_equalizer_lms2`
DTOR
  lms_dd_equalizer_cc.h: Fixing simple documentation typo.
  Addresses Defects 1046385 & 1046340: Out-of-bounds access
  Addresses Defects 1046385 & 1046340: Buffer not NULL-terminated
  Fixes Cov Defect 1046011: Resource Leak
  Fixes Cov Defect 1043301: Unitialized Variable in Conditional

Doug Geiger  (1):

  Bring fix from other pfb_arb_resampler_* variants

Gwenhael Goavec-Merou  (1):

  logger.h.in: sys/types.h is needed for mode_t

Johannes Demel  (1):

  fec: xml template doesn't produce duplicate var def's anymore

Johannes Schmitz  (1):

  gr-zeromq: fix python examples

Johnathan Corgan  (12):

  qtgui: install vector sink example
  blocks: enable missing multiply_matrix_cc and backport fixes

Martin Braun  (2):

  qtgui: Fixed vector sink example (block not showing)
  modtool: Add hint regarding python blocks + makexml

Nathan West  (5):

  blocks: add socket_pdu qa
  blocks: fix destruction and shutdown for socket_pdu
  blocks: add socket_pdu test using a flowgraph

Paul Cercueil  (1):

  blocks: Fix incorrect size check

Philip Balister  (1):

  Fix uhd_rx_nogui so it runs.

Sean Nowlan  (2):

  blocks: import pmt to get GRC to recognize defaults in Tag Object GRC
bindings
  trellis: fixed pulse normalization in CPM test script

Sebastian Koslowski  (7):

  grc: fix for reverted commit f184ccf 'better Popen argument
handling...'
  grc: fix printing empty traceback when a block is missing
  grc: no block alias param for Options blocks
  qtgui: indentation fix for number sink GRC wrapper
  grc: update port key on domain change
  grc: fix port placement for hidden ports
  grc: disconnect hidden blocks

Sylvain Munaut  (2):

  cmake: Fix warning related to GrSetupQt4 in modern CMake
  grc/blocks: Fix XML RPC server to allow proper flowgraph termination

Tom Rondeau  (3):

  fec: Fixed async_decoder. Can't use nbits_out because it's 0 at this
point.
  logger: fixed issue #851: "notset" instead of "noset".
  fec: Fixed alist file location for ber_curve_gen example.

spectrejan  (1):

  Fixed Bug in qa_multiply_matrix_ff test_005_t
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Flowgraph Control

[West, Nathan]

On Thu, Oct 22, 2015 at 3:58 PM, Richard Bell 
wrote:

> Or is this the correct stategy:
>
> if __name__ == '__main__':
>
> tb1 = my_flowgraph( paramter_set_1 )
> tb.start()
> tb.wait()
> tb.stop()
>
> tb2 = my_flowgraph( paramter_set_2 )
> tb.start()
> tb.wait()
> tb.stop()
>
> tb3 = my_flowgraph( paramter_set_3 )
> tb.start()
> tb.wait()
> tb.stop()
>
> etc..
>

That's what I would do, except create a list of your parameter values and
loop over the list.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testing

[West, Nathan]

On Mon, Oct 19, 2015 at 5:11 PM, Geof Nieboer  wrote:

> Hello all,
>
> I've completed a *beta* version of a windows binary installer for GNURadio
> 3.7.8.
>
> Information about it is available at
> http://www.gcndevelopment.com/gnuradio as is the download itself of
> course.
>
> Essentially I compiled every package in the dependency chain from source
> in 64-bit VS 2015, so it contains everything needed to run.  It also
> includes UHD/osmocom drivers for UHD, RTLSDR, HackRF, BladeRF, FCD, and
> AirSpy.  It should run on Win 7+ and has been roughly tested on Win 7 & 10.
>
> IMPORTANT: This is just a beta version; is 64-bit only, and I set all the
> optimizations for AVX2, so it will NOT run on any CPU prior to Haswell.
> Sorry about that, the 'production' version will come with two options, AVX2
> or SSE2+.
>
> So I'd sure appreciate feedback as I prep the next version, even if
> Windows isn't your primary platform.  The install is completely removable
> and doesn't impact any other Python installations or environment variables
> (see the website for more details).  It's ~400MB download.  Documentation
> and notes as to "why" are available on the site.
>
> Cheers,
>
> Geof
>
>
Hi Geof,

First, congrats on this achievement. Were there changes to GNU Radio and/or
VOLK required to do this? Assuming some changes were required: do you have
a public repo with your modifications and are you planning to submit them
for merging in to GNU Radio and VOLK?

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

Re: [Discuss-gnuradio] One more question about GNU Radio cross compilation

[West, Nathan]

On Thu, Oct 15, 2015 at 10:55 AM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> On Thu, Oct 15, 2015 at 10:40 AM, Douglas Geiger <
> doug.gei...@bioradiation.net> wrote:
>
>>
>>
>> On Wed, Oct 14, 2015 at 4:38 AM, Paul TT <hex...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm trying to build GNU Radio using a toolchain from Mentor Graphics
>>> (arm-none-linux-gnueabi-).
>>> Some gnuradio dependecies i have builded manually from source using this
>>> toolchain.
>>>
>>> 
>>
>>>
>>> export CC="arm-none-linux-gnueabi-gcc -mthumb -march=armv6t2
>>> -mfloat-abi=softfp -mfpu=neon"
>>> export CXX="arm-none-linux-gnueabi-g++ -mthumb -march=armv6t2
>>> -mfloat-abi=softfp -mfpu=neon"
>>> export CPP="arm-none-linux-gnueabi-gcc -E -mthumb -march=armv6t2
>>> -mfloat-abi=softfp -mfpu=neon"
>>>
>> 
>>
>>>
>>> Regards,
>>> Paul
>>>
>>>
>> Paul,
>>  You appear to be targeting an processor that uses the armv6 ISA. I
>> believe VOLK only supports armv7 at this point (although I'm uncertain if
>> that's explicitly stated anywhere
>>
>>  Doug
>>
>
> I don't think it's possible for -march=armv6* AND to have -mfpu=neon.
> Check that your flags are sane for your hardware.
>
> -nw
>

Ah, nevermind. That's not quite true. It is true that our asm is probably
not compatible with armv6 NEON. This is all unfortunately somewhat fragile,
and this case (armv6 + NEON) lost. So for now the solution is *probably* to
just disable the asm stuff. As Doug mentioned lib/CMakeLists.txt is the
source of the problem. You can either comment out that whole section that
includes ASM files or just get rid of the globbing line.

If you can think of a way to make this work for you and not require people
doing native builds to manually feed in CFLAGS and ASMFLAGS (they
apparently don't like doing such things, and there's a lot of them) then
I'll accept a patch.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] One more question about GNU Radio cross compilation

[West, Nathan]

On Thu, Oct 15, 2015 at 10:40 AM, Douglas Geiger <
doug.gei...@bioradiation.net> wrote:

>
>
> On Wed, Oct 14, 2015 at 4:38 AM, Paul TT  wrote:
>
>> Hello,
>>
>> I'm trying to build GNU Radio using a toolchain from Mentor Graphics
>> (arm-none-linux-gnueabi-).
>> Some gnuradio dependecies i have builded manually from source using this
>> toolchain.
>>
>> 
>
>>
>> export CC="arm-none-linux-gnueabi-gcc -mthumb -march=armv6t2
>> -mfloat-abi=softfp -mfpu=neon"
>> export CXX="arm-none-linux-gnueabi-g++ -mthumb -march=armv6t2
>> -mfloat-abi=softfp -mfpu=neon"
>> export CPP="arm-none-linux-gnueabi-gcc -E -mthumb -march=armv6t2
>> -mfloat-abi=softfp -mfpu=neon"
>>
> 
>
>>
>> Regards,
>> Paul
>>
>>
> Paul,
>  You appear to be targeting an processor that uses the armv6 ISA. I
> believe VOLK only supports armv7 at this point (although I'm uncertain if
> that's explicitly stated anywhere
>
>  Doug
>

I don't think it's possible for -march=armv6* AND to have -mfpu=neon. Check
that your flags are sane for your hardware.

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

Re: [Discuss-gnuradio] complex type clarification

[West, Nathan]

On Fri, Oct 2, 2015 at 12:55 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> I just wanted to make sure I have this right (because I always seem to
> confuse myself); the complex data type is 64bits, 4 bytes of I and 4
> bytes of Q, right?
>
> The gr_complex type is defined as std::complex (
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/gr_complex.h#L27).
I'm not certain what the C++ spec *requires*, but I've always seen that as
a pair of floats with the real part in the first 4 bytes and the imaginary
part in the second 4.


> Secondly, those 4B are of type signed floats from [-1,1], right?  I
> assume that these are of the IEEE 754 type?
>

There is nothing that restricts the real/imag parts to [-1,1] other than a
de facto standard that SDR hardware has floats in range [-1, 1]
representing the full ADC/DAC range.


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