Re: [gr-sigmf] 3.8.2 Update

[Ben Hilburn]

That was quick! Thanks, Kyle :)

Cheers,
Ben

On Wed, Sep 9, 2020 at 1:34 PM Kyle A Logue  wrote:

> For anyone using gr-sigmf with GNU Radio 3.8, we just updated our
> public/release branch to work with current GNU Radio master branch:
> https://github.com/the-aerospace-corporation/gr-sigmf/
>
> *Kyle Logue*
> *Senior Engineering Specialist*
> *⚝ The Aerospace Corporation*
>

Organizational Announcement: Partnership with The SETI Institute

[Ben Hilburn]

Hi all -

Next week is GRCon, and prior to the conference we would like to share some
exciting news. We are partnering with The SETI Institute to collaborate and
further our joint goals in open & accessible research, education, and
technology development with software radio. We first started working with
The SETI Institute and some of their UC Berkeley faculty a couple of years
ago, and since then have coordinated a number of successful events and
co-developments.

Specifically, what this partnership means for GNU Radio is that The SETI
Institute will assume back-office responsibilities for the project and
provide operational support - such as accounting and infrastructure. GNU
Radio maintains its own leadership and administration duties and will
appoint a Principal Investigator to directly represent the project inside
the SETI Institute.. Through our partnership, we expect to pursue new
funding opportunities for both the SETI Institute and GNU Radio, and
continue to expand the impact of GNU Radio's free software approach to
research & education.

In GNU Radio's 19-year history, we've been through several different
iterations of organizational support for the project and community. As most
projects do, GNU Radio started out supported through the private companies
/ consultancies of the core developers working on it. Eventually, we
founded the GNU Radio Foundation, and several years later migrated to the
Free Software Foundation. Our partnership with the SETI Institute reflects
our continued growth and success, and will provide the support we need to
continue on that trajectory for years to come.

The Free Software Foundation has expressed its support and excitement for
this partnership, and is working closely with GNU Radio and SETI Institute
leadership to make the back-office transition smooth.

You can read more about this partnership from The SETI Institute's
perspective here (just posted):
https://www.seti.org/press-release/seti-institute-and-gnu-radio-join-forces

We will be discussing this announcement further at GRCon. As always, feel
free to reach out if you have questions, and Happy Hacking!

Cheers,
The GNU Radio Officers

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

[Ben Hilburn]

Hi Miklos -

This is fantastic! I'm really excited to see where you take your technology
and design going forward, and I'm sure the community will greatly benefit
from you sharing it.

Congratulations again on your 2nd place victory at the challenge!

Cheers,
Ben

On Sun, Oct 27, 2019 at 8:21 AM Michael Dickens 
wrote:

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

[Discuss-gnuradio] GRCon19 Schedule is Live

[Ben Hilburn]

Hi all -

If you haven't seen it, yet, the schedule for GRon19 is live! You can find
it here:

https://openconf.org/GRCon19/modules/request.php?module=oc_program=program.php=program

The talk schedule for GRCon is full, but posters and papers can still be
submitted & accepted for the program. If you have any questions, just let
us know!

Reminder for authors who have already had your paper accepted - please have
your camera-ready draft uploaded a week before GRCon.

Registrations for GRCon can be purchased here:

https://tickets.gnuradio.org/grcon19/

And, as always, thank you to our sponsors for making GRCon possible!

https://www.gnuradio.org/grcon/grcon19/sponsors/

We look forward to seeing everyone in Huntsville next month.

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

[Discuss-gnuradio] GRCon19 Price Reminder

[Ben Hilburn]

Hi all -

Just a reminder that prices will go up for GRCon19 on August 1st! If you
haven't bought your tickets yet, head here:

https://tickets.gnuradio.org/grcon19/

Also, don't forget to book in the GRCon19 room block at the conference
venue!

https://www.marriott.com/event-reservations/reservation-link.mi?id=1553879040993=GRP=resvlink

The TPC has advised that the first round of acceptance notifications for
submissions will be going out shortly! If you haven't submitted yet, get
your abstract in soon to make the second round of reviews.

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

[Discuss-gnuradio] GRCon19 Updates & Reminders

[Ben Hilburn]

Hi all!

This year's keynotes have been announced! This year, our keynote speakers
will be:

   - Travis Goodspeed
   - Mark Shuttleworth, Canonical
   - Robert Suggs, Marshall Space Flight Center
   - Mark Spencer, Digium

You can see more details about the conference program on the website, located
here
.
Note that talks & submitted tutorials have not yet been added to the
program!

Next up, the first deadline for submissions to GRCon is next Monday 1 July!
Please get your talk, poster, and paper submissions in as soon as you can.
The submission website is here:

https://openconf.org/GRCon19/openconf.php

Remember that GRCon maintains a policy that you do not have to present at
the conference to publish in the technical proceedings. If you're
submitting a presentation or poster, we encourage you to also submit a
paper to the proceedings. If you're unable to make the event but would like
to publish and share your work, you can submit a paper alone, which if
accepted will be posted with this year's TP at pubs.gnuradio.org.

Lastly, per my annual call to register earlier, please register as soon as
you can! Conference registration can be found here:

https://tickets.gnuradio.org/grcon19/

Please note that
*prices will go up on August 1st.*

If you haven't booked your hotel, yet, you can book in our discounted room
block at the conference hotel using this link:

https://www.marriott.com/events/start.mi?id=1553879040993=GRP

As usual, if you have any questions, please don't hesitate to reach out!
You can reach the organizing team at gr...@gnuradio.org

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

Re: [Discuss-gnuradio] GR-inspector ACM error

[Ben Hilburn]

I _am_ the Ben of that post, but unfortunately I no longer have that file.
I'm CC'ing Sebastian, just in case he has a copy saved off somewhere!

Cheers,
Ben

On Wed, May 15, 2019 at 1:59 PM Daniel Andres Palacios 
wrote:

> Just in case you are the same Ben of this post
> <http://lists.gnu.org/archive/html/discuss-gnuradio/2017-01/msg00048.html>:
> I'll be tankful if you help to load the model to the ACM blok.
>
> Thank you.
> Sorry for my bad english, It's not my native language.
>
> On Wed, May 15, 2019 at 7:52 AM Daniel Andres Palacios 
> wrote:
>
>> Hi Ben, thanks for your replay.
>>
>> I trained and exported a tensorflow model based on this code
>> <https://github.com/chrisruk/models/blob/master/cnn_generate.py>. This
>> returns a folder with a file "*saved.pb* " and another folder called
>> *variables*, then I tried to import the saved.pb file into the AMC block
>> and got that error.
>>
>> On Wed, May 15, 2019 at 12:47 AM Ben Hilburn 
>> wrote:
>>
>>> Hi Daniel -
>>>
>>> So just to confirm, you do indeed have an `~/export.meta` file? Can you
>>> share more of the log that shows the issue you are encountering?
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Sun, May 12, 2019 at 12:27 PM Daniel Andres Palacios <
>>> dapa...@gmail.com> wrote:
>>>
>>>> Hi all. I have had problems using the ACM block of GR-inspector.
>>>> Although I export the tensorflow graph, I continue to get the error
>>>> RuntimeError: Expected meta graph file missing ~ / export.meta.
>>>> I'd appreciate your help.
>>>>
>>>> --
>>>> *Daniel Andrés Palacios Carabalí*
>>>> *Student of Telemathics engineering*
>>>> *Icesi University- Cali, Colombia*
>>>> *===*
>>>> *Estudiante de Ingeniería Telemática*
>>>> *Universidad Icesi. - Cali, Colombia*
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>
>> --
>> *Daniel Andrés Palacios Carabalí*
>> *Student of Telemathics engineering*
>> *Icesi University- Cali, Colombia*
>> *===*
>> *Estudiante de Ingeniería Telemática*
>> *Universidad Icesi. - Cali, Colombia*
>>
>
>
> --
> *Daniel Andrés Palacios Carabalí*
> *Student of Telemathics engineering*
> *Icesi University- Cali, Colombia*
> *===*
> *Estudiante de Ingeniería Telemática*
> *Universidad Icesi. - Cali, Colombia*
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Website Down

[Ben Hilburn]

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] free(): invalid pointer for AM demod block at Gnuradio 3.7.13.5

[Ben Hilburn]

Nice catch, Volker! Glad you're up and running, Ignatius.

And you're right, this should be emitting an error message that's actually
useful - the output here really didn't help at all. I've opened a bug on
Github in reference to this. It should be relatively straight-forward to
tackle, which makes it a great issue for a beginner contributor!

https://github.com/gnuradio/gnuradio/issues/2493

Cheers,
Ben

On Tue, May 14, 2019 at 6:27 PM Ignatius Rivaldi 
wrote:

> Ahh that solves it, I thought that was a bandpass filter and passband
> frequency is the lower cutoff frequency, thanks
>
> On Wed, May 15, 2019 at 2:07 AM Volker Schroer  wrote:
> >
> > You have set passband frequency to 0 ! So your passband reaches from 0
> > to 0. That make no sense. Probably a parameter check should be
> > introduced to the demod block Further  you should add a throttle block
> > after your source.
> >
> > Same problem can be found in 3.8.
> >
> >
> > Am 14.05.19 um 15:02 schrieb Ignatius Rivaldi:
> > > I'm running Arch Linux with Gnu Radio 3.7.13.5 and
> > > Python 2.7.16 (default, Mar 11 2019, 18:59:25)
> > > [GCC 8.2.1 20181127] on linux2
> > >
> > > and if I try to use AM demod block with anything the flowgraph crashes
> > > with this:
> > >
> >  Warning: This flow graph may not have flow control: no audio or RF
> hardware blocks found. Add a Misc->Throttle block to your flow graph to
> avoid CPU congestion.
> > >
> > > Executing: /usr/bin/python2 -u
> /home/feanor/Development/SDR/top_block.py
> > >
> > > free(): invalid pointer
> > >
> >  Done
> > >
> > > This is just a AM demod block with null sink and null source attached
> > > to it, reproduction flowgraph is attached to this email
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC19] Block header parsing tool

[Ben Hilburn]

Thanks, Arpit! Looking forward to seeing your design & plan once you've
worked it out with your mentor =)

Cheers,
Ben

On Tue, May 14, 2019 at 4:59 PM Arpit Gupta  wrote:

> Hi everyone,
> I have created a blog
>  for
> updating the progress and the milestones of the GSoC'19 project *Block
> header parsing tool. *The next blog will contain the updated timeline for
> the upcoming weeks and the milestones for the first week of the coding
> period.
> For viewing the exact code, you can go through my forked repository
>  of the GNU Radio project.
> Further, I will create a project with major tasks on the to-do list on the 
> project
> board .
>
> I am highly excited to work on this project. So, if you have any queries
> or suggestions on the project, please update on the mailing list or
> create issues on the forked repository.
>
> Thanks.
>
> Regards,
> Arpit Gupta
> Indian Institute of Technology Roorkee
> ___
> 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] [GSoC2019]: First report from Bowen

[Ben Hilburn]

Sounds great, Bowen, and thanks! I'm looking forward to seeing your work
progress =)

Cheers,
Ben

On Tue, May 14, 2019 at 1:43 AM Bowen Hu  wrote:

> Hi Johannes,
>
> Thank you for your advice. The source code of GNU Radio in GitHub
> repository is definitely a great reference, I have fork and clone it.
>
> As I discussed with my mentor, Marcus, for OOT module which I am going to
> work on, the stable version acquired through distros would be enough.
>
> I might port the code to a newer version later.
>
> Best regards,
> Bowen
> ​
>
> --
> *From:* Johannes Demel 
> *Sent:* Mon, 13 May 2019
> *To:* Bowen Hu
> *Subject:* Re: [Discuss-gnuradio] [GSoC2019]: First report from Bowen
>
> Hi Bowen,
> it's great that you start to work on your project right away. Since you
> want to implement a new feature for GNU Radio, I'd suggest to use the
> latest GNU Radio version which is the one in the repository. To rephrase
> it, I recommend to use GNU Radio 3.8. Though, I assume you already
> discussed this with your mentors or will do so.
> Therefore I suggest to use a source build/install instead of the version
> provided by your distribution.
> Cheers
> Johannes
> Am 12.05.19 um 18:18 schrieb Bowen Hu:
> > Hi all,
> >
> > I am happy to be accepted by GSoC 2019 working on cycle-accurate
> > simulation of Verilog. Here
> > 
> > (https://b0wen-hu.github.io/2019/05/12/First-report/)
> > is my first report.
> >
> >
> > ## Progress this week
> > I have set up the working environment and read some tutorials for GNU
> > Radio development in the last few days.
> >
> > My current working environment is Ubuntu 18.04 LTS installed GNU Radio
> > version 3.7.11 by apt, but I am considering switch to newest Ubuntu
> > 19.04 which shipped with GNU Radio version 3.7.13 by apt.
> >
> > I am following the tutorial and created my first module gr-howto (This
> > may not be a good name, so I will change the module name in the coming
> > week). I will continue to read tutorials, hopefully I could finish them
> > (from chapter 2 to chapter 7) in the next week.
> >
> > I also managed to run the simulation of a simple Verilog module with
> > Verilator, it works as anticipated, you can find it here. This is just a
> > standalone simulation program, in order to let the GNU Radio work with
> > the Verilator-generated file, there are much work to do.
> >
> > ## Plan next week
> > Finish all the tutorials from chapter 2 to chapter 7.
> >
> > Try to make the Verilator related header file available in GNU Radio
> > blocks. A source block like this (flicker.v) would be a good start.
> >
> > ## Issue(s)
> > The module name gr-howto need to be changed.
> >
> >
> > Best regards,
> > Bowen
> >
> > ___
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar

[Ben Hilburn]

Hey Brad -

On Fri, May 17, 2019 at 3:19 PM Brad Hein  wrote:

>
> Thank you Ben, and others for capturing the true essence of what makes
> gnuradio and its community so great. Although it spans a great range of
> disciplines and requires tremendous work (for some) to use and extend, the
> community is normally quite friendly and willing to help.
>

I think this captures much of what makes GNU Radio so great, and I'm happy
you share that opinion! =)


> Of course each individual should spend time doing the legwork to solve
> their own issues, not over-relying on the community. The project has on
> occasion been referred to as "Grad-ware" because so commonly it is used by
> students in grad-school, and requires an equivalent level of sophistication
> to use and extend.
>

Hah, that's actually the first time I had heard that phrase!


> I know my journey with Gnuradio started 10-15 years ago and it has taken
> me as many years to finally get to the point where I can build some of the
> logic that I had been contemplating for so many years. Some of my greater
> ambitions will take another 5-10 years yet.
>

I think this is natural to SDR as a technology, and it's also why it's so
fascinating in many regards, in my opinion. There's so much to learn!


> By the way the C++ suggestions that were so kindly provided were quite
> useful in helping me get on the right foot, and with a bit of refactoring
> my block is up and running - and  is thread-safe now. I studied C++ in
> college many years ago, and haven't had to use it since then, except for my
> hobby projects in Gnuradio, so I am immensely appreciative of those who
> have the patience to not only read the mailing list inquiries, but to also
> offer their insights, without which some of us would never be able to use
> and extend Gnuradio for useful purposes.
>

That's fantastic! I'm very happy to hear you have things up and running -
nice work!

Thanks to Marcus and Albin for providing pointers, here!


> The more people that use the platform, the more the platform grows both in
> community and in extensions and add-ons (custom blocks).
>

Very much agreed, and I think the network effect
 plays a not insignificant
role. I also strongly believe that most of the value of open source lies in
the community, which is one of the reasons we try so hard to cultivate,
grow, and support our community - which is one of the best around (IMO) =)

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

Re: [Discuss-gnuradio] GR-inspector ACM error

[Ben Hilburn]

Hi Daniel -

So just to confirm, you do indeed have an `~/export.meta` file? Can you
share more of the log that shows the issue you are encountering?

Cheers,
Ben

On Sun, May 12, 2019 at 12:27 PM Daniel Andres Palacios 
wrote:

> Hi all. I have had problems using the ACM block of GR-inspector. Although
> I export the tensorflow graph, I continue to get the error RuntimeError:
> Expected meta graph file missing ~ / export.meta.
> I'd appreciate your help.
>
> --
> *Daniel Andrés Palacios Carabalí*
> *Student of Telemathics engineering*
> *Icesi University- Cali, Colombia*
> *===*
> *Estudiante de Ingeniería Telemática*
> *Universidad Icesi. - Cali, Colombia*
> ___
> 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] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Ben Hilburn]

Sounds good, Moses! Keep us posted.

Cheers,
Ben

On Sat, May 11, 2019 at 9:16 PM Moses Browne Mwakyanjala 
wrote:

> Hello Ben,
> I did try to comment out the decode_u8 vector, without any luck.
> Interestingly, Michael was able to run the program successfully on his
> platform, which turned out to be much newer than the one I'm using (3.7.11).
> I'm in the process of installing a new release of GNU Radio and test the
> hypothesis. Unfortunately, the installation of the latest GNU Radio
> releases is surprisingly painful and lengthy.
> I will let you know what happens after I have tested the program on the
> new installation.
>
> Regards,
> Moses.
>
> On Thu, May 9, 2019 at 10:02 PM Ben Hilburn  wrote:
>
>> Hey Moses -
>>
>> I don't have an immediate answer for you, but it seems likely the issue
>> is with `decoded_u8`. Before spending time trying to debug why this might
>> be happening when the code is used in GNU Radio versus not, it would be
>> good to figure out where exactly the leak is occurring.
>>
>> You should be able to test the `decoded_u8` hypothesis by commenting out
>> the existing malloc & free, and just using some hard-coded dummy vector or
>> something similar. Your application obviously won't work, but what you care
>> about is how that affects the memory leak.
>>
>> Separately, is there a reason you are dynamically allocating that vector?
>> You are freeing the memory within the same scope, anyway. I guess I'm not
>> sure how much data that realistically is, so perhaps that's why you're
>> putting it on the heap?
>>
>> Cheers,
>> Ben
>>
>> On Wed, May 8, 2019 at 1:33 PM Moses Browne Mwakyanjala <
>> mbkit...@gmail.com> wrote:
>>
>>> Hello Ben,
>>> Yes. There are no memory leaks when the block is disabled.
>>>
>>> Regards,
>>> Moses.
>>>
>>> On Wed, May 8, 2019 at 5:50 PM Ben Hilburn 
>>> wrote:
>>>
>>>> Hi Moses -
>>>>
>>>> And just to confirm, if you remove your LDPC block from that flowgraph
>>>> or replace it with a passthrough, you don't see the leak?
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> On Tue, May 7, 2019 at 7:24 PM Moses Browne Mwakyanjala <
>>>> mbkit...@gmail.com> wrote:
>>>>
>>>>> Hello Ben,
>>>>> Thanks.
>>>>> For LDPC, the executable can be found at
>>>>>
>>>>> *gr-ccsds/examples/LDPC/ldpc_2/build-ldpc_decoder-Desktop-Debug/ldpc_decoder.*
>>>>> The C++ executable for Turbo code can be found at
>>>>> *gr-ccsds/lib/fec/turbo/deepspace-turbo/bin/deepspace_turbo*
>>>>>
>>>>> I'm not very familiar with Valgrind so I monitored the memory usage by
>>>>> looking at system monitor on my Ubuntu laptop. The memory usage is almost
>>>>> constant, at around 17.1 Mbs for the ldpc_decoder executable. On GNU 
>>>>> Radio,
>>>>> the memory usage jumps by huge steps (100Mb) in a matter of seconds until
>>>>> all the memory (the ram is around 8 gigs) is fully consumed.
>>>>>
>>>>> Thanks for links to the memory buffer blog post. I will have a look.
>>>>> Regards,
>>>>> Moses.
>>>>>
>>>>> On Tue, May 7, 2019 at 10:13 PM Ben Hilburn 
>>>>> wrote:
>>>>>
>>>>>> Hey Moses -
>>>>>>
>>>>>> This is really cool work! Thanks so much for sharing it. Michael's
>>>>>> suggestion of pushing it was a good one. I haven't looked at the code 
>>>>>> yet,
>>>>>> but:
>>>>>>
>>>>>> The code was able to run smoothly in a C++ application but
>>>>>>> experienced memory leaks in GNU Radio.
>>>>>>>
>>>>>>
>>>>>> I'm curious how confident you are in this? It might be worthwhile to run 
>>>>>> the pure-C++ version through Valgrind just to double-check, if you 
>>>>>> haven't already.
>>>>>>
>>>>>> I also have one question regarding buffering in GNU Radio. Since
>>>>>>> iterative decoding with a large number of iterations and large block 
>>>>>>> sizes
>>>>>>> takes time to complete, the input pmt data that is not consumed 
>>>>>>> immediately
>>>>>>> will have to be stored somewhere. Is that the case? Could that be the
>>>>>>> reason for the memory leak?
>>>>>>>
>>>>>>
>>>>>> Things do get stored until buffers and full, and then backpressure
>>>>>> builds up through the flowgraph. This shouldn't cause memory leaks.
>>>>>>
>>>>>> For a more thorough explanation of this, check out this excellent
>>>>>> blog post from Marcus Mueller!
>>>>>>
>>>>>> https://www.gnuradio.org/blog/2017-01-05-buffers/
>>>>>>
>>>>>> Cheers,
>>>>>> Ben
>>>>>>
>>>>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Announcement: XTRX SDR workshop in Berlin this Sunday

[Ben Hilburn]

Hey Alex -

Thanks for sharing this! Will anything be recorded & posted online?

Cheers,
Ben

On Fri, May 10, 2019 at 9:55 AM Alexander Chemeris <
alexander.cheme...@gmail.com> wrote:

