Re: EXTERNAL: Re: GNU Radio on Mac M1

[Michael Dickens]

I don't know if we'll have GNU Radio 3.10 as the default in MacPorts by
GRCon22. Lots of work to do there, mostly getting GR OOT modules updated to
compatible versions or removed if there isn't such a version. We'll see how
much progress we can make ... 6.5 weeks away, so not impossible ... - MLD

On Fri, Aug 12, 2022 at 10:26 AM Royce Connerley 
wrote:

> Michael:
>
> I would second the vote for 3.10.  Do you think this will be ready by GR
> Con22?
>
> Royce
>
> On May 25, 2022, at 10:52 AM, Price, Rodney D. 
> wrote:
>
> About the version of gnuradio: speaking only for myself, I would prefer to
> see the 3.10 version packaged. I don’t use many OOT blocks. Others may have
> a different opinion. I’m not that set on 3.10, however. Packaging 3.9 would
> be fine by me if others prefer it.
>
> Thanks for doing this,
> -Rod
>
> *From:* Michael Dickens [mailto:michael.dick...@ettus.com
> ]
> *Sent:* Tuesday, May 24, 2022 1:55 PM
> *To:* Ryan Volz
> *Cc:* Price, Rodney D.; discuss-gnuradio@gnu.org
> *Subject:* EXTERNAL: Re: GNU Radio on Mac M1
>
> Related to this general topic -- GR on ARM64:
>
> The MacPorts maintainers of GR are soon going to update the main
> "gnuradio" port ... we're proposing to the current 3.10 release. It is a
> pain to maintain more than 1 related port, and we were waiting for many GR
> OOT modules to be updated before we did this main update. Would folks
> prefer GR 3.9 instead of GR 3.10? I think most GR OOT are ported to GR 3.9
> by now ... more than for 3.10, but I'm sure not all have been ported yet.
> I'm curious folks thoughts here.
>
> Also: Can someone provide more details of the CMake install issue? I
> thought all of the required files were installed into the correct directory
> for CMake to find them.
> ---
> Dr Michael L Dickens
> Principal NI/Ettus Technical Support Engineer
>
>
> On Tue, May 24, 2022 at 3:23 PM Ryan Volz  wrote:
>
> Hi Rod,
>
> I have a positive report from a colleague who is running radioconda on
> an M1 through rosetta with the non-arm64 build. He also reports
> instability with GRC when trying to run the native arm64 packages, so I
> think your best shot might be trying the former with rosetta. (Another
> thing to consider is that gr-qtgui does not exist yet for arm64, since
> conda-forge is still struggling to get the Qt ecosystem built. It has
> been seemingly imminent for 6 months now, so I've stopped holding my
> breath.) Miniconda vs. radioconda should not matter, except for
> convenience in reinstalling if you want to wipe away your whole conda
> installation. I'm not sure in what ways the various packaging methods
> would interfere with each other's Python installations, but removing
> anything you don't need and keeping things minimal is always a good plan.
>
> Cheers,
> Ryan
>
> On 5/24/22 12:19 PM, Price, Rodney D. wrote:
> > Ryan,
> >
> > Thanks for your reply. I looked through the Mac OS X bug reports and
> didn't see anything that looked relevant to my case. The problem isn't
> necessarily connected to GRC. The Macports install seems to be missing some
> essential cmake files (i.e. GrSwig and dependencies). The conda install
> would be preferable, anyway. I'm beginning to wonder about m=y miniconda
> install: I have found multiple Python installs around my system, and after
> removing all my homebrew packages and replacing some with macports
> versions, I wonder if the Python libraries that GNU Radio uses might not be
> the ones that GNU Radio expects. I'm considering removing miniconda and
> replacing it with radioconda. What do you think? Is that likely to work on
> a Mac?
> >
> > Thanks,
> > -Rod
> >
> > -Original Message-
> > From: Ryan Volz [mailto:ryan.v...@gmail.com]
> > Sent: Monday, May 23, 2022 11:21 AM
> > To: Price, Rodney D.; discuss-gnuradio@gnu.org
> > Subject: EXTERNAL: Re: GNU Radio on Mac M1
> >
> > Hi Rod,
> >
> > I think your experience is common, unfortunately, and part of the
> > problem is that there are multiple bugs to work through and not all of
> > them are necessarily with GRC itself. There are multiple dimensions in
> > which things are failing (new vs. old macOS version, switch to arm64,
> > standard DPI display vs. high DPI [Retina] display), so providing as
> > many details about your system as you can would be helpful. As the
> > person putting out the conda packages, it saddens me that I haven't been
> > able to sort through enough of the bugs to get something working for
> people.
> >
> > So, what particular issues are you seeing with the conda install? There
> > are a few bugs tagged for "Mac OS X&quo

Re: How to isolate an ofdm carrier?

[Michael Dickens]

You might consider a polyphase channelizer to pick specific OFDM carriers
out of the aggregate signal. They are very efficient in terms of CPU usage,
and so can even work at reasonably high input sample rates on decent CPUs
(with moderate GHz speed & number of cores). - MLD


On Mon, Jun 6, 2022 at 7:14 PM Juan Antonio  wrote:

> Hello, for you I'm sure it's simple, but I'm having a hard time isolating
> a carrier of an ofdm (1k) signal (474 Mhz for example) to see it in the
> time domain.
>
> Would someone be so kind as to tell me a method of making a bandpass
> filter that would do the job?
>
> Thank you
>

Re: GNU Radio on Mac M1

[Michael Dickens]

Related to this general topic -- GR on ARM64:

The MacPorts maintainers of GR are soon going to update the main "gnuradio"
port ... we're proposing to the current 3.10 release. It is a pain to
maintain more than 1 related port, and we were waiting for many GR OOT
modules to be updated before we did this main update. Would folks prefer GR
3.9 instead of GR 3.10? I think most GR OOT are ported to GR 3.9 by now ...
more than for 3.10, but I'm sure not all have been ported yet. I'm curious
folks thoughts here.

Also: Can someone provide more details of the CMake install issue? I
thought all of the required files were installed into the correct directory
for CMake to find them.
---
Dr Michael L Dickens
Principal NI/Ettus Technical Support Engineer


On Tue, May 24, 2022 at 3:23 PM Ryan Volz  wrote:

> Hi Rod,
>
> I have a positive report from a colleague who is running radioconda on
> an M1 through rosetta with the non-arm64 build. He also reports
> instability with GRC when trying to run the native arm64 packages, so I
> think your best shot might be trying the former with rosetta. (Another
> thing to consider is that gr-qtgui does not exist yet for arm64, since
> conda-forge is still struggling to get the Qt ecosystem built. It has
> been seemingly imminent for 6 months now, so I've stopped holding my
> breath.) Miniconda vs. radioconda should not matter, except for
> convenience in reinstalling if you want to wipe away your whole conda
> installation. I'm not sure in what ways the various packaging methods
> would interfere with each other's Python installations, but removing
> anything you don't need and keeping things minimal is always a good plan.
>
> Cheers,
> Ryan
>
> On 5/24/22 12:19 PM, Price, Rodney D. wrote:
> > Ryan,
> >
> > Thanks for your reply. I looked through the Mac OS X bug reports and
> didn't see anything that looked relevant to my case. The problem isn't
> necessarily connected to GRC. The Macports install seems to be missing some
> essential cmake files (i.e. GrSwig and dependencies). The conda install
> would be preferable, anyway. I'm beginning to wonder about m=y miniconda
> install: I have found multiple Python installs around my system, and after
> removing all my homebrew packages and replacing some with macports
> versions, I wonder if the Python libraries that GNU Radio uses might not be
> the ones that GNU Radio expects. I'm considering removing miniconda and
> replacing it with radioconda. What do you think? Is that likely to work on
> a Mac?
> >
> > Thanks,
> > -Rod
> >
> > -Original Message-
> > From: Ryan Volz [mailto:ryan.v...@gmail.com]
> > Sent: Monday, May 23, 2022 11:21 AM
> > To: Price, Rodney D.; discuss-gnuradio@gnu.org
> > Subject: EXTERNAL: Re: GNU Radio on Mac M1
> >
> > Hi Rod,
> >
> > I think your experience is common, unfortunately, and part of the
> > problem is that there are multiple bugs to work through and not all of
> > them are necessarily with GRC itself. There are multiple dimensions in
> > which things are failing (new vs. old macOS version, switch to arm64,
> > standard DPI display vs. high DPI [Retina] display), so providing as
> > many details about your system as you can would be helpful. As the
> > person putting out the conda packages, it saddens me that I haven't been
> > able to sort through enough of the bugs to get something working for
> people.
> >
> > So, what particular issues are you seeing with the conda install? There
> > are a few bugs tagged for "Mac OS X" on the GNU Radio Github: do any of
> > those apply?
> >
> > One thing a recent report has brought to my attention is a possible bug
> > in conda-forge's cairo package. If you're seeing crashes that might have
> > to do with cairo (e.g. GRC crashes), you could try installing a patched
> > cairo package that I have available on my channel:
> >
> > conda install -c ryanvolz/label/bigsur-patch cairo
> >
> > Cheers,
> > Ryan
> >
> > On 5/23/22 12:33 PM, Price, Rodney D. wrote:
> >> I've been trying to get a good install of GNU Radio on a Mac M1 (ARM64)
> >> running Monterey, using several methods. I've tried installing via
> >> Homebrew, which gave me an install that crashed GRC constantly. I've
> >> tried conda install (I have miniconda installed) without success. My
> >> latest attempt is with Macports, which gives me a working GRC, but when
> >> I attempt to run cmake in the OOT module source, cmake can't find
> >> GrSwig, so I go online to find a GrSwig.cmake, which then leads to
> >> another error on LIBTOOL.
> >>
> >> This is not to complain, but I would really like to avoid going down
> >> some rabbit hole on an install that in the end, just won't work.
> >> Macports' gnuradio is version 3.8, and I would like something more up to
> >> date. Playing nicely with conda would be nice as well.
> >>
> >> So I'm asking for advice on the current state of GNU Radio on Macs with
> >> the Apple ARM chip. Have others been able to get a working install of
> >> GNU Radio on this 

Re: [Commit-gnuradio] About Reducing Latency When Implementing CSMA/NDA Protocol on Wireless Systems Using USRP Devices

[Michael Dickens]

Hi Mehmet - As nobody else has responded in any capacity, let me do so from
an Ettus Support perspective.

The reason your query isn't being answered is that it is highly technical,
with lots of details, and a very specific use-case that would require
someone many hours of work to process. Sometimes we get lucky and there are
folks who are already experts in the multiple domains required and who have
thus already put in the hours to understand the intersecting domains well
enough to be able to respond quickly. Sometimes not -- and, this seems to
be one of those cases.

It is not clear to me that this issue is related to UHD / USRP; I'm
guessing it has more to do with the GNU Radio / data processing side of
things.

General advice for minimizing latency in GNU Radio can be found online
include:

* Use C++, not Python, for blocks. Broadly speaking: Python will be slower.
GNU Radio uses Python for graph connectivity & other non-speed-critical
logistics.

* Reduce the maximum number of items to be processed to whatever minimum is
possible. There are options in the block settings to do this, plus or
minus. Broadly speaking: Processing fewer samples per block reduces latency.

* If GNU Radio still supports block profiling then reinstall GR with that
option enabled (and if I recall the required Thrift dependency) and run
your flowgraph to see where the high-CPU use blocks are and then try to
create alternative implementations that reduce CPU usage. Broadly speaking:
Higher CPU usage results in more latency.

I hope this is useful! - MLD
---
Dr Michael L Dickens
Principal NI/Ettus Technical Support Engineer


On Thu, May 5, 2022 at 4:48 PM Mehmet Fatih Ayten 
wrote:

