Re: [Discuss-gnuradio] GNU Radio 3.8 for Windows

[Geof Nieboer]

Pol,

That's great work!  I am the maintainer of the Win10 binaries you
mentioned, and while the scripts are currently capable of building 3.8
in Win10, I have delayed a binary release to allow a bit more time for
some more of the "add-on" packages to become compatible with 3.8 and
GRC specifically.  I suppose this should encourage me to "get on with
it" :)

Geof

On 10/2/19, Pol Henarejos  wrote:
> Dear all,
>
> I have been using GNU Radio since 3.2 series and the progress made in
> last years is amazing. I used to develop GNU Radio apps in linux but,
> sometimes, I also did it in Windows (specially for quick tests).
> However, I could not find the binaries of the 3.8 series and the
> documentation for Windows build is for prior releases.
>
> Finally, I managed to build it natively in Windows 10 (it should work in
> Windows 7 too).
>
> If someone is interested, the binaries for Windows can be downloaded
> from https://www.castle.cloud/gnuradio-for-windows
>
> This is the list of available modules:
>
> + python-support
> + testing-support
> + gnuradio-runtime
> + gr-ctrlport
> + gnuradio-companion
> + gr-blocks
> + gr-fec
> + gr-fft
> + gr-filter
> + gr-analog
> + gr-digital
> + gr-dtv
> + gr-audio (windows)
> + gr-channels
> + gr-qtgui
> + gr-trellis
> + gr-uhd
> + gr-utils
> + gr_modtool
> + gr-vocoder
> + gr-zeromq
>
> I cannot build gr-wavelet and gr-video-sdl due to some fails with SDL
> and GSL libraries.
>
> Please, note that the license belongs to the GNU Radio. I only
> repackaged the official release, without any modification.
>
> Any feedback is also appreciated.
>
> Thank you for your incredible efforts!
>
> Regards.
>
> --
>
> Dr. Pol Henarejos
> Researcher
> Array and Multi-Sensor Processing Department, Communication Systems
> Division
> pol.henare...@cttc.cat
>
> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00  Ext: 2177
> www.cttc.cat
>
> Your identification data and the data contained in the emails and
> attached files can be incorporated into our databases, in order to
> maintain professional and / or commercial relationships, and that it
> will be preserved throughout the relationship. You can exercise your
> right to access, rectification, erasure, restriction of processing, to
> portability and to object by sending an email to d...@cttc.cat.
> This message and any attached document, where appropriate, may be
> confidential and intended for the original recipient only.
>
>


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

[Discuss-gnuradio] GNU Radio 3.8 for Windows

[Pol Henarejos]

Dear all,

I have been using GNU Radio since 3.2 series and the progress made in 
last years is amazing. I used to develop GNU Radio apps in linux but, 
sometimes, I also did it in Windows (specially for quick tests). 
However, I could not find the binaries of the 3.8 series and the 
documentation for Windows build is for prior releases.


Finally, I managed to build it natively in Windows 10 (it should work in 
Windows 7 too).


If someone is interested, the binaries for Windows can be downloaded 
from https://www.castle.cloud/gnuradio-for-windows


This is the list of available modules:

+ python-support
+ testing-support
+ gnuradio-runtime
+ gr-ctrlport
+ gnuradio-companion
+ gr-blocks
+ gr-fec
+ gr-fft
+ gr-filter
+ gr-analog
+ gr-digital
+ gr-dtv
+ gr-audio (windows)
+ gr-channels
+ gr-qtgui
+ gr-trellis
+ gr-uhd
+ gr-utils
+ gr_modtool
+ gr-vocoder
+ gr-zeromq

I cannot build gr-wavelet and gr-video-sdl due to some fails with SDL 
and GSL libraries.


Please, note that the license belongs to the GNU Radio. I only 
repackaged the official release, without any modification.


Any feedback is also appreciated.

Thank you for your incredible efforts!

Regards.

--

Dr. Pol Henarejos
Researcher
Array and Multi-Sensor Processing Department, Communication Systems Division
pol.henare...@cttc.cat

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00  Ext: 2177
www.cttc.cat

Your identification data and the data contained in the emails and 
attached files can be incorporated into our databases, in order to 
maintain professional and / or commercial relationships, and that it 
will be preserved throughout the relationship. You can exercise your 
right to access, rectification, erasure, restriction of processing, to 
portability and to object by sending an email to d...@cttc.cat.
This message and any attached document, where appropriate, may be 
confidential and intended for the original recipient only.




smime.p7s
Description: Signatura criptogràfica S/MIME
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU-Radio Companion Python flowgraph - return signal that it is finished?

[Kevin Reid]

On Mon, Sep 30, 2019 at 8:02 AM Andrew Payne  wrote:

> I always do a tb.stop() followed by a tb.wait(), because I assume that
> .stop() is not blocking but .wait() is blocking


Yes, this is correct.

If you call stop() then wait() you stop the flow graph and wait for the
threads to actually shut down after they are commanded to. If you call
wait() then stop() then you also wait for the flow graph to finish its work
rather than stopping it early.

and this is the best practice way to prematurely stop a flowgraph.  Or is
> the .wait() necessary?


You must call wait() if you want to call start() again, or if you want to
wait for the threads to actually stop (which blocks *may* react to by
releasing resources or other cleanup actions).

In my programming I make a habit of always calling stop() and wait()
together, in whichever order suits the application.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU-Radio Companion Python flowgraph - return signal that it is finished?

[Andrew Payne]

Thanks Kevin. I ended up calling the python method os.stat.st_size on
the IQ file that the flowgraph will transmit, converted that file size
to a time duration in seconds considering the sample size and rate,
start the flowgraph, then have a sleep function that checks for a flag
every 100 milliseconds to stop the flowgraph if necessary.  I always
do a tb.stop() followed by a tb.wait(), because I assume that .stop()
is not blocking but .wait() is blocking and this is the best practice
way to prematurely stop a flowgraph.  Or is the .wait() necessary?

Thanks.


On Sat, Sep 28, 2019 at 10:43 PM Kevin Reid  wrote:
>
> On Sat, Sep 28, 2019 at 6:34 PM Andrew Payne  wrote:
>>
>> I have a short IQ file that I simply want to play once without repeating, 
>> and I want the calling Python code to "know" when it's completed after 
>> commanding the GR class instance to start via a call to tb.start(), if tb is 
>> the class instance variable.
>
>
> Call
> tb.start()
> tb.wait()
> tb.stop()
> in that order. The call to wait() will block until the flow graph finishes.
>
> If you need to do something else while waiting, you can create another thread 
> from Python (threading.Thread) and either have it call tb.wait() or have it 
> do the other work, whichever suits your application.

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

Re: [Discuss-gnuradio] GNU-Radio Companion Python flowgraph - return signal that it is finished?

[Kevin Reid]

On Sat, Sep 28, 2019 at 7:46 PM Andrew Payne  wrote:

> Understood. I do need to thread that tb.wait() because I have a callback
> to start the flow graph and a callback to stop the flow graph.  Say I start
> then wait for it in an independent thread.  Then say a different thread
> decides to stop it. How should the first thread that is waiting handle it?
> Would the results be unknown?
>

[Please make sure to always send your messages to the mailing list when
replying.]

I don't know the answer to what would happen; what I would *hope* would
happen is that the wait() returns as soon as it is stopped by either means.
That would be consistent with other behavior (e.g. if you reuse a
flowgraph, you must call wait() *after* stop() (to wait for cleanup, if
any) before start()ing again.)

I encourage you to try it out.

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

Re: [Discuss-gnuradio] GNU-Radio Companion Python flowgraph - return signal that it is finished?

[Kevin Reid]

On Sat, Sep 28, 2019 at 6:34 PM Andrew Payne  wrote:

> I have a short IQ file that I simply want to play once without repeating,
> and I want the calling Python code to "know" when it's completed after
> commanding the GR class instance to start via a call to tb.start(), if tb
> is the class instance variable.
>

Call
tb.start()
tb.wait()
tb.stop()
in that order. The call to wait() will block until the flow graph finishes.

If you need to do something else while waiting, you can create another
thread from Python (threading.Thread) and either have it call tb.wait() or
have it do the other work, whichever suits your application.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU-Radio Companion Python flowgraph - return signal that it is finished?

[Andrew Payne]

Hello,

I am writing a program in Python to interface with a simple file
source to USRP sink flowgraph.

I have a short IQ file that I simply want to play once without
repeating, and I want the calling Python code to "know" when it's
completed after commanding the GR class instance to start via a call
to tb.start(), if tb is the class instance variable.  I came across
the C++ GR API here:
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a89242cb1ac9d2bf5e75f923745baa576

^ That shows there's a gr.finished() boolean return that tells you
when the flowgraph is done, but evidently .finished is not an
attribute of tb.  The only methods that worked for me are
tb.start/tb.run, tb.wait, tb.stop.

I'd also be happy with polling the GR class instance for the
noutput_items from the work function of the USRP_sink block. I know
the file size so I can have a while loop with the noutput_items value
as a condition, but how do I do that in Python?  I think I am getting
close with these 2 results from Google but still not getting it:
1) 
https://stackoverflow.com/questions/50938245/gnuradio-number-of-output-items/50943105
2) 
https://stackoverflow.com/questions/32305813/gnuradio-how-to-change-the-noutput-items-dynamically-when-writing-oot-block

Thanks,
Andrew

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

[Discuss-gnuradio] GNU Radio Project Call Today!

[Martin Braun]

Hi all,

we have the monthly project call for GNU Radio on today, at the usual time
(10 AM Pacific, 19:00 EU, 1 PM Eastern, other timezones please do your own
math).

Please join us on IRC or Slack where we'll post the link to the call
shortly before it starts.

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

[Discuss-gnuradio] GNU Radio & RFNoC Workshops in Boston This Week

[Neel Pandeya]

==
*** Announcing Workshops in the Boston Area ***

* Tomorrow (Tuesday) -and- Thursday *

 Ettus Research will be running two free, hands-on, technical
 workshops in the Boston area, and you are welcome to attend!

  GNU Radio Workshop
Tuesday June 11
 Woburn, Massachusetts

RFNoC Workshop
   Thursday June 13
NEWSDR at UMass-Boston
Boston, Massachusetts

==
 *** GNU Radio Workshop ***

   Tuesday June 11
   09:00 to 17:00

National Instruments
  800 Cummings Park Drive
  Woburn, MA 01801
 (I-93, Exit 36, Washington Street)

Breakfast and Set-up start at 08:30
 Workshop runs from 09:00 to 17:00

 To register, please send email to:
   "haydn.nel...@ni.com"

Full Title:
Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain)

Abstract:
This workshop will provide a thorough and practical introduction to
the USRP hardware and the open-source software toolchain (UHD and
GNU Radio). We will examine the hardware and architecture of the
entire USRP family of software-defined radios. We will discuss topics
such as how to get started using a new USRP device, how to install and
configure the open-source software toolchain, programming the USRP
using the UHD API from C++, using GNU Radio with the USRP and creating
and running flowgraphs, using GNU Radio from both GRC and Python, and
various debugging techniques. Several exercises will be performed,
such as implementing an FM transmitter and receiver. Various
demonstrations of wireless systems will be shown. A discussion of the
embedded E310 radio and using embedded SDR will be included. Several
other open-source tools will be discussed, such as GQRX, Fosphor,
Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of
cellular applications, including OpenBTS and LTE stacks, as well as
GPS/GNSS applications will be presented. Several other miscellaneous
topics such as 10 Gigabit Ethernet networking, host system performance
tuning, X300/X310 device recovery, and some best practices will be
discussed. Attendees should come away with a solid foundation and
practical understanding of how to configure, program, and use the USRP
to implement a wide range range of wireless systems.

Prerequisites:
Attendees do not need to bring any USRP radios or laptop computers.
All necessary hardware and software will be provided in the workshop.

Attendees should have some previous experience with Linux and using
the Linux command line, and basic familiarity with a programming
language such as C, C++, or Python, and have basic understanding of
fundamental concepts in DSP and RF. Extensive or deep experience with
these topics is not necessary.

Attendees may bring their own equipment.
Please contact "supp...@ettus.com" for specific setup requirements.


==
   *** RFNoC Workshop ***

 Thursday June 13
  16:00 to 21:00

Run as part of NEWSDR
  http://www.sdr-boston.org/
  http://ecewp.ece.wpi.edu/wordpress/sdr-boston/workshops/newsdr-19/

University of Massachusetts Boston
  100 William T Morrissey Blvd
  Boston, MA 02125

Pizza/Soda and Set-up start at 16:00
  Workshop runs from 17:00 to 21:00

  To register, please register with the NEWSDR event.

Full Title:
FPGA Programming on the USRP with the RFNoC Framework

Abstract:
Ettus Research's RFNoC (RF Network-on-Chip) software framework is
designed to decrease the development time for experienced FPGA
engineers seeking to integrate IP into the USRP FPGA signal
processing chain. RFNoC is the framework for USRP devices that use
Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU).  Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
pres

[Discuss-gnuradio] GNU Radio & RFNoC Workshops in Boston on June 11 & 13

[Neel Pandeya]

==
*** Announcing Workshops in the Boston Area ***

 Ettus Research will be running two free, hands-on, technical
 workshops in the Boston area, and you are welcome to attend!

  GNU Radio Workshop
Tuesday June 11
 Woburn, Massachusetts

RFNoC Workshop
   Thursday June 13
NEWSDR at UMass-Boston
Boston, Massachusetts

==
 *** GNU Radio Workshop ***

   Tuesday June 11
   09:00 to 17:00

National Instruments
  800 Cummings Park Drive
  Woburn, MA 01801
 (I-93, Exit 36, Washington Street)

Breakfast and Set-up start at 08:30
 Workshop runs from 09:00 to 17:00

 To register, please send email to:
   "haydn.nel...@ni.com"

Full Title:
Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain)

Abstract:
This workshop will provide a thorough and practical introduction to
the USRP hardware and the open-source software toolchain (UHD and
GNU Radio). We will examine the hardware and architecture of the
entire USRP family of software-defined radios. We will discuss topics
such as how to get started using a new USRP device, how to install and
configure the open-source software toolchain, programming the USRP
using the UHD API from C++, using GNU Radio with the USRP and creating
and running flowgraphs, using GNU Radio from both GRC and Python, and
various debugging techniques. Several exercises will be performed,
such as implementing an FM transmitter and receiver. Various
demonstrations of wireless systems will be shown. A discussion of the
embedded E310 radio and using embedded SDR will be included. Several
other open-source tools will be discussed, such as GQRX, Fosphor,
Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of
cellular applications, including OpenBTS and LTE stacks, as well as
GPS/GNSS applications will be presented. Several other miscellaneous
topics such as 10 Gigabit Ethernet networking, host system performance
tuning, X300/X310 device recovery, and some best practices will be
discussed. Attendees should come away with a solid foundation and
practical understanding of how to configure, program, and use the USRP
to implement a wide range range of wireless systems.

Prerequisites:
Attendees do not need to bring any USRP radios or laptop computers.
All necessary hardware and software will be provided in the workshop.

Attendees should have some previous experience with Linux and using
the Linux command line, and basic familiarity with a programming
language such as C, C++, or Python, and have basic understanding of
fundamental concepts in DSP and RF. Extensive or deep experience with
these topics is not necessary.

Attendees may bring their own equipment.
Please contact "supp...@ettus.com" for specific setup requirements.


==
   *** RFNoC Workshop ***

 Thursday June 13
  16:00 to 21:00

Run as part of NEWSDR
  http://www.sdr-boston.org/
  http://ecewp.ece.wpi.edu/wordpress/sdr-boston/workshops/newsdr-19/

University of Massachusetts Boston
  100 William T Morrissey Blvd
  Boston, MA 02125

Pizza/Soda and Set-up start at 16:00
  Workshop runs from 17:00 to 21:00

  To register, please register with the NEWSDR event.

Full Title:
FPGA Programming on the USRP with the RFNoC Framework

Abstract:
Ettus Research's RFNoC (RF Network-on-Chip) software framework is
designed to decrease the development time for experienced FPGA
engineers seeking to integrate IP into the USRP FPGA signal
processing chain. RFNoC is the framework for USRP devices that use
Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU).  Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, includin

[Discuss-gnuradio] GNU Radio Con Lodging

[Kyle Flaherty]

Hello Everyone,

I am hoping to attend my first GNU Radio Conference this year. Since I will
be going alone, there is not much use in spending a lot on a single
hotel room. Is there a group of people looking to split an AirBnB or Hotel
Suite?

Thanks,

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

Re: [Discuss-gnuradio] GNU RADIO on Ubuntu Server

[jmfriedt]

> Radio as you need; so, no GRC, no gr-qtgui, hence no GTK, QT, …). I'd
> expect that to easily fit in 4 GB.

we have GNU/Linux + python + GNU Radio in less than 32 MB on the PlutoSDR :)
https://github.com/oscimp/PlutoSDR

JM

-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

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

Re: [Discuss-gnuradio] GNU RADIO on Ubuntu Server

[CEL]

Hi Mehtap,

yeah, Ubuntu is probably as far as it gets from an embedded operating
system ;) Ubuntu Server is only marginally better.

So, the usual way forward here would be to build your own slim Linux
Distro using OpenEmbedded that works on your board (and only on that,
containing only the drivers for hardware you actually have), and
building an eMMC image that contains GNU Radio (and only as much GNU
Radio as you need; so, no GRC, no gr-qtgui, hence no GTK, QT, …). I'd
expect that to easily fit in 4 GB.

Best regards,
Marcus

On Mon, 2019-03-04 at 15:20 +0300, mehtap özkan wrote:
> Dera All,
>  I have an embedded arm board with limited storage (4 GB eMMC). I suspect 
> Ubuntu+ GNU RADIO+Phyton will not fit on it. 
>  Does anybody have used GNU RADIO on Ubuntu Server or alternatively on a 
> small footprint Linux Distor?
>  I have created a .py file from an .grc file and it has no visual output. I 
> want to run the .py file.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU RADIO on Ubuntu Server

[john]

I have run a python based gnuradio application on Odroid C2 and recently 
XU4.  It will come done to what you are trying to do (amount of sample 
rate you require and what kind of processing you are doing).   Also, I 
just recently heard about and used volk_profile.  This helped me with 
performance.



On 3/4/19 6:20 AM, mehtap özkan wrote:

Dera All,
 I have an embedded arm board with limited storage (4 GB eMMC). I 
suspect Ubuntu+ GNU RADIO+Phyton will not fit on it.
 Does anybody have used GNU RADIO on Ubuntu Server or alternatively on 
a small footprint Linux Distor?
 I have created a .py file from an .grc file and it has no visual 
output. I want to run the .py file.


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

[Discuss-gnuradio] GNU RADIO on Ubuntu Server

[mehtap özkan]

Dera All,
 I have an embedded arm board with limited storage (4 GB eMMC). I suspect
Ubuntu+ GNU RADIO+Phyton will not fit on it.
 Does anybody have used GNU RADIO on Ubuntu Server or alternatively on a
small footprint Linux Distor?
 I have created a .py file from an .grc file and it has no visual output. I
want to run the .py file.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Project Call February 2019

[Martin Braun]

Hi all!

In 1hr 46 minutes, at 10 AM Pacific time / 19:00 CET we'll have the next
project call. I'll post the link to the call into IRC/Slack shortly
before it starts.

-- M

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

[Discuss-gnuradio] GNU Radio Companion crashes without any error.

[Sumit Kumar]

Hi,

I am having this issue on a freshly installed Ubuntu 16.04 machine.

I installed GNU Radio using apt-get and then gr-ieee 80211. While running
an example of gr-ieee 80211 (wifi_loopback.grc), it runs for a while and
stops -- no error or any log on the terminal at all.

Here is a video: https://www.youtube.com/watch?v=vmpb0_G6DBc

In an another case, while running ofdm_loopback.grc located in
*/usr/share/gnuradio/examples/digital/ofdm/*

, the ofdm_loopback generates 39 packets correctly, before exiting with the
error "std::bad_alloc" for packet 40 and 41.

It is a formatted new laptop, and everything is clean, no residue of the
previous install, etc. Could anyone please give me a clue to debug it.

Let me know if more information is needed.

Regards

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

[Discuss-gnuradio] GNU Radio Enhancements: Worth a Look!

[Martin Braun]

Hi all,

In case you didn't know: Like many other free software projects, we have a
process for communicating major changes to GNU Radio early, using what we
call GNU Radio Enhancement Proposals (GREPs). We manage GREPs in a git
repository:

https://github.com/gnuradio/greps

The purpose of GREPs is manifold, but the main reasons for having them are:
- They give us the ability to communicate early what we plan to do, so
everyone can be involved soon, and is less surprised by what's coming
- They 3rd-party developers the option to communicate their intent upstream
before submitting the code. Every maintainer dreads the
many-thousands-of-lines pull requests they hadn't heard before.
- They give us a platform to discuss changes with our users before we start
making decisions in private.

For us maintainers, the year 2018 was all about getting 3.8 done, with all
that it entailed: Removing Cheetah to enable Python 3, fighting SWIG to
enable Python 3, replacing Qt4 with Qt5, improving the CI system... lots of
stuff that was frankly a pain the rear and not the most entertaining. Now
while 3.8 is not quite finished (see our other emails on the release
planning), we feel like we're on the home stretch now. Which means, it's
time to think about other changes to modernize GNU Radio and keep it
relevant, modern, and powerful.

In the last 6 months, I've had many conversations with developers within
and around the GNU Radio community, and there's a lot of things that people
want to happen. Heterogeneous computing, better streaming performance, ...
there's so much we could do. To create a solid base for all of this, I've
submitted four GREPs that have fallen out of various conversations. They
are all in "Draft" stage, which means they're totally open for debate. We
could decide to not implement any of those, but then at least we'll have
come to that conclusion in a constructive fashion, and it will be
documented in the GREPs system.

Here they are:
GREP 13: Remove log4cpp
GREP 14: Create blocktool, a header parsing library for GR blocks
GREP 15: Remove SWIG and replace it with ???
GREP 16: Separate the scheduler and the base GNU Radio components into
separate in-tree modules to make the scheduler pluggable

This thread is not a great place to discuss them, I'll start another thread
for each one here.

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

[Discuss-gnuradio] GNU Radio developers & users meetup at 35c3

[Marcus Mueller]

Hello most awesome SDR community to graze upon the endless greens of
band-limited signals,

as I'm at 35c3, and as I'm desperately hoping to get to know exactly what
the current state of affairs in the GNU Radio community is, we'll have a
meetup.

It'll happen on Friday, 2018-12-28, at 16:25 in lecture room 11:

https://events.ccc.de/congress/2018/wiki/index.php?title=Session:GNU_Radio_Users_%26_Devs_Meetup

Last year, we had a nice round of people shortly introducing themselves and
explaining the problems they solve with GNU Radio, and the problems they
face because they did so. That was very interesting, but the format
(standing in a room full of chairs) wasn't quite perfect.

This year, we'll make sure to make things suit the purpose even better:
we'll have half an hour (16:25–16:55) of quick meet'n'greet (so that people
who just quickly want to meet up and see each other can meet, exchange
business cards and/or public keys), before then moving on to a bar, food
strip or assembly (depending on the number and needs of the attendants)
where we can have more one-on-one talking. It's effectively what we've done
last year, but this time, let's call it a plan.

If anyone wants to join, and has a topic to discuss that they think would
be of relevance to an audience that spans different industries and academic
disciplines, be sure to drop me/us a quick hint, for example by replying
here or on twitter :)

Best regards, and hoping to see you soon,
Marcus
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio 3.8 Release: Feature Freeze on 2019-01-10

[Marcus Müller]

Dear GNU Radio community,

---
Tl;dr: Feature freeze coming up, please help categorizing issues and
fixing unit tests using our project boards. General excitement.
---

as we've now closed a lot of the severe issues that GNU Radio had right
after we've tried to bring it to the present (meaning enabling Python
3, porting to Qt5), and adding a lot of cool new features (we're close
to finally merging Håkon's awesome C++ generation code), we're now
working on squashing the remaining bugs and really narrowing all the
things down that need to be done before we release something that
really deserves the Tag 3.8.0.0.

So, in order to do that, I'm defining the feature freeze for 3.8.0.0 to
happen on the tenth of January 2019. That means that all features and
feature requests after that won't be part of that release, but of
course, won't be forgotten; it's just that we'll then have reached a
state where we must avoid scope creep for this specific release.
Nothing says your feature can't be in 3.8.1!
Also, just because a feature is on the list by the 2018-01-10 doesn't
mean it's already implemented. It means we – as a project – commit to
putting it into the release. 

In the meantime we do our best to categorize the many outstanding
issues we have. What we're doing there is pretty classical (implemented
with the tools that Github gives us):

If you go to
https://github.com/gnuradio/gnuradio/projects/1
you'll find four categories, from "To Do" over "In Progress" to "Done".
"Contested" is for issues that we initially added to the "must haves"
for 3.8, but warrant that we reconsider whether actually necessary for
3.8.0.0 (or just additional complication). 
All the things in "To Do" deserve attention; if you happen to have
spare time, don't hesitate to pick any one of these. These are
definitely up for grabs!

So, if you feel like you can contribute anything, especially commentary
on demand and use cases, and of course we'd love code, for any of the
feature-issues, go ahead! If you don't have the permissions to move the
issue from the "To Do" to the "In Progress" category, give us (me) a
nudge. We'll get this thing rolling!


Another thing I want to draw attention to in this context: There's a
special, analogously operating board, "Meaningful QA", on
https://github.com/gnuradio/gnuradio/projects/3
There's a serious problem: whilst we've become a lot better than we
used to be at covering more and more of our code with test cases,
there's still quite a few tests that simply fail, for no reason that we
could easily see.
These partially touch on very specific topics, but partially really
frighten me. So, if you have spare cycles, run one or two of these test
cases a couple of times (many include infos on how to trigger), and
report success or failure together with your architecture.

So, as you can see, we're getting excitingly close to actually putting
out a cool new version of GNU Radio!

Best regards, 
Marcus


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

[Discuss-gnuradio] GNU Radio Conference 2019 // Save the Date // Volunteers Needed

[Neel Pandeya]

**
  * Save The Date *

   * Call for Volunteers *

**
  GNU Radio Conference 2019

   Huntsville, Alabama, USA

 16-20 September 2019

 Ninth Annual

 https://www.gnuradio.org/grcon-2019/

Registration and Submissions Open in Early 2019

**
The organizing committee for the 2019 GNU Radio Conference (GRCon) has
started planning for the event, and is looking for volunteers to join
the organizing committee. You do not have to be an expert on using
GNU Radio, although some previous experience with Software-Defined
Radio (SDR) and GNU Radio would be necessary. In addition, some
previous experience in planning large-scale events would be needed.
Committee members are expected to attend weekly conference calls and
to allocate approximately between two to five hours per week on
committee and conference activities. As the date of the event gets
closer, the time commitment and activity level may be higher. If you
are interested, please send an email to "gr...@gnuradio.org".

Thank you, and hope to see you all in Huntsville next year!

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

[Discuss-gnuradio] GNU Radio Project Call August: Postponed to next week

[Martin Braun]

Hi all,

we usually do the project call on the 3rd Thursday of the month, but
we'll be doing the August call next week. Many apologies for the very
late announcement.

Cheers,
Martin

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

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[CEL]

will define
> the minimum version of most dependencies. We don't yet have a CentOS
> 7 regression test VM, but it is something to consider. We will be
> enforcing the C++11 requirement in CMake which I believe is
> sufficient to make all this work on Centos, but it would be great to
> get your eyes on it once we've made that change to ensure that it
> does work properly for you. I believe the hope is to make that change
> in the next month.
> 
> Ubuntu 14.04 is the other older OS which pushes the minimum versions
> of dependencies, it remains supported (by Canonical) till the middle
> of next year. My *entirely personal* guess is that CentOS 7(.0?)
> official support on master will be dropped around the same time, but
> of course no one has any interest in making an arbitrary break in
> compatibility. The maint-X.X branches should help reduce the impact
> and increase the longevity of GNU Radio on these very long term
> support OSs.
> 
> Cheers,
> Derek
> 
> 
> On Fri, Jun 8, 2018 at 4:01 PM, Jason Matusiak  ring.com> wrote:
> > Derek, this was much appreciated and seems to have fixed my
> > problems on Centos 7.
> >  
> > A note about the C++11 mandatory changes that would help me (and
> > probably others).  There are a lot of us who have been forced into
> > using Centos 7 and their so very antiquated tools.  Ubuntu's newer
> > tools (probably cmake) are smart enough to know to switch to c++11
> > because of the need in the source code.  Centos doesn't appear to
> > be smart enough to do that, and so even though we can build the
> > c++11 code if the tools that are installed if we hand-touched the
> > source with some mods, the system wasn't smart enough to do it on
> > its own.
> >  
> > So my hope is that there might be something you can do in the
> > recipes or gnuradio itself that would force the Centos tools to use
> > c++11 (it appears that some mods to the CMakeLists.txt file like I
> > mentioned in my other thread might be enough (and it shouldn't
> > heart the Ubuntu users any).
> >  
> > Anyway, thanks for the temporary rollback!
> >  
> > > - Original Message -
> > > 
> > > 
> > > Hello Curt,
> > >  
> > > The fix for this issue was merged into the GNU Radio master
> > > branch last night. Thank you for posting the PR and describing
> > > your solution here. The 3.8 release is going to raise the minimum
> > > version requirements of an appreciable number of dependencies in
> > > order to make sure that GNU Radio development can keep moving
> > > forward smoothly. C++11 will be mandatory on master at some time
> > > before that release occurs, but today isn't here quite yet.
> > >  
> > > Thanks,
> > > Derek
> > > 
> > > On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum 
> > > wrote:
> > > > Mir and Jason,
> > > > I've been working through something similar and have found a
> > > > solution.
> > > > Please see the github issue: https://github.com/gnuradio/pybomb
> > > > s/issues/502 and below.
> > > > -Curt
> > > >  
> > > > Dear pybombs team and community,
> > > > Had issues with building gnuradio-default on relatively clean
> > > > but up to date Ubuntu 16.04 LTS. Seems related to https://www.m
> > > > ail-archive.com/discuss-gnuradio@gnu.org/msg66739.html https://
> > > > www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html
> > > > #424 #448
> > > > $ pybombs --version
> > > > 2.3.2
> > > > $ gcc --version
> > > > gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
> > > > It was necessary to do the following to get the gnuradio-
> > > > default recipe to build thrift, boost, uhd and gnuradio without
> > > > errors:
> > > > >sudo apt-get install g++-6
> > > > >sudo update-alternatives --install /usr/bin/gcc gcc
> > > > /usr/bin/gcc-6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-6
> > > > >sudo update-alternatives --config gcc
> > > > and setting gcc-6 to default
> > > > uninstall most of boost 1.58 binary packages (all but non -dev
> > > > distribution packages)
> > > > adding the following to gnuradio-default.lwr
> > > > # gnuradio-default.lwr
> > > > #binary boost linking fails *** CAC
> > > > boost:
> > > >   forcebuild: True
> > > > and modifying config.yml (directly as could not fig

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Curt Corum]

Derek,

Great!

It was also necessary to have


|-fext-numeric-literals |

in the mix as well for uhd and gnuradio to both build. Not sure if that
is covered implicitly?

Curt


On 06/08/2018 01:52 AM, Derek Kozel wrote:
> Hello Curt,
>
> The fix for this issue was merged into the GNU Radio master branch
> last night. Thank you for posting the PR and describing your solution
> here. The 3.8 release is going to raise the minimum version
> requirements of an appreciable number of dependencies in order to make
> sure that GNU Radio development can keep moving forward smoothly.
> C++11 will be mandatory on master at some time before that release
> occurs, but today isn't here quite yet.
>
> Thanks,
> Derek
>
> On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  > wrote:
>
> Mir and Jason,
>
> I've been working through something similar and have found a solution.
>
> Please see the github issue:
> https://github.com/gnuradio/pybombs/issues/502
>  and below.
>
> -Curt
>
>
> Dear pybombs team and community,
>
> Had issues with building gnuradio-default on relatively clean but
> up to date Ubuntu 16.04 LTS. Seems related to
> https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html
> 
> https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html
> 
> #424  #448
> 
>
> SNIP
>

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

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Derek Kozel]

Hi Jason,

Centos 7 is being specifically looked at for 3.8 as it will define the
minimum version of most dependencies. We don't yet have a CentOS 7
regression test VM, but it is something to consider. We will be enforcing
the C++11 requirement in CMake which I believe is sufficient to make all
this work on Centos, but it would be great to get your eyes on it once
we've made that change to ensure that it does work properly for you. I
believe the hope is to make that change in the next month.

Ubuntu 14.04 is the other older OS which pushes the minimum versions of
dependencies, it remains supported (by Canonical) till the middle of next
year. My *entirely personal* guess is that CentOS 7(.0?) official support
on master will be dropped around the same time, but of course no one has
any interest in making an arbitrary break in compatibility. The maint-X.X
branches should help reduce the impact and increase the longevity of GNU
Radio on these very long term support OSs.

Cheers,
Derek


On Fri, Jun 8, 2018 at 4:01 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Derek, this was much appreciated and seems to have fixed my problems on
> Centos 7.
>
> A note about the C++11 mandatory changes that would help me (and probably
> others).  There are a lot of us who have been forced into using Centos 7
> and their so very antiquated tools.  Ubuntu's newer tools (probably cmake)
> are smart enough to know to switch to c++11 because of the need in the
> source code.  Centos doesn't appear to be smart enough to do that, and so
> even though we can build the c++11 code if the tools that are installed if
> we hand-touched the source with some mods, the system wasn't smart enough
> to do it on its own.
>
> So my hope is that there might be something you can do in the recipes or
> gnuradio itself that would force the Centos tools to use c++11 (it appears
> that some mods to the CMakeLists.txt file like I mentioned in my other
> thread might be enough (and it shouldn't heart the Ubuntu users any).
>
> Anyway, thanks for the temporary rollback!
>
>
> - Original Message -
>
>
> Hello Curt,
>
> The fix for this issue was merged into the GNU Radio master branch last
> night. Thank you for posting the PR and describing your solution here. The
> 3.8 release is going to raise the minimum version requirements of an
> appreciable number of dependencies in order to make sure that GNU Radio
> development can keep moving forward smoothly. C++11 will be mandatory on
> master at some time before that release occurs, but today isn't here quite
> yet.
>
> Thanks,
> Derek
>
> On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  wrote:
>
>> Mir and Jason,
>>
>> I've been working through something similar and have found a solution.
>>
>> Please see the github issue: https://github.com/gnuradio/
>> pybombs/issues/502 and below.
>>
>> -Curt
>>
>>
>>
>> Dear pybombs team and community,
>>
>> Had issues with building gnuradio-default on relatively clean but up to
>> date Ubuntu 16.04 LTS. Seems related to https://www.mail-archive.com/
>> discuss-gnuradio@gnu.org/msg66739.html https://www.mail-archive.com/
>> discuss-gnuradio@gnu.org/msg66739.html #424
>> <https://github.com/gnuradio/pybombs/issues/424> #448
>> <https://github.com/gnuradio/pybombs/issues/448>
>>
>> $ pybombs --version
>> 2.3.2
>>
>> $ gcc --version
>> gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
>>
>> It was necessary to do the following to get the gnuradio-default recipe
>> to build thrift, boost, uhd and gnuradio without errors:
>>
>> >sudo apt-get install g++-6
>> >sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 60 
>> >--slave /usr/bin/g++ g++ /usr/bin/g++-6
>> >sudo update-alternatives --config gcc
>>
>> and setting gcc-6 to default
>>
>> uninstall most of boost 1.58 binary packages (all but non -dev
>> distribution packages)
>> adding the following to gnuradio-default.lwr
>>
>> # gnuradio-default.lwr
>> #binary boost linking fails *** CAC
>> boost:
>>   forcebuild: True
>>
>> and modifying config.yml (directly as could not figure out how to escape
>> -std=c++-11 for pybombs config --env)
>>
>> # config.yml
>> env:
>>   CXXFLAGS: -std=c++11 -fext-numeric-literals
>>
>> and modifying boost.lwr
>>
>>  # boost.lwr
>>   satisfy:
>>   deb: libboost-all-dev >= 1.6 || libboost-dev >= 1.6
>>   rpm: (boost-devel >= 1.6) || (boost_1_61-devel >= 1.6) || 
>> (boost_1_64-devel >= 1.6) || (boost_1_65-de

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Jason Matusiak]

Derek, this was much appreciated and seems to have fixed my problems on Centos 
7.
 
A note about the C++11 mandatory changes that would help me (and probably 
others).  There are a lot of us who have been forced into using Centos 7 and 
their so very antiquated tools.  Ubuntu's newer tools (probably cmake) are 
smart enough to know to switch to c++11 because of the need in the source code. 
 Centos doesn't appear to be smart enough to do that, and so even though we can 
build the c++11 code if the tools that are installed if we hand-touched the 
source with some mods, the system wasn't smart enough to do it on its own.
 
So my hope is that there might be something you can do in the recipes or 
gnuradio itself that would force the Centos tools to use c++11 (it appears that 
some mods to the CMakeLists.txt file like I mentioned in my other thread might 
be enough (and it shouldn't heart the Ubuntu users any).
 
Anyway, thanks for the temporary rollback!
 
- Original Message - 

  Hello Curt,
 
The fix for this issue was merged into the GNU Radio master branch last night. 
Thank you for posting the PR and describing your solution here. The 3.8 release 
is going to raise the minimum version requirements of an appreciable number of 
dependencies in order to make sure that GNU Radio development can keep moving 
forward smoothly. C++11 will be mandatory on master at some time before that 
release occurs, but today isn't here quite yet.
 
Thanks,
Derek


 On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  wrote:
   Mir and Jason,
 I've been working through something similar and have found a solution.
 Please see the github issue: https://github.com/gnuradio/pybombs/issues/502 
and below.
 -Curt
  
 Dear pybombs team and community,
 Had issues with building gnuradio-default on relatively clean but up to date 
Ubuntu 16.04 LTS. Seems related to 
https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html 
https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html #424 #448
 $ pybombs --version
 2.3.2
 $ gcc --version
 gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
 It was necessary to do the following to get the gnuradio-default recipe to 
build thrift, boost, uhd and gnuradio without errors:
 >sudo apt-get install g++-6
 >sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 60 --slave 
 >/usr/bin/g++ g++ /usr/bin/g++-6
 >sudo update-alternatives --config gcc
  and setting gcc-6 to default
 uninstall most of boost 1.58 binary packages (all but non -dev distribution 
packages)
 adding the following to gnuradio-default.lwr
 # gnuradio-default.lwr
 #binary boost linking fails *** CAC
 boost:
 forcebuild: True
  and modifying config.yml (directly as could not figure out how to escape 
-std=c++-11 for pybombs config --env)
 # config.yml
 env:
 CXXFLAGS: -std=c++11 -fext-numeric-literals
  and modifying boost.lwr
  # boost.lwr
 satisfy:
 deb: libboost-all-dev >= 1.6 || libboost-dev >= 1.6
 rpm: (boost-devel >= 1.6) || (boost_1_61-devel >= 1.6) || (boost_1_64-devel >= 
1.6) || (boost_1_65-devel >= 1.6)
 pacman: boost >= 1.6
 port: boost >= 1.6
 portage: dev-libs/boost >= 1.6
  Wanted to make sure this got captured as it took several days to resolve and 
seems to be an ongoing issue.
 -Curt
  
  
 
 On 06/07/2018 11:00 AM, discuss-gnuradio-requ...@gnu.org wrote:
 Message: 5
 Date: Thu, 7 Jun 2018 15:13:38 +0100
 From: Mir Muhammad Lodro 
 To: discuss-gnuradio@gnu.org
 Subject: [Discuss-gnuradio] GNU Radio not installing: Build Failed
 Message-ID:
 
 Content-Type: text/plain; charset="utf-8"
 
 Hi All
 i am installing GNU Radio on Linux 16.04, but it's not installing by saying
 this file requires compiler and library support for ISO 2011 standard. This
 can be done by issuing -std=c++11 or -std=gnu++11 when one has to run
 single file. But here the build process is automated. I would be grateful
 if you can look into the following prompt response and guide what could be
 the possible solution. I have already installed GNU Radio on different
 machine running 16.04, but I am surprise to see the error when installing
 on another machine and despite repeating the very same steps.
 
 The as it as prompt response is:
 
 root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
 prefix/default/ -R gnuradio-default
 PyBOMBS - INFO - PyBOMBS Version 2.3.2
 PyBOMBS.prefix - WARNING - There already is a prefix in
 `/home/eexmmlo/prefix/default'.
 Continue using this path Y/[N]? y
 Alias `default' already exists, overwrite Y/[N]? y
 PyBOMBS.prefix - INFO - Installing default packages for prefix...
 PyBOMBS.prefix - INFO -
 - gnuradio
 PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
 installing binary packages:
 Install tree:
 |
 \- gnuradio
 PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
 packages to prefix:
 PyBOMBS.install_manager - INFO - Inst

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Derek Kozel]

Hello Curt,

The fix for this issue was merged into the GNU Radio master branch last
night. Thank you for posting the PR and describing your solution here. The
3.8 release is going to raise the minimum version requirements of an
appreciable number of dependencies in order to make sure that GNU Radio
development can keep moving forward smoothly. C++11 will be mandatory on
master at some time before that release occurs, but today isn't here quite
yet.

Thanks,
Derek

On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  wrote:

> Mir and Jason,
>
> I've been working through something similar and have found a solution.
>
> Please see the github issue: https://github.com/gnuradio/
> pybombs/issues/502 and below.
>
> -Curt
>
>
> Dear pybombs team and community,
>
> Had issues with building gnuradio-default on relatively clean but up to
> date Ubuntu 16.04 LTS. Seems related to https://www.mail-archive.com/
> discuss-gnuradio@gnu.org/msg66739.html https://www.mail-archive.com/
> discuss-gnuradio@gnu.org/msg66739.html #424
> <https://github.com/gnuradio/pybombs/issues/424> #448
> <https://github.com/gnuradio/pybombs/issues/448>
>
> $ pybombs --version
> 2.3.2
>
> $ gcc --version
> gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
>
> It was necessary to do the following to get the gnuradio-default recipe to
> build thrift, boost, uhd and gnuradio without errors:
>
> >sudo apt-get install g++-6
> >sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 60 
> >--slave /usr/bin/g++ g++ /usr/bin/g++-6
> >sudo update-alternatives --config gcc
>
> and setting gcc-6 to default
>
> uninstall most of boost 1.58 binary packages (all but non -dev
> distribution packages)
> adding the following to gnuradio-default.lwr
>
> # gnuradio-default.lwr
> #binary boost linking fails *** CAC
> boost:
>   forcebuild: True
>
> and modifying config.yml (directly as could not figure out how to escape
> -std=c++-11 for pybombs config --env)
>
> # config.yml
> env:
>   CXXFLAGS: -std=c++11 -fext-numeric-literals
>
> and modifying boost.lwr
>
>  # boost.lwr
>   satisfy:
>   deb: libboost-all-dev >= 1.6 || libboost-dev >= 1.6
>   rpm: (boost-devel >= 1.6) || (boost_1_61-devel >= 1.6) || (boost_1_64-devel 
> >= 1.6) || (boost_1_65-devel >= 1.6)
>   pacman: boost >= 1.6
>   port: boost >= 1.6
>   portage: dev-libs/boost >= 1.6
>
> Wanted to make sure this got captured as it took several days to resolve
> and seems to be an ongoing issue.
>
> -Curt
>
>
>
>
> On 06/07/2018 11:00 AM, discuss-gnuradio-requ...@gnu.org wrote:
>
> Message: 5
> Date: Thu, 7 Jun 2018 15:13:38 +0100
> From: Mir Muhammad Lodro  
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] GNU Radio not installing: Build Failed
> Message-ID:
>
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hi All
> i am installing GNU Radio on Linux 16.04, but it's not installing by saying
> this file requires compiler and library support for ISO 2011 standard. This
> can be done by issuing -std=c++11 or -std=gnu++11  when one has to run
> single file. But here the build process is automated. I would be grateful
> if you can look into the following prompt response and guide what could be
> the possible solution. I have already installed GNU Radio on different
> machine running 16.04, but I am surprise to see the error when installing
> on another machine  and despite repeating the very same steps.
>
> The as it as prompt response is:
>
> root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
> prefix/default/ -R gnuradio-default
> PyBOMBS - INFO - PyBOMBS Version 2.3.2
> PyBOMBS.prefix - WARNING - There already is a prefix in
> `/home/eexmmlo/prefix/default'.
> Continue using this path Y/[N]? y
> Alias `default' already exists, overwrite Y/[N]? y
> PyBOMBS.prefix - INFO - Installing default packages for prefix...
> PyBOMBS.prefix - INFO -
>   - gnuradio
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
> installing binary packages:
> Install tree:
> |
> \- gnuradio
> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
> packages to prefix:
> PyBOMBS.install_manager - INFO - Installing package: gnuradio
> PyBOMBS.Packager.source - WARNING - Build dir already exists:
> /home/eexmmlo/prefix/default/src/gnuradio/build
> Building:(100%) [=
> 
> ]
> [  4%] Built target volk_obj
> [  4%] Built target volk
> [  4%] Built target volk_test_all
> [  4%] Built target volk_profile
>

[Discuss-gnuradio] GNU Radio not installing: Build Failed

[Curt Corum]

Mir and Jason,

I've been working through something similar and have found a solution.

Please see the github issue:
https://github.com/gnuradio/pybombs/issues/502 and below.

-Curt


Dear pybombs team and community,

Had issues with building gnuradio-default on relatively clean but up to
date Ubuntu 16.04 LTS. Seems related to
https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html
https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html #424
<https://github.com/gnuradio/pybombs/issues/424> #448
<https://github.com/gnuradio/pybombs/issues/448>

$ pybombs --version
2.3.2

$ gcc --version
gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424

It was necessary to do the following to get the gnuradio-default recipe
to build thrift, boost, uhd and gnuradio without errors:

|>sudo apt-get install g++-6 >sudo update-alternatives --install
/usr/bin/gcc gcc /usr/bin/gcc-6 60 --slave /usr/bin/g++ g++
/usr/bin/g++-6 >sudo update-alternatives --config gcc |

and setting gcc-6 to default

uninstall most of boost 1.58 binary packages (all but non -dev
distribution packages)
adding the following to gnuradio-default.lwr

|# gnuradio-default.lwr #binary boost linking fails *** CAC boost:
forcebuild: True |

and modifying config.yml (directly as could not figure out how to escape
-std=c++-11 for pybombs config --env)

|# config.yml env: CXXFLAGS: -std=c++11 -fext-numeric-literals |

and modifying boost.lwr

|# boost.lwr satisfy: deb: libboost-all-dev >= 1.6 || libboost-dev >= 1.6
rpm: (boost-devel >= 1.6) || (boost_1_61-devel >= 1.6) ||
(boost_1_64-devel >= 1.6) || (boost_1_65-devel >= 1.6) pacman: boost >=
1.6 port: boost >= 1.6 portage: dev-libs/boost >= 1.6 |

Wanted to make sure this got captured as it took several days to resolve
and seems to be an ongoing issue.

-Curt




On 06/07/2018 11:00 AM, discuss-gnuradio-requ...@gnu.org wrote:
> Message: 5
> Date: Thu, 7 Jun 2018 15:13:38 +0100
> From: Mir Muhammad Lodro 
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] GNU Radio not installing: Build Failed
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
>
> Hi All
> i am installing GNU Radio on Linux 16.04, but it's not installing by saying
> this file requires compiler and library support for ISO 2011 standard. This
> can be done by issuing -std=c++11 or -std=gnu++11  when one has to run
> single file. But here the build process is automated. I would be grateful
> if you can look into the following prompt response and guide what could be
> the possible solution. I have already installed GNU Radio on different
> machine running 16.04, but I am surprise to see the error when installing
> on another machine  and despite repeating the very same steps.
>
> The as it as prompt response is:
>
> root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
> prefix/default/ -R gnuradio-default
> PyBOMBS - INFO - PyBOMBS Version 2.3.2
> PyBOMBS.prefix - WARNING - There already is a prefix in
> `/home/eexmmlo/prefix/default'.
> Continue using this path Y/[N]? y
> Alias `default' already exists, overwrite Y/[N]? y
> PyBOMBS.prefix - INFO - Installing default packages for prefix...
> PyBOMBS.prefix - INFO -
>   - gnuradio
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
> installing binary packages:
> Install tree:
> |
> \- gnuradio
> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
> packages to prefix:
> PyBOMBS.install_manager - INFO - Installing package: gnuradio
> PyBOMBS.Packager.source - WARNING - Build dir already exists:
> /home/eexmmlo/prefix/default/src/gnuradio/build
> Building:(100%) [=
> 
> ]
> [  4%] Built target volk_obj
> [  4%] Built target volk
> [  4%] Built target volk_test_all
> [  4%] Built target volk_profile
> [  5%] Built target volk-config-info
> [  6%] Built target pygen_volk_python_volk_modtool_34493
> [  6%] Built target pygen_volk_python_volk_modtool_04eb6
> [  7%] Built target pmt_generated
> [  7%] Built target gnuradio-pmt
> [ 10%] Built target gnuradio-runtime
> [ 11%] Built target test-gnuradio-runtime
> [ 11%] Built target gr_runtime_test
> [ 11%] Built target test-gnuradio-pmt
> [ 11%] Built target gr_pmt_test
> [ 11%] Built target gnuradio-config-info
> [ 11%] Built target pmt_swig_swig_doc
> [ 11%] Built target _pmt_swig_swig_tag
> [ 11%] Built target pmt_swig_gnuradio_runtime_swig_7dd5e
> [ 11%] Built target _pmt_swig
> [ 11%] Built target runtime_swig_swig_doc
> [ 11%] Built target pmt_swig
> [ 11%] Built target _runtime_swig_swig_tag
> [ 11%] Built target runtime_swig_gnuradio_runtime_swig_7dd5e
> [ 11%] 

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Dave NotTelling]

Check out the thread titled: install issues with c++11.  I think you two
are having the same issue with PyBombs and C++11

On Thu, Jun 7, 2018 at 10:16 AM Mir Muhammad Lodro 
wrote:

> Hi All
> i am installing GNU Radio on Linux 16.04, but it's not installing by
> saying this file requires compiler and library support for ISO 2011
> standard. This can be done by issuing -std=c++11 or -std=gnu++11  when one
> has to run single file. But here the build process is automated. I would be
> grateful if you can look into the following prompt response and guide what
> could be the possible solution. I have already installed GNU Radio on
> different machine running 16.04, but I am surprise to see the error when
> installing on another machine  and despite repeating the very same steps.
>
> The as it as prompt response is:
>
> root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
> prefix/default/ -R gnuradio-default
> PyBOMBS - INFO - PyBOMBS Version 2.3.2
> PyBOMBS.prefix - WARNING - There already is a prefix in
> `/home/eexmmlo/prefix/default'.
> Continue using this path Y/[N]? y
> Alias `default' already exists, overwrite Y/[N]? y
> PyBOMBS.prefix - INFO - Installing default packages for prefix...
> PyBOMBS.prefix - INFO -
>   - gnuradio
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
> installing binary packages:
> Install tree:
> |
> \- gnuradio
> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
> packages to prefix:
> PyBOMBS.install_manager - INFO - Installing package: gnuradio
> PyBOMBS.Packager.source - WARNING - Build dir already exists:
> /home/eexmmlo/prefix/default/src/gnuradio/build
> Building:(100%)
> [=]
> [  4%] Built target volk_obj
> [  4%] Built target volk
> [  4%] Built target volk_test_all
> [  4%] Built target volk_profile
> [  5%] Built target volk-config-info
> [  6%] Built target pygen_volk_python_volk_modtool_34493
> [  6%] Built target pygen_volk_python_volk_modtool_04eb6
> [  7%] Built target pmt_generated
> [  7%] Built target gnuradio-pmt
> [ 10%] Built target gnuradio-runtime
> [ 11%] Built target test-gnuradio-runtime
> [ 11%] Built target gr_runtime_test
> [ 11%] Built target test-gnuradio-pmt
> [ 11%] Built target gr_pmt_test
> [ 11%] Built target gnuradio-config-info
> [ 11%] Built target pmt_swig_swig_doc
> [ 11%] Built target _pmt_swig_swig_tag
> [ 11%] Built target pmt_swig_gnuradio_runtime_swig_7dd5e
> [ 11%] Built target _pmt_swig
> [ 11%] Built target runtime_swig_swig_doc
> [ 11%] Built target pmt_swig
> [ 11%] Built target _runtime_swig_swig_tag
> [ 11%] Built target runtime_swig_gnuradio_runtime_swig_7dd5e
> [ 11%] Built target _runtime_swig
> [ 11%] Built target pygen_gnuradio_runtime_swig_bc893
> [ 12%] Built target pygen_gnuradio_runtime_swig_c7096
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_0cff0
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gr_c39fa
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gru_e77e9
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_20832
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_c0e39
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_2dcdd
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_a87ad
> [ 13%] Built target pygen_gnuradio_runtime_python_pmt_5fb7b
> [ 13%] Built target pygen_gnuradio_runtime_examples_mp_sched_be1cd
> [ 13%] Built target pygen_gnuradio_runtime_examples_network_14cb6
> [ 13%] Built target pygen_gnuradio_runtime_examples_volk_benchmark_0f7b0
> [ 14%] Built target blocks_generated_includes
> [ 14%] Building CXX object
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o
> In file included from /usr/include/c++/5/cstdint:35:0,
>  from
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:30:
> /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file
> requires compiler and library support for the ISO C++ 2011 standard. This
> support must be enabled with the -std=c++11 or -std=gnu++11 compiler
> options.
>  #error This file requires compiler and library support \
>   ^
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:32:14:
> error: ‘int64_t’ does not name a type
>  static const int64_t MAX_INT =  INT32_MAX;
>   ^
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:33:14:
> error: ‘int64_t’ does not name a type
>  static const int64_t MIN_INT =  INT32_MIN;
>   ^
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:
> In function ‘void float_array_to_int(const float*, int*, float, int)’:
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:39:5:
> error: ‘int64_t’ was not declared in this scope
>  int64_t r = llrintf(

[Discuss-gnuradio] GNU Radio not installing: Build Failed

[Mir Muhammad Lodro]

Hi All
i am installing GNU Radio on Linux 16.04, but it's not installing by saying
this file requires compiler and library support for ISO 2011 standard. This
can be done by issuing -std=c++11 or -std=gnu++11  when one has to run
single file. But here the build process is automated. I would be grateful
if you can look into the following prompt response and guide what could be
the possible solution. I have already installed GNU Radio on different
machine running 16.04, but I am surprise to see the error when installing
on another machine  and despite repeating the very same steps.

The as it as prompt response is:

root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
prefix/default/ -R gnuradio-default
PyBOMBS - INFO - PyBOMBS Version 2.3.2
PyBOMBS.prefix - WARNING - There already is a prefix in
`/home/eexmmlo/prefix/default'.
Continue using this path Y/[N]? y
Alias `default' already exists, overwrite Y/[N]? y
PyBOMBS.prefix - INFO - Installing default packages for prefix...
PyBOMBS.prefix - INFO -
  - gnuradio
PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
installing binary packages:
Install tree:
|
\- gnuradio
PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
packages to prefix:
PyBOMBS.install_manager - INFO - Installing package: gnuradio
PyBOMBS.Packager.source - WARNING - Build dir already exists:
/home/eexmmlo/prefix/default/src/gnuradio/build
Building:(100%) [=

]
[  4%] Built target volk_obj
[  4%] Built target volk
[  4%] Built target volk_test_all
[  4%] Built target volk_profile
[  5%] Built target volk-config-info
[  6%] Built target pygen_volk_python_volk_modtool_34493
[  6%] Built target pygen_volk_python_volk_modtool_04eb6
[  7%] Built target pmt_generated
[  7%] Built target gnuradio-pmt
[ 10%] Built target gnuradio-runtime
[ 11%] Built target test-gnuradio-runtime
[ 11%] Built target gr_runtime_test
[ 11%] Built target test-gnuradio-pmt
[ 11%] Built target gr_pmt_test
[ 11%] Built target gnuradio-config-info
[ 11%] Built target pmt_swig_swig_doc
[ 11%] Built target _pmt_swig_swig_tag
[ 11%] Built target pmt_swig_gnuradio_runtime_swig_7dd5e
[ 11%] Built target _pmt_swig
[ 11%] Built target runtime_swig_swig_doc
[ 11%] Built target pmt_swig
[ 11%] Built target _runtime_swig_swig_tag
[ 11%] Built target runtime_swig_gnuradio_runtime_swig_7dd5e
[ 11%] Built target _runtime_swig
[ 11%] Built target pygen_gnuradio_runtime_swig_bc893
[ 12%] Built target pygen_gnuradio_runtime_swig_c7096
[ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_0cff0
[ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gr_c39fa
[ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gru_e77e9
[ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_20832
[ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_c0e39
[ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_2dcdd
[ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_a87ad
[ 13%] Built target pygen_gnuradio_runtime_python_pmt_5fb7b
[ 13%] Built target pygen_gnuradio_runtime_examples_mp_sched_be1cd
[ 13%] Built target pygen_gnuradio_runtime_examples_network_14cb6
[ 13%] Built target pygen_gnuradio_runtime_examples_volk_benchmark_0f7b0
[ 14%] Built target blocks_generated_includes
[ 14%] Building CXX object gr-blocks/lib/CMakeFiles/
gnuradio-blocks.dir/float_array_to_int.cc.o
In file included from /usr/include/c++/5/cstdint:35:0,
 from /home/eexmmlo/prefix/default/
src/gnuradio/gr-blocks/lib/float_array_to_int.cc:30:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file
requires compiler and library support for the ISO C++ 2011 standard. This
support must be enabled with the -std=c++11 or -std=gnu++11 compiler
options.
 #error This file requires compiler and library support \
  ^
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:32:14:
error: ‘int64_t’ does not name a type
 static const int64_t MAX_INT =  INT32_MAX;
  ^
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:33:14:
error: ‘int64_t’ does not name a type
 static const int64_t MIN_INT =  INT32_MIN;
  ^
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:
In function ‘void float_array_to_int(const float*, int*, float, int)’:
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:39:5:
error: ‘int64_t’ was not declared in this scope
 int64_t r = llrintf(scale * in[i]);
 ^
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:9:
error: ‘r’ was not declared in this scope
 if (r < MIN_INT)
 ^
/home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:13:
error: ‘MIN_INT’ was not declared in this scope
 if (r < MIN_INT)
 ^
/home/eexmmlo/pre

[Discuss-gnuradio] GNU Radio Conference: Paper and Talk Submissions open

[Derek Kozel]

Greetings GNU Radio Community,

GNU Radio Conference 2018 is rapidly approaching us from Henderson, NV
from 17-21 September this year.
We are now accepting submissions for technical talks AND/OR technical
proceedings papers for this years conference!
Authors/contributors/presenters may elect to submit *(1) a talk
abstract only, (2) a technical paper only, or (3) a technical paper
which will also be presented at the conference*.  While technical
papers through our open access annual proceedings offer a great way to
publish your work, we believe there are also many excellent technical
talks and contributions which may prefer a presentation only format and
vice versa.
Information on paper formatting, templates, distribution rights, and
guidelines may be found here:https://www.gnuradio.org/grcon-2018/submit/

While submissions may be made through the double-blind review
system here:https://openconf.org/GRCon2018/openconf.php

As a brief reminder, our schedule for this years submissions is included
below, and our submission deadline is rapidly approaching.
* June 3: Deadline for Talk, Tutorial, and Poster Submissions
* June 17: Acceptance Notification
   Notification of decisions on talk abstracts are provided to authors.
* Sep 4: Camera Ready Paper Due
   Provide your final polished paper version for inclusion in the
   technical proceedings!
* Sep 17: Proceedings Publication
   Proceedings will be published electronically near the beginning of
   the GNU Radio Conference!
We look forward to seeing all of the excellent contributions from those
working in the GNU Radio and software radio world and meeting you all in
Henderson soon!
Best Regards,
GRCon2018 Organizers



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

Re: [Discuss-gnuradio] GNU Radio, peak values, export into a file

[PRIYANKA PRIYADARSHINI]

You can use file sink to store your peak value. It will continuously store the 
values until you close your program.

Alternatively you can use head before file sink to limit your to program to 
specific time.

Hope this helps!

Priyanka



> On 26. Apr 2018, at 01:42, ALEJANDRO RAMIRO MUNOZ <100314...@alumnos.uc3m.es> 
> wrote:
> 
> Hey all!
> 
> I started working with GNU Radio and HackRF One SDR for an university project 
> but I'm completely complete new and I'm still a little bit lost. 
> 
> I'm using the HackRF One as a spectrum analyzer, specifically at 120.457 KHz. 
> That signal source comes from an Avalanche Transceiver upconverted into HF 
> and it's a powerful periodic signal peak at this frequency.
> 
> With GNU Radio I'm just trying to capture and later export into a file the 
> peak power values of this signal. So I want to set a threshold, capture the 
> peak values of this signal continuously until I stop the programme and store 
> them in a file.
> 
> I've tried to follow some similar tutorials but I'm not able to get a proper 
> solution.
> 
> If someone could help me, I'll be so grateful! Thank you in advance!
> 
> 
> 
> 
> -- 
> Alejandro Ramiro Muñoz
> NIA: 100314975
> 
> Grado en Ingeniería de Sistemas de Comunicaciones
> (Bachelor's Degree in Communication System Engineering)
> 
> Universidad Carlos III de Madrid
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio, peak values, export into a file

[ALEJANDRO RAMIRO MUNOZ]

Hey all!

I started working with GNU Radio and HackRF One SDR for an university
project but I'm completely complete new and I'm still a little bit lost.

I'm using the HackRF One as a spectrum analyzer, specifically at 120.457
KHz. That signal source comes from an Avalanche Transceiver upconverted
into HF and it's a powerful periodic signal peak at this frequency.

With GNU Radio I'm just trying to capture and later export into a file the
peak power values of this signal. So I want to set a threshold, capture the
peak values of this signal continuously until I stop the programme and
store them in a file.

I've tried to follow some similar tutorials but I'm not able to get a
proper solution.

If someone could help me, I'll be so grateful! Thank you in advance!



-- 
Alejandro Ramiro Muñoz
NIA: 100314975

Grado en Ingeniería de Sistemas de Comunicaciones
*(Bachelor's Degree in Communication System Engineering)*

*Universidad Carlos III de Madrid*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Project Call April

[Martin Braun]

Hi all,

the project call for April will start in 8 minutes (it'll be at 10 AM
Pacific time).

To follow the live event:
http://youtu.be/MlyVOs8fkH4

To join the call and participate:
https://hangouts.google.com/hangouts/_/pb5arg52c5bqbh6pdt5gb5xoo4e

Cheers,
Martin

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

[Discuss-gnuradio] GNU Radio Project Call Tomorrow!

[Martin Braun]

This is a reminder that tomorrow is our monthly project call. As always, we
meet on Google Hangouts at 10 am Pacific time, 1pm Eastern, 19:00 Central
European. Check irc or slack for the link announcement.

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

Re: [Discuss-gnuradio] GNU Radio Frequency Divider

[CEL]

Hi Paul!

Just like in the analog world, frequency dividers are harder to
implement, since you can't simply use trigonometric formulas as you can
to double frequencies.

In hardware, you'd, typically, you'd do something like a PLL to
discipline your own oscillator to run at a fraction of the rate that
your input does. You could, hypothetically, do something similar in GNU
Radio. But:

This is digital signal processing. You could just as well
measure/estimate the frequency of your input, and then just run a sine
signal source at half of that rate.

What is the use case you're doing this for? I'd recommend painting "the
bigger picture", because there's a lot of enthusiastic experts on here
that just wait to comment on cool problems :)

Best regards,
Marcus

On Thu, 2018-04-12 at 20:04 -0400, paGNU iea wrote:
>  Hi, my name is paul.
> 
> I have a little issue, I need to do a frequency divider by 2, I did a 
> frequency multiplier by 2 and it is simple, because it is a multiply block 
> that have the same signal source at the inputs, and it produces at the output 
> the frequency adition, but the case of divider is complicated.
> 
> At the first I've tried multiplying by a cosine wave at half the frequency . 
> However there is a problem with the synchronization
> 
> Also I know I can resample up and then treat it as if I'm at the same 
> frequency, however I want to divide the frequency of my signal by 2 and keep 
> the same number of samples.
> 
> Also I was trying to do a python embeded block in GNU Radio, but I found it a 
> little complicated
> How would one implement a frequency divider?
> 
> Thank you all for your time .
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Frequency Divider

[paGNU iea]

 Hi, my name is paul.

I have a little issue, I need to do a frequency divider by 2, I did a
frequency multiplier by 2 and it is simple, because it is a multiply block
that have the same signal source at the inputs, and it produces at the
output the frequency adition, but the case of divider is complicated.

At the first I've tried multiplying by a cosine wave at half the frequency
. However there is a problem with the synchronization

Also I know I can resample up and then treat it as if I'm at the same
frequency, however I want to divide the frequency of my signal by 2 and
keep the same number of samples.

Also I was trying to do a python embeded block in GNU Radio, but I found it
a little complicated
How would one implement a frequency divider?

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

[Discuss-gnuradio] GNU Radio / RFNoC Workshops in Boston

[Neel Pandeya]

==
  ** Announcing GNU Radio and RFNoC Workshops in the Boston Area **
(Reminder)

==
Ettus Research will be running two free, hands-on, technical workshops
in the Boston area, and you are welcome to attend!

==
*GNU Radio Workshop*

   Monday April 30
   09:00 to 17:00

National Instruments
  800 Cummings Park Drive
  Woburn, MA 01801
 (I-93, Exit 36, Washington Street)

Breakfast and Set-up start at 08:30
 Workshop runs from 09:00 to 17:00

Registration Link:
https://docs.google.com/forms/d/e/1FAIpQLSfGz45YGv1kN-LQIZFg9C2bW-7Vt8-81OXKtRQ-NTAM4BwcVg/viewform

Full Title:
Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain)

Abstract:
This workshop will provide a thorough and practical introduction to
the USRP hardware and the open-source software toolchain (UHD and
GNU Radio). We will examine the hardware and architecture of the
entire USRP family of software-defined radios. We will discuss topics
such as how to get started using a new USRP device, how to install and
configure the open-source software toolchain, programming the USRP
using the UHD API from C++, using GNU Radio with the USRP and creating
and running flowgraphs, using GNU Radio from both GRC and Python, and
various debugging techniques. Several exercises will be performed,
such as implementing an FM transmitter and receiver. Various
demonstrations of wireless systems will be shown. A discussion of the
embedded E310 radio and using embedded SDR will be included. Several
other open-source tools will be discussed, such as GQRX, Fosphor,
Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of
cellular applications, including OpenBTS and LTE stacks, as well as
GPS/GNSS applications will be presented. Several other miscellaneous
topics such as 10 Gigabit Ethernet networking, host system performance
tuning, X300/X310 device recovery, and some best practices will be
discussed. Attendees should come away with a solid foundation and
practical understanding of how to configure, program, and use the USRP
to implement a wide range range of wireless systems.

Prerequisites:
Attendees do not need to bring any USRP radios or laptop computers.
All necessary hardware and software will be provided in the workshop.

Attendees should have some previous experience with Linux and using
the Linux command line, and basic familiarity with a programming
language such as C, C++, or Python, and have basic understanding of
fundamental concepts in DSP and RF. Extensive or deep experience with
these topics is not necessary.

Attendees may optionally bring their own laptops for use in the
workshop. The laptop should have a minimum of 4 GB memory, 60 GB
of free disk space, one Ethernet port available, and one USB 3.0
port available, and should be able to have Linux installed onto them.

==
 *RFNoC Workshop*

  Thursday May 3
  16:00 to 21:00

Run as part of NEWSDR
  http://www.sdr-boston.org/
  http://ecewp.ece.wpi.edu/wordpress/sdr-boston/workshops/newsdr-18/

 Worcester Polytechnic Institute (WPI)
  Atwater Kent Laboratories Building
   125 Salisbury Street
Worcester, MA 01609

Pizza/Soda and Set-up start at 16:00
  Workshop runs from 17:00 to 21:00

Registration Link:
https://docs.google.com/forms/d/e/1FAIpQLSdNwqutzlxOhAgKQt17_XjIi-4pUUkTe5oO-u4TZaQt_iqnvg/viewform

Full Title:
FPGA Programming on the USRP with the RFNoC Framework

Abstract:
Ettus Research's RFNoC (RF Network-on-Chip) software framework is
designed to decrease the development time for experienced FPGA
engineers seeking to integrate IP into the USRP FPGA signal
processing chain. RFNoC is the framework for USRP devices that use
Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU).  Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is support

[Discuss-gnuradio] GNU Radio Conference Tickets for Sale

[Derek Kozel]

Hello all,

Registration for GRCon18 is now live! We are happy to say that the early
bird and standard ticket prices are lower than last year.
Early Bird Ticket Price (until June 30th): $399
Standard Ticket Price: $549
Latecomer Ticket Price (starting September 1st): $699

Head here to purchase your ticket: http://grcon18.eventbrite.com.

Presentation, technical paper, and tutorial submissions will open
on April 1.
If you are interested in sponsoring the conference, please get in touch
with us at gr...@gnuradio.org. Sponsors are a critical part of GRCon,
and we look forward to providing an expanded set of benefits this year.
If you have any questions, please let us know. We look forward to seeing
you for GRCon18!
Cheers,
The GRCon Organizing Committee

Important Dates

April 1 - Submission Opens
June  3 – Submission Deadline
June 17 – Acceptance Notification
June 30 – Early Bird Sales End
Sept 17 – Conference Begins!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GNU-Radio] Regarding Transfer of files using GNU-Radio and USRP-N210

[CEL]

Dear VijayKrishnan,

you use multiple blocks from the "deprecated" category, and these are
deprecated because they have systematic bugs. Don't use them, we can't
help you, that's why they are "deprecated".

So, replace the DPSK block with a simple "Constellation Modulator" on
TX, and do the clock recovery like in our PSK mod tutorial on
tutorials.gnuradio.org

Best regards,
Marcus

On Wed, 2018-02-28 at 09:01 -0700, Vijaykrishnan Sarangarajan wrote:
> Hello everyone,
> 
> I am Vijay and I am a graduate student at University of Colorado-Boulder. I 
> am trying to transfer a text file using a pair of USRP-N210s. I am pretty 
> certain that the transmission is happening ( I checked with a Spectrum 
> Analyser) but I am not able receive the text-file properly.
> 
> I have put a Wx-FFT GUI after every block in the Rx to check the flow of data 
> and I feel that the flow is as expected till the Low-pass filter. After the 
> Packet Decoder, there is nothing written in the text-file (size = 0 Bytes). 
> 
> Frequency = 950 MHz
> Sampling Rate = 500K
> 
> 
> I have attached the Tx and Rx snippets and any guidance would be greatly 
> appreciated.
> 
> Thanks and Regards,
> VijayKrishnan
> 
> VijayKrishnan Sarangarajan
> Fall-16 Graduate Student,
> ITP Department,
> University of Colorado Boulder
> Ph : 720-325-7449
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Michael Dickens]

Great! You're welcome. For my knowledge, when you were using the "uhd"
port, which version was it? If you haven't already uninstalled it from
MacPorts, you can see via "port installed uhd"; if already gone then
"port info uhd". Thx! - MLD
On Sat, Feb 3, 2018, at 2:04 AM, Vipin Sharma wrote:
> uhd-devel did the trick. No more crashes. Thanks a bunch!

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

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Vipin Sharma]

uhd-devel did the trick. No more crashes. Thanks a bunch!

Vipin

On Fri, Feb 2, 2018 at 11:18 AM, Michael Dickens 
wrote:

> Hi Vipin - OK; interesting. Can you try the following:
> {{{
> sudo port -f deactivate uhd
> sudo port install uhd-devel
> }}}
> then if those work, try running "uhd_fft" again & hopefully it will work.
> If not, send me the crash log off-list & we'll try something else. - MLD
>
> On Fri, Feb 2, 2018, at 1:23 PM, Vipin Sharma wrote:
>
> Actually, the install works fine but I am running into segmentation
> violation while running top_block.py through GRC GUI or uhd_fft on command
> line. Somewhere I am guessing Python versions are getting messed up. Here
> is the crash log after running 'uhd_fft -f 868M -s 10M'; how do I figure
> out what is causing the crash?
>
> Process:   Python [98722]
> Path:  /opt/local/Library/Frameworks/Python.framework/
> Versions/2.7/Resources/Python.app/Contents/MacOS/Python
> Identifier:org.python.python
> Version:   2.7.14 (2.7.14)
> Code Type: X86-64 (Native)
> Parent Process:bash [93492]
> Responsible:   Python [98722]
> User ID:   503
>
> Date/Time: 2018-02-02 10:19:04.736 -0800
> OS Version:Mac OS X 10.12.6 (16G1114)
> Report Version:12
> Anonymous UUID:120FE2C9-C399-E258-2FCC-CB15EFBA9026
>
> Sleep/Wake UUID:   F31F40DE-3B36-4430-A542-C83035144872
>
> Time Awake Since Boot: 27 seconds
> Time Since Wake:   2000 seconds
>
> System Integrity Protection: enabled
>
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
>
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS at 0x0037312e
> Exception Note:EXC_CORPSE_NOTIFY
>
> Termination Signal:Segmentation fault: 11
> Termination Reason:Namespace SIGNAL, Code 0xb
> Terminating Process:   exc handler [0]
>
> VM Regions Near 0x37312e:
> __LINKEDIT 0001266f3000-0001266ff000 [   48K]
> r--/rwx SM=COW  /System/Library/Extensions/IOUSBFamily.kext/Contents/
> PlugIns/IOUSBLib.bundle/Contents/MacOS/IOUSBLib
> -->
> STACK GUARD7c905000-7c906000 [4K]
> ---/rwx SM=NUL  stack guard for thread 1
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libgnuradio-blocks.3.7.11.dylib 0x0001188b7f36
> boost::asio::detail::task_io_service::init_task() + 134
> 1   libgnuradio-blocks.3.7.11.dylib 0x0001188a4367
> boost::asio::io_service::service* boost::asio::detail::service_
> registry::create
> >(boost::asio::io_service&) + 105
> 2   libuhd.003.dylib   0x000119442167
> boost::asio::detail::service_registry::do_use_service(
> boost::asio::io_service::service::key const&, 
> boost::asio::io_service::service*
> (*)(boost::asio::io_service&)) + 127
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Michael Dickens]

Hi Vipin - OK; interesting. Can you try the following:
{{{
sudo port -f deactivate uhd
sudo port install uhd-devel
}}}
then if those work, try running "uhd_fft" again & hopefully it will
work. If not, send me the crash log off-list & we'll try something
else. - MLD
On Fri, Feb 2, 2018, at 1:23 PM, Vipin Sharma wrote:
> Actually, the install works fine but I am running into segmentation
> violation while running top_block.py through GRC GUI or uhd_fft on
> command line. Somewhere I am guessing Python versions are getting
> messed up. Here is the crash log after running 'uhd_fft -f 868M -s
> 10M'; how do I figure out what is causing the crash?> 
> Process:   Python [98722]
> Path:  /opt/local/Library/Frameworks/Python.framework-
> /Versions/2.7/Resources/Python.app/Contents/MacOS/Python> Identifier: 
>org.python.python
> Version:   2.7.14 (2.7.14)
> Code Type: X86-64 (Native)
> Parent Process:bash [93492]
> Responsible:   Python [98722]
> User ID:   503
> 
> Date/Time: 2018-02-02 10:19:04.736 -0800
> OS Version:Mac OS X 10.12.6 (16G1114)
> Report Version:12
> Anonymous UUID:120FE2C9-C399-E258-2FCC-CB15EFBA9026
> 
> Sleep/Wake UUID:   F31F40DE-3B36-4430-A542-C83035144872
> 
> Time Awake Since Boot: 27 seconds
> Time Since Wake:   2000 seconds
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS at 0x0037312e
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Termination Signal:Segmentation fault: 11
> Termination Reason:Namespace SIGNAL, Code 0xb
> Terminating Process:   exc handler [0]
> 
> VM Regions Near 0x37312e:
> __LINKEDIT 0001266f3000-0001266ff000 [   48K]
> r--/rwx SM=COW  /System/Library/Extensions/IOUSBFamily.kext/Conte-
> nts/PlugIns/IOUSBLib.bundle/Contents/MacOS/IOUSBLib> --> 
> STACK GUARD7c905000-7c906000 [4K]
> ---/rwx SM=NUL  stack guard for thread 1> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>libgnuradio-blocks.3.7.11.dylib 0x0001188b7f36
>boost::asio::detail::task_io_service::init_task() + 134> 1   
> libgnuradio-blocks.3.7.11.dylib 0x0001188a4367
> boost::asio::io_service::service* boost::asio::detail::service_regist-
> ry::create
> >(boost::asio::io_service&) + 105> 2   libuhd.003.dylib   
> >0x000119442167 boost::asio::de-
> tail::service_registry::do_use_service(boost::asio::io_service::servi-
> ce::key const&, boost::asio::io_service::service*
> (*)(boost::asio::io_service&)) + 127
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Project Leadership Updates

[CEL]

Hello everyone!

I think it's time that I finally also lose a couple of words on this
topic:

Thanks everyone for making GNU Radio the most popular SDR framework
with certainly the most interesting community! This, especially,
applies to Johnathan, whose contributions on all levels, technically,
financially, as well as personally, are invaluable to the presence and
future of this framework.

I'm still a bit overwhelmed by the idea of managing the technical side
of all of this. As Ben said, we have a couple immediate issues to
tackle,  but this leadership change doesn't come with only a set of
freshly identified challenges, but also with a lot of opportunities,
which I'm planning to take. We'll try to divide the workload a bit more
evenly, which implies also dividing responsibilities, and I hope that
leads to a high development coordination capacity while keeping the
code quality up :)

So, a bit on what to expect in the next week(s):
First of all, although I really feel we should be getting 3.8 out as
soon as possible, that also means: Not a day earlier; we'll take the
time to merge pending PRs, release a 3.7.xx version, and define what
will be part of 3.8, and what will then be on the master branch for the
 release after that. 
There will be slight changes to the dev process, but details on that
are pending while I try to meet up with a bunch of people with whom I
want to coordinate this.
I will hurry myself as much as feasible, but some features simply take
time, and my mision is to foster long-term active development, which
means that it's equally important to not frustrate users nor
developers; the next thing we'll do is sit together and find what the
"minimum viable release" is that doesn't obstruct future development
and get that ready for the masses!

As said, we'll not abandon anything anytime soon, but we will focus on
developing "forward", whilst keeping 3.7 nicely running and bug-free.
Part of that plan is that I consider the 3.8 release to be "relatively
soon", but that really depends on the feature set we define to be in
3.8. I won't be doing that definition alone; we'll all discuss this.
Basically, I feel that the most important features of 3.8 are Python 3
and Qt5, but these also come with effects on a lot of other subsystems.
Note that anything that doesn't make it into the 3.8 release is far
from being abandoned – we'll definitely crank up the release frequency.

I feel I'm already being overly specific and lengthy; a lot of this
process will actually unfold in the next two, three weeks. Clearly,
we'll have to come up with some kind of documentation (and if it's just
a blog post) that explains how we want to proceed, and I promise we'll
do that, as things fall into place.

On a personal note, I'm super happy to be part of this, and I know I've
been handed an impressive piece of software, a fantastic and actually
historically rich ecosystem, and anyone who's been observing me on the
mailing list hopefully realizes how much I like the community. The
speed of all this surprises even me, so please bear with me while I
sort out how to actually *do* all this. There's really so much more
that one wishes one had the time (and army of developers) for to
implement than I'll be able to do within a couple years of time frame,
so the trick really is finding out what the project needs the most.

Therefore, the thing I'd really like to ask everybody right now is to
do is sit down and think about where they'd like the project to move
from here, and discuss that. We're setting up a very Python Enhancement
Process-alike thing so that such ideas don't go to waste, without
adding the bureaucratic overhead of having a hierarchical idea
collection process. It's certain that if anything, we must encourage
users to become contributors, no matter whether it's in shape of bug
reports, pull requests, requests for architectural features, or simply
by engaging with each other. Same goes for developers (which are users,
too): I'll need you to be as productive as possible, so I'll try to get
into your way as little as feasible. 

So, now I'll have to mentally prepare for FOSDEM; if you're there, come
see me, say hello, but please don't expect me to have qualified answers
for complex development questions just yet :)
Anyway, I **know** you'll either be in the SDR devroom at FOSDEM on
Sunday, or neglecting your social live by watching the videos, so

see you and:

Best regards,

Marcus
(freshly baked GNU Radio Project Maintainer)

On Wed, 2018-01-31 at 15:24 -0500, Ben Hilburn wrote:
> Hi all!
> 
> As usual, there is a lot going on in the project and community,
> including GSOC & SOCIS, GRCon planning, and new development. There
> are also some big changes happening in the project leadership that I
> want to announce.
> 
> First, our Chief Architect and Foundation CTO, Johnathan Corgan, is
> moving into a new role as a Technical Advisor for the project. He
> will no longer be leading the project's technical development, b

Re: [Discuss-gnuradio] GNU Radio Project Leadership Updates

[Robert McGwier]

Thank you Jonathan.  I hope you have more time to enjoy your airplane and
amateur radio!

Welcome to all the other "old" new people taking on great roles.  We
appreciate it.

Bob


On Wed, Jan 31, 2018 at 3:24 PM, Ben Hilburn  wrote:

> Hi all!
>
> As usual, there is a lot going on in the project and community, including
> GSOC & SOCIS, GRCon planning, and new development. There are also some big
> changes happening in the project leadership that I want to announce.
>
> First, our Chief Architect and Foundation CTO, Johnathan Corgan, is moving
> into a new role as a Technical Advisor for the project. He will no longer
> be leading the project's technical development, but will remain part of the
> project leadership, sharing his technical knowledge and guidance. Johnathan
> has been a member of the GNU Radio project for 12 years, and served as the
> Project Maintainer for much of that. Additionally, for many years GNU
> Radio's infrastructure only existed because Johnathan paid for them with
> his own funds. Johnathan's contributions and leadership have been critical
> to GNU Radio's tremendous success, and the he deserves significant credit
> for the work he has done for the project and community.
>
> Here's a note from Johnathan, himself, about the change:
>
> I've watched GNU Radio grow from its origins in the enthusiast community
>> to a mainstream tool used extensively for government, academic, and
>> commercial wireless research and applications. To have helped steward its
>> design and implementation over the last decade, especially as an open
>> source project with a purely volunteer community, has put me in contact
>> with many talented and creative developers. Finally, teaching almost a
>> hundred GNU Radio courses and consulting on GNU Radio projects in over a
>> dozen countries has been the highlight of my career.
>>
>> While I will continue to engage with users and provide technical
>> assistance to the GNU Radio project, its forward growth depends on new
>> leadership and commitment. I look forward to seeing what's next.
>>
>
> As Johnathan transitions to his new role, well known developers in the
> community will be taking on expanded responsibilities. Marcus Mueller will
> become the Project Maintainer, responsible for merging, tagging, and
> generally maintaining the codebase. Derek Kozel, Bastian Bloessl, Andrej
> Rode, Philip Balister, and Nate Temple will become Project Officers, taking
> on various development and community efforts to keep the project moving
> forward.
>
> My position leading the project and Foundation remains unchanged, as do
> the roles of Martin Braun (Community Manager, PyBOMBS maintainer,
> Foundation Officer), and Nathan West (VOLK maintainer). While Andrej and
> Derek are expanding their development roles, Andrej will also continue as
> our web & devops infrastructure admin, and Derek will continue to organize
> GRCon18. Felix Wunsch will continue leading GNU Radio's participation in
> GSoC & SOCIS.
>
> Our major priorities in the near-term include integrating the latest pull
> requests, publishing a clear process for community suggestions &
> contributions to the project, and getting to the long-awaited 3.8 release.
> If you're interested in these topics, keep an eye on the list and IRC!
> You'll start to see some announcements and activity very shortly.
>
> We have a strong core team of experienced GNU Radio developers and
> community members, and I'm really excited about the work that will get done
> over the coming months. If you want to get involved, please don't hesitate
> to reach out! We love working with new contributors. And, as always, if you
> have any questions, just let us know.
>
> Lastly, I would like to once again publicly thank Johnathan for all of his
> hard work and contributions as a leader in our community over the last 12
> years!
>
> Happy Hacking,
> Ben
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Bob McGwier
Founder, Federated Wireless, Inc
Founder and Technical Advisor, HawkEye 360, Inc
Research Professor Virginia Tech
Chief Scientist:  The Ted and Karyn Hume Center for National Security and
Technology
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn, Trustee K4KDJ
Director of AMSAT
Member of PVRC (Roanoke-Blacksburg), TAPR,  life member of ARRL and AMSAT,
NRVR.ORG (Rocketry)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Project Leadership Updates

[Ben Hilburn]

Hi all!

As usual, there is a lot going on in the project and community, including
GSOC & SOCIS, GRCon planning, and new development. There are also some big
changes happening in the project leadership that I want to announce.

First, our Chief Architect and Foundation CTO, Johnathan Corgan, is moving
into a new role as a Technical Advisor for the project. He will no longer
be leading the project's technical development, but will remain part of the
project leadership, sharing his technical knowledge and guidance. Johnathan
has been a member of the GNU Radio project for 12 years, and served as the
Project Maintainer for much of that. Additionally, for many years GNU
Radio's infrastructure only existed because Johnathan paid for them with
his own funds. Johnathan's contributions and leadership have been critical
to GNU Radio's tremendous success, and the he deserves significant credit
for the work he has done for the project and community.

Here's a note from Johnathan, himself, about the change:

I've watched GNU Radio grow from its origins in the enthusiast community to
> a mainstream tool used extensively for government, academic, and commercial
> wireless research and applications. To have helped steward its design and
> implementation over the last decade, especially as an open source project
> with a purely volunteer community, has put me in contact with many talented
> and creative developers. Finally, teaching almost a hundred GNU Radio
> courses and consulting on GNU Radio projects in over a dozen countries has
> been the highlight of my career.
>
> While I will continue to engage with users and provide technical
> assistance to the GNU Radio project, its forward growth depends on new
> leadership and commitment. I look forward to seeing what's next.
>

As Johnathan transitions to his new role, well known developers in the
community will be taking on expanded responsibilities. Marcus Mueller will
become the Project Maintainer, responsible for merging, tagging, and
generally maintaining the codebase. Derek Kozel, Bastian Bloessl, Andrej
Rode, Philip Balister, and Nate Temple will become Project Officers, taking
on various development and community efforts to keep the project moving
forward.

My position leading the project and Foundation remains unchanged, as do the
roles of Martin Braun (Community Manager, PyBOMBS maintainer, Foundation
Officer), and Nathan West (VOLK maintainer). While Andrej and Derek are
expanding their development roles, Andrej will also continue as our web &
devops infrastructure admin, and Derek will continue to organize GRCon18.
Felix Wunsch will continue leading GNU Radio's participation in GSoC &
SOCIS.

Our major priorities in the near-term include integrating the latest pull
requests, publishing a clear process for community suggestions &
contributions to the project, and getting to the long-awaited 3.8 release.
If you're interested in these topics, keep an eye on the list and IRC!
You'll start to see some announcements and activity very shortly.

We have a strong core team of experienced GNU Radio developers and
community members, and I'm really excited about the work that will get done
over the coming months. If you want to get involved, please don't hesitate
to reach out! We love working with new contributors. And, as always, if you
have any questions, just let us know.

Lastly, I would like to once again publicly thank Johnathan for all of his
hard work and contributions as a leader in our community over the last 12
years!

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

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Michael Dickens]

Thanks for reporting back, Vipin, and your creative solution. Sometimes
starting over is the way to go ;)
A strange note: the "rev-upgrade" logfile was clean; no errors or issues
found beyond the usual innocuous ones. I've no idea why port thought uhd
was broken the final run-through.
Anyway: Good catch on the gpsd issue; I'm glad we got it fixed quickly! You're 
very welcome for the support! - MLD
On Wed, Jan 31, 2018, at 2:28 AM, Vipin Sharma wrote:
> Ok, I tried another attempt by completely removing the MacPorts and
> restarting. This time it worked!> sudo port -fp uninstall installed
> sudo rm -rf /opt/local /Applications/DarwinPorts
> /Applications/MacPorts /Library/LaunchDaemons/org.macports.*
> /Library/Receipts/DarwinPorts*.pkg
> /Library/Receipts/MacPorts*.pkg
> /Library/StartupItems/DarwinPortsStartup
> /Library/Tcl/darwinports1.0 /Library/Tcl/macports1.0
> ~/.macports> 
> sudo port selfupdate


> 


> sudo port install gnuradio  


> 


> 


> I got segmentation fault when I tried this:


> uhd_fft -f 868M -s 10M


> 


> but then after trying 


> 


> sudo port select --set python python27


> 
> uhd_fft works fine.
> 
> Thanks for your support!



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

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Vipin Sharma]

Ok, I tried another attempt by completely removing the MacPorts and
restarting. This time it worked!
sudo port -fp uninstall installed

sudo rm -rf /opt/local /Applications/DarwinPorts
/Applications/MacPorts /Library/LaunchDaemons/org.macports.*
  /Library/Receipts/DarwinPorts*.pkg
/Library/Receipts/MacPorts*.pkg
/Library/StartupItems/DarwinPortsStartup
/Library/Tcl/darwinports1.0 /Library/Tcl/macports1.0
~/.macports

sudo port selfupdate

sudo port install gnuradio


I got segmentation fault when I tried this:

uhd_fft -f 868M -s 10M


but then after trying

sudo port select --set python python27

uhd_fft works fine.

Thanks for your support!


Vipin

On Tue, Jan 30, 2018 at 7:42 PM, Vipin Sharma 
wrote:

> Alright, I gave it a try after your fix just now. Still not successful.
> Here is what I do/get. At first it seemed uhd installation went successful
> but while building gnuradio something goes wrong. I also tried collecting
> the uhd_rev.txt file from your earlier comment. I will send that file
> directly to you in the next email.
>
> mac01:~ emwaves$ sudo port selfupdate
>
> Password:
>
> --->  Updating MacPorts base sources using rsync
>
> MacPorts base version 2.4.2 installed,
>
> MacPorts base version 2.4.2 downloaded.
>
> --->  Updating the ports tree
>
> --->  MacPorts base is already the latest version
>
>
> The ports tree has been updated. To upgrade your installed ports, you
> should run
>
>   port upgrade outdated
>
> mac01:~ emwaves$ sudo port uninstall gnuradio
>
> --->  Deactivating gnuradio @3.7.11_6+docs+grc+jack+
> log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
>
> --->  Cleaning gnuradio
>
> --->  Uninstalling gnuradio @3.7.11_6+docs+grc+jack+
> log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
>
> --->  Cleaning gnuradio
>
> mac01:~ emwaves$ sudo port uninstall uhd
>
> --->  Deactivating uhd @3.10.2.0_1+docs+examples+
> gpsd+libusb+manpages+manual+python27+test
>
> --->  Cleaning uhd
>
> --->  Uninstalling uhd @3.10.2.0_1+docs+examples+
> gpsd+libusb+manpages+manual+python27+test
>
> --->  Cleaning uhd
>
> mac01:~ emwaves$ sudo port install gnuradio
>
> --->  Computing dependencies for gtk2
>
> --->  Fetching archive for gtk2
>
> --->  Attempting to fetch gtk2-2.24.32_0+x11.darwin_16.x86_64.tbz2 from
> https://packages.macports.org/gtk2
>
> --->  Attempting to fetch gtk2-2.24.32_0+x11.darwin_16.x86_64.tbz2.rmd160
> from https://packages.macports.org/gtk2
>
> --->  Installing gtk2 @2.24.32_0+x11
>
> --->  Cleaning gtk2
>
> --->  Computing dependencies for gtk2
>
> --->  Deactivating gtk2 @2.24.31_0+x11
>
> --->  Cleaning gtk2
>
> --->  Activating gtk2 @2.24.32_0+x11
>
> --->  Cleaning gtk2
>
> --->  Computing dependencies for py27-zmq
>
> --->  Fetching archive for py27-zmq
>
> --->  Attempting to fetch py27-zmq-16.0.4_0.darwin_16.x86_64.tbz2 from
> https://packages.macports.org/py27-zmq
>
> --->  Attempting to fetch py27-zmq-16.0.4_0.darwin_16.x86_64.tbz2.rmd160
> from https://packages.macports.org/py27-zmq
>
> --->  Installing py27-zmq @16.0.4_0
>
> --->  Cleaning py27-zmq
>
> --->  Computing dependencies for py27-zmq
>
> --->  Deactivating py27-zmq @16.0.3_0
>
> --->  Cleaning py27-zmq
>
> --->  Activating py27-zmq @16.0.4_0
>
> --->  Cleaning py27-zmq
>
> --->  Computing dependencies for gnuradio
>
> The following dependencies will be installed:  uhd
>
> Continue? [Y/n]: Y
>
> --->  Fetching archive for uhd
>
> --->  Attempting to fetch uhd-3.10.2.0_2+docs+examples+
> gpsd+libusb+manpages+manual+python27+test.darwin_16.x86_64.tbz2 from
> https://packages.macports.org/uhd
>
> --->  Attempting to fetch uhd-3.10.2.0_2+docs+examples+
> gpsd+libusb+manpages+manual+python27+test.darwin_16.x86_64.tbz2 from
> http://sea.us.packages.macports.org/macports/packages/uhd
>
> --->  Attempting to fetch uhd-3.10.2.0_2+docs+examples+
> gpsd+libusb+manpages+manual+python27+test.darwin_16.x86_64.tbz2 from
> http://ywg.ca.packages.macports.org/mirror/macports/packages/uhd
>
> --->  Fetching distfiles for uhd
>
> --->  Verifying checksums for uhd
>
> --->  Extracting uhd
>
> --->  Applying patches to uhd
>
> --->  Configuring uhd
>
> --->  Building uhd
>
> --->  Staging uhd into destroot
>
> --->  Installing uhd @3.10.2.0_2+docs+examples+
> gpsd+libusb+manpages+manual+python27+test
>
> --->  Activating uhd @3.10.2.0_2+docs+examples+
> gpsd+libusb+manpages+manual+python27+test
>
> --->  Cleaning uhd
>
> --->  Fetching archive for gnuradio
>
> --->  Attempting to fetch gnuradio-3.7.11_6+docs+grc+jack+log4cpp+logging+
> portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq.darwin_16.x86_64.tbz2 from
> https://packages.macports.org/gnuradio
>
> --->  Attempting to fetch gnuradio-3.7.11_6+docs+grc+jack+log4cpp+logging+
> portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq.darwin_16.x86_64.tbz2 from
> http://sea.us.packages.macports.org/macports/packages/gnuradio
>
> --->  Attempting to fetch gnuradio-3.7.11_6+docs+grc+jack+log4cpp+logging+
> portaudio+qtgui+sdl+swig+uhd

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Vipin Sharma]

Alright, I gave it a try after your fix just now. Still not successful.
Here is what I do/get. At first it seemed uhd installation went successful
but while building gnuradio something goes wrong. I also tried collecting
the uhd_rev.txt file from your earlier comment. I will send that file
directly to you in the next email.

mac01:~ emwaves$ sudo port selfupdate

Password:

--->  Updating MacPorts base sources using rsync

MacPorts base version 2.4.2 installed,

MacPorts base version 2.4.2 downloaded.

--->  Updating the ports tree

--->  MacPorts base is already the latest version


The ports tree has been updated. To upgrade your installed ports, you
should run

  port upgrade outdated

mac01:~ emwaves$ sudo port uninstall gnuradio

--->  Deactivating gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

--->  Cleaning gnuradio

--->  Uninstalling gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

--->  Cleaning gnuradio

mac01:~ emwaves$ sudo port uninstall uhd

--->  Deactivating uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Uninstalling uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

mac01:~ emwaves$ sudo port install gnuradio

--->  Computing dependencies for gtk2

--->  Fetching archive for gtk2

--->  Attempting to fetch gtk2-2.24.32_0+x11.darwin_16.x86_64.tbz2 from
https://packages.macports.org/gtk2

--->  Attempting to fetch gtk2-2.24.32_0+x11.darwin_16.x86_64.tbz2.rmd160
from https://packages.macports.org/gtk2

--->  Installing gtk2 @2.24.32_0+x11

--->  Cleaning gtk2

--->  Computing dependencies for gtk2

--->  Deactivating gtk2 @2.24.31_0+x11

--->  Cleaning gtk2

--->  Activating gtk2 @2.24.32_0+x11

--->  Cleaning gtk2

--->  Computing dependencies for py27-zmq

--->  Fetching archive for py27-zmq

--->  Attempting to fetch py27-zmq-16.0.4_0.darwin_16.x86_64.tbz2 from
https://packages.macports.org/py27-zmq

--->  Attempting to fetch py27-zmq-16.0.4_0.darwin_16.x86_64.tbz2.rmd160
from https://packages.macports.org/py27-zmq

--->  Installing py27-zmq @16.0.4_0

--->  Cleaning py27-zmq

--->  Computing dependencies for py27-zmq

--->  Deactivating py27-zmq @16.0.3_0

--->  Cleaning py27-zmq

--->  Activating py27-zmq @16.0.4_0

--->  Cleaning py27-zmq

--->  Computing dependencies for gnuradio

The following dependencies will be installed:  uhd

Continue? [Y/n]: Y

--->  Fetching archive for uhd

--->  Attempting to fetch
uhd-3.10.2.0_2+docs+examples+gpsd+libusb+manpages+manual+python27+test.darwin_16.x86_64.tbz2
from https://packages.macports.org/uhd

--->  Attempting to fetch
uhd-3.10.2.0_2+docs+examples+gpsd+libusb+manpages+manual+python27+test.darwin_16.x86_64.tbz2
from http://sea.us.packages.macports.org/macports/packages/uhd

--->  Attempting to fetch
uhd-3.10.2.0_2+docs+examples+gpsd+libusb+manpages+manual+python27+test.darwin_16.x86_64.tbz2
from http://ywg.ca.packages.macports.org/mirror/macports/packages/uhd

--->  Fetching distfiles for uhd

--->  Verifying checksums for uhd

--->  Extracting uhd

--->  Applying patches to uhd

--->  Configuring uhd

--->  Building uhd

--->  Staging uhd into destroot

--->  Installing uhd
@3.10.2.0_2+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Activating uhd
@3.10.2.0_2+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Fetching archive for gnuradio

--->  Attempting to fetch
gnuradio-3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq.darwin_16.x86_64.tbz2
from https://packages.macports.org/gnuradio

--->  Attempting to fetch
gnuradio-3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq.darwin_16.x86_64.tbz2
from http://sea.us.packages.macports.org/macports/packages/gnuradio

--->  Attempting to fetch
gnuradio-3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq.darwin_16.x86_64.tbz2
from http://ywg.ca.packages.macports.org/mirror/macports/packages/gnuradio

--->  Fetching distfiles for gnuradio

--->  Verifying checksums for gnuradio

--->  Extracting gnuradio

--->  Applying patches to gnuradio

--->  Configuring gnuradio

--->  Building gnuradio

--->  Staging gnuradio into destroot

--->  Installing gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

--->  Activating gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

--->  Cleaning gnuradio

--->  Updating database of binaries

--->  Scanning binaries for linking errors

--->  Found 76 broken files, matching files to ports

--->  Found 1 broken port, determining rebuild order

You can always run 'port rev-upgrade' again to fix errors.

The following ports will be rebuilt: uhd @3.10.2.0
+docs+examples+gpsd+libusb+manpages+manual+python27+test

Continue? [Y/n]: Y

--->  Computing dependencies for

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Michael Dickens]

I pushed fixes into MacPorts this morning. Will be live by around 9:30
AM US/Eastern (about 30 minutes from now). You will need to "selfupdate"
or "sync" to get the changes. Please let me know (here or off list)
success or failure. Cheers! - MLD
On Mon, Jan 29, 2018, at 8:54 PM, Vipin Sharma wrote:
> Great; thank you. I will just wait for your fix.

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

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Vipin Sharma]

Great; thank you. I will just wait for your fix.

Vipin

On Mon, Jan 29, 2018 at 2:38 PM, Michael Dickens 
wrote:

> I can now replicate the issue locally, so I don't need your rev-upgrade
> log. The issue is that a dependency, gpsd, was recently updated in MacPorts
> & the update somehow changed the self-id of the primary library -- was
> "${prefix}/lib/libgpsd.dylib" and now is just "libgpsd.dylib", which won't
> work. The issue has nothing to do with UHD coding per se; it's about a
> dependency that's messing things up for UHD linking. I'm looking into a
> fix. - MLD
>
> On Mon, Jan 29, 2018, at 9:51 AM, Michael Dickens wrote:
> > Hi Vipin - Can you execute:
> > {{{
> > sudo port -d -y rev-upgrade > ~/Desktop/uhd_rev.txt 2>&1
> > bzip2 ~/Desktop/uhd_rev.txt
> > }}}
> > then send me off-list the resulting file? That's going to be the easiest
> > way for me to debug what's going on. The basic issue is that 'port' is
> > finding library linkage inconsistencies (1 or more) in the UHD install.
> > "rev-upgrade" in debug mode prints out a lot of stuff & so why I say
> > "off-list"... - MLD
> >
> > On Mon, Jan 29, 2018, at 3:39 AM, Vipin Sharma wrote:
> > > I am trying to install GnuRadio on MacBook Pro (13" Late 2013) with
> Mac OS X 10.12. I am using MacPorts to install. Upon executing 'sudo ports
> install gnuradio' everything goes fine until "Building uhd" stage appears.
> > >
> > > I get this error:
> > >
> > > --->  Installing gnuradio @3.7.11_6+docs+grc+jack+
> log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
> > > --->  Activating gnuradio @3.7.11_6+docs+grc+jack+
> log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
> > > [snip]
> > > --->  Found 76 broken files, matching files to ports
> > > Error: Port uhd is still broken after rebuilding it more than 3 times.
> > > Error: Please run port -d -y rev-upgrade and use the output to report
> a bug.
> > > Error: rev-upgrade failed: Port uhd still broken after rebuilding 3
> times
> > > Error: Follow https://guide.macports.org/#project.tickets to report a
> bug.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Michael Dickens]

I can now replicate the issue locally, so I don't need your rev-upgrade log. 
The issue is that a dependency, gpsd, was recently updated in MacPorts & the 
update somehow changed the self-id of the primary library -- was 
"${prefix}/lib/libgpsd.dylib" and now is just "libgpsd.dylib", which won't 
work. The issue has nothing to do with UHD coding per se; it's about a 
dependency that's messing things up for UHD linking. I'm looking into a fix. - 
MLD

On Mon, Jan 29, 2018, at 9:51 AM, Michael Dickens wrote:
> Hi Vipin - Can you execute:
> {{{
> sudo port -d -y rev-upgrade > ~/Desktop/uhd_rev.txt 2>&1
> bzip2 ~/Desktop/uhd_rev.txt
> }}}
> then send me off-list the resulting file? That's going to be the easiest 
> way for me to debug what's going on. The basic issue is that 'port' is 
> finding library linkage inconsistencies (1 or more) in the UHD install. 
> "rev-upgrade" in debug mode prints out a lot of stuff & so why I say 
> "off-list"... - MLD
> 
> On Mon, Jan 29, 2018, at 3:39 AM, Vipin Sharma wrote:
> > I am trying to install GnuRadio on MacBook Pro (13" Late 2013) with Mac OS 
> > X 10.12. I am using MacPorts to install. Upon executing 'sudo ports install 
> > gnuradio' everything goes fine until "Building uhd" stage appears. 
> > 
> > I get this error:
> > 
> > --->  Installing gnuradio 
> > @3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
> > --->  Activating gnuradio 
> > @3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
> > [snip]
> > --->  Found 76 broken files, matching files to ports
> > Error: Port uhd is still broken after rebuilding it more than 3 times.
> > Error: Please run port -d -y rev-upgrade and use the output to report a bug.
> > Error: rev-upgrade failed: Port uhd still broken after rebuilding 3 times
> > Error: Follow https://guide.macports.org/#project.tickets to report a bug.

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

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Michael Dickens]

Hi Vipin - Can you execute:
{{{
sudo port -d -y rev-upgrade > ~/Desktop/uhd_rev.txt 2>&1
bzip2 ~/Desktop/uhd_rev.txt
}}}
then send me off-list the resulting file? That's going to be the easiest way 
for me to debug what's going on. The basic issue is that 'port' is finding 
library linkage inconsistencies (1 or more) in the UHD install. "rev-upgrade" 
in debug mode prints out a lot of stuff & so why I say "off-list"... - MLD

On Mon, Jan 29, 2018, at 3:39 AM, Vipin Sharma wrote:
> I am trying to install GnuRadio on MacBook Pro (13" Late 2013) with Mac OS X 
> 10.12. I am using MacPorts to install. Upon executing 'sudo ports install 
> gnuradio' everything goes fine until "Building uhd" stage appears. 
> 
> I get this error:
> 
> --->  Installing gnuradio 
> @3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
> --->  Activating gnuradio 
> @3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq
> [snip]
> --->  Found 76 broken files, matching files to ports
> Error: Port uhd is still broken after rebuilding it more than 3 times.
> Error: Please run port -d -y rev-upgrade and use the output to report a bug.
> Error: rev-upgrade failed: Port uhd still broken after rebuilding 3 times
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.

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

[Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Vipin Sharma]

Hi,

I am trying to install GnuRadio on MacBook Pro (13" Late 2013) with Mac OS
X 10.12. I am using MacPorts to install. Upon executing 'sudo ports install
gnuradio' everything goes fine until "Building uhd" stage appears.

I get this error:

--->  Installing gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

--->  Activating gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

--->  Cleaning gnuradio

--->  Updating database of binaries

--->  Scanning binaries for linking errors

--->  Found 76 broken files, matching files to ports

--->  Found 1 broken port, determining rebuild order

You can always run 'port rev-upgrade' again to fix errors.

The following ports will be rebuilt: uhd @3.10.2.0
+docs+examples+gpsd+libusb+manpages+manual+python27+test

Continue? [Y/n]: Y

--->  Computing dependencies for uhd

--->  Cleaning uhd

--->  Scanning binaries for linking errors

--->  Found 76 broken files, matching files to ports

--->  Found 1 broken port, determining rebuild order

--->  Rebuilding in order

 uhd @3.10.2.0 +docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Computing dependencies for uhd

--->  Fetching distfiles for uhd

--->  Verifying checksums for uhd

--->  Extracting uhd

--->  Applying patches to uhd

--->  Configuring uhd

--->  Building uhd

--->  Staging uhd into destroot

--->  Unable to uninstall uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test, the
following ports depend on it:

--->  gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

Warning: Uninstall forced.  Proceeding despite dependencies.

--->  Deactivating uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Uninstalling uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Computing dependencies for uhd

--->  Installing uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Activating uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Updating database of binaries

--->  Scanning binaries for linking errors

--->  Found 76 broken files, matching files to ports

--->  Found 1 broken port, determining rebuild order

--->  Rebuilding in order

 uhd @3.10.2.0 +docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Computing dependencies for uhd

--->  Fetching distfiles for uhd

--->  Verifying checksums for uhd

--->  Extracting uhd

--->  Applying patches to uhd

--->  Configuring uhd

--->  Building uhd

--->  Staging uhd into destroot

--->  Unable to uninstall uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test, the
following ports depend on it:

--->  gnuradio
@3.7.11_6+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq

Warning: Uninstall forced.  Proceeding despite dependencies.

--->  Deactivating uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Uninstalling uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Computing dependencies for uhd

--->  Installing uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Activating uhd
@3.10.2.0_1+docs+examples+gpsd+libusb+manpages+manual+python27+test

--->  Cleaning uhd

--->  Updating database of binaries

--->  Scanning binaries for linking errors

--->  Found 76 broken files, matching files to ports

Error: Port uhd is still broken after rebuilding it more than 3 times.

Error: Please run port -d -y rev-upgrade and use the output to report a bug.

Error: rev-upgrade failed: Port uhd still broken after rebuilding 3 times

Error: Follow https://guide.macports.org/#project.tickets to report a bug.

--->  Some of the ports you installed have notes:

  coreutils has the following notes:

The tools provided by GNU coreutils are prefixed with the character 'g'
by default to distinguish

them from the BSD commands.

For example, cp becomes gcp and ls becomes gls.



If you want to use the GNU tools by default, add this directory to the
front of your PATH

environment variable:

/opt/local/libexec/gnubin/

  dbus has the following notes:




# Startup items have been generated that will aid in

# starting dbus with launchd. They are disabled

# by default. Execute the following commands to start them,

# and to cause them to launch at startup:

#

# sudo launchctl load -w
/Library/LaunchDaemons/org.freedesktop.dbus-system.plist

# launchctl load -w
/Library/LaunchAgents/org.freedesktop.dbus-session.plist




  gpsd has the following notes:

The xgps variant is now needed to g

Re: [Discuss-gnuradio] GNU Radio Project Call Today!

[Martin Braun]

On 01/18/2018 09:22 AM, Martin Braun wrote:
> Hi all,
> 
> we'll have our first 2018 project call today. Join us on IRC or Slack,
> and we'll be posting the links to watch on YouTube or to join on
> Hangouts there.

Link to join:

https://hangouts.google.com/hangouts/_/w2exmubgh5eh7pqvl4nuvy4dnue

...or watch:

http://youtu.be/BGPGk2iy_FA

Cheers,
Martin

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

[Discuss-gnuradio] GNU Radio Project Call Today!

[Martin Braun]

Hi all,

we'll have our first 2018 project call today. Join us on IRC or Slack,
and we'll be posting the links to watch on YouTube or to join on
Hangouts there.

Cheers,
Martin

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

Re: [Discuss-gnuradio] GNU Radio v3.7.11.6 no attribute to byte array error

[Brian Clark]

Marcus,

I have now checked the patch, and I believe that it was an attempt by a
user to resolve the issue.  The Debi and bug as far as I can tell is
unresolved.

As a workaround it only affects QT GUI so I'm now using WX.

On 17 January 2018 at 19:11, Müller, Marcus (CEL)  wrote:

> Hi Brian,
>
> this came up today already, and seems solved by a patch:
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2018-01/msg00108.htm
> l
>
> Maybe this helps,
> best regards,
> Marcus
>
> On Wed, 2018-01-17 at 19:00 +, Brian Clark wrote:
> > Good evening all,
> >
> > I have recently updated my kali linux distribution using the below
> commands.
> >
> > apt-get update
> > apt-get upgrade
> > apt-get dist-upgrade
> >
> > I have a strange error that has occurred within GNU Radio where an error
> message as shown below appears:
> >
> > self.restoreGeometry(self.settings.value("geometry").toByteArray())
> > AttributeError: 'NoneType' object has no attribute 'toByteArray'
> >
> > When I investigated this it appears that my gnuradio installation has
> updated from 3.7.11.2 to 3.7.11.6.
> >
> > I have attempted, (unsuccesfully) to resolve this issue and neither my
> own knowledge or multiple google searches have identified the cause.  This
> is true on a friends of mine build aswell so may be a wider problem.
> >
> > Is there something I am missing? and if so do you have any suggestions?
> >
> > Kind Regards
> >
> > Brian Clark
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio v3.7.11.6 no attribute to byte array error

[CEL]

Hi Brian,

this came up today already, and seems solved by a patch:

http://lists.gnu.org/archive/html/discuss-gnuradio/2018-01/msg00108.htm
l

Maybe this helps,
best regards,
Marcus

On Wed, 2018-01-17 at 19:00 +, Brian Clark wrote:
> Good evening all,
> 
> I have recently updated my kali linux distribution using the below commands.
> 
> apt-get update
> apt-get upgrade
> apt-get dist-upgrade
> 
> I have a strange error that has occurred within GNU Radio where an error 
> message as shown below appears:
> 
> self.restoreGeometry(self.settings.value("geometry").toByteArray())
> AttributeError: 'NoneType' object has no attribute 'toByteArray'
> 
> When I investigated this it appears that my gnuradio installation has updated 
> from 3.7.11.2 to 3.7.11.6.
> 
> I have attempted, (unsuccesfully) to resolve this issue and neither my own 
> knowledge or multiple google searches have identified the cause.  This is 
> true on a friends of mine build aswell so may be a wider problem.  
> 
> Is there something I am missing? and if so do you have any suggestions?
> 
> Kind Regards
> 
> Brian Clark
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio v3.7.11.6 no attribute to byte array error

[Brian Clark]

Good evening all,

I have recently updated my kali linux distribution using the below commands.

apt-get update
apt-get upgrade
apt-get dist-upgrade

I have a strange error that has occurred within GNU Radio where an error
message as shown below appears:

self.restoreGeometry(self.settings.value("geometry").toByteArray())
AttributeError: 'NoneType' object has no attribute 'toByteArray'

When I investigated this it appears that my gnuradio installation has
updated from 3.7.11.2 to 3.7.11.6.

I have attempted, (unsuccesfully) to resolve this issue and neither my own
knowledge or multiple google searches have identified the cause.  This is
true on a friends of mine build aswell so may be a wider problem.

Is there something I am missing? and if so do you have any suggestions?

Kind Regards

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

Re: [Discuss-gnuradio] GNU Radio Project Call December on today!

[Martin Braun]

On 12/21/2017 09:20 AM, Martin Braun wrote:
> The call is at 10:00 Pacific time, which is about 40 minutes from now.
> Tune into the usual place! I'll post the links on IRC/Slack.
> 
> We'll do an end-of-the-year wrapup.

Follow us on YT:

http://youtu.be/zfaegNFHT_A

or join:

https://hangouts.google.com/hangouts/_/xqjk7p3airfwleqt7itv5uc6see

Cheers,
Martin

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

[Discuss-gnuradio] GNU Radio Project Call December on today!

[Martin Braun]

The call is at 10:00 Pacific time, which is about 40 minutes from now.
Tune into the usual place! I'll post the links on IRC/Slack.

We'll do an end-of-the-year wrapup.

Cheers,
Martin

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

Re: [Discuss-gnuradio] GNU Radio 3.7.12 RFNoC set_start_time()

[Reggie Wilcox]

Hi Derek,

Thanks for the advice. I tried adding in a sleep command, but the radio
still is not waiting the 15 seconds. I feel like it is an issue on the
software side since I never see a start time tagged in the packets from the
PC.

I have been digging into the GNUradio source code to see if I can identify
some of the cause and think it has to do with GNU Radio not propagating the
start time correctly. From what I can trace:
set_start_time() is implemented in rfnoc_block_impl.h, inherited as a
vertual function in rfnoc_block.h, and then inherited in rfnoc_radio.h,
which is the class it is called from.
set_start_time() sets two private variables in rfnoc_block_impl,
_start_time_set and _start_time based on the start time we give it.
In rfnoc_block_impl.cc, which handles the streaming, the TX streams never
look at this variable and the start time is never set. I can confirm this
by printing _tx.metadata.has_time_spec and _tx.metadata.time_spec.
Furthermore, these bits of metadata are intentionally purged, with the
calls:
_tx.metadata.start_of_burst = false;
_tx.metadata.end_of_burst = false;
_tx.metadata.has_time_spec = false;

If I explicitly change _tx.metadata.has_time_spec to true and
_tx.metadata.set time_spec to 15s, I observe the desired behaviour of
waiting 15s before transmitting. I think that this indicates that the
functionality is not completely integrated to GNU Radio and that there
needs to be some modification to the source in order to implement this. I
have implemented a simple fix that seems to work:
if (_start_time_set) {
  _tx.metadata.has_time_spec = true;
  _tx.metadata.time_spec = _start_time;
  } else {
  _tx.metadata.has_time_spec = false;
  }
Note that this code is only called for the first RFNoC block in my design
(which is a DmaFIFO), so I am only calling set_start_time() for the DmaFIFO
block. I'm not sure if this is a robust solution, but it seems to work for
my purposes. However, I think that this does indicate that there is
something missing with the TX start time implementation.

Thanks for your time,

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

Re: [Discuss-gnuradio] GNU Radio 3.7.12 RFNoC set_start_time()

[Derek Kozel]

Hello Reggie,

I believe the issue you are encountering is that the streaming starts
before the next PPS edge arrives and resets the USRP time to 0. Try adding
a sleep for one second between the set_time_next_pps and the
set_start_time. Some RFNoC features are not fully exposed in GNU Radio, but
most are and others are being added over time and as a need is expressed.

Regards,
Derek

On Tue, Nov 14, 2017 at 2:00 PM, Reggie Wilcox 
wrote:

> Hello,
>
> I'm trying to use the set_start_time() command on a RFNoC: Radio block
> with a USRP X300. I am using the syntax to try to set the start time:
> self.uhd_rfnoc_streamer_radio_0.set_time_next_pps(uhd.time_spec(0));
> self.uhd_rfnoc_streamer_radio_0.set_start_time(uhd.time_spec(15));
>
> However, the radio begins transmitting immediately after running the
> script instead of waiting for 15 seconds. Additionally, I know that there
> is no start time set in any of the packets sent to the radio, confirmed
> using a packet sniffer (wireshark).
>
> I am trying to understand where the error in this setup is. Am I not using
> the correct syntax to set the start time, or are there some features that
> are not yet fully supported with RFNoC in GNU Radio? For reference, I am
> using version 3.7.12, which was installed with the rfnoc recipe in pybombs.
>
> Thanks,
>
> ~Reggie
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio 3.7.12 RFNoC set_start_time()

[Reggie Wilcox]

Hello,

I'm trying to use the set_start_time() command on a RFNoC: Radio block with
a USRP X300. I am using the syntax to try to set the start time:
self.uhd_rfnoc_streamer_radio_0.set_time_next_pps(uhd.time_spec(0));
self.uhd_rfnoc_streamer_radio_0.set_start_time(uhd.time_spec(15));

However, the radio begins transmitting immediately after running the script
instead of waiting for 15 seconds. Additionally, I know that there is no
start time set in any of the packets sent to the radio, confirmed using a
packet sniffer (wireshark).

I am trying to understand where the error in this setup is. Am I not using
the correct syntax to set the start time, or are there some features that
are not yet fully supported with RFNoC in GNU Radio? For reference, I am
using version 3.7.12, which was installed with the rfnoc recipe in pybombs.

Thanks,

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

Re: [Discuss-gnuradio] GNU Radio OOT Modules with Same Name - What To Do?

[Martin Braun]

The way OOTs are set up, having two OOTs with the same name will only
work with hacky solutions.

-- M

On 11/03/2017 01:50 PM, Kyeong Su Shin wrote:
> Hello Nicolas,
> 
> It is a GNU Radio module that I saw from GRCon17:
> https://github.com/samwhiting/gnuradio-doa/tree/master/gr-doa
> 
> Regards,
> Kyeong Su Shin
> 
> On Fri, Nov 3, 2017 at 1:21 PM, Nicolas Cuervo  > wrote:
> 
> Hi Kyeong,
> 
> I see only one gr-doa around [1]. Could you point out which other
> implementation is called gr-doa? I would agree that these conflicts
> would be better addressed properly instead of hacky approaches. 
> 
>  Regards,
> - Nicolas
> 
> [1]https://github.com/EttusResearch/gr-doa
> 
> 
> On Fri, Nov 3, 2017 at 8:30 PM, Kyeong Su Shin  > wrote:
> 
> Hello All:
> 
> I am trying to use some GNU Radio OOT modules, and found that
> there are GNU Radio OOT modules have name conflicts ('gr-doa'). 
> 
> In this case, what would be the proper way to resolve the
> conflict and install both modules? I can only think of hacky
> approaches.
> 
> Regards,
> Kyeong Su Shin
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] GNU Radio OOT Modules with Same Name - What To Do?

[Kyeong Su Shin]

Hello Nicolas,

It is a GNU Radio module that I saw from GRCon17:
https://github.com/samwhiting/gnuradio-doa/tree/master/gr-doa

Regards,
Kyeong Su Shin

On Fri, Nov 3, 2017 at 1:21 PM, Nicolas Cuervo 
wrote:

> Hi Kyeong,
>
> I see only one gr-doa around [1]. Could you point out which other
> implementation is called gr-doa? I would agree that these conflicts would
> be better addressed properly instead of hacky approaches.
>
>  Regards,
> - Nicolas
>
> [1]https://github.com/EttusResearch/gr-doa
>
> On Fri, Nov 3, 2017 at 8:30 PM, Kyeong Su Shin  wrote:
>
>> Hello All:
>>
>> I am trying to use some GNU Radio OOT modules, and found that there are
>> GNU Radio OOT modules have name conflicts ('gr-doa').
>>
>> In this case, what would be the proper way to resolve the conflict and
>> install both modules? I can only think of hacky approaches.
>>
>> Regards,
>> Kyeong Su Shin
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio OOT Modules with Same Name - What To Do?

[Nicolas Cuervo]

Hi Kyeong,

I see only one gr-doa around [1]. Could you point out which other
implementation is called gr-doa? I would agree that these conflicts would
be better addressed properly instead of hacky approaches.

 Regards,
- Nicolas

[1]https://github.com/EttusResearch/gr-doa

On Fri, Nov 3, 2017 at 8:30 PM, Kyeong Su Shin  wrote:

> Hello All:
>
> I am trying to use some GNU Radio OOT modules, and found that there are
> GNU Radio OOT modules have name conflicts ('gr-doa').
>
> In this case, what would be the proper way to resolve the conflict and
> install both modules? I can only think of hacky approaches.
>
> Regards,
> Kyeong Su Shin
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio OOT Modules with Same Name - What To Do?

[Kyeong Su Shin]

Hello All:

I am trying to use some GNU Radio OOT modules, and found that there are GNU
Radio OOT modules have name conflicts ('gr-doa').

In this case, what would be the proper way to resolve the conflict and
install both modules? I can only think of hacky approaches.

Regards,
Kyeong Su Shin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU radio implementation for measuring frequency response

[Marcus Müller]

Hi Suman,

be careful with "use instantly": Well, what you're doing is channel
sounding, and as such, the results are up to your interpretation – for
example, in the 100 MHz (!) wide channel you're testing, what coherency
times do you expect from your environment? That is the time a single
channel impulse response is valid. Basically, how fast do the paths the
signal can take change, e.g. by movement of reflecting objects, or
absorbing (human, for example) bodies, or the transmitter or receiver?
With a 100 MHz overall observation bandwidth, you'd get a spatial
resolution of ~1.5m; so, if this is, for example, a room where people
move, this is the time where noone moves out of their position by any
significant amount of distance; that might be in the order of seconds.
If this is a channel between to moving cars, more like milliseconds.

Another aspect: I assume you're doing this with COTS SDR devices. These
typically are *not* calibrated devices, so you'll have to figure out a
way to remove the effect that your devices (from the DAC over the
filters, mixers, amplifiers, cables, antennas, to the ADC and DSP) from
your measurement.

So, if you get data, don't forget that it's not a sufficient description
of the world, unless you understand the model of the world you're using.

That being said: Haven't tried it in ages, but gr-channelsounder[1]
sounds a bit like what you're looking for.

Best regards,
Marcus

[1] https://github.com/gbaier/gr_channelsounder
On 20.10.2017 23:48, Suman Bhunia wrote:
> Hi !
>
> I want to measure frequency response of of a material in the 2.4 GHz
> ISM band. I was wondering if there is any GNURadio based
> implementation anyone is aware of that I can use instantly. Any
> suggestion regarding the implementation is also welcome. 
>
>
> I want to measure the frequency response from 2.4 GHz to 2.5 GHz. I
> want to use 2 USRP boards one as Tx and another as Rx. Alternatively,
> I can use the same board and use the two different ports if it makes
> more sense. 
>
> Thanks for your help in advance.
>
> Suman
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU radio implementation for measuring frequency response

[Dan CaJacob]

If you just want to sweep a filter, that's pretty easy. Just TX into one
port and RX from the other. Sweep a sine wave on the TX range and attach an
FFT sink to the RX port and set max hold.

On Fri, Oct 20, 2017 at 5:50 PM Suman Bhunia  wrote:

> Hi !
>
> I want to measure frequency response of of a material in the 2.4 GHz ISM
> band. I was wondering if there is any GNURadio based implementation anyone
> is aware of that I can use instantly. Any suggestion regarding the
> implementation is also welcome.
>
>
> I want to measure the frequency response from 2.4 GHz to 2.5 GHz. I want
> to use 2 USRP boards one as Tx and another as Rx. Alternatively, I can use
> the same board and use the two different ports if it makes more sense.
>
> Thanks for your help in advance.
>
> Suman
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

[Discuss-gnuradio] GNU radio implementation for measuring frequency response

[Suman Bhunia]

Hi !



I want to measure frequency response of of a material in the 2.4 GHz ISM band. 
I was wondering if there is any GNURadio based implementation anyone is aware 
of that I can use instantly. Any suggestion regarding the implementation is 
also welcome. 





I want to measure the frequency response from 2.4 GHz to 2.5 GHz. I want to use 
2 USRP boards one as Tx and another as Rx. Alternatively, I can use the same 
board and use the two different ports if it makes more sense. 



Thanks for your help in advance.



Suman



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

[Discuss-gnuradio] GNU Radio Project Call Today! (in 30 mins)

[Martin Braun]

Hi all,

this is a very late reminder, but we have a project call at 10 AM
Pacific time, 1 PM Eastern, 19:00 CET.

Go to #gnuradio for info!

Cheers,
Martin

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

Re: [Discuss-gnuradio] Gnu radio and IDEs

[Michael Piscopo]

Yes, you can use the Eclipse debugger if you incorporate some test apps
into your project (you can always pull them out to release/publish).

The way I got it all pulled together is that I add new test executables
(just C++ mains) to the project and manually added them to the cmake files
in the /lib directory.  Then I set the debugger to run whichever
test executable I wanted.  Inside there I could instantiate my new classes
and call whatever functions I want (such as work() or a modified work()
just for testing purposes).  For test data I would either use a real signal
saved with a file sink in GNURadio and just read it in, or create a
function in my test program to generate it.  Then I could step through my
modules with the debugger.  I'm personally a big fan of debuggers.  Trying
to debug with print statements to me is too painful/slow from a development
process perspective.


On Sat, Oct 14, 2017 at 8:32 AM, Walter Grossman 
wrote:

> Were you able to use the debugger?  If so, how?
>
> On Fri, Oct 13, 2017 at 5:14 PM, Michael Piscopo 
> wrote:
>
>> I've had great success with Eclipse.  I use it for all my OOT modules.
>>
>> On Fri, Oct 13, 2017 at 5:03 PM, Walter Grossman 
>> wrote:
>>
>>> Does anyone have experience e using an idea integrated with gnu radio
>>> for making c, c++ modules? Any recommendations? Eclipse? NetBeans? Don't do
>>> it?
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnu radio and IDEs

[U L]

I would recommend any IDE supported by cmake, as it is nice to have cmake
build the appropriate project files for the IDE.  I've personally used
codeblocks which I find acceptable.  I guess if the IDE has a sufficient
project import feature this might not be as important. On my system

$ cmake --help
...
Generators

The following generators are available on this platform:
  Unix Makefiles   = Generates standard UNIX makefiles.
  Ninja= Generates build.ninja files.
  Watcom WMake = Generates Watcom WMake makefiles.
  CodeBlocks - Ninja   = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja = Generates CodeLite project files.
  CodeLite - Unix Makefiles= Generates CodeLite project files.
  Sublime Text 2 - Ninja   = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
   = Generates Sublime Text 2 project files.
  Kate - Ninja = Generates Kate project files.
  Kate - Unix Makefiles= Generates Kate project files.
  Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  KDevelop3= Generates KDevelop 3 project files.
  KDevelop3 - Unix Makefiles   = Generates KDevelop 3 project files.



On Fri, Oct 13, 2017 at 4:55 PM, Martin Braun 
wrote:

> On 10/13/2017 02:27 PM, Andrej Rode wrote:
> > Hi,
> >
> >>> Does anyone have experience e using an idea integrated with gnu radio
> for
> >>> making c, c++ modules? Any recommendations? Eclipse? NetBeans? Don't
> do it?
> >
> > you can basically use any IDE which support C/C++ if you are into
> > hacking blocks together in C/C++. If you are using existing
> > blocks/create Python blocks you could get along with an IDE only
> > supporting Python.
> >
> > You can even work on GNU Radio just using an Editor. It really depends
> > on your personal preference.
>
> We've had some vague ideas about integrating gr_modtool into some IDE,
> but not much has come of it. That said, gr_modtool is pretty easy to use
> from the command line alongside the IDE of your choice.
>
> -- M
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnu radio and IDEs

[Martin Braun]

On 10/13/2017 02:27 PM, Andrej Rode wrote:
> Hi, 
> 
>>> Does anyone have experience e using an idea integrated with gnu radio for
>>> making c, c++ modules? Any recommendations? Eclipse? NetBeans? Don't do it?
> 
> you can basically use any IDE which support C/C++ if you are into
> hacking blocks together in C/C++. If you are using existing
> blocks/create Python blocks you could get along with an IDE only
> supporting Python. 
> 
> You can even work on GNU Radio just using an Editor. It really depends
> on your personal preference.

We've had some vague ideas about integrating gr_modtool into some IDE,
but not much has come of it. That said, gr_modtool is pretty easy to use
from the command line alongside the IDE of your choice.

-- M



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] Gnu radio and IDEs

[Andrej Rode]

Hi, 

> > Does anyone have experience e using an idea integrated with gnu radio for
> > making c, c++ modules? Any recommendations? Eclipse? NetBeans? Don't do it?

you can basically use any IDE which support C/C++ if you are into
hacking blocks together in C/C++. If you are using existing
blocks/create Python blocks you could get along with an IDE only
supporting Python. 

You can even work on GNU Radio just using an Editor. It really depends
on your personal preference.

Cheers
Andrej

 
-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

Re: [Discuss-gnuradio] Gnu radio and IDEs

[Michael Piscopo]

I've had great success with Eclipse.  I use it for all my OOT modules.

On Fri, Oct 13, 2017 at 5:03 PM, Walter Grossman 
wrote:

> Does anyone have experience e using an idea integrated with gnu radio for
> making c, c++ modules? Any recommendations? Eclipse? NetBeans? Don't do it?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Gnu radio and IDEs

[Walter Grossman]

Does anyone have experience e using an idea integrated with gnu radio for
making c, c++ modules? Any recommendations? Eclipse? NetBeans? Don't do it?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Wiki - Spam Prevention - Disabling GitHub OAuth

[Andrej Rode]

Hi all, 

in recent weeks we had an increased amount of spam edits originating
from spam bots using GitHub accounts to bypass the captcha at account
creation. 

Unfortunately the GitHub OAuth extension we are using is not yet
integrated to the new Medaiwiki AuthManager framework and hacking in a
captcha won't be that easy. The short term fix is disabling GitHub OAuth
until I (or someone else) updated the GitHub OAuth extension to play
nice with the AuthManager framework.

If you used GitHub OAuth to log in to the wiki and you are locked out
now: Please contact me via Mail  or IRC/Slack `noc0lour` and
I'll reset your password so you can login using password based auth.
Until we figured out all already registered bot users I limited editing
to `realuser` which is a manual approved group based on recent edits. If
you would like to edit something in the next couple of days and you are
not yet in the `realuser` group please contact me or any other wiki 
administrator [0].

Cheers,
Andrej

[0] 
https://wiki.gnuradio.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50

-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

Re: [Discuss-gnuradio] GNU Radio Project Call Moved from 17th to 24th

[Andrew Rich]

Roger that

Sent from my iPhone

> On 18 Aug 2017, at 1:21 am, Martin Braun  wrote:
> 
> Our monthly project syncup. See also:
> 
> https://wiki.gnuradio.org/index.php/DevelopersCalls
> 
> 
> 
>> On 08/17/2017 10:17 AM, Andrew Rich wrote:
>> What's a project call ? 
>> 
>> Sent from my iPhone
>> 
>>> On 18 Aug 2017, at 1:13 am, Martin Braun  wrote:
>>> 
>>> Hi all,
>>> 
>>> just a quick reminder that the call is not today, but next week.
>>> 
>>> Cheers,
>>> Martin
>>> 
 On 08/14/2017 05:53 PM, Martin Braun wrote:
 Hi all,
 
 this month's project call will be postponed by a week. It'll happen on
 August 24th, same time as before (10 AM Pacific).
 
 Cheers,
 Martin
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
>>> 
>>> 
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] GNU Radio Project Call Moved from 17th to 24th

[Martin Braun]

Our monthly project syncup. See also:

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



On 08/17/2017 10:17 AM, Andrew Rich wrote:
> What's a project call ? 
> 
> Sent from my iPhone
> 
>> On 18 Aug 2017, at 1:13 am, Martin Braun  wrote:
>>
>> Hi all,
>>
>> just a quick reminder that the call is not today, but next week.
>>
>> Cheers,
>> Martin
>>
>>> On 08/14/2017 05:53 PM, Martin Braun wrote:
>>> Hi all,
>>>
>>> this month's project call will be postponed by a week. It'll happen on
>>> August 24th, same time as before (10 AM Pacific).
>>>
>>> Cheers,
>>> Martin
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] GNU Radio Project Call Moved from 17th to 24th

[Andrew Rich]

What's a project call ? 

Sent from my iPhone

> On 18 Aug 2017, at 1:13 am, Martin Braun  wrote:
> 
> Hi all,
> 
> just a quick reminder that the call is not today, but next week.
> 
> Cheers,
> Martin
> 
>> On 08/14/2017 05:53 PM, Martin Braun wrote:
>> Hi all,
>> 
>> this month's project call will be postponed by a week. It'll happen on
>> August 24th, same time as before (10 AM Pacific).
>> 
>> Cheers,
>> Martin
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] GNU Radio Project Call Moved from 17th to 24th

[Martin Braun]

Hi all,

just a quick reminder that the call is not today, but next week.

Cheers,
Martin

On 08/14/2017 05:53 PM, Martin Braun wrote:
> Hi all,
> 
> this month's project call will be postponed by a week. It'll happen on
> August 24th, same time as before (10 AM Pacific).
> 
> Cheers,
> Martin
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] GNU Radio .grc repository

[Andrew Rich]

Thats awesome lots of examples 

Sent from my iPhone

> On 16 Aug 2017, at 9:13 pm, Marcus Müller  wrote:
> 
> Hi Andrew,
> 
> the latter. Makes more sense – if the project is a dependency of a flow
> graph, or the flowgraph is the reason the module exists in the first
> place, makes no sense to have it centralized elsewhere; if the flowgraph
> is sufficiently complex, it very often happens that you'd end up wanting
> a whole OOT module around it, anyway.
> 
> So, the central repository indeed /is/ cgran.org.
> 
> Best regards,
> 
> Marcus
> 
> 
>> On 08/16/2017 01:06 PM, vk4...@tech-software.net wrote:
>> Hello
>> 
>> Is there a global repository of .grc files ?
>> 
>> Or do we just rely on examples that come with each project ?
>> 
>> Andrew 
>> 
>> 
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] GNU Radio .grc repository

[Marcus Müller]

Hi Andrew,

the latter. Makes more sense – if the project is a dependency of a flow
graph, or the flowgraph is the reason the module exists in the first
place, makes no sense to have it centralized elsewhere; if the flowgraph
is sufficiently complex, it very often happens that you'd end up wanting
a whole OOT module around it, anyway.

So, the central repository indeed /is/ cgran.org.

Best regards,

Marcus


On 08/16/2017 01:06 PM, vk4...@tech-software.net wrote:
> Hello
>
> Is there a global repository of .grc files ?
>
> Or do we just rely on examples that come with each project ?
>
> Andrew 
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] GNU Radio .grc repository

[vk4tec]

Hello

Is there a global repository of .grc files ?

Or do we just rely on examples that come with each project ?

Andrew 




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

[Discuss-gnuradio] GNU Radio Project Call Moved from 17th to 24th

[Martin Braun]

Hi all,

this month's project call will be postponed by a week. It'll happen on
August 24th, same time as before (10 AM Pacific).

Cheers,
Martin

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

Re: [Discuss-gnuradio] GNU Radio debug with GDB

[Rafik ZITOUNI]

Thanks you Marcus and Cinaed for your answer,

I removed libc6-dbg from my ubuntu 14.04 and it is working now. I just give
the cc source code and after that added my breakpoints and debug works
fine.

For thread info, Yes I doing it on ddd, with a graphical tool seeing the
threads' numbers.

Best regards,

Rafik,





2017-07-18 1:10 GMT+02:00 Marcus Müller :

> ... and that's not a problem per se. Anyway, this is a syscall, and it's
> unlikely that there's a problem *within* your operating system.
>
> So, the rest of the backtrace where this is from is very likely more
> relevant.
>
> Also, poll() might indicate this is a more or less idle thread; use
> `info threads` to see the other threads of your process; use `thread
> NUMBER` to switch between them.
>
> Best regards,
>
> Marcus
>
>
> On 17.07.2017 22:49, Cinaed Simson wrote:
> > On 07/17/2017 09:28 AM, Rafik ZITOUNI wrote:
> >> Dear all,
> >>
> >> I have an issue that appears when I'm running gdb.
> >>
> >> I obtained the following message.
> >>
> >> 0x7fcb038c6c5d in poll () at ../sysdeps/unix/syscall-template.S:81
> >> 81  ../sysdeps/unix/syscall-template.S: No such file or directory.
> >>
> >>
> >> Could you have any idea how to fix this issue?
> > Typically it means you don't have source code to a library.
> >
> > -- Cinaed
> >
> >
> >> Best,
> >> --
> >> **Rafik
> >>
> >>
> >>
> >> ___
> >> 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
>



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

Re: [Discuss-gnuradio] GNU Radio debug with GDB

[Marcus Müller]

... and that's not a problem per se. Anyway, this is a syscall, and it's
unlikely that there's a problem *within* your operating system.

So, the rest of the backtrace where this is from is very likely more
relevant.

Also, poll() might indicate this is a more or less idle thread; use
`info threads` to see the other threads of your process; use `thread
NUMBER` to switch between them.

Best regards,

Marcus


On 17.07.2017 22:49, Cinaed Simson wrote:
> On 07/17/2017 09:28 AM, Rafik ZITOUNI wrote:
>> Dear all, 
>>
>> I have an issue that appears when I'm running gdb. 
>>
>> I obtained the following message. 
>>
>> 0x7fcb038c6c5d in poll () at ../sysdeps/unix/syscall-template.S:81
>> 81  ../sysdeps/unix/syscall-template.S: No such file or directory.
>>
>>
>> Could you have any idea how to fix this issue?
> Typically it means you don't have source code to a library.
>
> -- Cinaed
>
>
>> Best, 
>> -- 
>> **Rafik
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] GNU Radio debug with GDB

[Cinaed Simson]

On 07/17/2017 09:28 AM, Rafik ZITOUNI wrote:
> Dear all, 
> 
> I have an issue that appears when I'm running gdb. 
> 
> I obtained the following message. 
> 
> 0x7fcb038c6c5d in poll () at ../sysdeps/unix/syscall-template.S:81
> 81  ../sysdeps/unix/syscall-template.S: No such file or directory.
> 
> 
> Could you have any idea how to fix this issue?

Typically it means you don't have source code to a library.

-- Cinaed


> 
> Best, 
> -- 
> **Rafik
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

[Discuss-gnuradio] GNU Radio debug with GDB

[Rafik ZITOUNI]

Dear all,

I have an issue that appears when I'm running gdb.

I obtained the following message.

0x7fcb038c6c5d in poll () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.


Could you have any idea how to fix this issue?

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

[Discuss-gnuradio] GNU Radio Coverity statis analysis

[Philip Balister]

As part of some GNU Radio infrastructure work, the Coverity static
analyses is running again. Thanks guys!

https://scan.coverity.com/projects/gnuradio

This is a great way to find places the code needs some work and a good
way to start contributing to the project. Go ahead and take a look!

Philip

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

Re: [Discuss-gnuradio] GNU Radio Companion Extensions: Output C++ Code

[Marcus Müller]

Dear Sandeep,

hi, and welcome! We've already got a contribution for that project
aspect. Which certainly doesn't mean we don't want your help! So, if you
want to contribute to GNU Radio, I think a great way to contribute is
actually to improve some documentation. So, judging from your email, I'd
say you'd be exactly the entry-level user that I'd ask to give feedback
about the Guided Tutorials on http://tutorials.gnuradio.org by writing a
critical mail to tutori...@gnuradio.org .

Best regards,

Marcus


On 05/06/2017 09:32 PM, sandeep chauhan wrote:
> Hi 
> Myself Sandeep and I want to contribute to the GNURadio.
> my project is  "GNU Radio Companion Extensions: Output C++ Code"
> I have good coding  skills in C,C++,and python.
> I also familiar or have understanding about the grc's blocks (signal
> source,audio source, WX GUIs and QT GUIs audiosink,and etc..) and also
> about the types  (complex and float).
> So, suggest me the right way to do this project
> Now I want the origin for this project  
>  
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Discuss-gnuradio] GNU Radio Companion Extensions: Output C++ Code

[sandeep chauhan]

Hi
Myself Sandeep and I want to contribute to the GNURadio.
my project is  "GNU Radio Companion Extensions: Output C++ Code"
I have good coding  skills in C,C++,and python.
I also familiar or have understanding about the grc's blocks (signal
source,audio source, WX GUIs and QT GUIs audiosink,and etc..) and also
about the types  (complex and float).
So, suggest me the right way to do this project
Now I want the origin for this project
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio/No Devices Found (NI USRP-2920)

[Marcus Müller]

Hi,

as Derek said, can you please take this to the USRP-users mailing list?
GNU Radio and UHD are different things...

Best regards and thank you

Marcus


On 04.04.2017 23:50, bup487 wrote:
> Okay, here is the console for the error. Let me know if this is what you guys
> wanted to see...
>  
>
> I ran the "uhd_image_downloadeder" and it gave me tons of different images.
> I'm assuming I'd want to install the N21x_fw and N21x_fpga files. Are there
> better ones suited for the USRP-2920?
>  
>
> And finally, I couldn't find the program that allows me to see the images
> already installed, but due to the last update of the firmware being
> yesterday, I'm fairly confident these images are the ones installed
> currently.
>  
>
> I'm concerned that the image status is reading a null value currently.
> However, it still reads in MATLAB just fine.
>
>
> Which images should I install from that repository seen in the second
> picture?
>
> Thanks!
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/GNU-Radio-No-Devices-Found-NI-USRP-2920-tp63451p63454.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] GNU Radio/No Devices Found (NI USRP-2920)

[bup487]

Okay, here is the console for the error. Let me know if this is what you guys
wanted to see...
 

I ran the "uhd_image_downloadeder" and it gave me tons of different images.
I'm assuming I'd want to install the N21x_fw and N21x_fpga files. Are there
better ones suited for the USRP-2920?
 

And finally, I couldn't find the program that allows me to see the images
already installed, but due to the last update of the firmware being
yesterday, I'm fairly confident these images are the ones installed
currently.
 

I'm concerned that the image status is reading a null value currently.
However, it still reads in MATLAB just fine.


Which images should I install from that repository seen in the second
picture?

Thanks!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GNU-Radio-No-Devices-Found-NI-USRP-2920-tp63451p63454.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

Re: [Discuss-gnuradio] GNU Radio/No Devices Found (NI USRP-2920)

[Marcus D. Leech]

On 04/04/2017 02:49 PM, bup487 wrote:

Two programs, MATLAB and GNU Radio, are giving me different results when
searching for the USRP on my network.
My setup is Laptop -> Wired Ethernet -> Switch -> NI USRP-2920.

MATLAB can detect the USRP device, while GNU Radio throws an error whenever
it tries to identify the USRP device at 192.168.10.3.



My computer is configured with the static IP address 192.168.10.1. I'm
using Windows 10 for this setup. I recently downloaded the automated
NI-USRP driver software. Apparently, this software updates the USRP image to
the latest firmware. Installing new firmware onto the USRP had no effect on
the error message.

How do I get GNU radio to detect my USRP device?

If there is any help, I'd be very grateful.

Thanks!





Could you perhaps give us the exact text of the error message?

MATLAB-packaged UHD and GnuRadio-compatible UHD may well have different 
firmware requirements.


Also, the firmware doesn't "take effect" until you power-cycle the device.

Also, you should run "uhd_images_downloader" from the 
Gnuradio-compatible UHD that you may have, which will identify the 
version of the UHD
  library you're running, and download the appropriate firmware into 
your PC.  Once that happens THEN you need to program the FPGA of the USRP

  device with this firmware, and power-cycle.

But again, my understanding is that MATLAB packages their own UHD 
version, so if you want to use both MATLAB and Gnu Radio, you'll be in

  a switching-back-and-forth mode with the firmware.



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

Re: [Discuss-gnuradio] GNU Radio/No Devices Found (NI USRP-2920)

[Derek Kozel]

Hello,

I recommend joining the USRP users mailing list and asking your question
there. MATLAB and the Windows GNU Radio install both include their own UHD
drivers so this is likely a conflict between those two and the FPGA version
you have just loaded using the NI-USRP utility. These are three separate
environments, each with their own requirements about the UHD and FPGA
images. We would need to see more of the output for each tool. Can you
please copy and paste the full output from running uhd_find_devices which
is included in the GNU Radio install?

http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Regards,
Derek


On Tue, Apr 4, 2017 at 11:49 AM, bup487  wrote:

> Two programs, MATLAB and GNU Radio, are giving me different results when
> searching for the USRP on my network.
> My setup is Laptop -> Wired Ethernet -> Switch -> NI USRP-2920.
>
> MATLAB can detect the USRP device, while GNU Radio throws an error whenever
> it tries to identify the USRP device at 192.168.10.3.
> 
> 
>
> My computer is configured with the static IP address 192.168.10.1. I'm
> using Windows 10 for this setup. I recently downloaded the automated
> NI-USRP driver software. Apparently, this software updates the USRP image
> to
> the latest firmware. Installing new firmware onto the USRP had no effect on
> the error message.
>
> How do I get GNU radio to detect my USRP device?
>
> If there is any help, I'd be very grateful.
>
> Thanks!
> 
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.
> com/GNU-Radio-No-Devices-Found-NI-USRP-2920-tp63451.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] GNU Radio/No Devices Found (NI USRP-2920)

[bup487]

Two programs, MATLAB and GNU Radio, are giving me different results when
searching for the USRP on my network.
My setup is Laptop -> Wired Ethernet -> Switch -> NI USRP-2920. 

MATLAB can detect the USRP device, while GNU Radio throws an error whenever
it tries to identify the USRP device at 192.168.10.3.
 
 

My computer is configured with the static IP address 192.168.10.1. I'm 
using Windows 10 for this setup. I recently downloaded the automated 
NI-USRP driver software. Apparently, this software updates the USRP image to
the latest firmware. Installing new firmware onto the USRP had no effect on
the error message.

How do I get GNU radio to detect my USRP device?

If there is any help, I'd be very grateful.

Thanks!
 




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GNU-Radio-No-Devices-Found-NI-USRP-2920-tp63451.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] 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