> Hello, GNURadio'ers,
>
> It's a bit of a short notice but if you're in Berlin this weekend, we
> would like to invite you to a mini-workshop on XTRX SDR this Sunday, May 12.
>
> The workshop speaker is Sergey Kostanbaev, the brainfather of XTRX, so
> prepare your most difficult questions ;) GNU Radio will, of course, be
> covered as one of the primary use cases.
>
> Details:
>
>- Speaker: Sergey Kostanbaev, Founder and Head of Engineering at
>Fairwaves
>- Duration: 2h+
>- When: Sunday, May 12 from 3pm onwards
>- Where: IN-Berlin e.V., Lehrter Str. 53, 10557 Berlin
>- Admission: Free + Open to anyone
>
> Preliminary agenda:
>
>- Why XTRX. What's different in XTRX SDR?
>- XTRX hardware capabilities
>- XTRX carrier board (USB3 / PCIex2)
>- Understanding XTRX software layers
>- Building XTRX driver & host libraries
>- PCIe Driver specifics, ARM specifics, porting to other platforms
>- Native API overview, Spoapy wrapper
>- GNURadio plugins, building simple applications
>- Q
>
> XTRX homepage: https://xtrx.io/
>
> XTRX crowdfunding page: https://crowdsupply.com/fairwaves/xtrx
> 
>
> Previous talks, e.g. OsmoDevCon 2018 one year ago:
> https://media.ccc.de/v/MNL3YJ
> PS Many thanks to Harald "LaF0rge" Welte for his help with the workshop
> organization.
>
> --
> Regards,
> Alexander Chemeris.
> CTO/Founder, Fairwaves, Inc.
> https://fairwaves.co
> ___
> 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] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Ben Hilburn]

Ah, interesting. Thanks so much for the update, Michael, and keep us
posted! If this reveals a bug in the runtime we'll want to get that filed
for 3.8, assuming it hasn't already been fixed.

And, of course, thanks for providing support, Michael!

Cheers,
Ben

On Fri, May 10, 2019 at 7:43 AM Michael Dickens 
wrote:

> FYI: After some work off-list, we think the issue is that Moses is using
> an older release of GNU Radio (3.7.11.1). He's trying to get the version
> updated to the most recent 3.7 release. When I execute his OOT scripts
> using a GR devel version a little prior to the current release, I have no
> memory leak issues. If updating GR doesn't do the trick, then I'll keep
> working with him to try to narrow down where the issue is occurring (e.g.,
> as Ben notes: concentrating on the `decoded_u8` & memory allocation /
> freeing). Memory bugs can manifest themselves in "red herring" ways, and I
> think that's the case here: that GR 3.7.11.1 has a memory bug that's being
> triggered by his OOT's code & based on casual debugging of the issue it
> looks like the issue is in his code but in reality it's in GR somehow. More
> as this progresses ... - MLD
>
> On Thu, May 9, 2019, at 4:03 PM, Ben Hilburn wrote:
>
> Hey Moses -
>
> I don't have an immediate answer for you, but it seems likely the issue is
> with `decoded_u8`. Before spending time trying to debug why this might be
> happening when the code is used in GNU Radio versus not, it would be good
> to figure out where exactly the leak is occurring.
>
> You should be able to test the `decoded_u8` hypothesis by commenting out
> the existing malloc & free, and just using some hard-coded dummy vector or
> something similar. Your application obviously won't work, but what you care
> about is how that affects the memory leak.
>
> Separately, is there a reason you are dynamically allocating that vector?
> You are freeing the memory within the same scope, anyway. I guess I'm not
> sure how much data that realistically is, so perhaps that's why you're
> putting it on the heap?
>
> Cheers,
> Ben
>
>
> ___
> 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] Two instances of the same custom block walk into a bar

[Ben Hilburn]

The topic of "what kinds of questions go on gnuradio-discuss" has come up a
couple of times over the last few weeks, and we've had a lot of fresh
subscriptions over the same period (I get all the subscribe / unsub
notices), so I'll take this opportunity to quickly answer the question.
What Marcus and Albin have said are both correct, but I want to clarify
things for anyone new =)

It is our intention that users feel welcome and free to post any question
related to GNU Radio usage to this list. SDR is a tremendously complex
technology, and involves everything from electronics manufacturing to web
development. There is no such thing as a person that is an expert in all of
these things, and we can't and don't expect users to necessarily have the
expertise to know exactly where a problem lies.

At the same time, we do expect people asking for help to be willing to
spend the necessary time to debug their issue, and respect guidance given
on-list when referrals are made to non-GNU Radio tutorials (e.g., a
programming language or communications theory).

It really is quite common for, say, a signal processing engineer who is an
expert algorithm developer to try to build something in GNU Radio, only to
discover that they need to use Linux and they have no idea what that means.
They might very well ask a basic question on this list, as from their
perspective, they just want to use GNU Radio. That's fine. It's also fine
for someone to respond to them and point them to a Linux tutorial (kindly).
And if someone feels especially generous and wants to tutor them through
the process, that's great! It's better done off-list, though.

When referring someone to non-GNU Radio material, please do it in a way
that is actually useful. If someone is trying to figure out how to build
something from source, saying, "Here's a book on computer science." is not
terribly useful. Sending them to a tutorial on compiling software in Linux
would be, though.

I keep meaning to add this to the wiki and just haven't gotten to it. We
actually had a page on the old Redmine site about the sorts of advice you
can get on-list, etc., but it got lost in the move. That said, even the old
page wasn't as complete as it ought to be. We answer enough of these
questions that it's probably worthwhile having a list of useful tutorials
for various topics that we can recommend.

As always, everyone on this list should be treated with respect and
kindness. If you get frustrated by a question or discussion, simply don't
respond, and if you think something steps over the line, please refer it to
me or Martin.

Cheers,
Ben

On Thu, May 9, 2019 at 4:33 PM Marcus D. Leech 
wrote:

> On 05/09/2019 04:18 PM, Albin Stigö wrote:
>
> I absolutely agree with you. There are also other completely unrelated
> issues that keep coming up like Linux, python and x11. But I don't think
> there's any great harm in ending a topic by ever-so-gently pointing people
> in the right direction.
>
> Oh, indeed, and I don't want to discourage people from "diving right in",
> but that needs to be balanced with keeping the "support envelope"
>   for this forum manageable.
>
> It is the case that being really successful with a framework like Gnu
> Radio requires non-trivial facility in a number of different disciplines,
> and
>   there really is no substitute for developing that facility.  I'm fairly
> sure that other specialized programming frameworks go through the same
>   thing, and I wonder how they cope as a community...
>
>
>
> On Thu, May 9, 2019, 22:05 Marcus D. Leech 
> wrote:
>
>> On 05/09/2019 02:54 PM, Albin Stigö wrote:
>>
>> Every instance of a block is an instance of the c++ class but like Nick
>> says all your variables are static and not member variables. Those need to
>> be declared in the header. Your two block instances are referring to the
>> same variables and that's why things get messed up.
>>
>> "A tour of C++" by Bjarne Stroustrup is a good refresher on C++.
>>
>> --Albin
>>
>> I'm going to suggest, ever-so-gently, that discuss-gnuradio, and Gnu
>> Radio in general aren't the places for learning C++.  There are forums
>>   already for that.
>>
>> I'm saying this only because in the 15 years () I've been involved
>> with Gnu Radio, I see an alarming number of cases where the
>>   intrepid Gnu Radio developer actually doesn't have much in the way of
>> programming experience in the underlying languages used,
>>   and arrives here, nearly-certain that their problem is GR related,
>> rather than an improper use of the underlying programming language.
>>
>> My guess is that other specialized-framework environments have the same
>> issue.   Fortunately, most people here are helpful regardless.
>>   But it shouldn't be a growing *expectation*, IMHO.
>>
>>
>>
>> On Thu, May 9, 2019, 20:46 Nick Foster  wrote:
>>
>>> It looks like you've declared a bunch of static variables within your
>>> block's namespace. Those variables (including pointers!) will be shared
>>> with 

Re: [Discuss-gnuradio] Planet Frequency and Tracking Integration with GNURadio

[Ben Hilburn]

Hey Mike -

Whoa, this is cool - thanks so much for sharing it!

It sounds like you wrote it principally to facilitate something of a soft
hand-off between two receivers positioned around an occlusion, but do you
have thoughts on the utility of expanding it past receiver diversity?
Thinking through how it could be used or expanded next week for the
hackfest at the ATA =)

Cheers,
Ben


On Thu, May 9, 2019 at 12:11 PM Michael Piscopo 
wrote:

> HI everyone, another new tracking module that now integrates with GNURadio
> I just released here:
> https://github.com/ghostop14/skytrack
>
> Skytrack takes signal tracking out past gpredict with earth-based
> satellites and allows tracking (doppler frequency shifts and azimuth and
> elevation) out to solar system bodies (thanks to the python skyfield
> library).  Use case: pointing an antenna at the Moon or Mars.  It talks
> seamlessly to the new gr-gpredict-doppler GNURadio modules I pushed last
> week (https://github.com/ghostop14/gr-gpredict-doppler.git) to bring live
> doppler frequency updates into GNURadio.
>
> It's a little "rough" as a python script, and the skyfield library went
> through some updates late last year, but let me know if anyone has any
> issues.
>
> One more set of new modules I'm working on that I'll try to push hopefully
> before summer will pull a bigger picture together with a GNURadio block
> that can monitor inbound power and provide state output, and an input
> selector that integrates with it to automatically switch receivers based on
> signal strength to select the best receiver/antenna for a particular
> frequency.
>
> Ultimate goal/Big Picture: Multiple receivers monitoring the same
> space-based signal that can automatically select the best input based on
> power, and only record to file (using the new gr-filerepeater enhancements)
> when the signal should be (and is) present.  All this because I'm lazy and
> don't want to have to keep moving my antenna with North/South passes or
> have to keep running to my computer with each pass to start/stop recording
> a pass!
>
> ___
> 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] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Ben Hilburn]

Hey Moses -

I don't have an immediate answer for you, but it seems likely the issue is
with `decoded_u8`. Before spending time trying to debug why this might be
happening when the code is used in GNU Radio versus not, it would be good
to figure out where exactly the leak is occurring.

You should be able to test the `decoded_u8` hypothesis by commenting out
the existing malloc & free, and just using some hard-coded dummy vector or
something similar. Your application obviously won't work, but what you care
about is how that affects the memory leak.

Separately, is there a reason you are dynamically allocating that vector?
You are freeing the memory within the same scope, anyway. I guess I'm not
sure how much data that realistically is, so perhaps that's why you're
putting it on the heap?

Cheers,
Ben

On Wed, May 8, 2019 at 1:33 PM Moses Browne Mwakyanjala 
wrote:

> Hello Ben,
> Yes. There are no memory leaks when the block is disabled.
>
> Regards,
> Moses.
>
> On Wed, May 8, 2019 at 5:50 PM Ben Hilburn  wrote:
>
>> Hi Moses -
>>
>> And just to confirm, if you remove your LDPC block from that flowgraph or
>> replace it with a passthrough, you don't see the leak?
>>
>> Cheers,
>> Ben
>>
>> On Tue, May 7, 2019 at 7:24 PM Moses Browne Mwakyanjala <
>> mbkit...@gmail.com> wrote:
>>
>>> Hello Ben,
>>> Thanks.
>>> For LDPC, the executable can be found at
>>>
>>> *gr-ccsds/examples/LDPC/ldpc_2/build-ldpc_decoder-Desktop-Debug/ldpc_decoder.*
>>> The C++ executable for Turbo code can be found at
>>> *gr-ccsds/lib/fec/turbo/deepspace-turbo/bin/deepspace_turbo*
>>>
>>> I'm not very familiar with Valgrind so I monitored the memory usage by
>>> looking at system monitor on my Ubuntu laptop. The memory usage is almost
>>> constant, at around 17.1 Mbs for the ldpc_decoder executable. On GNU Radio,
>>> the memory usage jumps by huge steps (100Mb) in a matter of seconds until
>>> all the memory (the ram is around 8 gigs) is fully consumed.
>>>
>>> Thanks for links to the memory buffer blog post. I will have a look.
>>> Regards,
>>> Moses.
>>>
>>> On Tue, May 7, 2019 at 10:13 PM Ben Hilburn 
>>> wrote:
>>>
>>>> Hey Moses -
>>>>
>>>> This is really cool work! Thanks so much for sharing it. Michael's
>>>> suggestion of pushing it was a good one. I haven't looked at the code yet,
>>>> but:
>>>>
>>>> The code was able to run smoothly in a C++ application but experienced
>>>>> memory leaks in GNU Radio.
>>>>>
>>>>
>>>> I'm curious how confident you are in this? It might be worthwhile to run 
>>>> the pure-C++ version through Valgrind just to double-check, if you haven't 
>>>> already.
>>>>
>>>> I also have one question regarding buffering in GNU Radio. Since
>>>>> iterative decoding with a large number of iterations and large block sizes
>>>>> takes time to complete, the input pmt data that is not consumed 
>>>>> immediately
>>>>> will have to be stored somewhere. Is that the case? Could that be the
>>>>> reason for the memory leak?
>>>>>
>>>>
>>>> Things do get stored until buffers and full, and then backpressure
>>>> builds up through the flowgraph. This shouldn't cause memory leaks.
>>>>
>>>> For a more thorough explanation of this, check out this excellent blog
>>>> post from Marcus Mueller!
>>>>
>>>> https://www.gnuradio.org/blog/2017-01-05-buffers/
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installing GNURadio On Raspberry Pi

[Ben Hilburn]

Hey Pete -

I am sorry if I came across as cynical and sarcastic.  I didn't mean
> to.  I really wanted to know if anyone could make GNURadio work on a RPi.
>

Thanks, and it's okay. Tone and meaning are easily lost on mailing lists,
so we try to be extra cautious - especially when someone is experiencing
difficulties =)

I was really happy to see Glen's post, too! We'll work on getting that
filesystem broadly available for people to work with.


> I'll be the first to say I know nothing about Linux and Python. However,
>No matter how I install it, my flow graph just
> won't run when it is enabled.
>

I totally understand how that's been a frustrating flow, believe me, and
your story isn't uncommon. SDR can really be quite difficult and
overwhelming given the sheer number of technical fields involved.

Luckily during this process, last night, I discovered that I don't need
> the osmocom/rtlsdr block.  I can get the stream from my rtlsdr using the
> command:
> rtl-sdr -f  -s  /tmp/aFIFO
> where a FIFO is created with mkfifo aFIFO.  Then read the FIFO with a
> file source block.
>

Ah, nice hack!


> It might not have as good a SNR as on windows but I think I can adjust
> some filtering and move some gains around and it will be acceptable.
>
> So, I'm off and running to complete my project and I'm not looking back
> (I hope).
>

Yay! Very happy to hear that.

Maybe if I need to do this for another project I'll start over. It looks
> like Glen and Marcus are using Ubuntu where as I have been using
> Raspbian.  I'll go that route next time.
>

Yeah, that was an interesting note that came out of the thread - I hadn't
heard of difficulties with the latter, before. Good to know going forward,
for sure.

Cheers,
Ben


>
> Thanks,
>
> Pete
>
>
>
> On 5/7/2019 3:20 PM, Ben Hilburn wrote:
> > Hi Pete -
> >
> > Yes, I personally know of multiple. Albin's work of implementing volk
> > kernels for TujaSDR <https://tujasdr.com/>, shared here on the list
> > with some regularity, is an excellent example.
> >
> > On Wed, May 1, 2019 at 5:32 PM P C  > <mailto:pc...@yahoo.com>> wrote:
> >
> > Problem Solved! .NOT!
> > Tell me, is anyone running GNURadio on a Raspberry Pi (3-B) using an
> > RTL-SDR dongle?
> > I thought I cured my problems then the next day, more problems.
> > This is what I thought fixed my problem (but later, didn't).
> >
> >
> > This kind of thing can be difficult to debug, but please refrain from
> > cynical sarcasm here - especially if you want help and support.
> >
> > If you're willing to share your progress and current issues, I'm sure
> > there are people willing to provide some thoughts.
> >
> > Cheers,
> > Ben
>
>
> ___
> 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] RPi Filesystem Image

[Ben Hilburn]

Hi Glen -

We’ve put our event detection on three Raspberry Pi 3B +
> for confirming events in the forward direction (not side lobes).
>

Wow, this is really cool. Thanks so much for sharing!


> I have a 8 GB image .iso that I could put on line this weekend.
> Where is appropriate for such large files?  We installed everything
> on one Pi then just copied the image to the other SD cards.
>

That would be excellent! Storage & bandwidth are indeed tough, though.

We (GNU Radio) pay for storage on Google's cloud servers, and we could host
it there. Do you have a Google account? If so, and you can upload the image
to a Google Drive account and share it with me, I should be able to easily
replicate it over to GNU Radio's storage.

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

Re: [Discuss-gnuradio] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Ben Hilburn]

Hi Moses -

And just to confirm, if you remove your LDPC block from that flowgraph or
replace it with a passthrough, you don't see the leak?

Cheers,
Ben

On Tue, May 7, 2019 at 7:24 PM Moses Browne Mwakyanjala 
wrote:

> Hello Ben,
> Thanks.
> For LDPC, the executable can be found at
>
> *gr-ccsds/examples/LDPC/ldpc_2/build-ldpc_decoder-Desktop-Debug/ldpc_decoder.*
> The C++ executable for Turbo code can be found at
> *gr-ccsds/lib/fec/turbo/deepspace-turbo/bin/deepspace_turbo*
>
> I'm not very familiar with Valgrind so I monitored the memory usage by
> looking at system monitor on my Ubuntu laptop. The memory usage is almost
> constant, at around 17.1 Mbs for the ldpc_decoder executable. On GNU Radio,
> the memory usage jumps by huge steps (100Mb) in a matter of seconds until
> all the memory (the ram is around 8 gigs) is fully consumed.
>
> Thanks for links to the memory buffer blog post. I will have a look.
> Regards,
> Moses.
>
> On Tue, May 7, 2019 at 10:13 PM Ben Hilburn  wrote:
>
>> Hey Moses -
>>
>> This is really cool work! Thanks so much for sharing it. Michael's
>> suggestion of pushing it was a good one. I haven't looked at the code yet,
>> but:
>>
>> The code was able to run smoothly in a C++ application but experienced
>>> memory leaks in GNU Radio.
>>>
>>
>> I'm curious how confident you are in this? It might be worthwhile to run the 
>> pure-C++ version through Valgrind just to double-check, if you haven't 
>> already.
>>
>> I also have one question regarding buffering in GNU Radio. Since
>>> iterative decoding with a large number of iterations and large block sizes
>>> takes time to complete, the input pmt data that is not consumed immediately
>>> will have to be stored somewhere. Is that the case? Could that be the
>>> reason for the memory leak?
>>>
>>
>> Things do get stored until buffers and full, and then backpressure builds
>> up through the flowgraph. This shouldn't cause memory leaks.
>>
>> For a more thorough explanation of this, check out this excellent blog
>> post from Marcus Mueller!
>>
>> https://www.gnuradio.org/blog/2017-01-05-buffers/
>>
>> Cheers,
>> Ben
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installing GNURadio On Raspberry Pi

[Ben Hilburn]

Hi Pete -

Yes, I personally know of multiple. Albin's work of implementing volk
kernels for TujaSDR , shared here on the list with
some regularity, is an excellent example.

On Wed, May 1, 2019 at 5:32 PM P C  wrote:

> Problem Solved! .NOT!
> Tell me, is anyone running GNURadio on a Raspberry Pi (3-B) using an
> RTL-SDR dongle?
> I thought I cured my problems then the next day, more problems.
> This is what I thought fixed my problem (but later, didn't).
>

This kind of thing can be difficult to debug, but please refrain from
cynical sarcasm here - especially if you want help and support.

If you're willing to share your progress and current issues, I'm sure there
are people willing to provide some thoughts.

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

Re: [Discuss-gnuradio] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Ben Hilburn]

Hey Moses -

This is really cool work! Thanks so much for sharing it. Michael's
suggestion of pushing it was a good one. I haven't looked at the code yet,
but:

The code was able to run smoothly in a C++ application but experienced
> memory leaks in GNU Radio.
>

I'm curious how confident you are in this? It might be worthwhile to
run the pure-C++ version through Valgrind just to double-check, if you
haven't already.

I also have one question regarding buffering in GNU Radio. Since iterative
> decoding with a large number of iterations and large block sizes takes time
> to complete, the input pmt data that is not consumed immediately will have
> to be stored somewhere. Is that the case? Could that be the reason for the
> memory leak?
>

Things do get stored until buffers and full, and then backpressure builds
up through the flowgraph. This shouldn't cause memory leaks.

For a more thorough explanation of this, check out this excellent blog post
from Marcus Mueller!

https://www.gnuradio.org/blog/2017-01-05-buffers/

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

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Ben Hilburn]

Hey Brad - just checking in! This is an interesting experiment, and I would
love to hear how it went!

Big thanks to Kevin and JMF for providing very helpful guidance, here, too
=)

Cheers,
Ben

On Thu, May 2, 2019 at 7:12 PM Kevin Reid  wrote:

> On Thu, May 2, 2019 at 1:22 PM Brad Hein  wrote:
>
>> I took a Raspberry Pi and attached a 48KHz USB sound card, with a big
>> magnetic loop antenna fed into the mic. A little cheesy? yes! But I'd like
>> to try and see if I can receive VLF. It's in a remote location with little
>> to no interference so I'm thinking my chances should be good. The challenge
>> I'm facing is that I need to write the SDR logic to "tune" throughout the
>> 0-24KHz tuning range.
>>
>> My question is, being that a sound card source presents samples in float
>> and not the usual complex data type, can I still apply the same SDR logic
>> that we use for SSB/FM/AM demodulation such as those presented in the
>> Gnuradio tutorials (eg.
>> http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf)
>> and if not, how do I go about translating the float input into something I
>> can use to feed existing AM/FM/SSB demodulator flowgraphs?
>>
>
> The first thing you need to do is a "float to complex" operation (which
> will leave the imaginary/Q part zero). If you were to plot the spectrum of
> the resulting you would see that it is symmetric around 0 Hz, containing an
> extra copy of all the signals you're receiving, but that is no worse than a
> more typical received spectrum where the other half contains unrelated
> signals.
>
> After that, the approach is exactly the same as any other receiver
> flowgraph that supports receiving at an offset from the hardware
> center/zero frequency. You can use either the "Frequency Xlating FIR
> Filter" block (which combines a frequency shift and a low pass filter) or
> the "Rotator" block (which performs a frequency shift and would usually be
> followed by a separate filter), and the frequency shift of that block
> should be under user control for "tuning". Then you have a baseband signal
> that you can demodulate.
> ___
> 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] Audio source cannot use 2 outputs (Stereo) in windows