> Hello Dear Forum Members,
>
>
>
> I have already posted at 14th April with the same issue, but since I could
> not receive any reply, I decided to post again, sorry for inconvenience.  I
> am Fatih from Vrije Universiteit Brussels, and writing to ask for any
> suggestion about the Reducing Latency When Implementing CSMA/NDA Protocol
> on Wireless Systems Using USRP Devices.
>
>
>
> Firstly, I would like to briefly mention about CSMA/NDA protocol so, my
> question means more for you.
>
>
>
> CSMA/NDA (Carrier Sense Multiple Access/Non Destructive Arbitration)
> protocol is employed mainly in Control Area Network (CAN) buses. If 2 or
> more transceiver nodes want to broadcast simultaneously, the winner node is
> determined by arbitration fields of transceivers. The winner node continues
> transmitting, while other nodes become silent. Arbitration fields are
> generally composed of 12 bits, and recessive and dominant bits can be
> chosen by the designer. To give an example, lets assume length of
> arbitration field is decided as 4 bits and 2 transceivers want to broadcast
> their message on the bus network. Also, dominant bit is selected as "1":
>
>
>
> Node 1: -start of arbitration field- 1 1 1 1 -end of arbitration field-
> -start of meaningful message- 1 0 0 1 0 0 1 0 1 -end of meaningful message-
>
>
>
> Node 2: -start of arbitration field- 1 0 0 0 -end of arbitration field-
> -start of meaningful message- 0 1 0 1 1 1 0 1 0 -end of meaningful message-
>
>
>
> Since arbitration field of Node 1 includes more 1's, it is more dominant
> than Node 2, therefore as time goes on, Node 2 will become silent and
> message of Node 1 will appear on the bus.
>
>
>
> In my project, I am trying to implement this protocol in a wireless
> fashion. I use two USRP X310
>
> SDRs, one OctoClock CDA-2990 Clock Distribution Device in order to
> maintain synchronization between
>
> SDRs, one Gigabit ethernet switch in order to make connection between PC
> and SDRs. Wireless communication between SDRs has been maintained using
> VERT2450 Vertical Antennas. Also, experiments have been conducted in
> real-time on the host PC using the GNU Radio framework.
>
>
>
> The flowgraph that I use is in this link:
> https://drive.google.com/file/d/1iBkg8wWBPxVkYtm8LsT2qiPHqlvlZ6mj/view?usp=sharing
>
>
>
> As you can see from the flowgraph, two Tx nodes transmit their bits, one
> receiver reveives bits, then according to resulting received bits, command
> is sent to transmitters. In order to create this command, I have created an
> Embedded Python Block and its content is as follows (or you can check
> screenshot from the link:
> https://drive.google.com/file/d/1NCLQIKK_qp1Ltdf3fswCUsjxGKay1HKH/view?usp=sharing
> ):
>
>
>
> import numpy as np
>
> from gnuradio import gr
>
> import pmt
>
>
>
> class blk(gr.basic_block):
>
>
>
> def __init__(self, check=1.0):
>
> gr.sync_block.__init__(
>
> self,
>
> name='Embedded Python Block',
>
> in_sig=[np.int32,np.int32],
>
> out_sig=[np.int32]
>
> )
>
> self.check = check
>
> self.message_port_register_out(pmt.intern('Gain Changer Message
> Port'))
>
> def work(self, input_items,output_items):
>
> if self.check ==1:
>
> if (not 

Re: oot gr-cessb link error

[Michael Dickens]

ed_ptr,
> boost::shared_ptr)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `gr::sync_block::forecast(int,
> std::vector >&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `gr::block::set_processor_affinity(std::vector >
> const&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `gr::block::fixed_rate_ninput_to_noutput(int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `gr::fast_atan2f(float, float)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `gr::block::~block()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `gr::block::general_work(int,
> std::vector >&, std::vector std::allocator >&, std::vector
> >&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `volk_32fc_deinterleave_imag_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `gr::block::set_output_multiple(int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `gr::block::set_alignment(int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `volk_32f_x2_min_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `gr::sync_block::fixed_rate_ninput_to_noutput(int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `volk_32fc_deinterleave_real_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `gnuradio::detail::sptr_magic::fetch_initial_sptr(gr::basic_block*)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `volk_32f_cos_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `gr::block::stop()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `gr::block::log_level[abi:cxx11]()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `typeinfo for gr::basic_block'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `volk_32f_x2_subtract_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to
> `pmt::eqv(boost::shared_ptr const&,
> boost::shared_ptr const&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> libgnuradio-cessb.so: undefined reference to `gr::block::start()'
> collect2: error: ld returned 1 exit status
> make[2]: *** [lib/CMakeFiles/test-cessb.dir/build.make:115:
> lib/test-cessb] Error 1
> make[1]: *** [CMakeFiles/Makefile2:274: lib/CMakeFiles/test-cessb.dir/all]
> Error 2
> make: *** [Makefile:141: all] Error 2
>
> libboost is 1.71.0
> python is 2.7.17
>
> Seems not to find gr and volk libraries?
> Hints welcome!
>
> --
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: [USRP-users] Re: Reference indefined

[Michael Dickens]

Hi Fred - In the top-level BUILD directory there will be a file
"CMakeCache.txt" where you can track down the exact variable names you need
to use for including the GR CMake variables. I think these are consistent
between different GR versions, but I really don't recall any longer & I'm
not famility with GR 3.9's CMake -- just up through GR 3.8. In that file
you can search for "GNURADIO_BLOCKS" and you'll see the "INCLUDE_DIR" or
"INCLUDE_DIRS" and "LIBRARIES" or "LIBRARY" and others. You then use the
correct CMake commands in your OOT to use those variables. If you're using
GR's modtool to create the OOT those commands should be added
automatically. Sorry I can't be more precise ... I don't have the info in
front of me, but I know that the above is what I would do so that's easy to
write :) - MLD


On Tue, May 11, 2021 at 9:35 AM COURANT Frederique - Contractor via
USRP-users  wrote:

> I have tried to add ${GNURADIO_BLOCKS_INCLUDE_DIRS} and
> ${GR_BLOCKS_INCLUDE_DIRS} without any success.
>
> Anyone could give an example of CMakeList that use uhd and gnuradio module
> please ?
>
> Thanks.
>
> Regards.
>
> Fred
>
> -Message d'origine-
> De : Discuss-gnuradio  external.thalesgroup@gnu.org> De la part de COURANT Frederique -
> Contractor
> Envoyé : mardi 11 mai 2021 13:55
> À : Marcus Müller ; discuss-gnuradio@gnu.org
> Objet : RE: Reference indefined
>
> Sorry I would like to say 3.7.11.
>
> If I have understand I need to add ${GNURADIO_BLOCKS_INCLUDE_DIRS} in my
> CMakeFiles that's all ?
>
> Thank you very much for your help.
>
> Regards.
>
> Fred
>
> -Message d'origine-
> De : Discuss-gnuradio  external.thalesgroup@gnu.org> De la part de Marcus Müller Envoyé :
> mardi 11 mai 2021 13:39 À : discuss-gnuradio@gnu.org Objet : Re:
> Reference indefined
>
> Hi Fred,
>
> indeed, your link_directories need to include the BLOCKS library, not just
> RUNTIME, when you're linking against any code in gr::blocks.
>
> I might be a bit behind on current GNU Radio developments, but GNU Radio
> 3.11 isn't even in development yet, far as I can tell. Is it possible
> you're referring to 3.10.0.git?
>
> Best regards,
> Marcus
>
> On 11.05.21 13:30, COURANT Frederique - Contractor wrote:
> > Hello Users,
> >
> >
> >
> > I try to develop my own program in C++ with UHD3.14 and gnuradio 3.11.
> >
> > I have no problem to compile blocks that are including in uhd but when
> > I want to compile with a sig_source or magphase_to_complex blocks
> > that are including in Gnuradio blocks I have the following error :
> >
> > Main.cpp(.text+0x1351) : référence indefinite vers "
> > gr::analog::sig_source_c::make(double, gr::analog::gr_waveform_t, double
> int) "
> >
> > Main.cpp(.text+0x1351) : référence indefinite vers "
> > gr::blocks::magphase_to_complex::make(double, gr::analog::gr_waveform_t,
> double int) "
> >
> >
> >
> > In think I forgot something in my CMakeFiles, I have
> > include_directories(${GNURADIO_ALL_INCLUDE_DIRS}) and
> > link_directories(${GNURADIO_RUNTIME_LIBRARY_DIRS})
> >
> >
> >
> > Someone could help me please or give an example of CMakeFiles that are
> > using UHD and Gnuradio for compile a program.
> >
> >
> >
> > Thanks for your help.
> >
> >
> >
> > Regards.
> >
> >
> >
> > Fred
> >
> >
> >
>
> ___
> USRP-users mailing list -- usrp-us...@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>

Re: [USRP-users] [UHD] 4.0.0.0 Release Announcement

[Michael Dickens]

FYI for macOS users using MacPorts: I updated the "uhd-devel" port to the
current 4.0.0.0 release commit (20200913-90ce6062); the "uhd" port is still
at 3.15.0.0. Both ports should work with the "gnuradio" port for GNU Radio
3.8.2.0, and should install and execute under macOS 10.11 through
10.16-beta / 11.0-beta. Execution on older macOS / OSX can be made to work,
at least back to 10.8 and probably even 10.5. I'm working on updating the
ports to handle those older OS versions correctly, though this is a low
priority so thanks for your patience if you're such a user!

As always, I'd love to hear from macOS users, your successes or failures,
whether using UHD from MacPorts, or source, or any other install means.

Welcome to the future of UHD! - MLD
---
Michael L Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/


On Tue, Sep 15, 2020 at 2:53 PM Michael West via USRP-users <
usrp-us...@lists.ettus.com> wrote:

> UHD 4.0.0.0 is now available!  This is a major release.  It is not API or
> ABI compatible with earlier releases.  This release includes a new
> architecture as well as several new features and bug fixes.
>
> UHD 4.0.0.0 was a massive development undertaking, more than just a new
> version it's a leap forward in performance, usability, and stability you
> can learn more and see some demos at:
> https://www.ettus.com/announcing-uhd4/
>
> Installers for Windows and Fedora are available here:
> http://files.ettus.com/binaries/uhd/uhd_004.000.000.000-release/
>
> The PPA for Ubuntu will be uploaded soon and will be found here:
> https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
>
> The tag for this release is located here:
> https://github.com/EttusResearch/uhd/releases/tag/v4.0.0.0
>
> There have been 875 commits since the last API release which can be
> viewed here:
> https://github.com/EttusResearch/uhd/compare/v3.15.0.0...v4.0.0.0
>
> Please report any bugs found on the UHD issue tracker:
> http://github.com/EttusResearch/uhd/issues
> * Please do not use the issue tracker for help or support.
>
> Pull requests for direct code changes can be submitted to the UHD
> repository:
> http://github.com/EttusResearch/uhd/pulls
>
> As always, we at Ettus Research would like to thank all of the UHD users
> in the open source SDR community.  This release contains commits from users
> in the community that submitted pull requests against the UHD
>  repository as well as many commits
> that are a direct result of issues reported back to us by users like you
> through the UHD  issue
> tracker, the USRP-users mailing list
> , and 
> Ettus
> support .  You have all helped contribute to the
> continued improvement of UHD.  Thank you!
>
> CHANGELOG:
> ## 004.000.000.000
> * b200:
>   - Add unload-bootloader option to b2xx_fx3_utils
>   - Update FX3 SDK for bootloader and firmware
>   - Fix address for serial number in firmware
>   - Enable power calibration API
>   - Add a prop tree node usb_version
> * cal:
>   - Add utility to update all .fbs files, or check the generated ones
>   - Add pwr_cal container
> * cmake:
>   - Use relative path to Python lib location for Windows installer
>   - Add ability to pass CXXFLAGS to CMake environment
> * docs:
>   - Add new CHDR format to transports
>   - Update register maps
>   - Update FPGA manual
>   - Update mender commands for Zeus filesystems
>   - Add section about network mode on E3xx devices
>   - Add DPDK link detection section
>   - Add Windows-specific UHD Python module notes
>   - Add note about compiling on Ubuntu 20.04
>   - Update PCIe xport instructions for NI Repos
>   - n3xx: Include WX in table of N320 images
>   - Add stream and transport args documentation
>   - Update Basic/LF dboard references to use new operating mode
>   - e3xx/n3xx: Add sections on FP-GPIOs and how to drive them
>   - n3xx: Document eeprom flags
>   - Add note about DPDK needing to be built as shared libraries
>   - Change DPDK version to 18.11 and make args use underscores
>   - Clarifying which devices support DPDK
> * dpdk:
>   - Improve link status detection
>   - Increase default num recv frames
>   - Add new DPDK stack to integrate with I/O services
> * e31x:
>   - Add retry to loopback_self_test
>   - Change RFNoC Ctrl clock to 40 MHz
>   - Fix timeout for timekeeper registers
>   - Fix filter bank and antenna switching for channel 0
>   - Swap out liberio for internal Ethernet
> * e320:
>   - Fix timeout for timekeeper registers
>   - Swap out liberio for internal Ethernet
> * examples:
>   - Fix install paths in OOT RFNoC block example
>   - Add usrp_power_meter example
>   - Update test_messages example
>   - Update gpio example
>   - Add options to benchmark_rate
>   - Add example out-of-tree module for RFNoC modules
>   - Remove thread priority elevation
> * fpga:
>   - Added AA 

Re: [USRP-users] [UHD] Announcing 4.0.0.0 Release Candidate 1

[Michael Dickens]

Thanks for the UHD 4.0rc1 update, Michael. This UHD version will be the
most robust and compatible version yet!

For macOS users of UHD and GNU Radio, a brief update:

UHD 3.15 and UHD 4.0rc1 build and run on many macOS versions -- at
least 10.11 " El Capitan" through 10.15 "Catalina", and probably further
back with a modern enough compiler. I've built UHD 3.15 back to 10.8
"Mountain Lion", but unfortunately UHD applications do not execute ...
maybe others know what the issue is here? I have yet to try UHD 4.0rc1 on
these older macOS systems.

GNU Radio 3.7.14.0 and 3.8.2.0 -- with a patch to cover the commits since
this release was tagged on the "maint-3.8" branch -- also work with these
same macOS versions.

All of these projects / versions are available in MacPorts right now, via
the ports "uhd" (3.15), "uhd-devel" (4.0rc1), "gnuradio37" (3.7.14.0), and
"gnuradio" (3.8.2.0 + patches).

I have tested out GR 3.8.2.0 + UHD 4.0rc1 and they play nicely (enough)
together; I'm confident that the combinations GR 3.8.2.0 + UHD 3.15 and GR
3.7.14.0 + UHD 3.15 also work. MP allows GR 3.7.14.0 + UHD 4.0rc1, though I
don't know if this will even build.

I value any feedback on macOS building and/or use of UHD and GR (and Volk,
but that's pretty separate by now); MacPorts or some other install means;
any macOS version: 10.4-5 PPC 32/64, 10.4-16 Intel 32/64; even 10.16 ARM64
... if that's where you are (you're ahead of me then, though I'm catching
up ;)  !!!

Cheers! - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/


On Tue, Aug 25, 2020 at 8:46 PM Michael West via USRP-users <
usrp-us...@lists.ettus.com> wrote:

> The release candidate of the long awaited UHD version 4.0.0.0 has been
> tagged and is available for testing.  This major release introduces a new
> RFNoC framework, a new streaming infrastructure, a power calibration
> utility and API, and many other features and bug fixes.  The new
> infrastructure provides improved performance, more flexibility, and the
> foundation for future demands of higher throughput and lower latencies.
>
> The tag for this release candidate:
> https://github.com/EttusResearch/uhd/releases/tag/v4.0.0.0-rc1
>
> There have been 831 commits since the last release (3.15.0.0) which can
> be viewed here:
> https://github.com/EttusResearch/uhd/compare/v3.15.0.0...v4.0.0.0-rc1
>
> Please report any bugs found on the UHD issue tracker:
> http://github.com/EttusResearch/uhd/issues
> * Please do not use the issue tracker for help or support.
>
> Pull requests for direct code changes may be submitted to the UHD or FPGA
> repositories:
> http://github.com/EttusResearch/uhd/pulls
> http://github.com/EttusResearch/fpga/pulls
>
> CHANGELOG:
> ## 004.000.000.000
> * b200:
>   - Enable power calibration API
>   - Add a prop tree node usb_version
> * cal:
>   - Add utility to update all .fbs files, or check the generated ones
>   - Add pwr_cal container
> * cmake:
>   - Add ability to pass CXXFLAGS to CMake environment
> * docs:
>   - Update PCIe xport instructions for NI Repos
>   - n3xx: Include WX in table of N320 images
>   - Add stream and transport args documentation
>   - Update Basic/LF dboard references to use new operating mode
>   - e3xx/n3xx: Add sections on FP-GPIOs and how to drive them
>   - n3xx: Document eeprom flags
>   - Add note about DPDK needing to be built as shared libraries
>   - Change DPDK version to 18.11 and make args use underscores
>   - Clarifying which devices support DPDK
> * dpdk:
>   - Add new DPDK stack to integrate with I/O services
> * e31x:
>   - Change RFNoC Ctrl clock to 40 MHz
>   - Fix timeout for timekeeper registers
>   - Fix filter bank and antenna switching for channel 0
>   - Swap out liberio for internal Ethernet
> * e320:
>   - Fix timeout for timekeeper registers
>   - Swap out liberio for internal Ethernet
> * examples:
>   - Add usrp_power_meter example
>   - Update test_messages example
>   - Update gpio example
>   - Add options to benchmark_rate
>   - Add example out-of-tree module for RFNoC modules
>   - Remove thread priority elevation
> * fpga:
>   - Replaced RFNoC architecture with new 4.0 version
>   - Added modelsim make simulation target
>   - Upgrade to Vivade 2019.1
>   - Removed unused coregen files and modules
>   - Removed fpga submodule and merged into uhd repo
>   - lib: Change max FFT size to 1024
>   - lib: add Intel MAX10 architecture for 2clk FIFO
>   - rfnoc: Port RFNoC Keep One in N block to new RFNoC architecture
>   - rfnoc: Port RFNoC Replay block to new RFNoC architecture
>   - rfnoc: Port Signal Generator RFNoC block to new RFNoC architecture
>   - Add Switch

Re: [USRP-users] GPIO setup via gnuradio

[Michael Dickens]

Hi Ivan - I'll work with you off-list on this topic. If we figure out
something useful, we can report back to the lists here. - MLD



On Fri, Apr 17, 2020 at 7:41 PM Ivan Zahartchuk  wrote:

>
> Honestly, I have worked very little with gnuradio and do not quite
> understand what it means to transfer a UHD USRP object. If it does not make
> it difficult for you to show how it works, I will greatly appreciate it.
>
> пт, 17 апр. 2020 г. в 21:27, Michael Dickens :
>
>> Ohh ... nice! I didn't know gr-uhd provided that interface! A quick
>> search shows it's in GR as of sometime in version 3.7 .. not sure how far
>> back, but certainly in the current release. Good to know!
>>
>> Note that this gr-uhd GPIO API is available in Python (via SWIG) as well
>> as C++ ... BUT: it is not exposed into GRC.
>>
>> Hence, to use the UHD GPIO API inside GRC, you'll still need to do what I
>> wrote previously: provide the UHD USRP object to your custom GRC block
>> (whether Python or C++), and then it can manipulate the USRP GPIO via the
>> gr-uhd Python provided API, or directly in C++ via the UHD C++ API for GPIO.
>>
>> Fun fun fun! - MLD
>>
>>
>> On Fri, Apr 17, 2020 at 1:36 PM Rob Kossler  wrote:
>>
>>> The following link (GR documentation) shows some UHD GPIO functionality.
>>> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html
>>>
>>> On Fri, Apr 17, 2020 at 10:27 AM Michael Dickens via USRP-users <
>>> usrp-us...@lists.ettus.com> wrote:
>>>
>>>> Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via
>>>> UHD in GNU Radio?
>>>>
>>>> In theory this should be possible, at least in C++ and of course it
>>>> requires that the specific USRP have GPIO ...
>>>>
>>>> I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there
>>>> is then that method should work about the same as the C++ method.
>>>>
>>>> You'd have to get access to the instantiated USRP object, then you can
>>>> use that object to issue GPIO related calls. See these pages for more info
>>>> about GPIO in UHD:
>>>>
>>>> < https://files.ettus.com/manual/page_gpio_api.html >
>>>>
>>>> <
>>>> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
>>>>  >
>>>>
>>>> <
>>>> https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
>>>>  >
>>>>
>>>> I can't think of a current GNU Radio block that handles UHD USRP GPIO.
>>>> If you look around & can't find one, then you'd need to create a custom GNU
>>>> Radio block to handle this. You would pass your new block the USRP object,
>>>> which you'd then use for the GPIO calls ... using Python or C++ depending
>>>> on which API is available for your specific UHD.
>>>>
>>>> Maybe there's another way that I don't know of? If so hopefully others
>>>> will add to the discussion!
>>>>
>>>> Hope this is useful! - MLD
>>>>
>>>> On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
>>>> usrp-us...@lists.ettus.com> wrote:
>>>>
>>>>> Hello. Please tell me if it is possible to configure GPIO using
>>>>> gnuradio. I want to use RFNOC blocks and switch an external device using
>>>>> GPIO
>>>>> ___
>>>>> USRP-users mailing list
>>>>> usrp-us...@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>> ___
>>>> USRP-users mailing list
>>>> usrp-us...@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>

Re: [USRP-users] GPIO setup via gnuradio

[Michael Dickens]

Ohh ... nice! I didn't know gr-uhd provided that interface! A quick search
shows it's in GR as of sometime in version 3.7 .. not sure how far back,
but certainly in the current release. Good to know!

Note that this gr-uhd GPIO API is available in Python (via SWIG) as well as
C++ ... BUT: it is not exposed into GRC.

Hence, to use the UHD GPIO API inside GRC, you'll still need to do what I
wrote previously: provide the UHD USRP object to your custom GRC block
(whether Python or C++), and then it can manipulate the USRP GPIO via the
gr-uhd Python provided API, or directly in C++ via the UHD C++ API for GPIO.

Fun fun fun! - MLD


On Fri, Apr 17, 2020 at 1:36 PM Rob Kossler  wrote:

> The following link (GR documentation) shows some UHD GPIO functionality.
> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html
>
> On Fri, Apr 17, 2020 at 10:27 AM Michael Dickens via USRP-users <
> usrp-us...@lists.ettus.com> wrote:
>
>> Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via
>> UHD in GNU Radio?
>>
>> In theory this should be possible, at least in C++ and of course it
>> requires that the specific USRP have GPIO ...
>>
>> I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there is
>> then that method should work about the same as the C++ method.
>>
>> You'd have to get access to the instantiated USRP object, then you can
>> use that object to issue GPIO related calls. See these pages for more info
>> about GPIO in UHD:
>>
>> < https://files.ettus.com/manual/page_gpio_api.html >
>>
>> <
>> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
>>  >
>>
>> < https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
>>  >
>>
>> I can't think of a current GNU Radio block that handles UHD USRP GPIO. If
>> you look around & can't find one, then you'd need to create a custom GNU
>> Radio block to handle this. You would pass your new block the USRP object,
>> which you'd then use for the GPIO calls ... using Python or C++ depending
>> on which API is available for your specific UHD.
>>
>> Maybe there's another way that I don't know of? If so hopefully others
>> will add to the discussion!
>>
>> Hope this is useful! - MLD
>>
>> On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
>> usrp-us...@lists.ettus.com> wrote:
>>
>>> Hello. Please tell me if it is possible to configure GPIO using
>>> gnuradio. I want to use RFNOC blocks and switch an external device using
>>> GPIO
>>> ___
>>> USRP-users mailing list
>>> usrp-us...@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

Re: [USRP-users] GPIO setup via gnuradio

[Michael Dickens]

Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via UHD
in GNU Radio?

In theory this should be possible, at least in C++ and of course it
requires that the specific USRP have GPIO ...

I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there is
then that method should work about the same as the C++ method.

You'd have to get access to the instantiated USRP object, then you can use
that object to issue GPIO related calls. See these pages for more info
about GPIO in UHD:

< https://files.ettus.com/manual/page_gpio_api.html >

<
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
 >

< https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp >

I can't think of a current GNU Radio block that handles UHD USRP GPIO. If
you look around & can't find one, then you'd need to create a custom GNU
Radio block to handle this. You would pass your new block the USRP object,
which you'd then use for the GPIO calls ... using Python or C++ depending
on which API is available for your specific UHD.

Maybe there's another way that I don't know of? If so hopefully others will
add to the discussion!

Hope this is useful! - MLD

On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
usrp-us...@lists.ettus.com> wrote:

> Hello. Please tell me if it is possible to configure GPIO using gnuradio.
> I want to use RFNOC blocks and switch an external device using GPIO
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

Re: Problem in installing from Source

[Michael Dickens]

Hi Siddharth - Glad that all helped! Good luck with your GR work! - MLD


On Fri, Apr 17, 2020 at 7:05 AM Siddhartha Kapoor <
siddharthakapo...@gmail.com> wrote:

> Thanks Michael and Carl , after installing dependencies ans using sudo to
> install, it's working fine. I believe the error was in assigning flags for
> cmake.
>
> Regards
> Siddharth Kapoor
>
> On Fri, Apr 17, 2020 at 3:01 AM carl hansen 
> wrote:
>
>> first try
>> apt-get install gmp mpir
>>
>

Re: Problem in installing from Source

[Michael Dickens]

Let's take this off-list to work it out. If there's anything useful we'll
report back to the list. - MLD


On Thu, Apr 16, 2020 at 11:03 AM Siddhartha Kapoor <
siddharthakapo...@gmail.com> wrote:

> Thanks for the help,I tried building maint-3.8 and PFA the cmake output.
> Also I executed the following sa mentioned here [1]
>
> cd
> git clone --recursive https://github.com/gnuradio/gnuradio.git
> cd gnuradio
> git clone https://github.com/gnuradio/volk.git
> git checkout maint-3.8
> cd volk
> git checkout v2.2.1
> cd ..
> mkdir build
> cd build
>
> Uptil here it's working fine, it's failing at
> cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../
>
> [1]
> https://wiki.gnuradio.org/index.php/InstallingGR#For_the_GNU_Radio_Master_Branch
>
> On Thu, Apr 16, 2020, 8:00 PM Michael Dickens 
> wrote:
>
>> Oh ... just noticed you provided the cmake command itself already ... my
>> bad & you obviously don't need to supply it!
>>
>> What we do need to know is: which version of GR are you trying to build?
>> A release? A GIT branch & if so which one?
>>
>>
>> On Thu, Apr 16, 2020 at 10:28 AM Michael Dickens <
>> michael.dick...@ettus.com> wrote:
>>
>>> Hi Siddhartha - The logs are unfortunately not greatly useful here. What
>>> would be useful is noting the specific "cmake" command you're using, and
>>> then the output from that command. - MLD
>>>
>>> On Thu, Apr 16, 2020 at 3:44 AM Siddhartha Kapoor <
>>> siddharthakapo...@gmail.com> wrote:
>>>
>>>> I tried installing gnuradio from source as mentioned here [1] but
>>>> encountered problem while doing
>>>> cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3
>>>> ../
>>>>
>>>> OS is ubuntu 18, PFA the log and error files from CMake, any help would
>>>> be appreciated.
>>>>
>>>> Regards
>>>> Siddharth Kapoor
>>>>
>>>> [1] https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
>>>>
>>>

Re: Problem in installing from Source

[Michael Dickens]

Oh ... just noticed you provided the cmake command itself already ... my
bad & you obviously don't need to supply it!

What we do need to know is: which version of GR are you trying to build? A
release? A GIT branch & if so which one?


On Thu, Apr 16, 2020 at 10:28 AM Michael Dickens 
wrote:

> Hi Siddhartha - The logs are unfortunately not greatly useful here. What
> would be useful is noting the specific "cmake" command you're using, and
> then the output from that command. - MLD
>
> On Thu, Apr 16, 2020 at 3:44 AM Siddhartha Kapoor <
> siddharthakapo...@gmail.com> wrote:
>
>> I tried installing gnuradio from source as mentioned here [1] but
>> encountered problem while doing
>> cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../
>>
>> OS is ubuntu 18, PFA the log and error files from CMake, any help would
>> be appreciated.
>>
>> Regards
>> Siddharth Kapoor
>>
>> [1] https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
>>
>

Re: Problem in installing from Source

[Michael Dickens]

Hi Siddhartha - The logs are unfortunately not greatly useful here. What
would be useful is noting the specific "cmake" command you're using, and
then the output from that command. - MLD

On Thu, Apr 16, 2020 at 3:44 AM Siddhartha Kapoor <
siddharthakapo...@gmail.com> wrote:

> I tried installing gnuradio from source as mentioned here [1] but
> encountered problem while doing
> cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../
>
> OS is ubuntu 18, PFA the log and error files from CMake, any help would
> be appreciated.
>
> Regards
> Siddharth Kapoor
>
> [1] https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
>

Re: Control of running time

[Michael Dickens]

Short answer: no. - MLD

On Fri, Apr 3, 2020 at 2:44 PM Artur Nogueira  wrote:

> Hi all,
>
> Is there a way of precisely controlling the simulation/running time of GNU
> Radio, i.e. initial and final time instants?
>
> Thanks.
>
> Regards,
> Artur
>

Re: GNUradio 3.8: ModuleNotFoundError: No module named 'myModulename'

[Michael Dickens]

Hi Laura - I'm guessing the location where your GR OOT was installed isn't
in the PYTHONPATH, nor the default path for the Python being used. Check
out this (recently updated) GR wiki page <
https://wiki.gnuradio.org/index.php/ModuleNotFoundError > ... hopefully
that info helps you along! - MLD

On Thu, Feb 27, 2020 at 5:24 PM Laura Arjona  wrote:

> Hello community!
>
> I just updated my complete OOT module (named *bcsi*)  from gnuradio 3.7
> to 3.8, and I could make and install  without errors.
> Using version 3.8, I created every block with gr_modtool (and then
> copied-pasted the .cc and .h code from 3.7 version to 3.8)
>
> However, python will not find my module. I already did some basic
> debugging.
>
> In the /build directory, I already run
> $cmake ..
> .
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/Documents/gr-bcsi/build
> $make
> $sudo make install
> $sudo ldconfig
>
> I can see the modules appear in the grc GUI, but still cannot find my
> module.
>
> $ python3
> Python 3.6.9 (default, Nov  7 2019, 10:44:02)
> [GCC 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import gnuradio
> >>> import bcsi
> Traceback (most recent call last):
>   File "", line 1, in 
> ModuleNotFoundError: No module named 'bcsi'
> >>>
>
>
> Any advice would be welcomed!
>
> Best
>
>
> --
> *Laura Arjona *
> Washington Research Foundation Innovation Postdoctoral Fellow in
> Neuroengineering
>
> *Paul G. Allen School of Computer Science & Engineering*
> 185 E Stevens Way NE
> University of Washington
> Seattle, WA 98195-2350
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: GRC 3.8 Output language Py2 or Py3 (Windows)

[Michael Dickens]

If you install from an EXE, then you'll get whatever it was built for (Py27
or Py3). If there's any way to build from source then you can select the
Python version directly. I don't run Windows, nor do I build for it;
hopefully someone is providing different Windows installer for GR38 with
variants for Py27 and Py3 ... - MLD

On Thu, Feb 20, 2020 at 10:08 AM Jerom Maas - LR 
wrote:

> Hello Michael, thanks for the quick response!
>
> I've just reinstalled GRC, but I've not seen a single option about Py2 or
> Py3. Maybe it's because I use the .exe installer, that it automatically
> chooses Py2 then? As said before, I don't even have Py2 installed on my pc.
> Should I give it a go using Powershell, or try another method?
>
>
> Jerom
> ----------
> *Van:* Michael Dickens 
> *Verzonden:* donderdag 20 februari 2020 15:50:43
> *Aan:* Jerom Maas - LR
> *CC:* discuss-gnuradio@gnu.org
> *Onderwerp:* Re: GRC 3.8 Output language Py2 or Py3 (Windows)
>
> Hi Jerom - I believe GRC outputs Py script based on how GR is installed.
> Since GR38 can be installed using Py27 or Py3, if it's installed using Py27
> then GRC will output for Py27. If installed for Py3 then it'll output for
> Py3. Pretty sure this is correct. Hence, I'd advise you to check how GR is
> installed in the first place & if for Py27 then see about getting it
> installed for Py3. Hope this is useful! - MLD
>
> On Thu, Feb 20, 2020 at 9:06 AM Jerom Maas - LR 
> wrote:
>
>> Hello all,
>>
>>
>> after installing GRC 3.8, I find that the .py files that are created from
>> grc are python 2, instead of python 3.
>>
>> I use Py3 and not Py2, so that's a problem.
>>
>> How do I change the output language of GRC? If I use the 'option block'
>> I can only choose 'Python'  or ' C++' , but I can't specify the version of
>> Python. I am using Windows.
>>
>>
>> Thanks for your help,
>>
>>
>> Jerom Maas
>>
>>
>> PS I am not so familiar with C, so if the solution is to alter a bit in
>> Cmake or something, can you specifically name the file that needs to be
>> changed? That would be very helpful!
>>
>>
>>
>>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ettus.com_=DwMFaQ=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8=FxwOwDihISw27IZqIUL77cVHQ03qpclxjfkd7WoRAZ8=4Qt2qqxzwfcgse05-jHhxTKL2s_6khvM9dPG_7gJT-w=Z_ulw1Sj8aIhXzWJlursSXq4MkIH48XQTQjmWaIzjYw=>
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: GRC 3.8 Output language Py2 or Py3 (Windows)

[Michael Dickens]

Hi Jerom - I believe GRC outputs Py script based on how GR is installed.
Since GR38 can be installed using Py27 or Py3, if it's installed using Py27
then GRC will output for Py27. If installed for Py3 then it'll output for
Py3. Pretty sure this is correct. Hence, I'd advise you to check how GR is
installed in the first place & if for Py27 then see about getting it
installed for Py3. Hope this is useful! - MLD

On Thu, Feb 20, 2020 at 9:06 AM Jerom Maas - LR  wrote:

> Hello all,
>
>
> after installing GRC 3.8, I find that the .py files that are created from
> grc are python 2, instead of python 3.
>
> I use Py3 and not Py2, so that's a problem.
>
> How do I change the output language of GRC? If I use the 'option block'  I
> can only choose 'Python'  or ' C++' , but I can't specify the version of
> Python. I am using Windows.
>
>
> Thanks for your help,
>
>
> Jerom Maas
>
>
> PS I am not so familiar with C, so if the solution is to alter a bit in
> Cmake or something, can you specifically name the file that needs to be
> changed? That would be very helpful!
>
>
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Using ZMQ source blocks with a separate process

[Michael Dickens]

GR's ZMQ should work across threads, processes, and networks; between GR
and non-GR so long as the packet formatting is correct. I've used ZMQ
between GR within a network, never done this between GR and non-GR though
... so maybe this is an aspiration rather than guarantee? - MLD

On Mon, Feb 17, 2020 at 9:07 PM Barry Duggan  wrote:

> Hi,
>
> I would like to use one of the ZMQ source blocks (such as ZMQ PULL
> Message Source) to communicate with a separate Python process. I have
> been able to use various Python examples to test between processes, but
> when I try to use a GRC block, it fails. Are there restrictions which
> prohibit data exchange outside the gnuradio realm?
>
> Thanks for your help.
> --
> Barry Duggan KV4FV
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: wxgui GRC 3.7.13.5 MacOS 10.14.6

[Michael Dickens]

Hi Carlos - Just to make sure: When you do "port installed gnuradio" it
turns back the 3.7.13.5 release with variants that include +wxgui ... yes?
The GNU Radio ports do not by default install +wxgui; you have to do so
manually: "sudo port install gnuradio +wxgui". If your GR is installed that
way, please let me know & I'll reinstall mine to match & see if it works
for me. I moved to QtGUI a long time ago ... - MLD

On Sun, Feb 16, 2020 at 3:33 AM Carlos  wrote:

> As I remember wxgui is not in GRC 3.8 but I can’t move to 3.8 yet. I
> installed GRC with Macports but I’m having problems running any wxgui sink.
> Is there a way to get them working? Here’s one of the blocks.
>
>  File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fftsink2.py",
> line 31, in 
> from fftsink_gl import fft_sink_f, fft_sink_c
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_gl.py",
> line 27, in 
> import fft_window
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fft_window.py",
> line 33, in 
> import forms
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/__init__.py",
> line 36, in 
> from forms import \
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/forms.py",
> line 64, in 
> class _form_base(pubsub, wx.BoxSizer):
> TypeError: Error when calling the metaclass bases
> multiple bases have instance lay-out conflict
>
> v/r,
>
> Carlos
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: example pfb_sync_test

[Michael Dickens]

Can you provide us with a little more info here, and that we can try to
replicate your issue:

* Is the OS "Ubuntu 18.04.3 LTS (Bionic Beaver)" ... or something else?

* Are you trying to use the GNU Radio 3.8.0.0 release?

* How did you install GR?

* what version of Thrift is installed, and how did you install it?


On Thu, Feb 13, 2020 at 9:04 AM sarandis. Doulgeris <
sarandis.doulge...@gmail.com> wrote:

> Hi when i try to run the example i get this error
>
> ControlPort Monitor running.
> python3:
> /build/gnuradio-6i8Hb6/gnuradio-3.8.0.0~gnuradio~bionic/gnuradio-runtime/lib/controlport/rpcmanager.cc:38:
> static rpcserver_booter_base* rpcmanager::get(): Assertion
> `booter_registered || aggregator_registered' failed.
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: AttributeError: OOT Modul

[Michael Dickens]

Hi Til - Without seeing your code, we can just provide some basic advice,
such as the prior email. If you have a GitHub or GitLab public repo for
this we can take a look ... otherwise it's just guesswork on our end! - MLD

On Wed, Feb 12, 2020 at 9:48 AM "Till Hülder"  wrote:

> Hello,
>
> i build a OOT Module and after installing i get this error when i run the
> program .
>
>   File "/home/iheamira/Dokumente/BA_Huelder/gnu-radio/top_block.py", line
> 219, in 
> main()
>   File "/home/iheamira/Dokumente/BA_Huelder/gnu-radio/top_block.py", line
> 207, in main
> tb = top_block_cls()
>   File "/home/iheamira/Dokumente/BA_Huelder/gnu-radio/top_block.py", line
> 142, in __init__
> self.control_control_b_0 = control.control_b(5e-6, 1000, 10, 5e-6,
> 5e-6, 5e-6, 200e-6, 100e-6, 0.2, samp_rate)
> AttributeError: 'module' object has no attribute 'control_b'
>
> How can i fix this?
>
> Best regards ,
> Til
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Help GRC with USRP N300

[Michael Dickens]

Hi Jean Marie - 2 thoughts:

1) Did you run "sudo ldconfig" after installation? Always a good idea to do
that after installing anything, to update to LD cache.

2) If you run
{{{
/usr/bin/python2 -c "import sys; print(sys.path)"
}}}
is one of the paths "/usr/local/lib/python2.7/dist-packages"?  If not, then
you need to add that path to the shell environment PYTHONPATH variable, and
add it to one of the shell login command scripts. For example if you use
BASH, then you could add the following to ~/.bashrc:
{{{
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages:$PYTHONPATH
}}}
so that when you login this path is automatically available. You can, of
course, set it in your current terminal to test / verify that doing so
fixes the issue.

Hope this is useful! - MLD

On Wed, Feb 12, 2020 at 8:43 AM Jean Marie Brieussel 
wrote:

> Hi,
>
> I installed UHD V3.15.0.0 and GNURadio V3.7.13.4 the loaded FPGA image is
> the XG. I checked the correct functioning of UHD and GNURadio as well as
> the USRP N300 with UHD, the tests are correct. I checked that the N300 is
> seen by the host PC, see the result below:
>
> jmf6etu@JM-F6ETU:~$ uhd_find_devices
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.HEAD-0-gaea0e2de
> --
> -- UHD Device 0
> --
> Device Address:
> serial: 31C037E
> addr: 192.168.20.2
> claimed: False
> mgmt_addr: 192.168.10.2
> mgmt_addr: 192.168.20.2
> product: n300
> type: n3xx
> I did the small classic test program under GRC, see the attached
> screenshot, (I hope that the attached files are visible on this discussion
> list).
>
> In copy if below the Terminal information lines:
>
> jmf6etu@JM-F6ETU:~$ gnuradio-companion
> Gtk-Message: 14:15:09.794: Failed to load module "canberra-gtk-module"
> <<< Welcome to GNU Radio Companion 3.7.13.4 >>>
>
> Block paths:
> /usr/local/share/gnuradio/grc/blocks
>
> Loading: "/home/jmf6etu/Bureau/Appli_GNU/FM_exemplegrc.grc"
> >>> Done
>
> Loading: "/home/jmf6etu/Bureau/Appli_GNU/gene.grc"
> >>> Done
>
> Generating: '/home/jmf6etu/Bureau/Appli_GNU/fm_exemple.py'
>
> Executing: /usr/bin/python2 -u
> /home/jmf6etu/Bureau/Appli_GNU/fm_exemple.py
>
> Traceback (most recent call last):
>   File "/home/jmf6etu/Bureau/Appli_GNU/fm_exemple.py", line 25, in
> 
> from gnuradio import uhd
>   File "*/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/*__init__.py",
> line 135, in 
> _prepare_uhd_swig()
>   File "*/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/*__init__.py",
> line 38, in _prepare_uhd_swig
> import uhd_swig
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 17, in 
> _uhd_swig = swig_import_helper()
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 16, in swig_import_helper
> return importlib.import_module('_uhd_swig')
>   File "*/usr/lib/python2.7/importlib/*__init__.py", line 37, in
> import_module
> __import__(name)
> ImportError: No module named _uhd_swig
>
> >>> Done (return code 1)
> Advice to solve my problems is welcome.
>
> Best Regards,
>
> Jean Marie
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: clear buffers of stuck chain

[Michael Dickens]

GNU Radio does not provide a way to flush stream buffers during runtime, if
that's what you're asking. If something isn't working, then there's
something strange going on in the flowgraph and/or your overall system ..
for example sample rate mis-matches can happen when using actual hardware
(especially when doing both Tx and Rx in the same flowgraph). If you want
to get into some more detail (but not too much) about the issue(s) your
seeing, we might be able to provide more specific assistance. - MLD

On Mon, Feb 10, 2020 at 4:11 AM Eitan Hetzroni  wrote:

> hi,
> the chain is https://github.com/bastibl/gr-ieee802-15-4 used to transmit
> 802154 over usrp b200mini
>
> On Sun, Feb 9, 2020 at 12:32 PM Müller, Marcus (CEL) 
> wrote:
>
>> Hi Eitan,
>>
>> sorry, nobody will be able to help you based on the lack of information
>> on what exactly you're doing. "A zigbee chain" really doesn't help any
>> of us debug your issue!
>>
>> Best regards,
>> Marcus
>>
>> On Sun, 2020-02-09 at 09:33 +0200, Eitan Hetzroni wrote:
>> > anyone?
>> >
>> > On Wed, Feb 5, 2020 at 5:47 PM Eitan Hetzroni 
>> > wrote:
>> > > hi,
>> > > i am using a gnuradio zigbee chain , and sending alot of packets.
>> > > after a certain point, it stops sending packets(or does very
>> > > slowly).
>> > > can i somehow increase the buffer(message loop) or force it to
>> > > clear the message loop?
>> > >
>> > > thanks
>> > >
>> >
>> > The information transmitted is intended only for the person or entity
>> > to which it is addressed and may contain confidential and/or
>> > privileged material. Any review, retransmission, dissemination or
>> > other use of, or taking of any action in reliance upon, this
>> > information by persons or entities other than the intended recipient
>> > is prohibited. If you received this in error, please contact the
>> > sender and delete all copies of the message.
>>
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete all copies of the
> message.



-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Ubuntu 18.04 LTS QtGUI issues

[Michael Dickens]

Interesting. I really have no idea what's going on there. Using a package
install should just work. Are there maybe multiple GR installs & somehow
they are being mixed-between -- maybe by some odd shell
environment settings? - MLD

On Wed, Jan 29, 2020 at 1:35 PM Marcus D Leech 
wrote:

> Using apt-get install Gnuradio.
>
> That package includes everything.
>
> Sent from my iPhone
>
> On Jan 29, 2020, at 1:23 PM, Michael Dickens 
> wrote:
>
> 
> Looks like gr-qtgui wasn't installed. How did the user install GR?
>
> On Wed, Jan 29, 2020 at 1:22 PM Marcus D. Leech 
> wrote:
>
>> I have a user of my spectro_radiometer app who is having problems
>> installing it on Ubuntu 18.04 LTS.
>>
>> He installed gnuradio from the repos, then when using  grcc -d on the
>> .grc file, gets:
>>
>> Block key "variable_qtgui_label" not found
>> Block key "variable_qtgui_range" not found
>> Block key "variable_qtgui_entry" not found
>> Block key "variable_qtgui_push_button" not found
>> Block key "variable_qtgui_check_box" not found
>> Block key "variable_qtgui_chooser" not found
>> Block key "variable_qtgui_chooser" not found
>> Block key "variable_qtgui_label" not found
>> Block key "variable_qtgui_check_box" not found
>> Block key "variable_qtgui_entry" not found
>> Block key "variable_qtgui_entry" not found
>> Block key "variable_qtgui_entry" not found
>> Block key "variable_qtgui_label" not found
>> Block key "variable_qtgui_push_button" not found
>> Block key "variable_qtgui_entry" not found
>> Block key "variable_qtgui_label" not found
>> Block key "variable_qtgui_chooser" not found
>> Block key "qtgui_tab_widget" not found
>> Block key "osmosdr_source" not found
>> Block key "qtgui_vector_sink_f" not found
>> Block key "qtgui_vector_sink_f" not found
>> Block key "qtgui_vector_sink_f" not found
>> Block key "qtgui_waterfall_sink_x" not found
>> Block key "qtgui_tab_widget" not found
>>
>>
>> This looks to me like the QtGUI components of GR weren't installed
>> correctly by the installer, yet, on my systems here that I've tried,
>>everything works.
>>
>>
>>
>>
>>
>>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Ubuntu 18.04 LTS QtGUI issues

[Michael Dickens]

Looks like gr-qtgui wasn't installed. How did the user install GR?

On Wed, Jan 29, 2020 at 1:22 PM Marcus D. Leech 
wrote:

> I have a user of my spectro_radiometer app who is having problems
> installing it on Ubuntu 18.04 LTS.
>
> He installed gnuradio from the repos, then when using  grcc -d on the
> .grc file, gets:
>
> Block key "variable_qtgui_label" not found
> Block key "variable_qtgui_range" not found
> Block key "variable_qtgui_entry" not found
> Block key "variable_qtgui_push_button" not found
> Block key "variable_qtgui_check_box" not found
> Block key "variable_qtgui_chooser" not found
> Block key "variable_qtgui_chooser" not found
> Block key "variable_qtgui_label" not found
> Block key "variable_qtgui_check_box" not found
> Block key "variable_qtgui_entry" not found
> Block key "variable_qtgui_entry" not found
> Block key "variable_qtgui_entry" not found
> Block key "variable_qtgui_label" not found
> Block key "variable_qtgui_push_button" not found
> Block key "variable_qtgui_entry" not found
> Block key "variable_qtgui_label" not found
> Block key "variable_qtgui_chooser" not found
> Block key "qtgui_tab_widget" not found
> Block key "osmosdr_source" not found
> Block key "qtgui_vector_sink_f" not found
> Block key "qtgui_vector_sink_f" not found
> Block key "qtgui_vector_sink_f" not found
> Block key "qtgui_waterfall_sink_x" not found
> Block key "qtgui_tab_widget" not found
>
>
> This looks to me like the QtGUI components of GR weren't installed
> correctly by the installer, yet, on my systems here that I've tried,
>everything works.
>
>
>
>
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Issues with gnuradio paths and syntax errors

[Michael Dickens]

Hi Sarah - From the Python error, it looks like you're mixing Python 3 code
with a Python 2 executable. Since you don't list your actual commands
issued, I can't tell. If you have both installed and don't know if you need
Py2, I'd say to try removing it & see what happens for a day. Hope this
helps! - MLD

On Sat, Jan 25, 2020 at 2:25 AM Sarah Rogers  wrote:

> Hello,
>
> I'm having some issues using gnuradio with python programs. I am trying to
> use gnuradio with gr-satellites' python programs to decode packets from
> CubeSats. When I try to run a python file, I receive the following output
>
>
>
>
>
>
>
>
>
> *Traceback (most recent call last):  File "taurus1_telemetry_parser.py",
> line 23, in from gnuradio import gr  File
> "/usr/local/lib/python3/dist-packages/gnuradio/gr/__init__.py", line 39, in
> from .runtime_swig import *  File
> "/usr/local/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py", line
> 117def value(self) -> "PyObject *":^SyntaxError:
> invalid syntax*
>
> I have read that syntax errors result from different python versions, but
> I am also wondering if this might be the result of something else. I first
> tried investigating the syntax error, but when I didn't find anything, I
> became sucked into the black hole that is my potential issue below.
>
> I received the syntax error after editing my bash.rc file to include the
> path to the python3 library where the gnuradio folder is contained. In the
> process of investigating the path issue, it appeared that I didn't have all
> of the path dependencies that people normally do for running gnuradio with
> python. I'm not sure if this issue and my syntax error are related, so I
> thought I would inquire on here.
>
> The following command is in my bashrc file:
>
> *export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3/dist-packages*
>
> as reference, you can see that `/python3/dist-packages` contains gnuradio,
> along with a few other folders
>
>
> *WorkStation-T5500:/usr/local/lib/python3/dist-packages$ ls gnuradio  pmt
>  satellites  volk_modtool*
>
> In addition, the gnuradio folder contains the following:
> [image: image.png]
>
> However, based on the following references for installing gnuradio, it
> seems that I am missing the paths to gnuradio/lib and gnuradio/bin. I have
> not been able to find information that will allow me to fix this. Based on
> posts that I have read with similar questions as mine, I thought this may
> be one issue with my setup, but I could also be misinterpreting something.
>
> [Ref 1 (Ghithub) ](
> https://github.com/gnuberries/raspberry-radio/wiki/GNU-Radio-Installation-Instructions-(for-desktop-or-notebook)
> )
>
> [Ref 2 (lists.gnu.org)](
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-08/msg00017.html)
>
> I installed gnuradio through ppa, as well as pybombs. Do you think the
> missing paths could be the source of my issue, or are there actually
> multiple issues here? If so, would it be better to just delete gnuradio
> entirely and try to install it fresh using pybombs?
>
> Thank you for any advice you may have here. I'm still getting used to
> linux and solving installation issues in general, so please let me know if
> I can clarify anything further.
>
> ~Sarah
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: gnuradio-3.8 build fails with error: cannot convert const string {aka const std::__cxx11::basic_string} to pmt::pmt_t {aka boost::shared_ptr}

[Michael Dickens]

The issue is how CMake decides to order "include_directories". There are
(if I recall correctly) 4 primary sources of these via properties: for the
directory, for individual sources, for to-be-built targets, and for linkage
targets. The ordering of these is critical, since our goal is to list
in-tree headers/linkage before out-of-tree headers/linkage. I'd have to go
back to my work to remember how CMake orders these, but what I do recall is
that the last one (for linkage targets) doesn't come last, which seems
wrong to me: any out-of-tree property should always come last in any
ordering! And, I could not figure out an easy or clean way to force the
ordering to work for our goal. It's an unfortunate confluence of moving to
"modern CMake" linkage targets and how CMake works internally. Once I'm
caught up with UHD, GR, and Volk backlog from being away for 2 weeks, I'll
look into this issue again since it's pretty critical for MacPorts that
this work! Hope this is useful and maybe makes some sense! - MLD

Re: gnuradio-3.8 build fails with error: cannot convert const string {aka const std::__cxx11::basic_string} to pmt::pmt_t {aka boost::shared_ptr}

[Michael Dickens]

Marcus got it: there are old headers around in some system prefix (possibly
including "${CMAKE_INSTALL_PREFIX}/include"), which are being picked up by
CMake and included ("-I...") -before- the internal-to-GR-build ones. The GR
API changed, and because the old header is being used with the new code,
the error is generated. I've investigated this issue & could figure out no
good fix because of the way CMake handles the "include directories"
internally between targets and the current build. Hence, my recommendation
is to not build a new GR while an old one is installed in system prefix
(etc). - MLD

On Thu, Jan 2, 2020 at 11:16 AM Marcus Müller 
wrote:

> Hi Tom,
>
> funky distro!
> That API used to be string (of a serialized PMT) and now is PMT
> directly. That happened somewhere around July.
> Thus, this slightly looks like you still have some older header files
> lying around? Or some outdated SWIG output that somehow ends up in your
> build?
> Could you try in a clean container? I'm trying here locally, but
> honestly, I've never used slackware before, and thus I need to learn
> every packager tool in the process, and that's kind of a burden.
>
> Best regards,
> Marcus
> On Thu, 2020-01-02 at 15:18 +, Tom Crane wrote:
> > I am attempting to build the v.3.8 source under Slackware64 Linux
> > and
> > can't get past this and a few subsequent errors.
> >
> > Building from the git source results in the same failure.
> >
> > Build system details:
> >   o gcc 9.2.0
> >   o SWIG version 4.0.1
> >   o Boost 1.72.0
> >
> > My build scripts and build logs are here
> > https://www.mklab.rhul.ac.uk/~tom/tvdx/gr/build_problems/
> >
> > Please advise.
> >
> > Many thanks
> > Tom Crane
> >
>
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: [USRP-users] [UHD] 3.15.0.0 Release Announcement

[Michael Dickens]

ng
>   ce_clk driver
> * E310: Convert to MPM architecture, fix uhd_image_loader usage, fix DMA
>   arbitration to use contiguous packets, reduced DMA chans to 4 (using
>   data stream muxing), fix DRAM_TEST target build
> * E3xx: Correct frontend name in devtest
> * B200: Add command to query bootloader status, fix sc12 streaming, fix
>   FIFO sizes on GPIFII interface
> * UBX: add temperature compensation mode
> * SBX: Only update ATRs when lock state changes
> * TwinRX: add LO charge pump properties, increase default charge pump
>   value on LO1, add low spur tuning mode, fix duplicate write to N value
>   in DDC
> * RFNoC/device3: Read command FIFO size from device instead of
>   hardcoding values, fix multidevice graph connections, ENABLE_RFNOC now
>   defaults to ON, search all nodes for tick rate, add update_graph()
>   call which lets blocks do a graph-wide update of properties, fix
>   missing port arg in SR_WRITE Noc-Script call, constrain
>   send/recv_frame_size baed on MTU, fix flushing on init/deinit, disable
>   FC ACKs for lossless links
> * RFNOC/FPGA: Fix rb_stb in split stream block, fix off-by-one error in
>   the window block, fix phase reset and -accumulator for DDC and DUC
>   blocks, fix flushing on split-stream block, fix DC offset issue with
>   DDS by using proper rounding, fix DUC/DDC sample rate switching by
>   latching N on M in axi_rate_change, various fixes to
>   uhd_image_builder, fix MTU settings in blocks, align byte count to
>   8-byte word
> * RFNOC: Allow UHD_RFNOC_DIR to contain multiple paths
> * Python API: Replace Boost.Python with PyBind11, fix benchmark_rate
>   statistics, fix phase alignment test script
> * Python API: Added include of complex.h to allow pybind to convert
>   complex data types
> * Python API: Make multi_usrp::get_*_usrp_info() return a Python dict
> * Python API: Fix array processing in send_waveforms()
> * UHD: Allow ignoring fallthrough warnings, reduce Boost footprint,
>   remove gpsd dependency, improve streaming, reduced the number of
>   compiler warnings, introduce pop() to the prop tree, add typecast
>   operator from uhd::dict<> to std::map<>, properly cache config file
>   data
> * MPM/mpmd: Introduce compatible rev numbers to support future hardware,
>   fix some resource leaks in mpmd, fix spurious reclaims causing
>   unnecessary warnings, fix resource leaks in liberio xport, allow to
>   mux data streams over liberio transports (e.g. to require fewer DMA
>   channels on E310), wait for DPDK links to come up before proceeding,
>   relax failure handling when updating components (fixes spurious errors
>   when updating FPGA images over SFP), fix issue where RPC
>   initialization would hang on failure
> * MPM:  Re-enable RPC server timeouts after components have been updated
> * MPMD: Remove arbitrary frame size defaults for UDP transports
> * MPMD: Fix incorrect link rate warnings
> * FPGA: Use new device-tree overlay syntax, upgraded to Vivado 2018.3,
>   broke various paths with critical timing, allow SystemVerilog source
>   files, improve viv_modify_bd and viv_modify_tcl_bd, fix resets on 2clk
>   FIFOs
> * USB: Allow cancelled USB requests to occur
> * USB: Fix global session race condition
> * Logging: Always honour log level, don't log colours for non-ttys, fix
>   includes, demote various log messages, fix logging colours, fix
>   deadlock on Windows machines
> * Examples: Fix benchmark_rate INIT_DELAY, fix memory leak in
>   tx_samples_c
> * Examples: Remove thread priority elevation
> * Examples: Add options to benchmark_rate for start delays and priority
> * Tests: Make the Python interpreter for devtests a parameter, add unit
>   tests to MPM
> * Utilities: Fix converter benchmark for Py3k and scaling issue
> * Tools: Fix kitchen_sink
> * Tools: Fix Wireshark dissectors to work with WS1, 2, and 3
> * Tools: Various fixes to FPGA functional verification tests
> * Docs: Various fixes, fix Doxygen warnings, fix links to KB, update
>   DPDK information about building libraries, add DPDK subsection about
>   thread priorities, update testing procedures
> * C API: Add uhd_get_abi_string, uhd_get_version_string
> * CMake: Make manpage compression optional, allow setting of PKG_DOC_DIR
>   from the CMake command line, add replay example, fix missing 'project',
>   replace ENABLE_PYTHON3 with a simpler Python detection, clean up
>   superfluous modules, improve log statements, bump dependency min
>   versions, add MPM unit testing, fix missing BIGOBJ for MSVC, add our
>   own UHDBoost.cmake to better find Boost across versions and systems,
>   constrain DPDK check to exact version
> * Formatting: Apply clang-format to all files, break after template<>
>
> Best regards,
> Michael
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: oot gr-cessb link error

[Michael Dickens]

Hi Leo - What version of GR are you trying to use? This OOT requires GR37 to 
build. Also, if you do ‘make VERBOSE=ON’ you’ll see the actual link command 
which should be informative about the libraries being linked against. - MLD

> On Dec 29, 2019, at 11:50 AM, leo bistmans  wrote:
> 
> 
> https://github.com/drmpeg/gr-cessb
> 
> After cmake ../ the linking fails:
> 
> make
> [ 16%] Built target gnuradio-cessb
> [ 22%] Linking CXX executable test-cessb
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::block::fixed_rate_noutput_to_ninput(int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::sync_block::sync_block(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> boost::shared_ptr, boost::shared_ptr)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `pmt::dict_has_key(boost::shared_ptr const&, 
> boost::shared_ptr const&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `vtable for gr::sync_block'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `typeinfo for gr::sync_block'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `typeinfo for gr::block'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32f_x2_multiply_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `gr::block::forecast(int, 
> std::vector >&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `gr::io_signature::make(int, 
> int, int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::sync_block::general_work(int, std::vector >&, 
> std::vector >&, std::vector std::allocator >&)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `gr::block::consume_each(int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32f_x2_interleave_32fc'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::block::set_log_level(std::__cxx11::basic_string std::char_traits, std::allocator >)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32f_x2_max_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::sync_block::fixed_rate_noutput_to_ninput(int)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32f_s32f_multiply_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32f_sin_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32f_x2_add_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::msg_accepter::post(boost::shared_ptr, 
> boost::shared_ptr)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_get_alignment'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32fc_magnitude_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `volk_32f_x2_divide_32f'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::block::unset_processor_affinity()'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to 
> `gr::block::block(std::__cxx11::basic_string, 
> std::allocator > const&, boost::shared_ptr, 
> boost::shared_ptr)'
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
> libgnuradio-cessb.so: undefined reference to `gr::sync_block::forecast(int, 
> std::vector >&)'
> 

Re: How can I alter install script to bypass dead link causing install to fail on OS X10.6.8?

[Michael Dickens]

Hi Bob - I can't help you with the Brew issue ... so what I'm wondering is
if you've looked into using MacPorts. It should be able to install GNU
Radio 3.7 latest release on OSX 10.6.8 (and back to 10.4 PPC and forward to
10.15; I think it can't install on 10.4 Intel, but I'll admit that's a bit
esoteric -- even more so than 10.4/5 PPC these days!). If you run into
issues I can help you out! NP either way ... just offering an alternative.
Good luck! - MLD

On Sun, Dec 29, 2019 at 5:25 PM Bob  wrote:

> I am not an expert in OS X.  I likely am missing an easy work around for a
> gnuradio install missing file problem.
>
> I tried brew edit gnuradio, but there is no mention in the that script of
> icu4c, which is what is failing when dependencies are being addressed after
> I run brew install gnuradio:
>
> Downloading https://fossies.org/linux/misc/icu4c-55_1-src.tgz
> #=#=-# #
> curl: (22) The requested URL returned error: 410 Gone
> Error: Failed to download resource "icu4c"
> Download failed: https://fossies.org/linux/misc/icu4c-55_1-src.tgz
>
> What is valid is "icu4c-65_1-src.tgz" at the same address (instead of
> 55_1).  How can I find the script and run it locally after editing it?  I
> also downloaded the icu4c-55 file from a valid link and installed it
> manually, but the brew install gnuradio process apparently does not see
> this installation and goes ahead with the outdated https request.
>
> Is there a way I can alter my host file so that when it looks in the wrong
> place for the 55 version, I can point it to a new place for the 55 version?
>
> This is an old iMac9,1 on 10.6.8 which i am trying also to upgrade to
> 10.15, but that is a slow process and in the meantime i want to see if I
> can complete gnuradio so that I can play with my new rtl-sdr dongle.
>
> I googled for this problem and did not find anything.
>
> thanks...
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Stream args on UHD USRP Sink

[Michael Dickens]

Hi Glen - GR38 provides compatibility with Py27, so your old code should
still work there ... once the GR37 specific parts are update to what GR38
requires. From a Python perspective, it should still work. We'd recommend
creating a "maint-3.7" branch (or something that makes it clear that the
branch is for GR37), and then moving "master" to use GR38. Of course, GR39
will remove Py27 compatibility, so we advise everyone doing GR development
to update to Py3 code ... Py36 would be good enough, Py37 would be better!
Py38 is a little too young still to recommend long term moving to it, but
as of yet it seems to work out of the box with GR and UHD and Volk and
related projects. Hope this is useful! - MLD

On Tue, Dec 3, 2019 at 12:31 PM Glen Langston 
wrote:

> Hi
>
> This is a general question about upgrade to python 3 and gnu radio 3.8.
>
> We’ve got some custom C++ and Python code that will need to be installed.
> The python ran in version 2.7.  This is working with gnuradio companion
> 3.7.13.4
>
> How difficult a task is upgrading?  A day/week/month?
>
> Thanks again for all your guidance and help,
>
> Glen
>
> The code is modest in size, I’d say.   Is there a way of keeping
> backward compatibility to 2.7?   Should I create a whole new
> archive for python 3?
>
> ie we’re using
>
> www.github.com/WVURAIL/gr-radio_astro
>
> so should I make
>
> gr-radio_astro3
>
> ?
>
-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: More on C++11 requirements

[Michael Dickens]

That should work. Which version of cmake are you using?

On Mon, Nov 25, 2019 at 4:16 PM Marcus D. Leech 
wrote:

> On 11/25/2019 03:28 PM, Andrej Rode wrote:
> > Out of curiosity, what's your GCC version?
> > There might be a problem with CMake not detecting C++11 support
> > correctly/your version GCC is not fully C++11 compliant. (I know,
> > crazy).
> >
> > Cheers
> > Andrej
> >
> >
> gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
>
>
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: More on C++11 requirements

[Michael Dickens]

If setting `CMAKE_CXX_STANDARD` doesn't work to get `-std=c++11` or
`-std=gnu++11` into the CXX_FLAGS, then maybe the version of CMake is <
3.1.0?

The variable `CMAKE_CXX_STANDARD` was added to CMake in the capacity of
setting (e.g.) `-std=c++11` as of CMake 3.1.0. The code would be something
like:
{{{
# If cmake version is < 3.1, explicitly set C/C++ standard to use;
# this CMake doesn't internally use CMAKE_C*_STANDARD variables.

IF(${CMAKE_VERSION} VERSION_LESS 3.1)
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c${CMAKE_C_STANDARD}")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++${CMAKE_CXX_STANDARD}")
ENDIF()
}}}

Worth a try! - MLD

On Sun, Nov 24, 2019 at 5:22 PM Marcus D. Leech 
wrote:

> Playing with a project (gr-radio_astro from WVURAIL:
> https://github.com/WVURAIL/gr-radio_astro), and running into compile
> issues on
> older OS (Fedora 20 in this case).
>
> Now, the interesting thing is that my GCC appears to have support for
> c++11  (since -std=c++11 works as a command arg), and despite the
>fact that the CMakelists.txt file for the project includes:
>
> 
> # Compiler specific setup
> 
> if(CMAKE_COMPILER_IS_GNUCXX AND NOT WIN32)
>  #http://gcc.gnu.org/wiki/Visibility
>  add_definitions(-fvisibility=hidden)
>  set(CMAKE_CXX_STANDARD 11)
> endif()
>
> There doesn't appear to be any use of -std=c++11   in the Make files
> generated, and one gets compile errors for source that includes
>C++11 features/syntax.
>
> Are there extra "sets" in the CMakeLists.txt that I should be using to
> force it to use the c++11 compiler options?
>
> Cheers

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: PlutoSDR & Mac - iio block issues??

[Michael Dickens]

Hi Glen - Yes, all of this can be fixed in the "cmake .." step. That's what
we do in MacPorts to get all of the files installed in the correct
locations (using CMAKE_INSTALL_PREFIX=/opt/local by default; but also using
other cmake variables to set other install locations to be not the default
too, since MacPorts has expectations for where certain files types are
installed). This issue has nothing directly to do with the link provided
about site-packages and dist-packages. It's all about putting PYTHON files
where the version of Python used by GNU Radio will find the GR OOT scripts.
We provide the cmake variable `GR_PYTHON_DIR` for the top-level directory
to install PYTHON files. Generally, GR-proper PYTHON files will be
installed into "`GR_PYTHON_DIR`/gnuradio" ... most GR OOTs install into
"`GR_PYTHON_DIR`/OOT" though I believe gr-osmosdr installs into
"`GR_PYTHON_DIR`/gnuradio/osmosdr" by default (which, to be honest, I
prefer). If you install a GR OOT elsewhere, you can use the PYTHONPATH
environment variable to tell Python where to look for those scripts; this
is what "make test" does, at least nominally, so that we can "test" without
having to "install" first. Hope this is useful! - MLD

On Fri, Nov 15, 2019 at 9:51 AM Glen I Langston 
wrote:

> Thanks
> I’ll try that in the future.
> However I’m not sure why this is an issue in the first place.  It should
> be fixable at the cmake step.
>
> Looking at the link provided in an earlier email, it seems
> like part of the problem is the different uses of
> site-packages and
> dist-packages.
>
> Can that be fixed at the cmake step?
>
> Thanks again,
> Glen
>
> > On Nov 15, 2019, at 9:37 AM, Michael Dickens 
> wrote:
> >
> > You need to set
> > {{{
> > PYTHONPATH=/usr/local/lib/python2.7/site-packages/:$PYTHONPATH
> > }}}
> > to get access to gr-iio.
> >
> >
> > On Fri, Nov 15, 2019 at 8:17 AM Kevin Wheatley 
> wrote:
> > New here and new to gnuRadio...
> >
> > I'm attempting to get plutoSDR up and running on a Mac, I've installed
> gunradio and dependencies, I've also downloaded and built libiio,
> ibad9361-iio and gr-iio. Following this I've moved the block files across
> to the working directory. Running gnuradio-companion
> > I can see the plutoSDR source & sink blocks, but when using them I get
> the following error:
> >
> > Traceback (most recent call last):
> >   File "/Users/m0khz/Desktop/top_block.py", line 22, in 
> > from gnuradio import iio
> > ImportError: cannot import name iio
> >
> > any help in where I'm going wrong much appreciated 
> >
> > Cheers Kevin
> >
> > Full build details below:
> > Install GNU Radio
> >
> > Kevins-MacBook-Pro:~ m0khz$ sudo port install gnuradio
> > --->  Computing dependencies for gnuradio
> > --->  Cleaning gnuradio
> > --->  Scanning binaries for linking errors
> > --->  No broken files found.
> > --->  No broken ports found.
> > Kevins-MacBook-Pro:~ m0khz$
> > Kevins-MacBook-Pro:~ m0khz$ gnuradio-config-info --version
> > 3.7.13.5
> >
> > Download and build libiio
> >
> > Kevins-MacBook-Pro:~ m0khz$ cd libiio
> > Kevins-MacBook-Pro:libiio m0khz$ cmake .
> > -- Looking for libusb-1.0 : Found
> > -- Check for case-sensitive file systems
> > -- File system is not case-sensitive
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /Users/m0khz/libiio
> > Kevins-MacBook-Pro:libiio m0khz$ make
> > [ 48%] Built target iio
> > [ 55%] Built target iio_genxml
> > [ 62%] Built target iio_adi_xflow_check
> > [ 68%] Built target iio_reg
> > [ 75%] Built target iio_readdev
> > [ 82%] Built target iio_writedev
> > [ 89%] Built target iio_attr
> > [ 96%] Built target iio_info
> > [100%] Built target libiio-pkg
> > [100%] Built target libiio-py
> > Kevins-MacBook-Pro:libiio m0khz$ sudo make install
> > [ 48%] Built target iio
> > [ 55%] Built target iio_genxml
> > [ 62%] Built target iio_adi_xflow_check
> > [ 68%] Built target iio_reg
> > [ 75%] Built target iio_readdev
> > [ 82%] Built target iio_writedev
> > [ 89%] Built target iio_attr
> > [ 96%] Built target iio_info
> > [100%] Built target libiio-pkg
> > [100%] Built target libiio-py
> > Install the project...
> > -- Install configuration: "RelWithDebInfo"
> > installer: Package name is Libiio
> > installer: Upgrading at base path /
> > installer: The upgrade was successful.
> > Kevins-MacBook-Pro:libiio m0khz$ cd ..
&g

Re: PlutoSDR & Mac - iio block issues??

[Michael Dickens]

One final reply: You used MacPorts to install GNU Radio ... so why not use
it to install all of the IIO stuff? "port search iio" should come back with:
{{{
gr-iio @20190725-9088ac79_1 (science, comms)
Provides augmented functionality for GNU Radio: IIO device source

libad9361-iio @20190910 (science, comms)
libad9361-iio is an IIO AD9361 library for filter design and handling,
multi-chip sync, and more

libiio @0.18_1 (science, comms)
libiio is used to interface to the Industrial Input/Output (IIO)
Subsystem

libiio-devel @20191104-c9a854f8 (science, comms)
libiio is used to interface to the Industrial Input/Output (IIO)
Subsystem
}}}
The GR ports are for GR37 still; we're working on updating everything to be
installable for GR37 and GR38 ... and, where possible, GR39-beta. - MLD

Re: PlutoSDR & Mac - iio block issues??

[Michael Dickens]

I -strongly- recommend against setting the CMAKE_INSTALL_PREFIX to a system
directory such as /usr when you are building from source (not using a
package manager)! You never know what you're going to overwrite from the
system itself, which can cause library loading breakage. When installing
anything from source, use a "local" directory of some sort ... /usr/local
is perfectly fine! Then, set environment variables to find the installed
stuff: PATH, PYTHONPATH, PKG_CONFIG_PATH, MANPATH, INFOPATH, etc... That
said, on OSX just please don't set DYLD_LIBRARY_PATH except for temporarily
for testing purposes; doing so can really mess up application execution! My
US$0.02 worth ... - MLD

On Fri, Nov 15, 2019 at 8:42 AM Glen I Langston 
wrote:

> Hi Kevin,
>
> I’ve run into this too.
>
> The instructions tell you the solution after the build commands
>
> change the “cmake” line to
> cmake -DCMAKE_INSTALL_PREFIX=/usr .
> and rebuild all
>
> and do the copy step they suggest on site
>
> https://wiki.analog.com/resources/tools-software/linux-software/gnuradio
> (Either
> cp -r /usr/local/lib/python2.7/dist-packages/gnuradio/iio
> /usr/lib/python2.7/dist-packages/gnuradio/
> or
> cp -r /usr/local/lib/python2.7/site-packages/gnuradio/iio
> /usr/lib/python2.7/site-packages/gnuradio/
> or
> some similar combination, depending on where your build files end up after
> install
> )
>
> Good luck.
>
> Glen
>
> The packages can go into 4 different directories  (on Ubuntu, maybe only 2
> on mac)
>
> /usr/local/lib/python2.7/site-packages
> /usr/lib/python2.7/site-packages
>
> and
>
> /usr/local/lib/python2.7/dist-packages
> /usr/lib/python2.7/dist-packages
>
> on Ubuntu
>
> I’ve been copying all of the "site-packages" stuff into “dist-packages”
> and creating symbolic link from dist-packages to site-packages.
>
> (Not really recommended, but I do it anyway).
>
> Good Luck
>
-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: PlutoSDR & Mac - iio block issues??

[Michael Dickens]

_swig.py
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/iio_pluto_sink_swig.pyc
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/iio_pluto_sink_swig.pyo
> -- Up-to-date: /usr/local/include/swig/iio_swig.i
> -- Up-to-date: /usr/local/include/swig/iio_pluto_source_swig.i
> -- Up-to-date: /usr/local/include/swig/iio_pluto_sink_swig.i
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/__init__.py
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/attr_updater.py
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/__init__.pyc
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/attr_updater.pyc
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/__init__.pyo
> -- Up-to-date:
> /usr/local/lib/python2.7/site-packages/gnuradio/iio/attr_updater.pyo
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_device_source.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_device_sink.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_fmcomms2_source.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_fmcomms2_sink.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_fmcomms5_source.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_fmcomms5_sink.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_pluto_source.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_pluto_sink.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_math.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_math_gen.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_power_ff.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_modulo_ff.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_modulo_const_ff.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_attr_sink.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_attr_source.xml
> -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/iio_attr_updater.xml
> Kevins-MacBook-Pro:gr-iio m0khz$ cd ..
> Kevins-MacBook-Pro:~ m0khz$
>
> move the blocks between the necessary folders:
>
> cp -r /usr/local/lib/python2.7/dist-packages/gnuradio/iio
> /usr/lib/python2.7/dist-packages/gnuradio/
>
> This is where gnuRadio Companion is looking
> /opt/local/share/gnuradio/grc/blocks
>
> This is where the block were installed
> /usr/local/share/gnuradio/grc/blocks/
>
> So copied them across
>
> Run gnuRadio-companion, IIO blocks are present, plutoSDR source and sink
> etc. are present, but get this error when tying to run the flow graph:
>
> <<< Welcome to GNU Radio Companion 3.7.13.5 >>>
>
> Block paths:
> /opt/local/share/gnuradio/grc/blocks
>
> Loading: "/Users/m0khz/Desktop/pluto_initial_test.grc"
> >>> Done
>
> Generating: '/Users/m0khz/Desktop/top_block.py'
>
> Generating: '/Users/m0khz/Desktop/top_block.py'
>
> Executing:
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
> -u /Users/m0khz/Desktop/top_block.py
>
> Traceback (most recent call last):
>   File "/Users/m0khz/Desktop/top_block.py", line 22, in 
> from gnuradio import iio
> ImportError: cannot import name iio
>
> >>> Done (return code 1)
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Simulated time ?

[Michael Dickens]

Hi GD - GNU Radio doesn't implement simulated time in runtime in any direct
way. If you enable performance counters, assuming that feature still builds
and functions, you might be able to get info on timing -- for example
latencies and throughput; maybe more, I don't recall all the info PC
provides access to.

The only blocks with a knowledge of time are a few sources & sinks (e.g.,
gr-uhd using timed Tx packets), and the "throttle" block. There are
probably some GR OOT modules that have blocks with knowledge of time, too.
I don't know of any GR OOT project that tries to augment GR with more
specific knowledge of time, such as implement simulated time.

Hope this is useful! - MLD

On Wed, Nov 13, 2019 at 8:40 AM Guy Durrieu  wrote:

> Hello list !
>
> In GNU Radio, does it exist a mean, for a logical module which needs it,
> to get during a simulation the current simulated time (e.g. in order to
> calculate the delay between message arrivals) ? I was not able to find
> out something like that in the doc...
>
> Thanks in advance for your help !
>
> Regards.
>
> -- GD.
>
> Guy Durrieu
> ONERA - Département Traitement de l'Information et Systèmes
> CEntRe de Toulouse, 2, avenue Edouard Belin BP 74025 31055 TOULOUSE CEDEX 4
> Tél. +33 5 62 25 26 59
> avertissement http://www.onera.fr/onera-en/emails-terms
>
>
>
>
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Buffer sizes for UDPSink, UDPSource?

[Michael Dickens]

Hi Jeff - I know of no inherent limitation on UDP I/O sizes, but especially
at the small payload sizes you note, regardless of OS. I think the best way
forward here is to share your flowgraphs with me (off list) & I'll see if I
can replicate the issue (I'm still running Mojave, but again I don't think
the OS is making the difference here). - MLD

On Fri, Nov 8, 2019 at 6:19 PM Jeff Kyser  wrote:

> Hi,
>
> I’m running gnuradio v3.7.13.5 under macOS Catalina.
>
> We’ve set up transmit and receive flow graphs for a simple BPSK system.
>
> We pass UDP messages which are received by a UDPSource at the start of the
> Rx flow graph, modulation is performed, and the carrier and symbols are
> sent to the Tx flow graph via a UDPSink.
>
> The Tx flow graph receives the data in a UDPSource, performs the
> demodulation, and outputs an assembled message from the bytes.
>
> When I send smaller messages, less than 256 bytes in original length, they
> pass through both flow graphs just fine, and we receive exactly what we
> sent.
>
> When I send larger messages, above 256 bytes (actually, they’re about 430
> bytes), they don’t make it out of the UDPSource on the front end of the Rx
> flow graph.
>
> I’ve placed a file sink just before sending the complex data, and one just
> after receiving.
>
> The actual amount of data going across the UDP Sink —> Source is quite
> large - a single 180 byte message results in about 700K of complex data.
>
> But the larger messages never get finished.
>
> I’ve set the payload size on the UDPSource and UDPSink to 1024, and
> there’s been no problem with the smaller messages.
>
> Is there some kind of buffer overrun going on? When we send the 430 byte
> message, it expands to about 1.4 MB of data, which is all captured on the
> send side of the interface in the file, but on the receive side, there’s
> always only about 1.35 MB, which amounts to about 420 characters.
>
> Any ideas on this?
>
> Thank in advance!
>
> -Jeff
>
>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Cannot compile and build a QTGUI OOT eye_sink

[Michael Dickens]

-get update
> On Fri, 2019-11-08 at 14:38 +0100, Christophe Seguinot wrote:
> > Dear all
> >
> > I working under ubuntu 18.04 and GNURadio 3.7.11 and attempt to define a
> > QTGUI eye_sink block to display eye pattern under gnuradio-companion.
> > Without any knowledge of the best method to achieve this, I decided to:
> > 1- define a new OOT module using gr_modtool
> >  gr_modtool newmod csqtgui
> >  cd gr-csqtgui/
> >  gr_modtool add -t sink -l cpp eye_sink_c
> >  gr_modtool add -t sink -l cpp eye_sink_f
> > 2- insert in this module the gnuradio C code related to the original
> > time_sink
> >  see my code on github https://github.com/ChristopheSeg/eye_sink
> > 3- try to compile and install this OOT (at this step it should be a
> > duplicate of the time-sink block)
> >  mdkir build
> >  cd build
> >  cmake ../
> >  qmake ../
> >  make
> > 4- modify oot code to implement an eye-pattern plot
> >
> > But I'm stuck at step 3, unable to compile my OOT. (I succesfully tested
> > the square_ff OOT module proposed in OOT tutorial 2)
> >
> > if I use csqtgui namespace in files eye_sinc_*.h eye_sink_*_impl.cc
> > eye_sink_*_impl.h: no .o object file are generated
> >  namespace gr {
> >namespace csqtgui {
> >
> > the error is than
> >   In file included from ../lib/eye_sink_c_impl.h:25:0,
> >   from ../lib/eye_sink_c_impl.cc:26:
> > ../../gr-csqtgui/include/csqtgui/eye_sink_c.h:145:37: error:
> > ‘trigger_mode’ has not been declared
> > virtual void set_trigger_mode(trigger_mode mode, trigger_slope
> > slope,
> >
> > When using sqtgui namespace in those files
> >
> > namespace gr {
> >namespace qtgui {
> >
> > all .cc files object are created , but cmake fails with a lot of
> > undefined reference to : DisplayForm::, gr::block::, boost, CppUnit,
> pmt
> >
> > the error is than
> >
> > g++ -m64 -Wl,-O1 -o gr-csqtgui eye_sink_c_impl.o eye_sink_f_impl.o
> > qa_csqtgui.o qa_eye_sink_c.o qa_eye_sink_f.o test_csqtgui.o
> > -L/usr/lib/x86_64-linux-gnu -lQtDeclarative -lQtGui -lQtCore -lpthread
> > eye_sink_c_impl.o: In function
> > `gr::qtgui::eye_sink_c_impl::set_update_time(double)':
> > eye_sink_c_impl.cc:(.text+0xc4): undefined reference to
> > `DisplayForm::setUpdateTime(double)'
> >
> > I already modified my CMakelists.txt to include corresponding libraries
> > without any success
> >  set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS QTGUI PMT VOLK)
> >  find_package(Gnuradio "3.7.2" REQUIRED)
> >
> > I tried to add -lgnuradio-blocks -lgnuradio-runtime -lgnuradio-qtgui
> > -lgnuradio-pmt in the last g++ command for testing but get the same
> errors
> >
> > I didn't find any usefull help in GNURadio OOT pages, nor in other OOT
> > modules published on CGRAN.
> > Who could please tell me what is wrong in my method?
> >
> > Regards, Christophe
> >
> >
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: [EXTERNAL] Re: Using function from OOT in another OOT

[Michael Dickens]

That CMake code reads nicely; a little more verbose than desirable, but
whatever works as it's an OOT & not GR proper. You -might- be able to do
"find_package(gnuradio-myoot)" ... might work or not depending on whether
.cmake and/or .pc file were installed by the OOT.

Wouldn't it be nice if you could instead just do "find_package(gnuradio
COMPONENTS runtime myoot)" and then various return variables would be set
that you could use for the includes and linking? There's an open request
for something like this from, I believe, Mait. I don't think it's made
progress, but it's something I'd love to see! It would mean, of course,
than you can have only 1 version of "myoot" installed at a time. IMHO a
small price to pay for the convenience!

Food for thought... - MLD

On Tue, Nov 5, 2019 at 4:02 PM Morman, Joshua 
wrote:

> Michael,
>
>
> Thank you for the response.  Here is what I ended up doing:
>
>
> If I have gr-myoot that I want to reference from gr-anotheroot
>
>
> In gr-anotheroot/cmake/modules, create FindMyoot.cmake, which should look
> something like:
>
>
> 
>
> find_package(PkgConfig)
> pkg_check_modules(PC_GNURADIO_RUNTIME gnuradio-runtime)
>
> find_path(MYOOT_INCLUDE_DIR myoot/one_of_the_header_files.h
>   HINTS ${PC_GNURADIO_RUNTIME_INCLUDEDIR}
> ${PC_GNURADIO_RUNTIME_INCLUDE_DIRS}
>   PATH_SUFFIXES myoot )
>
> find_library(MYOOT_LIBRARY NAMES gnuradio-myoot
>  HINTS ${PC_GNURADIO_RUNTIME_LIBDIR}
> ${PC_GNURADIO_RUNTIME_LIBRARY_DIRS} )
>
> include(FindPackageHandleStandardArgs)
> # handle the QUIETLY and REQUIRED arguments and set MYOOT_FOUND to TRUE
> # if all listed variables are TRUE
> find_package_handle_standard_args(Myoot  DEFAULT_MSG
>   MYOOT_LIBRARY MYOOT_INCLUDE_DIR)
>
> mark_as_advanced(MYOOT_INCLUDE_DIR MYOOT_LIBRARY )
>
> set(MYOOT_LIBRARIES ${MYOOT_LIBRARY} )
> set(MYOOT_INCLUDE_DIRS ${MYOOT_INCLUDE_DIR} )
> 
>
> I'm sure there are better ways to do this, but this did the trick quick
> and dirty.  It looks like some other oots have .pc files installed which
> help with the process, but that doesn't look to be standard.
>
>
>
> Josh
>
> --
> *From:* Michael Dickens 
> *Sent:* Tuesday, November 5, 2019 2:14 PM
> *To:* Morman, Joshua
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* [EXTERNAL] Re: Using function from OOT in another OOT
>
> Hi Josh - I don't think there's a standard way to do this. -Most- OOTs
> install cmake scripts that can be used to "find" them, if you can determine
> the correct "find" name (might be "gr-OOT" or just "OOT", where 'OOT' is
> the name of the OOT module). Once found, you can then use either the target
> or returned variables (OOT_INCLUDE_DIRS, OOT_LIBRARIES most likely) to find
> the API and link against the ABI. Nothing special, but generic enough that
> it should work on different OSs & GR installs. Hope this is useful! - MLD
>
> On Tue, Nov 5, 2019 at 1:42 PM Morman, Joshua 
> wrote:
>
>> Is there a prescribed method for including functions from one OOT in
>> another OOT (c++ code)?
>>
>>
>> I could probably figure out how to do it in cmake, but is there some
>> magical cmake find functions that already exist for OOTs to set the
>> INCLUDE and LIBRARY variables relative to the GR prefix installation?
>>
>>
>> Thanks,
>>
>> Josh
>>
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/ [ettus.com]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ettus.com_=DwMFaQ=YC-d702opsuYKpiO2Bmlzg=-OttVOCFItYdAESKCAf54UYYCHv8xssKxCxab-nx5UA=Ef8z0W0VV0FJhO2Gi19L14SAnThIphzjnqAAgdGLv5k=2fWh96T2ZIoLHJl2x4asongRKo1Yc2zpJZUxPNTtzfc=>
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: UHD and FPGA version mismatch ERROR

[Michael Dickens]

Hi Bisma - This query is not really about GR, but rather about UHD / USRP.
Please direct it to the USRP email list <
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >.
Thanks! - MLD

On Tue, Nov 5, 2019 at 7:14 AM Bisma Amjad  wrote:

> Hi there,
> I have attached a report of the issue I am facing while installing GNU
> Radio and UHD for USRP E320 on UBUNTU.
>
> I'd be grateful if you can help me through this issue.
>
> Thank you.
>
> Regards,
> Bisma
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Using function from OOT in another OOT

[Michael Dickens]

Hi Josh - I don't think there's a standard way to do this. -Most- OOTs
install cmake scripts that can be used to "find" them, if you can determine
the correct "find" name (might be "gr-OOT" or just "OOT", where 'OOT' is
the name of the OOT module). Once found, you can then use either the target
or returned variables (OOT_INCLUDE_DIRS, OOT_LIBRARIES most likely) to find
the API and link against the ABI. Nothing special, but generic enough that
it should work on different OSs & GR installs. Hope this is useful! - MLD

On Tue, Nov 5, 2019 at 1:42 PM Morman, Joshua 
wrote:

> Is there a prescribed method for including functions from one OOT in
> another OOT (c++ code)?
>
>
> I could probably figure out how to do it in cmake, but is there some
> magical cmake find functions that already exist for OOTs to set the
> INCLUDE and LIBRARY variables relative to the GR prefix installation?
>
>
> Thanks,
>
> Josh
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: switching its frequency (hopping) when it decode the message(matches password)

[Michael Dickens]

Hi Madhuri - Please keep this discussion on the GR discussion list where it
started: more people reading it increases the chances of someone providing
help!

Nobody here is going to provide you with the programs as you describe. This
email discussion group is, broadly, about providing advice ... you have to
do the actual work & ask specific enough questions to get
reasonable feedback. You've provided some specifics now, and the best
advice I can give is the following:

If you look through GNU Radio examples, both from GR itself as well as "out
of tree" (OOT) modules, you'll find some interesting GRC flowgraphs. None
will do -everything- that you're looking out of the box, but you can piece
together enough from various places to do what you want, plus or minus.

Cheers! - MLD

On Tue, Oct 29, 2019 at 11:26 AM Madhuri Gummineni <
madhuri.vijay2...@gmail.com> wrote:

> Dear sir,
> i have USRPN210 (UBX Daughterboard ) transceiver .
> If  i (from one usrp)send any message say  password is -23
> on the otherside the other  usrp  should decode it and verify it. if it is
> 23 then it has to hop from f1(96Mhz) to f2(98Mhz)
>
> Therefore it requires two programs
> TX side-grc flowgraph for sending message
> program on RX side
> 1) grc hopping flowgraph for Hopping
> 2) grc flowgraph  for decoding (for password verification)
> 3)connecting 1) and 2) to implement it.
>  Sir remaining parameters BW-75K, modulation -PSK .
> please guide me sir
>
> Thank you sir
>
-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: switching its frequency (hopping) when it decode the message(matches password)

[Michael Dickens]

Hi Madhuri - Your question is -very- open ended ... there are plenty of
ways to implement such a system ... much depends on specifications &
constraints that you haven't mentioned: limits on RF bandwidth? timing
constraints? what SDR HW capabilities? what CPU HW capabilities? what sort
of RF channels are you expecting? I'd recommend starting with some
practical DSP & SDR books to get started; there are lots here <
https://wiki.gnuradio.org/index.php/SuggestedReading >. If you can narrow
down your specifications / note specific constraints, we might be able to
provide some specific insights ... until then, you'll just get generalities
such as this reply. Hope this is useful! - MLD

On Tue, Oct 29, 2019 at 7:20 AM Madhuri Gummineni <
madhuri.vijay2...@gmail.com> wrote:

> hi,
> i am trying to write grc flow graph  to switch(hop) from one frequency to
> other if it detects  the password.
> if one usrp send a message as switch it should to other frequency.
> for this what are blocks that are required.
> planning like a remote operation to switch a sdr or usrp to switch or hop
> based on password.
> if one usrp send a message as password, then other usrp/sdr should hop if
> password is correct otherwise it will not hop
>  please help me sir
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Latency out of Stream Mux block with unequal input lengths

[Michael Dickens]

Hi Adam - Check out this presentation from GRCon19 <
https://www.gnuradio.org/grcon/grcon19/presentations/managing_latency/ >.
The basic issue is that the FIFO buffer between the source and next block
will fill up with data, so any change to the source value will be at the
end of the FIFO & require all of the data in the buffer to be read out
before that value comes up. The FIFO buffer with 50 items will be updated
more quickly ... as in 49:1 more quickly! Hope this is useful! - MLD

On Mon, Oct 28, 2019 at 9:49 AM Gannon, Adam M. (GRC-LCI0) <
adam.gan...@nasa.gov> wrote:

> Hi List,
>
> I'm trying to understand the latency behavior of the Stream Mux block when
> two streams of unequal lengths are being multiplexed together. Attached is
> a minimal flow graph that illustrates the point.
>
> In the example, two streams are multiplexed: one Vector Source of length
> 50 and one of length 1 whose value is adjusted while running. It takes
> several seconds at 1Msps for the change in the value of the shorter (L=1)
> stream to be reflected in the muxed stream. The reverse is not true - a
> change in the longer stream (L=50) is immediately reflected in the muxed
> stream. I believe this is because both Vector Sources are producing samples
> at the same rate but are being muxed at a ratio of 50:1. So when the value
> of the L=1 stream changes it has to empty the existing samples from its
> output buffer before the new samples start to be muxed.
>
> In my application, I am formatting data from an external source into the
> header of my packet. There are several stream multiplexers after that to
> form the packet (adding payload, trailer, etc). I'd like to minimize the
> latency before new data is reflected in the entire formatted packet. I was
> considering writing one block to create the entire packet, but wanted to
> ask for advice on if there is a better / more modular solution.
>
>
> Much appreciated,
> Adam
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: [Discuss-gnuradio] DARPA SC2 Team MarmotE modem is open sourced

[Michael Dickens]

Hi Miklos - Excellent! Thanks for sharing your work! - MLD

On Thu, Oct 17, 2019 at 9:02 PM Miklos Maroti  wrote:

> Dear Fellow GNURadio Users,
>
> We are happy to announce that we are open sourcing the MarmotE modem
> that we have developed for the DARPA Spectrum Collaboration Challenge
> under the GPLv3 license at https://gitlab.com/marmote/gr-marmote3.
> This is an FBMC based modem capable of using up to 40MHz of bandwidth
> with a good computer, but can be used with a simple laptop with lower
> sampling rates. There might be a few rough edges in the code base
> specifically tailored for the Colosseum and SC2 challenge, but we have
> created a simplified version of the modem that works with any USRP or
> other SDR. The code base has lots of interesting components, including
> good error correcting codes, SSE optimized fractional FBMC channelizer
> and synthesizer, variable length packets, multiple MCS settings, ARQ,
> TCP/UDP port based QoS settings, etc. We plan to write a manual, but
> till then enjoy the short README, the raw code and the flow graphs.
> Finally, please cheer for Team MarmotE on the DARPA SC2 championship
> event at MWC Los Angeles 2019, October 23.
>
> Best,
> Miklos
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

[Michael Dickens]

Yes: GR GIT master == GR38, which will require qwt6+qt5 of some
combination. I'm using Qwt 6.1.4 right now with Qt5 5.12.5. Works nicely. -
MLD

On Mon, Oct 21, 2019 at 10:30 AM Gisle Vanem  wrote:

> Michael Dickens wrote:
>
> > Hi Gisle - Which version of GR are you trying to build? GR37
> uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing
> > Qwt 6.1.4 should work, though I don't think I've tried it out yet. - MLD
>
> I use the 'master' at https://github.com/gnuradio/gnuradio.git
> Should be v3.8, no?
>
> But just switching to 'https://github.com/osakared/qwt.git'
> compiles fine. Although it fails at the link stage and the
> latest commit is 2,5 year old!
>
> I just don't get this package mess!
>
> --
> --gv
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Run time error of gr-ieee802-11 after grc upgrade (UHD?)

[Michael Dickens]

Hi Carlos - The issue is with the USRP source block. If you open up its
options in GRC, under the tab "FE Corrections", there are 2 entries (IQ
Balance and DC Offset), both of which are probably double quotes ("") ...
these should be Python booleans, so True or False depending on if you want
to use the option or not. Hopefully changing them to True or False will
take care of your issue. - MLD

On Sun, Oct 20, 2019 at 6:00 PM Carlos Velazquez 
wrote:

> I am running macOS 10.14.6 and grc 3.7.13.5.  After troubleshooting the
> missing variable error in gr-ieee802 after a macport update, I now have the
> following error:
>
> Traceback (most recent call last):
>   File “~/Documents/Research/gr-ieee802-11/examples/wifi_rx.py", line 380,
> in 
> main()
>   File “~/Documents/Research/gr-ieee802-11/examples/wifi_rx.py", line 368,
> in main
> tb = top_block_cls()
>   File “~/Documents/Research/gr-ieee802-11/examples/wifi_rx.py", line 152,
> in __init__
> self.uhd_usrp_source_0.set_auto_dc_offset("", 0)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
> line 3582, in set_auto_dc_offset
> return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
> type 'bool'
>
> The loopback block runs fine. It seems UHD may have changed? Anyone having
> the problem? I tried to upgrade gr to 3.8 but macports is only fetching 3.7
>
> v/r,
>
> Carlos
> _______
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using GNU Radio without running Python

[Michael Dickens]

Hi Molly - Looks / sounds like you're using GR37 ... yes? If you move to
using GR38, you can generate C++ code directly from GRC. You can do so on a
your host computer, then copy the resulting C++ code to your target
computer & compile it there -- assuming of course that you have GR38 and
any required GR OOT modules installed on the target computer. On your host
computer, you'd need Python to get GRC, but I think you can avoid SWIG if
you want to -- though since it's a host computer (& not the target) you
might as well install everything, just not use the GR Python interface
generated by SWIG. Does that make sense? Hope this is useful! - MLD

On Fri, Oct 18, 2019 at 10:26 AM Molly Erskine  wrote:

> Hello all!
>
> I am working on a project where I wish to generate sound wave samples to
> then pass these samples out to another program that will generate audio. I
> would like to be able to use the GRC to specify the shape and frequency of
> the sound wave, but have the output be accessible from an external C++
> program without having to run any Python (working with very limited memory
> and don't want to have both C++ and Python programs running at the same
> time, especially if communicating between the two using calls to shared
> memory).
>
> I have a hier block that I have generated from a flow graph using GRC. How
> can I execute this as a C++ program?
> - Is there a way to generate C++ instead of Python from GRC?
> - Would I instead be better using gr_modtool to generate a sample hier
> block and then coding it manually?
> - If that is the case, how would I go from this OOT module in C++ to an
> executable (ideally C++) program (without going back to the GRC and
> generating xml or a Python script from new flow graph containing the custom
> block).
>
> I'm new to working with GNU Radio so apologies if I am missing something
> obvious!
> The closest thing I could find to what I am looking for was this lecture:
> https://www.youtube.com/watch?v=JJ_OgduYXvs
> Which covers a project that allows the generation of executable files
> straight from GRC to C++ but unfortunately I cannot locate the source code
> online.
>
> If anything is unclear please let me know!
> Thanks in advance,
> Molly
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New GNU Radio 3.8 GUI Widgets

[Michael Dickens]

Very cool! FYI for folks wanting to find this GR OOT, here's the link: <
https://github.com/ghostop14/gr-guiextra >. Cheers! - MLD

On Sun, Oct 13, 2019 at 2:14 PM GhostOp14  wrote:

> Hi folks, just pushed a beta of a new OOT module set (gr-guiextra) for GR
> 3.8 on github.  Bringing more GUI widgets to the interface.  More to come
> but here's what's included so far:
>
> Dial - Think of this as your volume dial control.  Supports both variables
> and messages.
> Digital Number Control (Frequency Control) - Very similar to SDR-based
> stand-alone applications, clicking the numbers can adjust frequency, or it
> can be set in read-only mode for display only.  Supports both controlling a
> variable and input / output messages.
> LED Indicator - Just as it sounds.  On-screen LED.  You can choose the
> on/off colors and supports both variables and messages to control state.
> Linear Gauge (Progress Bar) - Linear progress bar / linear gauge, either
> horizontal or vertical.  Colors can be chosen for the background and the
> bar, and it is controllable via variable or message.
> Graphics Item - Drop a graphic anywhere in your GNU Radio app screen.  You
> can also control the file based on input messages to change the graphic on
> the fly.
> Toggle Button - Push to hold down.  Push again to release.  Both variables
> and messages available.
> Message-based Checkbox - Like a standard checkbox, but a message is
> produced on check / uncheck.
> Message Push-button - Produce a message when the button is pushed.  (This
> is different than the toggle in that this bounces back to release like a
> traditional button when pressed and a message is only produced on press).
> Compass - Provides an on-screen compass with 3 different choices for the
> needle (full, half, and -pi to pi with DoA uncertainty)
> App Background - While stylesheets can be used to change an app, that can
> be cumbersome if all you want is to change the background color or display
> a background graphic.  This drop-in control lets you do either or both.
> Distance "Radar" - Similar to the old-school signal trackers, this widget
> produces a radar-like screen and draws a "contact" circle at a distance of
> your choosing controlled by an inbound message.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ImportError: cannot import name usrp

[Michael Dickens]

Hi Laura - Try: "from gnuradio import uhd" ... not "import usrp" ... - MLD

On Fri, Oct 11, 2019 at 4:05 PM Laura Arjona  wrote:

> Hello,
>
> I am using a usrp b200-mini, and I am trying to define the sink as follows:
> *tx = usrp_sink_c(fusb_block_size = 1024, fusb_nblocks=8)*
>
> However, I get the error
>
> * from gnuradio import usrpImportError: cannot import name usrp*
>
> I believe my GNU-radio installation is correct.
> Any clue of how to fix this?
>
> Thank you.
>
> --
> *Laura Arjona *
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem instal Gnuradio in Mac OS

[Michael Dickens]

Hi Edmar - There are lots of possible reasons why JACK might not configure.
Without the build log, we'll never know! If you want some help, email me
directly / off list & I'll do what I can to help ... but only if
you include the noted build log ... ;) - MLD

On Sat, Oct 5, 2019 at 2:26 PM Edmar Candeia Gurjão 
wrote:

> Dear colleagues,
>
> I a installing Gnuradio  in MACOS High Sierre and I receives the message
> below. Dos anyone has experienced this problem?
>
> --->  Fetching archive for jack
>
> --->  Attempting to fetch jack-1.9.12_0.darwin_17.x86_64.tbz2 from
> https://packages.macports.org/jack
>
> --->  Attempting to fetch jack-1.9.12_0.darwin_17.x86_64.tbz2 from
> http://aus.us.packages.macports.org/macports/packages/jack
>
> --->  Attempting to fetch jack-1.9.12_0.darwin_17.x86_64.tbz2 from
> http://mse.uk.packages.macports.org/sites/packages.macports.org/jack
>
> --->  Configuring jack
>
> Error: Failed to configure jack: configure failure: command execution
> failed
>
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_jack/jack/main.log
> for details.
>
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>
> Error: Processing of port gnuradio failed
>
>
>
> --
> -
> Edmar Candeia Gurjão
> Universidade Federal de Campina Grande
> Unidade Acadêmica de Engenharia Elétrica
> http://sites.google.com/a/dee.ufcg.edu.br/ecandeia/
> http://www.dee.ufcg.edu.br/~pet
> Tel.: 83 - 3310 1403
> _______
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake fails when installing maint_3.7 branch on VM-Ubuntu 18.04

[Michael Dickens]

Ouch; that looks horrible! I'm guessing you have or tried to install GR38 &
are now trying to install GR37 ... there's some crufty files around that
are killing this cmake configuration! Or maybe your GIT branch checkout
isn't complete? Something really strange is going on there!

On Tue, Oct 1, 2019 at 3:58 PM Achilleas Anastasopoulos 
wrote:

> Understood. Thanks!
> So here is the actual output of cmake (in my previous email I also
> included the file CMakeOutput.log in case it provides more info):
>
> thanks again for all the help,
> Achilleas
>
> --
>
> anastas@raulubuntu:~/workarea-gnuradio/build_maint37$ cmake ../gnuradio/
> -- Build type not specified: defaulting to release.
> -- Build type set to Release.
> -- Extracting version information from git describe...
> CMake Deprecation Warning at CMakeLists.txt:73 (cmake_policy):
>  The OLD behavior for policy CMP0026 will be removed from a future version
>  of CMake.
>
>  The cmake-policies(7) manual explains that the OLD behaviors of all
>  policies are deprecated and that a policy should be set to OLD only under
>  specific short-term circumstances.  Projects should be ported to the NEW
>  behavior and not rely on setting a policy to OLD.
>
>
> CMake Error at CMakeLists.txt:182 (include):
>  include could not find load file:
>
>CMakeOverloads
>
>
> -- Compiler Version: cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> /usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> CMake Error at CMakeLists.txt:265 (include):
>  include could not find load file:
>
>GrPlatform
>
>
> -- ADDING PERF COUNTERS
> -- Building Static Libraries: OFF
> CMake Error: File /home/anastas/workarea-gnuradio/gnuradio/cmake/
> cmake_uninstall.cmake.in does not
> exist.
> CMake Error at CMakeLists.txt:337 (configure_file):
>  configure_file Problem configuring file
>
>
> -- Boost version: 1.65.1
> -- Found the following Boost libraries:
> --   date_time
> --   program_options
> --   filesystem
> --   system
> --   regex
> --   thread
> --   chrono
> --   atomic
> CMake Error at CMakeLists.txt:365 (include):
>  include could not find load file:
>
>GrComponent
>
>
> CMake Error at CMakeLists.txt:366 (GR_REGISTER_COMPONENT):
>  Unknown CMake command "GR_REGISTER_COMPONENT".
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeOutput.log".
> See also
> "/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeError.log".
>
> On Tue, Oct 1, 2019 at 3:35 PM Michael Dickens 
> wrote:
>
>> What I mean is you listed the CMakeError.log file. During cmake
>> configuration, it looks for how to do threading; some fail before cmake
>> finds one that works. Cmake documents these errors in this file, and these
>> errors are not abnormal ... they are just part of cmake doing its job.
>>
>> That said, cmake's normal output printouts and other logging are only as
>> good as it is programmed to do. GR does a pretty good job of showing what's
>> going on so that one can figure out the issues & then how to resolve them.
>> GR OOTs vary a lot in this regard.
>>
>> On Tue, Oct 1, 2019 at 3:25 PM Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Hi Michael,
>>>
>>> not sure what you mean by "these errors are normal?"
>>> I thought that gnuradio development at the 3.7 branch is beyond "normal
>>> errors" status...
>>>
>>> In any case, I also attach the CMakeOutput.log file in case this is more
>>> useful:
>>>
>>> Thanks again,
>>> Achilleas
>>>
>> --
>> Michael Dickens
>> Ettus Research Technical Support
>> Email: supp...@ettus.com
>> Web: https://ettus.com/
>>
>

-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake fails when installing maint_3.7 branch on VM-Ubuntu 18.04

[Michael Dickens]

What I mean is you listed the CMakeError.log file. During cmake
configuration, it looks for how to do threading; some fail before cmake
finds one that works. Cmake documents these errors in this file, and these
errors are not abnormal ... they are just part of cmake doing its job.

That said, cmake's normal output printouts and other logging are only as
good as it is programmed to do. GR does a pretty good job of showing what's
going on so that one can figure out the issues & then how to resolve them.
GR OOTs vary a lot in this regard.

On Tue, Oct 1, 2019 at 3:25 PM Achilleas Anastasopoulos 
wrote:

> Hi Michael,
>
> not sure what you mean by "these errors are normal?"
> I thought that gnuradio development at the 3.7 branch is beyond "normal
> errors" status...
>
> In any case, I also attach the CMakeOutput.log file in case this is more
> useful:
>
> Thanks again,
> Achilleas
>
-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake fails when installing maint_3.7 branch on VM-Ubuntu 18.04

[Michael Dickens]

Those errors are normal. Guessing there's info in the cmake output that's
more useful. - MLD

On Tue, Oct 1, 2019 at 3:03 PM Achilleas Anastasopoulos 
wrote:

> Hi all,
>
> I have the following issue trying a fresh installation on a VM-Ubuntu
> 18.04.
> After installing the dependencies etc from here:
> https://wiki.gnuradio.org/index.php/UbuntuInstall
>
> and after checking out the maint_3.7 branch the cmake fails with the
> following CMakeError.log file.
>
> Something tell me I am missing something obvious, but don't know what...
> This is the first time I see something like this.
>
> Any help is appreciated.
>
> best
> Achilleas
>
>
>
>
> ---
>
> Determining if the pthread_create exist failed with the following output:
> Change Dir:
> /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/bin/make" "cmTC_a2fc5/fast"
> /usr/bin/make -f CMakeFiles/cmTC_a2fc5.dir/build.make
> CMakeFiles/cmTC_a2fc5.dir/build
> make[1]: Entering directory
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Building C object CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o
> /usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized-o CMakeFi
> les/cmTC_a2fc5.dir/CheckSymbolExists.c.o   -c
> /home/anastas/workarea-gnuradio/build_maint37/CMakeF
> iles/CMakeTmp/CheckSymbolExists.c
> Linking C executable cmTC_a2fc5
> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a2fc5.dir/link.txt
> --verbose=1
> /usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized -rdynamic
> CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o  -o cmTC_a2fc5
> CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o: In function `main':
> CheckSymbolExists.c:(.text+0x1b): undefined reference to `pthread_create'
> collect2: error: ld returned 1 exit status
> CMakeFiles/cmTC_a2fc5.dir/build.make:97: recipe for target 'cmTC_a2fc5'
> failed
> make[1]: *** [cmTC_a2fc5] Error 1
> make[1]: Leaving directory
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Makefile:126: recipe for target 'cmTC_a2fc5/fast' failed
> make: *** [cmTC_a2fc5/fast] Error 2
>
> File
> /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
>
> /* */
> #include 
>
> int main(int argc, char** argv)
> {
>  (void)argv;
> #ifndef pthread_create
>  return ((int*)(_create))[argc];
> #else
>  (void)argc;
>  return 0;
> #endif
> }
>
> Determining if the function pthread_create exists in the pthreads failed
> with the following output
> :
> Change Dir:
> /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/bin/make" "cmTC_cfcc3/fast"
> /usr/bin/make -f CMakeFiles/cmTC_cfcc3.dir/build.make
> CMakeFiles/cmTC_cfcc3.dir/build
> make[1]: Entering directory
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Building C object CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o
> /usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized -DCHECK_FUNCT
> ION_EXISTS=pthread_create   -o
> CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o   -c /usr/share/c
> make-3.10/Modules/CheckFunctionExists.c
> Linking C executable cmTC_cfcc3
> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_cfcc3.dir/link.txt
> --verbose=1
> /usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized -DCHECK_FUNCTI
> ON_EXISTS=pthread_create-rdynamic
> CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o  -o cmTC_c
> fcc3 -lpthreads
> /usr/bin/ld: cannot find -lpthreads
> collect2: error: ld returned 1 exit status
> CMakeFiles/cmTC_cfcc3.dir/build.make:97: recipe for target 'cmTC_cfcc3'
> failed
> make[1]: *** [cmTC_cfcc3] Error 1
> make[1]: Leaving directory
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Makefile:126: recipe for target 'cmTC_cfcc3/fast' failed
> make: *** [cmTC_cfcc3/fast] Error 2
>
>
> -
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD / -lboost_system / pkg-config / Debian patch

[Michael Dickens]

Hi Harald - Mait & I talked about this issue during GRCon19 a few weeks
ago. I believe we came to the same conclusions as you note: A project that
does not otherwise require non-UHD library/ies should not have to know to
link against them (nor how). The linkage should be provided transparently
by CMake or pkgconfig or whatever: variables are returned from "find"ing
UHD that provides CFLAGS, CXXFLAGS, LDFLAGS, LIBRARIES, LIBRARY_DIRS,
INCLUDE_DIRS, and so forth. These variables can then be used as-is by the
calling project without having to know anything else about how the API or
ABI is built, installed, or used beyond these variables. The correct way to
do this varies depending on which "find" is used. For pkgconfig, using
"Requires.private" or "Requires" or just leaving the linkage as before the
patch ... any of those might work. But, yes, the bottom line is that the
patch you note isn't doing the right thing and needs to be either fixed or
removed. I'm leaving it to Mait to deal with this as he sees fit; I think
we'd all prefer this get done sooner rather than later. - MLD

On Mon, Sep 30, 2019 at 2:34 AM Harald Welte  wrote:

> Hi all,
>
> Ettus points at this mailing list as the official forum for raising UHD
> related questions.
>
> This mail is sent to seek input on a recent regression we are seeing when
> the official Debian UHD package removed "-lboost_system" from uhd.pc 'Libs'
> in the following patch:
> https://sources.debian.org/patches/uhd/3.14.1.0-2/fix-pkg-config/
>
> This results in (among probably other failures) the osmo-trx Debian package
> failing to build [1], and it has actually been scheduled for removal from
> debian
> due to this FTBFS (fail to build from source) [2].
>
> The related Debian bug report for uhd is at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940135
> where the Debian package maintainer A. Maitland Bottoms argues his case
> for why the removal of "-lboost_system" is correct.  I'm not sure if
> that patch has ever been submitted upstream or has been discussed here?
>
> I'm looking for some guidance from upstream UHD as to what is the correct
> course of action.
>
> From us as the application developers, it seems rather clear:
> An application program, like osmo-trx, which doesn't use boost directly,
> shouldn't
> have to manually add any boost related libraries to the linker command
> line.
>
> We are using UHD, and we're using pkg-config to tell us what kind of
> compiler flags and linker command line snippets we should use in order
> to link against uhd. It's not our responsibility to know about
> implementation details of UHD and what kind of libraries it may need
> in terms of its upstream dependencies.
>
> I'm not a pkg-config expert, but *if* Debian is right to remove
> -lboost_system from
> Libs, then maybe it simply needs to be added to Requires?  Both the
> 'Requires'
> and the 'Requires.private' lines are empty in libuhd-dev:amd63 3.14.1.0-2
>
> Thanks for any help in advance.
>
> Regards,
> Harald
>
> [1] https://osmocom.org/issues/4182
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974
>
> --
> - Harald Welte 
> http://laforge.gnumonks.org/
>
> 
> "Privacy in residential applications is a desirable marketing option."
>       (ETSI EN 300 175-7 Ch.
> A6)
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] undefined reference to `pthread_create' while pybombs installation

[Michael Dickens]

Yes, but PyBOMBS is using Py36, not Py27 ...

On Wed, Sep 25, 2019 at 3:00 PM sumit kumar  wrote:

> Hi Michael,
>
> Yes I tried installing numpy, but it is already there.
> Further, I deleted the build directory and ran pybombs again, but still it
> cannot find numpy!
> Did system reboot also.
> Even orc 0.4 is there but installer cannot find it.
>
> I got a fresh i9 CPU and GNU Radio doesn't install.
>
>
> ubadmin@ub-exotic02:~$ sudo apt install python-numpy
> [sudo] password for ubadmin:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> python-numpy is already the newest version (1:1.13.3-2ubuntu1).
> The following package was automatically installed and is no longer
> required:
>   libllvm7
> Use 'sudo apt autoremove' to remove it.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> ubadmin@ub-exotic02:~$ python
> Python 2.7.15+ (default, Jul  9 2019, 16:51:35)
> [GCC 7.4.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> >>>
>
> On Wed, 25 Sep 2019 at 20:50, Michael Dickens 
> wrote:
>
>> Hi Sumit - According to your last log, your install is missing NumPy.
>> Since PyBOMBS force-enabled GRC and not all dependencies were met, CMake
>> errored out. Clearly PyBOMBS didn't catch that dependency. Maybe just
>> install it manually and create an issue in PyBOMBS github noting it? - MLD
>>
>> On Wed, Sep 25, 2019 at 2:27 PM sumit kumar  wrote:
>>
>>> Attaching output of Configuration (which failed)
>>>
>>> On Wed, 25 Sep 2019 at 20:12, sumit kumar  wrote:
>>>
>>>> Hi,
>>>> I am getting undefined reference to `pthread_create' when I am
>>>> installing GNU Radio using pybombs. The desktop has fresh install of ubuntu
>>>> 18.04.
>>>> Error and Output log files are attached.
>>>> Regards
>>>> Sumit
>>>>
>>>
>>>
>>> --
>>> Sumit Kumar
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> --
>> Michael Dickens, Mac OS X Programmer
>>
>> Ettus Research Technical Support
>>
>> Email: supp...@ettus.com
>>
>> Web: http://www.ettus.com
>>
>
>
> --
> Sumit Kumar
>
>
>

-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] undefined reference to `pthread_create' while pybombs installation

[Michael Dickens]

Hi Sumit - According to your last log, your install is missing NumPy. Since
PyBOMBS force-enabled GRC and not all dependencies were met, CMake errored
out. Clearly PyBOMBS didn't catch that dependency. Maybe just install it
manually and create an issue in PyBOMBS github noting it? - MLD

On Wed, Sep 25, 2019 at 2:27 PM sumit kumar  wrote:

> Attaching output of Configuration (which failed)
>
> On Wed, 25 Sep 2019 at 20:12, sumit kumar  wrote:
>
>> Hi,
>> I am getting undefined reference to `pthread_create' when I am
>> installing GNU Radio using pybombs. The desktop has fresh install of ubuntu
>> 18.04.
>> Error and Output log files are attached.
>> Regards
>> Sumit
>>
>
>
> --
> Sumit Kumar
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PyGTKDeprecationWarning

[Michael Dickens]

HI Barrry - GRC uses PyGTK (version 3, to be specific). We use PyQt5 as
well as C++ Qt5 for the blocks. Hence when starting up GRC, you'll see GTK
warnings (and errors sometimes), but they don't seem to be harmful (at
least for now). - MLD

On Tue, Sep 24, 2019 at 10:30 PM Barry Duggan  wrote:

> Hi Michael,
>
> Looking at the subject line in my Inbox, it just struck me as strange:
> the warning is for PyGTK, and I thought we were using PyQt5. Is that
> part of the problem?
>
> ---
> Barry Duggan
>
>
> On 2019-09-24 14:53, Michael Dickens wrote:
> > Sounds good, Barry. I'll check out that issue once I see it come
> > through &
> > see if I can add anything useful to it. - MLD
> >
> > On Tue, Sep 24, 2019 at 2:20 PM Barry Duggan  wrote:
> >
> >> Hi Michael,
> >>
> >> I'm not familiar enough with that area to work on it, so I submitted
> >> issue "PyGTKDeprecationWarning #2813"
> >>
> >> ---
> >> Barry Duggan
> >>
> >>
> >> On 2019-09-24 10:09, Michael Dickens wrote:
> >> > Hi Barry - Short answer: probably yes, should be fixed. Longer answer:
> >> > The
> >> > likelihood and difficulty of fixing deprecated API depends mostly on
> >> > whether we can cleanly switch to the new API, or if we have to add in
> >> > some
> >> > "if" version checking logic to use the old API or new API. If we can
> >> > cleanly do so, then YES PLEASE let's do it! If the solution isn't
> clean
> >> > then it's worth opening a GR issue noting what's going on & why it's
> >> > not a
> >> > clean change & then we can get back to it in the future ... once maybe
> >> > it
> >> > will be a clean change. If you have the bandwidth right now to figure
> >> > out
> >> > what's going on, that would be great! Otherwise, I'd advise you to
> open
> >> > a
> >> > GR issue and provide what info you can there. Hope this is useful! -
> >> > MLD
> >> >
> >> > On Fri, Sep 20, 2019 at 9:10 PM Barry Duggan 
> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> When I load a new Embedded Python Block in a flowgraph, I get the
> >> >> following warnings. This is before I have made any changes to the
> >> >> code.
> >> >> GR 3.8-maint, GRC 3.9.
> >> >>
> >> >> ```
> >> >>
> /usr/local/lib/python3.7/dist-packages/gnuradio/grc/gui/Dialogs.py:362:
> >> >> PyGTKDeprecationWarning: Using positional arguments with the GObject
> >> >> constructor has been deprecated. Please specify keyword(s) for
> "title,
> >> >> parent, action, buttons" or use a class specific constructor. See:
> >> >> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> >> >>transient_for=parent
> >> >>
> /usr/local/lib/python3.7/dist-packages/gnuradio/grc/gui/Dialogs.py:362:
> >> >> PyGTKDeprecationWarning: The "buttons" argument must be a
> >> >> Gtk.ButtonsType enum value. Please use the "add_buttons" method for
> >> >> adding buttons. See:
> >> >> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> >> >>transient_for=parent
> >> >> /usr/lib/python3/dist-packages/gi/overrides/Gtk.py:571:
> >> >> PyGTKDeprecationWarning: The keyword(s) "parent" have been deprecated
> >> >> in
> >> >> favor of "transient_for" respectively. See:
> >> >> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> >> >>self._init(*args, **new_kwargs)
> >> >> ```
> >> >>
> >> >> Is this something that needs to be fixed?
> >> >>
> >> >> --
> >> >> Barry Duggan
> >> >>
> >> >> ___
> >> >> Discuss-gnuradio mailing list
> >> >> Discuss-gnuradio@gnu.org
> >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >> >>
> >> >
> >> >
> >> > --
> >> > Michael Dickens, Mac OS X Programmer
> >> >
> >> > Ettus Research Technical Support
> >> >
> >> > Email: supp...@ettus.com
> >> >
> >> > Web: http://www.ettus.com
> >>
> >
> >
> > --
> > Michael Dickens, Mac OS X Programmer
> >
> > Ettus Research Technical Support
> >
> > Email: supp...@ettus.com
> >
> > Web: http://www.ettus.com
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PyGTKDeprecationWarning

[Michael Dickens]

Sounds good, Barry. I'll check out that issue once I see it come through &
see if I can add anything useful to it. - MLD

On Tue, Sep 24, 2019 at 2:20 PM Barry Duggan  wrote:

> Hi Michael,
>
> I'm not familiar enough with that area to work on it, so I submitted
> issue "PyGTKDeprecationWarning #2813"
>
> ---
> Barry Duggan
>
>
> On 2019-09-24 10:09, Michael Dickens wrote:
> > Hi Barry - Short answer: probably yes, should be fixed. Longer answer:
> > The
> > likelihood and difficulty of fixing deprecated API depends mostly on
> > whether we can cleanly switch to the new API, or if we have to add in
> > some
> > "if" version checking logic to use the old API or new API. If we can
> > cleanly do so, then YES PLEASE let's do it! If the solution isn't clean
> > then it's worth opening a GR issue noting what's going on & why it's
> > not a
> > clean change & then we can get back to it in the future ... once maybe
> > it
> > will be a clean change. If you have the bandwidth right now to figure
> > out
> > what's going on, that would be great! Otherwise, I'd advise you to open
> > a
> > GR issue and provide what info you can there. Hope this is useful! -
> > MLD
> >
> > On Fri, Sep 20, 2019 at 9:10 PM Barry Duggan  wrote:
> >
> >> Hi,
> >>
> >> When I load a new Embedded Python Block in a flowgraph, I get the
> >> following warnings. This is before I have made any changes to the
> >> code.
> >> GR 3.8-maint, GRC 3.9.
> >>
> >> ```
> >> /usr/local/lib/python3.7/dist-packages/gnuradio/grc/gui/Dialogs.py:362:
> >> PyGTKDeprecationWarning: Using positional arguments with the GObject
> >> constructor has been deprecated. Please specify keyword(s) for "title,
> >> parent, action, buttons" or use a class specific constructor. See:
> >> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> >>transient_for=parent
> >> /usr/local/lib/python3.7/dist-packages/gnuradio/grc/gui/Dialogs.py:362:
> >> PyGTKDeprecationWarning: The "buttons" argument must be a
> >> Gtk.ButtonsType enum value. Please use the "add_buttons" method for
> >> adding buttons. See:
> >> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> >>transient_for=parent
> >> /usr/lib/python3/dist-packages/gi/overrides/Gtk.py:571:
> >> PyGTKDeprecationWarning: The keyword(s) "parent" have been deprecated
> >> in
> >> favor of "transient_for" respectively. See:
> >> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> >>self._init(*args, **new_kwargs)
> >> ```
> >>
> >> Is this something that needs to be fixed?
> >>
> >> --
> >> Barry Duggan
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> >
> > --
> > Michael Dickens, Mac OS X Programmer
> >
> > Ettus Research Technical Support
> >
> > Email: supp...@ettus.com
> >
> > Web: http://www.ettus.com
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PyGTKDeprecationWarning

[Michael Dickens]

Hi Barry - Short answer: probably yes, should be fixed. Longer answer: The
likelihood and difficulty of fixing deprecated API depends mostly on
whether we can cleanly switch to the new API, or if we have to add in some
"if" version checking logic to use the old API or new API. If we can
cleanly do so, then YES PLEASE let's do it! If the solution isn't clean
then it's worth opening a GR issue noting what's going on & why it's not a
clean change & then we can get back to it in the future ... once maybe it
will be a clean change. If you have the bandwidth right now to figure out
what's going on, that would be great! Otherwise, I'd advise you to open a
GR issue and provide what info you can there. Hope this is useful! - MLD

On Fri, Sep 20, 2019 at 9:10 PM Barry Duggan  wrote:

> Hi,
>
> When I load a new Embedded Python Block in a flowgraph, I get the
> following warnings. This is before I have made any changes to the code.
> GR 3.8-maint, GRC 3.9.
>
> ```
> /usr/local/lib/python3.7/dist-packages/gnuradio/grc/gui/Dialogs.py:362:
> PyGTKDeprecationWarning: Using positional arguments with the GObject
> constructor has been deprecated. Please specify keyword(s) for "title,
> parent, action, buttons" or use a class specific constructor. See:
> https://wiki.gnome.org/PyGObject/InitializerDeprecations
>transient_for=parent
> /usr/local/lib/python3.7/dist-packages/gnuradio/grc/gui/Dialogs.py:362:
> PyGTKDeprecationWarning: The "buttons" argument must be a
> Gtk.ButtonsType enum value. Please use the "add_buttons" method for
> adding buttons. See:
> https://wiki.gnome.org/PyGObject/InitializerDeprecations
>transient_for=parent
> /usr/lib/python3/dist-packages/gi/overrides/Gtk.py:571:
> PyGTKDeprecationWarning: The keyword(s) "parent" have been deprecated in
> favor of "transient_for" respectively. See:
> https://wiki.gnome.org/PyGObject/InitializerDeprecations
>self._init(*args, **new_kwargs)
> ```
>
> Is this something that needs to be fixed?
>
> --
> Barry Duggan
>
> ___________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to find out if device sink is finished writing samples to radio

[Michael Dickens]

There are plenty of stream-based blocks that require a certain number of
input samples to do processing (think FFT), and so if the number of input
samples can't be processed then the data won't be pushed through the FG.
Whether a FG will complete -- push through all data to completion -- really
depends on which blocks are in the FG, and how the blocks are programmed. -
MLD

On Tue, Sep 17, 2019 at 11:37 AM Adrian Musceac  wrote:

> Very useful! I found that my solution to the problem was to just let the
> FG drain by itself and just minimize latency elsewhere. That said... If a
> source stops pushing data into it, does it mean the samples still in the
> buffers in other blocks get processed, or do they get stuck there until new
> data pushes them out? To the best of my experimentation when I stop pushing
> data into a source, the FG doesn't keep processing until all buffers empty,
> but I may be wrong.
>
> Thanks again,
> Adrian
>
> On September 17, 2019 3:30:22 PM UTC, Michael Dickens <
> michael.dick...@ettus.com> wrote:
>>
>> Hi Adrian - To the best of my memory, there is no "flush" or the
>> equivalent for clearing buffers after the FG stops but still has residual
>> data in it. The best way is to tear the FG down & recreate it; buffers will
>> be "cleared" in this manner, but it is of course a "hammer" to get the job
>> done. That said, generally for data streaming a FG won't stop until all of
>> the data is pushed through. So if a block isn't somehow processing data,
>> then the FG just won't stop & you'll have to kill the FG anyway. I believe
>> that for PMT data packets, the FG will stop even if there is residual PMTs
>> waiting to be processed ... not 100% sure, but that's my memory ... because
>> the data transport is asynchronous & thus harder to track progress. In data
>> streaming it's easy to track progress. Hope this is useful! - MLD
>>
>> On Tue, Sep 17, 2019 at 3:45 AM Adrian Musceac 
>> wrote:
>>
>>> Thanks Michael, I think this is too complicated for my use case, so I'll
>>> find another way.
>>> Apart from this, is there any way to tell the top block to flush the
>>> samples still in it after you call stop() and wait()?
>>> I don't want those samples to be sent out after I call start() again.
>>> Many thanks,
>>>
>>> Adrian
>>>
>>> On September 16, 2019 6:23:52 PM UTC, Michael Dickens <
>>> michael.dick...@ettus.com> wrote:
>>>>
>>>> Hi Adrian - It's non-trivial to determine the state of the buffers from
>>>> inside blocks, but with the correct C++ class/type coercion it can be done
>>>> -- even if you're not supposed to do that. I don't recommend doing so, of
>>>> course. Thinking there will be a better way to do what you're hoping to do.
>>>> - MLD
>>>>
>>>> On Mon, Sep 16, 2019 at 11:41 AM Adrian Musceac 
>>>> wrote:
>>>>
>>>>> Hi Kevin,
>>>>> Thanks for the answer, unfortunately in my case I want to keep the
>>>>> flowgraph running and I'd need a way to check the state of the block
>>>>> buffers. Maybe I can do that with a custom block before the source or 
>>>>> maybe
>>>>> I should rethink my approach.
>>>>>
>>>>> Adrian
>>>>>
>>>>> On September 16, 2019 2:42:06 PM UTC, Kevin Reid 
>>>>> wrote:
>>>>>>
>>>>>> On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac 
>>>>>> wrote:
>>>>>>
>>>>>>> So far I haven't found a way (callback?) to tell when the last
>>>>>>> sample is out of the flowgraph. I am using the C++ API of GNU radio.
>>>>>>>
>>>>>>
>>>>>> The wait() method of a top_block will block the calling thread until
>>>>>> all items have passed through.
>>>>>>
>>>>>> Note that this will only succeed if your *source* blocks indicate
>>>>>> there are no more items, by returning -1 (gr::block::WORK_DONE).
>>>>>> Vector and file sources and other such standard fixed-length sources do,
>>>>>> but if your source is merely emitting no items at this time (e.g. a 
>>>>>> network
>>>>>> source that's not currently receiving packets) the flow graph will still 
>>>>>> be
>>>>>> running waiting for more. I do not know of a way to ask for "when all
>>>>>> buffers are currently empty", if that's what you need.
>>>>>>
>>>>> ___
>>>>> Discuss-gnuradio mailing list
>>>>> Discuss-gnuradio@gnu.org
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Dickens, Mac OS X Programmer
>>>>
>>>> Ettus Research Technical Support
>>>>
>>>> Email: supp...@ettus.com
>>>>
>>>> Web: http://www.ettus.com
>>>>
>>>
>>
>> --
>> Michael Dickens, Mac OS X Programmer
>>
>> Ettus Research Technical Support
>>
>> Email: supp...@ettus.com
>>
>> Web: http://www.ettus.com
>>
>

-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to find out if device sink is finished writing samples to radio

[Michael Dickens]

Hi Adrian - To the best of my memory, there is no "flush" or the equivalent
for clearing buffers after the FG stops but still has residual data in it.
The best way is to tear the FG down & recreate it; buffers will be
"cleared" in this manner, but it is of course a "hammer" to get the job
done. That said, generally for data streaming a FG won't stop until all of
the data is pushed through. So if a block isn't somehow processing data,
then the FG just won't stop & you'll have to kill the FG anyway. I believe
that for PMT data packets, the FG will stop even if there is residual PMTs
waiting to be processed ... not 100% sure, but that's my memory ... because
the data transport is asynchronous & thus harder to track progress. In data
streaming it's easy to track progress. Hope this is useful! - MLD

On Tue, Sep 17, 2019 at 3:45 AM Adrian Musceac  wrote:

> Thanks Michael, I think this is too complicated for my use case, so I'll
> find another way.
> Apart from this, is there any way to tell the top block to flush the
> samples still in it after you call stop() and wait()?
> I don't want those samples to be sent out after I call start() again.
> Many thanks,
>
> Adrian
>
> On September 16, 2019 6:23:52 PM UTC, Michael Dickens <
> michael.dick...@ettus.com> wrote:
>>
>> Hi Adrian - It's non-trivial to determine the state of the buffers from
>> inside blocks, but with the correct C++ class/type coercion it can be done
>> -- even if you're not supposed to do that. I don't recommend doing so, of
>> course. Thinking there will be a better way to do what you're hoping to do.
>> - MLD
>>
>> On Mon, Sep 16, 2019 at 11:41 AM Adrian Musceac 
>> wrote:
>>
>>> Hi Kevin,
>>> Thanks for the answer, unfortunately in my case I want to keep the
>>> flowgraph running and I'd need a way to check the state of the block
>>> buffers. Maybe I can do that with a custom block before the source or maybe
>>> I should rethink my approach.
>>>
>>> Adrian
>>>
>>> On September 16, 2019 2:42:06 PM UTC, Kevin Reid 
>>> wrote:
>>>>
>>>> On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac 
>>>> wrote:
>>>>
>>>>> So far I haven't found a way (callback?) to tell when the last sample
>>>>> is out of the flowgraph. I am using the C++ API of GNU radio.
>>>>>
>>>>
>>>> The wait() method of a top_block will block the calling thread until
>>>> all items have passed through.
>>>>
>>>> Note that this will only succeed if your *source* blocks indicate
>>>> there are no more items, by returning -1 (gr::block::WORK_DONE).
>>>> Vector and file sources and other such standard fixed-length sources do,
>>>> but if your source is merely emitting no items at this time (e.g. a network
>>>> source that's not currently receiving packets) the flow graph will still be
>>>> running waiting for more. I do not know of a way to ask for "when all
>>>> buffers are currently empty", if that's what you need.
>>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> --
>> Michael Dickens, Mac OS X Programmer
>>
>> Ettus Research Technical Support
>>
>> Email: supp...@ettus.com
>>
>> Web: http://www.ettus.com
>>
>

-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error with gnuradio 3.8 and python 3

[Michael Dickens]

Hi Mark - Interesting issue. Is SWIG/Python -not- enabled in your GR
install? Following the code, that could cause the error you're seeing. If
you look through the file
"/opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake",
line 37 will show whether ENABLE_PYTHON is enabled or not. - MLD

On Mon, Sep 16, 2019 at 2:57 PM Mark Koenig <
mark.koe...@iubelttechnologies.com> wrote:

> Hello,
>
>
>
> I am trying to build a module and I keep seeing the error below during
> cmake.  Any deas?
>
>
>
> #9 3.713 -- Found VOLK: Volk::volk
>
> #9 3.729 -- Checking for module 'thrift'
>
> #9 3.761 --   Found thrift, version 0.10.0
>
> #9 3.840 CMake Error at
> /opt/truearrow/6.3/lib/cmake/gnuradio/FindTHRIFT.cmake:68
> (GR_PYTHON_CHECK_MODULE):
>
> #9 3.840   Unknown CMake command "GR_PYTHON_CHECK_MODULE".
>
> #9 3.840 Call Stack (most recent call first):
>
> #9 3.840   /usr/share/cmake-3.10/Modules/CMakeFindDependencyMacro.cmake:48
> (find_package)
>
> #9 3.840
> /opt/truearrow/6.3/lib/cmake/gnuradio/gnuradio-runtimeConfig.cmake:24
> (find_dependency)
>
> #9 3.840   /opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake:45
> (include)
>
> #9 3.840   CMakeLists.txt:23 (find_package)
>
> #9 3.840
>
> #9 3.840
>
> #9 3.842 -- Configuring incomplete, errors occurred!
>
> #9 3.842 See also
> "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeOutput.log".
>
> #9 3.842 See also
> "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeError.log".
>
> #9 3.849 [ Build gr-vrt (Release) FAILED with error code 1 ]
>
>
>
>
>
> Thank you
>
>
>
> Mark
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to find out if device sink is finished writing samples to radio

[Michael Dickens]

Hi Adrian - It's non-trivial to determine the state of the buffers from
inside blocks, but with the correct C++ class/type coercion it can be done
-- even if you're not supposed to do that. I don't recommend doing so, of
course. Thinking there will be a better way to do what you're hoping to do.
- MLD

On Mon, Sep 16, 2019 at 11:41 AM Adrian Musceac  wrote:

> Hi Kevin,
> Thanks for the answer, unfortunately in my case I want to keep the
> flowgraph running and I'd need a way to check the state of the block
> buffers. Maybe I can do that with a custom block before the source or maybe
> I should rethink my approach.
>
> Adrian
>
> On September 16, 2019 2:42:06 PM UTC, Kevin Reid 
> wrote:
>>
>> On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac 
>> wrote:
>>
>>> So far I haven't found a way (callback?) to tell when the last sample is
>>> out of the flowgraph. I am using the C++ API of GNU radio.
>>>
>>
>> The wait() method of a top_block will block the calling thread until all
>> items have passed through.
>>
>> Note that this will only succeed if your *source* blocks indicate there
>> are no more items, by returning -1 (gr::block::WORK_DONE). Vector and
>> file sources and other such standard fixed-length sources do, but if your
>> source is merely emitting no items at this time (e.g. a network source
>> that's not currently receiving packets) the flow graph will still be
>> running waiting for more. I do not know of a way to ask for "when all
>> buffers are currently empty", if that's what you need.
>>
> ___________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to get a specific output of a block if a condition is true?

[Michael Dickens]

amples in the vector for correlation
> d_vppm_symbol_samples[i + tmp] = in[i];
> d_read_counter++;
> }
>
>
> } // end for-loop
> std::cout << "d_tag_found=true d_read_counter: " <<
> d_read_counter << std::endl;
>
> }
> else // no tag found yet
> {
> // get all tags that are stored in the sample stream
> get_tags_in_range(tags, 0, nitems_read(0), nitems_read(0) +
> ninput_items[0], d_lengthtag);
>
> // check if tags were found in the bunch of samples in input
> buffer
> if (tags.size() > 0)
> {
> d_tag_found = true;
> // There was a tag in the sample stream!
> std::cout << "Tag found - move on!!" << std::endl;
> std::cout << "count of tags: " << tags.size() <<
> std::endl; // this line prints the count of tags that were found
>
> // store the offset between the first sample of the input
> stream and the tag
> tag_offset = tags[0].offset;
>
> // the delta between ID of tag.offset and first item of
> input_buffer
> nitems_read_tag_delta = tag_offset - nitems_read(0);
>
> // get the count of samples that can be copied from the
> tag until the end of the current input buffer samples
> ninput_items_tag_offset_delta = ninput_items[0] -
> (nitems_read_tag_delta);
>
> // copy all items after the tag
> for (int i = 0; i < ninput_items_tag_offset_delta; i++)
> {
> if (i == d_samples_per_symbol) //((i ==
> d_samples_per_symbol) || (d_read_counter == d_samples_per_symbol))
> {
> //reset variables and exit the loop
> d_read_counter = 0;
> std::cout << "* !!! first attempt READY
> FOR CORRELATION!!! *" << std::endl;
>
> d_ready_for_correlation = true;
>
> // leave the for-loop
> // next step will be to calculate the correlation
> break;
> }
> else
> {
> d_vppm_symbol_samples[i] = in[i + tag_offset];
> d_read_counter++;
> }
>
> if (i == (ninput_items_tag_offset_delta - 1))
> {
> std::cout << "Not enough samples yet. Continue
> with the next call of the work function!" << std::endl;
> }
> }
> std::cout << "d_tag_found=false d_read_counter: " <<
> d_read_counter << std::endl;
> } // loop for processing the found tags
> }
>
>
> // skip code.
>
> // end skip code
> }
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] "Make Test" fails when installing GNU Radio

[Michael Dickens]

Hi Tellrell - You're on the right track. GR39 requires Python3 packages, so
you'll need the SciPy & PyZMQ for Py3; I believe the ones you installed are
for Py2. Guessing with this info you can work out which packages to
install. Hope this helps! - MLD

On Tue, Sep 10, 2019 at 1:03 PM Tellrell White  wrote:

> Hello All
> I'm currently trying to install GNU Radio 3.9.0 on Ubuntu 18.04. Cmake,
> and the make command seem to work fine without any issues. When I run make
> test I get the following output:
>
> 97% tests passed, 10 tests failed out of 364
>
> Total Test time (real) = 142.30 sec
>
> The following tests FAILED:
> 243 - qa_polar_decoder_sc (Failed)
> 244 - qa_polar_decoder_sc_list (Failed)
> 245 - qa_polar_decoder_sc_systematic (Failed)
> 246 - qa_polar_encoder (Failed)
> 247 - qa_polar_encoder_systematic (Failed)
> 360 - qa_zeromq_pub (Failed)
> 361 - qa_zeromq_pubsub (Failed)
> 362 - qa_zeromq_pushpull (Failed)
> 363 - qa_zeromq_reqrep (Failed)
> 364 - qa_zeromq_sub (Failed)
> Errors while running CTest
> Makefile:85: recipe for target 'test' failed
> make: *** [test] Error 8
>
> From research, I see some folks have had this issue before and it was
> suggested to try
>
> "sudo apt-get install python-scipy" and  "sudo pip install scipy Zmq"
>
> Neither one of these commands worked in my case. Any suggestions?
>
>
> Tellrell White
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk is not building on Mac

[Michael Dickens]

Yeah the compiler used in OSX 10.12 should not be GCC; should be Clang of
some sort. Let me boot into 10.12 on one my buildbots & see what happens. -
MLD

On Fri, Sep 6, 2019 at 12:08 PM Milos Milosavljevic <
milos.milosavlje...@spire.com> wrote:

> Hi All,
> Thank you very much for coming back to me.
>
> Michael, I tried both of these methods. No luck.
>
> As pointed out by Johannes it could be that I really have an ancient
> version of gcc that doesnt have these things. I think I will have to start
> from scratch. Delete everything, update things and try again.
>
> Johannes, yeah I dont know what to make of `Apple LLVM`. :) It could be
> that my Xcode messed up things.
>
> Anyway, I will keep trying.
>
> Thanks
> Milos
>
> On Fri, 6 Sep 2019 at 13:51, Michael Dickens 
> wrote:
>
>> Hi Milos - "volk" builds for me cleanly, but I'm using a current model
>> MacBook Pro which supports most of the AVX features checked for by Volk. A
>> couple thoughts:
>>
>> 1) Can you try building the "volk-devel" port and see if it works?
>>
>> 2) Can you try the following & see if it works:
>> {{{
>> sudo port clean volk
>> sudo port install volk -orc
>> }}}
>>
>> Hope this is useful! - MLD
>>
>> On Thu, Sep 5, 2019 at 8:11 PM Milos Milosavljevic <
>> milos.milosavlje...@spire.com> wrote:
>>
>>> Dear All,
>>>
>>> I cant build Volk on Mac at all using macports. Getting bunch of similar
>>> things to these (log attached as well):
>>>
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_volk/volk/work/volk-2.0.0/kernels/volk/volk_32f_x2_divide_32f.h:303:10:
>>>> error: assigning to '__m512' (vector of 16 'float' values) from
>>>> incompatible type 'int'
>>>>
>>>
>>> This is gcc version I have installed.
>>>
>>>
>>> $ gcc --version
>>>> Configured with:
>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr
>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1
>>>> Apple LLVM version 8.0.0 (clang-800.0.42.1)
>>>>
>>>
>>> Does anybody have any ideas by any chance that I could try?
>>>
>>> I tried $sudo port clean volk & sudo port install volk but no luck. I
>>> found some threads from macports (e.g.
>>> https://trac.macports.org/ticket/48009) but they didnt help me.
>>>
>>> Many thanks,
>>> Milos
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> --
>> Michael Dickens, Mac OS X Programmer
>>
>> Ettus Research Technical Support
>>
>> Email: supp...@ettus.com
>>
>> Web: http://www.ettus.com
>>
>
>
> --
> *Dr. Milos Milosavljevic*
> Senior Communications Engineer
>
> *Spire Global UK Limited*
>
> Unit 5A, Sky Park 5, 45 Finnieston Street, Glasgow, G3 8JU United Kingdom
>
> *+44 (0)1413 439  <+44%207881%20295658>146*
>
> *+44 (0)7954 161 6 <+44%207881%20295658>79*
>
>

-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk is not building on Mac

[Michael Dickens]

Hi Milos - "volk" builds for me cleanly, but I'm using a current model
MacBook Pro which supports most of the AVX features checked for by Volk. A
couple thoughts:

1) Can you try building the "volk-devel" port and see if it works?

2) Can you try the following & see if it works:
{{{
sudo port clean volk
sudo port install volk -orc
}}}

Hope this is useful! - MLD

On Thu, Sep 5, 2019 at 8:11 PM Milos Milosavljevic <
milos.milosavlje...@spire.com> wrote:

> Dear All,
>
> I cant build Volk on Mac at all using macports. Getting bunch of similar
> things to these (log attached as well):
>
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_volk/volk/work/volk-2.0.0/kernels/volk/volk_32f_x2_divide_32f.h:303:10:
>> error: assigning to '__m512' (vector of 16 'float' values) from
>> incompatible type 'int'
>>
>
> This is gcc version I have installed.
>
>
> $ gcc --version
>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
>> --with-gxx-include-dir=/usr/include/c++/4.2.1
>> Apple LLVM version 8.0.0 (clang-800.0.42.1)
>>
>
> Does anybody have any ideas by any chance that I could try?
>
> I tried $sudo port clean volk & sudo port install volk but no luck. I
> found some threads from macports (e.g.
> https://trac.macports.org/ticket/48009) but they didnt help me.
>
> Many thanks,
> Milos
> _______
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Errors trying to build gr-radioteletype for version 3.8

[Michael Dickens]

Echoing what Derek wrote: there has already been a fix committed into GR
maint-3.8 for the library version. If you update to the current GIT master
HEAD, the libraries will go back to being version 3.8, which will then work
with GR OOT modules looking for GR 3.8. - MLD

On Thu, Sep 5, 2019 at 12:59 PM Derek Kozel  wrote:

> Ah, this is Marcus' fault, not yours! There was briefly the wrong version
> number on maint-3.8, this will fix itself next time you update. Sorry for
> the confusion, carry on!
>
> On Thu, Sep 5, 2019, at 5:25 PM, Barry Duggan wrote:
>
> Hi Derek,
>
> Well now I'm *really* confused! I did a git status and got:
>
> """
> pi@raspberrypi:~/gnuradio $ git status
> On branch maint-3.8
> Your branch is up to date with 'origin/maint-3.8'.
>
> nothing to commit, working tree clean
> """
>
> and the cmake said:
> /usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 3.9.0.0-git
>
> Do I have a "mixed bag" or is something else going on?
>
> Thanks,
> ---
> Barry Duggan
>
>
> On 2019-09-05 09:22, Derek Kozel wrote:
> > Hi Barry,
> >
> > It looks like you're on the master branch of GNU Radio. When you next
> > think of updating GNU Radio I'd recommend moving over to the maint-3.8
> > branch, there's no reason for anyone not doing active core development
> > to be on the master branch at the moment.
> >
> > You'll need "3.9" currently, and if you move to maint-3.8 you'll need
> > "3.8".
> >
> > I doubt that gr-radioteletype has been updated for 3.8 so you'll likely
> > hit the need to redo all the gr-radioteletype CMakeFiles, not a massive
> > task but maybe one you'd find challenging at your level of experience
> > with CMake. Here's the guide for updating an OOT.
> >
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide
> >
> > I can't remember if you had a specific reason for using the master/3.8
> > code but using the 3.7 releases have nearly universal compatibility
> > with
> > all the OOTs out there.
> >
> > Regards,
> > Derek
> >
> > On 05/09/2019 14:11, Barry Duggan wrote:
> >> Hi Michael,
> >>
> >> I installed libcppunit-dev which resolved the "No package 'cppunit'
> >> found" error, but still get:
> >>
> >> """
> >> CMake Error at CMakeLists.txt:143 (find_package):
> >>   Could not find a configuration file for package "Gnuradio" that is
> >>   compatible with requested version "3.7.2".
> >>
> >>   The following configuration files were considered but not accepted:
> >>
> >>     /usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version:
> >> 3.9.0.0-git
> >>
> >> -- Configuring incomplete, errors occurred!
> >> See also "/home/pi/gr-radioteletype/build/CMakeFiles/CMakeOutput.log".
> >> """
> >>
> >> CMakeLists.txt line 143 says:
> >> find_package(Gnuradio "3.7.2" REQUIRED)
> >>
> >> should I change that to "3.8.0"? or "3.9.0"?
> >>
> >> Thanks for your help.
> >> ---
> >> Barry Duggan
> >>
> >>
> >> On 2019-09-05 08:33, Michael Dickens wrote:
> >>> Hi Barry - The error is:
> >>> {{{
> >>> -- Checking for module 'cppunit'
> >>> --   No package 'cppunit' found
> >>> -- Could NOT find CPPUNIT (missing: CPPUNIT_INCLUDE_DIRS)
> >>> }}}
> >>> so ... please make sure CppUnit is installed. - MLD
> >>>
> >>> On Wed, Sep 4, 2019 at 10:21 PM Barry Duggan 
> >>> wrote:
> >>>
> >>>> I tried to build gr-radioteletype for version 3.8 and got the
> >>>> following
> >>>> errors:
> >>>>
> >>>> """
> >>>> pi@raspberrypi:~/gr-radioteletype/build $ cmake
> >>>> -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release ../
> >>>> CMake Deprecation Warning at CMakeLists.txt:54 (cmake_policy):
> >>>>The OLD behavior for policy CMP0026 will be removed from a future
> >>>> version
> >>>>of CMake.
> >>>>
> >>>>The cmake-policies(7) manual explains that the OLD behaviors of
> >>>> all
> >>>>policies are deprecated and that a policy should be set to OLD
> >>>> only
> >>>> under
> >>>> 

Re: [Discuss-gnuradio] Errors trying to build gr-radioteletype for version 3.8

[Michael Dickens]

Hi Barry - The error is:
{{{
-- Checking for module 'cppunit'
--   No package 'cppunit' found
-- Could NOT find CPPUNIT (missing: CPPUNIT_INCLUDE_DIRS)
}}}
so ... please make sure CppUnit is installed. - MLD

On Wed, Sep 4, 2019 at 10:21 PM Barry Duggan  wrote:

> I tried to build gr-radioteletype for version 3.8 and got the following
> errors:
>
> """
> pi@raspberrypi:~/gr-radioteletype/build $ cmake
> -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release ../
> CMake Deprecation Warning at CMakeLists.txt:54 (cmake_policy):
>The OLD behavior for policy CMP0026 will be removed from a future
> version
>of CMake.
>
>The cmake-policies(7) manual explains that the OLD behaviors of all
>policies are deprecated and that a policy should be set to OLD only
> under
>specific short-term circumstances.  Projects should be ported to the
> NEW
>behavior and not rely on setting a policy to OLD.
>
> CMake Deprecation Warning at CMakeLists.txt:57 (cmake_policy):
>The OLD behavior for policy CMP0043 will be removed from a future
> version
>of CMake.
>
>   (ditto of above)
>
> CMake Deprecation Warning at CMakeLists.txt:60 (cmake_policy):
>The OLD behavior for policy CMP0045 will be removed from a future
> version
>of CMake.
>
>   (ditto of above)
>
> CMake Deprecation Warning at CMakeLists.txt:63 (cmake_policy):
>The OLD behavior for policy CMP0046 will be removed from a future
> version
>of CMake.
>
>   (ditto of above)
>
> -- Boost version: 1.67.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Checking for module 'cppunit'
> --   No package 'cppunit' found
> -- Could NOT find CPPUNIT (missing: CPPUNIT_INCLUDE_DIRS)
> CMake Error at CMakeLists.txt:143 (find_package):
>Could not find a configuration file for package "Gnuradio" that is
>compatible with requested version "3.7.2".
>
>The following configuration files were considered but not accepted:
>
>  /usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version:
> 3.9.0.0-git
>
> -- Configuring incomplete, errors occurred!
> See also "/home/pi/gr-radioteletype/build/CMakeFiles/CMakeOutput.log".
> """
>
> It appears that the CMakeLists have not been updated for 3.8.
>
> --
> Barry Duggan KV4FV
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Maximum input items consumed on each input stream

[Michael Dickens]

Hi Adrian - If you use a file source with a throttle, then that section of
your flowgraph will not drop samples. Using what Kevin wrote: The file
source will "work" as fast as possible, so its output buffer will fill up
quickly and any time samples are removed from it & so long as there is file
data available the file source will keep the output buffer full -- and
hence the throttle's input buffer will basically always be full. The
throttle will pass every single sample through eventually, but at an
average rate the matches its configuration. When presented with data in
this fashion, the throttle will do a very good job of keeping the output
sample rate close to that requested. Hence any dropped samples are
happening downstream from the throttle. Hope this is useful! - MLD

On Mon, Sep 2, 2019 at 6:10 AM Adrian Musceac  wrote:

> Hi Kevin,
>
> Thanks for the explanation, I think my flawed understading was due to
> the fact of having a file source with a throttle block, and seeing
> samples being dropped from buffers that did not match ASCII bytes lost
> at the file source but somewhere along the way. Is it correct to
> presume that in this case it is the throttle block that will be
> dropping the samples?
>
> Thanks,
> Adrian
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Maximum input items consumed on each input stream

[Michael Dickens]

Hi Laura - All of what's written already is basically correct. I'll add on
minor tweak: "ninput_items" and "noutput_items", which are 2 of the
arguments to the "work" or "general_work" method, define the maximum number
of input and/or output items available to use or requested to produce; see
the comments in the header for this method: <
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L168
>. Which of these variables is used depends on the actual block type as
already  noted: source, sink, sync, tagged_stream, etc ... for example for
a source block -- one that does have inputs -- "ninput_items" is not used;
for a sink block "noutput_items" is not used. For general blocks,
"ninput_items" is as noted in the header: "number of input items available
on each input stream", and "noutput_items" is "number of output items to
write on each output stream" ... but note that both of these are maximums.
The values of these variables generally varies during runtime -- or rather,
it is not guaranteed that they will constant -- so, you can't do something
like "always produce 100 items", because there might not be enough output
buffer space. Hence you have to rely on the values of these variables to
determine how to do "work", and needs to keep track of the number of items
consumed during work (and then consume just that number). Hopefully this
and the other replies provide enough information for you to figure out how
to proceed. Cheers! - MLD

ps> It is -very- cool to have a neuroengineer and anesthesiologist using GR!

On Fri, Aug 30, 2019 at 6:27 AM Albin Stigö  wrote:

> Laura et al,
>
> consume_each <= ninput_items.
>
> If you need a larger buffer than you consume you can abuse the
> scheduler slightly by set_relative_rate(1, some_min_input_items), this
> is done in the stream to vector blocks for example. I do this in a
> visualization sink where I need to produce FFTs with a certain
> overlap.
>
> // We need at least this number of points to do our job
> m_input_length = std::max(m_consume_each, m_fft_size);
> // This is probably abusing the scheduler quite a bit
> set_relative_rate(1, m_input_length);
>
> Interesting to see you work in neuroengineering. I'm an
> anesthesiologist and very interested these applications of gnuradio.
>
>
> --Albin
>
> On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller 
> wrote:
> >
> > Hi Laura,
> >
> > the buffer sizes are determined at flow graph startup based on the
> > involved block's io signature, output multiples, alignment
> > requirements, minimum and maximum buffer sizes, and the page size
> > (which practically everywhere is 4kB).
> >
> > I think you're expecting the amount of items your block is presented
> > with to be deterministic: it's simply not.
> >
> > It's a thing that depends on  the temporal execution of the signal
> > processing flowgraph at run time. Thus, your work (or general_work)
> > must always make sure it works within the boundaries of how many
> > samples are supplied in that specific call, and how much output space
> > is available at that point.
> >
> > I think
> >
> > https://www.gnuradio.org/blog/2017-01-05-buffers/
> >
> > might be of interest to you.
> >
> > Best regards,
> > Marcus
> >
> > On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > > Thank you very much Michael.
> > >
> > >  What are the I/O buffer sizes?
> > >
> > > * My block is a general block
> > > * In my forecast: ninput_items_required[0] = noutput_items;
> > > * In the general_work:  const gr_complex *in = (const gr_complex *)
> > > input_items[0];
> > >   float *out = (float *)
> > > output_items[0];
> > >
> > > /*
> > >  * The private constructor
> > >  */
> > > decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> > > output_sizes)
> > >   : gr::block("decoder",
> > >   gr::io_signature::make(1, 1, sizeof(gr_complex)),
> > >   gr::io_signature::makev(2, 2, output_sizes)),
> > >   s_rate(sample_rate)
> > > {
> > >
> > >
> > >
> > >
> > > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > > michael.dick...@ettus.com> wrote:
> > > > Hi Laura - In the "work" or "general_work" method, there are
> > > > arguments that contain the information you're looking for. These
> > >

Re: [Discuss-gnuradio] Maximum input items consumed on each input stream

[Michael Dickens]

Hi Laura - In the "work" or "general_work" method, there are arguments that
contain the information you're looking for. These arguments are set
depending on what type of block you're creating (source, sink, sync,
tagged_stream, whatever), are influenced by what the "forecast()" method
returns, and are constrained by the I/O buffer sizes. Sorry to be a little
vague, but the answer is that the value of the variable "consumed" in your
description is context dependent. Hope this is useful! - MLD

On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona  wrote:

> Hello GNURadio community,
>
> Does anyone know what is the maximum number of input items that an Out Of
> Tree block can consume on each input stream?
>
> consume_each(consumed) --> what is the maximum value that the variable
> consumed can take?
>
> Thank you very much.
>
>
> --
> *Laura Arjona *
> Washington Research Foundation Innovation Postdoctoral Fellow in
> Neuroengineering
>
> *Paul G. Allen School of Computer Science & Engineering*
> 185 E Stevens Way NE
> University of Washington
> Seattle, WA 98195-2350
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to Share Modules with Coworkers

[Michael Dickens]

Hi Dylan - If you have access to a GR OOT module (e.g., "gr-example"), then you 
can try to build it directly on your host computer ... as it sounds like you're 
trying to do ... but without much success as it sounds like accessing GR 
libraries for linking isn't working well.

Which version of GR is installed? If 3.7 then any GR OOT started using 
gr_modtool should work pretty well. If 3.8 then you might need to tweak the 
CMake scripts a little here and there ... hopefully some of this will be 
alleviated in the next 3.8 release.

If you want direct help, ping me directly off list. Hope this is useful! - MLD___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] unable to get sound from alsa sink

[Michael Dickens]

You're welcome, Chris. Try those changes & see if maybe that helps. I can 
generally switch between GR37 and GR38 easily, but right now I'm doing some 
GR38 CMake-related fixups & need it installed while doing so. Can't easily 
switch right now ... It is very possible that setting an ID for that widget 
doesn't yet quite work in GR38; might be in a pending PR and might be fixed for 
the next release. If not & we can replicate the issue then we should at least 
open an issue on GitHub if not already. Let us know how your modifications go. 
Cheers! - MLD

On Mon, Aug 26, 2019, at 2:09 PM, Chris Gorman wrote:
> Hi Michael,
> 
> Thanks for your input.  I will change the grc script as you suggested.
> This may not solve my issue explicitly, but I want to learn gnuradio
> so everything helps.  I have been running gnuradio 3.7 mostly because
> I have seen everyone's scripts use WX widgets and I found it easier to
> port them to QT via 3.7.  Perhaps I should upgrade, but I found a
> small bug in 3.9 when I was using it. (I couldn't get and 'ID' for my
> 'QT GUI Tab Widget' so I could use ID@0, ID@1, ... with the my other
> QT GUI widgets and place them into tabs.  I emailed the list, but
> didn't file a bug report and my email wasn't very verbose.  Sorry.  I
> ran a git rev-list to try to get an id as to be able to log the error.
> 'git rev-list --count HEAD' gave me 13291.  Not sure if this will help
> you track it.)
> 
> Thanks again and take care,
> 
> Chris

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

Re: [Discuss-gnuradio] unable to get sound from alsa sink

[Michael Dickens]

Hi Chris - A few comments, more than anything else:

* You're generating 2 sinusoids then pushing them directly into the audio sink. 
You're not guaranteed that the audio sink can support 2 input channels, even if 
it seem to be able to. If the audio sink is working, it will always support at 
least 1 channel.

==> Use an "add" block to sum them into a single audio stream.

* The sinusoids are at 0.5 amplitude ... which may or not be enough for your 
specific audio system.

==> Add a "Multiply Const" block to get the levels audible. (or 2 of them if 
you insist on using 2 audio streams). Use a Qt GUI Range slider set between 0.0 
and 1.0 to set the gain for any Multiple Const block in use.

* At least in my testing, the buttons in the top don't work, but some of the 
radio buttons do. Note that the "no tone 0 Hz" seems to be the same as "1209 
Hz" ... note that Audio -does- come out for me using the GRC script.

Since I'm currently using GR38 & your Python script is for GR37, it's 
non-trivial to get the Python script going ... so, hope this helps! - MLD

On Mon, Aug 26, 2019, at 1:22 PM, Chris Gorman wrote:
> Hi Michael,
> 
> Here's the original .grc file.  Thanks for your help.
> 
> Chris

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

Re: [Discuss-gnuradio] unable to get sound from alsa sink

[Michael Dickens]

Can you send me the original GRC flowgraph too? I know you modified the output 
Python, but it might be useful. Also: I'm trying to use GR38 (just because) ... 
so seeing what Python it generates will be useful. Thx! - MLD

On Mon, Aug 26, 2019, at 11:13 AM, Chris Gorman wrote:
> Hi Michael,
> 
> Thanks for looking at this for me.  I'm using gnuradio-3.7.13.5 on
> ubuntu 18.04.
> 
> Chris

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

Re: [Discuss-gnuradio] unable to get sound from alsa sink

[Michael Dickens]

Just FYI that ALSA is Linux-specific.

Chris: Did you verify that audio output is working at all on your system? If 
so, then have you worked out why it's not working in your flowgraph? If not, 
let us know of any changes to it since you posted last & we'll see what we can 
do. - MLD

On Mon, Aug 26, 2019, at 9:38 AM, Barry Duggan wrote:
> Hi Chris,
> 
> You didn't mention your OS or your platform, but this works for a Linux 
> system:
> 
> Using a terminal screen, enter 'aplay -L'
> 
> Here is an excerpt from my Raspberry Pi:
> 
> """
> default:CARD=ALSA
>  bcm2835 ALSA, bcm2835 ALSA
>  Default Audio Device
> hw:CARD=ALSA,DEV=1
>  bcm2835 ALSA, bcm2835 IEC958/HDMI
>  Direct hardware device without any conversions
> hw:CARD=Device,DEV=0
>  USB Audio Device, USB Audio
>  Direct hardware device without any conversions
> """
> 
> The Pi has a headphone jack, an HDMI port, and I have a USB audio 
> dongle. What you need to do is pick the appropriate entry for your 
> system, and the enter the Device Name in the Audio Sink properties. For 
> example, I use "hw:CARD=ALSA,DEV=1" to get sound on my monitor.
> 
> On Windows or Mac, you might just enter "default:CARD=ALSA".
> 
> Good luck,
> -- 
> Barry Duggan

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

Re: [Discuss-gnuradio] gnuradio.conf file

[Michael Dickens]

I totally agree with you, Barry: if there is an issue then show the error 
always; if there is no error then don't show one. Showing it once isn't useful, 
regardless of whether there was an error or not! I'll open a GR issue about 
this & see if we can get some traction on it; it'll probably be a lot priority, 
since otherwise the code works. Thanks! - MLD

On Wed, Aug 21, 2019, at 10:30 AM, Barry Duggan wrote:
> Michael,
> 
> Thank you for that. Apparently it did find a default "xterm".
> 
> So I have two suggestions related to this:
> 1) Don't show the error message unless it can't find a default.
> 2) Continue to show the error message until it has an xterm to use. 
> Currently it shows the error message only once.
> 
> Best regards,
> ---
> Barry Duggan

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

Re: [Discuss-gnuradio] gnuradio.conf file

[Michael Dickens]

Hi Barry - The file "gnuradio.conf" resides in "~/.gnuradio/". In my setup, I 
put the "[grc]"and "xterm" lines in the file "config.conf" in the same 
directory ... not sure if this is correct ... maybe I could combine them into a 
single "*.conf"? Anyway ... the entry (after "[grc]") should be something like:
{{{
xterm_executable = /opt/local/bin/xterm
}}}
I just specifies which "xterm" executable to use. GRC should be able to find a 
default "xterm" assuming it's in a standard system path. On my computer I have 
the system "xterm" as well as one compiled from source, so I actually use the 
above line to set the specific "xterm" for GRC to use. Hope this is useful! - 
MLD

On Wed, Aug 21, 2019, at 8:23 AM, Barry Duggan wrote:
> Hi,
> 
> I just finished a clean start build of the maint-3.8 branch. When I 
> executed a gnuradio-companion flowgraph, it said I was missing the xterm 
> executable, and to specify it in gnuradio.conf as
> 
> [grc]
> xterm_executable
> 
> My problem is that there doesn't seem to be an existing gnuradio.conf 
> file, and I don't know where to put it. I have '~/gnuradio', 
> '~/.gnuradio', and '~/.gnuradio/prefs' as possible candidates. 
> Interestingly, it seems to run OK without it!
> 
> I am using Raspbian Buster on a Raspberry Pi 3B+.
> 
> Side note: The GRC version is 3.9.0.0.git!
> 
> Thanks for your help.
> -- 
> Barry Duggan KV4FV
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

Re: [Discuss-gnuradio] Gnuradio Runtime buffers and latency

[Michael Dickens]

Hi Wheberth - In a similar block I've created in the past, I include a 
parameter, let's call it "stuffing_size", that is the number of items to stuff 
when stuffing occurs. If this value is small, then there is "small" latency 
between when the PDU comes in and its data is output ... but, the block uses a 
lot of CPU time spinning checking whether it should do "work". If this value is 
large, then the block uses very little CPU time but the latency between PDU 
reception and output is "large". You have to play around to find the sweet spot 
trading off latency and CPU use, but that's not too difficult. Maybe this is 
the way to go for your situation? Hope this is useful! - MLD

On Wed, Aug 14, 2019, at 10:56 PM, Wheberth Damascena Dias wrote:
> Hi all, I have created an OOT block that receives PDUs as input, stores the 
> data in a FIFO buffer and generates a stream as output. Case no data is 
> available at the FIFO, stuffing data is generated. 
> The block (kind of) works as intended, but when it is on the system with no 
> data PDUS being received it does its job and generates stuffing. The problem 
> is that, if I understood correctly, the rate of generation is controlled by 
> the blocks downstream (via backpressure) meaning it fills all buffers of the 
> blocks downstream up to the USRP.
> This makes the next PDUs that arrive to suffer a very high latency.
> I am trying to find a way to limit the buffer of the blocks downstream, but 
> it doesn't feel like the right way to deal with this. Another idea is to 
> query the status of the output buffer (via pc_output_buffers_full()) and 
> generate stuffing data just when it is empty.
> Anyone have faced similar issue? Am I in the right direction?
> Any comments are appreciated.
> 
> Best Regards 
> -- 
> *Wheberth Damascena Dias*
> ___ _ _ __ ___ __ _ _ _ _ 
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.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] Problem installing Gnuradio3.8

[Michael Dickens]

Hi Al - I can't speak to PyBOMBS specifically, but the error message shows that 
GMP or MPIR isn't working correctly: "/usr/include/gmpxx.h" should "#include" 
the file "/usr/include/gmp.h", which should contain the function "mpf_cmp_z" 
... just checked my system & this is indeed the case. Maybe somehow the header 
"/usr/include/gmp.h" didn't get installed & you could do that manually? Hope 
this is useful! - MLD

On Thu, Aug 15, 2019, at 7:05 AM, LiverPudd wrote:
> Hi All
> 
> I cannot get gnuradio 3.8 to install. 
> 
> I have installed a clean copy of Ubuntu Mate 18.04 and pybombs on my machine 
> and installed all the pre-requisites required for gnuradio.
> 
> What I have done thus far is;
> 
> 1) Modify gnuradio-default.lwr to point to gnuradio38(.lwr)
> 2) Modify gnuradio38.lwr to include -DENABLE_CTRLPORT_THRIFT=OFF in the 
> config_opt line
> 3) Run "pybombs prefix init ~/src/gr -a gr -R gnuradio-default"
> 
> UHD installed OK without any errors, but the remaining outbut from the build 
> is shown below. 
> 
> Anyone got any ideas how to fix this before I pull out any remaining hair I 
> haved left?
> 
> =
> 
> Cloning into 'gnuradio38'...
> remote: Enumerating objects: 1164, done.
> remote: Counting objects: 100% (1164/1164), done.
> remote: Total 2892 (delta 1164), reused 1164 (delta 1164), pack-reused 1728
> Receiving objects: 100% (2892/2892), 1.28 MiB | 370.00 KiB/s, done.
> Resolving deltas: 100% (2315/2315), completed with 322 local objects.
> Submodule 'volk' (https://github.com/gnuradio/volk.git) registered for path 
> 'volk'
> submodule 'volk' cannot add alternate: path 
> '/home/gonzo/.pybombs/gitcache/modules/volk/' does not existCloning into 
> '/home/gonzo/src/gr/src/gnuradio38/volk'...
> remote: Enumerating objects: 33, done. 
> remote: Counting objects: 100% (33/33), done. 
> remote: Compressing objects: 100% (28/28), done. 
> remote: Total 7961 (delta 8), reused 17 (delta 4), pack-reused 7928 
> Receiving objects: 100% (7961/7961), 2.17 MiB | 332.00 KiB/s, done.
> Resolving deltas: 100% (5522/5522), done.
> Submodule path 'volk': checked out '1299d72c396a88fd2679adfd7a919ac00d2cf678'
> Configuring: (100%) 
> [===]
> Building: (100%) 
> [===]
> [ 6%] Built target volk_obj
> [ 6%] Built target volk
> [ 6%] Built target volk_test_all
> [ 7%] Built target volk-config-info
> [ 8%] Built target volk_profile
> [ 8%] Built target pygen_volk_python_volk_modtool_9770a
> [ 9%] Built target pygen_volk_python_volk_modtool_4d1e3
> [ 9%] Built target doxygen_target
> [ 9%] Built target gnuradio-pmt
> [ 9%] Building CXX object 
> gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block.cc.o
> In file included from 
> /home/gonzo/src/gr/src/gnuradio38/gnuradio-runtime/lib/../include/gnuradio/block.h:34:0,
>  from /home/gonzo/src/gr/src/gnuradio38/gnuradio-runtime/lib/block.cc:27:
> /usr/include/gmpxx.h: In static member function ‘static int 
> __gmp_cmp_function::eval(mpf_srcptr, mpz_srcptr)’:
> /usr/include/gmpxx.h:912:12: error: ‘mpf_cmp_z’ was not declared in this scope
>  { return mpf_cmp_z(f, z); }
>  ^
> /usr/include/gmpxx.h:912:12: note: suggested alternative: ‘mpf_cmp_d’
>  { return mpf_cmp_z(f, z); }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static int 
> __gmp_cmp_function::eval(mpz_srcptr, mpf_srcptr)’:
> /usr/include/gmpxx.h:914:13: error: ‘mpf_cmp_z’ was not declared in this scope
>  { return -mpf_cmp_z(f, z); }
>  ^
> /usr/include/gmpxx.h:914:13: note: suggested alternative: ‘mpf_cmp_d’
>  { return -mpf_cmp_z(f, z); }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static bool 
> __gmp_binary_equal::eval(mpf_srcptr, mpz_srcptr)’:
> /usr/include/gmpxx.h:980:12: error: ‘mpf_cmp_z’ was not declared in this scope
>  { return mpf_cmp_z(f, z) == 0; }
>  ^
> /usr/include/gmpxx.h:980:12: note: suggested alternative: ‘mpf_cmp_d’
>  { return mpf_cmp_z(f, z) == 0; }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static bool 
> __gmp_binary_less::eval(mpf_srcptr, mpz_srcptr)’:
> /usr/include/gmpxx.h:1040:12: error: ‘mpf_cmp_z’ was not declared in this 
> scope
>  { return mpf_cmp_z(f, z) < 0; }
>  ^
> /usr/include/gmpxx.h:1040:12: note: suggested alternative: ‘mpf_cmp_d’
>  { return mpf_cmp_z(f, z) < 0; }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static bool 
> __gmp_binary_less::eval(mpz_srcptr, mpf_srcptr)’:
> /usr/include/gmpxx.h:1042:12: error: ‘mpf_cmp_z’ was not declared in this 
> scope
>  { return mpf_cmp_z(f, z) > 0; }
>  ^
> /usr/include/gmpxx.h:1042:12: note: suggested alternative: 

Re: [Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml

[Michael Dickens]

Hi Jean Pierre & Kyeong - gr-osmosdr does not have an official port to GR3.8 as 
of yet. There are 3rd-party ports that might work, such as those from the issue 
noted: https://osmocom.org/issues/3855 . See also:

https://github.com/igorauad/gr-osmosdr/tree/gr3.8
https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8
https://github.com/igorauad/gr-osmosdr/tree/gr3.8

Hope this is useful! - MLD

On Wed, Aug 14, 2019, at 7:46 AM, Kyeong Su Shin wrote:
> Hello Jean Pierre:
> 
> You will have to install gr-osmosdr. If your repository does not provide 
> gr-osmosdr for GNU Radio 3.8.0.0, you will have to build it by yourself 
> (installing gr-osmosdr for a wrong version of GNU Radio may cause you 
> troubles).
> 
> See https://osmocom.org/projects/gr-osmosdr/wiki and 
> https://osmocom.org/issues/3855 if you experience troubles in building and 
> installing gr-osmosdr.
> 
> Regards,
> Kyeong Su Shin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM with continuous pilots but bursty data

[Michael Dickens]

Hi Alex - The default OFDM Rx is fully asynchronous: It tries to detect the 
packet preamble on a packet by packet basis only, without using any knowledge 
of historical successful packet detection. I don't think GR provides a 
synchronous receiver, and I don't know of one in any GR out of tree (OOT) 
module ... but I don't know everything so maybe there is one & if so hopefully 
others will chime in to tell us! Hope this is useful! - MLD

On Tue, Aug 13, 2019, at 1:04 PM, Alex Roberts wrote:
> I'm playing around with an OFDM transmit/receive chain. I've noticed that if 
> I get underruns at a high enough rate, it becomes a bursty system and the 
> receiver is unable to lock in and no longer demodulates the symbols. 
> 
> Would it be possible to generate continuous pilot tones or send OFDM frames 
> with just preambles and padded data such that even if the source data stream 
> underruns, the output is continous rather than bursty so that the receiver 
> can keep lock with time and frequency offests?
> 
> -Alex
> ___
> 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] 3.8.0.0-rc2 build from source on macOS

[Michael Dickens]

FYI to any OSX user on GR3.8 :

We're actively debugging this issue, and will end up pushing a fix into GR once 
the right one is confirmed. I've created a GR issue [1]; let's take the 
discussion there, since in the end we'll end up with a PR & others might want 
to test out the possible fixes and chime in on the matter. - MLD

[1] https://github.com/gnuradio/gnuradio/issues/2726
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS

[Michael Dickens]

Hi Emmanuel - I'm the GR OSX "expert" (LOL), as I do a lot of testing and 
verification and development on OSX (various versions). I'm happy to help as 
best I can. It might be that your issue is a generic GR bug. Let's take this 
discussion off-list & see what we can work out. If there's something relevant 
we can report back to the list and/or create a GR issue for it. - MLD

On Thu, Aug 8, 2019, at 10:02 AM, Emmanuel Blot wrote:
> Hi Marcus,
> 
> > my Apple experience limits itself to using an iPod in the summer 2010
> > or so, but I hope I can still be of help.
> 
> :-)
> 
> > First of all: Which path are
> > you taking to build stuff?
> 
> I’m using Homebrew (https://brew.sh) to build *nix applications on 
> macOS.
> It is nice to have a controlled build environment.
> 
> To build GR 3.0.0.8-rc2, I’m using the default Apple compiler:
> 
> $ cc --version
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> 
> and the following major dependencies:
> 
> cmake 3.15.2
> ninja 1.9.0
> swig 4.0.0
> python 3.7.4
> pyqt 5.10.1
> qwt 6.1.4
> qt 5.13.0
> 
> For PyGTK, I’m not sure which version is actually used.
> 
> >>> import gi
> >>> gi.version_info
> (3, 32, 2)
> 
> but PyGTK2 was also installed.
> 
> Let me know if there is a good/better way to check this point.
> 
> Less relevant I believe:
> 
> adwaita-icon-theme 3.32.0
> doxygen 1.8.15
> pkg-config 0.29.2
> sphinx 2.1.2
> boost 1.70.0
> fftw 3.3.8_1
> gsl 2.5
> numpy 1.16.4
> portaudio 19.6.0
> libyaml 0.2.2
> mpir 3.0.0
> uhd 3.14.1.0
> zeromq 4.3.2
> freeglut 3.0.0
> log4cpp 1.1.3
> + all sub-dependencies + all Python modules :P
> 
> GR is therefore built with CMake/Ninja, from an out of source build.
> I can post the build log if it can help.
> 
> I’m not sure I answer your question about the build path I take, 
> please let me know.
> 
> > Ah! That might be a package naming problem. For example, on Fedora 30,
> > the package you want for python3 PyQt would be python3-PyQt5 and
> > python3-qt5-devel.
> 
> I think on QT side this is correct (QT5), but I’m not sure how to 
> check which actual GTK version is actually used.
> I do develop on the same host with PyGTK3.
> 
> I removed GTK2 and pygtk (for Py2) packages as they were only used for 
> the previous GR 3.7 series on my host - it did not help up to now.
> 
> > So, two different things: making GRC work (GTK), and making gr-qtgui
> > (QT, PyQt, Qwt) work.
> 
> Ok, got it.
> 
> > Hope I got you out of that confusion!
> 
> Yes. Thanks a lot for these details, I really mean it.
> 
> > That's probably something else, as said, Qt isn't used in GRC. You
> > don't need Qt to have GRC, and you don't need GRC to get gr-qtgui.
> 
> Ok.
> 
> > I'd call that a bug!
> > Can you tell us which blog you dragged onto the canvas, or does this
> > happen with all blocks?
> 
> It happens with any block, as simple as the logical AND block, or 
> Constant waveform source
> 
> I was tracing the call before I receive your reply, and for now, here is 
> what I found:
> 
>  BlockTreeWindow.py:
>  def _handle_drag_get_data(self, widget, drag_context, 
> selection_data, info, time):
>  key = self._get_selected_block_key()
>  if key:
>  # key is a valid text string, e.g. “blocks_and_xx” or 
> “analog_const_source_x”
>  selection_data.set_text(key, len(key))
> 
> 
>  DrawingArea.py:
>  def _handle_drag_data_received(self, widget, drag_context, x, y, 
> selection_data, info, time):
>  coords = x / self.zoom_factor, y / self.zoom_factor
>  # here, selection_data is empty (no data, no text, no type), I 
> can’t tell why.
>  self._flow_graph.add_new_block(selection_data.get_text(), 
> coords)
> 
> 
>  flowgraph.py:
>  def add_new_block(self, key, coor=None):
>  id = self._get_unique_id(key)
>  ...
>  # key is None, and exception is raised
>  block = self.new_block(key)
> 
> 
> > Also: this is a clean install, right? There's no e.g. flowgraph.py
> > flying around anywhere else on your system where python might be
> > erratically picking it up?
> 
> No, I’ve removed all the previous GNUradio installation, and Homebrew 
> always installs each app in its own versioned directory, here 
> “/usr/local/Cellar/gnuradio/3.8.0.0-rc2/“
> There is no custom PYTHONPATH, and I also unset GRC_BLOCKS_PATH from a 
> previous setup. When I edit the Python file (to track down this issue), 
> my trace messages are executed as expected.
> 
> PYTHONPATH is therefore defined to:
> PYTHONPATH="/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages:\
>  
> /usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/site-packages:\
>  
> /usr/local/Cellar/gnuradio/3.8.0.0-rc2/libexec/vendor/lib/python3.7/site-packages"
> 
> 1: lib/python3.7/dist-packages: gnuradio, pmt
> 2: lib/python3.7/site-packages: volk_modtool
> 3: 

Re: [Discuss-gnuradio] turn off DC offset

[Michael Dickens]

Thank you, Julian ... that's the issue here I bet!

Simona is running GR 3.7.14.4, which contains a bug in gr-uhd's GRC interface 
where the "set_auto_dc_offset" function is executed only if its argument is 
"True". We fixed it here < 
https://github.com/gnuradio/gnuradio/commit/fc3eaf1414c192294281eef0a009359d1c913d99
 > to take any argument provided -- though only "True" or "False" will work -- 
and this fix is part of the 3.7.14.5 release.

Simona - Can you update GR to the 3.7.14.5 release? Doing so and using "True" / 
"False" (without ""s) in the UHD GRC blocks will hopefully resolve your issue. 
- MLD

On Tue, Jul 30, 2019, at 12:44 PM, Julian Arnold wrote:
> Hey,
> 
> I've had a similar issue with a 3.7 version so maybe this helps.
> 
> For me, no other value than "True" (without "") would generate a call to 
> "set_auto_dc_offset()" in the GRC generated python script ("top_block.py").
> 
> So, in order to disable DC offset tracking, a quick workaround would be 
> to set "Enable DC Offset Corrections" to "True". This adds the desired 
> call to "set_auto_dc_offset()" to your "top_block.py". Now you only need 
> to manually change "True" to "False" in "top_block.py" and DC offset 
> tracking should be disabled. Remember to not regenerate the flow-graph 
> after making those changes as otherwise GRC will override your changes.
> 
> Alternatively, you can of course always simply add the line 
> self.uhd_usrp_source_0.set_auto_dc_offset(False, 0)
> to your script without using GRC.
> 
> Hope this helps.
> Cheers,
> Julian

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

Re: [Discuss-gnuradio] turn off DC offset

[Michael Dickens]

Can you execute "gnuradio-config-info -v" and report back what it returns?

Can you execute some UHD-based application (whether GNU Radio or whatever), and 
report back the displayed debugging info?

On Tue, Jul 30, 2019, at 9:56 AM, Simona Sibio wrote:
> Of course, I am using Linux, the GNU radio version is 7.3.0 and UHD version 
> is UHD.3.13.1.
> 
> And, I would like to measure the DC offset in the receiver.
> 
> Thank you for your time.
> Best Regards,
> 
> Simona
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] turn off DC offset

[Michael Dickens]

OK. So did the change help for the IQ imbalance? Are you sure there is a DC 
offset to be removed?

Can you provide us with a little more info: which OS & version? Which GNU Radio 
& UHD versions and how installed? - MLD

On Tue, Jul 30, 2019, at 9:29 AM, Simona Sibio wrote:
> Thank you for the tip.
> But I tried with False and True in Enable DC offset, and nothing is changed.
> The system ran but the spectrum is not changed.
> 
> Best regards,
> 
> Simona
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] turn off DC offset

[Michael Dickens]

Hi Simona - Since you're working in the GRC domain, you need to use variables 
that make sense in Python ... "False" and "True" -- but without the ""s. "0" is 
not necessarily "False", etc... try those & see what happens. Hope this is 
useful! - MLD

On Tue, Jul 30, 2019, at 9:18 AM, Simona Sibio wrote:
> *Hi everyone,*
> *
**I want to disable automatic calibration of DC offset and IQ imbalance in** 
USRP Source block.
**
**I am aware that I need to pass bool value 'false' as the argument to 
***set_auto_dc_offset* and *set_auto_iq_balance*. The USRP Source block
**itself provide this facility in the tab *FE Corrections*. However, it
**does not seem to work. *
> *By providing 0 (boolean false) value in Enable DC** Offset Correction and 
> Enable IQ Imbalance Correction do not disable the **automation DC offset and 
> IQ Imbalance correction.*
> *I tested this with USRP **N210 by simply using USRP Source block.** The 
> spectrum plot does not show any changes **in both cases.
**
**If I want to force these changes in the UHD code (usrp_source_impl.cc **and 
usrp_source_impl.h), what changes do I need to make?
**
**
** Thanks,
** Simona*
> ___
> 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] Build GR 3.8 from source

[Michael Dickens]

Hi Barry - That's great! You're very welcome! Good luck with your GR work! - MLD

On Mon, Jul 22, 2019, at 4:51 PM, Barry Duggan wrote:
> Hi Michael,
> 
> Success! Based on Ron's suggestion, I was able to finish the last half 
> of the make in 3 hours.
> 
> Then I did a 'make test' and got the following failures:
> 
> """
> 98% tests passed, 6 tests failed out of 362
> 
> Total Test time (real) = 1465.99 sec
> 
> The following tests FAILED:
>   150 - qa_pmt (Failed)
>   243 - qa_polar_decoder_sc (Failed)
>   244 - qa_polar_decoder_sc_list (Failed)
>   245 - qa_polar_decoder_sc_systematic (Failed)
>   246 - qa_polar_encoder (Failed)
>   247 - qa_polar_encoder_systematic (Failed)
> Errors while running CTest
> make: *** [Makefile:86: test] Error 8
> """
> 
> I don't think it will impact what I need, but thought you might want to 
> know.
> 
> I really appreciate all the help you have provided.
> 
> Best regards,
> ---
> Barry Duggan
> 
> 
> On 2019-07-22 09:02, Michael Dickens wrote:
> > Good morning, Barry! Progress ... keep it coming!
> > 
> > Reviewing your cmake log: My guess is that you just need to give it
> > longer. A -lot- longer. The point of delay is when C++ is compiling
> > the SWIG-generated Python interface for gr::filter. SWIG C++ code is
> > horrendous to read through, and takes a log time to compile when it of
> > any reasonable amount of complexity. If your RPi can't handle the
> > compilation, it'll crash -- not just hang, but totally crash. Way back
> > with the RPi 1, we did get GR to compile on it ... but it took like 2
> > days! Patience sometimes works here!
> > 
> > All of that said: Did you look at Ron's recommendation? The RPi is
> > notoriously difficult to compile GR directly on; sometimes you need to
> > tweak file / memory settings to get "reasonable" compiles.
> > 
> > Also: You could try using OpenEmbedded to build GR on your host
> > computer, cross-compiled for your RPi. That would take some work, but
> > might be worth the effort as once it works it would be easily
> > repeatable!
> > 
> > Hope this is useful! - MLD
> > 
> > On Mon, Jul 22, 2019, at 7:30 AM, Barry Duggan wrote:
> >> Good Morning!
> >> 
> >> Well, good news and bad news. The good news is that it got past the 
> >> 13%
> >> mark with no problems. The bad news is that it got stuck again in an
> >> even tighter loop at 53%. I couldn't even move the cursor or interrupt
> >> it with a control-C. The activity light was on solid.
> >> 
> >> I started at 17:05 and at 20:35 it was at 53%, so I projected it 
> >> should
> >> finish around midnight. I left it running overnight, but it was still 
> >> at
> >> 53%. The output didn't capture the last of what was on the screen.
> >> 
> >> Let me know what to try next. Thank you for your help.
> >> 
> >> Best regards,
> >> ---
> >> Barry Duggan
> >> 
> >> 
> >> On 2019-07-21 13:41, Michael Dickens wrote:
> >> > Hi Barry - OK; good progress! Can you do the following, from the
> >> > top-level "build" directory (looks like "/home/pi/gnuradio/build"):
> >> > {{{
> >> > make clean
> >> > make VERBOSE=ON 2>&1 | tee make_out.txt
> >> > }}}
> >> > and then walk away & let it go until it's done. You'll be able to see
> >> > the build going along via the 'tee' command. Please be patient! It
> >> > might work; it might not! Either way on an RPi it'll take some time to
> >> > build whatever it can! - MLD
> >> >
> >> 
> >> 
> >> 
> >> Attachments:
> >> * make_out.txt
>

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

Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks?

[Michael Dickens]

Hi DL - One possible option that I think would handle both TDMA and FDMA and 2 
streams of data: use a PFB with 2 channels (or 2 separate rotators / filters), 
to create 2 parallel paths each at baseband. Each path represents complex data 
that was modulated at some frequency and bandwidth & is now at baseband. For 
each path, detect the signal of interest, and once found package it as a 
tagged_stream. Each path leads into a different input of the tagged_stream_mux 
block as before (assuming that worked before, it should work now). In this 
manner, the mux will wait until it has 2 such tagged_streams. Maybe this would 
do what you want? Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 2:25 PM, Lundberg, Daniel wrote:
> Hi, thanks. To elaborate a bit…

> I need to be able to absolutely align the start of two signals and add them 
> in an FDMA sense (so I will construct the signals in different parts of the 
> band and just add them together as complex numbers). The receiving system 
> requires that I do the alignment for it. It is also important that one of the 
> two signals be created and transmitted in a timely manner (I have a 
> requirement for the time between when the second signal is created and when 
> it is transmitted, because it contains some real-time diagnostic information).

> I have previously solved a similar problem, but instead of FDMA I was doing 
> TDMA. The basic code structure is:

> Convert the first of the two signals to a tagged stream via stream to tagged 
> stream block. 

> Custom trigger block waits for the packet_len tag in this signal, and when it 
> sees it, sends a message to trigger the creation of a PDU with the second 
> signal within another custom block. 

> PDU goes into PDU to tagged stream block

> Combine two signals (now both tagged streams) in a tagged stream mux block. 

> To the USRP and beyond!

> Using one signal to trigger the other, combined with the tagged stream mux 
> waiting until it has both signals in memory to proceed, means that the 
> latency of the whole process is naturally controlled, because the first 
> signal will not pass another packet_len tag through my custom trigger block 
> until the first packet is clear of the tagged stream mux. This did require 
> explicit adjustment to minimum buffer sizes to accommodate the big packets, 
> but things are stable and working on a pretty standard dell laptop, so I 
> don’t have any performance worries at this point, even with a bunch of custom 
> code written in python.

> So back to FDMA:

> I can do the same sort of thing, where I trigger the creation of the second 
> signal off of the first, but I don’t have an explicit way to control the flow 
> without the tagged stream mux introducing the (desirable!) bottleneck. 
> Without that backpressure, there is nothing to stop the first signal from 
> triggering the second signal a large number of times until a non-tagged 
> stream block’s buffer is filled up. This is undesirable for me, because it 
> means I will have a bunch of diagnostic signals generated right away, and 
> then the system will eventually settle into some steady-state latency that is 
> longer than my requirement. So if I had an OOT “tagged stream add” block that 
> does a simple complex add, but waits for both tagged stream packets to be 
> present before proceeding, I think I would be more or less done.

> Thank you for the OOT compiling tips, I’ll give it a go. C++ is not my forte…

> DL

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

Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks?

[Michael Dickens]

Hi DL - 2 primary thoughts:

1) To "create" a tagged stream block in your OOT using gr_modtool (if it 
doesn't do that as you desire), find an already existing tagged_stream block 
that you understand the programming of. Use gr_modtool to create a new "sync" 
block, then copy/paste from the existing tagged_stream block into your new one: 
3 files: include/OOT/NAME.h ; lib/NAME_impl.h ; lib/NAME_impl.cc . The 
CMakeLists.txt will already be setup for compiling, assuming you don't need any 
special definitions or linkage or whatever. Then, edit those files to do what 
you want.

2) 1 million data points is a lot of points to do using a data stream! And even 
more if you used a tagged stream for all 1e6 samples! Do you need them all at 
the same time, or are the offsets small enough that you just need a small 
number of data samples stored before you can alight them? Alternative 
implementations might include using PDUs ... but much depends on what exactly 
you're trying to accomplish beyond what you wrote (what the actual algorithm is 
you're trying to implement).

Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 11:28 AM, Lundberg, Daniel via Discuss-gnuradio wrote:
> I am working within Gnuradio version 3.7.13.4. As far as I can tell, 
> gr_modtool does not support tagged stream blocks for either python or C++. 
> Trying to make a new tagged stream block in C++ will create QA code, but does 
> not make files for the actual block. For python it will throw a hard error. 
> This appears to be a known issue: 
> https://github.com/gnuradio/gnuradio/issues/2489

> 

> Can someone point me to some documentation on how to implement an out of tree 
> module without gr_modtool? 

> 

> If this is a non-starter, then here is my problem description. I am open to 
> suggestions on how to solve the problem without an OOT tagged stream block:

> I need to implement a block that takes two generated signals with defined, 
> very large (~ million sample) packet lengths that are produced at different 
> times, align them on a sample-by-sample basis, and adds them. I know how to 
> do this within a tagged stream block. I am open to ideas on how to do this 
> without tagged streams, but I’m not sure how to do sample alignment of large 
> packets without having them contained in a tagged stream block work function.

> 

> Thank you,

> DL

> 

> ___
> 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] Build GR 3.8 from source

[Michael Dickens]

Hi Barry - OK; good progress! Can you do the following, from the top-level 
"build" directory (looks like "/home/pi/gnuradio/build"):
{{{
make clean
make VERBOSE=ON 2>&1 | tee make_out.txt
}}}
and then walk away & let it go until it's done. You'll be able to see the build 
going along via the 'tee' command. Please be patient! It might work; it might 
not! Either way on an RPi it'll take some time to build whatever it can! - MLD

On Sun, Jul 21, 2019, at 9:42 AM, Barry Duggan wrote:
> Hi Michael,
> 
> 'sudo pip3 install click-plugins' took care of the problem with cmake. 
> Then 'make' started OK, but when it got to 13%, it just hung in a tight 
> loop. After about an hour of waiting, I did a control-C and it finally 
> recognized it. I repeated the 'make' and it stopped in the same place. 
> See the following...
> 
> [ 13%] Building CXX object 
> gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx.o
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:
>  
> In function ‘void SWIG_Python_addvarlink(PyObject*, char*, PyObject* 
> (*)(), int (*)(PyObject*))’:
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:73109:16:
>  
> warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound 
> depends on the length of the source argument [-Wstringop-overflow=]
>   strncpy(gv->name,name,size);
>   ~~~^~~~
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:73106:27:
>  
> note: length computed here
> size_t size = strlen(name)+1;
>   ~~^~
> In file included from /usr/include/c++/8/vector:69,
>   from 
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:3060:
> /usr/include/c++/8/bits/vector.tcc: In function ‘void std::vector<_Tp, 
> _Alloc>::_M_range_insert(std::vector<_Tp, _Alloc>::iterator, 
> _ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with 
> _ForwardIterator = __gnu_cxx::__normal_iterator std::complex*, std::vector, 
> std::allocator > > >; _Tp = std::complex; 
> _Alloc = std::allocator >]’:
> /usr/include/c++/8/bits/vector.tcc:672:7: note: parameter passing for 
> argument of type ‘std::vector, 
> std::allocator > >::iterator’ {aka 
> ‘__gnu_cxx::__normal_iterator*, 
> std::vector, std::allocator > 
>  > >’} changed in GCC 7.1
> vector<_Tp, _Alloc>::
> ^~~
> /usr/include/c++/8/bits/vector.tcc:672:7: note: parameter passing for 
> argument of type ‘__gnu_cxx::__normal_iterator std::complex*, std::vector, 
> std::allocator > > >’ changed in GCC 7.1
> /usr/include/c++/8/bits/vector.tcc:672:7: note: parameter passing for 
> argument of type ‘__gnu_cxx::__normal_iterator std::complex*, std::vector, 
> std::allocator > > >’ changed in GCC 7.1
> ^Cmake[2]: *** 
> [gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/build.make:63: 
> gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx.o]
>  
> Interrupt
> make[1]: *** [CMakeFiles/Makefile2:1497: 
> gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/all] Interrupt
> make: *** [Makefile:141: all] Interrupt
> 
> I checked the memory space with 'df' and still have over 25GB available, 
> so that shouldn't be a problem.
> 
> What do you suggest?
> 
> Thanks,
> ---
> Barry Duggan

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

Re: [Discuss-gnuradio] Build GR 3.8 from source

[Michael Dickens]

Here are the (current) key issues:
{{{
-- Python checking for click - found
-- Python checking for click-plugins - not found
}}}

These are Python packages. If you get them installed hopefully the "cmake" 
command will finish & you can get on with building from source! - MLD

On Sat, Jul 20, 2019, at 6:56 PM, Barry Duggan wrote:
> I used """cmake -DENABLE_GR_UHD=OFF -DCMAKE_INSTALL_PREFIX="/usr/local" 
> -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > 
> cmake_out.txt 2>&1""". The file is attached.
> 
> There are several 'missing' packages, but I don't know which ones are 
> important.
> ---
> Barry Duggan
>
> Attachments:
> * cmake_out.txt

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