Re: GsoC Proposal Feedback

[Andrej Rode]

Hi Hamza, 

sorry for the late reply/not giving you feedback earlier. I’ve been travelling 
in the last week(s) and it slipped my attention. 

Your proposal seems to already go a lot into details how to include the AFF3CT 
library in GNU Radio in terms of pointers etc. 
It seems to me that your plan would be to fully replace existing 
implementations with AFF3CT. I would recommend to either add them
in a GNU Radio OOT first or add them side-by-side to existing 
Encoders/Decoders, as overall we might opt to make AFF3CT an optional
dependency and also it would aid in benchmarking (not only for you, but also 
other community members).
With this idea on the ideas’ list we also meant to give some opportunity to 
find other error correcting libraries, e.g. https://github.com/xdsopl/LDPC 
which show good performance and may be directly integrated in GNU Radio. 

In terms of timeline I see a small discrepancy, since you say that you will 
spend 30 hours each week, but you can “only" dedicate 3-4 hours per day. 
If you would work 7 days a week (which I do not recommend), will work out at 
21-28 hours a week. 
For the scheduling of the different tasks, I feel that in the beginning you 
left yourself a little bit of room, but then you put the Delivery 1 with moving 
LDPC,TCP,Polar in a timeframe of two weeks, which seems to be quite challenging 
to do in this short time. I guess in case you finish earlier with the 
repetition en/decoders you can already start on the blocks mentioned in this 
delivery.

In terms of reporting, in the past our students wrote short but concise weekly 
blog posts which gave a good turnaround time for feedback from the community. I 
would recommend
the same to you. You can publish blog posts directly on our webpage, which is 
created with the static website generator “hugo” here: 
https://github.com/gnuradio/hugo-website

Some small comments on the form: 
 - You have a lot of typos/transposition errors in your proposal, I recommend 
running it through some error checking
 - It is spelled “GNU Radio” - not gnu-radio, or Gnu radio.

Cheers,
Andrej


> On 28. Mar 2024, at 17:50, Hamza Mohammed  
> wrote:
> 
> Hi all,
> Please take a look at my proposal for the project "Forward Error Correction", 
> that I attached below. Do you think the way I am planning to integrate the 
> AFF3CT library in the gr-fec package is efficient ? I think it is because my 
> implementation will not change the overall FEC API.
> 

Re: GSOC proposal

[Andrej Rode]

Hi Kayla, 

thanks for sharing your current proposal on the forward error correction 
project idea from our GSoC ideas page. 
Overall it looks well written and it contains all required elements.
We have collected some feedback for you: 

 - In the proposal you mention that many of the current FEC blocks in GNU Radio 
are implemented in Python. This is actually not correct, as most FEC is 
implemented in C++ and made available in Python through a wrapper. This is a 
common technique employed throughout GNU Radio and also for new blocks it is a 
requirement to have a Python wrapper (which is easy to implement since GNU 
Radio comes with a framework for that). 

 - It would be very useful to develop a testbench (e.g. with a corresponding 
flowgraph) to compare the performance in terms of throughput, but also error 
correction capability, of existing blocks in GNU Radio with newly 
developed/integrated blocks e.g. using Aff3ct (which duplicate exisiting blocks 
like LDPC or viterbi decoders). 

Cheers,
Andrej

> On 23. Mar 2024, at 10:07, Kayla Comer  wrote:
> 
> Hello, I have attached a draft of my proposal for the forward error 
> correction project. Please let me know what could improve for the final 
> submission
> 
> Best,
> Kayla Comer
> 

Re: My Introduction to the Community

[Andrej Rode]

Hi Amitesh, 

welcome to the discuss-gnuradio mailinglist. Nice that you found your way here. 
Before you start drafting on your proposal I recommend you get a little bit 
familiar with GNU Radio. 
You can do that by looking at our tutorials, which you can find in the wiki and 
through tutorials.gnuradio.org

If you have questions or problems you are welcome to ask here on the 
mailinglist or in our chatroom. We use matrix, if you already have
an account you can join the general chat room through #gnuradio:gnuradio.org 
otherwise you can find some more information here 
https://wiki.gnuradio.org/index.php?title=Chat

Cheers,
Andrej

> On 15. Mar 2024, at 12:03, Amitesh Mahapatra  wrote:
> 
> Greetings!
> 
> I am Amitesh, a driven first year undergrad from Delhi, India. I came across 
> this org and its work through its GSoC listing, and thought I'd check it out! 
> I am figuring out how I can possibly contribute to it.
> I have extensive experience writing C and Python code, although contributing 
> to a project such as this would certainly be a challenge!
> 
> Currently, the ideas titled 'GRC: Build-in sub flowgraphs', 'GRC: Standalone 
> application and pluggable workflows', and 'Revitalize in-tree and out-of-tree 
> (OOT) modules' have caught my attention. I am learning and thinking more 
> about their specific requirements and considering writing a proposal for one 
> of these projects.
> 
> Hoping to make this count, and learn invaluable skills along the way!
> 
> Regards,
> 
> Amitesh
> 
> 

Re: Prospective GSoC contributor introduction

[Andrej Rode]

Hi Kayla,

welcome to the discuss-gnuradio mailinglist. Nice that you found your way here. 
Before you start drafting on your proposal I recommend you get a little bit 
familiar with GNU Radio. 
You can do that by looking at our tutorials, which you can find in the wiki and 
through tutorials.gnuradio.org 

Within GNU Radio you will already find some blocks implementing channel 
codes/error correcting codes. But also a lot of modern codes
and from recent research are missing/not implemented. Other libraries like 
https://aff3ct.github.io/ have verified and fast implementations.
Maybe you find other open source libraries which we can pull in, too!  

If you have questions or problems you are welcome to ask here on the 
mailinglist or in our chatroom. We use matrix, if you already have
an account you can join the general chat room through #gnuradio:gnuradio.org 
otherwise you can find some more information here 
https://wiki.gnuradio.org/index.php?title=Chat

Cheers,
Andrej

> On 11. Mar 2024, at 02:04, Kayla Comer  wrote:
> 
> Hello,
> 
> My name is Kayla, and I am interested in contributing to GNU Radio through 
> GSoC this summer. I finished my BS in EE in December, and I plan to start a 
> PhD program in the communications/networks field in the fall. I learned about 
> GNU Radio through a lab at school, and I think GSoC would be a great 
> opportunity for me to become more comfortable using and modifying the tool. I 
> am drawn to the forward error correction project, as it would allow me to 
> contribute usefully while exploring ideas I will delve into more deeply in 
> grad school. I am currently becoming familiar with the repository, and then I 
> will draft a proposal and ask for feedback. Thank you!
> 
> Best,
> Kayla

Re: GSoC 2024 - Build-in sub flowgraphs

[Andrej Rode]

Hi Ruben, 

welcome to the discuss-gnuradio mailinglist. Nice that you found your way here. 
Before you start drafting on your proposal I recommend you get a little bit 
familiar with GNU Radio. 
You can do that by looking at our tutorials, which you can find in the wiki and 
through tutorials.gnuradio.org

If you have questions or problems you are welcome to ask here on the 
mailinglist or in our chatroom. We use matrix, if you already have
an account you can join the general chat room through #gnuradio:gnuradio.org 
otherwise you can find some more information here 
https://wiki.gnuradio.org/index.php?title=Chat

Cheers,
Andrej

> On 27. Feb 2024, at 05:45, Ruben Arciba  wrote:
> 
> Hi,
> My name is Ruben Arciba. I am a 2nd year Computer Science student. I have 
> experience in Python and Java. I am looking forward to working with you
> 
> Thanks,
> Ruben Arciba

FOSDEM 2022 - Free Software Radio Devroom

[Andrej Rode]

Hi all, 

I’d like to invite you all to join the Free Software Radio Devroom at the 
FOSDEM 2022 online event tomorrow February 6th 2022 at 1300 (CET). 
We have a range of very interesting presentations ranging from project updates, 
implementation of hardware accelerators for Software Radio 
up to receiving communication from the most distant artificial object from 
Earth.

You can find the full schedule here: 
https://fosdem.org/2022/schedule/track/free_software_radio/

You can either join just the livestream of the event, but I really encourage 
you to join the Matrix chat to ask questions you might have and continue 
discussion 
about the presentation after it is finished, you can even join the video call 
for a more direct way of communication. You can find information about the chat 
system here:
https://fosdem.org/2022/practical/online/. If you are already a member of the 
GNU Radio Matrix server, you don’t have to create a new account or anything. 
You can simply visit:
https://matrix.to/#/#space-radio-devroom:fosdem.org to join the dedicated "Free 
Software Radio Devroom space". This space contains the main chatroom during the 
devroom but also
you will find all dedicated presentation chatrooms in there after the 
presentation has finished to continue in-depth discussion.

During the presentation you can ask questions in the chat and upvote questions 
of others, at the end of the presentation there will be a short live Q where 
a presentation host will address said questions directly to the presenter.
If your question is not answered during this time you are welcome to join the 
presentation chatroom to ask yourself.

I hope to “see” many of you tomorrow. And a big thanks for everyone presenting 
or helping to make this Devroom possible this year!

Cheers
Andrej

Re: [CFP] Free Software Radio DevRoom 2022

[Andrej Rode]

Hi all, 

Gentle reminder to submit proposals for presentations about e.g. your own 
projects, FOSS projects updates or other fun hacks you want to talk about. Our 
CfP is still open until (and including) December 26th. Do not hesitate to 
contact any of the Devroom managers if you have questions.  
Presentation slots are not fixed to 30 minutes, if you have some idea for a 
lightning talk we can also fit you in, as well as if you have some longer 
presentation to give. 

If you have creative ideas for a non-presentation format we are eager to hear 
about it.

Cheers,
Andrej

(For the Free Software Radio Devroom Managers)


> On 6. Dec 2021, at 02:04, Andrej Rode  wrote:
> 
> Dear friends and fans of software-defined radio and free/open-source radio 
> topics in general,
> 
> FOSDEM 2022 (the free and open-source developer's meeting usually in 
> Brussels, Europe but **repeatedly virtual**) will again feature a track on 
> Software Defined Radio and any other radio-related topics in the **Free 
> Software Radio** devroom. Therefore, we invite developers and users from the 
> free software radio community to join us for this track and present your 
> work, ideas and/or demos.
> 
> Given the current circumstances and the virtual nature of this event in 2022, 
> we are asking the presenters to pre-record the talks, which will then be 
> gathered by us and streamed during the event. Presenters are also asked to be 
> present online during their timeslot for live Q 
> 
> Software Radio is an important tool for educators, tinkerers and industry to 
> implement signal processing and communication algorithms in software while 
> still allowing for easy access to real signals. This allow anyone to access 
> the EM spectrum out of curiosity, for research or for profit. At FOSDEM we 
> want to foster collaboration and exchange of ideas between different projects 
> in the field of SDR. We hope to network all these projects, and improve 
> collaboration, bring new ideas forward and get more people involved.
> 
> The track's website resides at the link below. The final schedule will be 
> available through Pentabarf and the official FOSDEM website. Notice that the 
> reference time will be Brussels local time (CET).
> 
> https://fosdem.org/2022/schedule/track/free_software_radio/
> 
> Additional Information will be also available at: 
> https://wiki.gnuradio.org/index.php/FOSDEM_2022
> 
> ** Submit your presentations
> To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM22 and 
> follow the instructions (you need an account, but can use your account from 
> last year if you have one. Please do NOT create a new account if you already 
> have one). You need to create an 'Event'; make sure it's in the Free Software 
> Radio track! Your submission should have the following information:
> 
> * Your contact Email
> * A descriptive title and subtitle of your talk
> * A short abstract
> * Links related to the project
> * [Optional] A longer description of the content of your talk. 
> 
> Lengths aren't fixed, but give a realistic estimate, and please don't exceed 
> 30 minutes unless you have something special planned (in that case, contact 
> one of us). We will typically go for 30-minute slots -- shorter talks, unless 
> they're really short, usually tend to screw up the schedule too much. Please 
> take into account some live Q at the end of your presentation, going for 25 
> minutes presentation plus 5 minutes for Q will provide a more lively 
> conference experience for everyone.
> 
> You aren't limited to slide presentations, of course. Be creative. However, 
> FOSDEM is an free software conference, therefore we ask you to stay clear of 
> marketing presentations and present something relevant to free/open software. 
> We like nitty-gritty technical stuff.
> 
> Topics discussed in this devroom include (but are not limited to):
> * SDR Frameworks + Tools
> * Cellular/telecoms software
> * Free/Open SDR hardware
> * Wireless security
> * Random fun wireless hacks
> * SDR in education
> * Satellite/spacecraft communication
> * Ham radio related topics
> 
> 
> ** Important Dates
> * Submission deadline: 26 December 2021
> * Announcement of selected talks: 31 December 2021
> * (preliminary) Pre-recorded presentation submission deadline: 23 January 2022
> * Conference dates 5 & 6 February 2022 online
> * Free software radio devroom date: Sunday 6 February 2022 online
> 
> In the last years we were always full to the brim with presentations, so if 
> you want to present, please make sure to submit your abstracts soon!
> 
> (It might be possible to get our allotted time extended to Saturday - given 
> enough volunteers and high quality presentations to 

[CFP] Free Software Radio DevRoom 2022

[Andrej Rode]

Dear friends and fans of software-defined radio and free/open-source radio 
topics in general,
 
FOSDEM 2022 (the free and open-source developer's meeting usually in Brussels, 
Europe but **repeatedly virtual**) will again feature a track on Software 
Defined Radio and any other radio-related topics in the **Free Software Radio** 
devroom. Therefore, we invite developers and users from the free software radio 
community to join us for this track and present your work, ideas and/or demos.
 
Given the current circumstances and the virtual nature of this event in 2022, 
we are asking the presenters to pre-record the talks, which will then be 
gathered by us and streamed during the event. Presenters are also asked to be 
present online during their timeslot for live Q 
 
Software Radio is an important tool for educators, tinkerers and industry to 
implement signal processing and communication algorithms in software while 
still allowing for easy access to real signals. This allow anyone to access the 
EM spectrum out of curiosity, for research or for profit. At FOSDEM we want to 
foster collaboration and exchange of ideas between different projects in the 
field of SDR. We hope to network all these projects, and improve collaboration, 
bring new ideas forward and get more people involved.
 
The track's website resides at the link below. The final schedule will be 
available through Pentabarf and the official FOSDEM website. Notice that the 
reference time will be Brussels local time (CET).
 
https://fosdem.org/2022/schedule/track/free_software_radio/
 
Additional Information will be also available at: 
https://wiki.gnuradio.org/index.php/FOSDEM_2022
 
** Submit your presentations
To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM22 and 
follow the instructions (you need an account, but can use your account from 
last year if you have one. Please do NOT create a new account if you already 
have one). You need to create an 'Event'; make sure it's in the Free Software 
Radio track! Your submission should have the following information:
 
* Your contact Email
* A descriptive title and subtitle of your talk
* A short abstract
* Links related to the project
* [Optional] A longer description of the content of your talk. 
 
Lengths aren't fixed, but give a realistic estimate, and please don't exceed 30 
minutes unless you have something special planned (in that case, contact one of 
us). We will typically go for 30-minute slots -- shorter talks, unless they're 
really short, usually tend to screw up the schedule too much. Please take into 
account some live Q at the end of your presentation, going for 25 minutes 
presentation plus 5 minutes for Q will provide a more lively conference 
experience for everyone.
 
You aren't limited to slide presentations, of course. Be creative. However, 
FOSDEM is an free software conference, therefore we ask you to stay clear of 
marketing presentations and present something relevant to free/open software. 
We like nitty-gritty technical stuff.
 
Topics discussed in this devroom include (but are not limited to):
* SDR Frameworks + Tools
* Cellular/telecoms software
* Free/Open SDR hardware
* Wireless security
* Random fun wireless hacks
* SDR in education
* Satellite/spacecraft communication
* Ham radio related topics

 
** Important Dates
* Submission deadline: 26 December 2021
* Announcement of selected talks: 31 December 2021
* (preliminary) Pre-recorded presentation submission deadline: 23 January 2022
* Conference dates 5 & 6 February 2022 online
* Free software radio devroom date: Sunday 6 February 2022 online
 
In the last years we were always full to the brim with presentations, so if you 
want to present, please make sure to submit your abstracts soon!

(It might be possible to get our allotted time extended to Saturday - given 
enough volunteers and high quality presentations to cover two days, but that's 
only an option as last resort)
 
** Following steps for accepted talks
When your talk is accepted, you will be contacted by a deputy who will help you 
with the pre-recording of your talk. Together you will make sure that the 
content has the required quality and is stream-ready. When complete, the 
recording will be located into the streaming system, and Bob's your uncle. 
 
Don't forget that you **must** be available during the allocated timeslot of 
your talk for live Q
 
** Steering Committee
The track committee consists of:
 
* Phil Balister - "Crofton"
* Derek Kozel - "dkozel"
* Andrej Rode - "noc0lour"
* Martin Braun - "mbr0wn"  
 
Hope to hear from you soon! And please forward this announcement.

Cheers
Andrej

Re: Per-revision configuration directories

[Andrej Rode]

On Wed, 20 Jan 2021 16:58:25 -0500
Jeff Long  wrote:

> Lucas: See if deleting the block cache that Christophe mentions helps
> at all. If you haven't, put in an issue on Github to capture "need
> separate configs" so it doesn't get lost.

Please do so, on a side note: Also honoring XDG_* environment variables
for cache, config and other dirs on top of versioning the configuration
directories should be implemented.

Cheers
Andrej

Re: Stop making unneeded improvements

[Andrej Rode]

Hi all, 

to jump in from a point of someone who has contributed "improvements"
over the last couple of years.

Many of your points are vaild, I understand your frustation and pain of
continuouly having to adapt to new methodologies. 
Believe me when I say we are not these changes are not implemented just
for the fun of it. All of the changes you mentioned were mostly forced
with a gun on our chest to either implement a change or to simply not
have a usable GNU Radio for new Linux Operating System Releases. 

One of the reasons is that most of the GNU Radio development is
done by volunteers in their free time. Changes to GNU Radio reflecting
changes in dependencies which would have been useful to implement long
before said dependency is obsolete have been implemented in the last
possible momont, e.g Qt4,Python3. This lead to partially
untested/unmature code being pushed into a release. For at least Debian
and Gentoo GNU Radio has been the last package either on Qt4 or on
Python2 and patches have been backported to GNU Radio 3.7 by the OS
maintainers (Thanks!) to keep it in the operating system.

It's also quite hard to demand 100% backwards compatibility for
breaking changes and tools which provide full coverage for conversion
between breaking changes. I know the Python tools and I love them. But
development of these follow the Pareto principle. 80% of the tool is
written in 20% of the time. 80% or similar is what we are able to
provide and what gr_modtool provides in terms of conversion. For simple
cases conversion just works, but for complex setups you have to add
some additional changes by hand. 

TLDR: these changes are partly forced on GNU Radio by having a list of
dependencies. Core developers are doing their best to give users the
ability to convert between versions, but it's lacking and any help is
appreciated.

Cheers
Andrej

Re: Hidden e-mail address

[Andrej Rode]

Good catch, 

seems like the address scrubbing to reduce the amount of crawlable mail
addresses works for displaying single mails but is not done for
presenting the results of the search query. 

Either a bug in mailman or in the GNU lists configuration. Worth
reporting, will you do that? (the correct mail address should be at the 
bottom of the page)'

Cheers
Andrej

On Wed, 29 Apr 2020 10:34:28 -0300
Artur Nogueira  wrote:

> The problem is: when I type my name on the search engine here:
> https://lists.gnu.org/archive/html/discuss-gnuradio/, then it is
> visible (I also typed other names and the same happens...)
> 
> Em qua., 29 de abr. de 2020 às 04:56, Marcus Müller
>  escreveu:
> 
> > Looks pretty hidden to me:
> >
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00188.html
> >
> > or am I misinterpreting this?
> >
> > On 29.04.20 04:06, Artur Nogueira wrote:  
> > > Hello all,
> > >
> > > I was recently looking for some specific topics
> > > on https://lists.gnu.org/ and I realized that many e-mail
> > > addresses appear like address@hidden 
> > > there. How do I do to get my e-mail address hidden in the same
> > > way?
> > >
> > > Best regards,
> > > Artur  
> >  

Re: GNU Radio 3.8 OOT Linking (Migration from 3.7)

[Andrej Rode]

Hi, 

as a quite big difference to GNU Radio 3.7 the CMake does not set up
your project to blindly link to all of the GNU Radio libraries but you
have to also add in  `lib/CMakelists.txt` a
`target_link_library($my_oot_library gnuradio::gnuradio-filter)` to
link to gr-filter symbols.

The inital selection of components in `find_package` just limits the
list of imported CMake targets and thus the available components you
can ultimatively link to.

Cheers
Andrej


pgpZz3qa6ILlg.pgp
Description: OpenPGP digital signature

Re: USRP LO stabilization time ?

[Andrej Rode]

Hi,

a while a ago I looked into fast-hopping using a (possibly modified) 
B210.
Basically UHD is issuing a reconfiguration of the AD9361 for each tune 
which will not only
wait for the LO to settle, but also will due DC-offset and IQ balance 
calibration in the AD9361.

For fast hopping there is a special mode in the AD9361 manual where you 
can basically save the settings after
calibration either in a special set of registers (limited space) or 
supply them on the fly so no calibration is
carried out. Using this it would be possible to possibly to sub-ms 
tuning. (I don't recall the details)
In the end I did not implement this but it would be definitely feasible 
(would require a bit of work).
Maybe someone else has some more details on this (I think there is 
something in the archives on this).

Cheers
Andrej
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Finding GNU Radio 3.8 Compatible Versions Of OOT Modules

[Andrej Rode]

Hi Sebastian, 

that's correct. We (I mean Nicholas) put this in place during the
Hackfest and unfortunately did not document this secret feature
anywhere. 

Anyhow we should consider maybe creating a GREP for how to handle
OOT metadata (and maybe don't store yaml inside of a `*.md` file). 
So we can actually have some versioning in place, 

On a parallel track I'm trying to work out how to auto-generate debian
source packages (and build them on the CI) for our zoo of OOTs which
will hopefully lead to a less source-centric user perspective for GNU
Radio.  And I will definitely need to have a good access format for OOT
metadata, be it MANIFESTs and/or PYBOMBs recipes. I haven't fully g

Cheers
Andrej

On Fri, 7 Feb 2020 08:14:50 +0100
Sebastian Müller  wrote:

> Hi,
> 
> I “reverse engineered” this this feature.
> You should place a “gr_supported_version” key in your MANIFEST. The
> value is just a string AFAIK, eg “v3.7, v3.8”.
> 
> Sebastian Müller
> 
> > On 6. Feb 2020, at 20:26, Sylvain Munaut <246...@gmail.com> wrote:
> > 
> > Hi,
> >   
> >> Regarding that column, how does it work? I've seen that only
> >> gr-fosphor and gr-iqbal have that column filled out currently, but
> >> I don't know how tnt has accomplished that. I don't see anything
> >> special in the MANIFEST.md nor in the .lwr recipe.  
> > 
> > I accomplished that by not being on github ... and so CGRAN doesn't
> > actually even look at my manifest file and the data for fosphor and
> > iqbal is literally hard-coded inside of CGRAN's codebase.
> > 
> > Cheers,
> > 
> >   Sylvain
> >   
> 



pgpnzenIz5JTP.pgp
Description: OpenPGP digital signature

Re: Finding GNU Radio 3.8 Compatible Versions Of OOT Modules

[Andrej Rode]

Hi Sebastian, 

that's correct. We (I mean Nicholas) put this in place during the
Hackfest and unfortunately did not document this secret feature
anywhere. 

Anyhow we should consider maybe creating a GREP for how to handle
OOT metadata (and maybe don't store yaml inside of a `*.md` file). 
So we can actually have some versioning in place, 

On a parallel track I'm trying to work out how to auto-generate debian
source packages (and build them on the CI) for our zoo of OOTs which
will hopefully lead to a less source-centric user perspective for GNU
Radio.  And I will definitely need to have a good access format for OOT
metadata, be it MANIFESTs and/or PYBOMBs recipes. I haven't fully
figured out yet what would be the "perfect" solution.

Cheers
Andrej

On Fri, 7 Feb 2020 08:14:50 +0100
Sebastian Müller  wrote:

> Hi,
> 
> I “reverse engineered” this this feature.
> You should place a “gr_supported_version” key in your MANIFEST. The
> value is just a string AFAIK, eg “v3.7, v3.8”.
> 
> Sebastian Müller
> 
> > On 6. Feb 2020, at 20:26, Sylvain Munaut <246...@gmail.com> wrote:
> > 
> > Hi,
> >   
> >> Regarding that column, how does it work? I've seen that only
> >> gr-fosphor and gr-iqbal have that column filled out currently, but
> >> I don't know how tnt has accomplished that. I don't see anything
> >> special in the MANIFEST.md nor in the .lwr recipe.  
> > 
> > I accomplished that by not being on github ... and so CGRAN doesn't
> > actually even look at my manifest file and the data for fosphor and
> > iqbal is literally hard-coded inside of CGRAN's codebase.
> > 
> > Cheers,
> > 
> >   Sylvain
> >   
> 



pgp37KC3XJ32N.pgp
Description: OpenPGP digital signature

Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8

[Andrej Rode]

Hi Phil, 


> > 
> > You either need to make and host your own, or download from the
> > github mirror ( https://github.com/osmocom/gr-iqbal/releases )  
> 
> Standard warning, github is known to regenerate tarballs with
> different contents that lead to sha has mismatches with time making
> it hard to validate the downloaded tarball. Don't depend on githb
> downloaded tarballs if you care about supply chain integrity.

This is a bit imprecise: The contents of the tarball are not
different, but rather are timestamps might differ for _automatic_
generated tarballs. This is due to GitHub sometimes regenerating 
tarballs on the fly.

If a release tarball is created manually and
uploaded as asset for a release tag there is no problem. 

Cheers
A



pgpSnPIESw7zZ.pgp
Description: OpenPGP digital signature

Re: Coexistence of Gnuradio 3.7 and 3.8 on one PC

[Andrej Rode]

Hi Harald, 

if you want to have GNU Radio 3.7 & 3.8 on the same machine I recommend
to have both installed in a non-default search path for libraries.
Applications linking to GNU Radio then have to set LD_LIBRARY_PATH,
PYTHONPATH, GR_BLOCKS_PATH accordingly to point to the non-default
search path. 

Otherwise you will end up with applications using the wrong version or
even mixing both versions. 
Unfortunately this wouldn't be compatible with a precompiled SDRPlay
image (I assume GNU Radio is installed in the default search path
there).

Maybe someone else has a better suggestion.

Cheers
Andrej

On Mon, 23 Dec 2019 18:50:31 +0100
dd...@dd0vs.de wrote:

> Dear Readers,
> 
> i am using Gnuradio 3.7 on a Raspberry Pi 4 (SDRPlay image v0.6). This
> reduces compilation effort for RSP1 and B205 usage drastically.
> 
> Is there a way to compile and install GR3.8 in parallel to GR3.7?
> Do i need to build uhd-module new?
> 
> Regards, Merry X-Mas and vy 73
> Harald
> DD0VS
> 
> 



pgpcm7frRLSbX.pgp
Description: OpenPGP digital signature

Re: More on C++11 requirements

[Andrej Rode]

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

Re: GNU Radio Pre-FOSDEM Hackfest 2020

[Andrej Rode]

Hi all, 

short addendum: Participation is also possible for a subset of the
days (we have enough bugs to fix & ideas to develop). At the
registration is a questionaire where you can indicate the dates you
currently plan to attend. 

Cheers
Andrej

On Wed, 13 Nov 2019 23:35:36 +0100
Andrej Rode  wrote:

> Hi all, 
> 
> as announced on October 16th there will be another edition of the Free
> Software Radio Devroom at FOSDEM 2020.
> 
> In recent years we managed to assemble a GNU Radio Hackfest in
> relative proximity to come together and hack and spin new ideas on
> the GNU Radio core. This edition of the GNU Radio Pre-FOSDEM Hackfest
> will be hosted starting January 28th until January 30th about 2 hours
> of train ride away at ESA ESTEC in Noordwijk (Netherlands).
> 
> We started collecting topics for the working groups during the
> hackfest at: https://wiki.gnuradio.org/index.php/Hackfest2001
> Feel free to add another entry if you can think of something we should
> spend some time working on (and you spot someone on the list who might
> be the right fit for this).
> 
> Current list of topics:
>   * FPGA Accelerators (FPGA people would be useful)
>   * VRT & SigMF tools
>   * OOT 3.8 porting support and adding to GNU Radio package feed
>   * Add ptest support to volk and gnuradio recipes
> (https://wiki.yoctoproject.org/wiki/Ptest)
>   * GPU Accelerators
> 
> Due to room size limitation we created a registration page which will
> provide me your name, email adresses and additional information to
> help organization and entry on premise. Attendance is free of charge
> and the registration page can be found at: 
> https://tickets.gnuradio.org/hackfest2001/
> 
> Travel information and non-technical info will be also collected on
> the wiki page. 
> 
> If you have questions feel free to contact me. 
> 
> Cheers
> Andrej
> 



pgpsa4mDN4nby.pgp
Description: OpenPGP digital signature

GNU Radio Pre-FOSDEM Hackfest 2020

[Andrej Rode]

Hi all, 

as announced on October 16th there will be another edition of the Free
Software Radio Devroom at FOSDEM 2020.

In recent years we managed to assemble a GNU Radio Hackfest in relative
proximity to come together and hack and spin new ideas on the GNU Radio
core. This edition of the GNU Radio Pre-FOSDEM Hackfest will be hosted
starting January 28th until January 30th about 2 hours of train ride
away at ESA ESTEC in Noordwijk (Netherlands).

We started collecting topics for the working groups during the hackfest
at: https://wiki.gnuradio.org/index.php/Hackfest2001
Feel free to add another entry if you can think of something we should
spend some time working on (and you spot someone on the list who might
be the right fit for this).

Current list of topics:
  * FPGA Accelerators (FPGA people would be useful)
  * VRT & SigMF tools
  * OOT 3.8 porting support and adding to GNU Radio package feed
  * Add ptest support to volk and gnuradio recipes
(https://wiki.yoctoproject.org/wiki/Ptest)
  * GPU Accelerators

Due to room size limitation we created a registration page which will
provide me your name, email adresses and additional information to help
organization and entry on premise. Attendance is free of charge and
the registration page can be found at: 
https://tickets.gnuradio.org/hackfest2001/

Travel information and non-technical info will be also collected on the
wiki page. 

If you have questions feel free to contact me. 

Cheers
Andrej



pgp7SVG9X2hak.pgp
Description: OpenPGP digital signature

Re: Live Pull Request Review on Twitch 5 PM Pacific Time

[Andrej Rode]

Hi Adrian,

Pacific Time is actually a timezone. 

Cheers
Andrej


On Thu, 07 Nov 2019 14:22:57 +
Adrian Musceac  wrote:

> Hi Martin,
> This event might already be over by now, but can you please specify
> the time relative to UTC (or a timezone, alternatively) for the next
> event? I believe this community is spread over a large number of
> timezones.
> 
> Thanks,
> Adrian
> 
> On November 6, 2019 10:41:25 PM UTC, Martin Braun
>  wrote:
> >Hi all,
> >
> >sorry for the late announcement, but we'll do a first today: I'll be
> >spending some time looking at the pull requests queue, doing code
> >reviews, etc. Why should you care? Well, I'm not sure about that --
> >but I will be streaming the whole thing on Twitch. You can follow the
> >GNU Radio Twitch at twitch.tv/gnuradio.
> >
> >I'll start at 5 PM (-ish, as soon as I finish my regular day job
> >stuff, so bear with me if I'm a few minutes late). I will explain why
> >PRs are stuck, and hopefully merge some. To be honest, I haven't been
> >as active as my GNU Radio merge colleagues recently, so I will need a
> >few minutes to find my bearings -- however, that's exactly the thing
> >that might be worth talking about.
> >
> >Most people will probably be familiar with Twitch, but in case you're
> >not: It's that place where all the video games get streamed, and it's
> >supposed to be interactive. There is Twitch chat, which I will try to
> >follow. I'll also try and follow IRC/Slack, but I'm not good at
> >multitasking (or I would be streaming Starcraft instead). In fact,
> >let me say straight out that this is the first time that I'm
> >live-streaming anything related to coding, and who knows how this'll
> >end up working.
> >
> >Why are we doing this? At GRCon, we had a workshop on, among other
> >things, participation and transparency within the project, and this
> >was a suggestion from a GRCon participant. If this turns out to be of
> >interest, I can see us doing this more often. In any case, I'd be
> >curious to hear about any kind of feedback or suggestions you may
> >have.
> >
> >I believe there's a way to put the recording on YT afterwards, which
> >I intend to do.
> >
> >See you later (maybe?)
> >
> >-- Martin  

Re: Subject Line Prefix Missing

[Andrej Rode]

To drive this more Off-Topic than it already is...

> Mailing list software for decades inserts unique headers for filtering
> purpose.  "List-Id" is AFAICT the most common one, which is also used
> by GNU mailman.  It has been specified in 2001 in RFC2919

Even non-Mailinglist software, e.g. GitHub, EBay, Deutsche Bahn, are
supplying custom List-Id headers for separate topics. In case of GitHub
one can use List-Id headers to automatically separate mails for
different repositories without looking at the content or Subject.

Cheers
Andrej

Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?

[Andrej Rode]

Hi,

> > during the last congress (35c3) we have been talking about
> > the logging in GNU Radio. I was not thinking about this much,
> > until the recent discussion with another GNU Radio developer
> > at the CCCamp 2019 (unfortunately, I forgot his name, sorry).

I plead guilty. It was me. 

> > Instead of printing directly to stderr (or anywhere else),
> > we can define a value-string array of possible events:
> > 
> >   enum gr_audio_event_t {
> > GR_AUDIO_EV_OVERRUN,
> > GR_AUDIO_EV_UNDERRUN,
> > GR_AUDIO_EV_FOO_BAR,
> > /* other events... */
> >   };
> > 
> >   struct value_string {
> > unsigned int value;
> > const char *string;
> >   } gr_audio_events[] = {
> > { GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
> > { GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
> > { GR_AUDIO_EV_FOO_BAR, "Pretty description" },
> > /* other events... */
> > { 0, NULL }
> >   };
> > 
> > and give a possibility to the API user to subscribe either to
> > some of the events, or to all of them, so logging can be done
> > by the user itself, if needed. For GUI applications, the
> > corresponding part of UI can be updated instead.

This idea was especially valuable as blocks/objects/modules could keep
the logging messages in a binary format. Meaning that for each
event/block there could be a struct which contains information and
instead of serializing/stringifying every event logged the information
could stay in a binary/original format until it really needs to be
converted to a string. (Which is actually how the python logging
library handles string formating as well).

I thought about something like passing a
"event_severity, event_component, event_data_t, event_data_fmt" with
the last argument being a function pointer which can convert
event_data_t to string. For simple logging messages with static content
this could just be a static string, but for dynamic content this could
convert all sorts of information to a printable string (if needed).

Obviously I'm not going to implement this, just my 2 cents where this
idea originated. 

Cheers
Andrej


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

Re: [Discuss-gnuradio] ARM optimizations update

[Andrej Rode]

Hi Albin, 

just to throw in some snarky comments.

On Thu, 30 May 2019 16:20:44 +0200
Albin Stigö  wrote:

> I've finished ARM NEON SIMD optimization for 44 kernels which means
> only 23 kernels (not often used) are now missing a NEON
> implementation.

I've checked on your progress a couple of weeks ago and just to have
that info beforehand: It is really beneficial to have a good
reviewability with meaningful commits that can be merged seperately.
Since your changeset will be quite big I think going for a commit per
kernel might be a way to go. That will help getting reviews from other
experts on NEON (Me not being an expert in that field). 

Otherwise keep up the good work!

Cheers,
Andrej



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

Re: [Discuss-gnuradio] VOLK pre-built option

[Andrej Rode]

On Tue, 21 May 2019 20:39:11 +
"Müller, Marcus (CEL)"  wrote:
> Furthermore, VOLK is dependency-wise like GNU Radio light:
> if you can't build VOLK, chances are slim GNU Radio will work out.

Huh?

VOLK depends on almost nothing.   

Cheers
Andrej


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

Re: [Discuss-gnuradio] Website Not Down Anymore

[Andrej Rode]

Up again.

On Mon, 20 May 2019 16:26:32 -0400
Ben Hilburn  wrote:

> Hi all -
> 
> The website is down temporarily, affecting the Wiki and landing page,
> but not GRCon ticket registration (or Github, obviously). We're
> working on it and will have it back up as soon as we can.
> 
> Cheers,
> Ben


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

Re: [Discuss-gnuradio] gr_zeromq on MS-Windows ?

[Andrej Rode]

Hi Jean-Michael,

On Wed, 17 Apr 2019 15:34:21 +
"jean-michel.fri...@femto-st.fr"  wrote:

> Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py",
> line 18, in swig_import_helper return
> importlib.import_module('_zeromq_swig') File "C:\Program
> Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line 41,
> in import_module __import__(name)
> ImportError: DLL load failed: Le module spÚcifiÚ est introuvable.
> ^^^ French for "The specified module cannot be found"

This usually indicates that `_zeromq_swig.(so|dll)` was found, but
contains unresolvable dynamic linking. Maybe libzmq is missing in the
library_path/dll_path.

On a Linux host I'd go here: "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\" and look at the
`_zeromq_swig.so` with `ldd`. I don't know what the tool of choice on a
Windows platform is for looking up the dynamic linking of a library,
but certainly that information will help you locate the missing pieces.

Cheers
Andrej




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

Re: [Discuss-gnuradio] Tag propagation policy for tagged stream blocks

[Andrej Rode]

Hi Johannes, 

thanks for bringin this issue up.

On Wed, 17 Apr 2019 08:08:37 +
Johannes Demel  wrote:

> but what happens to other tags? They are left untouched. This results
> in a situation where a rate change basically makes all other tags
> disappear because these tags will be out of range for all other
> blocks down the line. Right now, the options are to not use tags,

This sounds like it is a bug and a solution should be implemented for
tagged stream blocks in the GR source. Recently changes were introduced
for tag propagation to use rational numbers to survive multiple down-
and upsampling steps. Plugging that calculation for tagged stream
blocks should be somehow possible, e.g. using instantaneous
decimation/interpolation rates.

Cheers
Andrej


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

Re: [Discuss-gnuradio] Question: is there code for hotel special rated re Sep conference

[Andrej Rode]

Hi Jerry, 

On Wed, 10 Apr 2019 11:17:59 -0700
"geraldfenkell"  wrote:

>  I am hoping to attend the upcoming (September 2019) conference.
>   
>  Is there any special discount code to use when booking hotel

Yes, the link to the discounted rate at the hotel is currently sent out
with the confirmation mail after you booked your registration to GRCon
'19.

Cheers
Andrej





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

Re: [Discuss-gnuradio] gr-vocoder: update codec2 and freedv blocks

[Andrej Rode]

Hi, 

I've submitted a pull request with your patch. [0]

Cheers
Andrej

[0] https://github.com/gnuradio/gnuradio/pull/2413


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

Re: [Discuss-gnuradio] GSoC: Introduction and GNU Radio Project discussion

[Andrej Rode]

Hi all, 

I have some remarks regarding the current state of the filter design
tool.

> First step would thus be to polish the tool and clean it up, modernize
> it. I'm not sure about its state w.r.t. no longer using pyqwt. Maybe
> that's a place to start.

Recently Edward Kigwana worked on porting the filter design tool from
PyQwt to PyQtGraph. Unfortunately he wasn't able to finish up porting
everything over, so now the filter design tool is half done.

The results (in one squashed commit, rebased on GNU Radio master) can
be found here [0]. 
Despite the lacking features the plotting and filter tap generation are
still working. I will submit the current progress as pull request and
maybe we can even merge it so you have a good starting point.

I have no objections if you want to redo the PyQwt to PyQtGraph porting
yourself. But since there has been some work in progress I want to make
sure y'all to know about it.

Cheers
Andrej

[0] https://github.com/noc0lour/gnuradio/tree/pyqtgraph_squash


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

Re: [Discuss-gnuradio] compressing I/Q files

[Andrej Rode]

This can partly be explained by complex IQ captured in 2x 32bit floats
only uses [-1,1] range of float. So instead of using 32 bits the data
already is only using 32 - 8 bit (since you literally do not use the
exponent to carry information).

If you then captured "real" data
instead of noise you don't have white info which can be compressed.

Thanks for posting your findings!

Cheers
Andrej


On Thu, 14 Mar 2019 10:49:45 +0100
Kristoff  wrote:

> Marcus, all,
> 
> 
> Thx.
> 
> In the mean time, I did a little bit of testing.
> 
> A 256 MB piece of a I/Q file (a pass of NOAA-19), sampled at 240 Ksps.
> Gzip compressed this down to 40 MB. 7Zip managed to get this down to
> 29 MB (but compressing took 10 to 20 times longer).
> 
> Now, after converting this file from float to short, you get a 128 MB
> file. However, if you then compress that, the gain isn't that big
> anymore: gzip 33 MB, 7zip 25 MB.
> 
> 
> My guess is that gzip and 7zip do compression based on looking for 
> repetitive patterns. This means that converting 32bit floats to 16bit 
> shorts does not really help if you plan to compress the files
> afterwards anyway.
> 
> 
> 
> Kristoff
> 
> 
> On 10/03/19 18:33, Marcus Müller wrote:
> > Hi Kristoff, Benny and Alban,
> >
> > TL;DR:
> > Benny is exactly on spot. Other than that, decimate your signal if
> > you know the bandwidth is less than your sampling rate, and don't
> > put too much hope on audio encoders.
> >
> > Long Version:
> >
> > Point is: the signal coming from your SDR device, whatever that
> > might be, has finite resolution – typically, no more than 16 bits
> > per channel. Hence, the conversion from float to short (or directly
> > getting short, if your device driver allows that) is lossless. For
> > example, USRPs' driver (UHD), and the GNU Radio USRP source, can be
> > configured to hand out the signed complex 16 bit conversion of the
> > data from the network or USB interface instead of the float32
> > conversion.
> >
> > Any other compression method can only do so much:
> > Your signal recording is essentially random – meaning that all
> > values should be roughly equally likely. Maybe extreme high
> > amplitudes are a little rarer, since you'd typically avoid those to
> > stay clear of clipping.
> > That means that the average info per sample is relatively high: From
> > seeing other samples, we know very little about it, so the surprise
> > we get from its actual value is pretty high.
> > Information-theoretically, the expected information content per
> > sample is the entropy of a source. Information and entropy are both
> > measured in bit – the completely fair random decision between 0 and
> > 1 ("flipping a coin") is worth 1 bit, and picking one out of 2¹⁶
> > values perfectly randomly is worth 16 bit.
> >
> > (Lossless) compression can, best case, achieve a compression where
> > the amount of bits used per sample is equal to the entropy of the
> > source. Now, if your signal is somewhat noisy, and other than that
> > relatively interesting (i.e. you're not observing a constant
> > value), your source entropy often approaches the limit given by the
> > ADC – in my tests, even on severly backed-off signals, standard
> > Huffmann and Lempel-Ziv-Welch compressors (zip, gzip, 7z, zstd,
> > bz2, xz) achieved negligible compression ratios on radio recordings.
> >
> > I've tried FLAC, too – FLAC doesn't allow to set the actual sampling
> > rate as high as was truly used by typical SDR hardware (i.e. the
> > header field for the sampling rate simply doesn't have enough size
> > to allow for 10⁷, for example). But that's mainly a metadata
> > problem that can be solved by ignorance.
> > However, FLAC's linear prediction coding relies on signals having
> > a) "small" deviation from a linear function for short time periods,
> > and b) the following residual coding relies on geometric
> > distribution –
> >
> > and that's usually not given, because
> > a) if you already know you will be in need of compression, you're
> > probably not significantly oversampling your signal, but are already
> > decimating it to a rate barely more than sufficient. Everything else
> > would be a larger waste of space – and has no benefits for signal
> > analysis later, and
> > b) with the prior assumption broken, only a zero-order linear
> > precoder doesn't make things worse – i.e., simply handing through
> > the input samples to the residual coder. That residual coder, as
> > said, depends on the distribution of amplitudes to follow a
> > specific statistic to work well.  Sadly, that statistic doesn't
> > apply to I signals, typically.
> >
> > My experience is that FLAC doesn't work well for anything that's not
> > massively oversampled AM audio – which is no surprise, because that
> > literally isn't very different from audio, which is what FLAC was
> > designed for.
> >
> > However, my FLAC experiments lie years in the past – maybe the
> > encoder got more versatile; Alban, do you have deviating 

Re: [Discuss-gnuradio] GSoC project idea discussion

[Andrej Rode]

Hi Arpit, 

> Also, pygccxml parser code
> itself is easy to visualize. libclang in python does a pretty good
> job in parsing all the header files, but it parses all the include
> files, and also the standard C++ ones because of it's compiler level
> parsing, which is not required, at least in our particular case.

Looking at both pygccxml and the python bindings for clang is
definitely a good thing and will give you an idea about which is the
better tool for the job. Looking at the pygccxml project it seems it's
active & mature enough to be used in GNU Radio from a technical
perspective.

Cheers
Andrej


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

Re: [Discuss-gnuradio] Getting Background on GNU Radio on Android (was: GSOC : GNU Radio Projects)

[Andrej Rode]

Hi, 


On Thu, 7 Mar 2019 09:27:50 +
"Müller, Marcus (CEL)"  wrote:

> Very little… https://wiki.gnuradio.org/index.php/Android 
> of which https://wiki.gnuradio.org/index.php/GRAndDeps is probably the
> most important, but it's pretty dated. I don't think modern GNU Radio
> has problems with GCC 4.9 anymore, but it does not work with GCC
> before 4.8.4.
> 
> You'll notice the dependency tarball from the first link URL is dead.
> Andrej, you don't happen to know where that went?


You can rebuild the tarball using the script from the third link since
the old dependencies tarball would be pretty useless by now anyway.
(Or fix the script to the point it builds again).

Since there wasn't a big push for changing dependencies the linked deps
should still work (minus updated versions).

Cheers
Andrej


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

Re: [Discuss-gnuradio] Testers needed: Updated CMake syntax

[Andrej Rode]

Hi, 

On Thu, 14 Feb 2019 17:44:26 +0100
Volker Schroer  wrote:

> Hi,
> I tried [1] on Ubuntu 18.10 and it build without problems.
> Starting to build some of mine OOT's I found, that FindUSB.cmake is 
> missing. I think this was used to build gr-fcd which is not part of 
> gnuradio 3.8.

Thanks a lot for trying out! Indeed FindUSB has went away together with
the fcd component. I time allows it someone (maybe be) has time to pull
it into it's own module so at leaste the fcd support won't be lost.

> But that's no problem.
> Will the new cmake be part of gnuradio-3.8 ?

If all goes well I think so, it's not really on the features list of
the feature freeze, but still.
> 
> I'll keep on testing some more OOT's

Great, keep me/the list in the loop on any success or issues you
encounter.

Cheers
Andrej



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

[Discuss-gnuradio] Testers needed: Updated CMake syntax

[Andrej Rode]

Hi all, 

in the last weeks I have been pursuing the quest of reworking the
current CMake build tooling in GNU Radio to use "modern CMake" syntax.
This work has mainly completed and now is the time to fix bugs you
encounter. 

The work on the updated CMake can be found here
[0]/[1] and should compile just fine using the cmake & make/ninja
commands you are used to. 
Support for static libraries might be still broken, but static linking
can be enabled using `-DBUILD_SHARED_LIBS=OFF` on the command line. No
shared library will be built using that flag.

Linking Out-of-Tree modules should be way easier using the new syntax
(but still old modules have to be updated). Mainly the `find_package`
call now follows the convention of specifying components in the
function call e.g. `find_package(Gnuradio COMPONENTS fft audio)`. After
the correct components are specified on in the `find_package` call the
corresponding build targets are available in your CMake project.  e.g.
you can `target_link_libraries(foo gnuradio::gnuradio-fft)`. Several
core build targets are always available (gnuradio::gnuradio-runtime,
gnuradio::gnuradio-pmt). 

Instead of linking to all GNU Radio libraries in the
`target_link_libraries` call in `lib/CMakeLists.txt` now only the
targets needed should be linked with. An example for changes needed in
a OOT can be found at [2].
Mostly removing almost everything from `cmake/Modules` and removing a
lot of manual dependency finding from your own `CMakeLists.txt` is a
good step forward.
Necessary changes to `gr_modtool` have been incorporated to work with
the new CMake syntax.

If you encounter bugs or have suggestions for further improvements do
not hesitate to contact me through the pull request [0] or email. I'll
help with build problems updating your OOT as well.

Cheers
Andrej 

[0] https://github.com/gnuradio/gnuradio/pull/2230
[1] https://github.com/noc0lour/gnuradio/tree/update_cmake
[2] https://github.com/noc0lour/gr-grnet/tree/3.8


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

Re: [Discuss-gnuradio] gr-logo use compliance

[Andrej Rode]

Hi, 

On Wed, 06 Feb 2019 22:21:35 -0500
"Marcus D. Leech"  wrote:

> I'm going to go have some front-panels made for a science 
> instrumentation project, with the front-panel layout:
> 
> http://www.ccera.ca/files/riometer_front_panel.pdf
> 

side note: it's spelled „GNU Radio“. I think I already saw
a „powered by GNU Radio“ design somewhere, maybe it was a sticker.

Cheers
Andrej

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

[Discuss-gnuradio] Survey: Additional static target & libtool support in build system

[Andrej Rode]

Hi all, 

During my recent work on getting the GNU Radio build system on a more
modern CMake foundation I stumbled upon some things I'd like to know
if someone is using them. [0]

1. Currently each component in GNU Radio is compiled as shared library
_and_ optionally a static build can be done. Because of the way it's
currently setup every source file is compiled twice anyway and a
shared library is always compiled as well.
In my quest to improve the build system I'd like to remove the second
"optional" build target for static libraries and use the  advised
`BUILD_SHARED_LIBS` switch in CMake to _either_ build shared libraries
_or_ static libraries. This will require having a separate build
directory for building shared & static libraries, but will simplify
the syntax in our build system immensly.
Building static-only libraries will be possible by specfiying
`-DBUILD_SHARED_LIBS=OFF`.

2. Optionally when specifiying `GENERATE_LIBTOOL` .la files are
generated by the build system. According to a comment in the
`GR_LIBTOOL` function those files are not compatible with auto-* tools
anyway and our build system is already providing package config and
CMake package configuration files. Is there still a user out there? 

Cheers
Andrej 

[0] https://github.com/gnuradio/gnuradio/pull/2230


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

[Discuss-gnuradio] web infrastructure maintenance

[Andrej Rode]

Hey all,

the website, wiki & other web services will be down for a couple of
hours due to some necessary maintenance.

Cheers
Andrej


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

Re: [Discuss-gnuradio] Gnuradio ring buffer code

[Andrej Rode]

Hi Ben, 

> 
> Could anyone help point me to the right part of the src, I've had an
> initial go but have been unable to find the specific parts of the
> code that handle the adding/taking of samples into the gnuradio ring
> buffer. I'm particularly interested to know what phtread scheduling
> is used if its different from the defaults and how mutexes are handled

Everything as fundamental as buffer setup can be found in
gnuradio-runtime/lib.
Specifically `buffer.cc` and `vmcircbuf.cc` contain code for setting ub
the circular buffer structure by mapping adjacent virtual memory to the
same physical memory. 

Every block output port holds one of these buffers with read/write
pointers indicating the position of producers & consumers. Essentially
the access to these buffers is "lockfree" in the sense that the
producer is only allowed to write items up to the curent position of the
next read pointer and the consumers are only allowed to read up to
the current position of the write pointer.


Cheers
Andrej




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

Re: [Discuss-gnuradio] [GREP] GNU Radio Coding Guidelines

[Andrej Rode]

Hi, 

On Mon, 14 Jan 2019 23:03:40 -0800
Ron Economos  wrote:

> I realize that I'm late to the game, but I was recently reminded of
> this GREP (and it's associated GREP 0011). I'm all for cleaning the
> code, but the current .clang-format rules create a problem (that's
> addressed in GREP 0011).

Yeah, a bit late, but with valid arguments nonetheless. 
> 
> Specifically, the current .clang-format would change the files so
> much, that the repository history would become useless. In GREP 0011,
> this is referred to as a "history reset".

Reformatting everything in one commit will make it easy to jump this
single commit if going back in git blame or in git log. Still all
functional (relevant) changes are visible to the observer. 
Mitigating "large" code changes by crafting a .clang-format comapatible
to the old, non-enforced, coding guideline will result in "medium" code
changes.

At that point it's not really clear if one would have a benefit of
changing only half of the code (since it's very likely to be the
"important" half). And thus the .clang-format was crafted to have the
most pleasant coding experience. 

Also while editing old files the formatting was all over the place in
relevant places (where the functional code lives). Usually header &
footer is formatted uniformly.
> 
> I'd like to suggest a middle ground. A .clang-format can easily be 
> crafted that uses the old GNU Radio guidelines. This would provide 
> minimal changes to the files, and a "history reset" would be avoided
> (or at least mitigated).

Personally I'm not really keen to touch the formatting again, but I'd
like to hear other opinions. But to be honest, I don't really care, as
long as the formatting is enforced automatically. Otherwise formatting
is futile.

Thanks for chiming in!

Cheers
Andrej


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

Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base files

[Andrej Rode]

Hi Martin, 

On Thu, 27 Dec 2018 13:54:54 -0800
Martin Braun  wrote:

> Hi all,
> 
> final GREP of the day:
> https://github.com/gnuradio/greps/blob/master/grep-0016-separate-scheduler.md
> 
> This is possible the most fundamental and influential GREPs that were
> added so far. I would find it hard to find any reasons not to do this
> -- of course, the question remains, who will do it. Any takers? I'm
> hoping that by separating scheduler from base, we can open up the
> avenue for more and better research into scheduling, as well as
> custom scheduler development.

So current situation is: we basically have a architecture where one
could write another scheduler and plug it into the current system. The
major problem with that: the current architecture has gone through a
lot of patching and growing and thus a lot of boundaries between blocks
and the scheduler have become unclear. 

Aside from uncluttering the runtime and cleaning up, a new architecture
design should be discussed without mental barriers looking at the
current design. Important points: how to we want to run the flowgraphs,
what owns the buffers, how are buffers handled, what schedules
execution of blocks, how is control communication done, how will
heterogeneous processing be handled (locally & distributed). 

This will change almost all interfaces of the current architecture and
thus I think the current scope of the GREP is still too narrow. 
I don't have a perfect solution for this. But fundamentally there is
need for more change than outlined. E.g. the word top_block & PMT
shouldn't be in there. Though I agree on the most basic point outlined:
the current UX must be preserved (or even improved).

I have some ideas on architecture and buffer handling in a new design,
but they need more thoughts & proof-of-concepts until they're ripe for
discussing.

Thanks for starting the discussion!

Cheers
Andrej


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

Re: [Discuss-gnuradio] [GREP] Replace SWIG

[Andrej Rode]

Hi, 

On Fri, 28 Dec 2018 17:30:05 -0800
Martin Braun  wrote:

> Here's a summary of of comments that have come up in chat:
> 
> - Andrej recommended using PyBind11, a close cousin to boost.python.
> it comes recommended by Sebastian Koslowski also. It's only a few
> headers and we could ship it as part of the source tree.
> - The question arose if we even need the python bindings as part of
> the standard install. Personally I think we do, installing GNU Radio
> from source should simply give you all the features. But it's a good
> thing to discuss.

Development of Python bindings with PyBind11 could even happen in a
separate CMake project since the only thing required for Python
bindings are available headers and shared libraries. Since that could
be easier on new developers.

I agree that currently most users are using Python as development
environment and we should ship the bindings with GNU Radio itself.

Also we had a discussion on generation of bindings and I don't see a
need of automatically generated bindings during each build. Maybe a
first generation can be done using binder[0]. But since that is a
separate tool I wouldn't want to depend on that to generate the sources.

Rather add the bindings during code review (or have a checkbox to check
for that during code review).

Cheers
Andrej

[0] https://github.com/RosettaCommons/binder



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

Re: [Discuss-gnuradio] 'module' object has no attribute

[Andrej Rode]

Hi Guy, 
> ---
> AttributeError: 'module' object has no attribute 'mac'
> ---

That usually happens if python can't import the created module. 
It can have several reasons why it can't:
 1. the installed module is not in your (custom) PYTHONPATH
 2. The python module tries to import the C++ code wrapped with SWIG and
 errors out (Usually because some linking problems)

That's the two usual suspects if working with GNU Radio. You should
check the directory you installed the python module in. E.g.
`/usr/local/lib64/python2.7/site-packages` if there is a `mac` folder. 
If there is you should check if it is in your pythonpath (e.g. python -c
'import sys;print(sys.path);'). If it is you can go into the `mac`
folder and check with `ldd _mac_swig.so` (or similar) if the dynamic
linker can locate all libraries required to run the code.

Cheers
Andrej

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


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

[Discuss-gnuradio] Call for Participation FOSDEM & pre-FOSDEM Hackfest

[Andrej Rode]

Hi all,

merely two months are left until we gather SDR hackers and friends in the Free
Software Radio Devroom in Brussels at FOSDEM. Please submit more
talks/events for the Devroom until December 7th here [0].

For everyone who is able to attend and is arriving early (or has the
possibility to do so): We want to invite you to the GNU Radio Hackfest
taking place at the Hackerspace Brussels (HSBXL) on *Jan 31st & Feb 1st '19*.
The hackfest will be part of a series called "Byteweek" which
is a yearly event organized by HSBXL in a byte-long week before
FOSDEM. The events' page can be found here [1].

Please feel free to add more ideas to the Hackfests' wiki page and if
you are able to attend you can add yourself to the list of participants
so we have rough idea who will be there. [2]

Cheers
Andrej (noc0lour)

[0] https://penta.fosdem.org/submission/FOSDEM19
[1] https://hsbxl.be/events/byteweek/2019/
[2] https://wiki.gnuradio.org/index.php/Hackfest1902
-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Andrej Rode]

On Tue, Oct 09, 2018 at 01:25:01PM +0200, Sylvain Munaut wrote:
> I'm starting to wonder if having different precision version of the
> kernels wouldn't make sense ...
> 

Totally makes sense. 
For the case of approximation it might be sufficient to document the
worst case error and measure the absolute error during tests/profile
instead of a normalized error.

Why do we have a normalized error instead of a absolute error threshold
at all?

Cheers
Andrej

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

Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Andrej Rode]

Another kernel with a lot of variying precision is the log2
implementation since it's currently a polynomial approximation with a
6-th degree polynomial.

The glibc implementation uses a 14-th degree polynomial to approximate
log2 which turns out to have a maximum error of 2**-58.45.

Probably the log2 approx. should be improved to a point where the
maximum normalized error is always less than 0.15.
The current implementation produces large normalized errors for input
values close to 1.

```
offset 98458 in1: -1.70264e-05 in2: -2.47955e-05 measured error was: 0.456301
 tolerance was: 0.15
```

Cheers
Andrej

On Mon, Oct 08, 2018 at 06:37:50PM +0200, Andrej Rode wrote:
> Hi all, 
> 
> I just created an issue for that in the volk GitHub repository: 
> https://github.com/gnuradio/volk/issues/202
> 
> The normalized error seemed to be in the ~1e-8 range (errors in volk are
> normalized to the amplitude of the result in question)
> Thus it passes the default error threshold of 1e-6. 
> 
> Marcus pointed out offline that some of the intrinsics might even have a
> better precision compared to the generic implementation.
> 
> Cheers
> Andrej
> 
> On Wed, Oct 03, 2018 at 04:57:32PM -0700, Ron Economos wrote:
> > It depends on which box I look at.
> > 
> > 1) volk_32fc_x2_divide_32fc a_avx u_sse3
> > 
> > 2) volk_32fc_x2_divide_32fc a_avx u_avx
> > 
> > Ron
> > 
> > On 10/03/2018 08:05 AM, Müller, Marcus (CEL) wrote:
> > > Well, I'd be willing to call that a bug, all in all:
> > >
> > > Though I totally get the "machine accuracy" argument, I'd at least
> > > expect the same results when running the same program twice, on the
> > > same machine.
> > >
> > > Now, I'm an author of one of the 32fc_x2_divide_32fc implementations;
> > > I'd like to know what I can do to fix this. Ron, what was the machine
> > > that volk_profile picked for you?
> > >
> > > By the way, just as for the float/char (and other ints) conversion
> > > kernels, it's not inherently obvious who's right or wrong, the
> > > optimized or the generic impl. So, we should be analyzing which values
> > > led to the differing result.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Wed, 2018-10-03 at 06:52 -0700, Ron Economos wrote:
> > >> That's the problem. If a set_output_multiple(4) in added to the
> > >> constructor in divide_cc_impl.cc, it solves the issue.
> > >>
> > >> Ron
> > >>
> > >> On 10/03/2018 06:42 AM, Ron Economos wrote:
> > >>> Well, I guess it's not really a bug. Most likely it has to do with the
> > >>> accuracy difference between the x86 intrinsics and the C library. If
> > >>> you look at the code in volk_32fc_x2_divide_32fc.h, the remaining
> > >>> points that are not a multiple of four are calculated with the C
> > >>> library. If the points from one run that are calculated with the C
> > >>> library line up with points calculated with intrinsics in the next
> > >>> run, there can be a mismatch.
> > >>>
> > >>> Ron
> > >>>
> > >>> On 10/03/2018 06:27 AM, Ron Economos wrote:
> > >>>> It's a VOLK bug. Go into ~/.volk/volk_profile and change the
> > >>>> volk_32fc_x2_divide_32fc line to generic. That fixes the issue here.
> > >>>>
> > >>>> Ron
> > >>>>
> > >>>>
> > >>>> On 10/03/2018 05:46 AM, Piotr Krysik wrote:
> > >>>>> Hi all,
> > >>>>>
> > >>>>> I simplified the flowgraph a bit and prepared a script that runs it
> > >>>>> twice and compares the results.
> > >>>>>
> > >>>>> https://imgur.com/a/CSjOeLc
> > >>>>>
> > >>>>> In short something is wrong indeed.
> > >>>>> Almost after every run of the script I get results with differences.
> > >>>>>
> > >>>>> I tested it on GNU Radio  3.7.12.0, I'm compiling the most fresh
> > >>>>> version
> > >>>>> now.
> > >>>>>
> > >>>>> Best Regards,
> > >>>>> Piotr Krysik
> > >>>>>
> > >>>>> W dniu 03.10.2018 o 06:55, Reiichiro Nakano pisze:
> > >>>>>> Here's an updated flowgraph where you don't need a separate file
> > >>>>>> source. Just run the flowgraph twice for a few seconds each. You'll
> > >>>>>> likely get different file sizes but `cmp` doesn't care, it'll still
> > >>>>>> show the first differing byte which should still prove the bug 
> > >>>>>> exists.
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> -- 
> Andrej Rode
> GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA



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


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


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

Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Andrej Rode]

Hi all, 

I just created an issue for that in the volk GitHub repository: 
https://github.com/gnuradio/volk/issues/202

The normalized error seemed to be in the ~1e-8 range (errors in volk are
normalized to the amplitude of the result in question)
Thus it passes the default error threshold of 1e-6. 

Marcus pointed out offline that some of the intrinsics might even have a
better precision compared to the generic implementation.

Cheers
Andrej

On Wed, Oct 03, 2018 at 04:57:32PM -0700, Ron Economos wrote:
> It depends on which box I look at.
> 
> 1) volk_32fc_x2_divide_32fc a_avx u_sse3
> 
> 2) volk_32fc_x2_divide_32fc a_avx u_avx
> 
> Ron
> 
> On 10/03/2018 08:05 AM, Müller, Marcus (CEL) wrote:
> > Well, I'd be willing to call that a bug, all in all:
> >
> > Though I totally get the "machine accuracy" argument, I'd at least
> > expect the same results when running the same program twice, on the
> > same machine.
> >
> > Now, I'm an author of one of the 32fc_x2_divide_32fc implementations;
> > I'd like to know what I can do to fix this. Ron, what was the machine
> > that volk_profile picked for you?
> >
> > By the way, just as for the float/char (and other ints) conversion
> > kernels, it's not inherently obvious who's right or wrong, the
> > optimized or the generic impl. So, we should be analyzing which values
> > led to the differing result.
> >
> > Best regards,
> > Marcus
> >
> > On Wed, 2018-10-03 at 06:52 -0700, Ron Economos wrote:
> >> That's the problem. If a set_output_multiple(4) in added to the
> >> constructor in divide_cc_impl.cc, it solves the issue.
> >>
> >> Ron
> >>
> >> On 10/03/2018 06:42 AM, Ron Economos wrote:
> >>> Well, I guess it's not really a bug. Most likely it has to do with the
> >>> accuracy difference between the x86 intrinsics and the C library. If
> >>> you look at the code in volk_32fc_x2_divide_32fc.h, the remaining
> >>> points that are not a multiple of four are calculated with the C
> >>> library. If the points from one run that are calculated with the C
> >>> library line up with points calculated with intrinsics in the next
> >>> run, there can be a mismatch.
> >>>
> >>> Ron
> >>>
> >>> On 10/03/2018 06:27 AM, Ron Economos wrote:
> >>>> It's a VOLK bug. Go into ~/.volk/volk_profile and change the
> >>>> volk_32fc_x2_divide_32fc line to generic. That fixes the issue here.
> >>>>
> >>>> Ron
> >>>>
> >>>>
> >>>> On 10/03/2018 05:46 AM, Piotr Krysik wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I simplified the flowgraph a bit and prepared a script that runs it
> >>>>> twice and compares the results.
> >>>>>
> >>>>> https://imgur.com/a/CSjOeLc
> >>>>>
> >>>>> In short something is wrong indeed.
> >>>>> Almost after every run of the script I get results with differences.
> >>>>>
> >>>>> I tested it on GNU Radio  3.7.12.0, I'm compiling the most fresh
> >>>>> version
> >>>>> now.
> >>>>>
> >>>>> Best Regards,
> >>>>> Piotr Krysik
> >>>>>
> >>>>> W dniu 03.10.2018 o 06:55, Reiichiro Nakano pisze:
> >>>>>> Here's an updated flowgraph where you don't need a separate file
> >>>>>> source. Just run the flowgraph twice for a few seconds each. You'll
> >>>>>> likely get different file sizes but `cmp` doesn't care, it'll still
> >>>>>> show the first differing byte which should still prove the bug exists.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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


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