[Ben Hilburn]

Sounds like you got your issue resolved, Gary? This one was a doozy to
follow, and I'm glad you got it sorted.

And thanks to Marcus for helping sort through it!

Cheers,
Ben

On Mon, May 6, 2019 at 7:17 AM Gary.Simpkins 
wrote:

> Hi Marcus.
>
> It was late last night and I missed the errors in the
> grnradio-config-info -- prefsdir response.
>
> It had the dirs twice. So I changed the Prefix in windows to be just
> GNUradio-3.7, and the tried again.
>
> The prefs now has details includng portaudio.
>
> When I start gnuradio companion  I now see lots of warnings about files
> already existing.
>
> When try to generate with the audio source I get a lot of audio config
> lines. all to do with portaudio
>
> BUT  --IT Looks like portaudio is working for me on windows.
>
> Certainly I get two outputs. If they are the I and Q Ioutputs t is my
> next test, but looking very good.
>
> Many Many thanks.
>
> Regards
>
> Gary
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 05/05/2019 17:43, Marcus Müller wrote:
> > Hi Gary,
> >
> >> This confuses simple folk like me.
> > this confuses simple folks such as me, too!
> >
> > That --prefsdir output is most defintely bogus. I can speculate what
> > happened there, however:
> >
> >> Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
> > That --prefsdir value is part of the source code that gets compiled
> > into the tool/the GNU Radio libraries. Normally, you wouldn't do that,
> > "hardwiring" a directory path into a library, but write it in a
> > configuration file or something.
> >
> > However, in this case, that's the place we start looking into to find
> > the configuration files. So, that's the one thing that actually need to
> > hardwire.
> >
> > So, there's a text string "Z:\gr-build\src-
> > stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which is
> > probably a remnant of the machine that your GNU Radio got built on
> > (again, how did you install that?).
> > Sadly, the "\" gets interpreted by the compiler to be "escape symbol",
> > so that you can have things like "\n" for newline in strings. Luckily,
> > none of the first letters of directory names combined with "\" give a
> > valid escape sequence, so the compiler just silently drops the "\" and
> > this is the string you end up with.
> >
> > I'll admit it: that's funky, and I didn't know that happened. We'll
> > most definitely will have to rewrite something to make this work under
> > windows (which uses backslashes for directory separation, unlike
> > unixoids, which use forward slashes).
> >
> > So, why does --userprefsdir work, but --prefsdir not?
> >
> > Well, --userprefsdir is built from environment variables at runtime, so
> > it's correct, not mangled by a compiler.
> >
> > I hear you say, that's fine and all, and now?
> >
> > Welll! I thought it strange that, although your userprefsdir seems
> > correct, GNU Radio didn't read the configuration file you modified. So,
> > down the rabbit hole it goes. Here's our culprit, in prefs.cc:
> >
> >std::vector
> >prefs::_sys_prefs_filenames()
> >{
> >  std::vector fnames;
> >
> >  fs::path dir = prefsdir();
> >  if(!fs::is_directory(dir))
> >return fnames; // >
> >   […]
> >
> >  // Find if there is a ~/.gnuradio/config.conf file and add this to
> >  // the end of the file list to override any preferences in the
> >  // installed path config files.
> >  fs::path userconf = fs::path(gr::userconf_path()) / "config.conf";
> >  if(fs::exists(userconf)) {
> >fnames.push_back(userconf.string());
> >  }
> >
> >  return fnames;
> >}
> >
> > So what happens here is that if the prefsdir isn't a proper directory,
> > and Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d bloody
> > well excels at not being a proper directory, it just throws the towel
> > and doesn't try to scan the userprefsdir things for configuration
> > files.
> >
> > I'm fully away of the irony saying the following in a > 10 emails
> > thread that started with a sound card problem:
> >
> > The solution should be simple.
> >
> > There's a way of overriding the hardwired prefsdir! We don't even have
> > to set it to the *right* directory, just any path that is actually a
> > directory. The way to do that would be setting an environment variable
> > "GR_PREFIX" that leads to the right place.
> >
> > So, I don't actually know where these things get installed to on
> > Windows, or on your individual machine, but: Can you look for a
> > directory "conf.d" in a path ending in etc\gnuradio\conf.d?
> >
> > Let's say it's C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d .
> >
> > then, you'd have to do something like
> >
> > set GR_PREFIX=C:\Programs\gnuradio\dragonsbehere
> > gnuradio-config-info --prefsdir
> >
> > If that now prints
> > C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d, we're almost
> > there. Try, from the same command window,
> >
> > 

Re: [Discuss-gnuradio] Data loss during transmission (OFDM .bmp file)

[Ben Hilburn]

Hey Simran -

All of this is to say that your communications system design does not
appear to be robust to the impairments and complexities of wireless
channels, some of which Marcus mentioned. Can you share what your specific
goal is or why you're undertaking this work? Depending on what you are
trying to achieve, you might not need something quite so complex.

Cheers,
Ben



On Sun, May 5, 2019 at 2:11 PM Kevin McQuiggin  wrote:

> Read, read read!  Simple questions often lead to very complex answers.
>
> You might start your studies with "The Scientist & Engineer's Guide to
> Digital Signal Processing” by S. Smith.
>
> Kevin
>
> > On May 5, 2019, at 9:46 AM, Marcus Müller 
> wrote:
> >
> > Well, noise happens, and synchronization isn't instantaneous. Things
> > that aren't detected can't be received, and bit errors that the FEC
> > can't correct are bit errors in the received data.
> >
> > That's the beauty and the curse of wireless communications.
> >
> > Best regards,
> > Marcus
> >
> > On Sat, 2019-05-04 at 20:26 -0400, Simran Kaur wrote:
> >> Hello All,
> >> We are trying to transmit a .bmp file using USRP Tx/Rx. However, I am
> >> getting bogus header data at the receiving end. I tried transmitting
> >> a text file also which clips my starting text and also it inserts
> >> some invalid/unknown characters. We are losing some of the bytes for
> >> e.g, the transmitted file size is of 426316 bytes, but receiving file
> >> size is of 4,264,224 bytes.
> >> Can somebody explain what we are doing wrong here. I have attached my
> >> Tx and Rx .grc and snapshots for the reference.
> >>
> >> Best,
> >> Simran Kaur
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to get precise time tag from blocks_meta_data_sink

[Ben Hilburn]

Hi Ziang -

I'm not sure I completely follow your system set-up, so I'm not sure how to
answer all of your questions, exactly. There are almost certainly a couple
of things at play here, including the source of your time (is it on the
radio? your PC?), and the data representation of the time tag itself.

The `rx_time` field of the file meta sink block uses UHD's tuple
representation for time, with an integer number of full seconds and then a
fractional second component. See more here:
https://github.com/EttusResearch/uhd/blob/master/host/lib/types/time_spec.cpp

So, concatenating them as `full.frac seconds` is correct, but it's
important to keep in mind the limitations of data representation in terms
of the fractional portion. Having 20 digits of "value" in your float
doesn't mean they are significant - you need to be aware of the limitations
and accuracy of your hardware to whatever degree it matters in your
application.

Does that help?

Cheers,
Ben

On Tue, Apr 30, 2019 at 4:13 PM Ziang Gao 
wrote:

> Hi,
>
> I'm trying to use blocks_file_meta_sink to record data with tags, and then
> use gr_read_file_metadata.py to read .hdr file, and I got this output:
> " " "
> HEADER 30
> Version Number: 0
> Sample Rate: 2000.00 sps
> Seconds: 1556652948.179670
> Item size: 8
> Data Type: float (5)
> Complex? True
> Header Length: 171 bytes
> Extra Length:  22
> Extra Header?  True
> Size of Data: 800 bytes
>   100 items
>
> Extra Header:
> rx_freq: 2.4205e+09
> " " "
> It looks like the time in seconds only has 6 floating points, however, it
> supposes to be double.
> I thought it was caused by string formatting so I went to
> parse_file_metadata.py and modified line 94 from "print "Seconds:
> {0:6f}".format(t)" to "print "Seconds: {0:20f}".format(t)", then I got:
> " " "
> Seconds: 1556652948.17966961860656738281
> " " "
> Is this the correct way to solve this problem? Is GNUradio's time tag
> actually precise to nanosecond? I want to use a PC with GPS time module and
> sync a B200mini with it, can I actually get the correct GPS time tag in
> this way?
>
>  Thanks
>
> Best regards,
> Ziang
> ___
> 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] Question on PMT boolean messages

[Ben Hilburn]

Excellent! So glad you got it working, Ali, and thanks for sharing the
solution to your issue!

Cheers,
Ben

On Wed, May 1, 2019 at 3:45 PM Ali Dormiani  wrote:

> I figured this out today. I used a handle_msg and simply connected a
> message strobe to the 'junk' msg input. My custom block works as expected
> now.
>
> On Tue, Apr 30, 2019 at 12:56 PM Ali Dormiani 
> wrote:
>
>> Hello,
>>
>> Thank you for the advice. I went back to the tutorials and now I have a
>> better grasp of what is going on.
>>
>> Regarding 'work' vs 'handle_msg', which situations fit each of these?
>>
>> Is 'handle_msg' supposed to be for passing messages through multiple
>> internal msg ports?
>>
>> Is 'work' for dealing with streams or can I do message related things in
>> 'work'?
>>
>> It appears that handle_msg is for passing from inputs to outputs (which I
>> do not need as I want a block with only a message out).
>>
>>
>> In short, if one wants to make a block with a single msg output and
>> nothing else, should s/he use a message handler (and leave work empty with
>> a pass) or use work? If so, what should work return, given there are no
>> data-streams involved?
>>
>> Thank you for your time,
>>
>> Ali
>>
>> On Mon, Apr 29, 2019 at 2:49 PM Marcus Müller 
>> wrote:
>>
>>> Hi Ali,
>>> causality, our old foe, strikes again!
>>>
>>> You're trying to emit a message in the constructor.  Messages will be
>>> delivered to all message acceptors connected to that message port.
>>> However, you can't possibly connect the block before the block-holding
>>> object exists, i.e. before the constructor returns.
>>>
>>> So, necessarily, the messages are sent before anything is connected to
>>> the msg_out port, and thus into the void and simply get dropped by the
>>> scheduler.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> PS: I'd strongly recommend having a `self.port = pmt.intern('msg_out')`
>>> in the constructor and using that whenever you need the port if you're
>>> doing that within the work() function often. Constructing PMT interns
>>> is relatively expensive.
>>>
>>> On Mon, 2019-04-29 at 14:39 -0700, Ali Dormiani wrote:
>>> > Hello everyone,
>>> >
>>> > I have been attempting to make my own block that sends out a boolean
>>> > message if certain time related conditions are met.
>>> >
>>> > I am unable to figure out why my block does not work. This seems to
>>> > be the line of interest:
>>> >
>>> > self.message_port_pub(pmt.intern('msg_out'), pmt.PMT_T)
>>> >
>>> > This line should cause the block to output a PMT true through port
>>> > msg_out right?
>>> >
>>> > My full block is attached bellow. Any help would be greatly
>>> > appreciated.
>>> >
>>> > Thank you all for your time,
>>> >
>>> > Ali
>>> >
>>> > ==
>>> > import numpy as np
>>> > from gnuradio import gr
>>> > import pmt
>>> > import datetime
>>> >
>>> > class msg_block(gr.basic_block):  # other base classes are
>>> > basic_block, decim_block, interp_block
>>> > """This block checks time and sends true or false if capture
>>> > period is desired"""
>>> >
>>> > def __init__(self, minutes=15, seconds=10):  # only default
>>> > arguments here
>>> > """arguments to this function show up as parameters in GRC"""
>>> > gr.basic_block.__init__(
>>> > self,
>>> > name='Time Enable',   # will show up in GRC
>>> > in_sig=None,
>>> > out_sig=None
>>> > )
>>> > self.message_port_register_out(pmt.intern('msg_out'))
>>> > now = datetime.datetime.now()
>>> > #P_true = pmt.PMT_T
>>> > #P_false = pmt.PMT_F
>>> > if ((now.minute % minutes) == 0): #check if minute is ok
>>> > if (now.second < seconds): #check if capture period is ok
>>> > self.message_port_pub(pmt.intern('msg_out'),
>>> > pmt.PMT_T)
>>> > else:
>>> > self.message_port_pub(pmt.intern('msg_out'),
>>> > pmt.PMT_F)
>>> > else:
>>> > self.message_port_pub(pmt.intern('msg_out'), pmt.PMT_F)
>>> >
>>> > def work(self, input_items, output_items):
>>> > pass
>>> > =
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > Discuss-gnuradio@gnu.org
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FEC Examples with Modulators

[Ben Hilburn]

Hi Alex -

Have you tried any of the examples in gr-fec/examples? If so and they
didn't work for you, what issues have you encountered?

Cheers,
Ben

On Sat, May 4, 2019 at 9:20 PM Alex Roberts  wrote:

> Hello GNURadio Users,
>
> I'm learning about convolutional encoders in school and would like to
> demonstrate their use in gnuradio for a presentation. The examples
> appear useful for showing BER and Encoding -> decodng, but I'm
> struggling to implement a signal chain
>
> tx_bytes --> unpacked to packed -> FEC_ENCODE -> modulation -> AWGN
> channel -> demod -> FEC_DECODE -> received_bytes
>
> I'm not sure where to put the fec_decode on receiver side or how the
> bytes need to packed to use it. Are there some tutorials or examples
> that FEC with tx to rx (either w/ hardware or loopback)?
>
> Thanks
> Alex.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Software Defined Radio Academy: Programme is ready

[Ben Hilburn]

That's quite the program, Markus! I can't make the event, but I'm really
looking forward to the recordings!

Cheers,
Ben

On Thu, May 2, 2019 at 6:58 PM Markus Heller  wrote:

> Dear community,
>
> please see our programme web site.
>
> The programme of the Software Defined Radio Academy 2019 on June 22 in
> Friedrichshafen is ready:
>
> http://2019.sdra.io/pages/programme.html
>
> Please note that we are looking forward to a distinguished talk from
> Nobel Price winner and radio astronomer Prof. Dr. Joe H. Taylor K1JT
> around 1300 hrs. Title yet to be announced.
>
> Besides that, this year's SDRA has a focus on space-related topics. We
> will be enthusiastic to listen to talks from Alex Csete OZ9AEC and his
> colleagues Sheila Christiansen, Manolis Surligas SV9SFC, Pierros
> Papadeas, on SDR Makerspace, Mario Lorenz DL5MLO from AMSAT on the new
> geo-stationary QC-100 Amateur Radio satellite and Carles Fernandez on
> Open Source GNSS systems.
>
> We will also listen to talks about the Charly25 RedPitaya based
> transceiver, and on latest developments from FLEXRADIO.
>
> And we'll listen to Christoph Mayer DL1CH on KiwiSDR as a new GNURadio
> source, and Prof. Dr. Michael Hartje DK5HH on how to measure the
> development of background noise levels in Germany.
>
> Since we're celebrating our SDRA's fifth anniversary this year, we'll
> have a short key note by the President of the German Amateur Radio Club
> DARC, Christian Entsfellner DL3MBG.
>
>
> We will inform you on this list a couple of days before about recent
> developments and how to join us through our Youtube live stream. As in
> past years, all talks will be recorded and made available on our
> channel: http://youtube.sdra.io
>
> Please feel invited to attend in person or online. If you have
> questions, please feel free to ask. Please feel free to share our
> programme.
>
> BR / vy73
> Markus
> DL8RDS
>
>
> ___
> 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] New/Updated GPredict Interfacing Blocks

[Ben Hilburn]

Congrats on the awesome work, Mike! This is really cool. The auto trigger &
close for file recordings is a nice touch.

You know this could be part of a pretty awesome GRCon talk ;)

Cheers,
Ben





On Mon, May 6, 2019 at 9:17 PM GhostOp14  wrote:

> Hi everyone,
>
> I've been doing a good bit of satellite work and had the need to blow the
> dust off of a discontinued gr-gpredict-doppler  OOT module and enhance it.
> The goal was to have a state value to pass in and key off of gpredict's
> perspective of if the satellite was visible or not for recording purposes
> (better yet preventing huge blind-saving files), and to better pass the
> doppler frequency through to GNURadio.  So I've forked it (
> https://github.com/ghostop14/gr-gpredict-doppler.git)  and added a bunch
> of new features:
>
> doppler block:
>   -  Now adds freq output block to make it compatible with other message
> blocks like the USRP source
> - Now supports AOS / LOS commands from gpredict - a state output message
> block compatible with all of the state inputs in the gr-filerepeater block
> is also produced.  Result: A file record can be triggered to start when a
> satellite is in range, then automatically closed when it goes out of range.
>  -  Enhanced the gqrx / gpredict radio control command handling to handle
> additional messages and correctly handle exit
>
> [new] rotor block:
>   - Accepts inputs from  rotctl / gpredict's rotor control.
>   - Az/El are passed in, interpreted, and packed in an output message with
> 'az' and 'el' meta keys
>   - A basic minimum elevation is added to the block where if the elevation
> is > min, an optional state output is produced (1= >= min, 0 is below
> min).  Again this can be used with the gr-filerepeater adv sink
>
> [new] az el limit block:
>   - Allows az/el min/max values to be set.  If the rotor block output
> az_el is fed into this block, an output state message is produced for
> "inside the az/el limits" / outside the az/el limits.  Again, this can
> interface with the file blocks
>
> gr-filerepeater (https://github.com/ghostop14/gr-filerepeater.git) has
> also gotten a lot of enhancements to help with controlling unsupervised
> file writes.  The concept of this state 1/0 has worked its way through for
> easy file write control.  The file sink can also now extract/save
> message-based data in exactly the same way streaming data was handled.
>
> Anyway let me know if there's any other enhancement requests or if you run
> into any new issues.
>
> Enjoy!
>
> ___
> 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] libvolk NEON support progress update

[Ben Hilburn]

This really is great work, Albin! Thanks so much for sharing your work and
keeping the community posted on your progress!

And wow, the speedup on the rotator is impressive. I'm really looking
forward to your work getting upstreamed =)

Cheers,
Ben

On Tue, May 7, 2019 at 12:50 PM Martin Braun  wrote:

> Very cool! Looking forward to your PR!
>
> On Tue, May 7, 2019 at 7:04 AM Albin Stigö  wrote:
>
>> Hi,
>>
>> Just a quick progress update. I have completed NEON support for 34 out
>> of 74 libvolk kernels that were missing NEON implementations.
>>
>> Average speedup is around 4x depending on kernel, not very surprising
>> since NEON SIMD vector size for float32 is 4...
>>
>> Biggest surprise was volk_32fc_s32fc_x2_rotator_32fc that now is 14x
>> faster on Raspberry Pi 3b. This is nice because this kernel is used in
>> the frequently used (pun intended) Frequency Xlating FIR Filter.
>>
>> https://github.com/gnuradio/volk/issues/243
>>
>> So far kernels are only available in my (messy) branch but I will
>> gradually create pull requests into libvolk.
>>
>>
>> --Albin
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC19] Accepted student projects announced!

[Ben Hilburn]

Congratulations, Arpit and Bowen! I look forward to tracking your
development this Summer and working with you in the community!

Cheers,
Ben

On Tue, May 7, 2019 at 2:27 PM Wunsch, Felix (CEL) 
wrote:

> Hi all,
>
>
> Google has announced the accepted student projects for GSoC 2019: Arpit
> Gupta and Bowen Hu will be contributing to GNU Radio during the summer
> - congratulations to both of them! Arpit will work on a tool for parsing
> GNU Radio header files to create YAML descriptions that can be used for
> GRC. His mentors are Nicolas Cuervo and Sebastian Koslowski. Marcus Müller
> will support Bowen who will work on cycle-accurate simulation of Verilog
> code.
>
>
> Both are exciting projects that will bring new functionality to GNU Radio.
> Bowen and Arpit will keep you up-to-date about their progress in weekly
> blog posts. Expect the first posts later this week. Please welcome them in
> the community and give them feedback!
>
>
> Arpit and Bowen, we are really happy to work with you and we are looking
> forward to seeing your contributions!
>
>
> To all students who unfortunately could not be selected: Thank you for
> applying to GNU Radio and please try again next year! :)
>
>
> Cheers,
> Felix
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRCon19 Registration Open

[Ben Hilburn]

Hi all -

This is a reminder that registration for the 9th Annual GNU Radio
Conference is open! You can purchase your registration here:

https://tickets.gnuradio.org/grcon19/

Student pricing is also available through the same registration link. Note
that we are still in the discounted registration period, which ends on May
1st.

The conference is being held at the Huntsville Marriott at the Space &
Rocket Center in Huntsville, Alabama, from September 16th - September 20th.
More info about the conference can be found on the homepage, here: GRCon19
.

*Submissions*
The deadline for submissions is July 1st. As in previous years, there are
three types of submissions:

   - Talks: Presented during the conference program.
   - Poster: Presented during the several poster sessions.
   - Paper: Published in the GRCon Technical Proceedings
   

Please remember that you do *not* need to present in order to publish, nor
do you need to publish in order to present. We do encourage you to do both,
but do not require it.

To make a submission, please use the following portal. Authors will be
notified of acceptance in early July. Peer reviews of talks and papers are
conducted using a double-blind process. If you submit a paper draft and are
accepted, the camera-ready date will be in late August.

https://openconf.org/GRCon19/openconf.php

*Sponsors*
GRCon is only possible every year thanks to our sponsors! Importantly,
remaining funds from the conference are put back into the project, directly
funding the efforts of the GNU Radio community. If you are interested in
learning more about sponsoring, please reach out to the organizing
committee: gr...@gnuradio.org

*See you in Rocket City!*
If you have any questions, please don't hesitate to get in touch with the
conferencing organizers, whom you can reach using gr...@gnuradio.org.

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

[Discuss-gnuradio] RF Hackathon at Allen Telescope Array

[Ben Hilburn]

Hi all -

The Berkeley SETI Institute and Breakthrough Listen are hosting a hackathon
at the Allen Telescope Array the week of May 13th, and would like to invite
members of the GNU Radio community who wish to participate to attend the
event. You can read more about the objectives and topics, as well as a high
level agenda, on their sign-up form, here:

https://goo.gl/forms/YMRWxQrxBQFNSFA72

Space is very limited at the facility, so please **only** register for the
event if you truly intend to be there. Claiming a spot you don't intend to
use might preclude someone else from attending.

Please feel free to share the link with anyone you think might be
interested! If you have any questions, let me know, and I can't answer
them, I'll connect you to the SETI team.

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

Re: [Discuss-gnuradio] OOT modules on Android

[Ben Hilburn]

Hey Laura -

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

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

Cheers,
Ben

On Tue, Mar 26, 2019 at 1:21 AM Laura Arjona  wrote:

> Thank you very much Ben,
>
> The OOT blocks that I want to run in Android are written in C++ entirely.
> My question is related to your comment "as long as they are built
> appropriately".
> That is, if it is possible to build OOT blocks to use in Android. But
> reading your message, I assume that is possible.
>
> I knew the link, thanks, but haven't started the android project yet,
> staring this week. Excited to start my project.
>
> Thanks
>
>
>
>
>
>
>
> On Mon, Mar 25, 2019 at 11:11 AM Ben Hilburn 
> wrote:
>
>> Hi Laura -
>>
>> Sorry for the delayed response, here.
>>
>> So, I'm not entirely sure I understand your question, actually. Once GNU
>> Radio is running in Android, using blocks from any module, in- or
>> out-of-tree, shouldn't be a problem as long as they are built
>> appropriately. Are you asking if you need to re-write Python-only blocks in
>> C++? If the OOTM only provides Python blocks, then yes, you'll want to put
>> those into C++ for use on Android.
>>
>> Also, I assume you've already seen the pages linked here, which provide a
>> lot more detail on that build process -- although the information is pretty
>> severely dated at this point, and almost certainly won't work as-is.
>>
>> https://wiki.gnuradio.org/index.php/Android
>>
>> Cheers,
>> Ben
>>
>> On Fri, Mar 22, 2019 at 12:36 PM Laura Arjona  wrote:
>>
>>> I might have been thinking about this in the wrong way.
>>>
>>> The way to proceed would be to re-write the blocks in Android studio,
>>> using C++?
>>> (instead of importing the blocks created with gr-modtool)
>>>
>>>
>>> Thank you and good weeked!
>>>
>>> On Thu, Mar 21, 2019 at 7:44 PM Laura Arjona  wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I want to build an Android App to communicate with an USRP B200-mini,
>>>> and this app should use one OOT module with several oot blocks.
>>>>
>>>> How should I proceed to import my OOT module?
>>>>
>>>> Thank you
>>>>
>>>>
>>>
>>> --
>>> *Laura Arjona *
>>> Washington Research Foundation Innovation Postdoctoral Fellow in
>>> Neuroengineering
>>>
>>> *Paul G. Allen School of Computer Science & Engineering*
>>> 185 E Stevens Way NE
>>> University of Washington
>>> Seattle, WA 98195-2350
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>
> --
> *Laura Arjona *
> Washington Research Foundation Innovation Postdoctoral Fellow in
> Neuroengineering
>
> *Paul G. Allen School of Computer Science & Engineering*
> 185 E Stevens Way NE
> University of Washington
> Seattle, WA 98195-2350
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT modules on Android

[Ben Hilburn]

Hi Laura -

Sorry for the delayed response, here.

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

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

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

Cheers,
Ben

On Fri, Mar 22, 2019 at 12:36 PM Laura Arjona  wrote:

> I might have been thinking about this in the wrong way.
>
> The way to proceed would be to re-write the blocks in Android studio,
> using C++?
> (instead of importing the blocks created with gr-modtool)
>
>
> Thank you and good weeked!
>
> On Thu, Mar 21, 2019 at 7:44 PM Laura Arjona  wrote:
>
>> Hi everyone,
>>
>> I want to build an Android App to communicate with an USRP B200-mini,
>> and this app should use one OOT module with several oot blocks.
>>
>> How should I proceed to import my OOT module?
>>
>> Thank you
>>
>>
>
> --
> *Laura Arjona *
> Washington Research Foundation Innovation Postdoctoral Fellow in
> Neuroengineering
>
> *Paul G. Allen School of Computer Science & Engineering*
> 185 E Stevens Way NE
> University of Washington
> Seattle, WA 98195-2350
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Libvolk license compatability

[Ben Hilburn]

Hi Albin -

That is correct. You may use MIT-licensed code in a GPL library, as long as
you obey the NOTICES requirement of the MIT code.

Please let us know if you have any further questions!

Cheers,
Ben

On Fri, Dec 21, 2018 at 11:30 AM Albin Stigö  wrote:

> There is the MIT neon-math library which includes a lot of the functions
> missing NEON versions in volk. My understanding of GPL v3 and MIT is that
> it's ok to include MIT code in GPL code as long as you retain the license
> text?
>
> https://code.google.com/archive/p/math-neon/
>
>
> --Albin
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Interest Check: GNU Radio Symposium hosted in the UK

[Ben Hilburn]

Hi all -

*Survey Link: *https://goo.gl/forms/Plifla0fYgSdxzQe2

We just concluded the 8th annual GNU Radio Conference, which was once again
a great success. Thanks so much to everyone that helped put the event
together and attended!

For the past few years, interest in GNU Radio events outside of the United
States has grown. Starting in 2018, the first "European GNU Radio Days"
(previously named "French GNU Radio Days") was held in Lyon, France. The
second, in July of 2019, has already been announced (
https://gnuradio-fr-19.sciencesconf.org/).

The purpose of this survey is to gauge interest in a GNU Radio conference
event hosted in the UK, with a working name of the "GNU Radio Symposium".

Note that just as the "European GNU Radio Days" event is *in addition* to
the annual GNU Radio Conference event held in the USA, the "GNU Radio
Symposium" would also be in addition to an annual event held in the USA.
Thus, given enough interest, there will be three annual GNU Radio events.

If you're interested in e-mail updates about this event, you can provide
your e-mail address in the last question. Otherwise, the gnuradio-discuss
mailing list, the @gnuradio Twitter account (https://twitter.com/gnuradio),
and the website (https://www.gnuradio.org/) are the best ways to stay
up-to-date.

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

Re: [Discuss-gnuradio] [GSoC18] Student projects announced!

[Ben Hilburn]

Congratulations, Swapnil and Luca! I'm really excited about your topics,
and look forward to seeing your work over the Summer.

Good luck, have fun, and happy hacking =)

Cheers,
Ben

On Tue, Apr 24, 2018 at 7:43 AM, Nicolas Cuervo 
wrote:

> Hi all!
>
> congratulations to Luca and Swapnil for being accepted for this year's
> GSoC! Both had very good proposals but also have been active in the
> community which is fantastic.
>
> I am very excited to be part of the mentors this year. I'm looking forward
> working with Swapnil on this project :)
>
> All in all, thanks to all the other candidates that didn't make it this
> year into GSoC. But if you are reading, we do thank your interest and hope
> to see you around next year or, even better, to see that you are interested
> in contributing to the project along the way!
>
> Cheers!
> - Nicolas
>
>
>
>
>
>
> On Tue, Apr 24, 2018 at 12:41 PM, Moritz Luca Schmid <
> luca.moritz.sch...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> I am really excited to work on a great GSoC project, again with GNU
>> Radio, in the upcoming summer and I hope that
>> my work will be a nice extension to the GNU Radio project.
>>
>> Thanks in advance to Marcus Müller and Felix Wunsch for mentoring me
>> during GSoC.
>> I am really looking forward to communicate and shape this project with
>> you.
>>
>> Also, congratulations to Swapnil for the selection in GSoC! I wish you
>> all the best for your respective tasks.
>>
>> As Felix mentioned, I am going to keep you all up to date by weekly posts
>> about the current state of my project.
>> Therefore, I am going to launch a blog in the next few days.
>>
>> Best
>> Luca
>>
>>
>> On 23.04.2018 19:26, Felix Wunsch wrote:
>>
>>> Hi all,
>>>
>>> an hour ago, Google has announced the accepted students for this year's
>>> Google Summer of Code and we are happy to have two of them working on
>>> GNU Radio! Swapnil Negi will improve gr-modtool, and Luca Schmid, who
>>> some of you surely know from last year's GSoC or GRCon17, will bring
>>> basic MIMO functionality to GNU Radio.
>>>
>>> Both of them will provide weekly updates on their progress, so please
>>> support them by welcoming them in the community and contributing to
>>> discussions about their projects!
>>>
>>> Swapnil and Luca, I'm really excited to work with you and looking
>>> forward to the improvements you will bring to GNU Radio!
>>>
>>> Cheers,
>>> Felix
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio : GPL use cases

[Ben Hilburn]

Hi Fabian -

Sorry I didn't see your question a couple of days ago! Martin's response is
good. If you are not conveying GPL software outside of your company, then
you have no obligations and can do what you wish. If you are conveying a
product with GPL software to customers, then you are obligated to provide
your customer the source to the GPL software in that product.

If you have further general questions, I'm happy to answer them.
Realistically, though, as Martin said, copyright law is different in every
country, and I have no familiarity with the French system. If you are
building a product with GPL'd software and have questions, we recommend
that you consult an IP attorney familiar with the copyright law in your
country.

I hope that helps!

Cheers,
Ben

On Wed, Apr 4, 2018 at 5:32 PM, Martin Braun  wrote:

> On 04/03/2018 06:15 AM, MARCHAND Fabien wrote:
> > In a professionnal context, I want to use GNURadio in 2 cases :
> >
> > -  Work bench : for internally use in a internally developed
> > software, to test some hardware for example.
> >
> > -  Embedded : I think about having GNURadio embedded in hardware
> > which will be sold to customers, and be called by the same software
> > developed internally
> >
> >
> >
> > In those 2 cases, I have a doubt concerning the license. Does it force
> > us to distribute our software code in none/one/all of those cases ?
>
> Fabien,
>
> I'm not a lawyer, and you can't use the mailing list for binding legal
> advice, especially across jurisdictions (France might be different from
> the USA, for example). However, there's some comparisons that can be
> drawn to other commercial entities using GNU Radio:
>
> - If you're using GNU Radio internally on your work benches, you can do
> whatever you want (i.e., if no code or binaries leave your company).
>
> - As for your embedded devices, there are many embedded devices that
> have GPL'd software (like, most routers and many TV set top boxes), and
> the legalities over those have been pretty much hashed out. You can look
> up some of the rulings and see if they apply to you.
>   One thing to keep in mind is that if you write software that links
> against GNU Radio, your software is itself GPL. That doesn't mean your
> customer's software has to be GPL, e.g., if it calls into your
> application through some network interface. Of course, you will need to
> provide source codes for all GPL components (this is not a GNU Radio
> specific thing) upon request to anyone who is buying your embedded device.
>
> Like I said, GPL software usage is well understood, and all those rules
> apply to GNU Radio as well. I would encourage you to look around for
> other GPL-related license interpretations.
>
> -- Martin
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 21 Feb 2018 Signals Challenge is Live

[Ben Hilburn]

Hi all -

We have introduced new prizes for the signals challenge, the first hint has
been posted, and we have one winner so far! Check out the blog post for
details on the updates:

https://www.gnuradio.org/blog/gnu-radio-challenge-21-feb-2018/

And thanks to everyone that is spreading the word, including rtl-sdr.com
<https://www.rtl-sdr.com/gnu-radio-signals-challenge-now-live/> and those
of you that have shared it in other forums! It's great to see so much
excitement and engagement, and we hope everyone participating is having fun!

Cheers,
Ben

On Wed, Feb 21, 2018 at 2:05 PM, Ben Hilburn <bhilb...@gnuradio.org> wrote:

> Thanks to Nate Temple's hard work last night, we have a new signals
> challenge live today! No hardware is needed, and one of the signals should
> be accessible to novice signals hackers.
>
> Have fun!
>
> https://www.gnuradio.org/blog/gnu-radio-challenge-21-feb-2018/
>
> Cheers,
> Ben
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 21 Feb 2018 Signals Challenge is Live

[Ben Hilburn]

Thanks to Nate Temple's hard work last night, we have a new signals
challenge live today! No hardware is needed, and one of the signals should
be accessible to novice signals hackers.

Have fun!

https://www.gnuradio.org/blog/gnu-radio-challenge-21-feb-2018/

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

Re: [Discuss-gnuradio] Project Call February this Thursday!

[Ben Hilburn]

Hi all -

Just a reminder that our monthly project call is today!

Cheers,
Ben

On Mon, Feb 12, 2018 at 7:22 PM, Martin Braun  wrote:

> Sorry, forgot the most important info. It's at 10 AM Pacific / 1 PM
> Eastern / 19:00 CET.
>
> -- M
>
> On 02/12/2018 12:04 PM, Michael Dickens wrote:
> > Hi Martin - Some good news there in the agenda; I'm looking forward to
> hearing more!
> >
> > Is this event starting at 1 PM / US / Eastern, which would be 10 AM / US
> / Pacific? Or is it 2 / 11? I still get them confused ...
> >
> > Cheers! - MLD
> >
> > On Mon, Feb 12, 2018, at 1:34 PM, Martin Braun wrote:
> >> this Thursday, we'll have our usual monthly project call. We have a lot
> >> to talk about, such as the leadership change, and Google Summer of Code.
> >>
> >> We'll be collecting agenda items here:
> >> https://wiki.gnuradio.org/index.php/Call20180215
> >>
> >> I'll post the link to call in or just listen here, and on IRC+Slack.
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Missed Connection at Port Discovery

[Ben Hilburn]

Someone here saw me wearing my GRCon17 hoodie at Port Discovery in
Baltimore on Saturday and tried to grab me to chat. I was in the middle of
chasing kids around, though, and we didn't really get a chance to talk. You
said you had just gotten your hands on a bunch of USRPs and were really
excited to start using them.

Please shoot me an e-mail! I'm always interested to hear about your awesome
GNU Radio projects!

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

Re: [Discuss-gnuradio] Introducing the GREP process

[Ben Hilburn]

I'm really excited about this - openness and inclusivity are key to
open-source development, and I'm really excited to see this get rolling.

Thanks, Martin and Marcus, for drafting GREP-0 and getting it live!

Cheers,
Ben

On Mon, Feb 5, 2018 at 6:42 AM, Martin Braun  wrote:

> Hi all,
>
> in order to facilitate the development of GNU Radio, we will be
> launching something new for GNU Radio: The GREP process. You may have
> guessed it... GREP stands for "GNU Radio Enhancement Proposal".
>
> If you want to take a look at what we've published so far, go here:
>
> https://github.com/gnuradio/greps/blob/master/grep--greps.md
>
> ...but I'll be going a bit into the motivation in the following. You
> might want to read this first.
>
> Other projects have done this for a while now; most famously, the Python
> project has the PEP process, from which we took heavy inspiration for
> the GREP process.
>
> ## What is this good for?
>
> For GNU Radio feature development, we currently lack a way of planning
> new features before any kind of development starts. For small things,
> such as adding a specific API call to a block, people can simply submit
> a "Feature Request" on github. However, there's no path forward, other
> than hoping that someone will pick up the work and implement it, there's
> no way of knowing what's happening with a feature request.
>
> It's much worse for big changes. Any maintainers second largest fear
> (after the fear of no one contributing) is the fear that someone submits
> a many-thousand line pull request out of the blue. Worst case scenario
> is when the maintainer needs to reject the pull request, and some
> enthusiastic developer just wasted weeks or months of work.
>
> For big feature development, we need a way to plan development and
> coordinate it between contributors, maintainers, and lead developers.
> This is the first big reason to introduce GREPs: They are a platform for
> discussing feature development, publicly, ahead of time.
>
> GREPs are so much more, though. They give us a tool to codify things
> such as coding guidelines, but with a clear way of putting them up for
> discussion. And they don't have to be technical; enhancement proposals
> to the GNU Radio organization itself can also become GREPs. We
> distinguish between GREPs that are technical enhancements,
> organizational changes, and informational documents.
>
> ## How does this affect me?
>
> As you can imagine, we GNU Radio developers discuss things among each
> other all the time. But do you know what we're talking about? Probably
> not. We don't even use electronic media all the time, because many of us
> know each other personally, and we can just chat face to face. That's
> nice sometimes, but it's not transparent. GREPs are designed to change
> that: Major technical or other discussions can now be publicly viewed,
> and participation is highly encouraged. Say Marcus and Andrej are
> planning changes to the testing system, they can write it up and post it
> on github. If you're a user that happens to be affected by the changes,
> you can go ahead and participate in the discussion before changes take
> effect, and use that opportunity to contribute to the code base in a way
> that is beneficial for you or your organization.
>
> Even if you're not affected, you might be interested to see where the
> project is going. As major changes shall become GREPs before they become
> code, you can extrapolate future development and plan accordingly.
>
> In other cases, we will submit GREPs that explain the way we do things,
> such as coding guidelines. Having such documents in one place (i.e., the
> GREP repository) will make it easier for you to understand rules and
> conventions used in the project.
>
>
> ## How do GREPs work?
>
> GREPs are numbered, and GREP 0 is the GREP that explains the GREP
> process itself, so I encourage you to go ahead and read it. In a
> nutshell, suggestions are written down in a markdown document, and a
> pull request is made to the GREP repository. Merging the pull request
> means that the GREP meets formal criteria and is now open for
> discussion (it does *not* mean the GREP is accepted for implementation).
>
> Find GREP 0 here:
>
> https://github.com/gnuradio/greps/blob/master/grep--greps.md
>
>
> ## I have suggestions for improving the GREP process, now what?
>
> That's fine -- in fact, it's built into the GREP process itself. Truth
> be told, we are assuming that we'll need to tweak and polish the process
> for a while until we get into its final form (or maybe it'll never reach
> a final form, as requirements keep changing).
> So go ahead and submit issues on the GREP issue tracker, and we'll have
> a discussion about them.
> Ultimately, it'll be up to core GNU Radio devs to decide whether or not
> we accept your suggestions for change, but since we don't know what the
> perfect GREP process looks like yet, we're very interested to hear any
> kind of 

[Discuss-gnuradio] GNU Radio Project Leadership Updates

[Ben Hilburn]

Hi all!

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

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

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

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

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

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

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

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

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

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

[Discuss-gnuradio] Software Design Engineer Opening at DeepSig

[Ben Hilburn]

Hi all!

I'm sending this e-mail wearing a different hat than I normally do when
sending messages to the list.

We are hiring at DeepSig, and we're (obviously) very interested in people
with GNU Radio experience. If you're in the market for a software
engineering position, check out the below description and get in touch!

Cheers,
Ben


/*
 * Job Posting: Software Design Engineer
 *
 * Keywords: C/C++, Python, Linux, Embedded, Open-Source, Software Radio,
Machine Learning
 * Type: Full-Time (W2) On-Site
 * Location: Arlington, VA
 */

/*
 * About the Position
 */
DeepSig Inc. is looking for a full-time software developer to join our R
team in Arlington, Virginia, for an immediate opening. The primary
responsibility of this position is contributing to the design and
implementation of DeepSig’s software products, which are principally
written with C/C++ and Python using common Linux-based open-source tools &
workflows. Important aspects of this role include writing clean &
maintainable code, designing user-friendly interfaces, creating great
documentation, and architecting a robust & re-usable software
infrastructure. Our products commonly interface with software-defined radio
hardware and are built around our machine learning algorithms, so
experience (or an interest) in working close to hardware, embedded systems,
and/or with machine learning is valuable.

Previous experience working with open-source projects & communities is a
big plus. Candidates should be able to communicate clearly, both internal
and external to the company, be self-driven, and know when to ask for help!
We hire engineers that empathize with the users of their code, develop good
relationships with customers, and love to learn.

Travel expectations are light, mostly consisting of conferences and
occasional customer visits. Candidates must be authorized to work in the
United States by US citizenship or permanent residency. This position is
located on-site with our engineering team in Arlington, Virginia. We are
not currently able to sponsor visa applications or support remote hires.

/*
 * Engineering at DeepSig
 */
DeepSig is growing its technical team while cultivating a collaborative,
agile, and fun small-team culture. We value creativity, knowledge sharing,
and employee growth, and we encourage participation in scientific
publications, conferences, and open-source software. We strive to offer
competitive salaries, compelling benefits (including health, dental,
retirement, and equity), a welcoming environment, a flexible schedule, and
a great work / life balance.

/*
 * About Us
 */
DeepSig is a venture-backed startup focused on wireless communications and
machine learning. We are creating software products and algorithms for the
commercial telecommunications market that enable the first generation of
true machine learning-based communications and sensing systems. More
information can be found on our website:  https://www.deepsig.io/.

/*
 * How to Apply
 */
Send an e-mail to j...@deepsig.io with your résumé / CV. Cover letters are
encouraged, but not required. You may also use this e-mail address for
questions about the position.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Boost 1.66.0 Compatibility: GNU Radio & Volk & UHD

[Ben Hilburn]

Thanks so much for the test & report, Mike!

How are you dealing with this on the packaging side for macOS?

Cheers,
Ben

On Mon, Jan 1, 2018 at 11:41 AM, Michael Dickens 
wrote:

> In initial testing, Boost 1.66.0 is fully compatible with the current GNU
> Radio and Volk GIT master & current releases. There's an issue with UHD
> that has already been fixed in the GIT master, but the new boost otherwise
> seems to work with UHD & the backport to the latest release is very
> straight forward. Cheers! - MLD
>
> ___
> 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] GRCON2017

[Ben Hilburn]

Hey all -

Ron is exactly right. I meant to post the link to the slidedecks, which are
now live.

We are still waiting on the videos, which will get posted to YouTube once
we receive them - I'll make another announcement, then. Sorry about the
copy / paste mixup on the URLs.

Cheers,
Ben

On Tue, Sep 19, 2017 at 5:29 PM, Ron Economos <w...@comcast.net> wrote:

> I think Ben meant to post this link, which are the presentation slides.
>
> https://www.gnuradio.org/grcon-2017/program/grcon17-presentations/
>
> I expect the presentation videos will take a little while to edit and
> publish.
>
> Ron
> On 09/19/2017 09:50 AM, Kevin Reid wrote:
>
> On Mon, Sep 18, 2017 at 7:01 PM, Ben Hilburn <bhilb...@gnuradio.org>
> wrote:
>
>> Presentations are now live: https://www.youtube.com/
>> channel/UCceoapZVEDCQ4s8y16M7Fng
>>
>> There are some missing, but we'll get them up as soon as we get them.
>> Same with the talk recordings, which will get posted to our YouTube channel.
>>
>
> There doesn't seem to be anything newer than 9 months other than the
> project calls. Are you sure the videos are public?
>
>
>
> ___
> 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] GRCON2017

[Ben Hilburn]

Presentations are now live:
https://www.youtube.com/channel/UCceoapZVEDCQ4s8y16M7Fng

There are some missing, but we'll get them up as soon as we get them. Same
with the talk recordings, which will get posted to our YouTube channel.

Cheers,
Ben

On Mon, Sep 18, 2017 at 12:52 PM, Ben Hilburn <bhilb...@gnuradio.org> wrote:

> I'm working on it! They'll all be up shortly =)
>
> Cheers,
> Ben
>
> On Sat, Sep 16, 2017 at 5:29 PM, Ian Buckley <i...@ionconcepts.com> wrote:
>
>> I may have missed this being announced whilst in San Diego, but is there
>> an online location where all the slides and presentations got uploaded to
>> yet?
>> ___
>> 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] GRCON2017

[Ben Hilburn]

I'm working on it! They'll all be up shortly =)

Cheers,
Ben

On Sat, Sep 16, 2017 at 5:29 PM, Ian Buckley  wrote:

> I may have missed this being announced whilst in San Diego, but is there
> an online location where all the slides and presentations got uploaded to
> yet?
> ___
> 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] [GRCon17] Room Block Update

[Ben Hilburn]

Oops, should have read the *11th* of August (tomorrow).

Thanks, Marcus, for pointing out my typo!

Cheers,
Ben

On Aug 10, 2017 11:40, "Ben Hilburn" <bhilb...@gnuradio.org> wrote:

> Hi all -
>
> This is a heads-up that our negotiated room rate (which matches the US
> Federal Government's per-diem rate for San Diego) and room block is no
> longer guaranteed by the hotel as of EOB this Friday, the 10th of August.
> If you haven't yet booked your rooms for GRCon, please do so soon!
>
> bahiahotel.com/groups/GRCon17/
>
> Cheers,
> The GRCon Organizing Committee
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GRCon17] Room Block Update

[Ben Hilburn]

Hi all -

This is a heads-up that our negotiated room rate (which matches the US
Federal Government's per-diem rate for San Diego) and room block is no
longer guaranteed by the hotel as of EOB this Friday, the 10th of August.
If you haven't yet booked your rooms for GRCon, please do so soon!

bahiahotel.com/groups/GRCon17/

Cheers,
The GRCon Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GRCon17] Conference Update

[Ben Hilburn]

Hi all!

GRCon17 is just six weeks away, and we are busy getting ready for the
conference.

*Conference Program*
The program is now live on the website! You can find it in PDF and PNG
formats, here: https://www.gnuradio.org/grcon-2017/program/

We are still working on getting it loaded into the website in HTML, as we
had last year.

*Technical Proceedings*
Peer reviews of this year's paper submissions completed last week, and
accept / reject notifications have gone out for the Technical Proceedings
of GRCon17! We are pleased to announce that 17 papers were accepted into
this year's TP. Once final drafts are submitted in early September, you
will be able to find them at pubs.gnuradio.org.

*Registration*
Registrations are ramping up quickly, and we are on-track for another year
of strong growth. If you don't have tickets or haven't booked your rooms,
yet, grab them here:

Registration: grcon17.eventbrite.com
Book rooms at the GRCon17 Conference Hotel: bahiahotel.com/groups/GRCon17/

*Sponsors*
We are also excited to announce new sponsors since our last update!

*Lime Microsystems - Diamond*
Lime Microsystems is the world’s leading designer and manufacturer of field
programmable RF transceivers. The company’s software configurable chips can
run any mobile standard and any mobile frequency and have been used in a
vast array of systems including mobile base stations and small cells, SDR
platforms, indoor navigation and machine-to-machine communication systems.
Further information is available at www.limemicro.com.

*Analog Devices - Platinum*
Analog Devices (NASDAQ: ADI) is the leading global high-performance analog
technology company dedicated to solving the toughest engineering
challenges. We enable our customers to interpret the world around us by
intelligently bridging the physical and digital with unmatched technologies
that sense, measure, power, connect and interpret. Visit
http://www.analog.com

*Leonardo DRS - Silver*
Leonardo DRS is a leading provider of high-performance software-definable
radios designed with an unsurpassed ability to detect very weak signals in
dense and noisy signal environments. DRS is a strong supporter of, and
active participant in, the SDR communities and is focused on developing SDR
software that runs in open source frameworks such as GNU Radio.  In
addition to SDRs, DRS designs HF through SHF tuners, receivers,
transceivers and data recorders that are driven by cutting-edge mechanical
packaging that yields the best in size, weight and power reductions.

*Questions*
Just get in touch with us at gr...@gnuradio.org!

Cheers,
The GRCon17 Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Issues Posting to List

[Ben Hilburn]

Hi all -

Over the past few days, we have had a number of reports of issues posting
to the list. We aren't certain what the problem is, and it's possible we
will need to reach out to the FSF Mailman admins to look into it.

I just sent an e-mail to everyone who has reported issues posting. If you
have experienced problems, please respond to this thread, on-list. If you
experience an issue, or your message isn't posted / bounces, please record
the error and send it to:

jcor...@gnuradio.org
bhilb...@gnuradio.org
mbr...@gnuradio.org
marcus.muel...@ettus.com

Thanks!

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

[Discuss-gnuradio] June 2017 Project Call

[Ben Hilburn]

Hey all -

This is just a reminder that our monthly project call is today at 1700 GMT
(1300 EDT)!

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



http://gnuradio.org/events/


You can also participate by joining #gnuradio in IRC / Slack. If you have
to miss it, don't forget you can always read the posted notes after the
meeting!

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

[Discuss-gnuradio] [GRCon17] Reminder of Deadlines this Week!

[Ben Hilburn]

Hey all -

Just some reminders about a number of deadlines this week regarding GRCon17:

*Presentation Deadline*
The deadline for submitting your presentation abstract (talk, tutorial, or
poster) is in *2 days*, Thursday 1 June. Check out the website for more
info, and please let us know if you have any questions! https://www.
gnuradio.org/grcon-2017/submit/

*Paper Submission Opens*
Paper submission will open on EDAS on Thursday 1 June, and closes on
Saturday 1 July. Acceptance will be on a rolling basis. For more details,
please see the website: https://www.gnuradio.org/grcon-2017/submit/

*Registration*
The deadline for Early Bird Registration is this Thursday, *June 1st*!

To register for the conference, head to Eventbrite: https://grcon17.
eventbrite.com/
To book your hotel rooms, use this link for our negotiated rate:
http://bahiahotel.com/groups/GRCon17/

Don't forget that there is discounted registration available for students (
https://www.gnuradio.org/grcon-2017/students/).

*Questions*
If you have any questions or need help, don't hesitate to let us know. You
can reach the conference organizers at `gr...@gnuradio.org`.

Cheers,
The GRCon17 Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Project Call Pushed to Next Week

[Ben Hilburn]

Hi all -

Today's project call is pushed to next week due to the busy schedules of
our coredevs today.

We'll have the call at the same time (2 PM EDT) next week, Thursday 25 May.

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

[Discuss-gnuradio] [GRCon17] Updates, Approaching Deadlines

[Ben Hilburn]

Hey all -

Some updates about GRCon17:

*Presentation Deadline*
As a reminder, the deadline for submitting your presentation abstract
(talk, tutorial, or poster) is in *2 weeks*, Thursday 1 June. Check out the
website for more info, and please let us know if you have any questions!
https://www.gnuradio.org/grcon-2017/submit/

*Paper Submission Opens*
Paper submission will open on EDAS on Thursday 1 June, and closes on
Saturday 1 July. Acceptance will be on a rolling basis. For more details,
please see the website: https://www.gnuradio.org/grcon-2017/submit/

*Registration*
Remember that the deadline for Early Bird Registration is *Thursday 1 June*,
in just two weeks! Don't forget that there is discounted registration
available for students (https://www.gnuradio.org/grcon-2017/students/).

To register for the conference, head to Eventbrite:
https://grcon17.eventbrite.com/
To book your hotel rooms, use this link for our negotiated rate:
http://bahiahotel.com/groups/GRCon17/

*Sponsors*
We've added four new sponsors since the last update to the list! We are
very happy to announce the following sponsors for GRCon17:

*simpleXecutive - Diamond Sponsor*
simpleXecutive Methodology’s patented modeling tools simulate hardware and
software performance on embedded systems, prior to writing any code. We
enable software engineers, architects and designers to deliver
sophisticated real-time systems that meet requirements, at lower costs, on
schedule and with greatly reduced risk. We encourage systematically testing
and tuning overall system design until optimal performance is achieved. We
applied our methodology and tools to the ATSC Flow Graph as part of our
DARPA contract and worked with Corgan Labs. We improved performance by over
20% without changing any of the application code or data and will share
details during our presentation.


*Epiq Solutions - Platinum Sponsor*
Epiq Solutions is a company focused on developing state of the art software
defined radio platforms and sensors that push the limits of small form
factor, integration and low power consumption. These products are used by
customers around the world in multiple business sectors, including
commercial, research and security/defense applications. In addition to
radio platform expertise, Epiq Solutions specializes in developing
integrated RF sensing products and signal processing applications that run
on these platforms. These applications leverage decades of experience in
the commercial wireless industry, enabling unique capabilities that support
2G/3G/4G cellular as well as other commercial wireless communications
standards.


*CyberRadio Solutions - Platinum Sponsor*
CyberRadio’s mission is to deliver rugged hardware solutions that combine
wideband RF tuners with embedded FPGA-based signal processing and standard
network data interfaces for worldwide connectivity. CyberRadio Solutions
GNURadio modules provide seamless open-source software development on all
CyberRadio products. The addition of GNURadio modules enable the CyberRadio
Solutions product line to support SDR applications. For More information on
our GNU Radio Modules please visit us at www.cyberradiosolutions.com


*Johns Hopkins Applied Physics Laboratory - Platinum Sponsor*
The Johns Hopkins University Applied Physics Laboratory has provided
solutions to national security and scientific challenges with engineering,
systems integration, research and development, and analysis for more than
70 years. APL is our nation’s largest University Affiliated Research
Center, with approximately 5,000 staff members and 600 ongoing sponsored
research projects. Our scientists, engineers and analysts serve as trusted
advisors and technical experts to the government, ensuring the reliability
of complex technologies that safeguard our nation’s security and advance
the frontiers of space. We also maintain independent research and
development programs that pioneer and explore emerging technologies and
concepts to address future national priorities.

Cheers,
The GRCon17 Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GFSK mod/demod does not work OK with wav file

[Ben Hilburn]

Hi Fernando -

Are there are errors / warnings / printouts happening in your GRC log
window or in your terminal? Do you see `aU` getting printed, by chance?

Also, just to be certain, your wavefile was recorded at 44.1kHz and not at
something like 48kHz?

Cheers,
Ben

On Fri, May 12, 2017 at 10:14 AM, Fernando  wrote:

> I'm playing with a GFSK modulator demodulator from here:
>
> https://www.scribd.com/doc/254559988/Gaussian-Frequency-shif
> t-Keying-With-GNU-Radio
>
> It works fine when transmitting a cosine, but when I transmit a audio
> signal (everything the same) it sounds bad, with noise and intermittent
> sound.
>
> What am I doing wrong?
>
>
>
> regards
>
>
>
>
>
> ___
> 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] How to solve command timeout error

[Ben Hilburn]

Hi Haile -

Just to be clear, you are using a custom FPGA image, is that correct?

Cheers,
Ben

On Thu, May 11, 2017 at 5:15 AM, Haile Berhe  wrote:

> Dear all,
> I have been working on my X310 USRP with gnuradio just fine. But after I have
> installed rfnoc modules and reload fpga images , the behavior of the
> device becomes unpredictable. It sometimes throws the following error
> message even if I run legacy gnuradio applications (or non rfnoc application):
>
> “RuntimeError: EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
> no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>   at /home/haile/prefix/default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197”
>
> I have observed that the above error is not thrown in the first run
> after I power cycle the device. [1] seems to discuss the issue but the
> proposed solution is not clear. It says, check ce_clk/ce_rst are
> connected in the rfnoc_ce_auto_inst_.v., etc .. How am I
> supposed to check?
>
> Thanks,
>
> [1] https://kb.ettus.com/RFNoC
>
>
> ___
> 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] Custom C++ blocks on E310

[Ben Hilburn]

Hey Jessica -

The SIGBUS you are receiving indicates that there is likely some funniness
happening with memory addressing / access somewhere. Especially since your
test flowgraph is so simple, using GDB to get a backtrace might point you
to the offending code pretty quickly. For more details on how to do this,
check out this page on our Wiki:
https://wiki.gnuradio.org/index.php/TutorialsDebugging#Expert_debugging_tools

Have you tried this already? If so, can you share the backtrace?

Cheers,
Ben



On Thu, May 11, 2017 at 6:15 PM, Jessica Iwamoto 
wrote:

> Hi again,
>
>
>
> Attached is the code that I’m using if anyone would like to try to
> replicate my issue. The test_msg_py.py file contains the custom python
> block code for a simple message sink. The test_msg_impl.cc,
> test_msg_impl.h, and test_msg.h files contain the custom C++ code for a
> message sink. The test.py file contains a simple flowgraph that connects a
> message strobe to my custom message sink blocks. When I run test.py with
> either of the blocks on my desktop, it works correctly. However, when I run
> test.py after cross compiling on the E310, it works correctly with the
> test_msg_py block and produces the following error with the test_msg block:
>
> Could not find port: in in:
>
> system
>
> Bus error
>
>
>
> Thanks,
>
> Jessica
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jessica.iwamoto=
> aero@gnu.org] *On Behalf Of *Jessica Iwamoto
> *Sent:* Wednesday, May 10, 2017 9:53 AM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* [Discuss-gnuradio] Custom C++ blocks on E310
>
>
>
> Hi all,
>
>
>
> I have built custom C++ blocks that work on my PC, but don’t work when
> cross compiled for the E310. Specifically, I am trying to build a custom
> C++ block with a message port and cross compile it for the E310. I am using
> version 3.7.12 of GNU radio and the latest version of the SDK/toolchain for
> the E310. I have built a simple message sink block with just a message
> input port and put it in a flowgraph with a message strobe. My code runs
> correctly on my PC but when I run it on the E310, I get the error:
>
> Could not find port: msg in:
>
> system
>
> Bus error
>
>
>
> I am able to create custom python blocks with message ports and run them
> on the E310 and my PC with no issues. Additionally, I am unable to create
> custom C++ blocks with normal input and output streams on the E310 (the
> program seg faults when I try to connect the custom block to another
> block), but they run correctly on my PC. Any suggestions on what could be
> causing this?
>
>
>
> Thanks,
>
> Jessica
>
>
>
> ___
> 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] [GSoC 2017] gr-bokehgui: Updates on Week 0

[Ben Hilburn]

Hi Kartik -

Thanks! I appreciate the description of how you will manage branches in
your repository.

This is really important work for GNU Radio's flowgraph UI, generally, and
I'm excited to see your work this Summer.

Happy Hacking!

Cheers,
Ben

On Thu, May 11, 2017 at 5:23 PM, Kartik Patel 
wrote:

> Hello all,
>
> I am Kartik Patel. I will be working on web-based display mechanism for
> GNU Radio during summer 2017.
>
> The module is available on Github at this link
> . My primary mode of
> providing updates will be a public blog .
> A brief email will be sent to this forum for the reference.
>
> The details of the week 0 are available here
> [1]. I have
> added the git workflow of the module, and tasks of week 0 on the blog.
>
> Kindly reply to this mail for any query or feedback.
>
> Thank you.
>
> Regards,
> Kartik Patel
>
>
> [1] http://kartikpatel.in/GSoC2017/2017/05/11/introduction.html
> ᐧ
>
> ___
> 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] GSoC17 - A DAB/DAB+ transceiver app

[Ben Hilburn]

Hey Luca -

Awesome! Nice touch adding the Phase 1 countdown, by the way, hah.
Congratulations, again, and we look forward to your work this Summer =)

Cheers,
Ben

On Fri, May 12, 2017 at 5:59 AM, Moritz Luca Schmid <
luca.moritz.sch...@gmail.com> wrote:

> Hi to all,
>
>
> the blog for my GSoC project "A DAB/DAB+ transceiver app" just went online!
>
> Check it out here <https://dabtransceiver.wordpress.com>. I am going to
> write weekly blog posts with updates about my progress and you can find
> find other information about GSoC and my project there.
>
> Checkout the forked gr-dab <https://github.com/kit-cel/gr-dab> repository
> on GitHub as well to watch my latest progress.
>
> Best
>
> Luca
>
>
>
> On 05.05.2017 01:06, Moritz Luca Schmid wrote:
>
> Thanks to Ben and Kartik for your congrats and thanks to all GNU Radio
> community members for your support!
>
> I am really excited about the upcoming summer and my DAB project and I am
> looking forward to work in this great community.
>
>
> Cheers and congrats to Kartik and Kosta as well!
>
> Luca
>
> On 04.05.2017 20:12, Kartik Patel wrote:
>
> Dear Ben,
>
> I would like to thank you and other GNU Radio members for this wonderful
> opportunity. Thank you all, for your help with proposal refinements and a
> quality discussions.
>
> I will try my best to complete the project. My association with GNU Radio
> was successful before GSoC and I am looking forward to a successful
> association during GSoC and way beyond the GSoC the time!
>
> Also, congratulations to Luca and Kosta for the selection in GSoC. All the
> best for the respective tasks! I hope we will share wonderful memories in
> upcoming future! :D
>
> Regards,
> Kartik Patel
>
>
>
> On Thu, May 4, 2017 11:15 PM, Ben Hilburn bhilb...@gnuradio.org wrote:
>
>> Congratulations to Luca, Kartik, and Kosta for being accepted into Google
>> Summer of Code 2017! We are really excited about your projects, and look
>> forward to seeing your work over the next few months.
>>
>> Luca will be working on GNU Radio's DAB/DAB+ capabilities, Kartik's
>> project is enabling a web-based GUI for flowgraphs, and Kosta will be
>> working on SigMF integration for GNU Radio. More information about these
>> projects can be found on the GNU Radio organization page on the GSoC
>> website, here: https://summerofcode.withgoogle.com/organizations/
>> 5111801772507136/#
>>
>> We now start the GSoC "Community Bonding period" during which Luca,
>> Kartik, and Kosta have time to get ramped up within the project and
>> community. Please join me in giving them a warm welcome and congratulations!
>>
>> Cheers,
>> Ben
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC 2017] SigMF functionality for GNU Radio

[Ben Hilburn]

Thanks, Kostis! I'm really looking forward to your work on `gr-sigmf` this
summer.

Happy Hacking!

Cheers,
Ben

On Fri, May 12, 2017 at 10:12 AM, Kostis Triantafyllakis  wrote:

> Hello,
>
> I just wanted to inform the list that the repo for my GSoC 2017 project is
> available on Github .
> Also, please consider my blog , for
> more information about the progress of the development.
>
> Your comments and suggestions are more than welcome.
> Best,
> Kostis Triantafyllakis
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GSoC Projects Announced!

[Ben Hilburn]

Congratulations to Luca, Kartik, and Kosta for being accepted into Google
Summer of Code 2017! We are really excited about your projects, and look
forward to seeing your work over the next few months.

Luca will be working on GNU Radio's DAB/DAB+ capabilities, Kartik's project
is enabling a web-based GUI for flowgraphs, and Kosta will be working on
SigMF integration for GNU Radio. More information about these projects can
be found on the GNU Radio organization page on the GSoC website, here:
https://summerofcode.withgoogle.com/organizations/5111801772507136/#

We now start the GSoC "Community Bonding period" during which Luca, Kartik,
and Kosta have time to get ramped up within the project and community.
Please join me in giving them a warm welcome and congratulations!

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

Re: [Discuss-gnuradio] April Project Call Today!

[Ben Hilburn]

Whoops - the top link in my e-mail was incorrect. Correct link:
https://wiki.gnuradio.org/index.php/DevelopersCalls

Thanks, Sagnik, for pointing this out!

Cheers,
Ben

On Thu, Apr 20, 2017 at 10:56 AM, Ben Hilburn <bhilb...@gnuradio.org> wrote:

> Hey all -
>
> This is just a reminder that our monthly project call is today at 1800
> GMT (1400 EDT)!
>
> https://wiki.gnuradio.org/index.php/DevelopersCalls
> <http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls>
>
> <http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls>
> http://gnuradio.org/events/
> <http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls>
>
> You can also participate by joining #gnuradio in IRC / Slack. If you have
> to miss it, don't forget you can always read the posted notes after the
> meeting!
>
> Cheers,
> Ben
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] April Project Call Today!

[Ben Hilburn]

Hey all -

This is just a reminder that our monthly project call is today at 1800 GMT
(1400 EDT)!

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



http://gnuradio.org/events/


You can also participate by joining #gnuradio in IRC / Slack. If you have
to miss it, don't forget you can always read the posted notes after the
meeting!

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

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

[Ben Hilburn]

Hi Håkon -

Welcome! I'm really excited to see someone tackling C++ Code Generation. As
Marcus said, it's something that people have been asked about for years,
and it would be great to get it implemented. A few questions / suggestions
on your proposal:

   - As Marcus mentioned, simple proposals are great, but I do think you
   need a bit more detail. Marcus covered this well in his e-mail, so I won't
   add anything to that point.
   - This is the sort of functionality that would be best upstreamed rather
   than existing in an OOT module. We should discuss how this process might
   work, as it requires a CLA to the FSF. If you aren't familiar with this,
   please e-mail me & Johnathan (jcor...@gnuradio.org) so that we can
   describe it further.
   - One of the big differences between generating Python and generating
   C++ is that a C++ flowgraph will need to be compiled before being executed.
   Laying out how you plan to handle that flow from GRC, I think, will be
   really important.

Again, welcome, and I look forward to seeing where this work goes =)

Cheers,
Ben

On Sun, Mar 26, 2017 at 10:48 AM, Marcus Müller 
wrote:

> Dear Håkon,
>
> cool! The C++ output option for GRC has been on many wishlists for a long
> long time.
>
> I do like the brevity of your proposal, however I miss a bit of you
> describing *how* exactly you want to do things, and what to focus on in
> which order. We're well aware of this specific idea being displayed very
> generally in the ideas list; that has the purpose of letting you pick and
> discuss your focus very freely. If I understand your timeline properly,
> your order of things is
>
>1. Add GUI elements to GRC to make it to connect functionality later
>2. C++ code generator
>3. Build system infrastructure
>
> Having the UI interface as first item seems like a positive approach to
> get to know the Python code of GRC a little better. I do think it kind of
> could wait until you'd actually be able to generate C++ code – that'd give
> you the chance to get a lot of feedback early and change directions of how
> you do things; GRC in it's current situation is relatively well split
> between the GUI and the (Python) code generation.
>
> I assume you've had a rough look at how Python generation in GRC works
> right now (block_name.xml files describe the GRC blocks, including the code
> that has to be called to instantiate an instance of the GNU Radio block
> class, and how these blocks are set up and connected is described in
> flow_graph.grc files; the actual python code is a template filled with the
> info from these).
>
> Now, in a first approach, this would "only" (as if) be a matter of adding
> new templates for the generated code, and new tags to the .xml files that
> describe which C++ code to call – but it would still be great to see you
> reflect a bit on whether you deem the same (Python-generation) templating
> infrastructure suitable for this use case (really, doesn't have to be
> in-depth – this is just a proposal) or whether you'd think there's things
> to change.
>
> Same goes for the "Makefile" generation. We really won't nail you down on
> what you propose now, but you giving a vision (maybe in a quick block
> diagram) of how the Makefile (or build system, in general – we use CMake in
> GNU Radio, and if you'd have another idea how to generate an executable
> from the C++ you generate, don't be shy, we can and will gently criticize
> if we found that necessary ;) ) will come together, and give maybe a list
> of infos on what info comes from where and ends up in the C++ header and
> the main source file and the Makefile, it'd give me a fuzzy warm feeling
> about you having a plan how to approach things.
>
> So: I like your project proposal, but I like it so much that I'd want to
> see more of a proposed idea here. I think both Felix and Sebastian don't
> want to mentor you as a "code monkey" – the whole project would very much
> value you as active critic and architect of "how things are done" in GRC
> and GNU Radio in general, so it's kind of important to us that you
> emphasize how your plan is more than what the Idea from the GSoC Ideas List
> already defines.
>
> Best regards,
>
> Marcus
> On 03/26/2017 02:20 PM, Håkon Vågsether wrote:
>
> Hello!
>
> My name is Håkon Vågsether, and I am a first year MSc student in
> Cybernetics and Robotics at NTNU's (Norwegian University of Science and
> Technology, Trondheim). I am very interested in participating in GSoC 2017
> for GNU Radio and I have added a link below to my proposal draft for the
> GRC C++ output idea for this year's GSoC. I believe I have added everything
> that was required, but I suppose I will have to be more specific with the
> deliverables and milestones in the final proposal. I would love some
> feedback, and if I have misinterpreted or neglected something, please tell
> me so I can fix it for the final proposal! :) I am really excited to get in
> 

Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

[Ben Hilburn]

Hi Kostis -

So the SigMF spec is designed specifically to enable writing the metadata
> and dataset files in a streaming manner. The spec is careful not to dictate
> how applications create SigMF recordings, so it's not a problem if you
> write a bunch of stuff and then after you finish streaming to the files you
> open them up and add some more stuff to finish them off.
>
> Bastian's point, though, is a good one. In the use-case where you are
> streaming metadata and samples into files and then you close your
> application, do you plan on needing to go back to add more information to
> the metadata file? If so, how do you do that in an automatic way if the
> flowgraph has stopped?
>
> Maybe I could let the destructor of the block in combination with fseekm
> handle the finalization of the metafile. The case of segfault is actually a
> question that needs more attention.
>

Not a bad idea. It might be worth getting Johnathan to weigh-in on what he
thinks is best, here, too.


> - We are working hard to get the SigMF spec into a stable state as soon as
> possible, but as you can see from the issue tracker (which is where we are
> hosting our discussions) there are aspects of the spec that are still being
> debated. Many of these would impact your implementation. I think it would
> be good to explain your plan to (a) participate in the SigMF spec
> discussions, especially with the insight you gain from implementing support
> for it and (b) deal with pieces of the spec that may be a moving target.
>
> I have already started looking at the open issues. Do you think it would
> be meaningful to move the discussion there, in a dedicated issue?
>

For discussion of the SigMF design, the SigMF tracker is the right place.
For discussion of your GSoC proposal, I think staying on-list is the right
thing =)


> - Since this will create a dependency on RapidJSON (or whatever you use),
> we'll want to be sure that *not* having that installed doesn't prevent
> building anything not related to SigMF within GNU Radio. I really dislike
> adding dependencies, but since we don't already have a JSON library there
> isn't much of an option, here, so we just need to be sure to minimize the
> burden to users, developers, and packagers.
>
> According to the description in the main page, RapidJSON "is
> self-contained and *header*-only". I dont know if MIT is a problem though.
>

MIT license is fine .

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

Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

[Ben Hilburn]

Hey Bastian -

> No, they cannot. If your capture details aren't changing (center
> > frequency, bandwidth, etc.,), then you can stream the annotations as
> > they are continuous, but you can't hop back and forth between them.
>
> But that means in all but the simples case the metadata cannot be
> written in a streaming manner. And worse, you cannot know in advance.
> If the SigMF sink wrote thousands of annotations and the SDR experiences
> an underrun, it creates a new segment and invalidates basically the
> whole file. So, AFAIS, we're back at the problem above, i.e., the sink
> needs a way to deal with that.
>

Yup, you're right. Did you open an issue on the SigMF repo to discuss this
further? If so, I think I missed it.

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

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

[Ben Hilburn]

Hey Kartik -


> Gentle reminder regarding previous email.
>

I read through it and didn't see anything that needed a response from me -
let me know if there is something there you would like for me to weigh-in
on?


>
> Also, I have implemented a Plotly based frontend and Bokeh server as
> backend. Please see [1 ].
>

Awesome! I really appreciate your effort to prove things out with
prototypes.


>
> For demo: Go to [2
> ]
> for Bokeh based output and [3 ]
> for Plotly based output. In both cases, backend is handled by Bokeh.
>

Unfortunately, neither of those links worked for me - the pages don't seem
to render anything.


> Now, I think this example solves the query of independent frontend and
> backend. As shown in the example, using the socket provided by Bokeh
> server, one can use any frontend library for plotting.
>
> Also, any change in connected client will be pushed by Bokeh server. So,
> the person changing the frontend library (in future) will have to handle
> such changes using Javascript.
>

While this does prove the feasibility of independent front-end and
back-ends, it is still "all-in" on Bokeh in the sense that the server and
integration with GR is built with Bokeh. Again, I'm not saying that's the
wrong decision, but I want to be sure that where the delineations lie are
clearly called out in the proposal & docs.


>
> So, I think, now we can easily use Bokeh backend for the task. Instead of
> writing server application on our own, Bokeh will be more structured and
> efficient. What is your suggestion on this?
>

I think this is suitable for this effort, and creating it in the OOTM
mitigates the risk of dependency lock-in. I'm on-board with the use of
Bokeh.

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

Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

[Ben Hilburn]

Responding to a couple of the points made:


On Fri, Mar 24, 2017 at 12:35 PM, Garver, Paul W  wrote:

4) In thinking about the GR metadata format, there’s sort of two different
> types of metadata you want. One is stuff that doesn’t change such as data
> type, recorder specifications, etc. The other is the per-sample  stuff like
> time tags, center frequency, etc. With GR tags, there’s some inefficiency
> since the static items are written every tag. How does sigMF address this?
>

SigMF breaks these up into different metadata segments attached to sample
indices: https://github.com/gnuradio/SigMF/blob/master/sigmf-spec.md

On Fri, Mar 24, 2017 at 12:17 PM, Bastian Bloessl  wrote:

> > So the SigMF spec is designed specifically to enable writing the
> > metadata and dataset files in a streaming manner.
>
> Can annotations and capture segments be interleaved or how is it
> possible to write the metadata in a streaming manner?
>

No, they cannot. If your capture details aren't changing (center frequency,
bandwidth, etc.,), then you can stream the annotations as they are
continuous, but you can't hop back and forth between them.

This is an interesting point, though. Would you mind raising this on the
SigMF tracker for discussion, Bastian?

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

Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

[Ben Hilburn]

Hi Kostis -

Great proposal! I'm really excited to see someone tackling the SigMF item
on the Ideas List.

I'll respond in-line to Bastian, and then add some of my own:

- You mention that sources and sinks will handle PDUs and Tagged
> Streams. I wonder what would be one PDU. A SigMF "capture segment" or
> some other chunk of samples. Also are you sure you want to use Tagged
> Streams? Maybe you meant normal streams with tags? With Tagged Streams,
> you would have to fit the whole capture segment in the input buffer of
> the block. That might not be possible.
>
> - You mention that RapidJSON code is messy. Does it auto-generate code?
> That could even be an advantage, since SigMF might well go through some
> more iterations. Did you plan to also create wrappers for Python?
>
> - The goal of SigMF seems to be to provide a very minimal spec, and I
> think many users will have to rely on custom extension in namespaces.
> Maybe you could describe a bit how source/sinks and the GUI could deal
> with these extensions.


> - You will provide the means to filter data. Did you only plan to filter
> specific capture segments or also arbitrary samples based on
> annotations? Since you mentioned modulation, which is, AFAIK, currently
> not specified, did you plan to allow filtering on custom properties?
>

So, thinking about this a bit, if Kostis' implementation enables filtering
on fields in the `core` namespace, it shouldn't really be any additional
effort to support non-`core` namespaced fields. Since any field would be in
a capture / annotation segment, which thus would be mapped to a sample
index / number of samples, Kostis' software doesn't have to care *what*
that field is in order to "select it" in the tool.

That's how I read the proposal, anyway. Kostis, it might be good to clarify
this in the proposal.


> - Regarding the GUI, it seems as if you plan to develop something from
> scratch. Did you consider extending projects like "such samples" from
> Tim or Inspectrum?
>

(Seth just responded while I was writing this message, but my comments are
similar.)

I agree with Seth and Bastian, here. Generally, I'm a fan of extending
existing functionality rather than creating something from scratch. That
said, using one of the existing things will also require development.

In the "such samples" case, it's actually just itself a flowgraph (
https://github.com/osh/gr-pyqt/blob/master/apps/such_samples2.grc). In
order to integrate SigMF into it (which I don't think is a bad idea), new
blocks / code will need to be written. Using "Inspectrum" is actually more
problematic, especially since it doesn't use GNU Radio under-the-hood. You
would effectively be doing work for a different project on GNU Radio GSoC
money, which I don't think makes sense.

It might be worth looking at what blocks / code would be necessary to allow
the existing Qt GUI features (e.g., "such samples") to make use of the
functionality you will be writing in GNU Radio. Ideally, any work you do
there can be used in other flowgraphs (not just "such samples"), but using
"such samples" would be a great way to reduce your own burden. If you
determine that there is really no way to build on things that already
exist, then implementing a new tool (like the one in your proposal, now)
that is integrated with GRC (e.g., the filter design tool) might indeed be
the best way forward. It would be good to explain the justification behind
the final decision in the proposal.

(It's worth noting that I would really like to see SigMF support in
Inspectrum, and I don't think SigMF support there means it wouldn't be
useful here, as well. Inspectrum does more than just visualize data, and
one of the key goals of SigMF is portability between tools & workflows.)


> - I wonder what would be the workflow when creating a SigMF recording.
> An issue might be that you cannot immediately write the SigMF meta file
> during recording. (For example, the hash has to be calculated after the
> recording. Or the annotations have to be written after the capture
> segments.). Did you plan to create the meta data in memory and write the
> file when the flow graph shuts down (which might cause data loss when
> you experience a segfault) or do you write meta data to disk in an
> intermediate format that you have to post-process manually to create the
> final SigMF files.
>

So the SigMF spec is designed specifically to enable writing the metadata
and dataset files in a streaming manner. The spec is careful not to dictate
how applications create SigMF recordings, so it's not a problem if you
write a bunch of stuff and then after you finish streaming to the files you
open them up and add some more stuff to finish them off.

Bastian's point, though, is a good one. In the use-case where you are
streaming metadata and samples into files and then you close your
application, do you plan on needing to go back to add more information to
the metadata file? If so, how do you do that in an automatic 

Re: [Discuss-gnuradio] [GSoC] A DAB/DAB+ transceiver app: Draft of proposal

[Ben Hilburn]

Hi Moritz -

Nice work! I'm really happy to see this proposal. A few notes:

* If you plan on integrating any other software into your work, please
specifically call out its license.
* As Martin said, it would be good to fix some of the typos. Also, please
add a paragraph break (either an indent or a carriage return) to more
clearly indicate where your paragraphs start & stop.
* In "Deliverable Features", there actually seems to be a mix of things
that you will deliver as part of this GSoC project, and things that already
exist that you will re-use. It would be good to find a way to specifically
highlight which items you are implementing / contributing to GNU Radio as
part of the work (note that integrating third-party software into a block
*is* a contribution).

I'm really excited to see where this goes, and great work so far!

Cheers,
Ben

On Mon, Mar 20, 2017 at 1:46 PM, Moritz Luca Schmid <
luca.moritz.sch...@gmail.com> wrote:

> Hi Bastian,
>
> thanks for the tip! The projects of opendigitalradio association seem
> really interesting for the DAB project, and welle.io in particular for
> the GUI. Matthias from opendigitalradio wrote me as well.
>
> I am planning to reuse some code especially for the implementation of MPEG
> Audio Layer II and HE-ACC-v2 coding, as I wrote in my proposal. These
> projects seem the perfect source for this case.
>
>
> Thanks and Regards
>
> Luca
>
>
>
> On 20.03.2017 18:00, Bastian Bloessl wrote:
>
>> Hi Luca,
>>
>> great proposal.
>>
>> Apart from gr-dab, there seem to be several other DAB implementations.
>> Opendigitalradio lists a few:
>> http://wiki.opendigitalradio.org/DAB_reception
>>
>> Did you have a look at them? welle.io, in particular, seems to be
>> interesting in that context.
>> Maybe you could reuse (some of) their code and mainly integrate it into
>> GNU Radio.
>>
>> Best,
>> Bastian
>>
>>
>>
>>
>> On 18 Mar 2017, at 15:59, Luca Schmid 
>>> wrote:
>>>
>>> Hi everyone,
>>> my name is Moritz Luca Schmid and I am a third-year student of
>>> electrical engineering at KIT. I also work as an assistant at the
>>> Communications Engineering Lab (CEL) in Karlsruhe.
>>>
>>> I am going to propose for the GSoC 17 DAB/DAB+ transceiver app project.
>>> It would be very kind of you to take a look at my proposal and give me some
>>> feedback.
>>> You can find the draft proposal on my GitHub:
>>> https://github.com/MoritzLucaSchmid/GSoC-proposal
>>>
>>> Thanks and Regards
>>> Luca
>>>
>>
>
> ___
> 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] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

[Ben Hilburn]

>
> Only reason, I am resistant to the idea of not using the Bokeh server is
> that the existing features and scope of the project will be reduced. Since,
> all the plots and widgets are necessary in order to make the module usable,
> limiting the plots will not be good enough. Although I am open to
> contributions on this module even after GSoC, this is not valid statement
> for the proposal in GSoC.
>
> I am fully aware with the probable issues of having the external library
> as core dependency. I can also imagine the module having independent
> frontend and backend. But is it worth rewriting the code that exist in
> Bokeh?
>

In my opinion, *no*, if Bokeh does what we need and has its own community
maintaining it, that's a better option than us trying to do it ourselves.
And while I'm normally extremely hesitant to add more dependencies (I know
Johnathan feels the same way), this is different as its an OOT module (at
least for now).

If the determination is that Bokeh is a good fit, then by all means lets
use it. The point I was trying to make (and the one that I think Marcus,
Bastian, and Martin were making), is that it is preferable to architect
this such that the interface to "the GNU Radio domain" is as agnostic to
Bokeh as possible; we want to maximize the reusability of this effort down
the road if for whatever reason we do something not-in-Bokeh.

Now, whether or not "Bokeh is a good fit" might still be up for debate, but
I see Sebastian just responded on that topic.

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

[Discuss-gnuradio] March 2017 Project Call Today

[Ben Hilburn]

Hey all -

This is just a reminder that our monthly project call is today at 1800 GMT
(~1 hour from now)!

http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls


http://gnuradio.org/events/


You can also participate by joining #gnuradio in IRC / Slack. If you have
to miss it, don't forget you can always read the posted notes after the
meeting!

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

[Discuss-gnuradio] [GRCon17] Student Registration, Program, New Sponsors

[Ben Hilburn]

Hey all -

We have a few announcements regarding GRCon17:

*Student Registration*
We are very excited to announce that Ettus Research will once again be
sponsoring student registrations for GRCon! To learn more about how to take
advantage of the student registration, visit the conference website, here:
http://gnuradio.org/grcon-2017/students/


*Conference Program*
A tentative structure for the conference program is now live on the
website. It is obviously subject to change and relatively high-level at
this point, but it should give you some idea of what the conference is
likely to look like: http://gnuradio.org/grcon-2017/program/

The Conference 'About' page provides additional details on the types of
sessions: http://gnuradio.org/grcon-2017/about/

*Sponsors*
Two more organizations have joined the conference sponsor list!


*Hume Center for National Security and Technology - Gold Sponsor*The Hume
Center leads Virginia Tech’s research, education, and outreach programs
focused on the challenges of cybersecurity and autonomy in the context of
national and homeland security. Education programs provide mentorship,
internships, scholarships, and seek to address key challenges in qualified
US citizens entering federal service. Current research initiatives include
cyber-physical system security, orchestrated missions, and the convergence
of cyber warfare and electronic warfare. Positions open for graduate
students and research faculty, with an emphasis on software defined radio,
digital signal processing, and machine learning.

*SkySafe - Bronze Sponsor*
SkySafe was founded in 2015 to develop small drone management and
mitigation systems. Built heavily on software defined radio and customized
frontend hardware, the SkySafe solution leverages a library of drone threat
information, protocol integration, and spectrum sensing techniques to
secure sensitive airspace. We are avid supporters of open source platforms,
security tools, and radio building blocks. For more information, please
visit www.skysafe.io or email us at i...@skysafe.io.

Cheers,
The GRCon Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GRCon17] Conference Update

[Ben Hilburn]

Hey all -

We would like to provide a brief update on GRCon17:

*Tickets*
We've had a fair number of ticket sales come through since registration
went live a couple of weeks ago, and we're looking forward to another year
of strong attendance.

Registration:
https://www.eventbrite.com/e/gnu-radio-conference-2017-tickets-32325995924

*Talks*
Thank you to those of you that have submitted talks so far! We have
received some really interesting abstracts already, and we are working on
an outline of the conference program which will go live on the site soon.
We are structuring the conference program to allow for more tutorial-style
content while maintaining the high quality of technical presentations that
you are accustomed to seeing at GRCon.

Call for Presentations: http://gnuradio.org/grcon-2017/submit/


*Sponsors*
We already have three sponsors committed to the conference!

Sponsor page: http://gnuradio.org/grcon-2017/sponsors/

*Ettus Research - Diamond Sponsor:*
Ettus Research™, a National Instruments (NI) company since 2010, is the
world’s leading supplier of software defined radio platforms, including the
Universal Software Radio Peripheral (USRP™) family of products. By
supporting a wide variety of development environments on an expansive
portfolio of high performance RF hardware, the USRP platform is the SDR
platform of choice for thousands of engineers, scientists and students
worldwide for algorithm development, exploration, prototyping and
deployment for next generation wireless technologies across a wide variety
of applications.

*Corgan Labs - Gold Sponsor:*
We are Corgan Labs. As a leader within the GNU Radio community, our mission
is to empower other engineers and developers to leverage software-defined
radio (SDR) technology. We offer training and project consulting services,
which are proven to shorten the learning curve and make development teams
more productive. If your team is looking to learn the basics of SDR, is
struggling to overcome unexpected development challenges, or is considering
how to use the latest in SDR technology, we hope to help you through this
process.

*Innovative Integration - Silver Sponsor:*
Innovative Integration, a Molex Company,  designs and manufactures a
variety of products which operate synergistically. Our broad range of XMC
and FMC I/O modules support capture and playback of analog signals from DC
to 5 GHz, with any number of channels phase-aligned and synchronous. These
can be combined with our rugged, embedded PC or SoC single board-computers
and custom programmed using our comprehensive Malibu C++ control library
and Framework Logic software packages to rapidly deploy unique products for
real-time control, wireless communications, medical instrumentation and
portable field measurements.  Included within our portfolio is our Digital
Transceiver and Digital Receiver series, which is a turnkey solution
providing an integrated data logger, digital down conversion (DDC), digital
up conversion (DUC), and a spectrum analyzer (FFT) in a compact system. The
Digital Transceiver is a turnkey solution providing an integrated data
logger, digital down conversion (DDC), digital up conversion (DUC), and a
spectrum analyzer (FFT) in a compact system.

Cheers,
The GRCon Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GRCon17] - Registration & Hotel Booking are Live!

[Ben Hilburn]

Greetings!

Registration for GRCon17 is now live! Note that there is an Early Bird
discount in effect from now until June 1st, so be sure to register soon if
you can.

Head here to purchase your ticket: grcon17.eventbrite.com.

Additionally, booking at the conference hotel is now open. The venue has
agreed to offer the GSA room rate for the area to GRCon17 attendees, which
is highly competitive compared to surrounding hotels. This rate is also
available several days before and after the event to GRCon17 attendees.

Book rooms in the GRCon17 Room Block here: bahiahotel.com/groups/GRCon17/

Starting this year we will be designing yearly conference swag, including
T-Shirts, Hoodies, and Beer Steins. These items will only be available in
extremely limited quantities at the conference, so if you would like one or
more of them we recommend purchasing them with your conference registration.

If you are interested in sponsoring the conference, please get in touch
with us at `gr...@gnuradio.org`. Sponsors are a critical part of GRCon, and
this year we have revamped the sponsor packages to improve benefits.

If you have any questions, please let us know. We look forward to seeing
you at the beautiful Bahia beach resort for GRCon17!

Cheers,
The GRCon Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code 2017: And we're in!

[Ben Hilburn]

I want to acknowledge all of the work that Martin puts in to GSoC and SOCIS
each year. Without his effort, GNU Radio would likely not be able to
participate in these programs, and thus students wouldn't have the
opportunity to hack on what is arguably one of the coolest open-source
projects around :)

Nice work, Martin, and thanks to all of the mentors & participants who
provided input to the ideas list! I'm looking forward to another great year.

Cheers,
Ben

On Mon, Feb 27, 2017 at 5:14 PM, Martin Braun  wrote:

> Everyone,
>
> I'm really happy to say that we made it into the list of GSoC mentor
> organizations for 2017. If you're a student, you should definitely check
> out our GSoC wiki page:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC
>
> Here, you will find instructions (should you want to participate) as
> well as ideas for projects. In general, the earlier you start engaging
> with the community, as some students here already have, the better your
> chances are. I would also highly recommend starting to work on an
> application ASAP. This mailing list is a good place to discuss those
> applications.
>
> More info is coming, but if you have any questions already, this is a
> good thread to ask them!
>
> Cheers,
> Martin
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GRCon17] Call for Presentations & Papers

[Ben Hilburn]

Hey all -

The CFP for GRCon17 is now live! You can find the details on the GRCon17
website:
http://gnuradio.org/grcon-2017/submit/

We are accepting abstracts for three types of presentations at GRCon17:
talks, tutorials, and posters. The format for the poster presentations will
change somewhat this year, as there will be scheduled poster session times
during the conference.

The deadline to submit your presentation abstract is *Thursday 1 June. *

In addition, we are very excited to once again publish the Annual Technical
Proceedings of the GNU Radio Conference. The proceedings of GRCon are
published on the GNU Radio website (http://pubs.gnuradio.org/), and are
also indexed by Google Scholar. Last year's proceedings have some truly
excellent contributions to the field, and we look forward to seeing this
year's papers.

*You do not need to publish in the proceedings to give a talk at GRCon, and
you do not need to give a talk at GRCon to publish in the proceedings.* We
encourage everyone giving a talk to also submit a paper, and anyone
submitting a paper to also give a talk, but it is not required. We do this
to so that people with important contributions to publish, but who are
unable to make it to the conference, can still participate.

We take pride in GRCon's reputation for having a high signal-to-noise
ratio, and our growing attendance is testament to the high quality of
people and content at the conference each year . This is only possible with
your participation, and we look forward to seeing you at the conference!
Please let us know if you have any questions.

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

[Discuss-gnuradio] Feb 2017 Project Call

[Ben Hilburn]

Hey all -

This is just a reminder that our monthly project call is today at 1800 GMT!

http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls


http://gnuradio.org/events/


You can also participate by joining #gnuradio in IRC / Slack. If you have
to miss it, don't forget you can always read the posted notes after the
meeting!

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

[Discuss-gnuradio] [GRCon17] Dates & Venue Announcement!

[Ben Hilburn]

Hi all -

We are very pleased to announce that we have a venue & dates for the 7th
Annual GNU Radio Conference! GRCon17 will take place at the Bahia Resort
Hotel  in San Diego, California, from Monday 11
September through Friday 15 September 2017.

We have negotiated a very competitive room rate with the conference hotel,
and are working on finalizing the registration system. The hotel rate will
also be available for a few days before and after the conference if you
want to spend a bit of extra time in beautiful San Diego. We will send out
another message when the registration system goes live, which should be
very soon.

The conference website is here, and will be updated with new information as
its ready: http://gnuradio.org/grcon-2017/

We are also still looking for volunteers to join the GRCon Organizing
Committee. If you are interested, let me know!

If you have any questions, please don't hesitate to get in touch with us at
gr...@gnuradio.org. Thanks, and we look forward to seeing you in San Diego
in September!

Cheers,
The GRCon Organizing Committee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code -- Ideas List!

[Ben Hilburn]

Hey Kartik -

Sebastian and I just caught up about this, and I'm in agreement that they
should be separate ideas. Sebastian is going to break the ideas back out
again and make sure the delineation between the two is clear.

Thanks again for adding the idea! I'm really excited about both of these =)

Cheers,
Ben

On Thu, Feb 9, 2017 at 12:26 PM, Kartik Patel <kartikpatel1...@gmail.com>
wrote:

> Hi Ben,
>
> Regarding HTML-based GUI of GRC: Actually both the ideas are slightly
> different. As far as I think, the idea added by Sebastian was basically
> opening HTML view at run-time. So, output would be based on HTML view. All
> the panels and plots will be based on HTML.
>
> On the other hand, my idea was to use a full-fledged HTML based GRC. Draw
> a flowgraph on HTML canvas, upon running, it will initiate a process on
> server, and the response data will be a response from the server which will
> be shown on frontend.
>
> So, actually both are different. I also contacted Sebastian, and he
> suggested that both ideas can be there. But the full-fledged HTML based
> gnuradio will be too long for a 3 month project.
> Now when I think about it, I think the first phase of full-fledged HTML
> based gnuradio can be the one suggested by Sebastian.
>
> So, that's fine if it's combined for now. I just wanted to clarify both
> ideas.
>
> Also, thank you very much for your interest in mentorship for statistical
> toolbox.
>
>
> Regards,
> Kartik Patel
>
>
>
> On Thu, Feb 9, 2017 8:22 PM, Ben Hilburn bhilb...@gnuradio.org wrote:
>
>> Hi Kartik -
>>
>> Thanks for getting involved! There actually already was an HTML-based GRC
>> on the ideas list, so I combined the new one you created with the existing
>> one. I also made some minor edits to your Stastical Toolbox idea, and added
>> my name as a Mentor.
>>
>> Cheers,
>> Ben
>>
>> On Thu, Feb 9, 2017 at 5:31 AM, Kartik Patel <kartikpatel1...@gmail.com>
>> wrote:
>>
>> Hello everyone,
>>
>> The two of the ideas (1. statistical toolbox, 2. HTML based GRC) have
>> been added in the GSoC Idea wiki page.
>>
>> Please review it and suggest any updates on *wiki*.
>>
>> Thank you.
>>
>> Regards,
>> Kartik Patel
>>
>>
>>
>> On Tue, Feb 7, 2017 8:24 PM, Marcus Müller marcus.muel...@ettus.com
>> wrote:
>>
>> Hi Kartik,
>>
>> ha! Sorry for mixing this up. Yes, in that case, you'd be the GSoC
>> participant, not the mentor :)
>>
>> I've pinged the right people. Hopefully we can get your account going.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 02/06/2017 08:55 PM, Kartik Patel wrote:
>>
>> Hi Marcus,
>>
>> I was interested in implementing this myself. Sorry for not clarifying.
>> It would be my first time contributing a whole new feature to GNU Radio. I
>> believe, the mentoring should be from someone who is more frequent
>> contributor? If someone is interested in being the mentor to the project,
>> it would be great.
>>
>> I can add to wiki, but I don't have account on redmine. It is waiting to
>> be approved from Admin for a long time.
>>
>> Regards,
>> Kartik Patel
>>
>>
>>
>> On Tue, Feb 7, 2017 1:19 AM, Marcus Müller marcus.muel...@ettus.com
>> wrote:
>>
>> Hi Kartik,
>>
>> sorry, we've all been pretty busy over the Weekend – FOSDEM and stuff.
>>
>> So, I personally think this is a pretty great idea that you should
>> definitely put on the GNU Radio wiki page for GSoC ideas – if someone has a
>> great idea how to improve what you're proposing, it's a wiki for a reason –
>> so frankly, go for it. Notice that it'd be awesome if you putting this on
>> the page also meant that you'd agree to at least partially mentor the
>> student that picks that topic!
>>
>> Best
>>
>> On 02/06/2017 08:26 PM, Kartik Patel wrote:
>>
>> Hello all,
>>
>> Any discussion over statistical toolbox?
>>
>> Thank you.
>>
>> Regards,
>> Kartik Patel
>>
>>
>>
>> On Wed, Feb 1, 2017 1:32 AM, Kartik Patel kartikpatel1...@gmail.com
>> wrote:
>>
>> Hi Marcus,
>>
>> Sorry for replying late. I was travelling.
>>
>> My point is we can have a statistical module for GNU Radio. Although
>> Scipy has extensive library available, we can have it's wrappers for GNU
>> Radio. We can use those wrappers in GRC. Basically, all major statistical
>> analysis can be done at GRC level instead of going to the python/c++
>> backend.
>&g

Re: [Discuss-gnuradio] Gr-Inspector Install error

[Ben Hilburn]

Hi Tellrell -

It looks like your `gr-inspector` OOT module isn't getting found by GNU
Radio. How did you install it? Are you using PyBOMBS? Are you sure you
installed it into the same directory as GNU Radio?

Cheers,
Ben

On Tue, Feb 7, 2017 at 3:51 PM, Tellrell White  wrote:

> I'm running the live_signal_detection. I replaced the rtlsdr_source block
> with a signal source block. When I run the flowgraph I get
>
> "attributerror: Module object has no attribute
> 'signal_detector_cvf"
>
> I tried deleting and reinstalling all the dependencies before installing
> gr-inspector but I'm getting the same result.
>
> Regards
> Tellrell White
>
>
> On Tuesday, February 7, 2017 7:53 AM, Christopher Richardson <
> chrisrichardso...@gmail.com> wrote:
>
>
> Hi Tellrell,
>
> Which flow graph are you running?
>
> Cheers
> Chris
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code -- Ideas List!

[Ben Hilburn]

Hi Kartik -

Thanks for getting involved! There actually already was an HTML-based GRC
on the ideas list, so I combined the new one you created with the existing
one. I also made some minor edits to your Stastical Toolbox idea, and added
my name as a Mentor.

Cheers,
Ben

On Thu, Feb 9, 2017 at 5:31 AM, Kartik Patel 
wrote:

> Hello everyone,
>
> The two of the ideas (1. statistical toolbox, 2. HTML based GRC) have been
> added in the GSoC Idea wiki page.
>
> Please review it and suggest any updates on *wiki*.
>
> Thank you.
>
> Regards,
> Kartik Patel
>
>
>
> On Tue, Feb 7, 2017 8:24 PM, Marcus Müller marcus.muel...@ettus.com wrote:
>
>> Hi Kartik,
>>
>> ha! Sorry for mixing this up. Yes, in that case, you'd be the GSoC
>> participant, not the mentor :)
>>
>> I've pinged the right people. Hopefully we can get your account going.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 02/06/2017 08:55 PM, Kartik Patel wrote:
>>
>> Hi Marcus,
>>
>> I was interested in implementing this myself. Sorry for not clarifying.
>> It would be my first time contributing a whole new feature to GNU Radio. I
>> believe, the mentoring should be from someone who is more frequent
>> contributor? If someone is interested in being the mentor to the project,
>> it would be great.
>>
>> I can add to wiki, but I don't have account on redmine. It is waiting to
>> be approved from Admin for a long time.
>>
>> Regards,
>> Kartik Patel
>>
>>
>>
>> On Tue, Feb 7, 2017 1:19 AM, Marcus Müller marcus.muel...@ettus.com
>> wrote:
>>
>> Hi Kartik,
>>
>> sorry, we've all been pretty busy over the Weekend – FOSDEM and stuff.
>>
>> So, I personally think this is a pretty great idea that you should
>> definitely put on the GNU Radio wiki page for GSoC ideas – if someone has a
>> great idea how to improve what you're proposing, it's a wiki for a reason –
>> so frankly, go for it. Notice that it'd be awesome if you putting this on
>> the page also meant that you'd agree to at least partially mentor the
>> student that picks that topic!
>>
>> Best
>>
>> On 02/06/2017 08:26 PM, Kartik Patel wrote:
>>
>> Hello all,
>>
>> Any discussion over statistical toolbox?
>>
>> Thank you.
>>
>> Regards,
>> Kartik Patel
>>
>>
>>
>> On Wed, Feb 1, 2017 1:32 AM, Kartik Patel kartikpatel1...@gmail.com
>> wrote:
>>
>> Hi Marcus,
>>
>> Sorry for replying late. I was travelling.
>>
>> My point is we can have a statistical module for GNU Radio. Although
>> Scipy has extensive library available, we can have it's wrappers for GNU
>> Radio. We can use those wrappers in GRC. Basically, all major statistical
>> analysis can be done at GRC level instead of going to the python/c++
>> backend.
>>
>> There are some fundamental statistical tools (can be extended with
>> suggestions from community): 1. generation of RV, 2. various distributions
>> and distribution fitting, 3. regressions 4. hypothesis testing (including
>> non-parametric testing which basically check whether current samples
>> matches a particular distribution or not) 5. parameter estimations. We will
>> need various distributions/functions from Scipy.
>>
>> So, consider a scenario where we have a block of "random variable
>> generators" which will get input from a block called "distribution" which
>> will specify the distribution as well as it's parameters.
>> There can be another block for "distribution fitting". Which will take
>> two inputs: vector of samples and input from "distribution" block.
>> Consider a hypothesis testing scenario: Get a input vector: Provide a
>> condition of testing (like energy of vector should be greater than some
>> value).
>> Consider a testing mechanism where we test whether a sample vector is
>> taken from a distribution or not (aka non-parametric goodness-of-fit based
>> testing): It may take input from a "distribution block" and set of samples.
>> and based on value of some "false alarm probability", it will give the
>> decision.
>>
>> We can try to make these testing completely generic. Like, you can write
>> whole equation in textbox in GRC (may be. need to see how can we do it).
>> It's similar to some blocks in Simulink (not sure exactly which one, but I
>> remember those).
>>
>> Note1: the "distribution" block will provide a distribution object. It
>> may work internally, or externally. That's debatable.
>> Note2: This is a idea. We can discuss on various implementation
>> approaches once the scope of project etc are discussed.
>>
>> Regards,
>> Kartik Patel
>>
>>
>>
>> On Thu, Jan 26, 2017 11:51 PM, Marcus Müller marcus.muel...@ettus.com
>> wrote:
>>
>> Hi Kartik,
>>
>> I heartily agree with you, you need a lot of random variables, but the
>> question is: in which shape?
>>
>> Do you need the noise source to produce more different types of amplitude
>> distributions? Do you need those in the channel models?
>>
>> "Blocks for hypothesis testing" sounds pretty interesting. Can you flesh
>> out that idea a little more? In my head, I'm not sure what a 

Re: [Discuss-gnuradio] Want Gnu Radio work done. What is the best platform?

[Ben Hilburn]

Hi Booth -

Contract GNU Radio development is not uncommon, and there are a number of
talented folks that provide such services. I've heard of GNU Radio-related
jobs getting posted to freelance sites like the ones you mentioned, but
have never seen them nor recommended them myself.

That said, to land someone's time you'll want to provide significantly more
detail about the job itself. Your welcome to either try one of the
freelancing sites, post more details here to the gnuradio-discuss list, or
e-mail me directly to try and find available contractors.

Cheers,
Ben

On Thu, Feb 9, 2017 at 7:55 AM, Booth  wrote:

> Dear All, We have just purchased an USRP N210 device and want to test
> several devices with it. GNU Radio is the perfect toolfor that. As we don't
> want to waste time and have the budget we decided to purchase an extensible
> and comprehensive modem design. Which platform is the best for getting this
> job done. Freelance sites like freelancer, upwork, guru.com ? Please
> advice. As for the design; An extensible modem design supporting modulation
> types like FM/ PM/ PSK/ QAM Upto 10Mbps bit rates PRBS generation, BER
> measurements FFT Constellation display Ethernet-File Input Output Framing
> deframing like HDLC CCSDS Scrambling descrambling Etc... We believe all the
> components of the requested design are built in or present as OOT modules.
> --
> View this message in context: Want Gnu Radio work done. What is the best
> platform?
> 
> Sent from the GnuRadio mailing list archive
>  at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee802_15_4 swig import error

[Ben Hilburn]

You should never see "S"s, which indicate sequence errors

in
the UHD  driver (not GNU Radio). You'll want to solve that problem before
trying to use gr-ieee802_15_4, I think.

Have you gone through the system configuration process for the X310
, especially the
MTU settings? Do you see sequence errors if you just use the
`benchmark_rate` example in UHD or other GNU Radio applications?

Cheers,
Ben

On Mon, Jan 23, 2017 at 5:53 PM, Doublele 96 
wrote:

> Updating path did not resolve the issue. I uninstalled the module,
> installed swig2.0 (sudo apt install swig2.0) and rebuilt and reinstalled
> the module. That resolved the issue. Thanks for the quick response!
>
> Also, do you know what is the idea sample rate(s) for running this on USRP
> X310? Getting a lot of "S" and "U"s at 32MHz as well as smaller sample
> rates (3.2MHz and 1MHz).
>
> Thanks!
>
> On Mon, Jan 23, 2017 at 4:13 PM, Bastian Bloessl 
> wrote:
>
>> Hi,
>>
>>
>> On 23 Jan 2017, at 20:21, Doublele 96 
>> wrote:
>>
>> import ieee802_15_4
>>
>> File "/usr/local/lib/python2.7/dist-packages/ieee802_15_4/__init__.py",
>> line 17, in 
>>
>> from ieee802_15_4_swig import *
>>
>> ImportError: No module named ieee802_15_4_swig
>>
>>
>> Please assert that you have updated your PYTHONPATH to include the folder
>> where you installed the python module.
>>
>> If the path is already correct, there might be a problem when the shared
>> library is loaded. Such errors are sometimes hidden by a ‘except
>> ImportError’ block.
>> In that case change ieee802_15_4_swig.py to print the error.
>>
>> Best,
>> Bastian
>>
>
>
> ___
> 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] PyBombs installation issue

[Ben Hilburn]

Hi Usman -

Give the source build
 a shot and
see what components it configures during the `cmake` process. Try to
install the dependencies from
your OS's package manager if you don't have them, yet.

Cheers,
Ben

On Tue, Jan 24, 2017 at 1:02 AM, Usman Haider 
wrote:

> Hi,
>
> What is recommend to fix the issue? Should I go for source install instead
> of PyBombs?
>
>
> --
> Usman
>
>
> On Fri, Jan 20, 2017 at 10:58 AM, Usman Haider 
> wrote:
>
>> Hi Martin,
>>
>> I see from output of the command that a lot of components are disabled.
>>
>> -- ##
>> -- # Gnuradio disabled components
>> -- ##
>> --   * python-support
>> --   * doxygen
>> --   * sphinx
>> --   * gr-ctrlport
>> --   * gnuradio-companion
>> --   * gr-comedi
>> --   * gr-utils
>> --   * gr-video-sdl
>> --   * gr-wxgui
>>
>> Looking further I found that PyBombs was unable to find SWIG as well. I
>> remember that PyBombs install all the required dependencies itself? Do I
>> have to reinstall everything from scratch? Following is the output of the
>> command
>> $ pybombs -vv rebuild gnuradio
>>
>>  http://pasted.co/9ebaa709
>>
>> Thanks.
>>
>> --
>> Usman
>>
>> On Thu, Jan 19, 2017 at 10:25 PM, Martin Braun 
>> wrote:
>>
>>> It did not install GRC, and no other graphical tools either. Rerun
>>>
>>> $ pybombs -vv rebuild gnuradio
>>>
>>> to see where it fails during cmake.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 01/18/2017 10:35 PM, Usman Haider wrote:
>>> > Hi Martin,
>>> >
>>> > Yeah. Please find below the output
>>> >
>>> > $ ls ~/rfnoc/bin
>>> >
>>> > gnuradio-config-info
>>> > uhd_cal_tx_iq_balance
>>> >  usrp2_card_burner
>>> > octoclock_firmware_burner
>>> > uhd_config_info
>>> >  usrp_n2xx_simple_net_burner
>>> > rfnocmodtool
>>> > uhd_find_devices
>>> >   usrp_x3xx_fpga_burner
>>> > thrift
>>> >  uhd_image_loader
>>> >  volk-config-info
>>> > uhd_cal_rx_iq_balance
>>> >   uhd_images_downloader
>>> > volk_modtool
>>> > uhd_cal_tx_dc_offset
>>> > uhd_usrp_probe
>>> >   volk_profile
>>> >
>>> > $ pybombs inv
>>> >
>>> > PyBOMBS - INFO - PyBOMBS Version 2.3.1a
>>> > Showing package state:
>>> > uhd-fpga:   installed
>>> > uhd:installed
>>> > apache-thrift:  installed
>>> > gnuradio:   installed
>>> > gr-ettus:   installed
>>> >
>>> >
>>> > You get anything from this?  Thanks
>>> >
>>> > --
>>> > Usman
>>> >
>>> > On Thu, Jan 19, 2017 at 5:15 AM, Martin Braun >> > > wrote:
>>> >
>>> > It's almost as if UHD installed, but GNU Radio didn't, although
>>> your
>>> > output says otherwise.
>>> >
>>> > What does
>>> >
>>> > $ ls ~/rfnoc/bin
>>> >
>>> > look like?
>>> >
>>> > Or
>>> >
>>> > $ pybombs inv
>>> >
>>> > ?
>>> >
>>> > On 01/18/2017 02:10 AM, Usman Haider wrote:
>>> > > Hi Nicolas,
>>> > >
>>> > > Thanks for your time. I did that but the result is same. I can
>>> run
>>> > >
>>> > > |$|uhd_images_downloader
>>> > > but
>>> > > |$ gnuradio-companion
>>> > > |
>>> > >
>>> > > fails. Let me know if any further information is needed. Thanks
>>> > >
>>> > > --
>>> > > Usman
>>> > > On Wed, Jan 18, 2017 at 2:11 PM, Nicolas Cuervo
>>> > > 
>>> > >> >>>
>>> > wrote:
>>> > >
>>> > > Hello Usman,
>>> > >
>>> > > Did you set up your PyBOMBS environment?  If not, please do
>>> so. As
>>> > > long as I understand your prefix is at ~/rfnoc. Being that
>>> the case,
>>> > > please run:
>>> > >
>>> > > $ source ~/rfnoc/setup_env.sh
>>> > >
>>> > > After this your shell will have access to everything which
>>> has been
>>> > > installed in that prefix, and you should be able to start
>>> > > gnuradio-companion. Please have in mind that you have to set
>>> up this
>>> > > environment in every new shell you start.
>>> > >
>>> > > Please let us know if this doesn't work so that we can look
>>> further
>>> > > into it.
>>> > >
>>> > > Cheers,
>>> > >
>>> > > - Nicolas
>>> > >
>>> > > On Wed, Jan 18, 2017 at 9:58 AM, Usman Haider
>>> > > 
>>> > >>
>>> > wrote:
>>> > >
>>> > > Yes, could be the cause.  After running the following
>>> commands
>>> > >
>>> > > $ cd ~/rfnoc
>>> > > $ source ./setup_env.sh
>>> > > $ 

Re: [Discuss-gnuradio] gr-inspector example `amc_cnn` fails

[Ben Hilburn]

Hey Chris -

What is the `TF AMC Model` block expecting, exactly, in the "Graph File"
field? Based on the earlier discussion, my understanding is that the block
needs not just the graph file, but also the weights.

A different way to ask the question, perhaps, is how are you writing your
trained models to disk so that you can then use them from within this block?

Cheers,
Ben

On Sat, Jan 7, 2017 at 5:34 AM, Christopher Richardson <
chrisrichardso...@gmail.com> wrote:

> Hi Ben,
>
> Yeah with respect to the shifts, that was just to do with the Python
> flowgraph where I generated the training data for the CNN model in my
> cnn_generate.py script.  I notice the generation code for RadioML is now
> available https://github.com/radioML/dataset :)
>
> I'm currently trying to find out why Keras & TensorFlow Serving, no longer
> seem to be saving the model in the same way as before, as I get an error
> message when
> loading the model via the amc_cnn graph:
>
> """
> handler caught exception: Attempting to use uninitialized value
> convolution2d_1_W_1
>  [[Node: convolution2d_1_W_1/read = Identity[T=DT_FLOAT,
> _class=["loc:@convolution2d_1_W_1"], _device="/job:localhost/
> replica:0/task:0/cpu:0"](convolution2d_1_W_1)]]
>
> Caused by op u'convolution2d_1_W_1/read', defined at:
> """
>
> Yeah I think that's a good idea adding notes in the flow graph.  I'll just
> try to solve the loading issue, then I'll do that.
>
> Cheers
>
> Chris
>
>
>
>
> On Sat, Jan 7, 2017 at 2:14 AM, Ben Hilburn <bhilb...@gnuradio.org> wrote:
>
>> Hey Chris -
>>
>> Thanks for the guidance! With Tim O'Shea's help, I was able to create &
>> train the TensorFlow model in the RadioML repository. I noticed that you
>> made an update to the README steering folks away from the CNN model, for
>> the moment:
>>
>> Please use the FAM model at the moment, I'm just tweaking the CNN model,
>> as I need to implement 64 sample shifts.
>>
>>
>> I'm assuming that refers to the CNN model in your repository (
>> https://github.com/chrisruk/models), and not CNN models, generally? I'm
>> going to give the `amc_cnn` flowgraph another shot with my newly trained
>> CNN as soon as I get the chance.
>>
>> Once I get everything up and running and have a better understanding of
>> how it works, I'd like to create some more documentation about how to get
>> this up and running. Your (and Sebastian's) work in `gr-inspector` is not
>> only really impressive but also timely & very useful, and I want to make it
>> accessible to as many people as possible. Even some small notes in the
>> flowgraph about needing a trained model would be helpful, as right now this
>> example relies on the user just knowing that's a necessary prerequisite.
>>
>> I'll keep you posted on my progress =)
>>
>> Cheers,
>> Ben
>>
>>
>>
>> On Fri, Jan 6, 2017 at 5:24 AM, Christopher Richardson <
>> chrisrichardso...@gmail.com> wrote:
>>
>>> Hi Ben,
>>>
>>> I just found this awesome example in the RadioML repo
>>> https://github.com/radioML/examples/blob/master/modulation_r
>>> ecognition/RML2016.10a_VTCNN2_example.ipynb
>>>
>>> Which I'd not seen before, I'll update my CNN model generation to make
>>> sure it creates the model in the same way as that.
>>>
>>> (Sorry if you get this mail twice Ben, I forgot to hit reply to all
>>> first time)
>>>
>>> Cheers
>>> Chris
>>>
>>> On Fri, Jan 6, 2017 at 12:21 AM, Christopher Richardson <
>>> chrisrichardso...@gmail.com> wrote:
>>>
>>>> Hi Ben
>>>>
>>>> I think it looks like you haven't generated the model, if I'm
>>>> understanding correctly, for the GRC file.
>>>>
>>>> At the moment the code to generate the models is at:
>>>> https://github.com/chrisruk/models
>>>>
>>>> Tomorrow I'll check that the model generation works with the latest
>>>> version of TensorFlow for you.
>>>>
>>>> If anyone has experience with Keras, I'd love to have someone have a
>>>> look over of the correctness of the models,
>>>> as I seem to have lower accuracy with the Keras models, than when they
>>>> where implemented with TFLearn if I recall
>>>> correctly, which is very odd.
>>>>
>>>> Cheers
>>>> Chris
>>>>
>>>>
>>>> On Thu, Jan 5, 2017 at 9:45 PM, Ben

Re: [Discuss-gnuradio] gr-inspector example `amc_cnn` fails

[Ben Hilburn]

Hey Chris -

Thanks for the guidance! With Tim O'Shea's help, I was able to create &
train the TensorFlow model in the RadioML repository. I noticed that you
made an update to the README steering folks away from the CNN model, for
the moment:

Please use the FAM model at the moment, I'm just tweaking the CNN model, as
I need to implement 64 sample shifts.


I'm assuming that refers to the CNN model in your repository (
https://github.com/chrisruk/models), and not CNN models, generally? I'm
going to give the `amc_cnn` flowgraph another shot with my newly trained
CNN as soon as I get the chance.

Once I get everything up and running and have a better understanding of how
it works, I'd like to create some more documentation about how to get this
up and running. Your (and Sebastian's) work in `gr-inspector` is not only
really impressive but also timely & very useful, and I want to make it
accessible to as many people as possible. Even some small notes in the
flowgraph about needing a trained model would be helpful, as right now this
example relies on the user just knowing that's a necessary prerequisite.

I'll keep you posted on my progress =)

Cheers,
Ben



On Fri, Jan 6, 2017 at 5:24 AM, Christopher Richardson <
chrisrichardso...@gmail.com> wrote:

> Hi Ben,
>
> I just found this awesome example in the RadioML repo
> https://github.com/radioML/examples/blob/master/modulation_
> recognition/RML2016.10a_VTCNN2_example.ipynb
>
> Which I'd not seen before, I'll update my CNN model generation to make
> sure it creates the model in the same way as that.
>
> (Sorry if you get this mail twice Ben, I forgot to hit reply to all first
> time)
>
> Cheers
> Chris
>
> On Fri, Jan 6, 2017 at 12:21 AM, Christopher Richardson <
> chrisrichardso...@gmail.com> wrote:
>
>> Hi Ben
>>
>> I think it looks like you haven't generated the model, if I'm
>> understanding correctly, for the GRC file.
>>
>> At the moment the code to generate the models is at:
>> https://github.com/chrisruk/models
>>
>> Tomorrow I'll check that the model generation works with the latest
>> version of TensorFlow for you.
>>
>> If anyone has experience with Keras, I'd love to have someone have a look
>> over of the correctness of the models,
>> as I seem to have lower accuracy with the Keras models, than when they
>> where implemented with TFLearn if I recall
>> correctly, which is very odd.
>>
>> Cheers
>> Chris
>>
>>
>> On Thu, Jan 5, 2017 at 9:45 PM, Ben Hilburn <bhilb...@gnuradio.org>
>> wrote:
>>
>>> Hey all -
>>>
>>> I'm trying to get some of the tensorflow gr-inspector examples up and
>>> running, and running into a few hiccups (note that the non-tensorflow
>>> flowgraps work fine). I'm using the non-GPU version of tensorflow (`$ sudo
>>> pip install tensorflow`) as I don't have an nVidia GPU.
>>>
>>> With the `amc_cnn` example, I was first getting the following error:
>>>
>>> RuntimeError: Expected meta graph file missing
>>> /tmp/cnn/0001/export.meta
>>>
>>> Not really being sure what that was, I created the `/tmp/cnn/0001/`
>>> directory, touched the `export.meta` file, and moved on (this may have been
>>> my first mistake).
>>>
>>> Anyway, it gets a bit further, but dies with this:
>>>
>>> Executing: /usr/bin/python2 -u /home/bhilburn/code/gnuradio/g
>>> r-inspector.git/examples/top_block.py
>>>
>>> Traceback (most recent call last):
>>>   File 
>>> "/home/bhilburn/code/gnuradio/gr-inspector.git/examples/top_block.py",
>>> line 139, in 
>>> main()
>>>   File 
>>> "/home/bhilburn/code/gnuradio/gr-inspector.git/examples/top_block.py",
>>> line 127, in main
>>> tb = top_block_cls()
>>>   File 
>>> "/home/bhilburn/code/gnuradio/gr-inspector.git/examples/top_block.py",
>>> line 75, in __init__
>>> self.inspector_tfmodel_vcf_0 = inspector.tfmodel_vcf("complex
>>> 64",128,'/tmp/cnn/0001',(),0)
>>>   File 
>>> "/home/bhilburn/usr/lib64/python2.7/site-packages/inspector/tfmodel_vcf.py",
>>> line 64, in __init__
>>> sess, inp, out,classes = self.load_graph(graphfile)
>>>   File 
>>> "/home/bhilburn/usr/lib64/python2.7/site-packages/inspector/tfmodel_vcf.py",
>>> line 88, in load_graph
>>> signatures_any[0].Unpack(signatures)
>>>   File 
>>> "/usr/lib/python2.7/site-packages/google/protobuf/internal/containers.py",
>>> line 204, in __getitem__
>>> return self._values[key]
>>> IndexError: list index out of range
>>>
>>>
>>> Any ideas / pointers?
>>>
>>> Cheers,
>>> Ben
>>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-inspector example `amc_cnn` fails

[Ben Hilburn]

Hey all -

I'm trying to get some of the tensorflow gr-inspector examples up and
running, and running into a few hiccups (note that the non-tensorflow
flowgraps work fine). I'm using the non-GPU version of tensorflow (`$ sudo
pip install tensorflow`) as I don't have an nVidia GPU.

With the `amc_cnn` example, I was first getting the following error:

RuntimeError: Expected meta graph file missing /tmp/cnn/0001/export.meta

Not really being sure what that was, I created the `/tmp/cnn/0001/`
directory, touched the `export.meta` file, and moved on (this may have been
my first mistake).

Anyway, it gets a bit further, but dies with this:

Executing: /usr/bin/python2 -u
/home/bhilburn/code/gnuradio/gr-inspector.git/examples/top_block.py

Traceback (most recent call last):
  File
"/home/bhilburn/code/gnuradio/gr-inspector.git/examples/top_block.py", line
139, in 
main()
  File
"/home/bhilburn/code/gnuradio/gr-inspector.git/examples/top_block.py", line
127, in main
tb = top_block_cls()
  File
"/home/bhilburn/code/gnuradio/gr-inspector.git/examples/top_block.py", line
75, in __init__
self.inspector_tfmodel_vcf_0 =
inspector.tfmodel_vcf("complex64",128,'/tmp/cnn/0001',(),0)
  File
"/home/bhilburn/usr/lib64/python2.7/site-packages/inspector/tfmodel_vcf.py",
line 64, in __init__
sess, inp, out,classes = self.load_graph(graphfile)
  File
"/home/bhilburn/usr/lib64/python2.7/site-packages/inspector/tfmodel_vcf.py",
line 88, in load_graph
signatures_any[0].Unpack(signatures)
  File
"/usr/lib/python2.7/site-packages/google/protobuf/internal/containers.py",
line 204, in __getitem__
return self._values[key]
IndexError: list index out of range


Any ideas / pointers?

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

[Discuss-gnuradio] Call for GRCon17 Committee Volunteers

[Ben Hilburn]

Hey all!

With the new year, it's time to really kick off GRCon17 planning. GRCon16
had a record (and sold-out) turn-out, and 94.6% of attendees who responded
to the survey gave the event a 4/5 or 5/5 overall rating. We are looking
forward to an even better GRCon17.

Planning GRCon is a significant undertaking, and is only possible each year
because of our community volunteers. You can volunteer at a variety of
levels, taking on whatever responsibilities your time & availability
affords. It's a great experience, and a good opportunity to get more deeply
involved with the GNU Radio project & community.

If you are interested in joining the GRCon17 Committee, or have any
questions, please let me (Ben) know!

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

[Discuss-gnuradio] Hello, 2017!

[Ben Hilburn]

Hi all -

Happy New Year! Last year was a great year for the GNU Radio project, and I
think 2017 is going to be even better. We got a lot of key infrastructure
work done in 2016 (and I'm not talking about just code), and as a result we
are very well situated to knock out our goals over the next year.

Johnathan and I will be sharing more details over the next couple of weeks
about both on-going and new efforts, as well as sharing some general
updates about a lot of the behind-the-scenes stuff that we finished up late
last year. I do have a few items to share now, though:

*FOSDEM & DARPA Hackfest Reminder*
The schedule has been set for the SDR Dev Room at FOSDEM `17, and it's a
great lineup. If you can make it, let us know that you'll be there so we
know to look for you! I also want to acknowledge the organizers of the dev
room, whom are well-known GNU Radio developers: Martin Braun, Philip
Balister, and Sylvain Munaut.

   - FOSDEM 2017: https://fosdem.org/2017/
   - SDR Dev Room:
   https://fosdem.org/2017/schedule/track/software_defined_radio/

Also, don't forget that Tom Rondeau (former lead of the GNU Radio project,
now a DARPA PM), is running a DARPA-sponsored hackfest for the three days
leading up to FOSDEM. I'm really excited to see how GNU Radio is used by
the participants, and hope to see you there!

   - DARPA Hackfest:

http://www.cvent.com/events/darpa-mto-hackfest-brussels/event-summary-c64f4cd412334d6a93fca4f202378188.aspx
   


*Call for Blog Posts*
We closed out 2016 with some great posts on the GNU Radio blog, and I would
like to keep the trend going. The GNU Radio website gets between 800-1000
unique hits on most weekdays, so it's a great venue for sharing your work
and ideas. If you're interested in writing up something, please let me know!

   - GNU Radio blog: http://gnuradio.org/blog/

*Reminder for January Call*
The GNU Radio Project call is on January 19th! Mark your calendars.

   - http://gnuradio.org/events/

*Get Involved!*
One of the topics that came up a couple of times at GRCon16 was that it can
be hard to know where to start if you want to contribute back to the
project. While there is some documentation about this on the Redmine site,
we are working on putting together new, more comprehensive, content. Until
that's ready, if you want to get involved and aren't sure how, just let me
know! We welcome anyone who wants to contribute, and you don't need to be
an expert to make a big impact.

It's a great time for the project, I'm really looking forward to the coming
year. As usual, please reach out to me if you have any questions,
suggestions, or good jokes, and keep an eye out for more updates soon!

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

Re: [Discuss-gnuradio] Reminder: Dev Call Tomorrow Thu 15 Dec

[Ben Hilburn]

Minor correction: should have read 1800 UTC.

Cheers,
Ben

On Wed, Dec 14, 2016 at 12:37 PM, Ben Hilburn <bhilb...@gnuradio.org> wrote:

> Hi all -
>
> This is just a reminder that tomorrow is our monthly Dev Call! The Dev
> Call takes place at 1700 UTC / 1300 Eastern / 1000 Pacific.
>
> Information about how to join or watch the livestream is available here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls
>
> Thanks, and as usual, please let us know if you have any questions!
>
> Cheers,
> Ben
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reminder: Dev Call Tomorrow Thu 15 Dec

[Ben Hilburn]

Right now it's UTC-7 =)

Cheers,
Ben

On Wed, Dec 14, 2016 at 12:37 PM, Ben Hilburn <bhilb...@gnuradio.org> wrote:

> Hi all -
>
> This is just a reminder that tomorrow is our monthly Dev Call! The Dev
> Call takes place at 1700 UTC / 1300 Eastern / 1000 Pacific.
>
> Information about how to join or watch the livestream is available here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls
>
> Thanks, and as usual, please let us know if you have any questions!
>
> Cheers,
> Ben
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

[Ben Hilburn]

Marcus didn't mention this in his e-mail, but I wanted to bring attention
to it, again:

CCERA is trying to raise money to support their efforts through a
crowdfunding campaign, which you can find here:
https://www.gofundme.com/help-make-the-ccera-a-reality-2tvbzx8?rcid=cc4b75bc902911e6adacbc764e05b494

Everyone on this list knows Marcus' name, and more than likely has received
support from him at some point. If you are able, I encourage you to support
his efforts in open source radio astronomy =)

Cheers,
Ben

On Thu, Dec 1, 2016 at 3:57 PM,  wrote:

> Effective integration time was about 40 minutes.
>
> The beamshape is roughly 42 x 18 degrees from our array antenna.
>
>
>
>
>
>
> On 2016-12-01 15:54, Daniel R. Marlow wrote:
>
> Hello,
>
>
>
>   First, congrats to Marcus and CCERA.
>
>
>
>   We are working at 21 cm (1420 MHz) and find that there are at least
> a few pulsars not that far below B0329+54 (now called J0332+5434) in signal
> strength. Indeed, one of the interesting things is that owing to
> scintillation effects, there are times when this pulsar is not as bright as
> some of the pulsars. Of course, when this pulsar is at its best, the
> signal really is quite strong: we get a good detection after just a few
> turns using a 60' dish and 50 MHz of BW.
>
>
>
>A question . . . roughly what was the integration time for the plot
> that you showed?
>
>
>
> Sincerely,
> Dan Marlow
>
>
>
>
>
> *From: *Discuss-gnuradio  princeton@gnu.org> on behalf of "mle...@ripnet.com"  >
> *Date: *Thursday, December 1, 2016 at 3:41 PM
> *To: *"Iain Young, G7III" 
> *Cc: *Discuss-gnuradio ,
> "discuss-gnuradio@gnu.org" 
> *Subject: *Re: [Discuss-gnuradio] Probable pulsar observing success at
> CCERA
>
>
>
> Keep in mind also that B0329+54 is really the only one within reasonable
> "reach" for an amateur in the northern hemisphere--the others are much
> fainter, although if one simply added another "gulp" of antenna every
> paycheque or two...
>
> Also, you need a stable clock--I'm using an OCXO, but a TCXO will work for
> shorter observing times.  So, if you are using a dongle, you'll need to
> replace its clock.
>
>
>
>
>
>
>
>
>
> On 2016-12-01 15:19, Iain Young, G7III wrote:
>
> Hi Marcus,
>
> Brilliant. I am in the middle of assembling my own radio telescope,
> but had not thought Pulsar reception would be possible.
>
> I have a couple of questions on the RF Hardware. I see from some other
> updates, that the antenna is essentially sets of a 4 bay HDTV antenna.
>
> How are you phasing them all together ? Just additive combiners with
> same length coax ? What amplification are you using before feeding
> them to the SDR ? Or ?
>
>
> Best Regards
>
> Iain
>
> On 01/12/16 18:45, Marcus D. Leech wrote:
>
> One of the many goals we set for ourselves at the Canadian Centre for
> Experimental Radio Astronomy was to successfully observe
>pulsar B0329+54 before spring.  This pulsar is the only one bright
> enough for a small observatory in the northern hemisphere to
>observe.
>
> See our update:
>
> http://www.ccera.ca/uncategorized/success-in-observing-pulsar-b032954/
>
> The software is available via github:
>
> https://github.com/ccera-astro/pulsar_pfb _display
>
> No custom blocks required--just a modern Gnu Radio install, and ideally,
> pyephem.
>
> Doing this with Gnu Radio was so very easy...
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio