Re: [Discuss-gnuradio] C++11 plans

[Johnathan Corgan]

The GNU Radio repository 'next' branch, which will eventually turn into the
3.8 release, already allows/requires C++11.

On Sun, Oct 22, 2017 at 4:22 PM, Scott Torborg <storb...@gmail.com> wrote:

> Hi-
>
> Is there a planned schedule for switching the main GNU Radio codebase to
> require C++11?
>
> Thanks,
> Scott
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Releases 3.7.11 and 3.7.10.2

[Johnathan Corgan]

GNU Radio releases 3.7.11 and 3.7.10.2 are now available for download.

Release 3.7.11 is the latest of the 3.7 API, with new features, and
includes all bug fixes in release 3.7.10.2.

Both releases and their detached signatures are available via the following
links:

https://gnuradio.org/releases/gnuradio/gnuradio-3.7.11.tar.gz
https://gnuradio.org/releases/gnuradio/gnuradio-3.7.11.tar.gz.asc

https://gnuradio.org/releases/gnuradio/gnuradio-3.7.10.2.tar.gz
https://gnuradio.org/releases/gnuradio/gnuradio-3.7.10.2.tar.gz.asc

The GNU Radio Live SDR Environment has been updated to use 3.7.11:

http://s3-dist.gnuradio.org/ubuntu-16.04.2-desktop-amd64-gnuradio-3.7.11.torrent

MD5 sums:

c24377fa5e625180ccafd898a5eaf417 gnuradio-3.7.10.2.tar.gz
7b7b871237ae6fc109d203f78c4654ef gnuradio-3.7.11.tar.gz

Release notes for 3.7.11 are available here:

https://wiki.gnuradio.org/index.php/Changelog_Version_3.7.11

Release notes for 3.7.10.2 are available here:

https://wiki.gnuradio.org/index.php/Changelog_Version_3.7.10.2

Information about the Live SDR environment is here:

https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment


Johnathan Corgan, Chief Architect
Ben Hilburn, Project Lead
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Call for Developers

[Johnathan Corgan]

Hi all -

As we've discussed in recent project calls and at last year's GRCon, we are
pushing hard towards the 3.8 release. We've made significant progress on
the 3.8 development map and one of our current efforts is porting GRC to
Python3, which on its own is both an important and large undertaking.

There's still a fair amount of work to be done on this port, and we are
looking for some additional help to get it finished. Just to be clear, you
do not need to be a radio / DSP expert to contribute to this effort! If
you're a GNU Radio user and are interested in making some critical
contributions, this is a great opportunity to get involved.

If you have any questions and would like to jump in, let us know!

Johnathan Corgan, Chief Architect
Ben Hilburn, Project Lead
Martin Braun, Community Manager
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Code freeze pending release

[Johnathan Corgan]

This is a quick announcement that the window has closed for non-bug fix
pull requests and the code base is frozen for the testing period prior to
release.

We expect to tag and complete a final 3.7.10.2 maintenance release and a
new 3.7.11 feature release during the week of January 23rd.

This has been a longer than usual release cycle with over 80 pull requests
merged, so we're looking forward to getting these out the door!

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

Re: [Discuss-gnuradio] Dynamic OFDM carrier allocation

[Johnathan Corgan]

On Mon, Nov 28, 2016 at 3:42 AM, <adrian.perez.port...@alu-etsetb.upc.edu>
wrote:


> 1. I want the block to transmit the range of unallocated carriers to
> another part of the flowgraph. I've read about the Probe blocks and message
> passing, but they look overly complicated for the task. Could I directly
> access a GRC variable from my python code and set its value to the new
> range? Or should I use messages / probes?
>

​Message passing is a straightforward way for the work (or another message
handling) function of one block to pass arbitrary metadata to another block
anywhere in the flowgraph.

Unfortunately, GRC variables are an abstraction that turns ​into a set of
function calls in the generated flowgraph, so there is nothing to "access".
So you need to create message-based configuration ports in the blocks that
need updating, then connect those to a message output port on the block
that calculates the average and outputs the message.

2. It depends on the first question, but if I wanted to first average
> the obtained unallocated carriers and then transmit the value, how would a
> block that transmits 1 value every 5 inputs work in this situation? I guess
> messages would make more sense, as I could send the message once I am sure
> of the carrier allocation, and only update the variable with meaningful
> values.
>

​You can keep track and average in the message receiver or transmitter.​

3. As for the Carrier Allocation block, I've read in
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-02/msg00416.html
> that it is not possible to update the allocated carriers during execution.
> When implementing a new block capable of doing that, would the constant
> change of the allocation cause problems with the tagged stream of constant
> length that comes before it?
>

​If the upstream tagged stream assumes a fixed number of allocated
carriers, then you'd need to change that so the tagged stream length tracks
the changing number of allocated tones.

This is sort of a lot to tackle all at once; I'd focus on getting one thing
at a time right.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bug in GR runtime related to lock/unlock and tag propagation

[Johnathan Corgan]

On Wed, Nov 16, 2016 at 10:55 AM, Eugene Grayver <eugene.gray...@aero.org>
wrote:

> I came across a nasty bug in the runtime.  It has something to do with the
> tag pruning code after a flowgraph is reconfigured.  My guess is that some
> counter is not being reset, even though the output buffer is reset.  It is
> easy to demonstrate by hooking up a usrp_source to tag_debug.  usrp_source
> inserts tags but they are not seen by the tag_debug (after the first time).
>
​It's really helpful that you provide a script that helps us replicate the
problem.  Can you report this on our Github issue tracker?​

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tag propagaton bug in pack_k_bits_bb

[Johnathan Corgan]

On Wed, Nov 16, 2016 at 5:15 PM, Eugene Grayver <eugene.gray...@aero.org>
wrote:

> I found a tag propagation bug in pack_k_bits_bb.  Example python file to
> demonstrate the bug is below.  This block takes every 2 bits and packs them
> into one output.  Thus, a tag on input 0 should come out on output 0, and
> tag on input 7 should come out on output 3.  However, as can be seen from
> this example, the second tag comes out on output 4.  This is probably due
> to the way sync_decimator does tag propagation: round(input_index /
> decimation).  However, that is NOT the correct approach for this block.
>

​It would be useful to report this as an issue on our Github tracker.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] debugging runtime errors

[Johnathan Corgan]

On Wed, Nov 16, 2016 at 1:56 PM, Tom Early <ac...@nycap.rr.com> wrote:


> Maybe cmake should error out if it can't find swig. Or am I missing
> something in the big picture?
>

​It's entirely possible run GNU Radio as a pure C++ application wrapping
C++ native and OOT blocks; in those cases, we have the option to not bother
with compiling any of the SWIG/Python wrapper code.

However, if you're using a stock apt-get installed version of GNU Radio, it
should be pulling in the appropriate swig packages, so the error above is
unusual.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Flow control with message ports

[Johnathan Corgan]

On Thu, Nov 10, 2016 at 8:07 AM, Bastian Bloessl 
wrote:


> I don't know a good solution, but when I had a similar problem, I ended up
> with:
>
> - the file parser creates an initial message
> - the sync block sends a message back to the file parser when it converted
> the message into stream domain
> - this message triggers sending the next (actual) message in the parser
> block


This is a pretty good strategy in and of itself.

I've used something like it to implement low-latency by having a downstream
block advertise a processing window size to an upstream source, which it
updates each call to work(). In the steady state this results in just
enough buffer filling in the intermediate blocks to keep the downstream
consumer busy.

Need to think about how to generalize this and what you are doing above
into blocks inside GNU Radio.

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

Re: [Discuss-gnuradio] (no module specified) in the block tree

[Johnathan Corgan]

On Wed, Nov 9, 2016 at 8:36 PM, Tom Early  wrote:

> I guess it would be helpful if the on-line documentation were updated (at
> least in the OOT tutorial) with:
>
Good suggestion; I've added this as an issue in our tracker:

https://github.com/gnuradio/gnuradio/issues/1087

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

Re: [Discuss-gnuradio] (no module specified) in the block tree

[Johnathan Corgan]

On Wed, Nov 9, 2016 at 3:39 PM, Tom Early  wrote:


> The tool-tip on this branch says the modules should have a module name in
> their GRC Block Descriptions or their Block Tree. I have been unsuccessful
> in figuring out how fix this. Can someone point me in the correct direction?
>

Just add [NAME] to the XML description for each block,
right after the name and key entries (change NAME to your module name as
you want it listed.)

This was something that was added in 3.7.10 to help clean up the category
tree and to allow OOT modules to have all their blocks grouped together
separately from the pre-supplied GNU Radio modules.

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

[Discuss-gnuradio] New Public Course Offerings for SDR and GNU Radio

[Johnathan Corgan]

New Public Course Offerings for SDR and GNU Radio

Based on feedback and demand from the GNU Radio conference held this year
in September in Boulder, Colorado, Corgan Labs is reintroducing new public
courses that are designed for individuals and small teams. These courses
are built upon the experience Corgan Labs has accumulated as we’ve trained
hundreds of users how to efficiently use GNU Radio and SDR platforms.

We will be conducting these hands-on courses once per quarter on each of
the United States east and west coasts, with the following two as our first:

   - US East Coast - Columbia, MD, 7th December 201
   <http://corganlabs.com/events/intro-to-sdr-east-coast>6
   <http://corganlabs.com/events/intro-to-sdr-east-coast>
   - US West Coast - Santa Clara, CA, 27th January 201
   <http://corganlabs.com/events/intro-to-sdr-west-coast>7
   <http://corganlabs.com/events/intro-to-sdr-west-coast>

These courses provide a brief introduction to GNU Radio, the USRP hardware
platform, and general SDR concepts.  After this introduction, attendees
will be immersed in hands-on exercises that accelerate learning with a
building-block approach. By the end of the course, users with no previous
experience will be able to build simple analog and digital applications.
Each attendee will receive a *USRP B200*
<http://www.ettus.com/product/details/UB200-KIT> to be used for the
hands-on exercises, which they keep after the course.



Corgan Labs also offers customized, on-site courses for teams.  For more
information or to register for a course, please visit the *Corgan Labs
Training Services Page* <http://corganlabs.com/training/>.


Best Regards,

Johnathan Corgan

+1 408 463 6614

*johnat...@corganlabs.com* <johnat...@corganlabs.com>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building gnuradio with Pybombs on MacOSX

[Johnathan Corgan]

On Sun, Oct 23, 2016 at 12:37 AM, Peter Horvath  wrote:


> You need to amend e.g., gr-dtv/swig/CMakeLists.txt so that
> set(GR_SWIG_LIBRARIES gnuradio-dtv)
> becomes
> set(GR_SWIG_LIBRARIES gnuradio-dtv ${GSL_LDFLAGS})
>
> and in gr-dtv/CMakeLists.txt, the GR_REGISTER_COMPONENT section should
> probably also contain GSL_FOUND.
>

​This was fixed in:

https://github.com/gnuradio/gnuradio/pull/1066​

​...and will be part of the 3.7.10.2 maintenance release.

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

Re: [Discuss-gnuradio] RTL SDR & GNU Radio new linux machine.

[Johnathan Corgan]

On Mon, Oct 24, 2016 at 9:40 AM, Paul Zander  wrote:


> 2.  I first tried the GNURadio v3.7.10.1 as a live .iso.  PLL not locked
>

​We compile/install the latest master branch RTLSDR ​driver from git://
git.osmocom.org/rtl-sdr, which is commit e3c03f73 from June/2015.  If there
is a better option, please let me know.

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

Re: [Discuss-gnuradio] Thrift bulding make Issus

[Johnathan Corgan]

On Wed, Aug 31, 2016 at 10:05 AM, Marcus Müller 
wrote:


> Whether the configure line is correct: yes, the options I'd expect are
> there. However, typically, thrift is a nightmare to configure, and
> analyzing the ./configure output most of the time lead me to disable
> further things (demos/tutorials/ruby bindings/...) explicitly.
>

After long trial and error this is what we've come up with as a configure
line for thrift:

https://github.com/gnuradio/gr-recipes/blob/master/apache-thrift.lwr#L21

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

Re: [Discuss-gnuradio] offline wiki?

[Johnathan Corgan]

On Thu, Aug 25, 2016 at 8:55 AM, Philip Hahn  wrote:


>  Is there an offline version of the wiki (specifically, the tutorials
> section) available to download? I will be spending a week without internet
> access but would like to work on building an OOT module.
>

​The LiveSDR image has the tutorials downloaded locally as well as having
gr-tutorial (and many other OOTs) installed.  You can learn more here:

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

This might also save you time in getting every​thing properly installed so
you don't find out you missed something when you don't have Internet access.

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

Re: [Discuss-gnuradio] ctest segfaults after thrift installation for control port

[Johnathan Corgan]

You should be using Thrift 0.9.3 release, and configure thrift to be single
threaded (how escapes me at the moment.)

Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com

On Wed, Aug 24, 2016 at 1:51 PM, Harper, Andrew <
andrew.har...@gtri.gatech.edu> wrote:

>
> Hi, I am having trouble installing Control Port, and I'm hoping someone
> can point me in the right direction. I've been following the directions
> here:
>
>   http://gnuradio.org/redmine/projects/gnuradio/wiki/
> ControlPort#Thrift-092-Shutdown-Patch
>
>
> I set the PYTHONPATH to:
>
>  ~/thrift$ export PYTHONPATH=$PYTHONPATH:/usr/
> lib/python2.7/site-packages
>
>
> and defined the prefix:
>
>  ~/thrift$ export prefix=/usr
>
>
> and changed the appropriate files to implement the patch as shown in:
>
>  source:gnuradio-runtime/lib/controlport/thrift/thrift-
> codebase-shutdown-patch.diff
> <http://gnuradio.org/redmine/projects/gnuradio/repository/entry/gnuradio-runtime/lib/controlport/thrift/thrift-codebase-shutdown-patch.diff>
>
>
> and in the configure step used:
>  ~/thrift$ ./configure --prefix=$prefix \
>  --with-c_glib --with-cpp --with-libevent --with-python \
>  --without-csharp --without-d --without-erlang --without-go \
>  --without-haskell --without-java --without-lua --without-nodejs \
>  --without-perl --without-php --without-ruby --without-zlib \
>  --without-qt4 --without-qt5 \
>  --disable-tests --disable-tutorial $config_opt \
>  CC=$cc CXX=$cxx PY_PREFIX=$prefix CXXFLAGS="-DNDEBUG"
>
>
> The Thrift install seems to work and GNU Radio recognizes that it's
> enabled:
>
>  ~/gnuradio/build$ thrift --version
>  Thrift version 0.9.2
>
>
>  -- ##
>  -- # Gnuradio enabled components
>  -- ##
>  --   * python-support
>  --   * testing-support
>  --   * volk
>  --   * doxygen
>  --   * gnuradio-runtime
>  --   * gr-ctrlport
>  --   * * thrift
>
>
> But when I run ctest and output to file I see errors due to segfaults.
> Here is an example where I run ctest twice in a row:
>
>  ~/gnuradio/build$ ctest -j4 --output-on-failure > ctestout.txt
>  Errors while running CTest
>  ~/gnuradio/build$ ctest -j4 --output-on-failure > ctestout2.txt
>  Errors while running CTest
>
>
> Here are a few failure messages from the first file:
>
>   ~/gnuradio/build$ vim ctestout.txt
>
>
>
>   17/211 Test  #45: qa_ctrlport_probes ...***Failed
> 1.60 sec
>   INFO: Apache Thrift: -h swarm-nuc05 -p 40196
>   .
>   
> --
>   Ran 5 tests in 0.513s
>   OK
>   Segmentation fault (core dumped)
>
>   33/211 Test #194: qa_qtgui .***Failed
> 1.29 sec
>
>   
>   
> --
>   Ran 12 tests in 0.282s
>   OK
>   Segmentation fault (core dumped)
>
>
>
>   The following tests FAILED:
>   7 - qa_kludged_imports (Failed)
>  34 - qa_vector_insert (Failed)
>  45 - qa_ctrlport_probes (Failed)
> 194 - qa_qtgui (Failed)
>
>
> And a few from the second file:
>
>   ~/gnuradio/build$ vim ctestout2.txt
>
>
>
>   111/211 Test #130: qa_sig_source ***Failed
> 0.73 sec
>...
>---
> ---
>   Ran 11 tests in 0.015s
>   OK
>   Segmentation fault (core dumped)
>
>   187/211 Test  #97: qa_goertzel ..***Failed
> 0.43 sec
>   ..
>   
> --
>   Ran 2 tests in 0.008s
>   OK
>   Segmentation fault (core dumped)
>
>   The following tests FAILED:
>  15 - qa_bin_statistics (Failed)
>  74 - qa_vector_sink_source (Failed)
>  97 - qa_goertzel (Failed)
> 130 - qa_sig_source (Failed)
>
>
> As you can see, each time I run ctest a new set of tests fail. It seems to
> be completely random. I have tried everything I can thing of based on the
> installation instructions. Has anyone else had this issue when installing
> Control Port? There haven't been many posts about Control Port recently, is
> it even supported anymore? Is there an alternative method of looking into
> whic

Re: [Discuss-gnuradio] Adding public methods(getters() and setters()) to out of tree modules in GNURadio

[Johnathan Corgan]

You are doing the right things.  However, there is a long standing bug in
our gr_modtool created template that doesn't trigger recompiling the SWIG
wrapper when changing the public .h file(s).  Just do a 'make clean',
'make', and 'sudo make install' again.

-Johnathan

Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com

On Tue, Aug 2, 2016 at 1:40 PM, Damindra Bandara <damindra.band...@gmail.com
> wrote:

> Hi,
>
> I am looking for a way to add public methods to GNURadio OOT modules. I
> modified the _impl.cc and _impl.h files. I also
> added the function signature as a virtual function to
> /include/.h file. I compiled the code(make /make
> install/ldconfig), and I did not get any errors. However, the functions are
> not visible outside. For example, I cannot use the public methods from the
> topblock.py.
>
> If you could give me some guidelines to make public methods in OOT
> modules, I would really appreciate it.
>
> Thank you,
>
> Damindra
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
> ___
> 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] ZMQ REQ / REP naming Swap?

[Johnathan Corgan]

On Thu, Jul 28, 2016 at 12:20 PM, Michael Dickens  wrote:


> OK. I think the issue is that's not how ZMQ is designed to work with
> respect to REQ/REP.  I think it's designed to do "sink -> REQ -> ZMQ ->
> REP -> source", so that the REQ is a sink & REP is a source. In a quick
> internet search, this model is what I turn up. GR's model is the name
> swap of this model; it would work internally to GR, but I won't be able
> to connect GR to the outside world (or, at least my application) because
> of this swapping.
>


​The ZMQ REQ/REP dataflow has the receiving end REQuest data from the
sending end when needed, which REPlies with a packet.  It's a form of flow
control.

>From the GNU Radio perspective, streams flow into GNU Radio sinks to exit
the flowgraph, and data is sourced into a flowgraph from a GNU Radio source
block.

Thus, the correct model is GR Stream | GR REP Sink | ZMQ REP | ZMQ
Transport | ZMQ REQ |  GR REQ source | GR stream

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

Re: [Discuss-gnuradio] Example CMakeLists for dial_tone.cc

[Johnathan Corgan]

On Sat, May 28, 2016 at 3:35 PM, Louis Brown  wrote:


> Does anyone have an example CMakeLists.txt to build something very simple
> like dial_tone.cc?  I DON'T want to do this in the GR source tree, rather
> just have simple ~/dial_tone containing the single *.cc and
> CmakeLists.txt.  I have learned enough c++ now to work through the guided
> tutorials, but the build environment is still somewhat overwhelming, so I
> want to start basic and work my way up.
>

Your question made me realize it has been an embarrassingly long time since
I've written a CMakeLists.txt file from scratch.  Below is the minimum one
that would work to compile dial_tone.cc into an executable:

cmake_minimum_required(VERSION 2.6)
project(dialtone CXX)

find_package(Boost "1.35" COMPONENTS system)
set(GR_REQUIRED_COMPONENTS RUNTIME ANALOG AUDIO)
find_package(Gnuradio "3.7.2" REQUIRED)

include_directories(${GNURADIO_ALL_INCLUDE_DIRS})

add_executable(dialtone dial_tone.cc)
target_link_libraries(dialtone ${Boost_LIBRARIES} ${GNURADIO_ALL_LIBRARIES})


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

Re: [Discuss-gnuradio] Flow Graph Flow Control (was: Re: Code Reuse Question)

[Johnathan Corgan]

On Thu, May 12, 2016 at 2:53 PM, Marcus Müller 
wrote:

> Hi Johnathan,
>
> blocks can't side effect each other except through really strictly
> controlled, well-defined ways
>
> ... and that was still very clear and dominant to the user under GR 3.4, I
> agree – then we "softened" that concept by adding stream tags, message
> passing, and if you look at things like the ofdm_rx.grc, you'll notice that
> there's extensive use of shared state through using the same equalizer
> object for payload and header and so on.
>

​The desire to minimize side effects between blocks is motivated by the
principle that block authors shouldn't have to know anything about the
other blocks they connect to or that are connected to them, and flowgraph
designers shouldn't have to know anything about how the internals of blocks
work other than their stated operation.​  This decoupling is crucial to the
building block approach to application design.

​There are five ways blocks can side-effect each other (and I've been
pushing to remove the fifth for a very long time):

1) Produce data on an output port in work() => causes downstream block
scheduler(s) to wake up and evaluate whether to run their own work()

2) Consume data on an input port in work() => causes upstream block
scheduler to wake up and evaluate whether to run its own work()

​3) Add/remove stream tags in work() => communicates out-of-band data
synchronous to a stream flow downstream

4) ​Post asynchronous messages to an output message port => queues the
message at listening blocks, causes their schedulers to wake up and call
registered message handler functions

5) Call a function on a block from another block or from a thread outside
GNU Radio

The nice thing about 1) through 4) is that they are all mediated by the
scheduler, and therefore are fire-and-forget actions that make it hard to
cause race conditions, deadlocks, or memory corruption.

With 5) the calling thread is always different than the called block's own
execution thread, so without adding synchronization primitives, it is very
easy to cause any of the above without a skilled understanding of
multithreaded programming.  Also, the calling code has to have some sort of
in memory pointer to the called block to call it as a function.

The shared object issue in ofdm_rx.grc (and elsewhere) is a result of
this--passing shared objects via function calls (constructors) between
different objects in different threads. It's not the greatest way to do
things, but a lot of that code was written before there was anything like a
message passing mechanism in GNU Radio and before we had much experience
with the stream tag mechanism.

In addition, calling functions on blocks requires that the caller and
callee be in the same process memory, limiting the flowgraph scope to a
single application running in one environment. The alternative is to
implement remote procedure calls and that way lies CORBA and madness (but I
repeat myself.)

We've been exploring the idea of using asynchronous messages instead of
function calls for a while now.  Several blocks can now have their
configuration parameters updated via a message port, and we just recently
added a QTGUI block that generates asynchronous messages when updated by
the user.  Also, QTGUI sinks can now have their display updated via
receiving async messages instead of stream ports.

An immediate consequence is that, if a block can only communicate or be
communicated with via a messages or stream(s)+tags, those are very easy to
extend to distributed flowgraphs in a way that is completely decoupled from
the blocks themselves.  Two blocks passing messages or stream tags to each
other can be on opposite sides of the Internet and only need to agree
themselves on what the messages mean, while the transport can be message
independent.  We're starting to get some experience with this in a purely
manual way with the ZMQ stream and message blocks.

​All this goes to say that there has been fundamental architectural
considerations in GNU Radio design that have driven its evolution, and even
more has to happen to evolve GNU Radio into more heterogeneous environments.

So, there's two conflicting opinions I have about that
>

​[...]​



> * The whole python variables/callback/GRC-generated code thing is great
> for ad-hoc GUI things, but it has led to numerous cases of people being in
> confusion on how to make blocks "talk" to each other. It's unclean, and
> maybe we should look into how we can reduce usage of that in favour of
> replacing it either by explicit application of e.g. message passing, or
> implicit RPC (which we'd still have to come up with a consistent method
> for).
>

​Yes, as outlined above.​


> OK. Time for lucid dreaming:
>

​I need a little time to think through what you have written.  Agree it is
ripe for discussion.​

​-Johnathan​
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Code Reuse Question

[Johnathan Corgan]

On Thu, May 12, 2016 at 9:18 AM, Marcus Müller 
wrote:


> Yeah, like the head block, it's a copying operation. But that's
> "relatively cheap".
> I'm not quite sure about the state of this, but at GRCON '14 work was
> started on letting blocks define where their buffers are – maybe, one day,
> as a side effect, we can actually use the same buffers for in- and output
> and get rid of the copying.
>

It probably should be the subject of another thread, but one of the deep
underlying philosophies of GNU Radio design is that blocks can't side
effect each other except through really strictly controlled, well-defined
ways.  This includes not being able to modify their upstream block's output
buffer, as potentially many other blocks are also reading that upstream
output buffer.  (There are no "input buffers" in GNU Radio, only input
ports that maintain a read point to upstream-owned memory.)

We do have a branch that was developed by Doug Geiger that allows blocks to
provide their own memory for their output buffer, or to provide their own
memory to an upstream block for it's output buffer.  This was spec'd and
written to support custom hardware that could only work on it's own
physical pages or had DMA restrictions or some other constraint.  However,
it still maintains the idea that you cannot modify the contents of an
upstream block's output buffer.

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

[Discuss-gnuradio] Announcing GNU Radio Slack, a new addition to our community collaboration tools

[Johnathan Corgan]

The GNU Radio project is pleased to announce the addition of a new
community resource for our users and developers to collaborate. We’ve
created an organization on Slack, the team communications application
platform:

https://slack.com/is

The project management and core developers have been trialling this for
several weeks with a mostly positive experience, and we’d now like to open
it up to the GNU Radio community at large.

Slack is accessible via desktop application, web, or mobile app, and takes
full advantage of the capabilities of each to allow text, multimedia, and
notifications in real time. We’ve found it very useful as our team has
grown in both people and time zones.

We’ve been able to integrate Slack with our existing IRC channel #gnuradio
on Freenode, so community members will be able to use either one to gain
access to the common channel shared between both. IRC has long been an
important meeting place for the project, and our hope is that the Slack
integration will allow us to increase the number and ways developers can
interact with us, and improve the ease with which people can participate in
the community.

Access to the GNU Radio Slack is set up via an email invite you can have
automatically generated by visiting:

http://slack.gnuradio.org

We look forward to seeing you there!

Ben Hilburn, Project Lead

Johnathan Corgan, Chief Architect

The GNU Radio Project - The Free & Open Software Radio Ecosystem
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] UHD Updating Question

[Johnathan Corgan]

On Tue, Apr 12, 2016 at 3:27 PM, Martin Braun 
wrote:


> It's my experience that ccache errs on the right side, i.e. it rather
> recompiles if unsure. I've never had any caching issues with ccache.
> Note that the cache quickly fills up, if I can spare the space I will up
> the cache size from the default 1 GB. Right now it's at 8 GB but I doubt
> that'll ever fill up.
>

My experience is the same.  I've only ever had ccache erroneously decide
something has changed and needs recompiling, not the other way around.
It's been a long while since I've looked at its internals, but ISTR it does
a hash on both the compiler command line options and the output from the
preprocessor to match a cached output object file.

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

Re: [Discuss-gnuradio] [USRP-users] UHD Updating Question

[Johnathan Corgan]

On Tue, Apr 12, 2016 at 12:13 PM, Marcus Müller 
wrote:


> GR compile time is an interesting issue.
>

I can't recommend enough using the ccache utility if you are going to be
compiling GNU Radio more than once.

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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Johnathan Corgan]

On Fri, Apr 8, 2016 at 8:09 AM, Stefan Wunsch  wrote:


> Regarding running the GUI: In the readme I've included the commands for
> X forwarding (that's your approach). Works fine on my machine! The VNC
> approach targets especially windows users.
>

I've had success running GRC and QT-based GNU Radio applications using
several different display techniques from inside Docker containers (on
Linux).

- Volume mapping the local /tmp/.X11-unix into the container, setting
DISPLAY to unix$DISPLAY, and allowing access through xhost. This only works
on your local machine.

- Using --net host and -e DISPLAY when launching the container.  This is
useful when you are remotely ssh'd into a host and have X forwarding, so
the container will use the tunneled X server back at your local machine.

- Using xfvb and x11vnc to allow display access via VNC.  This is the most
flexible but slowest.

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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Johnathan Corgan]

On Fri, Apr 8, 2016 at 6:12 AM, Ben Hilburn  wrote:


> It seems like Docker could make it much easier for us to support a variety
> of operating systems - although the user would still need to install
> Docker, itself. Presumably that's easier than earlier containerized models,
> though (e.g., VMs).
>


I've been doing a lot of behind-the-scenes work with GNU Radio and docker
recently, mostly to beef up our automated test infrastructure.

There are a number of different use cases that overlap.  One is testing, as
mentioned.  Another is "full installation of all GNU Radio, dev tools, and
related items to do complete application development."  Yet a third is
"minimal set of packages needed to execute a given GNU Radio application."

I'm working out a stratification of layers that build on one another,
starting with an OS base layer, one adding minimal runtime packages, then
adding minimum build time packages, then a full development layer.

I caution, though, the containers are not the answer to everything, and
it's at least questionable whether providing a full dev environment as a
container is useful to beginners.  There's enough work required "outside"
the container (permissions, volumes, device mappings, networking config)
that the user will still need to understand the internals of Docker before
becoming productive.

That said, I'm very interested in feedback on what the community feels is
useful vs. my own perceptions.

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

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Johnathan Corgan]

Most of you already know me, as I’ve been in the GNU Radio community for
eleven years in various roles, including release manager, integration
manager, Live SDR developer, infrastructure manager, engineering
consultant, and technical trainer.  Today I’m happy to move on to the role
of Chief Architect.

It is an exciting time of transition for GNU Radio.  Recently there has
been large growth in several areas--growth in our user base, our number of
contributors, the types of radio applications and computing environments
that GNU Radio is running in, and hardware vendor support for interfacing
with GNU Radio applications.

Much of this success comes from the efforts of unpaid volunteer
contributors whose code they have made freely available to others in the
community.  This is the nature of open source development, and to a large
extent this has been accomplished without much formal direction from the
project.  As the GNU Radio codebase has grown more complex, we’ve seen the
need for more structured guidance and coordination across development
efforts.

As Ben has outlined, we’re filling out the new organizational roles of Tech
Leads, whom we are looking to champion their respective areas of
development.  This includes:


   -

   Developing a roadmap for feature development and communicating that
   roadmap to the user community and code contributors across the project
   -

   Identifying and recruiting individual code contributors
   -

   Shepherding feature proposals in their area through the process of
   getting community feedback and clarification
   -

   Coordinating code integration in their area of the code tree prior to
   final review and merging
   -

   Ensuring support issues and questions in their area of responsibility
   are properly resolved


In the next few weeks, Ben and I will be sharing more details about how we
will fill out the organization and how we will be operating the project and
the new Foundation.  Key among these are:


   -

   A new process for proposing, getting community feedback on, and
   documenting new (significant) feature development, patterned after the
   Python Improvement Proposal process many of you are already familiar with
   -

   A more structured code review, unit testing, integration, and release
   management process
   -

   Roadmap-based development tracks that allow better coordination among
   different developers, especially for feature sets that cross organizational
   lines
   -

   Improved communication among our globally distributed community and
   developer base


As Chief Architect, I’ll be working closely with Ben, our user community,
and each of our Tech Leads to accomplish these goals.

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

Re: [Discuss-gnuradio] Google Summer of Code / ham radio

[Johnathan Corgan]

On Tue, Mar 8, 2016 at 10:06 AM, Daniel Pocock  wrote:


> Debian and GNU Radio are both confirmed in GSoC this year, is there
> interest in advertising this idea[1] for converting the GNU Radio live
> DVD into a Debian Live project, merging with the Debian Ham CD?
>

​The GNU Radio Live SDR environment builder is completely scripted, and
designed to allow easy customization:

https://github.com/gnuradio/gnuradio-livesdr

For simple binary package installations, you can add a file with a list of
packages here:

https://github.com/gnuradio/gnuradio-livesdr/tree/livesdr/config/install-pkgs.d

To add additional PyBOMBS (1.0) based GNU Radio OOT modules, you can modify:

https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/config/pybombs.d/install.conf

The conversion to using PyBOMBS 2.0​ is in progress.

So it would be straightforward to create a long-lived branch that focuses
on ham radio specific content.

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

Re: [Discuss-gnuradio] polar code example

[Johnathan Corgan]

On Tue, Mar 1, 2016 at 11:42 AM, Jose Ruvalcaba  wrote:


> I was wondering if anyone has seen this issue I am encountering when
> trying to run polar_code_example.grc. Whenever I open the file my POLAR
> code configurator block shows:
>
> Value "polar.load_frozen_bits_info(True, "polar.CHANNEL_TYPE_BEC",
> block_size, n_info_bits, 0.0, 32)" cannot be evaluated:
> name 'polar' is not defined
>
> I was looking online for information on this issue but was not successful
> in finding any information. Does anyone have any insight on this?
>

​This is possibly an existing GRC bug that was fixed in 3.7.9.1.  What
version are you using?​

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

Re: [Discuss-gnuradio] Measure FM frequency deviation

[Johnathan Corgan]

Consider Carson's rule for the occupied bandwidth of an FM modulated
signal, which can be summarized as: 98% of the signal energy of an FM
signal is contained in twice the maximum deviation plus twice the highest
modulating frequency.  This is an approximation.

In the case of commercial broadcast band, the maximum deviation is 75 KHz.
With the original mono FM, the modulating signal was limited to 15 KHz, and
thus the 98% power calculation results in about 180 KHz occupied bandwidth.

Indeed, this was the original reason why commercial BCB stations were
allocated 200 KHz with center frequencies spaced apart the same amount.

Later, when stereo FM, then RDS, and eventually SCA features were added,
the occupied bandwidth widened.  SCA occupies 60-74 KHz, so occupied BW
becomes 300 KHz or so.

Modern stations are now allocated 400 KHz, and while the center frequencies
are still in 200 KHz increments, no stations are assigned in a coverage
area closer than 400 KHz.

In practice, few stations carry SCA anymore, but most have RDS (55-59 KHz),
so this works out to about 270 KHz.

Finally, some stations carry a new product, HD2, which is added to the
signal *after* the FM modulation, and occupies the outer 150 KHz of the 400
KHz allocation.  (These are recognizable on a spectrum display by their
square shape, a result of using OFDM).  In this case the station does not
use SCA, and filters the FM portion of the signal to 250 KHz, result in a
slight distortion of the FM stereo and RDS products.

Hope this clears some things up.

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

[Discuss-gnuradio] GNU Radio Live SDR Image persistence/versions/etc.

[Johnathan Corgan]

I wanted to address some of the recent commentary on the GNU Radio Live SDR
Environment in one location.

*Persistence*

This is something supported by the Ubuntu live system when converting our
supplied ISO image to a bootable USB drive, typically with a program like
Unetbootin.  (A direct copy of the ISO image to a USB drive using something
like 'dd' does not provide persistence.)

Unfortunately, Unetbootin seems to create boot configuration files for
syslinux and Grub that don't enable that persistence, even when it creates
the required files to do so.  When we make our own USB drives for our
training classes, we substitute our own files in place of these after the
fact, by copying them into place from:

https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/custom/grub/grub.cfg
https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/custom/grub/syslinux.cfg

The grub.cfg file goes into /boot/grub and the syslinux.cfg goes into the
root dir of the USB drive *after* unetbootin is completed, overwriting the
ones installed by Unetbootin.

(FYI, if you're wondering, the live system boots with syslinux when doing a
'legacy boot' and with grub/EFI when booted via the new EFI system.)

Longer term, we intend to design a livesdr image that is an actual disk
image that you can dd into place and that will create a persistence
file/partition on first boot.  There would be no reason to use a program
like Unetbootin.


*OS/Kernel Version*

All of the "official" GNU Radio livesdr distributions have been based on
Ubuntu Linux, and this is unlikely to change anytime soon.

Right now, this is Ubuntu 14.04.3 LTS, as it is the most stable and tested
version that is supplied by Canonical.  The kernel version does not have
support for some newer hardware, or has older, buggy versions of the
required hardware drivers.

There is a way (see below) to create a custom version of the Live SDR
Environment image based on Ubuntu 15.10, but we are already beginning the
design and implementation of the image builder to use the Ubuntu 16.04 LTS
alpha, and plan to support that as soon as it is released and we've
completed our testing.


*Live SDR Environment Installation to Hard Disk*

It is often requested to be able to install the Live SDR Environment onto a
hard disk for a more permanent development environment solution.  This is
*not* something currently supported; the ISO image is explicitly designed
to run as a live system and has the Ubuntu Linux installer removed (for
space/size reasons.)

The Live SDR Environment is not only a bootable live system with GNU Radio
installed, there are 25 additional GNU Radio-based applications and block
libraries installed from source code, and numerous tweaks and configuration
edits to Ubuntu itself to (ahem) improve performance, security, and
privacy.  To replicate this on a users' existing Ubuntu installation or to
recreate a traditional Ubuntu installation but with all the additions would
require a non-trivial amount of work to port the live image build system to
a native installer.  We might take this up at some point, but unlikely soon.

The ISO image can be booted within a virtual machine, with perhaps some
extra work to fine-tune hardware performance in the VM.  And of course, one
can use the GNU Radio PyBOMBS installer to install GNU Radio and all of the
extra software on the live image on whatever platforms that supports.


*Custom ISO Images/Live SDR Environment Builder*

The generation of the live image ISO file is completely modular and
automated.  It is a branch of the Ubuntu Remaster system from Corgan Labs,
which is a general purpose live image customization tool:

https://github.com/gnuradio/gnuradio-livesdr

You can clone this repository and build your own custom live images as
variations on the GNU Radio one, adding or removing software components as
desired.  The base system (prior to the GNU Radio additions) also supports
several privacy enhancing options, like fully encrypted ISO images,
transparent Tor proxying, and removal of Ubuntu "features" like the Amazon
integration and online search scopes.

Ubuntu 15.10 kernel support is possible, though it is relatively untested
and only enabled when turning on the experimental features.

One of the areas being worked right now is to be able to choose other
window managers like Xfce or KDE as an alternative to Unity.

The workstation storage and CPU, and bandwidth requirements to build your
own ISO image from scratch are heavy, however--this is not recommended for
end users so much as people who want to create their own derivative
distributions.  And, to completely honest, it is not very well documented.


Hopefully this clarifies some recent issues people have reported, and I
welcome questions/suggestions/testers/pull requests.

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

Re: [Discuss-gnuradio] power amplifiers on TX

[Johnathan Corgan]

On Wed, Dec 30, 2015 at 3:14 PM, James Humphries <james.humphr...@ettus.com>
wrote:


> I'm on Marcus' side with that output power, that's a scary high output. I
> start to sweat at 10W... :)
>

​Heh, I connected a USRP to a 20KW PA once.  Sweating was only one of
several things done in anticipation :)​


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT module authors, please update your cmake

[Johnathan Corgan]

On Tue, Dec 29, 2015 at 4:42 PM, Michael Dickens <michael.dick...@ettus.com>
wrote:


> No way to force things here, I don't think.
>

To be clear, I was referring to new OOT modules created by gr_modtool.  Why
would they need to have local copies of those files if they are already
available via the installed GNU Radio?

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT module authors, please update your cmake

[Johnathan Corgan]

On Tue, Dec 29, 2015 at 4:10 PM, Michael Dickens <michael.dick...@ettus.com>
wrote:


> My advice is to just update the whole cmake directory. There have been
> other changes in that directory that should be included in OOT modules
> too. I know not all OOT modules use the latest, because I patch them in
> MacPorts for the parts I need. - MLD
>

​This makes me wonder how many of these should be installed as part of GNU
Radio, then used by OOT CMake.​

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT module authors, please update your cmake

[Johnathan Corgan]

On Tue, Dec 29, 2015 at 5:08 PM, Philip Balister <phi...@balister.org>
wrote:

> On 12/29/2015 07:47 PM, Johnathan Corgan wrote:
> > On Tue, Dec 29, 2015 at 4:42 PM, Michael Dickens <
> michael.dick...@ettus.com>
> > wrote:
> >
> >
> >> No way to force things here, I don't think.
> >>
> >
> > To be clear, I was referring to new OOT modules created by gr_modtool.
> Why
> > would they need to have local copies of those files if they are already
> > available via the installed GNU Radio?
>
> Dunno, but gr-newmod (or whatever it is called) in gnuradio has a copy
> of the files. I had to fix the issue twice.
>

​This is good opportunity then to see what we can now remove from
gr-newmod.​


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-channel: adding ETSI/3GPP channel model taps

[Johnathan Corgan]

On Tue, Dec 29, 2015 at 11:50 AM, Marcus Müller <marcus.muel...@ettus.com>
wrote:


> ETSI TS 145 005 V[1] specifies the relevant GSM channel models.
>
> I do have a bit of python code that converts those to 10MS/s sampled
> FIRs. Should I just add something to gr-channels python code that gives
> you FIR taps for different of these models?
>

​It would be useful to see how well the Annex C tables can be mapped to the
Frequency Selective Fading Model block parameters and do some resulting
simulations with these.  The block simulates the time-varying effects of
doppler and Rician/Rayleigh fading given a power delay profile and other
relevant parameters.​


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Saving work on Gnu radio live usb stick

[Johnathan Corgan]

On Mon, Dec 28, 2015 at 1:45 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> On 27.12.2015 01:16, Chris Kuethe wrote:
> > Doesn't unetbootin format the device as FAT32, which doesn't support
> > files larger than 4GB...
>
> Yep, it does, and yes, this is a common issue. I'm not sure how you can
> make bigger persistence partitions with other file systems, but I'm sure
> it's possible.


​I'm working with Neel on adding the ability to produce GNU Radio live
images on a target USB drive, directly from the live image builder, without
having to go through UNetbootin first.  This will allow the live system to
be ext4 based and have larger persistence options than 4GB.  Unfortunately,
there will still need to be a FAT32 boot partition to allow for UEFI boot
on modern systems.

It's fairly complicated though and we won't be picking this up again until
later in January.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Saving work on Gnu radio live usb stick

[Johnathan Corgan]

On Thu, Dec 24, 2015 at 8:18 AM, Neel Pandeya <neel.pand...@ettus.com>
wrote:


> The GNU Radio Live SDR image [1] does not have persistence, so you will
> not be able to permanently save anything to the USB drive.
>

​This is inaccurate.

The GNU Radio Live SDR image is an ISO image.  It can be burned to a DVD,
which indeed does not have persistence, but the more typical way to use it
is to create a bootable USB drive with a program like UNetBootin or Ubuntu
Startup Disk Creator.  Both of these options have the choice to create a
persistence area that will automatically preserve files created or changed
during the use of the live image.

​--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio release 3.7.9rc1 tarball and Live SDR Environment image available

[Johnathan Corgan]

GNU Radio release 3.7.9rc1 is available for testers to download from:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9rc1.tar.gz
http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9rc1.tar.gz.asc (GPG
detached signature)

GNU Radio Live SDR Environment ISO Image

http://s3-dist.gnuradio.org/ubuntu-14.04.3-desktop-amd64-gnuradio-3.7.9rc1.iso
http://s3-dist.gnuradio.org/ubuntu-14.04.3-desktop-amd64-gnuradio-3.7.9rc1.iso.asc
The GNU Radio Project is now be providing digitally signed releases using
the following key:

*pub*  3072D/BB8ED9B2
<http://pgp.mit.edu/pks/lookup?op=get=0x2987C77CBB8ED9B2>
2015-08-28
 Fingerprint=B90D DFAC 5698 9BF6 2262  EB81 2987 C77C BB8E D9B2
*uid* GNU Radio Project (Admin) <ad...@gnuradio.org>
sig  sig3  BB8ED9B2
<http://pgp.mit.edu/pks/lookup?op=get=on=0x2987C77CBB8ED9B2>
2015-08-28 __ 2017-08-27 [selfsig]
<http://pgp.mit.edu/pks/lookup?op=vindex=on=0x2987C77CBB8ED9B2>
sig  sig   671DA2F7
<http://pgp.mit.edu/pks/lookup?op=get=on=0x473077BC671DA2F7>
2015-08-28 ______ __ Johnathan Corgan
<johnat...@corganlabs.com>
<http://pgp.mit.edu/pks/lookup?op=vindex=on=0x473077BC671DA2F7>
sig  sig   D65EF422
<http://pgp.mit.edu/pks/lookup?op=get=on=0x2A0A88A0D65EF422>
2015-08-28 __ __ Thomas Rondeau <t...@trondeau.com>
<http://pgp.mit.edu/pks/lookup?op=vindex=on=0x2A0A88A0D65EF422>


This release candidate is mainly targeted at distribution maintainers and
Live SDR Environment users and is a snapshot of the GNU Radio git
repository master branch at tag v3.7.9rc1.  Release notes are still in
progress.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CDMA 2000/IS-95

[Johnathan Corgan]

On Sat, Dec 5, 2015 at 5:19 PM, Henry Barton  wrote:


> I previously asked about a mystery signal I had encountered and was told
> it was either CDMA2000 or IS-95. Can GNURadio decode either these?
>

​GNU Radio is a toolkit for writing software radio applications.​  You
could use it to demodulate CDMA2000 signals, but I'm not aware of anyone
who has written or published an application to do so.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Possible LTE signal

[Johnathan Corgan]

That looks like two signals, each ~1.25MHz wide.  Maybe old school CMDA2000.

On Thu, Dec 3, 2015 at 7:46 PM, Henry Barton <kw...@outlook.com> wrote:

> Does anyone know what this signal is?
> http://www.sigidwiki.com/wiki/One_of_many_signals_near_877_MHz.
>
>
>
> I think it’s LTE but I’m not sure. If it is, I’d like to be able to use
> gr-lte to decode it.
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Schedule for GNU Radio 3.7.9 release

[Johnathan Corgan]

The next feature release of GNU Radio, 3.7.9, is targeted for mid-late
December, just before the holiday period.  Here are the key dates:

   - 12/07/15 - Feature freeze.  Bug fix merges only until final release;
   git/PyBOMBS users can do testing on master branch
   - 12/11/15 - 3.7.9rc1 tarball and ISO image release - users who do
   source builds and distribution maintainers can test build scripts
   - 12/22/15 - 3.7.9 release tarball, ISO image, gnuradio.org site update

If you have any pending bug fixes or finalized feature branches, please
submit pull requests as soon as possible.

Thank you,

-Johnathan

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Weird install problem, GR 3.7.8.1

[Johnathan Corgan]

The fix for this was already put into GNU Radio's maint and master
branches, and will show up in the 3.7.8.2 and 3.7.9 releases.

If you are using git to obtain GNU Radio, you can update to get it right
away.

On Wed, Nov 11, 2015 at 6:49 PM, John Coppens <j...@jcoppens.com> wrote:

> On Wed, 11 Nov 2015 13:42:35 -0800
> Johnathan Corgan <johnat...@corganlabs.com> wrote:
>
> > On Wed, Nov 11, 2015 at 6:07 AM, Frederick E. Stevens <
> sk8tesgr...@gmail.com
> > > wrote:
> >
> >
> > > As I recall, this behavior has cropped up in 3.6 and 3.7 of gnuradio
> for
> > > me but it wasn't much of an issue at the time.
> > >
>
> This afternoon, I had some time to trace where the problem originated. It
> seems that on some systems (mine ;) the test for isinstance(category, str)
> doesn't work, as the type of category is actually 'unicode'. (This is
> on Slackware 14.1 + some mods from -current).
>
> I changed to isinstance(category, basestring), which captures both str
> and unicode.
>
> (This is around line 130 in BlockTreeWindow.py)
>
> I've submitted a bug report for this - which was accepted.
>
> John
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFC: updating pybombs libpng recipe

[Johnathan Corgan]

On Wed, Nov 11, 2015 at 11:22 PM, Chris Kuethe <chris.kue...@gmail.com>
wrote:


> gr-fosphor depends on libpng 1.6, here's a diff to update the png
> recipe. before i update it and break something, here's your chance to
> test and discuss.


​Just FYI, libpng 1.6 is not packaged on Ubuntu's stable LTS distribution,
nor Debian stable, so it will end up being a source compile for a lot of
users now.  Sylvain had mentioned in IRC he might make this a conditional
dependency.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python Script Stalls

[Johnathan Corgan]

On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> John, did you mean this four step process, otherwise stop before wait
> doesn't let anything happen:
>
> tb.start()
> tb.wait()
> tb.stop()
> tb.wait()
>
> Like that? If so, why don't the auto-generated top_blocks have to do that?
>

​To clarify what is happening under the hood here, let me go through what
these calls actually do.

tb.start() creates and runs a thread for each block in the flowgraph, and
immediately returns to the foreground thread execution. One uses this form
when one wants to continue to do other things in the application while the
flowgraph is running in the background.  This is typically used with GUI
applications that have their own event loop thread.

At the end of the application, one must call tb.stop(), which issues a
cancel to each thread, and then tb.wait(), which joins each thread and
ensures everything is cleaned up before continuing.

​Now, flowgraphs can either exit on their own, such when a finite data
source is used, or a head() block is in place, or they run indefinitely.
In either case, if the flowgraph is started with tb.start(), it must
eventually be followed with tb.stop() and tb.wait().

The alternative, which is more common in non-GUI scripts, is to use
tb.run().  This will internally call start(), and then block either until
the flowgraph to exits on its own, or a SIGINT (ctrl-c) arrives.  It then
calls tb.stop() and tb.wait() internally, then returns.

Thus, the simpler tb.run() semantics let you create a flowgraph, let it run
till exit, or break out of it with SIGINT.  When tb.run() returns, there is
nothing else the user needs to do.  Hence, many command-line examples you
see in GNU Radio use tb.run().  If they use the tb.start() method, which
again, returns immediately to the foreground, they usually have a raw input
call or something else that blocks until the user does something, then they
call tb.stop() and tb.wait().

It sounds like what you are trying to do, if I understood correctly, is run
a finite-length flowgraph over and over again.  For that, tb.run() should
suffice.  If the flowgraph is not guaranteed to exit on its own, then
you'll need to do tb.start(), block while you figure out whether conditions
are proper for terminating the flowgraph, then do tb.stop() and tb.wait().

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [VOLK] SIMD accelerated Mersenne-Twister

[Johnathan Corgan]

On Wed, Nov 11, 2015 at 10:47 AM, Martin Braun <martin.br...@ettus.com>
wrote:


> Since you're not the copyright holder of the original code, you have no
> way of transferring said copyright to the FSF.
>
> I'm not sure what the correct way to do this is. An out-of-tree approach
> will definitely work, since the licenses are compatible according to
> lists provided by e.g. the FSF.
> If the authors would agree to a copyright transfer of this copy of the
> code, that'll also work but it's annoying to get that.


​While all the above is true, we do occasionally make exceptions for
including non-FSF owned code inside GNU Radio, as long a the licenses are
compatible.  We try to avoid this as much as possible and have actually
been removing such code a little at a time as it becomes possible.​

In this case, I don't think we'd want to include it, but I wanted to
clarify the above.​

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Weird install problem, GR 3.7.8.1

[Johnathan Corgan]

On Wed, Nov 11, 2015 at 6:07 AM, Frederick E. Stevens <sk8tesgr...@gmail.com
> wrote:


> As I recall, this behavior has cropped up in 3.6 and 3.7 of gnuradio for
> me but it wasn't much of an issue at the time.
>

​It turns out this is a long-standing bug in GRC that has been around since
its inception. Sebastian has fixed it and it will get pushed out to our
maint and master branches shortly.​

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python Script Stalls

[Johnathan Corgan]

tb.stop(), then tb.wait()

On Tue, Nov 10, 2015 at 6:39 PM, Richard Bell <richard.be...@gmail.com>
wrote:

> I've written a python script that instantiates a top_block.py file (no
> GUI), sets the parameters, runs until 100 block errors are detected, stops
> the simulation and starts the process over with a new instantiation, etc..
>
> The problem I have is that I randomly (as far as I can tell) have a
> problem where the gnuradio simulation stalls out during one of these
> simulations. Everything its supposed to be printing to terminal stops. I
> can still hit 'Ctrl-C' to get it to move on to the next simulation, and it
> will continue on working after that. But I can't figure out why it stalls
> such that all I can do to get it to move onto the next simulation iteration
> is hit 'Ctrl-C'.
>
> For an example of what I mean by stall, I added a message debug block to
> my sim just to see if that also stopped outputting to terminal when the
> stall happened, and sure enough, it too was effected.
>
> I can't recreate this issue when I just the radio from GRC. It always runs
> fine.
>
> Has anyone experienced something like this when using python? What I do in
> python is pretty simple:
>
> for nn in xrange(0,nsims):
> tb = top_block()
> time.sleep(1)
>
> --set a bunch of radio paramters--
>
> tb.start()
> tb.wait()
> tb.stop()
>
> --collect results and push to file--
>
> tb = None
>
> I could really use some debug help
>
> Rich
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Conference 2015, RF Network-on-a-Chip, and New Public Courses

[Johnathan Corgan]

View this email in your browser
<http://us10.campaign-archive1.com/?u=ef1aa9b809823d269b24031b7=264d198b25=>GNU
Radio Conference 2015 Recap
Corgan Labs and the rest of the GNU Radio Conference 2015 team are
extremely proud to report that GRCon15 was a major success.  Compared to
2014, attendance more than doubled for both the New Developer Day and
general conference. Presenters covered a wide range of topics, from
introductory sessions about getting started with GNU Radio to new advances
in cognitive radio techniques using deep learning. We have received
positive feedback from beginners and advanced developers alike. The growth
of this conference, widespread adoption, and enthusiasm throughout the
community is an indication that GNU Radio is a great platform to invest in.

Over the next few months Corgan Labs will be working with the GRCon15 team
to highlight some of the interesting material and discussions.
 RFNoC: Survey for Potential UsersOne very popular topic at the conference
was RF Network-on-a-Chip (RFNoC)
<http://www.ettus.com/sdr-software/detail/rf-network-on-chip>, a new
framework developed by Ettus Research that drastically reduces the effort
required to offload high-performance DSP functions to an FPGA.  RFNoC
promises to revolutionize high-performance SDR design flows and enable new
applications.  However, RFNoC is a multi-faceted framework, which requires
knowledge and experience in a number of areas for full utilization, such as
digital design for FPGAs, DSP theory, C/C++ programming, and GNU Radio
application development.

Corgan Labs is currently developing a course that will help users become
productive using RFNoC and FPGA design.  Planned for later this year, we
are gathering input from potential attendees to understand their
requirements.  If you would like to participate in the survey, and receive
$100 toward any Corgan Labs SDR course, please visit this page
<http://corganlabs.com/rf-network-on-a-chip-survey-for-potential-users/>.
 New Public CoursesCorgan Labs is also excited to announce new public
courses designed for beginners.  We started hosting these public courses in
the beginning of 2015, and they have been a big hit.  New course listings
include:

   - US East Coast - Columbia, MD,  November 5th, 2015
   <http://corganlabs.com/events/intro-to-sdr-east-coast>
   - US West Coast - San Diego Clara, CA, November 2nd, 2015
   <http://corganlabs.com/events/intro-to-sdr-west-coast>

Click on the links above for more information about the public courses.
Corgan Labs also offers on-site, customized, and advanced courses.  For
more information, please visit the Corgan Labs Training Page
<http://corganlabs.com/training/> or email i...@corganlabs.com
<i...@corganlabs.com?subject=Public%20Course%20Inquiry>.

Best Regards,
Johnathan Corgan
johnat...@corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio live USB. GRUB2 broken, how to fix it?

[Johnathan Corgan]

I replied to your earlier email, but your mail server rejected the email.
You can check the list archive for my response.

On Fri, Sep 4, 2015 at 9:47 AM, Fernando Peral <ferna...@samara.com.es>
wrote:

> Hi!
>
> I Installed GNU Radio live on a usb stick and I was changing some
> aspects of its configuration.
> I like to delete some entries of the boot menu (is to use with my
> students at class and I don't one anyone to use "install ubuntu") and i
> broke grub2. Now the usb stick does not boot.
>
> I know hot to fix a normal grub2 installation, but as it is a grub2 on a
> casper filesystem I don't know how to fix it.  Any help please?
>
> regards
>
> P.D. excuse me for posting the topic twice, but I posted it replying to
> another topic (changing the subject) and as a result the post was "lost"
> inside the other topic
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio live USB. GRUB2 broken, how to fix it?

[Johnathan Corgan]

On Thu, Sep 3, 2015 at 12:41 AM, Fernando Peral <ferna...@samara.com.es>
wrote:


> I Installed GNU Radio live on a usb stick and I was changing some
> aspects of its configuration.
>

​What are you using to create the USB drive?​

I know hot to fix a normal grub2 installation, but as it is a grub2 on a
> casper filesystem I don't know how to fix it.  Any help please?
>

​I expect you'll find it easiest to start over from scratch.

For reference, when we create the live USB drives for our classes​, we use
Unetbootin, then replace the installed syslinux and grub configuration
files with these:

https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr-snapshot/custom/grub/syslinux.cfg
https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr-snapshot/custom/grub/grub.cfg

These have the extraneous menu options removed and allow the user to choose
between persistent and non-persistent modes.  The syslinux.cfg controls the
boot options when booting in legacy BIOS mode, and the grub.cfg controls
the boot options in UEFI boot mode.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class -
​Nov. 2-3, Santa Clara, CA
Intro to SDR Class -
​Nov​
.
​4​
-
​5​
,
​Columbia, MD
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GPS Signals recorded IQ samples file

[Johnathan Corgan]

On Fri, Aug 21, 2015 at 8:41 PM, Francisco Albani 
francisco.alb...@gmail.com wrote:


 Marcus: I was not expecting to see the signal because I already knew it
 was under noise floor. My conclusion of signal absence was after my GPS
 receiver was not able to decode it when I replayed it with an USRP.


​If you replayed the capture file over the USRP for reception by a
commercial GPS receiver, you'll have to carefully adjust the digital
amplitude sent to the USRP and USRP PA gain setting in order to 1) transmit
enough signal power, as the captured data typically has very low numerical
values, and 2) avoid overloading the front end of the GPS receiver that is
designed to work with low-level signals.

I've done this successfully in the past in building GPS interference
mitigation applications.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[Johnathan Corgan]

On Tue, Aug 11, 2015 at 4:24 AM, bob wole bnw...@gmail.com wrote:


 Anyone successful in applying that patch to thrift 0.9.2 ? Thoughts ?


​In the mastering of the live SDR image, I had to create a new patch that
was slightly different from the original one; I suspect the original one
was based on a different version of thrift than 0.9.2.

In any case, you can try this one, it applies cleanly to the 0.9.2 tag in
the thrift repository:

https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/custom/gnuradio/thrift-shutdown-fix.diff
​

Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Channel Model

[Johnathan Corgan]

On Wed, Aug 5, 2015 at 12:51 PM, Martin Braun martin.br...@ettus.com
wrote:


 Try

 noise_voltage = self.EbN0_to_noise_voltage(EbN0)/sqrt(2)

 the original berawgn.py was already buggy, because it didn't follow a
 recent change in the noise power. I've submitted a patch, but it
 probably won't be merged before the release cycle is reset (cf

 https://github.com/gnuradio/gnuradio/compare/master...mbr0wn:digital/berawgn_fix_noisepower?expand=1
 ).


​This did get merged for 3.7.8 release.​


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio 3.7.8 Release Candidate 1, Call For Testers, and Live SDR Environment Snapshot Update

[Johnathan Corgan]

*Feature Freeze and Release Candidate*

The merge window for new features for GNU Radio 3.7.8 has closed, release
candidate 3.7.8rc1 has been tagged, and only bug fixes will be accepted
into the tree prior to release.  The planned release date is August 8.  If
you have any pending fixes to submit, please create pull requests as soon
as possible.

Tarball:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.8rc1.tar.gz

MD5:

e26d478e7ad51b7f889abb38f76d7aa1  gnuradio-3.7.8rc1.tar.gz

*Call For Testers*

If you have installed GNU Radio via git but don't routinely upgrade your
GNU Radio installation, now is an opportunity to do so and test out what
will eventually be released as 3.7.8.  Please remember to execute git pull
--recurse-submodules in order to get the latest VOLK updates as well.

Since we lack automated tests for the GNU Radio Companion, we're asking
people to emphasize testing your existing GRC applications for proper
operation.

*Live SDR Environment*

We have updated the snapshot release of the GNU Radio Live SDR Environment
image.  In addition to having the release candidate version of GNU Radio,
there are new software releases for hardware support from Ettus Research
(UHD 3.8.5), Nuand (2015.07), GreatScottGadgets (v2015.07.2), and Analog
Devices (libiio/gr-iio v0.5).  Many of the third-party GNU Radio-based
libraries and application software have been updated as well.

Please see
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD for
details about how to obtain and use the Live SDR Environment.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Packet Based Radio

[Johnathan Corgan]

On Fri, Jul 24, 2015 at 3:24 PM, Martin Braun martin.br...@ettus.com
wrote:


  I hope this is useful information for people starting up on something
  like this. Though I failed with the packet based approach, I was able to
  make a streaming based approach work. I detect the start of a stream one
  [...]

 This kind of feedback is fantastic, and thanks a lot for taking the time
 for both being thorough in your setups and the recaps here on the list.


Completely agree.  While we of course hope that nobody has to struggle as
you have to get things working (or not), you've helped out a lot just by
bringing these issues to our attention and in a way that helps others.

Thanks again.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Additional Public SDR Class Dates, Gearing Up For GRCON15

[Johnathan Corgan]

View this email in your browser
http://us10.campaign-archive2.com/?u=ef1aa9b809823d269b24031b7id=d3060bacd0e=
Upcoming Public CoursesCorgan Labs is excited to announce two additional
two-day public courses on the East and West Coast:

   - US East Coast - Columbia, MD,  August 31st, 2015
   http://corganlabs.com/events/intro-to-sdr-east-coast
   - US West Coast - Santa Clara, CA, September 3rd, 2015
   http://corganlabs.com/events/intro-to-sdr-west-coast

These courses begin with a brief introduction to GNU Radio, the USRP
hardware platform, and general SDR concepts.  After this introduction,
attendees will be immersed in hands-on exercises that help learn the tools
with a proven building-block approach.  By the end of the course, users
with no previous experience will be able to build simple analog and digital
applications.  Each attendee will receive and keep a USRP B200 to be used
for the hands-on exercises.  For more information, please visit the Corgan
Labs Training Page http://corganlabs.com/training/.
 GNU Radio Conference 2015We are happy to report that plans for GNU Radio
Conference 2015 are coming together and we expect it to be a highly
educational, productive and engaging event.  The conference is packed with
high-quality content, and you will also find numerous opportunities to
network with other GNU Radio developers.

As a Platinum sponsor, Corgan Labs is proud to commit financial,
organizational, and technical resources to the fastest growing SDR
conference on the globe.

Here is a basic overview of the event:

   - Dates: August 24 - 28th, 2015
   - Location: Center for Strategic  International Studies
   
http://csis.org/files/publication/131205_external_conferencing_brochure_web.pdf
in
   Washington DC.
   - Program includes presentations, hands-on tutorials, working groups,
   and multiple networking opportunities

For more information, or to register, please visit the GNU Radio Conference
2015 web site http://www.trondeau.com/gnu-radio-conference-2015/.
Free Hands-on TutorialsCorgan Labs will be offering a free hands-on
introductory tutorial during the New Developer Day of the GNU Radio
conference.  The session will be 2-4 hours in length and will cover a
variety of topics for beginners, including:

   - Overview of USRP and RTL-SDR hardware platforms
   - Building your first application to visualize signals
   - Building your first spectrum analyzer and FM Receiver - Step-by-Step

We will provide updates with more information about the event and tutorials
in the coming weeks.  If you would like more information about the course,
please contact us at i...@corganlabs.com.

We look forward to seeing you at the conference!

Best Regards,
Johnathan Corgan
johnat...@corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Live SDR Environment Snapshot 2015-0623 Released

[Johnathan Corgan]

GNU Radio Live SDR Environment Snapshot Release 2015-0623

This version of the ISO image is based on the current, unreleased master
branch of GNU Radio and latest releases of third party software as of June
23, 2015. Use this to try out the in-progress feature development of the
GNU Radio project:

http://s3-dist.gnuradio.org/ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.8git-snapshot-2015-0623.torrent

If a Bittorrent client is not available or its use is restricted, you may
download the ISO image file by choosing from one of the following mirror
sites:

http://s3-dist.gnuradio.org/ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.8git-snapshot-2015-0623.iso
http://eu1-dist.gnuradio.org/ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.8git-snapshot-2015-0623.iso
http://eu2-dist.gnuradio.org/ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.8git-snapshot-2015-0623.iso

MD5 checksums:

36af5aa4e4039bcf6c68de5d9917d6c3
ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.8git-snapshot-2015-0623.iso

c7a686d5aa0a535042ea14784c8a28bc
ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.8git-snapshot-2015-0623.torrent

This snapshot release has the following changes from the stable release:

   - GNU Radio release 3.7.8git, commit b9bdd1ce
   - The ControlPort
   http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort feature
   set of GNU Radio has been reenabled, using Apache Thrift now as the
   underlying transport
   - The linux-tools package is installed to allow use of perf
   https://perf.wiki.kernel.org/index.php/Main_Page for fine-grained
   performance analysis
   - The GNU Radio logging
   https://gnuradio.org/doc/doxygen/page_logger.html feature is enabled
   - The octave packages octave-audio, octave-communications, octave-signal,
   and qtoctave GUI front-end have been installed
   - The Analog Devices http://wiki.analog.com/software/linux/docs/iio/iio
libiio/gr-iio out-of-tree module has been installed
   - The libsodium
   https://github.com/jedisct1/libsodium/blob/master/README.markdown crypto
   library and gr-nacl
   https://github.com/stwunsch/gr-nacl/blob/master/README.md out-of-tree
   module have been installed

Further information about the GNU Radio Live SDR Environment may be found
at:

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

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Remove portion of tagged stream

[Johnathan Corgan]

On Mon, Jun 22, 2015 at 4:09 PM, Richard Bell richard.be...@gmail.com
wrote:


 Is there a block that exists that will identify a tag and then remove the
 next X items, where X is user defined?


No.



 is the conclusion that I have to use a general block here correct?


Yes



 if I call produce(X) to place samples in the output buffer, then what does
 the return statement do? If I return 8000, what does this mean?


Use 'return WORK_CALLED_PRODUCE'.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] why alignment feature work only when output_multiple not set

[Johnathan Corgan]

On Fri, Jun 19, 2015 at 6:09 AM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jun 18, 2015 at 8:29 AM, Tiankun Hu tiankun...@foxmail.com
 wrote:

  Hi Tom,
 Thanks your reply, I have another question, in function
 min_available_space why buffer_size/2 is best ?


 I'm not really sure. That's a question for Eric.


The scheduler aims to keep the buffer no more than half full, so that in
the steady state the producing block can write into the free half and the
downstream consuming block(s) read from the filled half.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Embedded WG

[Johnathan Corgan]

On Mon, Jun 15, 2015 at 7:38 PM, Nowlan, Sean sean.now...@gtri.gatech.edu
wrote:

  J Corgan's bootable USB stick on a Minnowboard


I'm pretty curious how well this worked and if you ran into any issues or
had to do anything extra for this combination.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Install GNURadio from Source

[Johnathan Corgan]

=on-- git submodule update--   External
 VOLK
  disabled.--   Override with -DENABLE_INTERNAL_VOLK=ON/OFF-- CMake
 Error at
  CMakeLists.txt:309 (message):  VOLK required but not found.*
 
  I've run the two git commands it asks me to run, deleted the build
  directory and re-ran cmake but I get the same error. I see a volk
  directory
  in the gnuradio directory.
 
  What is causing this problem?
 
  v/r,
  Rich
 
  ___
  Discuss-gnuradio mailing list

  Discuss-gnuradio@

  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





 --
 View this message in context:
 http://gnuradio.4.n7.nabble.com/Install-GNURadio-from-Source-tp54119p54125.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 mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Install GNURadio from Source

[Johnathan Corgan]

On Wed, Jun 17, 2015 at 3:09 PM, Richard Bell richard.be...@gmail.com
wrote:


 I was overlooking the Thrift dependency previously. I installed Thrift
 0.9.2 from source, following this
 https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort as well
 as the Thrift homepage install instructions,
 http://thrift.apache.org/docs/install/, because I needed to install a few
 more dependencies for thrift than what was listed in the first link. I then
 deleted build and re-built gnuradio. When I ran CMake, I saw that under the
 gr-ctrlports module section it said it found thrift 0.9.2. Was there
 something else I needed to confirm in the cmake output beyond that?



What is your installation prefix?

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CPU usage when hdlc framer is used

[Johnathan Corgan]

On Tue, Jun 16, 2015 at 10:16 AM, Nick Foster bistrom...@gmail.com wrote:


 Issue #1 is likely the problem. Thanks for pointing that out, Andy! The
 other two issues should be pretty miniscule in overhead, but are probably
 good ideas nonetheless. The block was written for clarity rather than for
 speed, but even so it shouldn't be particularly heavy-duty.



In the future, we plan to allow designating a non-empty message queue as a
prior condition to be satisfied before the scheduler calls work(), thus it
will won't ever be necessary to block inside work directly on the queue
itself.  This is a common issue with source blocks that rely on input
message ports for content.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CPU usage when hdlc framer is used

[Johnathan Corgan]

On Tue, Jun 16, 2015 at 1:32 PM, Marcus Müller marcus.muel...@ettus.com
wrote:


 if I understand you correctly, you think the situation calls for
 something like a wait for message flag that a block would need to set
 every work call?


Actually, this is the idea--that, *when needed*, make a call to the
scheduler just before ending work, that says, in in effect--don't call me
again until input message port X is not empty.

Otherwise, call me again whenever you otherwise would, which, for a source
block, is when there is room in the output buffer (subject to other
constraints.)

This would allow work() to be invoked one more times as needed, to exhaust
any pending data that might exceed noutput_items in a given call, yet then
finally wait on a message for more content.

The key point would be to not block in work, which prevents the scheduler
from that block from processing any other events, but instead allow the
scheduler itself to do so.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] variable type while creating a block

[Johnathan Corgan]

On Tue, Jun 16, 2015 at 2:17 PM, Marbellys marbellysramos3...@gmail.com
wrote:


 If i set the input of my block as a byte, means that the block will handle
 8
 bits at a time and each item correspond to one bit of that byte?

 in[0] is the first bit and so on?



No, this isn't automatic.  You would also have to precede your block with a
block like gr::blocks::unpack_k_bits_bb or ::repack_k_bits_bb to generate
such a stream from a packed byte format.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] variable type while creating a block

[Johnathan Corgan]

On Tue, Jun 16, 2015 at 4:13 PM, Marbellys marbellysramos3...@gmail.com
wrote:


 So if i use an unpack_k_bits block, and i set k to 1,  will I be handle 1
 bit at a time?


Yes.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Diagnosing the cause of D's

[Johnathan Corgan]

On Fri, May 29, 2015 at 9:07 AM, Richard Bell richard.be...@gmail.com
wrote:


 What I would like to do now, is learn how to monitor performance such that
 I can figure out which part of my receiver is the bottleneck, so I can
 focus on optimizations there. I can't lower the sample rate anymore,
 because I'm already at the minimum rate the USRP requires (320k).

 Would someone recommend a next course of action and tools I should
 download to proceed?


There are many potential sources of problems that can result in overflow
from the USRP. Some common ones:

- Insufficient network stack buffering in the OS. Increasing this, however,
may just be masking the real problem, and at the data rate you are
describing, is unlikely the issue.

- One of the blocks in the flowgraph is exceeding the CPU resources
available in a single core.  While all GNU Radio blocks run in their own
threads and area scheduled by the OS onto as many cores as are available,
due to their sequential data dependencies, a single slow block can become
the rate-setting portion of the flowgraph.  Normally, you always want the
hardware to have this role.

- OS operations like periodic file system flushing can often consume CPU
and I/O bandwidth that competes with the flowgraph.  This is made much
worse if you are writing to disk as a result of the flowgraph processing.

A coarse view of the flowgraph resource usage (CPU, etc.) can be had with a
thread and core aware tool like htop.  This will quickly show if a single
block/thread has become a CPU bottleneck.

A more granular view can be seen with the perf tool available in the
linux-tools package. This allows profiling CPU usage by function and can
identify hot spots for further optimization.

Finally, it might help to understand if the overflow events are a few
every so often, or continuous.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 150, Issue 31

[Johnathan Corgan]

On Thu, May 28, 2015 at 9:17 AM, John Murphy 
mr.john.joseph.mur...@gmail.com wrote:


 Tried this, then deleted the xml file before attempting to make again
 without it.
 Got the following error when re-making (the line with the xml file had a
 destination which I had thought was just for that file)


That looks like the error you would get if it were the only XML file to
install.  In that case, just delete the entire INSTALL clause.  If not, can
you post the CMakeLists.txt file?

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Reacting Slowly

[Johnathan Corgan]

On Thu, May 28, 2015 at 12:05 AM, Marcus Müller marcus.muel...@ettus.com
wrote:


 I'll pitch `perf` here (you're on Ubuntu, so it's in the linux-tools,
 probably).



I'm pretty sure the issue is as Murray Thomson described above.  We've had
to optimize this area in the past in GRC.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: modtool noblock and xml files and grc

[Johnathan Corgan]

On Thu, May 28, 2015 at 8:26 AM, John Murphy 
mr.john.joseph.mur...@gmail.com wrote:


 Anyhow, it unexpectedly generated an xml file to import the non-block into
 GRC.
 Is there a best way to just remove that xml file without causing other
 issues?


First, do a 'make uninstall' from your build directory, to remove the file
from where GRC finds it.

Then, edit grc/CMakeLists.txt and remove the line that has the XML filename
in it.

Finally, rerun the build (cmake, make, sudo make install, etc.).

Also when I tried to drag and drop the non-block into GRC, presumably from
 the default created xml file with no edits (curiosity always gets one in
 trouble?) GRC went to a blank screen. Of course I was able to close and
 restart and pick up at the last save which was fine. Okay none of that is
 really unexpected.


In general, gr_modtool creates XML files that need further editing before
being usable in GRC; in this case, GRC didn't handle the mis-parse very
well.


 I guess there must be a reason you would have a noblock that can be added
 to a flowgraph?


You can create generic functions with parameters that you can set up as
variables in GRC.  They aren't blocks added to the flowgraph but are still
GRC blocks.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scrambler Mask, Seed and Lenght

[Johnathan Corgan]

On Fri, May 15, 2015 at 1:32 AM, Marcus Müller marcus.muel...@ettus.com
wrote:


 So, yes, I think I agree, and length should at least be 8 here (your
 polynomial has degree 7), and it's a bit uncommon to see a LFSR being used
 without the x^0 coefficient.


Agree.  This was a poor implementation decision by someone who clearly
didn't know what he was doing at the time :-)

I've been wanting to fix this for a long time; looks like 3.8 would be a
good chance to break this properly.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Release 3.7.7.1 and Live SDR Environment is available for download

[Johnathan Corgan]

GNU Radio release 3.7.7.1 is available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.7.1.tar.gz

GNU Radio Live SDR Environment:

http://s3-dist.gnuradio.org/ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.7.1.torrent

MD5 sums:


ca8e47abcb01edc72014ccabe38123a3  gnuradio-3.7.7.1.tar.gz
1603f93c3b9d9f5815131328bf1b743e
 ubuntu-14.04.2-desktop-amd64-gnuradio-3.7.7.1.torrent

Release 3.7.7.1 is a maintenance release that quickly followed 3.7.7, and
so both are being rolled up into this announcement.

Release notes for the significant changes between 3.7.6.1 and 3.7.7 are
here:

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

...while the bug fixes for its first maintenance release are here:

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

Information about the GNU Radio Live SDR Environment is here:

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


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correlation Estimation Block Oddity

[Johnathan Corgan]

On Wed, Apr 29, 2015 at 8:50 AM, Richard Bell richard.be...@gmail.com
wrote:


 Thanks for replying. The question is, how do I do this? We both agree the
 zeros need to go. What I'm not sure on is how to do that. I'd rather keep
 this contained to GRC, because I don't like maintaining python files not
 connected to grc. Can you explain how you do this or provide an example?


Since GRC parameters can be Python expressions, you can use formulas to do
this.

If 'seq' is the original sequence to be modulated, use 'seq+seq' in the
parameter to the modulate_vector variable block.

If the variable is named 'mod_vec', use:

mod_vec[len(mod_vec)/2:]

...as the taps for the correlation estimator.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correlation Estimation Block Oddity

[Johnathan Corgan]

On Tue, Apr 28, 2015 at 12:48 PM, Richard Bell richard.be...@gmail.com
wrote:


 When you mentioned I should remove leading or trailing zeros from the
 Correlation Estimator symbols field, how would you go about doing this if
 you used the modulate vector block as done in the example? I'm stuck on
 this.


The group delay in the pulse shaping filter (in this case, RRC) causes
these leading zeros.  This is something I'd like to figure out a proper
solution for, but my quick hack that works pretty well is to duplicate the
PN sequence as it goes into modulate_vector, then take only the second half
of the samples of the output for the correlation block.

This then pre-fills the filter with data that is arguably the right
spectral shape, and the resulting second-half vector works much better than
the original way.

Again, this is a quick hack, but it works well.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correlation Estimator

[Johnathan Corgan]

On Tue, Apr 21, 2015 at 11:19 AM, Richard Bell richard.be...@gmail.com
wrote:

 Was the Correlation Estimator block recently added? If so, thank you
 whoever wrote it. If not, thanks anyway. It seems to be an alternative to
 the infamous Corr_and_Sync block.

 I also like the testbench that goes with it in gr-digital/examples/demod.
 I did not know I could use Modulate Vector (or the existence thereof) to
 pre-modulate a preamble. Very clean.


Both corr_est_cc and modulate_vector were written and contributed to GNU
Radio by Nick Foster and Andy Walls, and are intended as a more general
replacement for corr_and_sync, and were recently merged into master for
eventual release in 3.7.8.

Tom Rondeau, Sean Nowlan, and I are working on better packet/burst mode
processing and the above is a nice addition to that.

The modulate_vector function/block may undergo some changes as we're trying
to figure out the best way to deal with group delay in the pulse shaping
filter.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Empty volk directory when I git gnuradio

[Johnathan Corgan]

This happened on Sunday.  The --recursive flag could have been added at any
point in anticipation of it.

On Wed, Apr 1, 2015 at 8:24 AM, Marcus D. Leech mle...@ripnet.com wrote:

 On 04/01/2015 10:20 AM, Sylvain Munaut wrote:

 git clone --recursive

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

 When did the change actually occur?  I knew it was coming, but was waiting
 to update build-gnuradio to take this into account.


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




-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

[Johnathan Corgan]

I believe Michael Dickens will have a comprehensive fix for issues like
this soon.

On Wed, Apr 1, 2015 at 5:44 PM, Ron Economos w...@comcast.net wrote:

  I know what's causing this error. It's a function of using the GCC 4.7
 compiler. It works with GCC 4.8 or later because the define complex in
 complex.h is undefined in complex.

 I'll have a fix for this soon.

 Ron


 On 04/01/2015 04:57 PM, Activecat wrote:

 Dear Sir,

  Recently I failed to install GNU Radio using PyBOMBS.
 Error message:

  
 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:750:95:
 error: ‘volk_32fc_s32fc_multiply_32fc’ was not declared in this scope
 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:756:72:
 error: cannot convert ‘gr_complex* {aka std::complexfloat*}’ to ‘const
 int*’ in argument passing
 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:780:71:
 error: ‘volk_32fc_x2_multiply_conjugate_32fc’ was not declared in this scope
 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:785:62:
 error: cannot convert ‘gr_complex* {aka std::complexfloat*}’ to ‘const
 int*’ in argument passing
 make[2]: ***
 [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o]
 Error 1
 make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
 make[1]: *** Waiting for unfinished jobs
 Linking CXX executable fcd_nfm_rx
 [ 91%] Built target fcd_nfm_rx
 Linking CXX shared module _qtgui_swig.so
 [ 91%] Built target _qtgui_swig
 Linking CXX shared module _digital_swig.so
 [ 91%] Built target _digital_swig
 make: *** [all] Error 2
 Build failed. See output above for error messages.


  The complete installation log is at
 https://github.com/activecat/gnuradio/blob/master/installation_log_001.txt

  I am using Debian 7.8 64bit.
 Further details of system info is at
 https://github.com/activecat/gnuradio/blob/master/system_info.txt

  Please advise me how to solve this installation error.
 Thank you very much.



 ___
 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




-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Johnathan Corgan]

On Wed, Apr 1, 2015 at 12:30 PM, Martin Braun martin.br...@ettus.com
wrote:


 Unfortunately, we can't provide liveSDR ISOs anymore, now, because of
 licensing issues.


Rest assured we are almost ready to announce our GNU Radio Live SDR Floppy
Disk Environment and parallel port license dongle.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New Public Course Offerings for SDR and GNU Radio

[Johnathan Corgan]

View this email in your browser
http://us10.campaign-archive1.com/?u=ef1aa9b809823d269b24031b7id=f45ea7f61ee=[UNIQID]New
Public Course Offerings for SDR and GNU Radio

Earlier this year Corgan Labs introduced new public courses that are
designed for individuals and small teams.  These courses are built upon the
experience Corgan Labs has accumulated as we’ve trained a hundreds of users
how to efficiently use GNU Radio and SDR platforms.

With outstanding initial feedback and additional demand, we have added two
new courses to our calendar:

   - US West Coast - Santa Clara, CA 23rd April 2015
   http://corganlabs.com/events/intro-to-sdr-west-coast
   - US East Coast - Columbia, MD, 4th June 2015
   http://corganlabs.com/events/intro-to-sdr-east-coast

These courses provide a brief introduction to GNU Radio, the USRP hardware
platform, and general SDR concepts.  After this introduction, attendees
will be immersed in hands-on exercises that accelerate learning with a
building-block approach.  By the end of the course, users with no previous
experience will be able to build simple analog and digital applications.
Each attendee will receive a *USRP B200*
http://www.ettus.com/product/details/UB200-KIT to be used for the
hands-on exercises, which they keep after the course.


Corgan Labs also offers customized, on-site courses for teams.  For more
information or to register for a course, please visit the *Corgan Labs
Training Services Page* http://corganlabs.com/training/.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.7 and ControlPort

[Johnathan Corgan]

It's unlikely to happen for 3.7.7, though it may show up on the master
branch of the source repository soon after, for an eventual 3.7.8 release.

On Sun, Mar 29, 2015 at 3:36 AM, Murray Thomson murraythomson...@gmail.com
wrote:

 Hi,

 Anyone knows if we´ll get controlport back in 3.7.7?

 Thanks,
 Murray

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




-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issues Installing From Source

[Johnathan Corgan]

=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages

 //if u prefer python 3.0 then u can add 3.0//
 //Save it and close//

 11)sudo ldconfig

 12)sudo apt-get install gnuradio-companion

 Note:
 1)If you get any error related to dpkg then run the command as suggested
 in the error.

 2)Installation can take around 2hours and it depends upon the speed of
 your internet
  I hope it could help you

 Regards
 Krishna



 On Thu, Mar 5, 2015 at 4:02 PM, Ralph A. Schmid, dk5ras 
 ra...@schmid.xxx wrote:

 I am afraid I did not document this, but I ran into similar issues with
 the
 script and Kubuntu 14.04. However doing it all by hand, resolving
 dependencies, load uhd and gnuradio sources, compile the stuff,
 installing
 udev rules, installing the gnuradio icons by hand and such, this all
 was not
 a big deal, and in some cases I simply read the script as a manual how
 to do
 it.

 Pybombs is something I could not become friends with yet. For many
 people it
 seems to work, for me all attempts were disastreous.

 Ralph.

  -Original Message-
  From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
  [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf
 Of
  Marcus D. Leech
  Sent: Wednesday, March 4, 2015 5:43 PM
  To: discuss-gnuradio@gnu.org
  Subject: Re: [Discuss-gnuradio] Issues Installing From Source
 
  On 03/04/2015 10:40 AM, Peter Witkowski wrote:
   Hello,
  
   In the past, I've always used the build-gnuradio script to install
   everything with great success.  This ensures that I have all the
   latest versions of both GNU Radio and UHD.
  
   However, I recently got a new machine and installed Ubuntu 14.04 on
 it
   (I haven't had any issues with 14.04 before). I updated the OS to
 the
   latest version and then tried using build-gnuradio.  Immediately I
   started having issues.  First, the script was unable to install git,
   cmake, and other dependencies.  However, I was manually able to do a
   sudo apt-get on all of these packages and at least get to the
 point
   where the script tries to install UHD.
  This is the first I've heard of it having problems doing the pre-req
 installs.  If
  you run build-gnuradio with -v, you get more details about why.
 If the underlying OS tooling is falling over, there's very little
 that
 build-
  gnuradio can do about it.  It has as much troubleshoot-and-repair
 ability as a moribund gnat.
 
  ___
  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 
 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




 --
 Peter Witkowski
 pwitkow...@gmail.com

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




-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issues Installing From Source

[Johnathan Corgan]

On Thu, Mar 5, 2015 at 2:41 PM, Johnathan Corgan johnat...@corganlabs.com
wrote:

$ apt-get install libgl1-mesa-dev-lts-utopic mesa-common-dev-lts-utopic


That would be 'sudo apt-get install ...'


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Corgan Labs Expands Offering with Public and Advanced Courses

[Johnathan Corgan]

View this email in your browser
http://us10.campaign-archive1.com/?u=ef1aa9b809823d269b24031b7id=4bd4a3853be=


http://corganlabs.com

Corgan Labs, a leading provider of SDR training and consulting
solutions, and a preferred partner of Ettus Research, is proud to
announce expanded course offerings.  These courses are built upon
methods that are proven to make users more productive with GNU Radio and
USRP products quickly.  Our new offerings include:
 


  Public Course - Introduction to SDR with GNU Radio and USRP

Corgan Labs will be hosting several  two-day introductory courses, which
are ideal for individuals or small teams that are new to GNU Radio. 
Each attendee will receive a USRP B200
http://www.ettus.com/product/details/UB200-KIT that will be used for
hands-on lessons during the course.

  * US East Coast - Reston, VA, 26th March 2015
http://corganlabs.com/events/intro-to-sdr-east-coast/
  * US West Coast - Santa Clara, CA, 23rd April 2015
http://corganlabs.com/events/intro-to-sdr-west-coast/


  Advanced Courses

We have also introduced two new advanced courses.  These courses can be
provided on-site, worldwide, and can be tailored to fit the needs of
your team.

  * Custom GNU Radio Application Development with Python and C++
http://corganlabs.com/offerings/advanced-application-development/
  * A Hands-On Introduction to Digital Signal Processing
http://corganlabs.com/offerings/hands-on-dsp/

“Ettus Research is excited about these expanded course offerings as they
will enable even more people to use these tools for exciting SDR
applications.  Johnathan Corgan's role as a key leader and developer in
the GNU Radio community means they are uniquely positioned to give users
a running start with their application development.”  - Matt Ettus,
founder, Ettus Research.

For more information please see the full story
http://corganlabs.com/corgan-labs-partners-with-ettus-research-to-deliver-sdr-training-on-industry-standard-platform/
on our website, or visit the Corgan Labs Training Services Page.
http://corganlabs.com/training/

Best Regards,
Johnathan Corgan
+1 408 463 6614
johnat...@corganlabs.com


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

Re: [Discuss-gnuradio] Threaded GRC blocks

[Johnathan Corgan]

On 01/16/2015 12:44 PM, Marcus Müller wrote:

 Since you were talking about ranging:
 Do you know of gr-radar [1]? It already comes with quite a set of
 algorithms and visualizations, and is generally considered to be awesome
 [2]. Installation is quite straightforward[3], and the source is
 available under [4].

Just FYI, gr-radar is one of the many GNU Radio-based packages that
comes pre-installed on the live DVD.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Command Not Found

[Johnathan Corgan]

On 01/16/2015 02:33 PM, Richard Bell wrote:

 Is there someone who can explain the pybombs install mechanism to me. I
 have been speaking to some CentOS guys about the package-manager and
 they say that pybombs isn't using that at all because it is installing
 programs from source.

Pybombs, in fact, asks the system package manager whether a binary is
already installed, or is installable that way first.  Only if neither of
these are the case does it install from source.

This behavior can be modified through the configuration, but the above
is the default.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PDU_to_tagged_stream consumes 100% CPU even though it is throttled!

[Johnathan Corgan]

On 01/15/2015 12:59 AM, Sylvain Munaut wrote:

 To me it look like all it's missing is a
 basic_block::delete_head_blocking with a timeout. Then the
 pdu_to_tagged_stream_impl::calculate_output_stream_length could just
 use that with a reasonably small timeout (like 100ms or so) so that it
 waits on a message but if none comes, it still handout control back to
 the caller from time to time (which I think is required for stop() to
 work).
 
 Is there anything that wouldn't work with this approach ?

A change to a blocking call with a timeout would work as a short term fix.

The longer term proper fix requires a scheduler change as outlined in a
that email Stephan Ludwig asked about.  It's in a long list of things
Tom and I are organizing for 3.8 scheduler work.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with Virtual Sink/Source

[Johnathan Corgan]

On 01/12/2015 05:44 PM, Johnathan Corgan wrote:
 On 01/12/2015 02:25 PM, Richard Clarke wrote:
 
 /usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py,
 line 93, in __getattr__
 return getattr(self._impl, name)
 *AttributeError: 'top_block_sptr' object has no attribute
 'virtual_source_0'*
 
 This may be related to a recent change that was done prior to the 3.7.6
 release.  I'm investigating.

I've replicated this problem locally, working on a fix.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with Virtual Sink/Source

[Johnathan Corgan]

On 01/12/2015 02:25 PM, Richard Clarke wrote:

 /usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py,
 line 93, in __getattr__
 return getattr(self._impl, name)
 *AttributeError: 'top_block_sptr' object has no attribute
 'virtual_source_0'*

This may be related to a recent change that was done prior to the 3.7.6
release.  I'm investigating.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [ANN] GNU Radio 3.7.6, 3.7.5.2, and Live SDR Environment released

[Johnathan Corgan]

GNU Radio releases 3.7.6 and 3.7.5.2 are available for download:

http://s3-dist.gnuradio.org/gnuradio-3.7.5.2.tar.gz
http://s3-dist.gnuradio.org/gnuradio-3.7.6.tar.gz

Additionally, a new version of the GNU Radio Live SDR Environment
image has been created, available via BitTorrent at:

http://s3-dist.gnuradio.org/ubuntu-14.04.1-desktop-amd64-gnuradio-3.7.6.torrent

MD5 sums:

dc5da27c3e37387384ed762e677d3594  gnuradio-3.7.5.2.tar.gz
388d4af6c68e095f62dc4745b0f805c0  gnuradio-3.7.6.tar.gz
3485b0e81360ad431f92133315f7ef5c
ubuntu-14.04.1-desktop-amd64-gnuradio-3.7.6.torrent


A special thanks from the GNU Radio Project to all the individual
contributors that continue to grow the GNU Radio software:

Abhishek Bhowmick abhowmic...@gmail.com
Achilleas Anastasopoulos anas...@umich.edu
Doug Geiger doug.gei...@bioradiation.net
Felix Wunsch un...@student.kit.edu
Jiří Pinkava j...@seznam.cz
Johnathan Corgan johnat...@corganlabs.com
Marcus Müller mar...@hostalia.de
Martin Braun martin.br...@ettus.com
Michael Dickens michael.dick...@ettus.com
Michael Ossmann m...@ossmann.com
Nathan West nathan.w...@okstate.edu
Nick Foster bistrom...@gmail.com
Paul Garver garv...@gatech.edu
Philipp Aigner phaig...@gmail.com
Sebastian Koslowski koslow...@kit.edu
Stefan-Olt stefan-oltma...@gmx.net
Sylvain Munaut t...@246tnt.com
Tim O'Shea tim.oshea...@gmail.com
Tom Rondeau t...@trondeau.com
Uwe Hermann u...@hermann-uwe.de
Will Code willco...@gmail.com


Release 3.7.5.2 is a bug-fix only maintenance patch following 3.7.5.1,
and will be the last one for the 3.7.5 release.  Release 3.7.6
incorporates all these fixes and adds significant new features.


GNU Radio Distribution and Mirror Sites

The GNU Radio Project has changed its distribution location for
release and data files. The new location allows us to more easily add
GNU Radio mirror sites, and we're in the process of adding two new
ones in Europe.  An announcement with more details will follow.
(Hint: We expect to be distributing a lot more files...)


GNU Radio Live SDR Environment

The new live SDR image not only has GNU Radio 3.7.6 pre-installed, but
has updated driver support from several SDR hardware vendors and new
versions of many of the pre-installed GNU Radio-based applications.

Newly added with this release is gr-fosphor, a GPU-accelerated
real-time spectrum analyzer display component from Sylvain
Munaut. However, due to distribution restrictions, the live SDR
environment only comes pre-installed with the Intel CPU Open CL
driver, and gr-fosphor will not run in GPU-accelerated mode even if
one is available.  It is possible, after converting the ISO image to a
USB drive, to download, install, and configure additional Open
CL support.

Further details on the live SDR image are here:

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


There have been hundreds of changes in the GNU Radio software in this
release, throughout the tree.  Below is a summary of the more
significant ones:


GNU Radio Companion

Sebastian Koslowski and the GRC Working Group continue to make many
updates to GRC.  Important among these:

* The default windowing system for new flowgraphs is now QT GUI.
  Existing flowgraphs that use WX GUI are not affected, and one can
  still choose to use WX GUI for new flowgraphs.  However, we've
  formally deprecated WX GUI support, will not be making further
  updates to it, and will remove it in a future API version.

* Introduction of port domains. GRC now allows blocks to declare a
  domain property for ports, along with code for managing and
  displaying their connections.  This is primarily to support FPGA- and
  co-processor-offload hardware block development.


Stream Tag Performance Improvements

At GRCON14, Tim O'Shea, Doug Geiger, and Eric Blossom (!) reworked the
stream tag dequeuing implementation in gnuradio-runtime, resulting in a
very significant performance increase for flowgraphs using tagged
stream blocks for burst-mode processing.  More details can be found on
Tim's blog:

http://tinyurl.com/n3qr2ab


Vector Optimized Library of Kernels (libvolk)

VOLK continues to undergo rapid development by the VOLK working group
members, and has become mature enough to break off into its own
project/package.  Nathan West will be leading the effort to migrate
libvolk into its own source code tree, repository and release cycle.

GNU Radio 3.7.6 will likely be the last release that will have libvolk
directly included in its source code tree.  However, we'll be closely
coordinating with VOLK releases and distribution to ensure a smooth
build process for GNU Radio.


QT GUI Display Support

With this release, GNU Radio's implementation of instrumentation
display sinks and controls using the QT GUI windowing system has
become our official way of creating application GUIs.  As mentioned
above, GRC has changed its default option for new flowgraphs to use QT
GUI, and further development on WX GUI has stopped.


Bug fixes (3.7.5.2, also in 3.7.6

Re: [Discuss-gnuradio] Locking TopBlock stops WavFile-Sink

[Johnathan Corgan]

On 01/05/2015 08:08 AM, Luke Berndt wrote:

 I am trying to figure out why calling lock() on one instance of a
 HeirBlock cause all the other instances to lock().

Yes, a lock/unlock event affects the whole flowgraph, by necessity.

Reconfiguring flowgraphs should be considered a very big hammer, often
used in cases that can be solved some less invasive way.

Think of it like disassembling and reassembling a car transmission just
to shift gears, or tearing down and rebuilding a different road to
change your destination.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

[Johnathan Corgan]

On 12/30/2014 06:37 AM, Ralph A. Schmid, dk5ras wrote:

 I installed gnuradio master from source on a Kubuntu 14.04 64 bit
 system, and it appears that all wxgui stuff does not work. What may be
 the issue here? Gnuradio and uhd build without error, without missing
 features, but for example uhd_fft gives this output:

This is indeed a bug, an unfortunate side effect of a semi-last minute
commit before the 3.7.6 release.

Fortunately, it's a one line bug fix I'll be committing to the
repository shortly.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] RFNoC -- Making FPGA design easy from GNU Radio

[Johnathan Corgan]

On 12/04/2014 10:52 AM, Matt Ettus via USRP-users wrote:

 Ettus Research is very excited to announce the release of RFNoC! 

[...]

 All documentation and links to the source code can be found here:
 
   https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started

RFNoC is an exciting development, one we plan to take full advantage of
in our custom application services and training classes.

However, I want to add that at present, using the above capabilities
requires an Ettus Research-specific development branch of GNU Radio
(specifically, the GNU Radio Companion.)

The GNU Radio Project team is working closely with Ettus Research to
bring the needed GRC modifications into GNU Radio in a vendor-neutral
way.  This would allow other interested parties to develop their own
blocks that provide specialized ports, and have them displayed and
configured through GRC.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] grcc issues

[Johnathan Corgan]

On 11/06/2014 09:09 AM, Koslowski, Sebastian (CEL) wrote:

 Same here. I pushed a fix to
 https://github.com/gnuradio/gnuradio-wg-grc/tree/maint_grcwg
 
 I also added a more detailed error message to grcc (on branch
 master_grcwg of the same repo)

These have been merged into mainline.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT GUI Segmentation Fault

[Johnathan Corgan]

On 10/30/2014 02:07 PM, Michael Rahaim wrote:

 While I'm happy to have it working again, I don't exactly know what this
 modification actually does. If anyone with knowledge of the volk library
 can give me a quick bit of info about what these modifications are
 actually doing and / or why this would resolve the segfault issue, it
 would ease my mind a bit.

What you did was instruct VOLK to use a non-SIMD implementation of these
two functions.  It appears that for whatever reason the AVX versions of
those kernels are having problems when running on your specific CPU.

Can you give us the information from running:

$ grep 'model name' /proc/cpuinfo

What OS and version are you using?

Are you running in a virtualized environment like VMware or KVM?

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] All ist klar, Herr Kommisar

[Johnathan Corgan]

On 10/30/2014 12:04 PM, Ryan Marlow wrote:

 I've seen this comment for a while now in flowgraph.cc and most of the
 time chose to ignore it. Today I saw it and decided to do a quick google
 search to see what I could find.
 https://www.youtube.com/watch?v=6GmkjnL4EYw
 What??? Why???
 Funny easter egg to say the least...

It only took 7 years for someone to comment on that, misspellings and all :)

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] All ist klar, Herr Kommisar

[Johnathan Corgan]

On 10/31/2014 01:01 PM, Mike Markowski wrote:

 Bug: It is 'Alles klar, Herr Kommissar'.  (Nicht 'all ist klar'.)

Thank you for reporting this.

A fix has been generated and pushed to the maintenance branch, and will
become part of the 3.7.5.2 and 3.7.6 releases.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] All ist klar, Herr Kommisar

[Johnathan Corgan]

On 10/31/2014 10:44 AM, Martin Braun wrote:

 I don't know who put this in there (clearly not a German native speaker
 given that most words are misspelled) but I think it's hilarious.

That was me, and you are right, my German is limited to a few phrases
not spoken in polite company, and various brands of pretty good beer.

Enough to get by on, anyway. :)

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Latest Gnuradio git won't compile on OS X

[Johnathan Corgan]

On 10/31/2014 09:04 AM, Michael Dickens wrote:
 I just fixed this issue within MacPorts  
 https://trac.macports.org/changeset/127653 , which will be live by around 
 12:30 PM/US/Eastern.  I ended up following Stephan’s lead and moving the 
 shuffle index values directly into the function call; nothing else made clang 
 happy.  Given that these constants are used just once, and other constants 
 are used in other shuffle calls directly, I think it makes sense to just 
 commit this change to GIT.  The patch (-p0) is found at  
 https://trac.macports.org/browser/trunk/dports/science/gnuradio/files/patch-volk-shuffle.diff?rev=127653
   for anybody interested.  For folks using MacPorts, you’ll want to do:
 {{{
 sudo port clean gnuradio*
 sudo port selfupdate
 }}}
 before installing or upgrading whichever gnuradio port you’re using (next or 
 devel; none of the others are affected). - MLD

This was just fixed earlier this morning on our master branch.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio