Re: [Discuss-gnuradio] Displaying angle measurements with a nice GUI

[Nate Temple]

There is the "WX DOA Compass" in gr-baz

https://github.com/balint256/gr-baz

https://github.com/balint256/gr-baz/blob/master/grc/doa_compass.xml

-- Nate


> On Jun 15, 2016, at 10:44 AM, Philip Balister  wrote:
> 
> On 06/15/2016 01:06 PM, Nick Foster wrote:
>> You ought to be able to use PyQwt's compass widget:
> 
> Qwt is OK, but please do not use PyQwt. It is unmaintained. See:
> 
> https://sourceforge.net/p/pyqwt/mailman/message/30352623/
> 
> Philip
> 
>> 
>> http://qwt.sourceforge.net/class_qwt_compass.html
>> 
>> I used it for gr-air-modes and, while ugly, it does work. There's no
>> integration into GRC so the Python to integrate the widget will, of course,
>> be your responsibility.
>> 
>> --n
>> 
>> On Wed, Jun 15, 2016 at 9:45 AM Martin Braun  wrote:
>> 
>>> Meny,
>>> 
>>> no, we don't. A compass was one of the suggestions for this year's GSoC,
>>> but no one signed up for that.
>>> 
>>> M
>>> 
>>> On 06/15/2016 04:34 AM, Meny Sidar wrote:
 Hi guys
 
 I'm looking for a nice GUI that can plot my AoA calculations in a some
 kind of a compass looking GUI.
 Does anything like that exists? or do i have to build one of my own?
 Don't really know how, and would prefer not to start learning Python
 right now (on a deadline).
 
 Any help would be much appreciated!
 Thanks,
 Meny
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
>>> 
>>> 
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> 
>> 
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] Python Unit Tests Running Twice

[Dave NotTelling]

I noticed that my Python unit tests were running twice.  Using PyCharm's
debugger I was able to figure out that the culprit is the following snippet
from gr_unittest.py:

# use the xmlrunner if we can write the the directory
if(xmlrunner is not None):
xmlrunner.run(suite)

main()


xmlrunner.run(suite) runs my tests, when that finishes (failure or not)
main() gets called which runs the tests again.  This plays hell with my
tests that talk to radio hardware as the radio hardware is never released.
Should there be an 'else' clause that calls main()?

Thanks!

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

Re: [Discuss-gnuradio] DVB-S2 Physical Layer Framer: Why outputs a zero after each sample?

[Ron Economos]

The primary design decision was to use the FFT filter instead of the 
interpolating FIR filter for performance. The FFT filter is considerably 
faster, especially at the 100 taps used in the flow graph. However, (as 
far as I know) the FFT filter does not have an interpolation option, 
just decimation. So the 2X interpolation is done in the Physical Layer 
Framer block instead.


You can remove the zero stuffing from the Physical Layer Framer and use 
the Interpolating FIR Filter block instead of the FFT filter block for 
RRC filtering. If you try that, be sure to remove the factor of two in 
lines 535, 548 and 680 in the PL framer block.


Here's a link that explains why zero stuffing is the correct way to do 
interpolation.


http://www.dspguru.com/dsp/faqs/multirate/interpolation

Ron

On 06/15/2016 02:37 PM, Francisco Albani wrote:

Hi to all! Specially to Ron Economos! (and thanks for sharing your work)

I was trying to understand the example *dvbs2_tx.grc* and, after 
putting graphical sinks after many blocks, I noticed that the one 
called "Physical Frame Layer" outputs one complex zero after each 
constellation point (see attached screenshot). Moreover, the FFT 
Filter that gives the RRC shape is *not* instructed to interpolate to 
fit any samples_per_symbol requirement. Moremoreover, the sample rate 
is hardcoded to symbol_rate*2.


This makes me think this transmitter can only work for 2 samples per 
symbol. (I suppose one can resample to an arbitrary sps value if needed.)


The point of this message is to confirm my suspicion and to ask why 
this was a design decision. I hope to learn some insight.


Here is the code: 
*https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbs2/dvbs2_physical_cc_impl.cc#L684*


Relevant lines: 80, 684, 704 and 727.

Bye and thanks!


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

Re: [Discuss-gnuradio] File source problem

[Olivier Goyette]

Ok I will try that. Just for your information, throttle or not, it works in
both cases on the Nutaq Zepto
Le 2016-06-15 17:15, "Nick Foster"  a écrit :

> One clue for you is already being printed out for you in the TX flowgraph
> image. Get rid of the throttle block.
>
> The RX time domain plot looks actually pretty healthy. It's showing a
> frequency offset, which is normal for unsynchronized devices.
>
> The constellation plot needs to happen after timing and phase recovery, or
> it will show useless garbage. Because your PSK demod is happening all in a
> single, monolithic block, you don't get access to the constellation. If you
> put a timing recovery block and a Costas loop block in front of the QT GUI
> sink, and set their parameters appropriately, you should be able to get a
> decent constellation plot.
>
> --n
>
> On Wed, Jun 15, 2016 at 1:26 PM Olivier Goyette <
> olivier.goyett...@gmail.com> wrote:
>
>> I'm giving a copy of the email I just sent to Ettus Research. I think
>> that it's been a hardware problem since the beginning but i'm waiting for
>> their response.
>>
>> Check it out, maybe some of view have already seen this kind of bug
>>
>>
>> *E-mail*
>>
>> Hi !
>>
>>
>>
>> My name is Olivier and I’m actually working with your USRP N210 and
>> GNURadio Companion. It’s been a couple of week since I started using your
>> equipment and yet, I already had issues with it. Doing a simple
>> modulation/demodulation seems impossible and everything I came up with
>> until now, suggest me that it’s a hardware problem. So, I took quite a lot
>> of pictures for you to see what’s wrong and I’ll share the links to my
>> dropbox so it will be easier like that.
>>
>>
>>
>> What I’m trying to do is a PSK mod and demod. I know it works because one
>> of my colleague is using a Nutaq Zepto SDR and he’s been using the same
>> flowgraph as mine in an other project and it works perfectly. So, what we
>> did is the following setup :
>> https://www.dropbox.com/s/ottq341sob5z90r/Actual_setup.jpg?dl=0
>>
>>
>>
>> The upper radio represents the TX link (WBX card) and the one at the
>> bottom represent the RX link (SBX card).
>>
>>
>>
>> This is the flowgraph on the TX radio :
>> https://www.dropbox.com/s/ir5ehp6caiy525a/TX_side.jpg?dl=0
>>
>>
>>
>> This is the flowgraph on the RX radio :
>> https://www.dropbox.com/s/tl95cwbstwzl4r8/RX_side.jpg?dl=0
>>
>>
>>
>> What we’re trying to do is to transmit a video stream from one computer
>> to another. Unfortunately, on the RX computer, the file supposedly
>> containing the video is empty (0 bytes when you right click on it and go to
>> the properties panel).
>>
>>
>>
>> This is the TX spectrum :
>> https://www.dropbox.com/s/pzsn8oo74sgrehp/TX_spectrum.jpg?dl=0 and this
>> is the spectrum when you look at it with a spectrum analyser :
>> https://www.dropbox.com/s/5bks7aksih8ctzh/TX_MDO_spectrum.jpg?dl=0
>>
>>
>>
>> This is the RX spectrum :
>> https://www.dropbox.com/s/dlsovfxovv4n9tm/RX_spectrum.jpg?dl=0
>>
>>
>>
>> This is the TX time domain graph :
>> https://www.dropbox.com/s/q25sbjukyzsyymz/TX_time_domain.jpg?dl=0
>>
>>
>>
>> This is the RX time domain graph :
>> https://www.dropbox.com/s/qetgf0cr4s7d5hb/RX_time_domain_1.jpg?dl=0
>>
>>
>>
>> This is the TX constellation :
>> https://www.dropbox.com/s/gflb0f65oa0m1rl/TX_constellation.jpg?dl=0
>>
>>
>>
>> This is the RX constellation :
>> https://www.dropbox.com/s/4j0hnhl97v2uj7g/RX_constellation.jpg?dl=0
>>
>>
>>
>> What seems strange to me is the time domain graph at RX. It’s like if the
>> imaginary part and the real part of the signal were modulated onto whatever
>> signal that appears to be there. I tried my RX link on one of the other
>> radio I have and look at the result :
>> https://www.dropbox.com/s/f1al75vgo5z2wcf/RX_time_domain_2.jpg?dl=0 .
>> The time domain is completely different but still it is a SBX card and I
>> haven’t touch any settings in my flowgraph to keep consistency.
>>
>>
>>
>> So, now I’m asking for your help because my knowledge is pretty basic
>> with this equipment and I’d like to have your input about that.
>>
>>
>>
>> For your information, I did reload the firmware and the bitfile into the
>> FPGA before sending this email so it’s not necessary to ask me to do it.
>>
>>
>>
>> I sincerely hope this will lead somewhere as I’m out of options right now.
>>
>>
>> Thank you for your time and have a nice day !
>>
>> 2016-06-15 13:58 GMT-04:00 Marcus Müller :
>>
>>> Hi Olivier,
>>>
>>> what does this mean:
>>>
>>> The 1st file contains only '1' and the other only '0'.
>>>
>>> How did you generate these files. Without knowing better, I'd say this
>>> is a case for our File Format FAQ:
>>>
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 06/15/2016 12:25 AM, Olivier Goyette wrote:
>>>

[Discuss-gnuradio] DVB-S2 Physical Layer Framer: Why outputs a zero after each sample?

[Francisco Albani]

Hi to all! Specially to Ron Economos! (and thanks for sharing your work)

I was trying to understand the example *dvbs2_tx.grc* and, after putting
graphical sinks after many blocks, I noticed that the one called "Physical
Frame Layer" outputs one complex zero after each constellation point (see
attached screenshot). Moreover, the FFT Filter that gives the RRC shape is
*not* instructed to interpolate to fit any samples_per_symbol requirement.
Moremoreover, the sample rate is hardcoded to symbol_rate*2.

This makes me think this transmitter can only work for 2 samples per
symbol. (I suppose one can resample to an arbitrary sps value if needed.)

The point of this message is to confirm my suspicion and to ask why this
was a design decision. I hope to learn some insight.

Here is the code:
*https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbs2/dvbs2_physical_cc_impl.cc#L684
*

Relevant lines: 80, 684, 704 and 727.

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

Re: [Discuss-gnuradio] File source problem

[Nick Foster]

One clue for you is already being printed out for you in the TX flowgraph
image. Get rid of the throttle block.

The RX time domain plot looks actually pretty healthy. It's showing a
frequency offset, which is normal for unsynchronized devices.

The constellation plot needs to happen after timing and phase recovery, or
it will show useless garbage. Because your PSK demod is happening all in a
single, monolithic block, you don't get access to the constellation. If you
put a timing recovery block and a Costas loop block in front of the QT GUI
sink, and set their parameters appropriately, you should be able to get a
decent constellation plot.

--n

On Wed, Jun 15, 2016 at 1:26 PM Olivier Goyette 
wrote:

> I'm giving a copy of the email I just sent to Ettus Research. I think that
> it's been a hardware problem since the beginning but i'm waiting for their
> response.
>
> Check it out, maybe some of view have already seen this kind of bug
>
>
> *E-mail*
>
> Hi !
>
>
>
> My name is Olivier and I’m actually working with your USRP N210 and
> GNURadio Companion. It’s been a couple of week since I started using your
> equipment and yet, I already had issues with it. Doing a simple
> modulation/demodulation seems impossible and everything I came up with
> until now, suggest me that it’s a hardware problem. So, I took quite a lot
> of pictures for you to see what’s wrong and I’ll share the links to my
> dropbox so it will be easier like that.
>
>
>
> What I’m trying to do is a PSK mod and demod. I know it works because one
> of my colleague is using a Nutaq Zepto SDR and he’s been using the same
> flowgraph as mine in an other project and it works perfectly. So, what we
> did is the following setup :
> https://www.dropbox.com/s/ottq341sob5z90r/Actual_setup.jpg?dl=0
>
>
>
> The upper radio represents the TX link (WBX card) and the one at the
> bottom represent the RX link (SBX card).
>
>
>
> This is the flowgraph on the TX radio :
> https://www.dropbox.com/s/ir5ehp6caiy525a/TX_side.jpg?dl=0
>
>
>
> This is the flowgraph on the RX radio :
> https://www.dropbox.com/s/tl95cwbstwzl4r8/RX_side.jpg?dl=0
>
>
>
> What we’re trying to do is to transmit a video stream from one computer to
> another. Unfortunately, on the RX computer, the file supposedly containing
> the video is empty (0 bytes when you right click on it and go to the
> properties panel).
>
>
>
> This is the TX spectrum :
> https://www.dropbox.com/s/pzsn8oo74sgrehp/TX_spectrum.jpg?dl=0 and this
> is the spectrum when you look at it with a spectrum analyser :
> https://www.dropbox.com/s/5bks7aksih8ctzh/TX_MDO_spectrum.jpg?dl=0
>
>
>
> This is the RX spectrum :
> https://www.dropbox.com/s/dlsovfxovv4n9tm/RX_spectrum.jpg?dl=0
>
>
>
> This is the TX time domain graph :
> https://www.dropbox.com/s/q25sbjukyzsyymz/TX_time_domain.jpg?dl=0
>
>
>
> This is the RX time domain graph :
> https://www.dropbox.com/s/qetgf0cr4s7d5hb/RX_time_domain_1.jpg?dl=0
>
>
>
> This is the TX constellation :
> https://www.dropbox.com/s/gflb0f65oa0m1rl/TX_constellation.jpg?dl=0
>
>
>
> This is the RX constellation :
> https://www.dropbox.com/s/4j0hnhl97v2uj7g/RX_constellation.jpg?dl=0
>
>
>
> What seems strange to me is the time domain graph at RX. It’s like if the
> imaginary part and the real part of the signal were modulated onto whatever
> signal that appears to be there. I tried my RX link on one of the other
> radio I have and look at the result :
> https://www.dropbox.com/s/f1al75vgo5z2wcf/RX_time_domain_2.jpg?dl=0 . The
> time domain is completely different but still it is a SBX card and I
> haven’t touch any settings in my flowgraph to keep consistency.
>
>
>
> So, now I’m asking for your help because my knowledge is pretty basic with
> this equipment and I’d like to have your input about that.
>
>
>
> For your information, I did reload the firmware and the bitfile into the
> FPGA before sending this email so it’s not necessary to ask me to do it.
>
>
>
> I sincerely hope this will lead somewhere as I’m out of options right now.
>
>
> Thank you for your time and have a nice day !
>
> 2016-06-15 13:58 GMT-04:00 Marcus Müller :
>
>> Hi Olivier,
>>
>> what does this mean:
>>
>> The 1st file contains only '1' and the other only '0'.
>>
>> How did you generate these files. Without knowing better, I'd say this is
>> a case for our File Format FAQ:
>>
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink
>>
>> Best regards,
>> Marcus
>>
>> On 06/15/2016 12:25 AM, Olivier Goyette wrote:
>>
>> This is non sense seriously. This is my flowgraph :
>> 
>> https://www.dropbox.com/s/4cfptq5419kvyhz/file_source.png?dl=0
>>
>> When I send only zeros '0', this is what I get :
>> 
>> https://www.dropbox.com/s/aipf6ws

Re: [Discuss-gnuradio] File source problem

[Olivier Goyette]

I'm giving a copy of the email I just sent to Ettus Research. I think that
it's been a hardware problem since the beginning but i'm waiting for their
response.

Check it out, maybe some of view have already seen this kind of bug

*E-mail*

Hi !



My name is Olivier and I’m actually working with your USRP N210 and
GNURadio Companion. It’s been a couple of week since I started using your
equipment and yet, I already had issues with it. Doing a simple
modulation/demodulation seems impossible and everything I came up with
until now, suggest me that it’s a hardware problem. So, I took quite a lot
of pictures for you to see what’s wrong and I’ll share the links to my
dropbox so it will be easier like that.



What I’m trying to do is a PSK mod and demod. I know it works because one
of my colleague is using a Nutaq Zepto SDR and he’s been using the same
flowgraph as mine in an other project and it works perfectly. So, what we
did is the following setup :
https://www.dropbox.com/s/ottq341sob5z90r/Actual_setup.jpg?dl=0



The upper radio represents the TX link (WBX card) and the one at the bottom
represent the RX link (SBX card).



This is the flowgraph on the TX radio :
https://www.dropbox.com/s/ir5ehp6caiy525a/TX_side.jpg?dl=0



This is the flowgraph on the RX radio :
https://www.dropbox.com/s/tl95cwbstwzl4r8/RX_side.jpg?dl=0



What we’re trying to do is to transmit a video stream from one computer to
another. Unfortunately, on the RX computer, the file supposedly containing
the video is empty (0 bytes when you right click on it and go to the
properties panel).



This is the TX spectrum :
https://www.dropbox.com/s/pzsn8oo74sgrehp/TX_spectrum.jpg?dl=0 and this is
the spectrum when you look at it with a spectrum analyser :
https://www.dropbox.com/s/5bks7aksih8ctzh/TX_MDO_spectrum.jpg?dl=0



This is the RX spectrum :
https://www.dropbox.com/s/dlsovfxovv4n9tm/RX_spectrum.jpg?dl=0



This is the TX time domain graph :
https://www.dropbox.com/s/q25sbjukyzsyymz/TX_time_domain.jpg?dl=0



This is the RX time domain graph :
https://www.dropbox.com/s/qetgf0cr4s7d5hb/RX_time_domain_1.jpg?dl=0



This is the TX constellation :
https://www.dropbox.com/s/gflb0f65oa0m1rl/TX_constellation.jpg?dl=0



This is the RX constellation :
https://www.dropbox.com/s/4j0hnhl97v2uj7g/RX_constellation.jpg?dl=0



What seems strange to me is the time domain graph at RX. It’s like if the
imaginary part and the real part of the signal were modulated onto whatever
signal that appears to be there. I tried my RX link on one of the other
radio I have and look at the result :
https://www.dropbox.com/s/f1al75vgo5z2wcf/RX_time_domain_2.jpg?dl=0 . The
time domain is completely different but still it is a SBX card and I
haven’t touch any settings in my flowgraph to keep consistency.



So, now I’m asking for your help because my knowledge is pretty basic with
this equipment and I’d like to have your input about that.



For your information, I did reload the firmware and the bitfile into the
FPGA before sending this email so it’s not necessary to ask me to do it.



I sincerely hope this will lead somewhere as I’m out of options right now.


Thank you for your time and have a nice day !

2016-06-15 13:58 GMT-04:00 Marcus Müller :

> Hi Olivier,
>
> what does this mean:
>
> The 1st file contains only '1' and the other only '0'.
>
> How did you generate these files. Without knowing better, I'd say this is
> a case for our File Format FAQ:
>
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink
>
> Best regards,
> Marcus
>
> On 06/15/2016 12:25 AM, Olivier Goyette wrote:
>
> This is non sense seriously. This is my flowgraph :
> 
> https://www.dropbox.com/s/4cfptq5419kvyhz/file_source.png?dl=0
>
> When I send only zeros '0', this is what I get :
> 
> https://www.dropbox.com/s/aipf6wsj5ekwxnb/zeros.png?dl=0
>
> When I send only ones '1' this is what I get :
> 
> https://www.dropbox.com/s/g38hgrtc7s6exyt/ones.png?dl=0
>
> When I interleave both ones and zeros '1' & '0' , this is what I get :
> https://www.dropbox.com/s/a1cfs0tebmywz0l/interleave.png?dl=0
>
> What's wrong seriously ? If I can't even modulate properly, how am I
> suppose to make this work ?
>
> 2016-06-14 9:54 GMT-04:00 Olivier Goyette :
>
>> Hi
>>
>> I have a problem.  On my first setup, I use 2 file source. The 1st file
>> contains only '1' and the other only '0'. The 2 file sources go through a
>> selector and end up in a CPFSK mod block. When I run this, switching from
>> '1' to '0' makes the frequency drift from + to - FSK_deviation like it
>> should do normally. Now, when I use a unique file source containing '1' and
>> '0' (actually I wrote up 

Re: [Discuss-gnuradio] LimeSDR USB3.0 peripheral.

[Andrew Back]

On 15 June 2016 at 20:17, Andrew Back  wrote:
> Hi All,
>
> Apologies to those who may have already seen this, but just wanted to
> share details of a new low cost SDR hardware platform that is
> currently crowdfunding, the LimeSDR. Main specifications are as
> follows:
>
> * 100kHz-3.8GHz 2x2 MIMO (LMS7002M)
> * Bandwidth: 61.44 MHz
> * Power Output (CW): up to 10 dBm
> * Altera Cyclone IV EP4CE40F23
> * 256 MBytes DDR2 SDRAM
> * Cypress USB 3.0 CYUSB3014-BZXC
> * Oscillator: Rakon RPT7050A @30.72MHz (plus external ref input)
> * RF connection: 10 U.FL connectors (6 RX, 4 TX)
>
> Currently crowdfunding — $299 for the board, with various additional
> options, including a PCIe version — and the campaign ends next Tuesday
> (21st June).
>
> GNU Radio support via SoapySDR/UHD/gr-osmosdr. For demonstrations with
> LTE, Bluetooth Low Energy and DVB-S2 etc. see the campaign updates.

Argh! A URL would help, wouldn't it...

  https://www.crowdsupply.com/lime-micro/limesdr

A.

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

[Discuss-gnuradio] LimeSDR USB3.0 peripheral.

[Andrew Back]

Hi All,

Apologies to those who may have already seen this, but just wanted to
share details of a new low cost SDR hardware platform that is
currently crowdfunding, the LimeSDR. Main specifications are as
follows:

* 100kHz-3.8GHz 2x2 MIMO (LMS7002M)
* Bandwidth: 61.44 MHz
* Power Output (CW): up to 10 dBm
* Altera Cyclone IV EP4CE40F23
* 256 MBytes DDR2 SDRAM
* Cypress USB 3.0 CYUSB3014-BZXC
* Oscillator: Rakon RPT7050A @30.72MHz (plus external ref input)
* RF connection: 10 U.FL connectors (6 RX, 4 TX)

Currently crowdfunding — $299 for the board, with various additional
options, including a PCIe version — and the campaign ends next Tuesday
(21st June).

GNU Radio support via SoapySDR/UHD/gr-osmosdr. For demonstrations with
LTE, Bluetooth Low Energy and DVB-S2 etc. see the campaign updates.

Design for LMS8001 add-on module about to be published which extends
coverage to 12GHz (not available as part of this campaign, though).

Cheers,

Andrew

-- 
Andrew Back
http://carrierdetect.com

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

Re: [Discuss-gnuradio] Re channel state information on rx_ofdm.grc

[Marcus Müller]

Hi Avinash,

when you attach a "tag debug" after the "ofdm channel estimation" block,
you'll see stream tags containing CSI estimates flying by.
For more information on stream tags and how to handle them, I'd refer
you to the Guided Tutorials [1], chapter 1-5.

Best regards,
Marcus
[1] http://tutorials.gnuradio.org

On 06/15/2016 06:25 PM, avinash kalyanaraman wrote:
> Hello all,
>
> Could you please let me know how I can get channel-frequency response
> (like channel state information (CSI) ) for an OFDM transmission? I am
> looking at rx_ofdm.grc to capture the phase and amplitude at each of
> the 64 sub-carriers. 
>
> Would connecting the OFDM Channel Estimation Block of the HeaderStream
> to a FileSink such that item_size is fft_size* gr.sizeof_gr_complex ,
> give me enough information to capture the CSI ?
>
>  What would be the granularity of the aforementioned calculation?
>
> I transmit using tx_ofdm.grc.
>
> Please let me know.
>
> Thanks! 
>
> -- 
> Avinash 
>
>
> ___
> 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] Transmitting changes a received value

[Santos Campos]

Ah rookie mistake on my part!
I went ahead and made the sample rates consistent (40.96k) across the
schematic and an interesting thing happened.

So I set these parameters:
frequency to recover: 100Hz
fft size: 4096
sample rate: 40.96k Sps
to have a nice FFT bin number at 10

The interesting thing is that when receiving AND transmitting the expected
bin is half of what I thought it would be. (ex: Recovering 100Hz should
have been in FFT bin 10, when TX-ing it ends up in bin 5)

Does the B200 do some kind of "split" with the sample rate when using the
full duplex? Maybe dedicates half to each operation?(Not a huge issue)

Side question:
The resultant FFT bin seems to "blip" once in a while (half or full
duplex). Is it some kind of artifact of a Log Power FFT block? I was
looking around for documentation on it and if I could stabilize the output
bin with any of it's parameters. If I can't do it in block my other ideas
are:
- Use some kind of sample and hold logic to make the system non-sensitive
to small change.
- Decrease the bandwidth and low pass filter potential noise
- Increase power output from the board that's transmitting the tone
Would any of these be viable?

Any nudge in the right direction would be fantastic!
Thanks and very much appreciated!

On Tue, Jun 14, 2016 at 4:51 PM, Marcus D. Leech  wrote:

> On 06/14/2016 02:37 PM, Santos Campos wrote:
>
> Hello, all!
> This may be more of a board specific problem, so apologies if this is the
> wrong place to ask.
>
> I'm sending a tone from one b200 usrp to a receiving one. I was trying to
> recover the frequency of the original tone and was able to do so while only
> receiving.
>
> However, when I tried to add a transmitting functionality, it seems that
> my received samples are "corrupted" and the frequency I was trying to
> recover bounces all over the place. I was pretty sure that they supported
> full duplex, so I'm not sure what it might be.
>
> Any thoughts and suggestions are much appreciated!
>
> -Santos
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> So, another thing that leaps out at me is that your signal source and many
> of the intervening processing blocks think that they're operating at 32K,
> when in fact, they'll be operating at the hardware rate of your sink of
> 40.96ksps.   The "math" will be all wrong.  Either adjust the parameters of
> your intervening blocks so that they know you're operating at 40.96ksps, or
> put in an interpolator.
>
>
>
> ___
> 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] File source problem

[Marcus Müller]

Hi Olivier,

what does this mean:
> The 1st file contains only '1' and the other only '0'.
How did you generate these files. Without knowing better, I'd say this
is a case for our File Format FAQ:

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink

Best regards,
Marcus

On 06/15/2016 12:25 AM, Olivier Goyette wrote:
> This is non sense seriously. This is my flowgraph :
> https://www.dropbox.com/s/4cfptq5419kvyhz/file_source.png?dl=0
>
> When I send only zeros '0', this is what I get :
> https://www.dropbox.com/s/aipf6wsj5ekwxnb/zeros.png?dl=0
>
> When I send only ones '1' this is what I get :
> https://www.dropbox.com/s/g38hgrtc7s6exyt/ones.png?dl=0
>
> When I interleave both ones and zeros '1' & '0' , this is what I get :
> https://www.dropbox.com/s/a1cfs0tebmywz0l/interleave.png?dl=0
>
> What's wrong seriously ? If I can't even modulate properly, how am I
> suppose to make this work ?
>
> 2016-06-14 9:54 GMT-04:00 Olivier Goyette  >:
>
> Hi
>
> I have a problem.  On my first setup, I use 2 file source. The 1st
> file contains only '1' and the other only '0'. The 2 file sources
> go through a selector and end up in a CPFSK mod block. When I run
> this, switching from '1' to '0' makes the frequency drift from +
> to - FSK_deviation like it should do normally. Now, when I use a
> unique file source containing '1' and '0' (actually I wrote up the
> alphabet in a file) and I run this, this is what I get :
> https://www.dropbox.com/s/4tdswnmp79lj67c/unique_file_source.png?dl=0
> . Any Idea why it's doing this. Is it the rate of transmission
> that does this, like if it was to fast ?
>
> my setup :
> https://www.dropbox.com/s/snamjalklskfdzh/single_file.png?dl=0
>
> Thank you
>
>
>
>
> ___
> 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] Displaying angle measurements with a nice GUI

[Philip Balister]

On 06/15/2016 01:06 PM, Nick Foster wrote:
> You ought to be able to use PyQwt's compass widget:

Qwt is OK, but please do not use PyQwt. It is unmaintained. See:

https://sourceforge.net/p/pyqwt/mailman/message/30352623/

Philip

> 
> http://qwt.sourceforge.net/class_qwt_compass.html
> 
> I used it for gr-air-modes and, while ugly, it does work. There's no
> integration into GRC so the Python to integrate the widget will, of course,
> be your responsibility.
> 
> --n
> 
> On Wed, Jun 15, 2016 at 9:45 AM Martin Braun  wrote:
> 
>> Meny,
>>
>> no, we don't. A compass was one of the suggestions for this year's GSoC,
>> but no one signed up for that.
>>
>> M
>>
>> On 06/15/2016 04:34 AM, Meny Sidar wrote:
>>> Hi guys
>>>
>>> I'm looking for a nice GUI that can plot my AoA calculations in a some
>>> kind of a compass looking GUI.
>>> Does anything like that exists? or do i have to build one of my own?
>>> Don't really know how, and would prefer not to start learning Python
>>> right now (on a deadline).
>>>
>>> Any help would be much appreciated!
>>> Thanks,
>>> Meny
>>>
>>>
>>>
>>> ___
>>> 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] Displaying angle measurements with a nice GUI

[Nick Foster]

You ought to be able to use PyQwt's compass widget:

http://qwt.sourceforge.net/class_qwt_compass.html

I used it for gr-air-modes and, while ugly, it does work. There's no
integration into GRC so the Python to integrate the widget will, of course,
be your responsibility.

--n

On Wed, Jun 15, 2016 at 9:45 AM Martin Braun  wrote:

> Meny,
>
> no, we don't. A compass was one of the suggestions for this year's GSoC,
> but no one signed up for that.
>
> M
>
> On 06/15/2016 04:34 AM, Meny Sidar wrote:
> > Hi guys
> >
> > I'm looking for a nice GUI that can plot my AoA calculations in a some
> > kind of a compass looking GUI.
> > Does anything like that exists? or do i have to build one of my own?
> > Don't really know how, and would prefer not to start learning Python
> > right now (on a deadline).
> >
> > Any help would be much appreciated!
> > Thanks,
> > Meny
> >
> >
> >
> > ___
> > 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] Displaying angle measurements with a nice GUI

[Martin Braun]

Meny,

no, we don't. A compass was one of the suggestions for this year's GSoC,
but no one signed up for that.

M

On 06/15/2016 04:34 AM, Meny Sidar wrote:
> Hi guys
> 
> I'm looking for a nice GUI that can plot my AoA calculations in a some
> kind of a compass looking GUI.
> Does anything like that exists? or do i have to build one of my own?
> Don't really know how, and would prefer not to start learning Python
> right now (on a deadline).
> 
> Any help would be much appreciated!
> Thanks,
> Meny
> 
> 
> 
> ___
> 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] Retune Request Time

[Martin Braun]

Or try this:

tr = uhd.tune_request(900e6, 0)
tb.usrp.set_center_freq(tr)
tr = uhd.tune_request(901e6, -1e6)
tb.usrp.set_center_freq(tr)

M


On 06/14/2016 07:47 PM, Marcus D. Leech wrote:
> On 06/14/2016 09:39 PM, Richard Bell wrote:
>> I think I have a misunderstanding about the DSP tune, because it's not
>> behaving the way I expect it to. Let me describe my experiment.
>> Suppose I want to hop between two frequencies, 900e6 and 901e6, using
>> a sample rate of 500e3 and a usrp as a sink (transmitter).
>>
>> 1) If I use set_center_freq(900e6) and set_center_freq(901e6) in a
>> loop to hop between the two frequencies, it works just as you would
>> expect. I verified this by using a second USRP as a spectrum analyzer.
>>
>> 2) Now, If I use the following to make the same hop, I see a strong
>> static tone coming out at 900e6, and a small baby tone popping up and
>> down at 901e6. The baby tones are about 40 dB down from the static
>> tone. There are also even smaller image tones popping up and down at
>> the hop rate around 901e6.
>>
>> tr = uhd.tune_request(900e6, 1e6)
>> successful_hop = tb.usrp.set_center_freq(tr)
>>
>> and then on the next iteration
>>
>> tr = uhd.tune_request(900e6, 0)
>> successful_hop = tb.usrp.set_center_freq(tr)
>>
>> I'm expecting to see the exact same behavior as I did when using
>> set_center_freq in the first approach above, but I'm not. Am I
>> understanding the dsp_tune incorrectly?
>>
>> Rich
>>
> You should spend some time looking through this:
>
> http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>
> In the example, you gave the Fc is still 900Mhz, but with the FPGA
> providing an offset tuning.  That's not what you want.
>
> What you want is to set the target frequency to 901MHz, use POLICY_NONE
> on the RF side, and provide a 1e6 DSP_FREQ, with POLICY_MANUAL.
>
> POLICY_NONE means that it won't touch the already-tuned analog RF
frequency.
>
>
>>
>> On Tue, Jun 14, 2016 at 1:20 PM, Marcus D. Leech > > wrote:
>>
>> On 06/14/2016 03:13 PM, Richard Bell wrote:
>>> Martin,
>>>
>>> If I create a USRP object
>>>
>>> self.usrp = uhd.usrp_sink(device_addr=options.args,
>>> stream_args=uhd.stream_args('fc32'))
>>>
>>> and initialize the USRP center frequency to 900e6
>>>
>>> self.usrp.set_center_freq(900e6)
>>>
>>> and then do
>>>
>>> tr = uhd.tune_request(901e6, 1e3)
>>>
>>> followed by
>>>
>>> uhd.usrp_sink.get_center_freq()
>>>
>>> it returns the original center freq of 900e6. My question is what
>>> is the tune_request doing?
>>>
>>> Rich
>> uhd.tune_request() is just a constructor for a tune_request_t
>> object, it doesn't actually touch the hardware at all.  So, you
>> take that tr, and
>>   hand it to a uhd.usrp_sink.set_center_freq(tr).
>>
>>
>>
>>>
>>> On Mon, Jun 13, 2016 at 4:47 PM, Richard Bell
>>> mailto:richard.be...@gmail.com>> wrote:
>>>
>>> I can call the C++ functions from Python? Why is there a
>>> separate python API, I'm confused.
>>>
>>> Lets say I set an initial center frequency of 900 MHz to
>>> start the script off. You're saying that if the next
>>> frequency I want to hop to is within the ADC sampling rate,
>>> which in my case for the N210 is 100 MHz, I should manually
>>> tell the USRP to set the DSP_FREQ and leave the RF_FREQ alone
>>> for the fastest hop, and that the USRP automatic settings are
>>> not smart enough to figure this out?
>>>
>>> If the above is true, it seems I should do something like this:
>>> 1) Ask the USRP what the current RF_FREQ is
>>> 2) Find the difference between RF_FREQ and the new center freq
>>> 3) If the difference is greater then 100 MHz, change the RF
>>> Freq, otherwise change the DSP freq
>>>
>>> Is this correct?
>>>
>>> On Mon, Jun 13, 2016 at 4:03 PM, Martin Braun
>>> mailto:martin.br...@ettus.com>> wrote:
>>>
>>> Richard,
>>>
>>> "use DSP tuning when possible" is not a valid policy.
>>>
>>> In Python:
>>>
>>> from gnuradio import uhd
>>>
>>> rf_freq = 900e6
>>> dsp_freq = 1e3
>>> TR = uhd.tune_request(rf_freq, dsp_freq)
>>> # Oh look it worked:
>>> print TR.rf_freq_policy == uhd.tune_request.POLICY_MANUAL
>>>
>>>
>>> So, in a nutshell, rf_freq and dsp_freq are used
>>> depending on the
>>> respective policies, but there's no 'figure out smart
>>> tunes based on
>>> state' policy.
>>>
>>> -- M
>>>
>>>
>>> On 06/13/2016 03:49 PM, Richard Bell wrote:
>>> > Derek,
>>> >
>>> > that manual is the C++ API. How would I format the tune
>>> policy
>>> > information in python? It's not clear to me looking at
>>> 

[Discuss-gnuradio] Re channel state information on rx_ofdm.grc

[avinash kalyanaraman]

Hello all,

Could you please let me know how I can get channel-frequency response (like
channel state information (CSI) ) for an OFDM transmission? I am looking at
rx_ofdm.grc to capture the phase and amplitude at each of the 64
sub-carriers.

Would connecting the OFDM Channel Estimation Block of the HeaderStream to a
FileSink such that item_size is fft_size* gr.sizeof_gr_complex , give me
enough information to capture the CSI ?

 What would be the granularity of the aforementioned calculation?

I transmit using tx_ofdm.grc.

Please let me know.

Thanks!

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

Re: [Discuss-gnuradio] [GSoC] Weekly update for PyBOMBS and CGRAN integration

[Ravi Sharan]

Apologies for the double mail. I had accidentally sent the previous
response, even before compiling the complete mail.

That said, I am working on finishing the gui part and integration with
the pybombs API by this weekend, before the mid-term evaluation
period.

[1] https://gitlab.com/NinjaComics/pybombs-qtgui

On Wed, Jun 15, 2016 at 8:05 PM, Ravi Sharan
 wrote:
> Hi Ben,
>
> Thanks for the feedback.
>
> 1. I have created a new repo for the Pybombs frontend on Gitlab [1]
> recently. During my weekly interaction sessions with Martin, we have
> decided to make the gui-frontend installable from pybombs-cli itself.
> Initially, I had plans on integrating the gui-frontend with the
> pybombs, but GUI being a personal preference, it was decided to have
> it as a separate project.
>
> 2. I am using a table view as demo'ed in the screencast, which has a
> 'Status' column that indicates whether the package is already
> installed or not.
>
> 3. Currently, the pybombs' recipe manager uses a technique to handle
> the prefix specific recipes (if that's what you mean by private
> recipes). I am planning to include a Recipe manager dialog to the UI,
> which address this need.
>
> 4. The UI definitely displays the documentation and dependencies. I
> have included a 'Module Info' dialog which generate the dependencies
> based on the recipe. On the documentation front, I have still not
> decided whether to provide links to the module's CGRAN page or fetch
> the Manifest file from each project during runtime to display the
> information (handling screenshots/images in the dialog can be a
> problem in the second case).
>
>
> On Tue, Jun 14, 2016 at 11:07 PM, Ben Hilburn  wrote:
>> Hi Ravi -
>>
>> Thanks for the update! I really appreciate you going through the effort of
>> posting a screencast, as well.
>>
>> A few questions:
>>
>> Where is the repository that you are pushing your code to?
>> I think it would be useful if the UI indicated which packages were already
>> installed. You may be planning for this, already.
>> How will the UI handle private recipe lists?
>> Will the UI give any information regarding the dependencies of the packages?
>>
>> Thanks!
>>
>> Cheers,
>> Ben
>>
>> On Sun, Jun 12, 2016 at 1:26 AM, Ravi Sharan
>>  wrote:
>>>
>>> Hi All,
>>>
>>> I have written a small blog post [1] on my weekly progress for the
>>> PyBOMBS and CGRAN integration project which I am working on for GSoC.
>>> Also, I have recorded a small screencast [2] on the progress so far
>>> with the GUI. I will be happy to receive any feedback and suggestions
>>> on the GUI design. Thanks in advance.
>>>
>>> Cheers,
>>> Ravi
>>>
>>> [1] - http://ninjacomics.github.io/radioblogr/2016/06/gsoc_week2_3.html
>>> [2] - https://www.youtube.com/watch?v=VVN534cHtm4
>>>
>>> ___
>>> 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] Weekly update for PyBOMBS and CGRAN integration

[Ravi Sharan]

Hi Ben,

Thanks for the feedback.

1. I have created a new repo for the Pybombs frontend on Gitlab [1]
recently. During my weekly interaction sessions with Martin, we have
decided to make the gui-frontend installable from pybombs-cli itself.
Initially, I had plans on integrating the gui-frontend with the
pybombs, but GUI being a personal preference, it was decided to have
it as a separate project.

2. I am using a table view as demo'ed in the screencast, which has a
'Status' column that indicates whether the package is already
installed or not.

3. Currently, the pybombs' recipe manager uses a technique to handle
the prefix specific recipes (if that's what you mean by private
recipes). I am planning to include a Recipe manager dialog to the UI,
which address this need.

4. The UI definitely displays the documentation and dependencies. I
have included a 'Module Info' dialog which generate the dependencies
based on the recipe. On the documentation front, I have still not
decided whether to provide links to the module's CGRAN page or fetch
the Manifest file from each project during runtime to display the
information (handling screenshots/images in the dialog can be a
problem in the second case).


On Tue, Jun 14, 2016 at 11:07 PM, Ben Hilburn  wrote:
> Hi Ravi -
>
> Thanks for the update! I really appreciate you going through the effort of
> posting a screencast, as well.
>
> A few questions:
>
> Where is the repository that you are pushing your code to?
> I think it would be useful if the UI indicated which packages were already
> installed. You may be planning for this, already.
> How will the UI handle private recipe lists?
> Will the UI give any information regarding the dependencies of the packages?
>
> Thanks!
>
> Cheers,
> Ben
>
> On Sun, Jun 12, 2016 at 1:26 AM, Ravi Sharan
>  wrote:
>>
>> Hi All,
>>
>> I have written a small blog post [1] on my weekly progress for the
>> PyBOMBS and CGRAN integration project which I am working on for GSoC.
>> Also, I have recorded a small screencast [2] on the progress so far
>> with the GUI. I will be happy to receive any feedback and suggestions
>> on the GUI design. Thanks in advance.
>>
>> Cheers,
>> Ravi
>>
>> [1] - http://ninjacomics.github.io/radioblogr/2016/06/gsoc_week2_3.html
>> [2] - https://www.youtube.com/watch?v=VVN534cHtm4
>>
>> ___
>> 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 companion Options block ID

[Sebastian Koslowski]

Hey Wayne,

You are right, a check would be good. The same issue can occur for variable 
blocks.

Thanks,
Sebastian 

Sent from BlueMail



On Jun 14, 2016, 15:28, at 15:28, Wayne Roberts  wrote:
>It would seem that the ID entered into options block of gnuradio
>companion
>is used as the class name of the generated python script.  (defaults to
>top_block)
>But there is one source of trouble with that.
>What if I put into ID field some name which could be same as some
>imported
>module.
>This could happen if your working on OOT module, and put into ID of
>options
>block the same name as your OOT module. It gives you the error:
>AttributeError: 'module' object has no attribute 'foobar'
>Perhaps some little check should be put into gnuradio-companion to
>prevent
>the name conflict.
>
>
>
>
>___
>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] Displaying angle measurements with a nice GUI

[Meny Sidar]

Hi guys

I'm looking for a nice GUI that can plot my AoA calculations in a some kind
of a compass looking GUI.
Does anything like that exists? or do i have to build one of my own?
Don't really know how, and would prefer not to start learning Python right
now (on a deadline).

Any help would be much appreciated!
Thanks,
Meny
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio