Seeking RF ML Demos for IEEE's new ICMLCN Conference in May 2024

[Tim O'Shea]

Dear Fellow GNU Radio Hackers,



If you’re working in the RF ML space and have a relatively recent demo of
applied work in this area (possibly even using GNU Radio!), please consider
submitting it to IEEE’s first ever flagship ComSoc conference focused on
the intersection of ML and communications systems (ICMLCN), where we’ve
extended our call for demo proposals below through Nov 30th!  Apologies if
you have already seen or received this, I wouldn't normally post CFP's to
this list, but this is potentially highly aligned with some folks building
cool things in the community!



Thanks & Cheers,

Tim






IEEE International Conference on Machine Learning for Communication and
Networking (ICMLCN) 2024 solicits proposals for demonstrations at the first
ever IEEE ComSoc flagship conference dedicated to machine learning and
communications networks, to be held in Stockholm, May 2024.



While ICMLCN will host a wide range of activities focusing on the
intersection of machine learning and communications networks from theory to
practice, there is no better place to demonstrate new data-driven methods
and ideas than in the real world. As such, we would like to invite the
submission of abstracts for proposed demonstrations from industry,
academia, and elsewhere, which bring concepts from machine learning
communications networks into live demonstrations, prototypes, and which can
be shown and measured.



The demo proposals will be reviewed based on its novelty; significance of
implementation; relevance to ICMLCN scope; potential impact on the
audience; quality of implementation.



Please submit an extended abstract (2 pages) on your proposed demonstration
to https://edas.info/N31472


Abstracts must be received by November 30th, 2023.


Please see additional details at
https://icmlcn2024.ieee-icmlcn.org/authors/call-demo-proposals if this is
of interest!

SPAWC21: ML for Multi-Domain Localization and Signal Recognition Data Competition Call for Participation!

[Tim O'Shea]

Call for IEEE SPAWC Data Competition Paper Submissions & Competitors!

===

IEEE Workshop on Signal Processing Advances in Wireless Communications (SPAWC) 
2021
September 27 – 30, 2021  --   Lucca, Italy (And Online Hybrid Event)

===

SPAWC is hosting two exciting data competition this year at the intersection of 
wireless communications and machine learning and soliciting competitors both 
through paper submissions on approaches to these problems and through direct 
participation in the competitions through submission of scored results.

We will accept the submission of full papers with proposed approaches and 
solutions to the data competition problem statements and datasets through July 
5th and will accept competition solution entries through the beginning of the 
conference on September 27th through the data competition sites hosted on 
Kaggle and eval.ai.

Full details for the data competition event may be found at the official 
conference website at https://www.spawc2021.com/data-competition/
Challenge #1 (Industrial Multi-Domain Localization) focuses on Industry 4.0 
centric robust and versatile positioning of robotic devices using a combination 
of Camera-based, IMU-Based and ultra-wideband (UWB) based data observations 
requiring the fusion of multiple domains of observation to maximize precision.  
As robust and precise radio emitter localization is a key component in future 
industry and factory applications, we are excited to launch this data-driven 
challenge as part of SPAWC 21.
https://www.kaggle.com/c/ieeespawc21localization/data

Challenge #2 (Wideband Signal Recognition) focuses on rapid spectrum awareness 
and signal recognition to enable radio spectrum access coordination, anomaly 
detection, spectrum sharing, spectrum analytics and spectrum monitoring 
applications.  As real-time spectrum awareness and spectrum aware decision 
making may be key components to beyond-5G and 6G communications systems, we are 
excited to launch this data-driven signal recognition competition as part of 
SPAWC this year to compare and contrast new promising approaches to the problem.
https://eval.ai/web/challenges/challenge-page/1057/overview

Both address key challenge areas where machine learning has demonstrated 
extremely promising initial results in related areas, but where we believe 
these datasets provide an exciting new step in expanding these results to 
multi-domain and to broad recognition challenges beyond what has been the 
principal focus in research publications thus far.   Thus, we hope by posing 
these two challenges we can excite new researchers to propose, compare and 
publish new approaches to these problems which can help accelerate and mature 
these domains at the intersection of communications systems and machine 
learning.

We’re soliciting full workshop papers via EDAS 
(https://edas.info/newPaper.php?c=28267) from competitors wishing to publish 
their approaches and ideas as well as competition submissions via Kaggle and 
eval.ai which may be submitted directly via the competition websites above 
until the beginning of the Conference event.

Best Regards,
Tim O’Shea
Data Competition Chair, SPAWC21

[Deadline Extended!] Re: Open Workshop on Machine Learning in Communications @ IEEE ICC 2020 (Call for Contributions)

[Tim O'Shea]

ine learning techniques for non-linear signal processing
> · Low-complexity and approximate learning techniques and power reduction 
> applications
> · Machine learning for edge Intelligence, sensing platforms, and sense making
> · Algorithmic advances in machine learning for communication systems
> · Advancing the joint understanding of information theory, capacity, 
> complexity and machine learning communications systems
> · Machine learning methods for exploiting complex spatial, traffic, channel, 
> traffic, power and other distributions more effectively using measurement vs 
> idealized distributions.
> · Compression of neural networks for low-complexity hardware implementation
> · Unsupervised, semi-supervised and self-supervised learning approaches to 
> communications
> 
> ===
> Important Dates
> ===
> Paper submission deadline: January 27, 2020
> Notification of acceptance: February 20, 202
> Camera-ready papers: March 1, 2020
> ===
> Paper Submission
> ===
> The workshop accepts only novel, previously unpublished papers. The page 
> length limit for all initial submissions for review is SIX (6) printed pages 
> (10-point font) and must be written in English. Initial submissions longer 
> than SIX (6) pages will be rejected without review. All final submissions of 
> accepted papers must be written in English with a maximum paper length of six 
> (6) printed pages (10-point font) including figures. No more than one (1) 
> additional printed page (10-point font) may be included in final submissions 
> and the extra page (the 7th page) will incur an over length page charge of 
> USD100. For more information, please see IEEE ICC 2020 official website: 
> https://icc2020.ieee-icc.org/authors/call-workshop-papers 
> <https://icc2020.ieee-icc.org/authors/call-workshop-papers>
> 
> EDAS submission link: https://edas.info/newPaper.php?c=26827 
> <https://edas.info/newPaper.php?c=26827>
> Please note we are also accepting submissions for live demonstrations and 
> prototype systems in the ML-Comms area via abstract as well! Please see the 
> full CFP pdf on the workshop webpage for additional details!
> 
> ===
> Workshop Organizers
> ===
> · Tim O'Shea, DeepSig & Virginia Tech, US
> · Elisabeth de Carvalho, Aalborg University, DK
> · Jakob Hoydis, Nokia Bell Labs, FR
> · Marios Kountouris, EURECOM, FR
> · Zhi Ding, UC Davis, US
> ===
> MLC ViWi Dataset/Competition Organizers
> ===
> · Ahmed Alkhateeb, Arizona State University, US
> · Muhammad Alrabeiah, Arizona State University, US

Re: [Discuss-gnuradio] gr-eventstream OOT module

[Tim O'Shea]

On 04/17/2017 05:26 PM, Cinaed Simson wrote:

Hi - anyone using gr-eventstream?

If I recall correctly, gr-eventstream depends upon

   gr-mapper
   gr-framers
   gr-burst
   python-bitarray


it does not depend on any of these


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

Re: [Discuss-gnuradio] Asynchronous source with zeros in between

[Tim O'Shea]

You may want to look at gr-eventstream source block, this is exactly what
it is intended to do, precisely timed if desired


On Mon, Nov 30, 2015, 2:38 PM Francisco Albani 
wrote:

> Hi to all.
>
> (this email subject may be inaccurate)
>
> I need a block with the following characteristics:
>
> * Input port for messages.
> * Output port for complex/float/byte/etc. stream.
> * Forecast always answers 0.
> * Work function first check the message queue. If there are no messages,
> emits zeros; if there are, it emits the samples inside the message.
>
> I'm willing to write it, but first I want to hear from the people in the
> list in case this can be crafted using existing blocks or if this idea is
> deemed to fail for some reason I can't see.
>
> I need this in order to transmit N parallel burst radios using something
> like Polyphase Channel Synthesizer. The problem emerges when not all the
> transmitters have data to send and stop the other transmitters flows.
>
> Many thanks!
>
> Bye.
> ___
> 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] Message inputs and hierachical block: incompatibility introduced in GNU Radio 3.7.9

[Tim O'Shea]

Hi Piotr,

Hier message ports were actually not working at all prior to this fix -
- since the logic had been changed from the originally functioning pub/sub
based message connection data structures into the more traditional digraph
flattening structure incorrectly
please see:  http://gnuradio.org/redmine/issues/862#change-2460

This change was needed to correct the hier port flattening logic
and was the originally intended API that got reversed somewhere along the
way -
GRC was updated to correspond --
Have you tested your hier message ports actually function with 3.7.8
successfully prior to this?  I would be kind of surprised -
Perhaps if you are writing python code, some kind of conditional check work
around might be in order, or just dropping support for old versions as they
did not function correctly

-Tim



On Sat, Jan 2, 2016 at 4:12 AM Piotr Krysik  wrote:

> Hi all,
>
> In GNU Radio version 3.7.8 message inputs of hierarchical blocks were
> created from python level with:
>self.message_port_register_hier_out("msg_in")
>
> Starting (most probably) from GNU Radio 3.7.9 message inputs are created
> with:
>self.message_port_register_hier_in("msg_in")
>
> This leads to incompatibility. I can't now distribute to the users
> python code of hierarchical blocks generated with GRC because for some
> of them it won't work (if they don't use the same GNU Radio version as I
> do). Compilation of GRC files to python with grcc during building is not
> an option as it doesn't work reliably yet and it will lead to higher
> level of problems.
>
> Currently I manually added this code to my hierarchical blocks in order
> to make them work on with GNU Radio earlier than 3.7.9:
>
>   from distutils.version import LooseVersion as version
>
>   if version(gr.version()) >= version('3.7.9'):
> self.message_port_register_hier_in("msg_in")
>   else:
> self.message_port_register_hier_out("msg_in")
>
> Is it possible to fix this problem for example on the level GRC - so it
> generate code that is compatible with GNU Radio versions < 3.7.9 and
> >=3.7.9?
>
> Best Regards,
> Piotr Krysik
>
> ___
> 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] Renaming PyBOMBS

[Tim O'Shea]

Most new users should be installing gnu radio binaries via their os package
manager repos or ppa.   Pybombs should be used for 1. Helping get up to
date oot modules set up and deployed ( like pip ) and 2. Helping developers
set up their development environment.
So I'm not sure installer is the right idea to impart on new users at all

On Wed, Dec 23, 2015, 1:23 PM Richard Bell  wrote:

> I'd like to throw in another point from an entry level perspective. Those
> people who might need pybombs most, are those who need names that tell them
> what it's for the most. Even if it is incorrect to call pybombs an
> installer, it would really help the entry level folks (which I would claim
> without support is the largest population of the community at any given
> time) understand what it's for and how they should use it. I think we all
> have the experience of learning new tools and running into tool names,
> which even though the description is spot on for what its for, at the time
> carried zero value for the new guy using it (thinking mostly about Xilinx
> tool names here).
>
> With that said, I think it would be good for the community to use the word
> installer in the tool that makes gnuradio and uhd really easy to install,
> and is what the vast majority of people I'm guessing would use it for.
>
> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun 
> wrote:
>
>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>> > I don't want to destroy your idea, but GRAB sounds like CRAP as well and
>> > you can think of the associated sentences ;)
>>
>> 'grab' is also a very common english verb, so I think people would be
>> able to distinguish. It also sounds like 'crab' if you like :)
>>
>> M
>>
>> >
>> > On 12/22/2015 09:31 PM, Richard Bell wrote:
>> >> GRAB = Gnu RAdio Basic installer
>> >>
>> >> Then we can say things like "Go GRAB it" when referring to a needed
>> module
>> >>
>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun > >
>> >> wrote:
>> >>
>> >>> There's been some demand to rename PyBOMBS, and now that we're
>> >>> re-releasing it, this is a good time to think about it. Complaints
>> about
>> >>> the name include:
>> >>>
>> >>> - It may or may not be true that people have been detained by TSA for
>> >>> working on PyBOMBS at the airport[1]
>> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>> >>> rather than a GNU Radio-related tool
>> >>> - People can't agree on a capitalization
>> >>> - No one can remember what the acronym stands for
>> >>>
>> >>> Sure, this is not a critical thing, but now's a good chance to bring
>> it
>> >>> up and also, this is not a joke :)
>> >>>
>> >>> Here's how we're going to do this:
>> >>>
>> >>> - Please suggest new names in this thread.
>> >>> - I will choose from those names based on 'can I live with this name',
>> >>> 100% subjectively.
>> >>> - New names will be put up for a vote. This will include an option to
>> >>> keep the old name.
>> >>> - Finally, the result of the vote will be used as a strong suggestion
>> on
>> >>> what the new name will be.
>> >>>
>> >>> There already have been some suggestions:
>> >>>
>> >>> - gromit -- the GNU Radio out-of-tree module installation tool
>> >>> - the groot
>> >>> - grpm -- the GNU Radio package manager
>> >>>
>> >>>
>> >>> OK guys, bring up the ideas!
>> >>>
>> >>> Cheers,
>> >>> Martin
>> >>>
>> >>> [1] It's not.
>> >>>
>> >>> ___
>> >>> Discuss-gnuradio mailing list
>> >>> Discuss-gnuradio@gnu.org
>> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>>
>> >>
>> >>
>> >>
>> >> ___
>> >> Discuss-gnuradio mailing list
>> >> Discuss-gnuradio@gnu.org
>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim O'Shea]

Ubuntu packages uhd
Assuming other oses do too
I'm sure there are up to date ppas somewhere too

On Wed, Dec 23, 2015, 1:34 PM Richard Bell <richard.be...@gmail.com> wrote:

> Is there a way for a new user to get uhd installed from the package
> manager though? A lot of people want to dive right into gnu radio with
> hardware, doing simple things like spectrum analysis. I'm not aware of a
> way of getting the uhd + gnuradio setup running that's easier then pybombs.
> I very well could be wrong here.
>
> On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea <tim.oshea...@gmail.com>
> wrote:
>
>> Most new users should be installing gnu radio binaries via their os
>> package manager repos or ppa.   Pybombs should be used for 1. Helping get
>> up to date oot modules set up and deployed ( like pip ) and 2. Helping
>> developers set up their development environment.
>> So I'm not sure installer is the right idea to impart on new users at all
>>
>>
>> On Wed, Dec 23, 2015, 1:23 PM Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> I'd like to throw in another point from an entry level perspective.
>>> Those people who might need pybombs most, are those who need names that
>>> tell them what it's for the most. Even if it is incorrect to call pybombs
>>> an installer, it would really help the entry level folks (which I would
>>> claim without support is the largest population of the community at any
>>> given time) understand what it's for and how they should use it. I think we
>>> all have the experience of learning new tools and running into tool names,
>>> which even though the description is spot on for what its for, at the time
>>> carried zero value for the new guy using it (thinking mostly about Xilinx
>>> tool names here).
>>>
>>> With that said, I think it would be good for the community to use the
>>> word installer in the tool that makes gnuradio and uhd really easy to
>>> install, and is what the vast majority of people I'm guessing would use it
>>> for.
>>>
>>> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com>
>>> wrote:
>>>
>>>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>>>> > I don't want to destroy your idea, but GRAB sounds like CRAP as well
>>>> and
>>>> > you can think of the associated sentences ;)
>>>>
>>>> 'grab' is also a very common english verb, so I think people would be
>>>> able to distinguish. It also sounds like 'crab' if you like :)
>>>>
>>>> M
>>>>
>>>> >
>>>> > On 12/22/2015 09:31 PM, Richard Bell wrote:
>>>> >> GRAB = Gnu RAdio Basic installer
>>>> >>
>>>> >> Then we can say things like "Go GRAB it" when referring to a needed
>>>> module
>>>> >>
>>>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun <
>>>> martin.br...@ettus.com>
>>>> >> wrote:
>>>> >>
>>>> >>> There's been some demand to rename PyBOMBS, and now that we're
>>>> >>> re-releasing it, this is a good time to think about it. Complaints
>>>> about
>>>> >>> the name include:
>>>> >>>
>>>> >>> - It may or may not be true that people have been detained by TSA
>>>> for
>>>> >>> working on PyBOMBS at the airport[1]
>>>> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>>>> >>> rather than a GNU Radio-related tool
>>>> >>> - People can't agree on a capitalization
>>>> >>> - No one can remember what the acronym stands for
>>>> >>>
>>>> >>> Sure, this is not a critical thing, but now's a good chance to
>>>> bring it
>>>> >>> up and also, this is not a joke :)
>>>> >>>
>>>> >>> Here's how we're going to do this:
>>>> >>>
>>>> >>> - Please suggest new names in this thread.
>>>> >>> - I will choose from those names based on 'can I live with this
>>>> name',
>>>> >>> 100% subjectively.
>>>> >>> - New names will be put up for a vote. This will include an option
>>>> to
>>>> >>> keep the old name.
>>>> >>> - Finally, the result of the vote will be used as a strong
>>>> 

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim O'Shea]

