GNU Radio, One Step at a Time: June 2017

Friday, June 30, 2017

Re: [Discuss-gnuradio] Convert recorded FM wav file to I,Q values

On 06/28/2017 10:55 PM, Jahnavendra Mattipa wrote:
> Hello all,
> Is there any possibility to convert the recorded FM 'wav' file to I,Q
> values, if possible please tell me how to do this?

Well it depends upon what you mean by 'wav' file.

For a real valued signal with constant amplitude - my guess as to what
you mean, namely

Acos(wt+phi)

use the trigonometric identity

cos(wt+phi)=cos(wt)cos(phi)-sin(wt)sin(phi)

- which is easy to derive from complex exponentials.

Then set

I=Acos(phi)
Q=Asin(phi)

Hence

Acos(wt+phi)=Icos(wt)-Qsin(wt)

-- Cinaed

>
>
> Best reagards,
> M. Jahnvendra
>
>
> _______________________________________________
> 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] Change value of a Variable defined in the flowgraph from a block

Hi everyone.

I created a variable in the flowgraph called freq_Tx.

This is assigned as the central freq of the block USRP source and is used by several blocks to do signal processing.

I need to listen two different frequencies in my application. For example one minute, 2.4 GHz and other minute 2.5GHz, depending of a specific logic. How can I, from a block, modify this variable? I mean, something like

set_freq_Tx(new value)

In this moment i'm doing it through a QT GUI RANGE, but i need to set it automatically, then I think it must be a variable in the flowgraph, but I don't know if it can be modified from a block in the flowgraph.

Do you think is it possible?

If yes, may anyone please shares me a reference page or an example.

If not, my other option is to create the variable in my block, send it as an input to the blocks which use it, and to the USRP as a command. But it looks longer in time.

Thanks in advance.

Best regards,

Cristian

Re: [Discuss-gnuradio] dBm and dB Measurements

GNU Beginner,

this is getting stupid. I've told you repeatedly NOT to use Nabble,
because it is a very bad mailing list frontend.

Please subscribe directly to the mailing list under
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio .

Best regards,

Marcus

On 30.06.2017 20:30, GNUBeginner wrote:
> <http://gnuradio.4.n7.nabble.com/file/n64430/Measurements-1.jpg>
>
> I have tried to attach a table as a jpg file and hope that it works.
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/dBm-and-dB-Measurements-tp64413p64430.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] dBm and dB Measurements

<http://gnuradio.4.n7.nabble.com/file/n64430/Measurements-1.jpg>

I have tried to attach a table as a jpg file and hope that it works.

--
View this message in context: http://gnuradio.4.n7.nabble.com/dBm-and-dB-Measurements-tp64413p64430.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] How to receive a finite number of samples at a future time using UHD/GNURadio?

Hi Eric,

this mail kind of fell through the cracks. Have you found a solution to this, yet?

It's not overly clear from the documentation, but the finite_acquisition method really bypasses parts of what you configure as behaviour for the USRP_source. So, ok, that won't work.

The second one might be slightly off, syntaxwise. You'll need to create a stream_cmd_t (of the right type), not use one of the type constant fields of stream_cmd_t (just as you do in the next approach).

The third might work, but really breaks GNU Radio idea of processing streams of samples; so, I'm not 100% sure what is appropriate for you :(

Best regards,

Marcus

On 04/24/2017 09:30 PM, Eric Martin wrote:

I'm using the GNURadio python interface to UHD, and I'm trying to set a specific time to start collecting samples and either collect a specific number of samples or stop the collection of samples at a specific time. Essentially, creating a timed snapshot of samples. This is something similar to the C++ Ettus UHD example 'rx_timed_sample'.

I can get a flowgraph to start at a specific time, but I can't seem to get it to stop at a specific time (at least without causing overflows). I've also tried doing a finite aquisition, which works, but I can't get it to start at a specific time. So I'm kind of lost at what to do next.

Here is my try at the finite acquisition (seems to just ignore the start time and collects 0 samples):

num_samples = 1000

usrp = uhd.usrp_source(

",".join(("", "")),

uhd.stream_args(

cpu_format="fc32",

channels=range(1),

),

)

...

usrp.set_start_time(absolute_start_time)

samples = usrp.finite_acquisition(num_samples)

I've also tried some combinations of following without success (TypeError: in method 'usrp_source_sptr_issue_stream_cmd', argument 2 of type '::uhd::stream_cmd_t const &'):

usrp.set_command_time(absolute_start_time)

usrp.issue_stream_cmd(uhd.stream_cmd.STREAM_MODE_NUM_SAMPS_AND_DONE)

I also tried the following in a flowgraph:

...

usrp = flowgrah.uhd_usrp_source_0

absolute_start_time = uhd.uhd_swig.time_spec_t(start_time)

usrp.set_start_time(absolute_start_time)

flowgrah.start()

stop_cmd = uhd.stream_cmd(uhd.stream_cmd.STREAM_MODE_STOP_CONTINUOUS)

absolute_stop_time = absolute_start_time + uhd.uhd_swig.time_spec_t(collection_time)

usrp.set_command_time(absolute_stop_time)

usrp.issue_stream_cmd(stop_cmd)

For whatever reason the flowgraph one generated overflows consistently for anything greater than a .02s collection time.

I posted this question on stack overflow without any success:

