Re: [Discuss-gnuradio] Removed TCP source block

Oh, you're using GNU Radio 3.8. Unfortunately, almost no OOT's have been
converted to 3.8, so your choices are extremely limited. However, there
is a test OOT here that may be useful.

https://github.com/noc0lour/gr-grnet

Ron

On 3/29/19 06:56, Andriy Gelman wrote:
> On Thu, 28. Mar 20:24, Ron Economos wrote:
>> It's still around. It's just been deprecated. Look in the Deprecated
>> category in GNU Radio Companion.
>>
>> Ron
>>
>> On 3/28/19 20:01, Andriy Gelman wrote:
>>> Hi,
>>>
>>> It looks that the TCP source block was removed in commit fd1148e8c.
>>> Anyone recommend a replacement?
>>>
>>> Thanks,
>>> Andriy
> It doesn't seem to be in the deprecated category of the
> master branch. See attached figure.
>
> Andriy
>
>

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

Re: [Discuss-gnuradio] Removed TCP source block

On Thu, 28. Mar 20:24, Ron Economos wrote:
> It's still around. It's just been deprecated. Look in the Deprecated
> category in GNU Radio Companion.
>
> Ron
>
> On 3/28/19 20:01, Andriy Gelman wrote:
> > Hi,
> >
> > It looks that the TCP source block was removed in commit fd1148e8c.
> > Anyone recommend a replacement?
> >
> > Thanks,
> > Andriy

It doesn't seem to be in the deprecated category of the
master branch. See attached figure.

Andriy

Re: [Discuss-gnuradio] Removed TCP source block

It's still around. It's just been deprecated. Look in the Deprecated
category in GNU Radio Companion.

Ron

On 3/28/19 20:01, Andriy Gelman wrote:
> Hi,
>
> It looks that the TCP source block was removed in commit fd1148e8c.
> Anyone recommend a replacement?
>
> Thanks,
> Andriy
>
>
>
>
> _______________________________________________
> 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] Removed TCP source block

Hi,

It looks that the TCP source block was removed in commit fd1148e8c.
Anyone recommend a replacement?

Thanks,
Andriy




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

Re: [Discuss-gnuradio] [Commit-gnuradio] Error while installing GNU Radio Block

Modern GR installs <gnuradio/math.h> ... maybe it contains what this OOT block needs? - MLD

On Thu, Mar 28, 2019, at 9:45 AM, Tawahaa Ahmed wrote:

Hi 

     I am trying to install a costas loop block in GNU Radio whose code was written in C++ by my professor back 2012. Now I have .cc .h .i and .xml files of his code. I am using gr-modtool to make a folder and then adding file in it. After that I edited the newly generated .cc and .h files in lib folder with C++ code provided by my professor. While compiling those files in Linux terminal using cmake ../ and then make command in terminal, I am getting an error (fatal error: gr_math.h: No such file or directory #include <gr_math.h>) whose image is attached. It looks like that camke is trying to find this gr_math.h file in the local out of tree directory but it should be finding it in the main GNU directory. So kindly help me fix this error as I am new to GNU Radio and Linux environment.

Regards

_______________________________________________

Commit-gnuradio mailing list

Commit-gnuradio@gnu.org

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

Attachments:

• Error_costas.png
  

[Discuss-gnuradio] Error while installing GNU Radio Block

Hi 

     I am trying to install a costas loop block in GNU Radio whose code was written in C++ by my professor back 2012. Now I have .cc .h .i and .xml files of his code. I am using gr-modtool to make a folder and then adding file in it. After that I edited the newly generated .cc and .h files in lib folder with C++ code provided by my professor. While compiling those files in Linux terminal using cmake ../ and then make command in terminal, I am getting an error (fatal error: gr_math.h: No such file or directory #include <gr_math.h>) whose image is attached. It looks like that camke is trying to find this gr_math.h file in the local out of tree directory but it should be finding it in the main GNU directory. So kindly help me fix this error as I am new to GNU Radio and Linux environment.

Regards

[Discuss-gnuradio] Fwd: Re: grc file -- display problem

pls reply to below mail

--- Original message follows ---
Subject: Re: [Discuss-gnuradio] grc file -- display problem
From: "Mrs. Parvathi Piduparthi" <pparvathi@narl.gov.in>
To: mueller@kit.edu, discuss-gnuradio@gnu.org
Date: 20-03-2019 21:49



dear  mr marcus

Thanks for the reply . kindly see below

1.  The version of gnu radio is 3.7.10.1 as attached screenshot shows and let us know is it the x axis displaying as 'dB' is due to this version.

2. My intention was as to based on what input level it is  displaying output as -8.83dB in previous mail attached output . I could not understand the mistake you are mentioning. kindly explain again. 

3. that means with ' QT GUI frequency sink' we can be able to get the signal and need to write a python block. As we are very beginners to gnu radio and new to python block writing , request you to kindly give some examples for the same. We would basically want to record continuous  data of signal which is fed to the usrp n210 which we are  processing by means of  gnu radio. 

thanks & regards
Parvathi

On Friday, 15-03-2019 at 15:54 Müller, Marcus (CEL) wrote:

Hi Parvathi!

> 1.  why the screen shot is displaying x-axis and y-axis as dB only
i.e.  2.03dB, -8.83dB.

Displaying the frequency (x-axis) in dB is most definitely a bug. Which
version of GNU Radio are you using (`gnuradio-config-info --version`
has the answer)? We've fixed that a while ago.

Displaying the y-axis in dB is a pretty common thing to do for PSD
estimates.

> 2.   How to interpret the magnitude of the output and on what basis

Not quite sure what you're asking here – that plot is a power density
estimate over frequency. The dB are relative to "full scale".

You're making mistakes when configuring the Qt GUI frequency sink –
your center frequency is simply what the center of your x-axis labeling
is shifted to; since you're dealing with baseband only, it needs to be
zero.

> 3. We would basically want to write the peak of the signal into a
file to record continuously and request you to give an example for the
same.

That sounds like you want a spectral estimator, not a visualization!
So, you wouldn't do that with the Qt GUI frequency sink – which is just
something to look at, not something to generate data.

The operation done by the Qt GUI frequency sink is really just

stream to vector (length=1024) ->
FFT (length=1024) (including windowing) ->
complex to magnitude^2 ->
convert to logarithmic scale

You could do the same, write a small Python block to find the bin with
the maximum value, and write that bin's index to a file. Should be
pretty easy, if you know Python!

Generally, from a scientific point of view, it's questionable whether
this FFT-based route is an appropriate estimator for whatever you want
to do – in the end, you're quantizing your frequency in to FFT-length
number of steps, and you get horrendous leakage effects if a frequency
isn't exactly N·f_sample/L_FFT for some integer N.

But: the frequency estimator suitable for your problem can not be
advised on without knowing which problem you're trying to solve, or
which question to answer in the end.

Best regards,
Marcus

On Fri, 2019-03-15 at 09:48 +0530, Mrs.  Parvathi Piduparthi wrote:
> hello
>
> We have installed gnu radio and working with ubuntu .  Attached is the grc file and its output which basically gets a signal from source and tries to display the fft  of the same as a spectrum. W.r. to these , kindly clarify the following
>
> 1.  why the screen shot is displaying x-axis and y-axis as dB only i.e.  2.03dB, -8.83dB.
>
> 2.   How to interpret the magnitude of the output and on what basis
>
> 3. We would basically want to write the peak of the signal into a file to record continuously and request you to give an example for the same.
>
> thanks &  regards
> Parvathi
> Scientist/Engineer
> National Atmoshperic Research Laboratory , Department of Space
> Gadanki, Tirupathi
> Andhra Pradesh
> India
>
> Ph. 91 877 2500583
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSoC Participation

Hi Martin,

I would like to spawn into an OOT rather than making a merge.

I have mailed the draft for my proposal with another subject "Module for MAC layer development | GSOC'19 Proposal"

The following is the link to the page for my mail in Mail Archive

https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg68199.html  

I have addressed the predicted problem raised by Marcus in my proposal. I am attaching the proposal draft in this email also for your convenience. And yes, it is still a draft and I might need to edit it as per the GSoC Wiki Page. This draft is to mainly float my idea among the community.

I would like to request you to kindly excuse me for my delayed replies.

Regards

Rachuri Sri Pramodh

B. Tech (Hons) 3rd Year

Department of Electrical Engineering and Computer Sciences

IIT Bhilai

On Thu, Mar 21, 2019 at 10:23 PM Martin Braun <martin.braun@ettus.com> wrote:

On Sun, Mar 10, 2019 at 12:43:52AM +0530, Rachuri Sri Pramodh wrote:
>    Hi GNU Radio Community!
>    I am a pre-final year student in Dept of EECS at IIT Bhilai.
>    We were thought about how to use SDRs using GNU Radio during one of our
>    lab courses and also made a small python-code block as an assignment. It
>    was then when I got the idea of making a block for a Datalink layer
>    implementation.
>    The block would have options to configure Framing, MAC, Addressing, Flow
>    and Error control. If this block is properly implemented, one should be
>    able to develop a small wireless network of multiple SDRs. This block will
>    help students who study Wireless Networks in experimenting and applying
>    various MAC models and even make some of their own.
>    Later, when I saw GNU Radio among the list of GSoC's participating
>    companies, I got really excited and wrote this mail. Please let me know
>    your thoughts on this proposal for my GSoC's entry. 
>    I wrote a very brief description of my proposal here and I am ready to
>    submit a very detailed proposal soon if asked for.

Rachuri,

I'll echo everything that Marcus said, and add some more flavour: Most
importantly, you'd need to point out how your project fits into the rest
of GNU Radio. Do you want to spawn an OOT, or merge into the tree? In
the latter case, it's important you understand which blocks already
exist in GNU Radio, and how you want to use or extend them.

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

Re: [Discuss-gnuradio] Block Output as a Variable for Another Block

Hello all,

I tried to add a python block and do the processing, but is not working.

The thing is I need that the exit of my block (a floating type output) becomes a variable, that could be called by other blocks to change parameters of the executing blocks, and I failed to do this with the "Python Block". My questions would be:

1- Is there a sample of a code, where an input becomes a global variable in the Top_Block Code, so it can be called by other blocks?

2- Is there a graphical way (in a flowgraph) for taking an output from a block and making this output as a  global variable for other blocks to read it an change their parameters accordingly?

Once again thanks for all your help.

Kind regards.

On Tue, Mar 26, 2019 at 10:02 AM Luis Felipe Albarracin Sanchez <lfasanchez@gmail.com> wrote:

Thank you Martin,

I will try that and let everybody knows about the result.

Kind regards.

On Thu, Mar 21, 2019 at 12:25 PM Martin Braun <martin.braun@ettus.com> wrote:

On Mon, Mar 18, 2019 at 02:44:30PM -0500, Luis Felipe Albarracin Sanchez wrote:
>    Hello all,
>    I am trying to make the output of a block a variable for other blocks, as
>    explained here:
>    https://lists.gnu.org/archive/html/discuss-gnuradio/2012-02/msg00581.html
>    My flowgraph is as follows:
>    Captura de pantalla 2019-03-18 a la(s) 2.38.42 p. m..png
>    The  configuration of the block "Variable" is:
>    Captura de pantalla 2019-03-18 a la(s) 2.38.54 p. m..png
>    I was wondering if there are other ways for doing this?....Is there a
>    specific control block that changes an output to a variable?.....is there
>    any other way of making an output as a variable?. 
>    Once again, thank you for the help.

Usually, the easiest way is to pipe your output into a Python block, and
then do whatever Pythonic thing you want to do from there.

-- M

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

--

Eng. Luis Felipe Albarracin

Msc. Telematics / MBA
PMP
CCNA/CCDA/CCNP/CCDP/CCIP
ITIL v3 Foundation
"Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"

--

Eng. Luis Felipe Albarracin

Msc. Telematics / MBA
PMP
CCNA/CCDA/CCNP/CCDP/CCIP
ITIL v3 Foundation
"Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"

[Discuss-gnuradio] [UHD] 3.14.0.0 Release Announcement

UHD 3.14.0.0 is now available!  This is an API release spawning the new UHD-3.14 branch.  This API release introduces support for the N320 and N321 USRPs soon to be released (watch for the announcement on ettus.com!), a DPDK-based transport, and several other features and bug fixes.  This release includes all bug fixes and enhancements in the 3.13.0.1, 3.13.0.2, and 3.13.1.0 maintenance releases.

Installers for Windows and Fedora are available here:
http://files.ettus.com/binaries/uhd/uhd_003.014.000.000-release/

The PPA for Ubuntu will be available soon and will be found here:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd

The tag for this release is located here:
https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0

There have been 466 commits since the last API release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0

Please report any bugs found on the UHD issue tracker:

http://github.com/EttusResearch/uhd/issues

* Please do not use the issue tracker for help or support.

Pull requests for direct code changes can be submitted to the UHD or FPGA repositories:

http://github.com/EttusResearch/uhd/pulls

http://github.com/EttusResearch/fpga/pulls

As always, we at Ettus Research would like to thank all of the UHD users in the open source SDR community.  This release contains commits from users in the community that submitted pull requests against the UHD and FPGA repositories as well as many commits that are a direct result of issues reported back to us by users like you through the UHD and FPGA issue trackers, the USRP-users mailing list, and Ettus support.  You have all helped contribute to the continued improvement of UHD.  Thank you!

CHANGELOG:

## 003.014.000.000

* N320: Add support for N320 and N321

* USRP-2974: Add support for USRP-2974

* DPDK: Add DPDK-based sockets-like library (for N3xx)

* N3xx: clocking API changes for transitioning clock and time sources

* N3xx: Bump max rev to G/6

* N3xx: Improve error messages for invalid clock/time settings

* N3xx: Get RFNoC crossbar baseport from FPGA

* N3xx: init peripherals before loading FPGA (to fix SFP0 init issues)

* N3xx: Move Linux kernel to 4.15

* N3xx/E320: Prepend SDK filename with device name

* N3xx: Update max rev to 7 (H)

* N3xx: Remove DDR3 from standard BIST collection

* N3xx: BIST: Improve DDR3 BIST to check for DmaFIFO

* N3xx: BIST: Auto-load the AA image for the ddr3 BIST

* N3xx: BIST: DDR3 test only enumerates first block

* N310: Modify AD9371 reset function to keep it in reset

* N310: move init_rf_cal before JESD de/framer bringup

* N310: Fix sporadic power on failures (requires firmware update)

* E3xx: Increase spp limit for E3xx radio

* E320: bist: Fix ref_clock lock test implementation

* E320: bist: Add link_up test

* E320: Add all 5 temp sensors, fan sensor and rssi sensors per channel

* E320: Fix tx/rx atr - antenna and frequency settings

* E320: Enable devtest for E320

* E320: images: Separate images package for Aurora image

* E320: Get RFNoC crossbar baseport from FPGA

* E320: add fpga_version_hash to e320 device info

* E310: Fix initialization of antenna and frequency values

* E31x: Destruct RFNoC before loading idle image

* X300: Reduce default send_frame_size to 4000 over Ethernet

* X300: Change Ethernet buffering

* X300: Log git hash and compat number as debug message

* X300: Move defaults to their own header

* X300: Use constrained_args

* X300: Enable clock_source and time_source device args

* X300: NIRIO: Demote RPC client cancel/abort to TRACE

* X300: remove default_buff_args properties

* X300: Remove 120 MHz master_clock_rate option

* X300: Set minimum master clock rate to 184.32 MHz

* X300: Factor our PID -> MB type and MB type -> product name mapping

* X300: Remove usage of boost::bind

* X300: Fix compiler warnings related to type conversions

* X300: Fix tick and sample rate setting

* X300: Enable ADC gain through RFNoC API

* X300: Demote NIRIO rpc client start/stop log messages to DEBUG

* X300: Enable 11.52 MHz and 23.04 MHz system ref rates

* X300: Enable x300_device_args.to_string()

* X300: Catch more inconsistencies in x300_device_args

* X300: Removed invalid 200 MHz sysref rate

* X300: Change PLL CP currents in x300_clock_ctrl

* B200: Remove superfluous fake lambda

* B200: Add support for user regs

* B200: Fix compiler warnings related to type conversions

* B100: Move fifo_ctrl_excelsior to b100 subdir

* B100: Fix fifo_ctrl_excelsior not exiting

* B100: Remove all Boostisms from fifo_ctrl_excelsior

* B100: Demote some clocking-related log messages to trace

* MPM: Get list of temperatures from all thermal zones

* MPM: add link_speed xport_info

* MPM: Add __mpm_device__ as usrp_hwd module variable

* MPM: Add usrp_update_fs

* MPM: Add i2c APIs for simple transfers

* MPM: Add vector-based transfer function for i2c

* MPM: Add variable configuration support to nijesdcore

* MPM: Add eyescan utility to nijesdcore

* MPM: Add PRBS-31 testing to nijesdcore

* MPM: Add convenience function to pull i2c bus from device tree

* MPM: Open and close i2c file descriptor on every access

* MPM: Multiprocessing instead of threading for claimer loop

* MPM: Factor out user EEPROM code into own module

* MPM: Add gpgga sensor function to GPSd iface

* MPM: Add bridge mode support

* MPM: Parameterize max UDP link allocation

* MPM: xport: add commit_xport docstring

* MPM: Improve error message on double-claim

* MPMD: Parallelize broadcast-finding

* MPMD: add option to enum rfnoc blocks from args

* MPMD: add link speed to xport udp

* MPMD: Add API to set RPC timeout atomically

* MPMD: Move timeout constants to header

* MPMD: Use new RPC API with timeout

* MPMD: Increase claim_rpc call timeout

* MPMD: implement get_*x_hints

* MPMD: honor user supplied send/recv_frame_size args

* MPMD: Use 4096 bytes for frame size for liberio transport

* MPMD: Use init timeout for update_component

* MPMD: Allow reclaim failures on component updates

* MPMD: Fix typecast warning in property tree default settings

* Device: Parallelize device discovery

* Device3: Move from packet-based to byte-based flow control

* Device3: Constrain send_buff_size to input fifo size

* Device3: remove tx_hint[send_buff_size]

* Device3: Replace NULL with 0 for empty function pointers

* Device3: Remove redundant function call

* Device3: Fix flow control window and interval

* UHD: Release recv buffers earlier in rx_streamer

* UHD: Fix ADF400x driver for ref counter and charge pump mode

* UHD: Improve constrained_device_args_t

* UHD API: Add multi_usrp::get_user_settings_iface()

* UHD: Remove usage of time_t (except when required)

* UHD: add default xport params to udp_zero_copy

* UHD: Update rx_frontend_gen3.v controls for 1/4-rate mixer

* UHD API: Move definition of ALL_MBOARDS and ALL_CHANS constants to

           CPP file.

* UHD: Add traffic counter to null source sink

* UHD API: Add multi_usrp::set_sync_source() API

* UHD: Improve documentation for the UHD exception types

* UHD: Improve documentation for set_{time,clock,sync}_source

* UHD: add .clang-format file

* UHD: Add device arg to enable dual ethernet for tx

* UHD API: Add sync source to Python API

* UHD API: Add support for Tx LO control to C API

* UHD: Improve compatibility of abs() calls

* UHD: include <stdint.h> for int64_t for time_spec

* UHD: Updates to coding guidelines

* UHD: Fix MSVC warnings by changing a size_t to unsigned int or

       uint32_t

* UHD: Add potentially missing but sometimes inferred include for

       experts

* UHD: Add default xport params to udp_wsa_zero_copy

* UHD: Move device3 flow control functions to header for benchmark

       utility

* UHD: Make sure BOOST_VERSION is always available

* UHD: Make clang-format skip formatting for some data structures

* UHD: Remove vim hints in headers

* UHD/MPM: Apply clang-format to all files

* UHD: Add modified clang-format for headers

* UHD: Replace uhd::math::log2 with std::log2

* UHD: Replace boost::*::{lcm,gcd}() with portable versions

* UHD API: Change get_{tx/rx}_dc_offset_range default from ALL_CHANS

           to 0

* UHD: Revert to boost instead of std for sleep in some instances

* UHD: Replace Boost macros with custom ones for endianness

* UHD: muxed_zero_copy_if fixes

* UHD: Replace Boost lock & mutex with std variety for AD9361 code

* UHD: fix includes for boost::noncopyable

* UHD: Fix buffer size warning on UDP transport

* UHD: Remove duplicate operator=() for sid_t

* UHD: Fix conversion warning in max287x

* UHD: Fix various type-conversion compiler warnings

* RFNoC: Convert SR_READBACK_REG_FIFOSIZE to bytes

* RFNoC: Add ability to enable/disable RX timestamp

* RFNoC: add async message handler

* RFNoC: Changes to traffic counter register names

* RFNoC: Fix replay example port args

* RFNoC: Fix default SPP for replay

* RFNoC: Add halt to replay API

* RFNoC: Fix late packet errors

* RFNoC: Fix detection of outstanding acks by ctrl_iface

* RFNoC: Add some missing virtual destructors

* RFNoC: Update FIFO XML definition

* RFNoC: Prevent unnecessary FC ACK packets

* RFNoC: More graph traversal fixes

* RFNoC: Fix scaling of M and N values in DDC/DUC

* RFNoC: Fix typos in legacy_compat

* RFNoC: Limit number of control packets in flight

* RFNoC: Disable FC ACK packets for lossless links

* RFNoC: Add valid num_input_ports check to node_ctrl_base

* Utils: Add Zip test to downloader

* Utils: Factor wait_for_lo_lock() out of cal utils

* Utils: Add check for gdb_eeprom before accessing

* Utils: Deny positional options in uhd_image_loader

* Utils: Set tx gain to max for rx iq cal

* Tools: Add tool to analyze settling time of gain and freq changes

* Tools: Make the UHD source gen a plugin for the phase alignment test

* Test: Add Python API test

* Test: Integrate Python API Tester into Devtest

* Test: Add graph impl test to device3_test

* Test: Retrofit sph test to use new mock transport

* Test: Enable rx_samples_to_file in devtest for X300

* Test: Fix CMake `endif` warning for devtest

* Test: Fix compiler warning about unused timestamp

* Test: Add #include <thread> in system time test

* Test: Add benchmark of streaming code paths

* Test: replace has_key by using 'in'

* Test: Add universal_newlines to subprocess call in devtest

* Examples: add rfnoc_radio_loopback example

* Examples: Add benchmark_streamer example

* Examples: Add dual measurements to benchmark_streamer

* Examples: Clean up rfnoc_radio_loopback example

* Examples: Add keyboard controls to rx_ascii_art_dft

* Examples: Add benchmark_streamer support for multi-channel streamer

* Examples: Optimize benchmark_rate start time

* Examples: Improve formatting and comments in tx_waveforms

* Examples: Optimize tx_waveforms memory allocations

* Examples: change boost to std for time commands

* Examples: Add LO Offset to rx_samples_to_file

* Examples: update lo-offset naming in tx from file

* Examples: Add lo-offset to tx_waveforms

* Examples: Improved error message in tx_waveforms

* Examples: Move ascii_art_dft main function within include guard

* Examples: Fix boundary condition in ascii_art_dft plotting

* Docs: Fix Doxygen warnings

* Docs: Add info on how to implement user regs on B200

* Docs: Add manual page on compat numbers

* Docs: Add comments for TwinRX and MCR

* Docs: N3xx page shell formatting and bb image

* Docs: n3xx: fix Salt formatting

* Docs: Add note on manually disabling NEON extensions

* Docs: Fixed typos in N3xx image names (SD card build)

* Docs: Add notes on external reference frequencies for X300

* CMake: Bump CMake minimum version to 2.8.12

* CMake: Change SOVERSION and VERSION for the library files

* CMake: Extend list of additional Boost versions

* CMake: fix variable usage

* Cmake: remove Boost from dyn libs for tests on Apple

* Cmake: Fix MSVC options (add /bigobj)

* Cmake: Use native format for setup.py

* CPack: Fix RPM generation

## 003.013.001.000

* E320: Fix front panel GPIO readback

* E320: Fix master_clock_rate setting

* E320: Print extra ouptut for ref_clock BIST

* E320: Fix gps_locked type

* E320: Fix return value of get_fpga_type()

* N3xx: Enable setting clock and time sources at runtime

* N3xx: Add ref_clock BIST

* N3xx: Improve set_time_source() and set_clock_source()

* N3xx: Add exception for init failure

* N3xx: Remove HA, XA images packages

* N3xx: Change init() procedure to reduce configuration time

* N310: Add frequency bounds

* N310: Fix RX antenna mapping

* N310: Add log messages when re-initializing dboards

* N310: Add skip_rfic argument to reduce time of BIST

* N310: Add initialization of TX bandwidth

* E310: Fix initialization of antenna and frequency values

* E310: Type-cast fix for Boost

* X300: Improve firmware compat error message

* X300: Updated niusrprio driver

* X300: Add recovery for duplicate IP addresses in EEPROM

* X300: Prevent duplicate MAC and IP addresses from being programmed

* X300: New mode to configure master clock rate

* X300: Implement RFNoC get antenna functions

* B2xx: Fix values of MASK_GPIO_SHDN_SW and GPIO_AUX_PWR_ON in firmware

* B2xx: Revert changes to DSP core to fix scaling factor adjustment

* B2xx: Restore asynchronous reset of AD936x

        (fixes LIBUSB_TRANSFER_OVERFLOW and unexpected sid errors)

* TwinRX: enable ch1 lo amps if ch2 is using an external lo source

* TwinRX: Correctly initialize antenna mapping on X300

* TwinRX: Revise ADF5356 frac2 register calculation to prevent drifting spurs

* TwinRX: Fix initialization

* TwinRX: Tuning improvements

* TwinRX: Enable phase resync on ADF535x

* TwinRX: Make routing to LO1 and LO2 mutually exclusive

* BasicRX/LFRX: Fix real mode in rx_frontend_core_3000

* UHD: Define UHD_API as empty string when building static lib

* UHD: Changed to 'all_matching' endpoint resolution for udp_simple transport

* UHD: Add CMake flag for NEON SIMD

* UHD: Fix usb_dummy_impl compilation in MSVC

* UHD: Reconcile time_spec operators with boost concepts

* UHD: Fix rounding in ddc/duc rate calculation

* UHD: Increase MPMD RPC timeout when calling set_time_source()

* UHD: Fix RX streamer SOB and EOB handling

* UHD: Add UHD_SAFE_CALL to block_ctrl_base destructor

* UHD: Change SOVERSION to ABI string and VERSION to full UHD version

* UHD: Update cmake style to use lower case commands

* UHD: Add SOURCE_DATE_EPOCH

* UHD: Improve logic for UHD_IMAGES_DIR

* UHD: Add RUNTIME_PYTHON_EXECUTABLE

* UHD: Fix return value of get_rolloff() for filters

* UHD: Properly register devtest

* UHD: Fix log statement for Port number on RFNoC block

* UHD: Use "MATCHES" instead of "STREQUAL" for "Clang"

* UHD: Fix GPGGA string formatting for gpsd

* Device3: Set default block control response SIDs

* Device3: Fix block control flushing

* RFNoC: Improved flushing mechanism in noc_shell and dma_fifo

* RFNoC: Install missing dma_fifo_block_ctrl header

* RFNoC: Replace some [] with .at() in radio_ctrl_impl

* RFNoC: Fix graph traversal

* MPM: Add Git hash, version to device info

* MPM: Reset the RPC server upon reload

* MPM: TDC: Update PDAC BIST and flatness test to use latest APIs

* MPM: Fix handling of 0-valued dt-compat

* MPM: Fix GPSD sensor names for N3xx and E320

* MPM: Add args to update_ref_clock_freq to properly support dynamic setting

*      of clock and time references

* MPM: Fix Pylint warnings

* MPM: Identify sysfs gpios more generically

* MPM: Add lock_guard() function

* MPM: Factor E320 and N3xx BIST code into common module

* MPM: Add gpsd error handling

* MPM: Add FPGA git hash to device info

* MPMD: Increase RPC timeout during readng mb sensor

* MPMD: Improve error message for compat number mismatches

* Python API: Enable Python API on Windows

* Python API: Change .dll to .pyd for Win32

* Python API: Fixing Boost.Python initializer visibility

* Python API: Fix duration of benchmark rate

* Python API: Add missing constructors of time_spec_t

* Python API: Expose streamer timeouts

* Python API: Tighten the scope of releasing the GIL

* Python API: Add device_addr_t

* Python API: Populate the tune_result_t binding

* Utils: Many fixes and enhancements for uhd_images_downloader

* Utils: Update query_gpsdo_sensors to work on E310

* Examples: Removed some legacy code patterns from RFNoC examples

* Examples: Fix channel argument for rx_samples_to_file

* Examples: Fix benchmark_rate MIMO synchronization

* Examples: Add phase alignment example

* Examples: Fix RX antenna not being applied in txrx_loopback_to_file

* Test: Add more env vars, make Py3k compatible

* Test: Add multi_usrp_test.py to devtest

* Test: Clean up, refactor, and improve devtest

* Test: Enable rx_samples_to_file in E320 devtest and N3xx devtest

* Test: Reduce sample rate for E320 1G devtest

* Test: Add unit test for eeprom_utils

* Docs: Add clock_source and time_source to n3xx argument list and fix WR clock_source call

* Docs: Minor tweaks to the Python API manual page

* Docs: Add E320 test procedures

* Docs: Added TwinRX page

* Docs: Fix N210 MIMO Phase Alignment test command

* Docs: Add E320 information

* Docs: Improve sections on clock/time references

* Docs: Add section on X300 motherboard clocking

* Docs: Add more information on Salt for N3xx and E320

* Docs: Adjust E310 functional verification tests

* Docs: Add documentation on GIL release

* Debian: Update control files

* Images: Add N3xx CPLD file to manifest

## 003.013.000.002

* N3xx: Fix issue where changing the clock/time source could result in

        clocks becoming unlocked

* N3xx: Improve error messages for invalid clock/time settings

* N3xx: Add support for Rev G mboard

* MPM: Add function parameter to support holding AD9371 in reset

* Docs: Add section on building fs/SD images for N3xx

* Docs: Fix Doxygen warnings

## 003.013.000.001

* N3xx: Fix UIO usage in Aurora BIST

* N3xx: Fix EEPROM parsing (for upcoming hardware)

* UHD: Fix install path for Python API

Best regards,

Michael

[Discuss-gnuradio] Software Defined Radio Academy 2019

Dear lists,

please find our Call for Papers below.

BR / vy73
Markus Heller, M.A. DL8RDS
Prof. Dr. Michael Hartje DK5HH

>
>
> >
> >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
** apologies for cross-posting **
Call for Papers: SDRA-2019 Friedrichshafen

HAMRADIO Friedrichshafen Software Defined Radio Academy 2019 (SDRA-
2019)

Date: Saturday 22.06.2019

Conference Websites:

    http://www.hamradio-friedrichshafen.de
    http://2019.sdra.io

SDRA-2019 invites radio amateurs and researchers from acadaemia and
industry to submit papers for oral and poster presentations on recent
research that addresses theoretical aspects, algorithms, applications,
hardware and software architectures for applied Software Defined Radio
systems and resources and other aspects of SDR, as well as survey and
discussion papers. The invitation particularly addresses open source
research and projects. We also particularly invite specialists giving
introductory talks and tutorials on SDR technologies.
SDRA Topics:

    Advances in GNURadio related projects and research
    Algorithms, applications, architectures in SDR systems
    Real Time signal processing
    Innovative applications using modern ADC/DAC environments

Submission Information

How to submit: Please send an abstract of approximately 250 words to:

sdra@darc.de

Please include the following information:

    Paper title
    Author's name (and callsign). Names and callsigns of all authors if
multiple authors.
    Author's affiliation
    Country
    Email address of the main author

All accepted papers will be published. Publication details will be
available at a later point of time.

We ask authors to keep a limit of 6 pages. If there is a reason why the
paper should be longer, please contact us.

We also solicit Posters and Demo papers: Poster/Demo papers describe a
small focused result, a negative result, or a late-breaking result, or
a description of a system that can be demonstrated on-site at the
conference.

Papers should be formatted using the IEEE A4 templates: http://www.ieee
.org/conferences_events/conferences/publishing/templates.html
Organization

    Prof. Dr. Michael Hartje, DK5HH
    Markus Heller, M.A., DL8RDS

Senior Programme Committee

    Prof. Dr. Michael Hartje, HS Bremen, DK5HH
    Prof. Dr. Michael Niemetz, OTH Regensburg, DG2RAM
    Prof. Dr. Michael Mächtel, HTWG Konstanz, DL2SBS

Important Dates:

    Abstract Submission: 31.03.2019
    Acceptance Notification: 15.04.2019
    Presentation Slides: 31.05.2019
    Paper Presentation: 22.06.2019
    Paper Submission: 31.07.2019

Contact

For enquiries and paper submission details please do not hesitate to
contact us:

Email: sdra@darc.de Tel.: +49.89.420956305-0

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

Re: [Discuss-gnuradio] Block Output as a Variable for Another Block

Thank you Martin,

I will try that and let everybody knows about the result.

Kind regards.

On Thu, Mar 21, 2019 at 12:25 PM Martin Braun <martin.braun@ettus.com> wrote:

On Mon, Mar 18, 2019 at 02:44:30PM -0500, Luis Felipe Albarracin Sanchez wrote:
>    Hello all,
>    I am trying to make the output of a block a variable for other blocks, as
>    explained here:
>    https://lists.gnu.org/archive/html/discuss-gnuradio/2012-02/msg00581.html
>    My flowgraph is as follows:
>    Captura de pantalla 2019-03-18 a la(s) 2.38.42 p. m..png
>    The  configuration of the block "Variable" is:
>    Captura de pantalla 2019-03-18 a la(s) 2.38.54 p. m..png
>    I was wondering if there are other ways for doing this?....Is there a
>    specific control block that changes an output to a variable?.....is there
>    any other way of making an output as a variable?. 
>    Once again, thank you for the help.

Usually, the easiest way is to pipe your output into a Python block, and
then do whatever Pythonic thing you want to do from there.

-- M

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

--

Eng. Luis Felipe Albarracin

Msc. Telematics / MBA
PMP
CCNA/CCDA/CCNP/CCDP/CCIP
ITIL v3 Foundation
"Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"

Re: [Discuss-gnuradio] OOT modules on Android

Hey Laura -

Yes, you can build OOTM for use on Android - you'll just have to build them using a manual process (e.g., Android Studio) rather than something more automatic like PyBOMBS.

Keep us posted on your progress! Excited to hear you'll be working on this =)

Cheers,

Ben

On Tue, Mar 26, 2019 at 1:21 AM Laura Arjona <arjonal@uw.edu> wrote:

Thank you very much Ben,

The OOT blocks that I want to run in Android are written in C++ entirely.

My question is related to your comment "as long as they are built appropriately".

That is, if it is possible to build OOT blocks to use in Android. But reading your message, I assume that is possible. 

I knew the link, thanks, but haven't started the android project yet, staring this week. Excited to start my project.

Thanks

 

On Mon, Mar 25, 2019 at 11:11 AM Ben Hilburn <bhilburn@gnuradio.org> wrote:

Hi Laura -

Sorry for the delayed response, here.

So, I'm not entirely sure I understand your question, actually. Once GNU Radio is running in Android, using blocks from any module, in- or out-of-tree, shouldn't be a problem as long as they are built appropriately. Are you asking if you need to re-write Python-only blocks in C++? If the OOTM only provides Python blocks, then yes, you'll want to put those into C++ for use on Android.

Also, I assume you've already seen the pages linked here, which provide a lot more detail on that build process -- although the information is pretty severely dated at this point, and almost certainly won't work as-is.

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

Cheers,

Ben

On Fri, Mar 22, 2019 at 12:36 PM Laura Arjona <arjonal@uw.edu> wrote:

I might have been thinking about this in the wrong way.

The way to proceed would be to re-write the blocks in Android studio, using C++?

(instead of importing the blocks created with gr-modtool)

Thank you and good weeked! 

On Thu, Mar 21, 2019 at 7:44 PM Laura Arjona <arjonal@uw.edu> wrote:

Hi everyone,

 

I want to build an Android App to communicate with an USRP B200-mini,  and this app should use one OOT module with several oot blocks.

How should I proceed to import my OOT module? 

Thank you

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

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

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

Re: [Discuss-gnuradio] howto create multiple carriers with usrp

A multiply constant block is needed to reduce the level for actual transmission with an SDR. It should be set to 1 / (number of active carriers).

Also an odd number of carriers produces a cleaner spectrum. Updated flow graph attached.

Ron

On 3/26/19 04:55, Ron Economos wrote:

Just use an inverse FFT. Flow graph attached.

In the vector source, just zero out carriers you don't want.

Ron

On 3/26/19 00:45, on4bhm@telenet.be wrote:

Hi group,

I want to create 10 or 20 or 30 carriers all spaced evenly at 250Khz apart.

How can i do this, any tips?

thanks

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

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

Re: [Discuss-gnuradio] howto create multiple carriers with usrp

Just use an inverse FFT. Flow graph attached.

In the vector source, just zero out carriers you don't want.

Ron

On 3/26/19 00:45, on4bhm@telenet.be wrote:

Hi group,

I want to create 10 or 20 or 30 carriers all spaced evenly at 250Khz apart.

How can i do this, any tips?

thanks

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

Re: [Discuss-gnuradio] howto create multiple carriers with usrp

Use a polyphase filterbank. It's not runtime reconfigurable in GR, but if you create the correct spacing with the max you'll ever need then you can always optionally direct the output of some to a null sink. Hope this is useful! - MLD

On Tue, Mar 26, 2019, at 3:46 AM, on4bhm@telenet.be wrote:

Hi group,

I want to create 10 or 20 or 30 carriers all spaced evenly at 250Khz apart.

How can i do this, any tips?

thanks

_______________________________________________

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

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

[Discuss-gnuradio] Runtime error

Hi Everyone.

can u please let me know how to solve runtime error issue and also somtimes device serial number not found.

Thanking you

Regards:

Khwaja

[Discuss-gnuradio] howto create multiple carriers with usrp

Hi group,

I want to create 10 or 20 or 30 carriers all spaced evenly at 250Khz apart.

How can i do this, any tips?

thanks

Re: [Discuss-gnuradio] OOT modules on Android

Thank you very much Ben,

The OOT blocks that I want to run in Android are written in C++ entirely.

My question is related to your comment "as long as they are built appropriately".

That is, if it is possible to build OOT blocks to use in Android. But reading your message, I assume that is possible. 

I knew the link, thanks, but haven't started the android project yet, staring this week. Excited to start my project.

Thanks

 

On Mon, Mar 25, 2019 at 11:11 AM Ben Hilburn <bhilburn@gnuradio.org> wrote:

Hi Laura -

Sorry for the delayed response, here.

So, I'm not entirely sure I understand your question, actually. Once GNU Radio is running in Android, using blocks from any module, in- or out-of-tree, shouldn't be a problem as long as they are built appropriately. Are you asking if you need to re-write Python-only blocks in C++? If the OOTM only provides Python blocks, then yes, you'll want to put those into C++ for use on Android.

Also, I assume you've already seen the pages linked here, which provide a lot more detail on that build process -- although the information is pretty severely dated at this point, and almost certainly won't work as-is.

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

Cheers,

Ben

On Fri, Mar 22, 2019 at 12:36 PM Laura Arjona <arjonal@uw.edu> wrote:

I might have been thinking about this in the wrong way.

The way to proceed would be to re-write the blocks in Android studio, using C++?

(instead of importing the blocks created with gr-modtool)

Thank you and good weeked! 

On Thu, Mar 21, 2019 at 7:44 PM Laura Arjona <arjonal@uw.edu> wrote:

Hi everyone,

 

I want to build an Android App to communicate with an USRP B200-mini,  and this app should use one OOT module with several oot blocks.

How should I proceed to import my OOT module? 

Thank you

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

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

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

Re: [Discuss-gnuradio] [Announcement] Ctrlport is broken -> potential candidate for removal in 3.8 -> RPC discussion

Hi, I use the control port, or at least I'm trying to... But I can only use and see the performance counters, I can never see the graphical representation on the proves that I use, and that will be so useful for my dissertation thesis.

On Mon, 25 Mar 2019 at 08:44, Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Hi Johannes!

let me answer in-text real quick:
On Mon, 2019-03-25 at 10:13 +0000, Johannes Demel wrote:
> Hi Marcus,
>
> it seems like Thrift is a painful dependency. So, this is a pro
> ctrlport
> removal. Though, what else does ctrlport removal entail?

Removal of Ctrlport and the tools dependent on it.

> Is it really only used for monitoring and control?

I'm only speaking for in-tree code, but yes.
Speaking for the whole ecosystem: I'm by now aware of 1 (one) external
project that uses CtrlPort. We're in contact.

> Just for clarification, the zeromq blocks are not affected?

Not affected.

> How will the performance monitor be preserved?

At this point, I have no clue. Suggestions welcome!

>  I really like to look at
> the statistics to get a first idea where to look for problems and
> analyze my system with it.

That's a fair point. But to be honest, you don't really need an RPC
framework running in a separate process to query perfcounters, do you.
A very valid model would be having a tiny perfcounter-server (e.g.
behind a req/rep zeromq socket). It wouldn't be a general RPC
framework, but it could do ctrlport's job for this very limited scope!

>
> Also, in case ctrlport is removed, we should have a GREP to discuss
> what
> we want and how we want ctrlport back in some other form.

YESSSS! Want to (co)author that?

Best regards,
Marcus

>
> Cheers
> Johannes
>
> Am 24.03.19 um 20:26 schrieb Marcus Müller:
> > Dear GNU Radio community,
> >
> > we've got an outstanding breakage in our controlport
> > infrastructure.
> > Since fixing it seems to involve architectural changes to what
> > controlport does, and since making these changes would quite
> > possibly
> > break the semantics of using controlport anyway, we're considering
> > removing Controlport from the GNU Radio 3.8 release (this does NOT
> > apply to 3.7).
> >
> > The negative effect of that would obviously be that we'd lose
> > controlport (which I'm not going to introduce here; if you don't
> > know
> > what it is, you haven't been using it). We would *not* lose the
> > performance counters, just the default way of querying them.
> >
> > The most important upside would be the ability to remove the Apache
> > thrift dependency. Thrift has been the single worst thing we've
> > relied
> > on for as long as I can remember in terms of availability and
> > consistency across platforms. In fact, different distros build
> > completely different configurations of thrift, and noone seems to
> > be
> > able to build a "fully featured" thrift.
> >
> > Another aspect to this is that albeit controlport is pretty cool in
> > theory – an adaptable RPC server within GNU Radio, with pluggable
> > RPC
> > backends – its adoption has been slow to say the least, and it
> > doesn't
> > really tie neatly into any GNU Radio applications I'd be aware of.
> >
> > So, lest someone fixes the bug (I'll be describing it below), I'd
> > recommend we remove Controlport alltogether, and remove the thrift
> > dependency. I still stand by the very idea of controlport – having
> > RPC
> > access to what a flow graph does – but in the end, there's a
> > discussion
> > that we need to have:
> >
> > How do we want to do RPC in a way that enables us to make GNU Radio
> > far
> > more machine-agnostic than it is? How does one not only allow for
> > gathering of statistics and calling of functions, but build an RPC
> > framework that makes heterogeneous and distributed GNU Radio really
> > feasible?
> >
> > We've been addressing the question of what the scheduler needs to
> > become at the heterogeneous compute working group at GRCon'18. To
> > conclude, we need to get away from the "one buffer type fits all"
> > and
> > "all blocks are born equal and are just individual OS threads"
> > towards
> > domain-specific subschedulers and buffer managers. This is where
> > this
> > needs to tie in.
> >
> > Hence: Is anyone seriously using ControlPort and needs it for 3.8?
> > Please raise a metaphorical hand on the mailing list or write a
> > private
> > one in response to this email.
> >
> > Best regards,
> > Marcus
> >
> > ----------------------------------
> >
> > Bug: clang correctly has been complaining for quite a while now
> > that
> > the RPCAggregator stores a reference to a temporary object. It
> > seems
> > that in the past this just worked by chance – probably, libc never
> > really got around to reassign the memory of these temporary objects
> > and
> > all lived happily everafter. However, now on multiple platforms, we
> > just see aborts in various tests due to access to freed memory.
> > Probably memory protection just got smart enough to kick some sense
> > into this code.
> > All is fine as long as one doesn't actually use the code in
> > question.
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC freezing and showing stream of "LLLLLL"

Hello,

I was recently working on a flowgraph, which involved using both a USRP Source, USRP Sink block and a QT fosphor sink block, and when running my flowgraph, GRC froze and displayed a stream of "LLLLLLLLL". I noticed that if I replaced my QT fosphor sink with a QT GUI Frequency sink, the problem goes away. I just wanted to know if anyone could tell me what this stream of "LLLL" means and how does someone typically fix their flowgraph to stop this? If it helps, I am using on a Ubuntu 16.04 system and am running GNU Radio 3.7.12.

Thanks,

Jose Ruvalcaba