IMO it is generally nice to have a unique googleable name for an
application which doesn't result in five trillion unrelated Google
results.  While short acronyms will have false positives, names like "grab"
or any standard English words are generally bad choices from this point of
view
Grpm and the like seem fairly unique - pybombs was a win by this measure

On Wed, Dec 23, 2015, 1:02 PM Martin Braun  wrote:

> On 23.12.2015 09:28, Stefan Wunsch wrote:
> > I don't want to destroy your idea, but GRAB sounds like CRAP as well and
> > you can think of the associated sentences ;)
>
> 'grab' is also a very common english verb, so I think people would be
> able to distinguish. It also sounds like 'crab' if you like :)
>
> M
>
> >
> > On 12/22/2015 09:31 PM, Richard Bell wrote:
> >> GRAB = Gnu RAdio Basic installer
> >>
> >> Then we can say things like "Go GRAB it" when referring to a needed
> module
> >>
> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun 
> >> wrote:
> >>
> >>> There's been some demand to rename PyBOMBS, and now that we're
> >>> re-releasing it, this is a good time to think about it. Complaints
> about
> >>> the name include:
> >>>
> >>> - It may or may not be true that people have been detained by TSA for
> >>> working on PyBOMBS at the airport[1]
> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
> >>> rather than a GNU Radio-related tool
> >>> - People can't agree on a capitalization
> >>> - No one can remember what the acronym stands for
> >>>
> >>> Sure, this is not a critical thing, but now's a good chance to bring it
> >>> up and also, this is not a joke :)
> >>>
> >>> Here's how we're going to do this:
> >>>
> >>> - Please suggest new names in this thread.
> >>> - I will choose from those names based on 'can I live with this name',
> >>> 100% subjectively.
> >>> - New names will be put up for a vote. This will include an option to
> >>> keep the old name.
> >>> - Finally, the result of the vote will be used as a strong suggestion
> on
> >>> what the new name will be.
> >>>
> >>> There already have been some suggestions:
> >>>
> >>> - gromit -- the GNU Radio out-of-tree module installation tool
> >>> - the groot
> >>> - grpm -- the GNU Radio package manager
> >>>
> >>>
> >>> OK guys, bring up the ideas!
> >>>
> >>> Cheers,
> >>> Martin
> >>>
> >>> [1] It's not.
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>
> >>
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim O'Shea]

Python build overlay managed bundle system


On Tue, Dec 22, 2015, 4:47 PM Donald Pupecki  wrote:

> I like GRPM - GnuRadio Package Manager.
>
> Can never remember what pybombs stands for anyway.
> On Dec 22, 2015 3:10 PM, "Martin Braun"  wrote:
>
>> There's been some demand to rename PyBOMBS, and now that we're
>> re-releasing it, this is a good time to think about it. Complaints about
>> the name include:
>>
>> - It may or may not be true that people have been detained by TSA for
>> working on PyBOMBS at the airport[1]
>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>> rather than a GNU Radio-related tool
>> - People can't agree on a capitalization
>> - No one can remember what the acronym stands for
>>
>> Sure, this is not a critical thing, but now's a good chance to bring it
>> up and also, this is not a joke :)
>>
>> Here's how we're going to do this:
>>
>> - Please suggest new names in this thread.
>> - I will choose from those names based on 'can I live with this name',
>> 100% subjectively.
>> - New names will be put up for a vote. This will include an option to
>> keep the old name.
>> - Finally, the result of the vote will be used as a strong suggestion on
>> what the new name will be.
>>
>> There already have been some suggestions:
>>
>> - gromit -- the GNU Radio out-of-tree module installation tool
>> - the groot
>> - grpm -- the GNU Radio package manager
>>
>>
>> OK guys, bring up the ideas!
>>
>> Cheers,
>> Martin
>>
>> [1] It's not.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim O'Shea]

Cutesy acronym grumblings aside on this one, If all you wanted to do was
install gnu radio, apt, rpm, our emerge would do.   IMO pybombs seems more
about indexing, installing, setting up development environments, and
updating out of tree modules - "grin" implied scope is a small subset
thereof

On Tue, Dec 22, 2015, 10:02 PM Neel Pandeya <neel.pand...@ettus.com> wrote:

> Also perhaps:
>
> GRIN = Gnu Radio INstaller
>
>
>
> On 22 December 2015 at 15:37, Martin Braun <martin.br...@ettus.com> wrote:
>
>> Another suggestion from #gnuradio was 'grapple'.
>>
>> M
>> On 22 Dec 2015 15:12, "Neel Pandeya" <neel.pand...@ettus.com> wrote:
>>
>>> My vote would be for one of these:
>>>
>>> GRPM = GnuRadio Package Manager
>>>
>>> GRAB = Gnu RAdio Basic installer
>>>
>>> GRBI =
>>> ​​
>>> Gnu Radio Basic Installer
>>>
>>> I agree with Tim O'Shea, the name should be something short and
>>> functional, and give an idea of what it does, instead of being cutesy and
>>> contrived.
>>>
>>> --Neel
>>>
>>>
>>>
>>>
>>> On 22 December 2015 at 12:10, Martin Braun <martin.br...@ettus.com>
>>> wrote:
>>>
>>>> There's been some demand to rename PyBOMBS, and now that we're
>>>> re-releasing it, this is a good time to think about it. Complaints about
>>>> the name include:
>>>>
>>>> - It may or may not be true that people have been detained by TSA for
>>>> working on PyBOMBS at the airport[1]
>>>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>>>> rather than a GNU Radio-related tool
>>>> - People can't agree on a capitalization
>>>> - No one can remember what the acronym stands for
>>>>
>>>> Sure, this is not a critical thing, but now's a good chance to bring it
>>>> up and also, this is not a joke :)
>>>>
>>>> Here's how we're going to do this:
>>>>
>>>> - Please suggest new names in this thread.
>>>> - I will choose from those names based on 'can I live with this name',
>>>> 100% subjectively.
>>>> - New names will be put up for a vote. This will include an option to
>>>> keep the old name.
>>>> - Finally, the result of the vote will be used as a strong suggestion on
>>>> what the new name will be.
>>>>
>>>> There already have been some suggestions:
>>>>
>>>> - gromit -- the GNU Radio out-of-tree module installation tool
>>>> - the groot
>>>> - grpm -- the GNU Radio package manager
>>>>
>>>>
>>>> OK guys, bring up the ideas!
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> [1] It's not.
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Tim O'Shea]

You may also want to have a look at
http://stats.gnuradio.org/
To get a feel for how fast different sdr kernels run on different
processing platforms

Tim

On Fri, Aug 7, 2015, 11:47 AM Tom Cook tom.k.c...@gmail.com wrote:

 I'm brand new to SDR and I'm just trying to calibrate my expectations of
 what will be possible in real time.  I'm hoping someone here can give me a
 pointer or two.

 I'm running GNU Radio 3.7.2 on Ubuntu 14.04, having installed from the
 Ubuntu repositories.  The machine I'm using has an Intel Core i5-2520M
 running at 2500MHz.

 I'm constructing flowgraphs in GRC and using an RTL-2832U-based USB dongle
 as a receiver.

 I've built a fairly simple broadcast FM stereo receiver as an example.  It
 has the following components:
 * RTL-SDR source (768k sample rate).
 * Low pass filter (768k sample rate, 96k cutoff, 4k transition)
 * Rational resampler (4x decimation)
 * WBFM receiver (quadrature rate 192k)
 * Low pass filter (1x decimation, 192k sample rate, 15k cutoff, 2k
 transition)
 * 2x Band pass filter (1x decimation, 192k sample rate, differing cutoff
 and transition)
 * Multiply
 * Low pass filter (192k sample rate, 15k cutoff, 2k transition)
 * Add, subtract
 * 2 x rational resampler (4x decimation)
 * Audio sink (sample rate 48k)

 My system is not able to run this in realtime, producing regular underruns
 (about two per second).  Decreasing the receiver sample rate to 384k and
 decreasing the decimation factor in the first resampler to 2 allows it to
 run in without underruns, from which I deduce that the CPU is right on the
 edge of being able to process the flowchart in realtime.

 Are my expectations of what I'll be able to do in realtime unreasonably
 high?  Is there something I'm missing, that I can do to make this run much
 faster?

 Thanks,
 Tom
 ___
 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] Updating GNU Radio, UHD or PyBOMBS

[Tim O'Shea]

Try running
Pybombs clean gnuradio
Pybombs clean uhd
And then installing

-Tim
On Oct 31, 2014 11:53 AM, Richard Bell richard.be...@gmail.com wrote:

 I'm still asking for help with this maintenance process. I tried the
 './pybombs remove' command to get rid of uhd and gnuradio as a test. I
 didn't get any error or warnings and it completed. When I looked in the
 pybombs/src folder, both gnuradio and uhd folders still existed there. I
 deleted them by hand. I then tried the './pybombs install uhd' command to
 reinstall uhd, but pybombs seems to think it's installed.

 I'm really at a loss as to how I'm supposed to do things here. I think in
 theory, pybombs would make all of this painless, but I've either done
 something terribly wrong and screwed pybombs up at this point, or it's not
 working as intended.

 What should I do at this point to fresh install with pybombs? I checked
 the packages I have installed on my ubuntu and I don't see gnuradio or uhd
 in the list, which is good. If I deleted the pybombs folder and start over
 from there, would you expect a clean installation at that point? Is that
 what Martin meant by Just reinstall it?

 Thanks,
 Rich

 On Wed, Oct 29, 2014 at 4:06 PM, Martin Braun martin.br...@ettus.com
 wrote:

 Just reinstall it. No hassle :)

 M

 On 10/29/2014 11:07 PM, Richard Bell wrote:
  Well, I can tell you that I deleted the gnuradio build directory and
  then executed ./pybombs update to see if it would start the build
  process. It did not. As of now I'm not really sure what ./pybombs update
  does. The wiki leads me to believe it's supposed to do the pull and
  build process, link below to explanation of ./pybombs update.
 
  http://gnuradio.org/redmine/projects/pybombs/wiki/Using
 
  Unfortunately, the wiki also recommends that we don't update each recipe
  manually, because we could break a dependency. So at this point, I'm
  still not sure what I'm supposed to do to update my install when new
  versions of gnuradio or uhd come out. Can someone with experience in
  this flow chime in for me. Much appreciated.
 
  Rich
 
  On Wed, Oct 29, 2014 at 2:46 PM, Martin Braun martin.br...@ettus.com
  mailto:martin.br...@ettus.com wrote:
 
  On 10/29/2014 09:32 PM, Richard Bell wrote:
   Thanks Martin, but I'm still unsure of this process.
  
   1) I tried using ./pybombs update, but it doesn't look like it
 initiated
   a build process on anything. Did you mean to imply it would do
 that, or
   just the git pull process for gnuradio and uhd?
 
  Hm, I thought that's what it would do. Maybe it just git pulls.
 
   2) There is no build directory in uhd, like there was in
 gnuradio. From
   the pybombs/src/uhd directory where do I need to be to execute
 make and
   sudo make install?
 
  You sure? Maybe pybombs/src/uhd/host/build ?
 
   3) There is also no build directory in pybombs, where should I
 execute
   make and sudo make install?
 
  That you just git pull. It's pure Python, and doesn't get
 installed, so
  it just needs a build process.
 
  M
  
   Thanks,
   Rich
  
  
   On Wed, Oct 29, 2014 at 1:18 PM, Martin Braun 
 martin.br...@ettus.com mailto:martin.br...@ettus.com
   mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com
  wrote:
  
   Sometimes it's safer to clear the build dir, usually it's OK
  to leave
   in. If you have any cmake variables set, you'll need to reset
  them if
   you clear the dir.
  
   UHD is updated the same way. In all cases, it depends where
 you
   installed your stuff.
  
   pybombs can do all this for you, by the way: ./pybombs update
  
   ...although I don't think this will update pybombs itself.
  
   M
  
   On 10/29/2014 08:53 PM, Richard Bell wrote:
Hi all,
   
I am new to all of this, so I'm looking for some guidance. I
  recently
setup UHD and GNURadio using PyBOMBS on Ubuntu 14.04. I now
  want to do a
git pull and update my stuff. I'm not sure what commands to
  execute
after I do the git pull for each.
   
For example, I found two different recommendations for
  updating gnuradio
after a git pull
   
First way:
   
*git pull
*
*rm -Rf build
*
*mkdir build
*
*cd build
*
*cmake ../
*
*make
*
*sudo make install*
   
Second way:
   
*git pull
*
*cd build
*
*make
*
*sudo make install*
   
Is the removal of the existing build directory and cmake
  command necessary?
   
After 

Re: [Discuss-gnuradio] PyBombs install maint branch from fresh

[Tim O'Shea]

Martin,
You are probably right we should track maint by default at this point.I
think it's worth adding a Pybombs environment question about which branch
to track during initial setup for those that prefer to track master
however.
Tim
 On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote:


 On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com
 wrote:

 On 07/23/2014 07:14 AM, Activecat wrote:
  Dear Sirs,
 
  I am performing fresh gnuradio installation using pybombs.
  Pybombs install master branch by default.
  How to make pybombs install 'maint' instead?
 
  Act@rsLAPTOP: ~/download/pybombs $ git checkout maint
  error: pathspec 'maint' did not match any file(s) known to git.

 This is not how you use git; you need to give it a remote branch to
 track first. Also, if you checked out 'maint' on pybombs, it wouldn't
 necessarily check out 'maint' on any SW package it's trying to install.

 I assume you're trying to install GNU Radio maint, right? I guess one
 way would be to modify the gnuradio.lwr recipe, change the default
 branch to maint.

 M



 Thanks.
 yes, I am trying to install GNU Radio maintenance branch.
 I will change the gitbranch of gnuradio.lwr recipe to 'maint'.
 Does this means the uhd.lwr also need to be 'maint', or can just be
 'master' as default?

 ___
 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] Trouble building stuff with build-gnuradio

[Tim O'Shea]

I'm not sure its the job of a build system to clean up the broken state
left by either not running uninstall previously or an incomplete uninstall
routine - this strikes me as a bit of a hackish solution to a more general
problem
Rather than worry about this I would like to see people who build GNU Radio
from source repos start using prefixed builds more
this is generally a much cleaner practice as if you are done with a certain
build (say 3.5 or 3.6 now that 3.7 is out) you can simply blow away the
whole prefix dir.
This generally also ensures that any dependent GR OOT modules you have
built against that version of GNU Radio live in the same version prefix so
for instance if you are blowing away gr3.5 you blow away the whole gr3.5
prefix including any OOT modules linked against gr3.5 and are forced to
rebuild them in your newer prefix
pybombs does help enable this by forcing you to specify the prefix when it
is first run - and while /usr/local/ is the default in keeping with the
default prefix used everywhere else in linux - it is a pretty poor choice
due to its shared nature and something like /usr/local/gr3.7/ would be a
better choice.
-Tim


On Mon, Jul 1, 2013 at 7:51 PM, Marcus D. Leech mle...@ripnet.com wrote:

 If you've been having trouble today getting a successful build out of
 build-gnuradio, please update your copy of build-gnuradio and try again.

 The main branch was updated to 3.7.0 and I didn't know that, so
 build-gnuradio was dutifully fetching main, and then fetching various
   OOT modules (gr-osmosdr, gr-iqbal, etc) at their 3.6 API versions, and
 the result was an explosion of build failures.

 Also, the previous 3.7 build left little bits of deadly detritus lying
 around in /usr/local/include/gnuradio which would then cause subsequent
   3.6 OOT module builds to fail, depsite GR having been changed back to
 3.6.

 So, build-gnuradio now deals with said detritus prior to doing the make
 install inside the actual Gnu Radio build bits.

 I sure hope the pybombs folks are paying attention :) :)


 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org


 __**_
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] anyone implement the Raleigh fading model / multi-path?

[Tim O'Shea]

There are currently two fading model blocks that are usable in 3.7
both should show up in GRC - or from python you can use:

the flat fading model:
channels.fading_model( 8, 10.0/samp_rate, False, 4.0, 0 )
where args are {# sinusoids, fDTs, los_component, rician_factor,
prng_seed }

and a simple frequency selective fading model combining N flat fading
channels of a fixed PDP:
channels.selective_fading_model( 8, 10.0/samp_rate, False, 4.0, 0,
(0.0,0.1,1.3), (1,0.99,0.97), 8 )
where args are {# sinusois, fDTs, los_component, rician_factor,
prng_seed, power_delay_profile_delays_samples,
power_delay_profile_amplitudes, max_channel_taps}

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

Re: [Discuss-gnuradio] issue with GRC on ubuntu 12.10 - Segmentation Fault when launching the tool

[Tim O'Shea]

Another simple workaround is importing _io before the gnuradio swig modules
are imported
ultimately fixing the underlying swig problem is the right thing to do

diff --git a/grc/scripts/gnuradio-companion b/grc/scripts/gnuradio-companion
index e76322b..7da73fd 100755
--- a/grc/scripts/gnuradio-companion
+++ b/grc/scripts/gnuradio-companion
@@ -18,6 +18,7 @@ along with this program; if not, write to the Free
Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
USA
 

+import _io
 import pygtk
 pygtk.require('2.0')
 import gtk








On Fri, Oct 19, 2012 at 10:33 PM, Tom Rondeau t...@trondeau.com wrote:

 Johnathan Corgan and I /might/ have tracked down the problem. Please
 check out the branch 'rtld_ticket181_undo' on my github git repo:
 git://github.com/trondeau/gnuradio.git


 This undoes something that was put in a while ago to make up for a
 problem with exceptions in SWIG. We think that a) SWIG now handles
 this stuff better and b) someone (ld, Python, stdc, etc., etc.) have
 updated their behavior to cause a conflict with how things run. On my
 12.10 box, this patch allows me to run GRC again. Also, I could not
 run 'from gnuradio import audio' before but can now.

 This is a bit touchy since this code has been in here for so long.
 We're concerned that people might be relying on it and that removing
 it could cause some other, unknown behavior. At the same time, getting
 GRC to run again is a pretty big deal.

 Please check out and test the branch and let me know how it works on
 your currently broken systems or on your currently working system to
 see if it breaks anything. This was branched off today's master
 branch.

 Tom

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

Re: [Discuss-gnuradio] which math library to link with

[Tim O'Shea]

gsl


On Dec 1, 2011, at 4:56 PM, Achilleas Anastasopoulos anas...@umich.edu wrote:

 We are writing a block that requires SVD of matrices.
 Is there a preferred library (eg, LAPACK) that other gnuradio blocks
 are already using that we can link with.
 I don't want to add another library dependence...
 
 thanks
 Achilleas
 
 ___
 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