http://stackoverflow.com/questions/43420300/how-to-receive-a-finite-number-of-samples-at-a-future-time-using-uhd-gnuradio

Any help would be greatly appreciated!!

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

Re: [Discuss-gnuradio] Problem processing BLOB type in a new block for IEEE 802-11 transceiver

Hi Cristian,

a blob is not a string.

You MUST NOT

const char *aux = reinterpret_cast<const char *>(pmt::blob_data(blob));
pmt::pmt_t snrf2 = pmt::intern(std::string(aux));

ever. Blob data is *not* zero-terminated and it's absolutely legal to contain the zero byte.

While a std::string might actually contain zero bytes, there's nothing guaranteeing that for the pmt string type. Also: it doesn't really make sense to try and convert something that is not a string to a string type.

So, if your Tx App takes arbitrary data, it shouldn't be consuming PMT strings (which actually come with quite a performance hit, by the way, if used to transport info), and if it actually only accepts strings, then you can't just put arbitrary binary data through it.

Best regards,
Marcus

On 06/30/2017 06:13 PM, Cristian Rodríguez wrote:

Hi all.

I'm trying to convert a variable from BLOB to String.

I'm trying to do this.

Before, the next block was instead of WiFi App.

Message strobe sends a PMT message of STRING type (without car and cdr, just message_port_pub(pmt::mp("strobe"), pmt.intern("12345678")); ), then I need to send from the port Message out a PMT message of STRING type.

But I receive the message in a BLOB type. I was trying all types of methods, but I can't convert from BLOB to String If I send BLOB it doesn't work.

The message comes in the cdr of the PMT, so i tried with different versions of this code

        pmt::pmt_t blob(pmt::cdr(msg));
        const char *aux = reinterpret_cast<const char *>(pmt::blob_data(blob));

        pmt::pmt_t snrf2 = pmt::intern(std::string(aux));
        std::cout << "Es blob " <<std::string(aux)<< std::endl;
        message_port_pub(pmt::mp("message out"), snrf2);

There, i try to convert it to a char and later from char to String, but it doesn't work.

What do you think i can do? What i need is to take de data in BLOB format, convert it to String, save it in a PMT message and send it.

Thanks a lot for your time to read.

Best regards,

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

[Discuss-gnuradio] Problem processing BLOB type in a new block for IEEE 802-11 transceiver

Hi all.

I'm trying to convert a variable from BLOB to String.

I'm trying to do this.

Before, the next block was instead of WiFi App.

Message strobe sends a PMT message of STRING type (without car and cdr, just message_port_pub(pmt::mp("strobe"), pmt.intern("12345678")); ), then I need to send from the port Message out a PMT message of STRING type.

But I receive the message in a BLOB type. I was trying all types of methods, but I can't convert from BLOB to String If I send BLOB it doesn't work.

The message comes in the cdr of the PMT, so i tried with different versions of this code

        pmt::pmt_t blob(pmt::cdr(msg));
        const char *aux = reinterpret_cast<const char *>(pmt::blob_data(blob));

        pmt::pmt_t snrf2 = pmt::intern(std::string(aux));
        std::cout << "Es blob " <<std::string(aux)<< std::endl;
        message_port_pub(pmt::mp("message out"), snrf2);

There, i try to convert it to a char and later from char to String, but it doesn't work.

What do you think i can do? What i need is to take de data in BLOB format, convert it to String, save it in a PMT message and send it.

Thanks a lot for your time to read.

Best regards,

Cristian

[Discuss-gnuradio] [GSoC 2017] gr-bokehgui: Updates on Week 7

Hello all,

This week, I added a Base Sink template class. It will be a common class for all sinks. For more details, check out my latest blog post here.

Thank you.

Regards,

Kartik Patel

ᐧ

[Discuss-gnuradio] FW: Fwd: query about fm example file in github tutorials repository

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

FWIW, I got the aforementioned “fm101.8_1Msps.cfile” to demodulate once I tried using the more generic FM demod block rather than the WBFM receive block. I was using the rational resampler block in both cases to match the audio sink rate (48 kHz) and I did have the ‘Ok to block’ option turned off in the audio sink there too. I do have to go to some trouble to configure the audio for the ArchLinux VM I am using but it does work once I remember to crank up the volume.

So the only change I made was to switch to using the FM demod block and then I could hear the demodulated fm sample file. I note that the FM demod block includes a LPF setting but I assumed that was present in the WBFM receive block? Anyway I was able to use the WBFM receive block successfully to ‘listen to’ FM radio received and streamed by a B200. Just a bit puzzled as to why it didn’t work with the streamed data file.

Regards

Jacqueline

From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jacqueline.walker=ul.ie@gnu.org] On Behalf Of Jacqueline.Walker
Sent: 29 June 2017 20:44
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Fwd: query about fm example file in github tutorials repository

Sent from my HTC

----- Forwarded message -----
From: "Jacqueline.Walker" <Jacqueline.Walker@ul.ie>
To: "Marcus Müller" <marcus.mueller@ettus.com>
Subject: [Discuss-gnuradio] query about fm example file in github tutorials repository
Date: Thu, Jun 29, 2017 8:40 P.M.

OMG, silly me ...it was staring me in the face as I was laboriously typing out the filename!!

Thanks will try that

Regards

Jacqueline

Sent from my HTC

----- Reply message -----
From: "Marcus Müller" <marcus.mueller@ettus.com>
To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] query about fm example file in github tutorials repository
Date: Thu, Jun 29, 2017 6:43 P.M.

Hi Jacqueline,

judging from the file name (_1Msps), the sampling rate is 1 MS/s. When it comes to signal bandwidth – a complex 1MS/s stream can contain up to 1 MHz of bandwidth, but FM broadcast radio stations typically use something like 75 kHz of bandwidth for their FM signal.

Best regards,

Marcus

On 06/29/2017 04:39 PM, Jacqueline.Walker wrote:

Hi,

I downloaded the file fm101.8MHz_1Msps.cfile (from gr-tutorials/examples/tutorial6/ ) to use for trying out demodulation flowgraphs in gnuradio. It was recommended here: https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations

But I can’t find any details about the file – it says on the tutorial page – ‘an actual recording from a radio (USRP I presume) with nothing done to the data, so I presume it is just a binary stream such as one would receive from a USRP and that the centre frequency is 101.8MHz. What is the sample rate output by the USRP that recorded the file – is it 250k as given on the tutorial page? What is the signal bandwidth expected? I ask this because I don’t see that much on the FFT?

Thanks

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

Re: [Discuss-gnuradio] Backoff Counter in IEEE 802.11 impmelemntation

Yes!

Regards,

Marcus

On 06/30/2017 11:26 AM, Ayan Chatterjee wrote:

Hi all,

Can a backoff counter be introduced to this implementation https://github.com/bastibl/gr-ieee802-11 ?

Regards,

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

Re: [Discuss-gnuradio] dBm and dB Measurements

Can you convert the data to a table + 2 graphs (1st: SA level vs. input power, 2nd: SDR level vs. input power)? It will help you and others conclude the relationship between the behaviors

On Thu, Jun 29, 2017 at 11:16 PM GNUBeginner <muratca77@hotmail.com> wrote:

Hello Everyone,

I am using HackRF One and running gr-scan spectrum monitoring software. I am
also utilizing vector signal generator and spectrum analyzer.

Can anyone please help me understand the following measurement results from
both spectrum analyzer (reference level: -20 dBm) and gr-scan?

Spectrum Analyzer: -25 dBm VSG at 2437 MHz -> Peak Power: -47.26 dBm (Almost
no loss since it is one foot cable directly connected to spectrum analyzer
from vector signal generator)

gr-scan: -25 dBm VSG at 2437 MHz -> Peak Power: -47.61 dB

Spectrum Analyzer: -30 dBm VSG at 2437 MHz -> Peak Power: -52.85 dBm (Again,
it is the same...Almost no loss)

gr-scan: -30 dBm VSG at 2437 MHz -> Peak Power: -51.37 dB

Spectrum Analyzer: -35 dBm VSG at 2437 MHz -> Peak Power: -58.22 dBm (Almost
no loss)

gr-scan: -35 dBm VSG at 2437 MHz -> Peak Power: -58.34 dB

Spectrum Analyzer: -40 dBm VSG at 2437 MHz -> Peak Power: -63.21 dBm

gr-scan: -40 dBm VSG at 2437 MHz -> Peak Power: -63.15 dB

Spectrum Analyzer: -45 dBm VSG at 2437 MHz -> Peak Power: -67.63 dBm

gr-scan: -45 dBm VSG at 2437 MHz -> Peak Power: -67.41 dB

I guess there is no relationship between SDR dB values and spectrum analyzer
dBm values but what I have noticed that SDR is linearly following VSG power
increments.

Thanks,

--
View this message in context: http://gnuradio.4.n7.nabble.com/dBm-and-dB-Measurements-tp64413.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Backoff Counter in IEEE 802.11 impmelemntation

Hi all,

Can a backoff counter be introduced to this implementation https://github.com/bastibl/gr-ieee802-11 ?

Regards,

Ayan

[Discuss-gnuradio] [GSoC 17] DAB: Updates of the week

Hi all,

this week is the first evaluation period of Google Summer of Code.

I started to work on my next milestones for the second coding period which mainly contain the audio encoding and decoding.

I also dealt with some buffer issues due to long vectors which lengths are no power of 2 bytes.

Read in detail in my latest blog post.

Best

Luca

[Discuss-gnuradio] lack of clarity regarding "FM wav file" (was: Re: Discuss-gnuradio Digest, Vol 176, Issue 29)

Hi Mattipa,

I know this is kind of annoying, but the first actual line of text in the mail you replied to is:

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."

I'd politely ask you to try and adhere to such advise (as it gets hard to follow conversations if you don't).

In any case, if *you* can't guess what you professor meant, then how are *we* supposed to guess? If in doubt about what a task entails, ask the one who assigned that task to you, not someone on "the internet". We really can't guess what's inside a file you've been given.

Best regards,

Marcus

On 30.06.2017 07:15, Jahnavendra Mattipa wrote:

Please bear my short message below,
I am sorry Mr. Marcus, i know i asked some irrelevant and undefined questions. But this question is not mine, my scientific professor aksed me try to convert the FM wav file to I, Q values if possible. I also confused with that question and searched some papers too but no information regarding this.

Thank you Marcus.

Best Regards,

M. Jahnavendra

On Thu, Jun 29, 2017 at 9:30 PM, <discuss-gnuradio-request@gnu.org> wrote:

Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."

Today's Topics:

1. gr-eventstream, gr-mapper, gr-burst revisted (Cinaed Simson)
2. [UHD] Introducing the Python API (Martin Braun)
3. Convert recorded FM wav file to I,Q values (Jahnavendra Mattipa)
4. Re: Convert recorded FM wav file to I,Q values (Marcus M?ller)
5. query about fm example file in github tutorials repository
(Jacqueline.Walker)

----------------------------------------------------------------------

Message: 1
Date: Wed, 28 Jun 2017 14:58:55 -0700
From: Cinaed Simson <cinaed.simson@gmail.com>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] gr-eventstream, gr-mapper, gr-burst
revisted
Message-ID: <f276b53f-1ddc-65b2-00e9-566a500706d5@GMail.COM>
Content-Type: text/plain; charset=utf-8

gr-eventstream:
--------------

In '_es_swig.so', instead of including the symbol 'init_es_swig' and
linking to python2 libraries, it was including the symbol
'PyInit__es_swig' and linking to python3 libraries.

See ./build/swig/es_swigPYTHON_wrap.cxx.

Tried to modify the cmake file GrPython.cmake and GrSwig.cmake but
couldn't stop '_es_swig.so' from including the symbol 'PyInit__es_swig'
and linking to to python3 libraries.

So I had to uninstalled libpython3-dev and it passed

make test

gr-mapper:
---------

Test failed because the cart got in front of the horse.

In 'qa_preamble.py' I had to replace 'import mapper' with
'import mapper_swig as mapper' and then it passed

make test

gr-burst:
---------

Fails because 'qa_synchronizer_v3.py' because

x = sio.loadmat('../../matlab/gr_impl_test.mat')

can't find the file 'gr_impl_test.mat' - which is typically a show
stopper - there could be other errors.

Couldn't find the file on

https://github.com/gr-vt/gr-burst/tree/master/matlab

either - and yes, 'scipy' is installed on the system.

-- Cinaed

------------------------------

Message: 2
Date: Wed, 28 Jun 2017 15:36:23 -0700
From: Martin Braun <martin.braun@ettus.com>
To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>,
"discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] [UHD] Introducing the Python API
Message-ID: <954eb77d-f574-aea4-25a7-956076e07549@ettus.com>
Content-Type: text/plain; charset=utf-8

Hi all,

some people have already heard the rumour that we're working on a Python
API for UHD that does not involve gr-uhd. And yes, it's true. A minute
ago, I published our current development branch on github:

https://github.com/EttusResearch/uhd/tree/python-api

We'll be doing some more development on this branch before we're merging
it, but most importantly, we'd like to get some feedback from the
greater community.

The biggest thing missing is more documentation, but it already includes
some examples. It's definitely ready for testing!
If you have feedback, post it either in this thread, or on github:
https://github.com/EttusResearch/uhd/issues/105

I've tried to preempt some questions:

- Does it support Python 2 and 3? Yes.
- Does it use SWIG? No, it uses Boost.Python. We didn't want to add
another dependency to UHD (i.e., SWIG) and Boost was already a
dependency of UHD. It also doesn't require the C API.
- How does this relate to the Python API in gr-uhd? It serves an
entirely different purpose. This Python API is for people writing
standalone applications for USRPs that *don't* use GNU Radio. gr-uhd is
staying the way it is, and is going nowhere. If you're using GNU Radio,
you probably don't care about this.
- Are the UHD Python API and the gr-uhd Python API compatible? Short
answer: No. Long answer: There are very few cases where it makes sense
to mix these APIs, so no. However, this means that a TimeSpec from the
Boost.Python API is not convertible into a time_spec_t from the gr-uhd API.
- When will it be released? TBD, but if we hear a lot of encouragement
that'll drive things along faster. It'll go into master branch whenever
it's considered stable enough, and then in the first major release after
that merge.
- Does it support RFNoC API? Not yet, but it's not hard to add. We
wanted to get the basics (i.e. multi_usrp API) right first.
- What's the streaming performance? Worse than straight C++. Better than
I would have thought, thanks to numpy. We have no benchmarks yet.
Overall, recv() calls are pretty efficient if you've preallocated a
numpy array, because we can cast that to a straight pointer (and also
skip any type checking!!!!!!) and then it's not that different from a
recv() call in a C++ app. However, consuming the data is limited by how
fast you can handle that in Python.

We're really looking forward to feedback from the community.

Cheers,
Martin

------------------------------

Message: 3
Date: Thu, 29 Jun 2017 11:25:22 +0530
From: Jahnavendra Mattipa <jahna.mattipa2525@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Convert recorded FM wav file to I,Q values
Message-ID:
<CAH5NE-Z9CNphqc8h6FYiBSqWW2PvHh3xNs==JQ0A3uv1RFo-dQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello all,
Is there any possibility to convert the recorded FM 'wav' file to I,Q
values, if possible please tell me how to do this?

Best reagards,
M. Jahnvendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170629/426d8f13/attachment.html>

------------------------------

Message: 4
Date: Thu, 29 Jun 2017 11:04:23 +0200
From: Marcus M?ller <marcus.mueller@ettus.com>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Convert recorded FM wav file to I,Q
values
Message-ID: <f6f16e7f-4829-bf1c-7591-b437eeb229bc@ettus.com>
Content-Type: text/plain; charset="utf-8"

Hi Mattipa,

uh, what? What files are you referring to? Please make sure that someone
who's got no idea what you're working on can understand your question.
We like to help, but our senses of clairvoyance are severely
underdeveloped :)

Best regards,
Marcus

On 29.06.2017 07:55, Jahnavendra Mattipa wrote:
> Hello all,
> Is there any possibility to convert the recorded FM 'wav' file to
> I,Q values, if possible please tell me how to do this?
>
>
> Best reagards,
> M. Jahnvendra
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170629/12c1f886/attachment.html>

------------------------------

Message: 5
Date: Thu, 29 Jun 2017 14:39:00 +0000
From: Jacqueline.Walker <Jacqueline.Walker@ul.ie>
To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] query about fm example file in github
tutorials repository
Message-ID:
<29CC4BAEE76E33429FB7F05BDC99630267A9CB7D@exMbx3.ul.campus>
Content-Type: text/plain; charset="us-ascii"

Hi,

I downloaded the file fm101.8MHz_1Msps.cfile (from gr-tutorials/examples/tutorial6/ ) to use for trying out demodulation flowgraphs in gnuradio. It was recommended here: https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations
But I can't find any details about the file - it says on the tutorial page - 'an actual recording from a radio (USRP I presume) with nothing done to the data, so I presume it is just a binary stream such as one would receive from a USRP and that the centre frequency is 101.8MHz. What is the sample rate output by the USRP that recorded the file - is it 250k as given on the tutorial page? What is the signal bandwidth expected? I ask this because I don't see that much on the FFT?

Thanks
Jacqueline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170629/e7686796/attachment.html>

------------------------------

Subject: Digest Footer

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

------------------------------

End of Discuss-gnuradio Digest, Vol 176, Issue 29
*************************************************
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  

Thursday, June 29, 2017

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 176, Issue 29

Please bear my short message below,

I am sorry Mr. Marcus, i know i asked some irrelevant and undefined questions. But this question is not mine, my scientific professor aksed me try to convert the FM wav file to I, Q values if possible. I also confused with that question and searched some papers too but no information regarding this.

Thank you Marcus.

Best Regards,

M. Jahnavendra

On Thu, Jun 29, 2017 at 9:30 PM, <discuss-gnuradio-request@gnu.org> wrote:

Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."

Today's Topics:

1. gr-eventstream, gr-mapper, gr-burst revisted (Cinaed Simson)
2. [UHD] Introducing the Python API (Martin Braun)
3. Convert recorded FM wav file to I,Q values (Jahnavendra Mattipa)
4. Re: Convert recorded FM wav file to I,Q values (Marcus M?ller)
5. query about fm example file in github tutorials repository
(Jacqueline.Walker)

----------------------------------------------------------------------

Message: 1
Date: Wed, 28 Jun 2017 14:58:55 -0700
From: Cinaed Simson <cinaed.simson@gmail.com>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] gr-eventstream, gr-mapper, gr-burst
revisted
Message-ID: <f276b53f-1ddc-65b2-00e9-566a500706d5@GMail.COM>
Content-Type: text/plain; charset=utf-8

gr-eventstream:
--------------

In '_es_swig.so', instead of including the symbol 'init_es_swig' and
linking to python2 libraries, it was including the symbol
'PyInit__es_swig' and linking to python3 libraries.

See ./build/swig/es_swigPYTHON_wrap.cxx.

Tried to modify the cmake file GrPython.cmake and GrSwig.cmake but
couldn't stop '_es_swig.so' from including the symbol 'PyInit__es_swig'
and linking to to python3 libraries.

So I had to uninstalled libpython3-dev and it passed

make test

gr-mapper:
---------

Test failed because the cart got in front of the horse.

In 'qa_preamble.py' I had to replace 'import mapper' with
'import mapper_swig as mapper' and then it passed

make test

gr-burst:
---------

Fails because 'qa_synchronizer_v3.py' because

x = sio.loadmat('../../matlab/gr_impl_test.mat')

can't find the file 'gr_impl_test.mat' - which is typically a show
stopper - there could be other errors.

Couldn't find the file on

https://github.com/gr-vt/gr-burst/tree/master/matlab

either - and yes, 'scipy' is installed on the system.

-- Cinaed

------------------------------

Message: 2
Date: Wed, 28 Jun 2017 15:36:23 -0700
From: Martin Braun <martin.braun@ettus.com>
To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>,
"discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] [UHD] Introducing the Python API
Message-ID: <954eb77d-f574-aea4-25a7-956076e07549@ettus.com>
Content-Type: text/plain; charset=utf-8

Hi all,

some people have already heard the rumour that we're working on a Python
API for UHD that does not involve gr-uhd. And yes, it's true. A minute
ago, I published our current development branch on github:

https://github.com/EttusResearch/uhd/tree/python-api

We'll be doing some more development on this branch before we're merging
it, but most importantly, we'd like to get some feedback from the
greater community.

The biggest thing missing is more documentation, but it already includes
some examples. It's definitely ready for testing!
If you have feedback, post it either in this thread, or on github:
https://github.com/EttusResearch/uhd/issues/105

I've tried to preempt some questions:

- Does it support Python 2 and 3? Yes.
- Does it use SWIG? No, it uses Boost.Python. We didn't want to add
another dependency to UHD (i.e., SWIG) and Boost was already a
dependency of UHD. It also doesn't require the C API.
- How does this relate to the Python API in gr-uhd? It serves an
entirely different purpose. This Python API is for people writing
standalone applications for USRPs that *don't* use GNU Radio. gr-uhd is
staying the way it is, and is going nowhere. If you're using GNU Radio,
you probably don't care about this.
- Are the UHD Python API and the gr-uhd Python API compatible? Short
answer: No. Long answer: There are very few cases where it makes sense
to mix these APIs, so no. However, this means that a TimeSpec from the
Boost.Python API is not convertible into a time_spec_t from the gr-uhd API.
- When will it be released? TBD, but if we hear a lot of encouragement
that'll drive things along faster. It'll go into master branch whenever
it's considered stable enough, and then in the first major release after
that merge.
- Does it support RFNoC API? Not yet, but it's not hard to add. We
wanted to get the basics (i.e. multi_usrp API) right first.
- What's the streaming performance? Worse than straight C++. Better than
I would have thought, thanks to numpy. We have no benchmarks yet.
Overall, recv() calls are pretty efficient if you've preallocated a
numpy array, because we can cast that to a straight pointer (and also
skip any type checking!!!!!!) and then it's not that different from a
recv() call in a C++ app. However, consuming the data is limited by how
fast you can handle that in Python.

We're really looking forward to feedback from the community.

Cheers,
Martin

------------------------------

Message: 3
Date: Thu, 29 Jun 2017 11:25:22 +0530
From: Jahnavendra Mattipa <jahna.mattipa2525@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Convert recorded FM wav file to I,Q values
Message-ID:
<CAH5NE-Z9CNphqc8h6FYiBSqWW2PvHh3xNs==JQ0A3uv1RFo-dQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello all,
Is there any possibility to convert the recorded FM 'wav' file to I,Q
values, if possible please tell me how to do this?

Best reagards,
M. Jahnvendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170629/426d8f13/attachment.html>

------------------------------

Message: 4
Date: Thu, 29 Jun 2017 11:04:23 +0200
From: Marcus M?ller <marcus.mueller@ettus.com>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Convert recorded FM wav file to I,Q
values
Message-ID: <f6f16e7f-4829-bf1c-7591-b437eeb229bc@ettus.com>
Content-Type: text/plain; charset="utf-8"

Hi Mattipa,

uh, what? What files are you referring to? Please make sure that someone
who's got no idea what you're working on can understand your question.
We like to help, but our senses of clairvoyance are severely
underdeveloped :)

Best regards,
Marcus

On 29.06.2017 07:55, Jahnavendra Mattipa wrote:
> Hello all,
> Is there any possibility to convert the recorded FM 'wav' file to
> I,Q values, if possible please tell me how to do this?
>
>
> Best reagards,
> M. Jahnvendra
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170629/12c1f886/attachment.html>

------------------------------

Message: 5
Date: Thu, 29 Jun 2017 14:39:00 +0000
From: Jacqueline.Walker <Jacqueline.Walker@ul.ie>
To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] query about fm example file in github
tutorials repository
Message-ID:
<29CC4BAEE76E33429FB7F05BDC99630267A9CB7D@exMbx3.ul.campus>
Content-Type: text/plain; charset="us-ascii"

Hi,

I downloaded the file fm101.8MHz_1Msps.cfile (from gr-tutorials/examples/tutorial6/ ) to use for trying out demodulation flowgraphs in gnuradio. It was recommended here: https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations
But I can't find any details about the file - it says on the tutorial page - 'an actual recording from a radio (USRP I presume) with nothing done to the data, so I presume it is just a binary stream such as one would receive from a USRP and that the centre frequency is 101.8MHz. What is the sample rate output by the USRP that recorded the file - is it 250k as given on the tutorial page? What is the signal bandwidth expected? I ask this because I don't see that much on the FFT?

Thanks
Jacqueline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170629/e7686796/attachment.html>

------------------------------

Subject: Digest Footer

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

------------------------------

End of Discuss-gnuradio Digest, Vol 176, Issue 29
*************************************************

[Discuss-gnuradio] Problem with Convertion From BLOB to String in a PMT message C++

Hi all.

I'm trying to convert a variable from BLOB to String.

I'm trying to do this.

Before, the next block was instead of WiFi App.

There, i try to convert it to a char and later from char to String, but it doesn't work.

What do you think i can do? What i need is to take de data in BLOB format, convert it to String, save it in a PMT message and send it.

Thanks a lot for your time to read.

Best regards,

Cristian

Re: [Discuss-gnuradio] Trouble Installing a new block in GNURAdio (gr-ieee-802-11) not .cc.o file generated

Hi Kyeong,

2017-06-29 20:00 GMT-05:00 Kyeong Su Shin <ksshin@uw.edu>:

Hello Cristian:

I am not too familiar with cmake and gr-802-11, but you probably have to modify cmake files and run cmake again if the files do not automatically get added. I suggest try editing CMakeLists.txt (the one located in lib directory).

thanks a lot for your message.

Yes, as you indicated it was solved by including my file in both CMakeLists.txt, and, in the Swig list, because it was built in C++.

Best regards,

Cristian

Regards,
Kyeong Su Shin
On Thu, Jun 29, 2017 at 11:43 AM, Cristian Rodríguez <cristian.rodriguez.ud@gmail.com> wrote:
Hi all,

I'm designing a block in C++. It has .c, .h and .xml files. I put them in the same folders than mac or decode_mac blocks are in.

I installed all the blocks of ge-ieee-802-11 again, as follows,
cd gr-ieee802-11  mkdir build  cd build  cmake ..  make  sudo make install  sudo ldconfig
but I dont know what i'm not including because the .cc.o file is not being generated for my block, as occurs with mac or decode_mac.
In the terminal, I can see that decode_mac.cc.o (the block from which i'm building the mine ) is generated.
[ 20%] Building CXX object lib/CMakeFiles/gnuradio-ieee802_11.dir/decode_mac.cc.o
And, installed in the project,
Install the project...
-- Up-to-date: /usr/local/include/ieee802-11/gnuradio/ieee802_11/decode_mac.h
But the mine, doesn't appear in the list.
Though, when it is checking for .xml files, it is listing the mine.
-- Up-to-date: /usr/local/share/gnuradio/grc/blocks/ieee802_11_app.xml
I know, maybe, it is just a line in a file, but i can't go ahead with it.
If you know the solution to my problem or you have a reference page, i would be very greatful.
I read,
https://wiki.gnuradio.org/index.php/OutOfTreeModules#Making_your_blocks_available_in_GRC
but I didn't found the answer.
Thanks a lot for your time to read.
Best regards,
Cristian
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble Installing a new block in GNURAdio (gr-ieee-802-11) not .cc.o file generated

Hello Cristian:

I am not too familiar with cmake and gr-802-11, but you probably have to modify cmake files and run cmake again if the files do not automatically get added. I suggest try editing CMakeLists.txt (the one located in lib directory).

Regards,

Kyeong Su Shin

On Thu, Jun 29, 2017 at 11:43 AM, Cristian Rodríguez <cristian.rodriguez.ud@gmail.com> wrote:

Hi all,

I'm designing a block in C++. It has .c, .h and .xml files. I put them in the same folders than mac or decode_mac blocks are in.

I installed all the blocks of ge-ieee-802-11 again, as follows,
cd gr-ieee802-11  mkdir build  cd build  cmake ..  make  sudo make install  sudo ldconfig
but I dont know what i'm not including because the .cc.o file is not being generated for my block, as occurs with mac or decode_mac.
In the terminal, I can see that decode_mac.cc.o (the block from which i'm building the mine ) is generated.
[ 20%] Building CXX object lib/CMakeFiles/gnuradio-ieee802_11.dir/decode_mac.cc.o
And, installed in the project,
Install the project...
-- Up-to-date: /usr/local/include/ieee802-11/gnuradio/ieee802_11/decode_mac.h
But the mine, doesn't appear in the list.
Though, when it is checking for .xml files, it is listing the mine.
-- Up-to-date: /usr/local/share/gnuradio/grc/blocks/ieee802_11_app.xml
I know, maybe, it is just a line in a file, but i can't go ahead with it.
If you know the solution to my problem or you have a reference page, i would be very greatful.
I read,
https://wiki.gnuradio.org/index.php/OutOfTreeModules#Making_your_blocks_available_in_GRC
but I didn't found the answer.
Thanks a lot for your time to read.
Best regards,
Cristian
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] PMT: Get a value associated to a specific key in a car of PMT message C++

Hi all.

I'm trying to get the car of a PMT message. And later in the car, the value associated to a specific key.

I'm receiving it:

(((dlt . 105) (freqofs . -0.00015152) (nomfreq . 5.89e+09) (snr . 144.985) (encoding . 0)) . #[1 2 3 4 5 6 7 8 9 0])

I want to get the car:

((dlt . 105) (freqofs . -0.00015152) (nomfreq . 5.89e+09) (snr . 144.985) (encoding . 0))

And later get the value of the key "snr":
144.985

I'm doing that with the next code: msg is the message that I receive.

pmt::pmt_t dict = pmt::car(msg);

pmt::pmt_t snrf =pmt::dict_ref(dict, pmt::mp("snr"), pmt::from_double(10));
message_port_pub(pmt::mp("SNR out"), snrf);

If I public dict, I get in console:

pmt_uniform_vector_elements: wrong_type : ((freqofs . -0.00015152) (nomfreq . 5.89e+09) (snr . 144.985) (encoding . 0))

If I public snrf, I get in console:

pmt_car: wrong_type : 144.985

In general, it is working, but I don't understand why these messages appears.

What do you think, Is another way of doing the same?

Thanks in advance.

Best regards,

Cristian

Re: [Discuss-gnuradio] USRP N210 gain requirement

Dear Roohollah,

I've answered you in private. Generally, please try to keep inquiries here on discuss-gnuradio@gnu.org as related to GNU Radio as possible.

Thank you!

Best regards,

Marcus

On 29.06.2017 23:40, Roohollah Parvizi wrote:

Hello all,

I am going to buy GPS antenna cables for my Sensor Suit. My sensor suite that includes 2 USRP N210 with SBX daughter-board. But the problem is that the vendor asked about the gain required for the receiver (here USRP N210)

Or their overall gain requirement! They want to know this information then suggest the cable which fulfills this requirement. But I have not found such information from USRP N210 manual or Webpage. Could you please help me with this issue?

Thank you in advance for your help.

Thanks,

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

[Discuss-gnuradio] USRP N210 gain requirement

Hello all,

I am going to buy GPS antenna cables for my Sensor Suit. My sensor suite that includes 2 USRP N210 with SBX daughter-board. But the problem is that the vendor asked about the gain required for the receiver (here USRP N210)

Or their overall gain requirement! They want to know this information then suggest the cable which fulfills this requirement. But I have not found such information from USRP N210 manual or Webpage. Could you please help me with this issue?

Thank you in advance for your help.

Thanks,

Roohollah

[Discuss-gnuradio] dBm and dB Measurements

Hello Everyone,

I am using HackRF One and running gr-scan spectrum monitoring software. I am
also utilizing vector signal generator and spectrum analyzer.

Can anyone please help me understand the following measurement results from
both spectrum analyzer (reference level: -20 dBm) and gr-scan?

Spectrum Analyzer: -25 dBm VSG at 2437 MHz -> Peak Power: -47.26 dBm (Almost
no loss since it is one foot cable directly connected to spectrum analyzer
from vector signal generator)

gr-scan: -25 dBm VSG at 2437 MHz -> Peak Power: -47.61 dB

Spectrum Analyzer: -30 dBm VSG at 2437 MHz -> Peak Power: -52.85 dBm (Again,
it is the same...Almost no loss)

gr-scan: -30 dBm VSG at 2437 MHz -> Peak Power: -51.37 dB

Spectrum Analyzer: -35 dBm VSG at 2437 MHz -> Peak Power: -58.22 dBm (Almost
no loss)

gr-scan: -35 dBm VSG at 2437 MHz -> Peak Power: -58.34 dB

Spectrum Analyzer: -40 dBm VSG at 2437 MHz -> Peak Power: -63.21 dBm

gr-scan: -40 dBm VSG at 2437 MHz -> Peak Power: -63.15 dB

Spectrum Analyzer: -45 dBm VSG at 2437 MHz -> Peak Power: -67.63 dBm

gr-scan: -45 dBm VSG at 2437 MHz -> Peak Power: -67.41 dB

I guess there is no relationship between SDR dB values and spectrum analyzer
dBm values but what I have noticed that SDR is linearly following VSG power
increments.

Thanks,

--
View this message in context: http://gnuradio.4.n7.nabble.com/dBm-and-dB-Measurements-tp64413.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Fwd: query about fm example file in github tutorials repository

Sent from my HTC

OMG, silly me ...it was staring me in the face as I was laboriously typing out the filename!!

Thanks will try that

Regards

Jacqueline

Sent from my HTC

Hi Jacqueline,

Best regards,

Marcus

On 06/29/2017 04:39 PM, Jacqueline.Walker wrote:

Hi,

I downloaded the file fm101.8MHz_1Msps.cfile (from gr-tutorials/examples/tutorial6/ ) to use for trying out demodulation flowgraphs in gnuradio. It was recommended here: https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations

But I can't find any details about the file – it says on the tutorial page – 'an actual recording from a radio (USRP I presume) with nothing done to the data, so I presume it is just a binary stream such as one would receive from a USRP and that the centre frequency is 101.8MHz. What is the sample rate output by the USRP that recorded the file – is it 250k as given on the tutorial page? What is the signal bandwidth expected? I ask this because I don't see that much on the FFT?

Thanks

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

Re: [Discuss-gnuradio] Convert Float to PMT in a Gnuradio flowgraph

Hi Cristian,

On 06/29/2017 08:29 PM, Cristian Rodríguez wrote:

Thanks for your answer Marcus.

2017-06-28 5:52 GMT-05:00 Marcus Müller <marcus.mueller@ettus.com>:

Hi Cristian,

the sending of values from within work() is really just a one liner (and I think you'd do it right – just send a pmt::from_double() using msg_port_pub) so you'd just write a block for that.

It is not clear for me how the common inputs work (I mean the not PMT type).

It has a buffer, and save the incoming values in a buffer, and later when the work() function is called use all this values until the buffer is empty?

I've kind of wrote a blog entry about that:
https://www.gnuradio.org/blog/buffers/

I'm going to build the block, and i tell you how it is going.

Anyway, your flow graph is probably misbehaving because you set the throttle rate to 1. That means that when the trottle is presented with N samples on the input buffer, it will wait N seconds.

N depends on the scheduling of this flow graph, but might typically be something like 1024, which in turn means that your flow graph starts, Signal source generates N items, Throttle gets called with N items, and then just sleeps for N seconds – that's nearly 20 min for N=1024 – before Complex to Mag gets 1024 items, processes them (likely all at once, though it's perfectly free to first process any number smaller than N, and be repeatedly called), and so on.

I set that parameter in several values, that screenshot had that value, but i used a lot and always the flowgraph failed.

That's not a parameter you can set!

Thanks in advance.

Best regards,

Cristian
Best regards,

Marcus

On 28.06.2017 06:06, Cristian Rodríguez wrote:
Hi all.

I'm implementing this flowgraph.

I want to calculate the power in the antenna, which is set as float and later convert it to a PMT type. I don't know if it is possible.

I tried to build the above flowgraph, My idea was to convert the float type to a tagged stream and later it in PMT type. Though the flowgraph can do that, it is not working as I expected.

What blocks could you recommend me to do this conversion?

In C++ word i want to:

float x=output_of_Moving average.
pmt::cons(pmt::PMT_NIL, pmt::from_float(x))

Thanks a lot.

Best regards,

Cristian
_______________________________________________  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