Re: [Discuss-gnuradio] LDPC in GNURadio

[Andrej Rode]

Hi, 

On Sat, Oct 06, 2018 at 02:31:46PM +, Johannes Demel wrote:
> Hi,
 
> Earlier someone pointed out that all these implementations for LDPC codes are 
> not very fast. We would only have that with precompiled codes. This is one of 
> those flexibility vs. speed cases. I would assume that GR would lean towards 
> flexiblity here. Though, an OOT module which helps to integrate precompiled, 
> very fast LDPC codes is very interesting for special use cases. I assume the 
> DVB folks would appreciate it.

I can imagine having a LDPC implementation which will use specialized
precompiled codes if available and fall back to a generic implementation
if no specialized code is available.
This could be helpful to add already established protocols into GR
without sacrifice in flexibility.

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

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

Re: [Discuss-gnuradio] LDPC in GNURadio

[Andrej Rode]

Hi Sylvain, 

thanks for you thorough look into the state of the LDPC encoder/decoder.
I just skip the long text of wall and answer your questions from my
point of view:

> So my questions would be :
> 
> (1) Is cleaning up the mess worth it ?

I personally would like to see the FEC module cleaned up a bit. There is also a
viterbi decoder in gr-trellis which would be perfectly fine in gr-fec
and using the gr-fec API. Maybe even porting in the specialized LDPC for
gr-dtv would be possible for the parameters used in gr-dtv. (which does
not mean you have to do so)

> (2) Is completely breaking the API of those blocks acceptable ?

For post-3.8 releases breaking the API for these blocks (and integrating
them into the FEC API if they're not already there would be a big plus)

> (3) Is adding a dependency to M4RI library to gnuradio acceptable ?
> (possibly optional one, disabling LDPC if not present).

Looking at M4RI is available in Ubuntu, Fedora and is probably easy to
add to other Linux distributions/Windows etc etc. 
It is "only" a math library and has no dependencies beside libc. 

Cheers
Andrej

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


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

Re: [Discuss-gnuradio] GRCon 17 presentation slides page broken/gone.

[Andrej Rode]

Hi Andy, 

the contents of previous GNU Radio conferences haven't been migrated
yet. 
We are working on migrating them in a timely manner. 
Sorry for the inconveniences.

Cheers
Andrej

On Sun, May 20, 2018 at 08:31:38AM -0400, Andy Walls wrote:
> Oh, those who are so wise in the ways of the GNURadio website:
> 
> The following link returns "gr-404"
> 
> https://www.gnuradio.org/grcon-2017/program/grcon17-presentations/
> 
> I'm not sure if that is intentional or not.
> 
> Regards,
> Andy
> 
> ___
> 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 "GR-FBMC" WITH PyBOMBS

[Andrej Rode]

Hi, 

I've posted your build issue to the gr-fbmc issue tracker [0].
There it might be picked up and fixed upstream. 

[0] https://github.com/kit-cel/gr-fbmc/issues/1

On Mon, Apr 09, 2018 at 07:32:58PM -0500, Elkin Ducuara wrote:
> Hi everyone
> 
> I want to install gr-fbmc from pybombs. For this reason i executed the next
> command:
> 
> ~$sudo pybombs install gr-fbmc
> 
> But i have gotten the next errors:
> 
> "PyBOMBS - INFO - PyBOMBS Version 2.3.3a0
> PyBOMBS.Packager.apt - INFO - Install python-apt to speed up apt processing.
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
> installing binary packages:
> Install tree:
> |
> \- gr-fbmc
> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
> packages to prefix:
> PyBOMBS.install_manager - INFO - Installing package: gr-fbmc
> PyBOMBS.Packager.apt - INFO - Install python-apt to speed up apt processing.
> Clonar en «gr-fbmc»...
> remote: Counting objects: 3770, done.
> remote: Total 3770 (delta 0), reused 0 (delta 0), pack-reused 3770
> Receiving objects: 100% (3770/3770), 2.77 MiB | 85.00 KiB/s, done.
> Resolving deltas: 100% (2971/2971), done.
> Comprobando la conectividad… hecho.
> PyBOMBS.Packager.apt - INFO - Install python-apt to speed up apt processing.
> Configuring: (100%)
> [=]
> Building:(100%)
> [=]
> [  1%] Building CXX object lib/CMakeFiles/gnuradio-fbmc.dir/fbmc_config.cc.o
> /usr/local/src/gr-fbmc/lib/fbmc_config.cc: In member function ‘void
> gr::fbmc::fbmc_config::gen_preamble_sym()’:
> /usr/local/src/gr-fbmc/lib/fbmc_config.cc:277:7: error: ‘gr_uint16’ was not
> declared in this scope
>gr_uint16 start_state = 0xACE1u; /* Any nonzero start start will
> work. */
>^
> /usr/local/src/gr-fbmc/lib/fbmc_config.cc:278:18: error: expected ‘;’
> before ‘lfsr’
>gr_uint16  lfsr = start_state;
>   ^
> /usr/local/src/gr-fbmc/lib/fbmc_config.cc:285:17: error: ‘lfsr’ was not
> declared in this scope
>  bit = ((lfsr >> 0) ^ (lfsr >> 2) ^ (lfsr >> 3) ^ (lfsr >> 5)) & 1;
>  ^
> lib/CMakeFiles/gnuradio-fbmc.dir/build.make:62: fallo en las instrucciones
> para el objetivo 'lib/CMakeFiles/gnuradio-fbmc.dir/fbmc_config.cc.o'
> make[2]: *** [lib/CMakeFiles/gnuradio-fbmc.dir/fbmc_config.cc.o] Error 1
> CMakeFiles/Makefile2:137: fallo en las instrucciones para el objetivo
> 'lib/CMakeFiles/gnuradio-fbmc.dir/all'
> make[1]: *** [lib/CMakeFiles/gnuradio-fbmc.dir/all] Error 2
> Makefile:138: fallo en las instrucciones para el objetivo 'all'
> make: *** [all] Error 2
> PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
> messages.
> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
> gr-fbmc:
> Build failed.
> PyBOMBS.install_manager - ERROR - Error installing package gr-fbmc.
> Aborting.
> "
> 
> If anyone have had the same problem and/or know how solve it, please write
> me.
> 
> Thanks.

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


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


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

Re: [Discuss-gnuradio] ERROR DURING GR-GFDM INSTALLATION BLOCKS IN GNURADIO.

[Andrej Rode]

** [test] Error 8"
> > 
> > 
> > For show the cause of error of an specific item (for example "5 -
> > qa_simple_modulator_cc") I trying with the command line "ctest -V -R
> > qa_simple_modulator_cc" and the result is the next:> 
> > "user@USER:~/gr-gfdm/build$ ctest -V -R qa_simple_modulator_cc
> > UpdateCTestConfiguration  from :/home/user/gr-
> > gfdm/build/DartConfiguration.tcl> UpdateCTestConfiguration  from 
> > :/home/user/gr-
> > gfdm/build/DartConfiguration.tcl> Test project /home/user/gr-gfdm/build
> > Constructing a list of tests
> > Done constructing a list of tests
> > Checking test dependency graph...
> > Checking test dependency graph end
> > test 5
> > Start 5: qa_simple_modulator_cc
> > 
> > 5: Test command: /bin/sh "/home/user/gr-
> >gfdm/build/python/qa_simple_modulator_cc_test.sh"> 5: Test timeout 
> > computed to be: 9.99988e+06
> > 5: Traceback (most recent call last):
> > 5:   File "/home/user/gr-gfdm/python/qa_simple_modulator_cc.py", line
> >  24, in > 5: import gfdm_swig as gfdm
> > 5:   File "/home/user/gr-gfdm/build/swig/gfdm_swig.py", line 28, in
> >  > 5: _gfdm_swig = swig_import_helper()
> > 5:   File "/home/user/gr-gfdm/build/swig/gfdm_swig.py", line 24, in
> >  swig_import_helper> 5: _mod = imp.load_module('_gfdm_swig', fp, 
> > pathname, description)> 5: ImportError: 
> > /home/user/gr-gfdm/build/lib/libgnuradio-gfdm.so:
> >undefined symbol: volk_32f_index_max_32u> 1/1 Test #5: 
> > qa_simple_modulator_cc ...***Failed0.18 sec
> > 
> > 0% tests passed, 1 tests failed out of 1
> > 
> > Total Test time (real) =   0.19 sec
> > 
> > The following tests FAILED:
> >   5 - qa_simple_modulator_cc (Failed)
> > Errors while running CTest"
> > 
> > Then, How do I for solve the errors during gr-gfdm installation?
> > 
> > PD: I have installed previously the requeriments for gr-gfdm (GNU
> > Radio OOT and PyGFDM items).> Thank you all. 
> 

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


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


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

Re: [Discuss-gnuradio] High Pass and Low Pass performance not inverse

[Andrej Rode]

Hi John, 

On Tue, Mar 13, 2018 at 09:15:33AM -0400, John Ackermann N8UR wrote:
> I'm setting up a measurement program to look at the channel power inside 
> and outside a defined bandwidth centered at zero.  The idea is to get 
> the ratio of the power within a low pass filter (nominally 500 Hz), and 
> the power in the rest of the spectrum (192 kHz) with that same 500 Hz 
> chunk notched out.  Attached are a screenshot of the the flowgraph and 
> of an FFT showing the results.
> 
> What puzzles me is that the low pass filter has a defined flat-top, 
> while the high pass filter shows a very narrow notch.  I would expect 
> the two to have a similar shape.  (I'm using rectangular windows because 
> I want to get the actual noise power for the given bandwidth.)

Running this short python script will generate filtertaps from the
firdes functions in GNU Radio and plot the amplitude of their transfer functions
linearly.

```
#!/usr/bin/env python2

from gnuradio import filter
import numpy as np
import matplotlib.pyplot as plt


def main():
  lp = filter.firdes_low_pass(1.0, 192e3, 250.0, 25.0, 
filter.firdes.WIN_RECTANGULAR)
  hp = filter.firdes_high_pass(1.0, 192e3, 250.0, 25.0, 
filter.firdes.WIN_RECTANGULAR)

  plt.plot(np.abs(np.fft.fftshift(np.fft.fft(lp
  plt.plot(np.abs(np.fft.fftshift(np.fft.fft(hp

  plt.show()
  return True

if __name__ == "__main__":
  exit(not main())

```

Given your GNU Radio modules are in the Python path and you have
Matplotlib installed.
You can also run more verifications using the impulse responses.

> 
> Any thoughts on why this is happening, or on ways to make the two 
> responses more precisely mirror each other?

According to the impulse responses they mirror each other pretty well
and shouldn't cause what you are seeing.  I did not look at the source
code of the firdes_* functions though.

Cheers
Andrej

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


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

[Discuss-gnuradio] Website security breach (gnuradio.org)

[Andrej Rode]

Hello,

Last week we discovered that the Wordpress installation of the website had been 
compromised. The compromise allowed access to the system to an unauthenticated, 
unprivileged
remote user for at least the past year.

In the worst case scenario it is possible that the website has been serving 
hostile scripts, but we can find no evidence of this having occured.
Due to the large security implications to the system running the website we 
have shut it down and are now serving a static snapshot of the website until 
further notice.
This compromise only affected the Wordpress website (gnuradio.org) and its 
MySQL database. The wiki, cgit repository, LiveDVD images, and everything else 
are not affected.

We are considering how best to improve the security of the website in the long 
run.

Cheers
Andrej

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


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

[Discuss-gnuradio] Project Call March 2018 today

[Andrej Rode]

Hi everyone, 

today (in 10 minutes) the GNU Radio Project Call for March 2018 takes
place.

If you want to listen in: https://youtu.be/bNICMm49Jcw

You can find the agenda for the call here: 
https://wiki.gnuradio.org/index.php/Call20180315

Cheers
Andrej

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


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

[Discuss-gnuradio] Website maintenance (main website, wiki, pubs)

[Andrej Rode]

Dear all, 

due to stability problems the main gnuradio.org website, wiki and
pubs.gnuradio.org will experience a maintenance right now.

I expect them to be up again in a couple of hours. Sorry for the
inconvenience!

Cheers
Andrej

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


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

Re: [Discuss-gnuradio] GRCon 17 - Presentation videos available

[Andrej Rode]

Hi again, 

now all videos of talks held Monday through Thursday should be online
and published. You can find them in the GRCon17 playlist on youtube [0].
The previous youtube link was only a link to the first Keynote video.

Feel free to comment if there is something wrong. Also like and share
the videos to spread the word if you like them.

I'll publish the remaining video material in the next couple of days.
Basically only lightning talks and anything I messed up are missing.

[0] https://www.youtube.com/playlist?list=PLbBQHMnVMR43mM18y4r8L7l8bbYMgloFx
-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

[Discuss-gnuradio] GRCon 17 - Presentation videos available

[Andrej Rode]

Hi all, 

the first batch of videos from GRCon Monday is available in the GRCon17 
Playlist on YouTube. [0]
Remaining videos will be uploaded until end of next week.

Cheers
Andrej

[0] https://youtu.be/-0taq3endCI
-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

Re: [Discuss-gnuradio] Overlapping blocks and wires bug

[Andrej Rode]

Hi, 

On Wed, Nov 01, 2017 at 04:55:11PM +, Bakshi, Arjun wrote:
> Not sure if this is the right place, but a couple of annoying behaviors of 
> GRC.
> 
> 
> Often times when one adds a block to the flowgraph in GR, it'll go over a 
> wire or under another block.
> 
> 
> When it goes over a wire, often times clicking on the block will select the 
> wire underneath it, and move or disconnect it. The block on top should always 
> be selected, not the obscured part of the wire.
> 
> 
> When it goes under existing blocks, it's just hard to find.
> 
> 
> I'm experiencing this in version 3.7.10.1.

Can you create a new issue in our issue tracker [0]?

If not, I'll create one for further tracking.

Cheers
Andrej

[0] https://github.com/gnuradio/gnuradio/issues/

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


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

Re: [Discuss-gnuradio] Data types

[Andrej Rode]

Hir ,

On Tue, Oct 31, 2017 at 11:03:57PM -0400, Tellrell White wrote:
> Hello All
> I have a question concerning data types. I'm creating a sink block in python 
> that takes float values from a "divide" block that has a vector length of 
> 1024. The output port on the divide block is red. How can set the input of my 
> block to have a red input port?

You need to match the output type of the divide block (which is probably
float) _and_ you need to match the vector length of the divide block.
Best done with setting a parameter `vlength` and setting this as your
io_signature in the constructor:
`io_signature::make (1,  1, sizeof (float)*vlen)),`

This creates a block with a configurable vector length as input.

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


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

Re: [Discuss-gnuradio] CRC32 discrepancy

[Andrej Rode]

Hi Eric & Marcus, 

I just submitted a fix for this issue [0].
This should new have the correct behaviour.

Cheers
Andrej

[0] https://github.com/gnuradio/gnuradio/pull/1504
On Fri, Aug 04, 2017 at 11:32:13AM +0200, Marcus Müller wrote:
> Hi Eric!
> 
> Thanks for the bug report! Tracking that as an issue on github [1] now.
> 
> You don't happen to have a fix that you've tested already?
> 
> Best regards,
> 
> Marcus
> 
> 
> [1] https://github.com/gnuradio/gnuradio/issues/1407
> 
> 
> On 08/03/2017 04:54 PM, ERIC BANWART wrote:
> >
> > I am using the Stream CRC32 block and was having trouble getting the 
> > CRCs to pass. After some debugging I discovered that the 
> > calculated CRC is different depending on whether or not the source 
> > data is packed. This can be observed using the attached flow graph. 
> > The result of the packed stream appears to be correct. I looked at the 
> > code for the block (crc32_impl_bb.cc) and that see that regardless of 
> > the Packed setting in the block the CRC calculated with: 
> > d_crc_impl.process_bytes(in, packet_length);
> >
> >
> > I believe that for the unpacked case, either the bits need be repacked 
> > before the calculation or repeated calls to process_bits should be 
> > used in place of the the call to process_bytes.
> >
> >
> > My version of gnuradio is:  3.7.12git-126-g37d373ac
> >
> >
> > Thanks!
> >
> > Eric
> >
> >
> >
> > ___
> > 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


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


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

Re: [Discuss-gnuradio] Fwd: Random test failures when compiling GNURadio from source

[Andrej Rode]

Hi, 

On Mon, Oct 30, 2017 at 10:27:06PM +0100, Sebastian Müller wrote:
> I’ve noticed the same on our buildbot setup (and wanted to address this for
> a while). `qa_packet_format` is another candidate which seems to randomly
> fail. Also compiling on buildbot seems to fail sometimes randomly because
> of `M_SQRT2` or `M_LOG2E` undeclared errors.
Those are new, can you pinpoint to a specific failed build?

> 
> So, Kevin, without having a deeper look I assume the tests need to be
> revised. I’m also glad to have a look as soon as I find some time. Maybe we
> can accumulate faulty tests within this thread and start working from there.

I already started accumulating flaky/broken unittests some time ago in this 
issue:
https://github.com/gnuradio/gnuradio/issues/1261

Some of them are only triggered with `make -j N test` for great N.

Cheers
Andrej


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


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

Re: [Discuss-gnuradio] Integrate Mac in CI

[Andrej Rode]

Hi, 

> I’ve had the idea on extending our CI with a Mac installation. Many problems 
> remain undetected for a long time when using GNU Radio on a Mac, since we are 
> not many out there :) . Andrej, do you know if this is possible/how to do 
> this? I would gladly support you with this or take over the task!

From my side this is super easy if we have access to some sort of
Mac-based machine (doesn't matter if HW or a VM). I would need to do
some more work to setup proper authentication so the Mac can safely
connect to the Buildbot master. 

Other than that running builds/tests on a Mac is easier than on a
Windows-based machine.

Cheers
Andrej

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


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

Re: [Discuss-gnuradio] Package gnuradio-core was not found

[Andrej Rode]

Hi, 

> I am trying to run configure command for gnuradio-802.15.4-demodulation file 
> downloaded from github.
> https://github.com/septikus/gnuradio-802.15.4-demodulation
> It is showing these error.
>  checking for gnuradio-core >= 2... Package gnuradio-core was not found in 
> the pkg-config search path. Perhaps you should add the directory containing 
> `gnuradio-core.pc' to the PKG_CONFIG_PATH environment variable No package 
> 'gnuradio-core' found configure: error: Library requirements (gnuradio-core 
> >= 2) not met; consider adjusting the PKG_CONFIG_PATH environment variable if 
> your libraries are in a nonstandard prefix so pkg-config can find them.
> i have already installed gnuradio-companion and its working well.
> 
> I do not much programming and kindly tell what is the problem in simple terms 
> and what correction i should make?
> is it because these files are too old for my Ubuntu 16.04 and pkg-conig 
> version 0.29.1?

This module wasn't updated for about 10 years. Since then a lot of
things changed in GNU Radio and this code is not compatible with GNU
Radio anymore. If you really want to run this code you
either could try to install an old version of GNU Radio. Or you update
the module (requires some programming) to work with a newer version of
GNU Radio.

Cheers
Andrej

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


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

Re: [Discuss-gnuradio] Buffer: Change the oldest with the newest

[Andrej Rode]

Hi, 

> I have a GRC in which I am turning USRP stream to vectors of 1024 length.
> Then I have a DSP block (Block 1) that uses these blocks and gives an
> output of length 1024.
> 
> * Then, I want to accumulate 10 of these 1024 length blocks.
> * After 10 of these blocks accumulated, I will give these 10*1024 length
> block to another DSP block(Block 2).
> 
> After I used this 10*1024 block, I don't want this block to be completely
> erased, but I want that it should be updated with the new 1*1024 block
> coming from Block 1. Then I will use this updated 10*1024 block in Block 2.

This functionality is available as `history` function inside of a block.
If you write your own blocks you can call `set_history(9)` and then
will have 9+1 blocks in your input buffer. After you consumed this block
in the next call you again get 9+1 with the "newest" block in the
history being your previous block. Basically you will have a shift
register saving 9 previous blocks and giving them to you.

10x1024 might be more than the default buffer size will allow you, so
you also should increase that.

Cheers
Andrej

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


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

Re: [Discuss-gnuradio] Gnu radio and IDEs

[Andrej Rode]

Hi, 

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

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

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

Cheers
Andrej

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


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

Re: [Discuss-gnuradio] Checking that a flowgraph is done

[Andrej Rode]

Hi Gilad, 

On Fri, Oct 06, 2017 at 03:17:52PM +, Gilad Beeri (ApolloShield) wrote:
> I have a flowgraph used for simulations that uses a File Source with no
> repeat.
> I want to run some code after the flowgraph is done (-> when the source
> returns -1).
> How can I achieve that?

If you are ok with the flowgraph blocking your current thread you could
call `run()` on the top_block. Or you could continue doing other
calculations on your data after calling `start()` and then call `wait()`
on the top_block. `wait()` will either block until the flow graph is
done or return immediatly if the flowgraph was done already. In either
case you can be sure the flowgraph is done.

Cheers
Andrej

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


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

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

[Andrej Rode]

Hi all, 

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

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

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

Cheers,
Andrej

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

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


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

Re: [Discuss-gnuradio] set_output_multiple() and forecast() when there are multiple sources in a general block

[Andrej Rode]

Hey Tom,
On 16/12/16 14:30, Tom Early wrote:
> I am designing a general block that will split it's input into two
> outputs. 96 input items will become 9 items on one source and 3 items on
> another source. I have some questions:
> 
> Is it required to set both streams in forecast()?

Forecast just determines how many items the scheduler should provide on
each input port of your block to produce the requested number of output
items by a upstream block. I'd is you take the maximum number of items
you need at each input port to produce items on each output port.
> 
> How do I call set_output_multiple() where there are multiple sources,
> the larger stream, the first stream, the sum or what?

I would recommend you take the larger number of output items. The thing
is the scheduler will only request chunks of n*output_multiple items and
will give you a buffer with n*output_multiple for each output. (n>=1)
> 
> When general_work() is called, is noutput_items for one stream or
> something else?

noutput_items is basically the size of each of your output buffers. You
are free to produce 0 items or any number up to noutput_items items on
each of your outputs. For handling with multiple output streams with
different rates I'd recommend you take a look at [0], especially
forecast(), general_work(), consume() and produce() are interesting if
you work with multiple inputs and multiple outputs with different rates.
Maybe even history() if you want to retain a certain number of items for
the next call of general_work().

I hope I could help you with your question :)

Cheers,
Andrej

[0] http://gnuradio.org/doc/doxygen/classgr_1_1block.html



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

Re: [Discuss-gnuradio] How to properly add a pybombs packager

[Andrej Rode]

Hey Jared,

nice you want to add another package manager to PyBOMBS. I recently
added portage package manager  to PyBOMBS.

Based on your output these lines [0] give a clue what's happening.
I'd guess your functions do not properly report the installation status
back to PyBOMBS.Therefore PyBOMBS keeps trying to install wget with
every possible package manager left.

Cheers,
Andrej


[0]
```
PyBOMBS.PackageManager - DEBUG - Using packager zypper
PyBOMBS.Packager.zypper - OBNOXIOUS - install(wget,
static=False)
PyBOMBS.ReqScanner - OBNOXIOUS - Adding package with name wget
PyBOMBS.ReqScanner - OBNOXIOUS - End of requirements list
PyBOMBS.ReqScanner - OBNOXIOUS - Done parsing requirements
string `wget`
PyBOMBS.Packager.zypper - OBNOXIOUS - Calling ev for recursive
satisfier rule evaluation
PyBOMBS.Packager.zypper - DEBUG - Package wget has version
1.18-2.2  in zypper
PyBOMBS.monitor_process() - DEBUG - Running with elevated
privileges.
PyBOMBS._process_thread() - DEBUG - Executing command `['sudo',
'-H', 'zypper', 'install', '-y', 'wget']'
Loading repository data...
Reading installed packages...
'wget' is already installed.
No update candidate for 'wget-1.18-2.2.x86_64'. The highest available
version is already installed.
Resolving package dependencies...

Nothing to do.
PyBOMBS.monitor_process() - DEBUG - Thread signaled termination
or returned
PyBOMBS.monitor_process() - DEBUG - Return value: 0
PyBOMBS.PackageManager - INFO - getattr(zypper,
install)(Recipe: wget
category: baseline
```



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

Re: [Discuss-gnuradio] (no subject)

[Andrej Rode]

Hi Idress,

> There are some demo flowgraphs that should make clear how the toolbox works.
> 

Also you should have a look at the slides and Bachelor theses in the
repository. They should give you an insight in theory and give some
references on how the blocks work.

Cheers,
Andrej



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

Re: [Discuss-gnuradio] pybombs gnuradio vs gnuradio-default

[Andrej Rode]

Hello Jason,

> Why is there two different installs?

Basically gnuradio is the correct install for a pure gnuradio install.
gnuradio-default is more or less a meta-package installing gnuradio and
gr-osmosdr. This is most convenient if you want to use gnuradio with a
hardware device not supported by uhd. (RTL-sdr/airspy/hackrf or similar)

But you should also be able to install gnuradio-default if something fails?

Cheers
Andrej



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

Re: [Discuss-gnuradio] Minimal install of GNU Radio without GUI, etc possible?

[Andrej Rode]

Hey,

a similar system to have customized source-builds is used by portage
(Gentoo Package Manager) which mainly builds all kind of sources. In the
Gentoo World customizing builds (of libraries, applications...) is
achieved with "USE-flags". Maybe we can adopt this concept to PyBOMBS?
I can imagine having a gnuradio-default.lwr with all features enabled
(most convienient for users) and a gnuradio.lwr with specified "USE
flags"/feature flags. With these feature flags one could specify changes
in configuration and dependencies.

When installing a recipe an option can be specified to install or not to
install a specific feature which is then reported/saved to the prefix
configuration.

Maybe we want to have a feature like this. Another option is to create
new recipes for different usages.

Cheers
Andrej




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

Re: [Discuss-gnuradio] PyBOMBS: Error installing package python-zmq

[Andrej Rode]

Hi,

> Please submit the pullrequest! The package is definetely missing.
Done.

Cheers
Andrej



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

Re: [Discuss-gnuradio] PyBOMBS: Error installing package python-zmq

[Andrej Rode]

Hi,

I'm currently testing pybombs with arch in a chroot. I found some more
issues besides python-zmq with ArchLinux and going to tackle them now.

@Cyrille: try removing your prefix-directory and then installing again.
I added python2-pyzmq to the recipe and now installation gets stuck
somewhene else.

Best Regards,
Andrej

On 01/08/16 20:14, Jacob Gilbert wrote:
> Cyrille, I recently PR'd python-zmq as a dependency to GR as it is required
> for the ZMQ blocks to work from python. I did not check to see if this
> worked on arch though. If you want a workaround in the near term you can
> uncomment the line in gnuradio.lwr that adds python-zmq as a dependency.
> 
> Jacob
> 
> On Mon, Aug 1, 2016 at 10:55 AM, Cyrille DERORY <cyri...@derory.fr> wrote:
> 
>> I modified the file ~/.pybombs/recipes/gr-recipes/python-zmq.lwr below the
>> port line:
>>
>> #
>> # This file is part of PyBOMBS
>> #
>> # PyBOMBS is free software; you can redistribute it and/or modify
>> # it under the terms of the GNU General Public License as published by
>> # the Free Software Foundation; either version 3, or (at your option)
>> # any later version.
>> #
>> # PyBOMBS is distributed in the hope that it will be useful,
>> # but WITHOUT ANY WARRANTY; without even the implied warranty of
>> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> # GNU General Public License for more details.
>> #
>> # You should have received a copy of the GNU General Public License
>> # along with PyBOMBS; see the file COPYING.  If not, write to
>> # the Free Software Foundation, Inc., 51 Franklin Street,
>> # Boston, MA 02110-1301, USA.
>> #
>>
>> category: baseline
>> satisfy:
>>   deb: python-zmq
>>   rpm: python-zmq
>>   port: py27-zmq
>>   pacman: python2-pyzmq
>>
>>
>>
>>
>> But it still not working even after I did a manual install of
>> python2-pyzmq package with command line:
>> sudo pacman -S python2-pyzmq
>> (python2-pyzmq-15.2.0-1 is installed)
>> https://www.archlinux.org/packages/community/x86_64/python2-pyzmq/
>>
>> verbosity mode:
>>
>>  PyBOMBS.PackageManager - DEBUG - Checking if package python-zmq is
>> installed.
>> PyBOMBS.PackageManager - DEBUG - Checking if package python-zmq is
>> installed.
>> Install tree:
>> |
>> \- gr-gsm
>>|
>>+- libosmocore
>>|  |
>>|  \- libtalloc-dev
>>|
>>+- gr-osmosdr
>>|  |
>>|  +- gr-iqbal
>>|  |  |
>>|  |  \- gnuradio
>>|  | |
>>|  | \- python-zmq
>>|  |
>>|  \- gnuradio
>>| |
>>| \- python-zmq
>>|
>>\- gnuradio
>>   |
>>   \- python-zmq
>> PyBOMBS.PackageManager - DEBUG - Checking if package python-zmq is
>> installed.
>> PyBOMBS.install_manager - INFO - Installing package: python-zmq
>> PyBOMBS.PackageManager - DEBUG - install(python-zmq, static=False)
>> PyBOMBS.PackageManager - DEBUG - Using packager pip
>> PyBOMBS.PackageManager - DEBUG - Using packager pacman
>> PyBOMBS.PackageManager - DEBUG - Using packager pkgconfig
>> PyBOMBS.PackageManager - DEBUG - Using packager cmd
>> PyBOMBS.PackageManager - DEBUG - Using packager source
>> PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package
>> python-zmq
>> PyBOMBS.install_manager - ERROR - Error installing package python-zmq.
>> Aborting.
>>
>>
>> Cyrille
>>
>>
>> 2016-08-01 17:55 GMT+02:00 Andrej Rode <m...@andrejro.de>:
>>
>>> Hey Cyrille,
>>>
>>>
>>> On 01/08/16 17:20, Cyrille DERORY wrote:
>>>> Thank you for your reply,
>>>>
>>>> my distro/OS is archlinux and package manager is pacman:
>>>> https://wiki.archlinux.org/index.php/pacman
>>>
>>> Try adding:
>>>   pacman: python2-pyzmq
>>> in ~/.pybombs/recipes/gr-recipes/python-zmq.lwr below the port line.
>>> If you can install gnuradio successfully I'll submit a pull-request
>>> against gr-recipes master.
>>>
>>> Best Regards,
>>> Andrej
>>>
>>> P.S. Don't forget to add the mailing-list in your reply. Your answer
>>> might be interesting for other folks.
>>>
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> 



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

Re: [Discuss-gnuradio] PyBOMBS: Error installing package python-zmq

[Andrej Rode]

Hey Cyrille,


On 01/08/16 17:20, Cyrille DERORY wrote:
> Thank you for your reply,
> 
> my distro/OS is archlinux and package manager is pacman:
> https://wiki.archlinux.org/index.php/pacman

Try adding:
  pacman: python2-pyzmq
in ~/.pybombs/recipes/gr-recipes/python-zmq.lwr below the port line.
If you can install gnuradio successfully I'll submit a pull-request
against gr-recipes master.

Best Regards,
Andrej

P.S. Don't forget to add the mailing-list in your reply. Your answer
might be interesting for other folks.




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

Re: [Discuss-gnuradio] PyBOMBS: Error installing package python-zmq

[Andrej Rode]

Hi Cyrille,

> this is my first time with PyBOMBS.
> Do you have any idea what is the problem with:
> "PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package
> python-zmq"

the python-zmq recipe can be satisfied if installed on a system with
deb, rpm or port package manager.
Which distro/OS are you using?
None of the above package managers is found on your system and then
PyBOMBs falls back to installation from source and there is no
source-installation defined for python-zmq.

Bet Regards,
Andrej




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

Re: [Discuss-gnuradio] Channel model - the identity channel

[Andrej Rode]

Hey Raj,

> introduces a delay that can be corrected by applying the taps [0,0,0,1].
> See the attached flowgraph that subtracts the signals before and after
> the channel model; if you let taps = 1, the two signals don't cancel. If
> you use taps = [0,0,0,1], they do. 

The delay you are seeing is introduced by the fractional_resapmler
inside the channel_model block. The FIR filter inside the fractional
resampler needs to build up and therefore introduces a initial delay of
three samples.

If you want to know more about the insides of the channel model I
suggest you look at the sources [0][1] yourself.

Greetings,
Andrej

[0] ./gr-channels/lib/channel_model_impl.cc
[1] ./gr-channels/lib/channel_model_impl.h



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

Re: [Discuss-gnuradio] Big GRC flowgraphs

[Andrej Rode]

Hey John,

you could create a hier-block and parametrize it as needed and then drop it 16+ 
times in your flowgraph. Or you could create a hier block with a variable 
number of inputs and outputs, but I'm not sure if that's possible.

Best Regards,
Andrej



On June 9, 2016 2:43:27 PM GMT+02:00, John Ackermann   N8UR  
wrote:
>I'm working on a flowgraph that has a lot of blocks (sets of identical
>blocks for 16+ channels).
>
>What's the best way to manage this on-screen in GRC?  Can GRC handle
>multiple sheets, or is there a way to group a bunch of blocks into a
>"superblock" that shows in the flowgraph as a single block?
>
>Thanks!
>
>John
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] stream_mux tag propagation

[Andrej Rode]

Hey Merlin,

> The tagged_stream_mux uses the packet_len tags to determine the input
> lengths. It outputs a new packet_len that is the sum of the input
> packet_lens. So here you also loose information about the streams that were
> muxed.
>
> What sense would the standard tag propagation make in this case?

I have adjusted the tag propagation policy to at match least your example. But
it should be able to handle tag propagation in general preserving tag position
relative to its original stream.

If you have installed GNU Radio from git-master you should be able to apply
this patch and compile GNU Radio with it. I will submit a pull request, maybe
this patch will be in master soon.

Best Regards,
Andrej


From 512bd5d2b082807c6687a546d5fe096c9c9b7af6 Mon Sep 17 00:00:00 2001
From: Andrej Rode <m...@andrejro.de>
Date: Mon, 25 Apr 2016 14:33:17 +0200
Subject: [PATCH] gr-blocks: fix tag propagation policy for stream mux block

---
 gr-blocks/lib/stream_mux_impl.cc | 8 
 1 file changed, 8 insertions(+)

diff --git a/gr-blocks/lib/stream_mux_impl.cc b/gr-blocks/lib/stream_mux_impl.cc
index 698cf89..4d5e71b 100644
--- a/gr-blocks/lib/stream_mux_impl.cc
+++ b/gr-blocks/lib/stream_mux_impl.cc
@@ -53,6 +53,7 @@ namespace gr {
 }
   }
   d_residual = d_lengths[d_stream];
+  set_tag_propagation_policy(TPP_DONT);
 }

 void
@@ -76,6 +77,7 @@ namespace gr {
   const char *in;
   int out_index = 0; // Items written
   gr_vector_int input_index(d_lengths.size(), 0); // Items read
+  std::vector stream_t;

   while (out_index < noutput_items) {
 if (ninput_items[d_stream] <= input_index[d_stream]) {
@@ -91,6 +93,12 @@ namespace gr {
 );
 in = (const char *) input_items[d_stream] + input_index[d_stream]*d_itemsize;
 memcpy([out_index*d_itemsize], in, items_to_copy*d_itemsize);
+get_tags_in_window(stream_t, d_stream,input_index[d_stream],input_index[d_stream] + items_to_copy);
+BOOST_FOREACH(gr::tag_t t, stream_t){
+  t.offset = t.offset - nitems_read(d_stream) - input_index[d_stream] + nitems_written(0) + out_index;
+  add_item_tag(0, t);
+}
+
 out_index += items_to_copy;
 input_index[d_stream] += items_to_copy;
 d_residual -= items_to_copy;
--
2.7.3



signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] stream_mux tag propagation

[Andrej Rode]

Hi Merlin, 

> Is that a bug in stream_mux? It means that the streams cannot be demuxed by
> looking at the tags.

There is no special processing for stream tags in stream_mux. It simply takes 
the input streams and copies them input-wise into the output buffer. Stream 
tags are propagated according to their initial offset at the input. And there 
you get behaviour you described.

Did you have a look at tagged_stream_mux ? Maybe it will serve your needs? It 
sounds not unreasonable to have a switch to change tag propagation in 
stream_mux to your desired behaviour. Or is it a major breakage to the tag 
propagation policy?

Best Regards, 
Andrej








signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Multiple Inputs in Tagged Stream Block

[Andrej Rode]

Hello Jenny, 

I can try to help you, but I'm not quite sure if I am right. If I am wrong I 
will be corrected soon. 

> >> Generating: "/home/jenny/Tutorials/rx_ofdm.py"
> >> Executing: "/home/jenny/Tutorials/rx_ofdm.py"
> >> Using Volk machine: sse4_2_64_orc
> >> gr::log :FATAL: geese_vcvc0 - Missing a required length tag on port 1 at
> >> item #0
> >> thread[thread-per-block[46]: ]: Missing length tag.

This error tells you that your block is missing a length tag in one of his 
inputs. A Stream Tag on the first sample is a requirement for a tagged stream 
block. This Stream Tag has to provide information about how much input data 
your block has to process.
I assume you don't have an tagged stream on each of your inputs and this 
causes a problem for your tagged stream block. 

Best you provide a screenshot of your example flowgraph (the relevant parts). 
Based on the error it is nothing inside of your block but the way you are 
trying to feed it with samples. 

Best Regards, 
Andrej


signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Own block in GNURADIO-COMPANION

[Andrej Rode]

Hello Ganesh, 

> I have successfully created my own block(not fully), but I am not able to
> see this block in GNURADIO's block list. What should I do? 

I guess you have created your own OOT-Block with gr_modtool. Did you read and 
understand the guided tutorials? [0] If not, you should definitively do so.
Most likely you are interested in the programming topics [1] or [2]. 
There you will find a description how to configure your block for usage in GNU 
Radio Companion (GRC) and how to install it to your system.

Best Regards, 
Andrej

[0] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[1] 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python
[2] 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++


signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Embedding qtgui widgets inside QFrame

[Andrej Rode]

Hey, 

> So ICE problems. Getting out the good ol' tome of /fixing elaborate
> technology by //random incantation and//extensive guesswork/, does
> deleting ~/.ICEauthority fix the issue? For me, it does.

I'm having a Gentoo-Machine with KDE4 running here, even without an 
~/.ICEauthority file mentioned above.

I also was stuck with a blank window. Attaching gdb did not bring anything 
interesting up to analyze.

Then I put in several print commands in between:
   38 print('assigned window')  
   
   39 vsg = vsg_gui.Ui_MainWindow() 
   
   40 print('generated mainwindow') 
   
   41 vsg.setupUi(win)  
   
   42 print('setup gui')

And surprisingly it worked! Maybe you need some kind of wait() in between?
I'm not that kind into GUI design to debug this issue completely but maybe 
this tip helps :)

Best Regards, 
Andrej


signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Guided Tutorial Inquiry

[Andrej Rode]

Hi, 

> The problem looked like the cmake process could not find swig.  SWIG 2.0.12
> could be found.  According to the gnuradio dependencies (
> http://gnuradio.org/doc/doxygen/build_guide.html), it should need at least
> 1.3.31.

Oh, I did not notice the second screenshot. The SWIG-Version is the main 
problem here.
Alexander's solution should work. 

Regards, 
Andrej

signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Guided Tutorial Inquiry

[Andrej Rode]

Hello Rocye, 

>  But upon executing it as indicated from the tutorial, there were no output
> displayed and the terminal part of GRC shows an Import Error: No module
> named tutorial_swig as shown in the image below.

Great to hear you doing the tutorials. It looks like your install path for the 
python module is not in your $PYTHONPATH and python is not able to find your 
module. If you did not change the install path, then you should add 
'/usr/local/lib/python2.7/site-packages' to your environment variable 
$PYTHONPATH. Maybe in your '~/.profile' or something similar. 

Best Regards, 
Andrej





signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-gsm python problem "ImportError: No module named osmosdr"

[Andrej Rode]

Hello Uli, 

> -
> ~/GSM/gr-gsm/apps$ ./grgsm_livemon
> Traceback (most recent call last):
>   File "./grgsm_livemon", line 29, in 
> import osmosdr
> ImportError: No module named osmosdr
> --

This error looks like the path you installed gr-osmosdr is not included in 
your PYTHONPATH.

You probably should add '/usr/local/lib/python2.7/site-packages' or generally 
speaking '$INSTALL_DIR/lib/python2.7/site-packages' to your $PYTHONPATH. 

Best Regards, 
Andrej



signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dive into gnu-radio

[Andrej Rode]

Hi Desmond and everyone else, 

> With my knowledge the mechanics of
> writing an OOT module and getting it to show up in GRC is fairly simple.
> It's the knowledge of radio signals and digital signal processing where I
> have the most difficulty.

as a EE student I can recommend getting familiar with the concepts taught in 
the lectures 'Signals & Systems', 'Digital Communications I+II' and maybe 
'Digital Signal Processing'. Material as well as recordings can be found at 
[0]. Before looking through the lectures you should now there are some 
requirements in mathematics you should know. For someone with a (university) 
background in CS I think there should be a way to get in touch with integral 
transforms/discrete integral transforms and the concept behind 
digital/discrete thinking.

Concering literature I would recommend to look for a book with a title 
'Signals and Systems', unfortunatly I can only name a german book for 
recommendation for this one.  If you are familiar with the basic concept of 
signal processing you could try to get your hands on 'Digital Communications' 
by John G. Proakis. It is written in a very mathematical way but you should be 
able to understand the concepts behind it and then verify them by looking 
through GNU Radio blocks or writing some blocks yourself. 

That is what I can recommend you from an EE students' point of view. I started 
dealing with signal processing about two years ago. And I think with a 
background in some kind of university mathematics you should be able to grasp 
the basic concepts of digital signal processing in about a half year or less.
Most of the thinks in DSP are based on math and so are the blocks/Code in GNU 
Radio.

If there is something missing or I am wrong, correct me :)

Best Regards, 
Andrej

[0] http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/


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