Re: [Discuss-gnuradio] I hate Unity

[Paul M. Bendixen]

I have had no problems installing Gnu Radio under Kubuntu.
If you already have a potent machine, try that. It gives the added bonus of
being much prettier than Gnome ;)

Best Regards
Paul M. Bendixen

2011/10/17 Ben Hilburn 

> N.B.: What follows is obviously all opinion:
>
> I can't stand Unity, and the default settings for Gnome 3 drove me nuts.
>
> If you are willing to put the effort in, you can install a bunch of
> extensions that will make it at least approach the usability of Gnome 2.
>
> I recommend:
> http://intgat.tigress.co.uk/rmy/extensions/gnome32.html
> http://www.webupd8.org/2011/10/official-gnome-shell-extensions.html
>
> After installing, restart Gnome, and then use the 'Advanced Settings' menu
> (which is actually a shortcut to the tool Bob mentioned, gnome-tweak-tool)
> to enable the extensions you want.
>
> I was able to almost achieve what I had in Gnome 2 by doing this - although
> there are still some annoyances.
>
> I really don't understand why Gnome3 took this giant step backwards, and
> Canonical took Ubuntu even further backwards with Unity.
>
> Cheers,
> Ben
>
> On Mon, Oct 17, 2011 at 11:10 AM, Vincenzo Pellegrini 
> wrote:
>
>> Just a couple of lines to cast my ballot in favor of Bob's complaint.
>>
>> I had the same reaction in response to Fedora 15 reception of the Gnome3
>> thing.
>> That stuff does move too far away from the power-user-desktop concept I've
>> been enjoying for several years as a developer.
>>
>> Also I'm a bit frustrated to have to go after that load of "tweaks" in
>> order to get a freshly installed system usable.
>>
>> my best regards to everybody there
>>
>> vince
>>
>>
>> 2011/10/17 Alexandru Csete 
>>
>>> On Mon, Oct 17, 2011 at 7:28 PM, Tom Rondeau 
>>> wrote:
>>> > On Mon, Oct 17, 2011 at 10:39 AM, Robert McGwier 
>>> > wrote:
>>> >>
>>> >> Install gnome-tweak-tools to get advanced settings for gnome to be
>>> able to
>>> >> get your favorite settings after you install gnome-shell.
>>> >>
>>> >> On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier >> >
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/
>>> >>>
>>> >>> --
>>> >>> Bob McGwier
>>> >>> Facebook: N4HYBob
>>> >>> ARS: N4HY
>>> >
>>> > Or do what I did: apt-get install gnome-session-fallback and switch to
>>> Gnome
>>> > Classic Mode at the login screen. Removes Unity.
>>> > I haven't heard anyone say a good thing about Unity. It's an awful
>>> > environment to develop under. The first thing I do in Ubuntu now is
>>> stop
>>> > using it.
>>> > I'm now shopping around for another Linux distro if they keep going
>>> this
>>> > way.
>>> > Tom
>>>
>>> On Ubuntu 11.04 I have installed Xfce desktop ( http://www.xfce.org/ )
>>> - it is available via the package manager (or by installing xubuntu
>>> instead of regular ubuntu). It is similar to Gnome 2 and is very
>>> lightweight.
>>>
>>> Alex
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Vincenzo Pellegrini
>> http://www.youtube.com/user/wwvince1
>>
>> ___
>> 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] OFDM Transmiter and receiver by using USRP1

[waqasme]

hi Marcus,

I am attaching the screen shots and also block diagram of transmitter..
right now i am just trying to look for transmission of OFDM signal via
usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the
typical ofdm signal but on the other hand in usrp sink on the spectrum
analyser i saw only simple sine wave peak. please have a look and let me
know if there is something else do i need to do to generate the proper ofdm
signal on the spectrum analyser.

/home/hp/Desktop/spectrumoutput.jpeg 
http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg 



Block diagram in GNU radio
/home/hp/Documents/finaltesting.grc 
http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc 


Please have a look and suggest me how to fix this problem in order to see
the proper ofdm signal on spectrum analyser as well?? Do i need and firm
ware update or sumthing on FPGA on usrp1 ???
Looking forward to hear from you.

Thanks for your help.
Cheers.



Marcus D. Leech wrote:
> 
> On 10/16/2011 05:55 PM, waqasme wrote:
>> Hi Marcus,
>>
>> As i mentioned the flow graph signal blocks i have used in gnu radio
>> companion from that i am getting this out put on FFT sink in GNU radio
>> companion simulation flowgraph which is similar like this
>>
>>
>>
>>
> If you're trying to embed images, it's not working, and the de-embedded 
> ones on the bottom show only
>the spectrum of something typical of OFDM, and a spectrum-analyser 
> output that looks like it was
>set up to sweep from 10Hz to 5GHz (is that what you had in mind?), 
> which would produce only a sharp
>peak in the middle.
> 
> We still don't know what your flow-graph(s) look like.
> 
> -- 
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32675018.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] Odd behaviur of "Fractional Interpolator"

[Mattia Rizzi]

I’m using gnuradio-3.3.0 with GRC.
I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1 MHz of 
frequency), the fractional interpolator with 12/8 value for interpolation and a 
FFT sink with 12MS/s of sample rate. (throttle block included).
I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz cosine. If 
i put 8/12 (the inverse) i see the (correct) 1MHz cosine.
Why?
If i use the Rational resampler, with interpolation 12 and decimation 8, i see 
the correct 1MHz cosine. What’s wrong with fractional interpolator block?___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Odd behaviur of "Fractional Interpolator"

[Marcus D. Leech]

On 18/10/11 01:38 PM, Mattia Rizzi wrote:
> I’m using gnuradio-3.3.0 with GRC.
> I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1
> MHz of frequency), the fractional interpolator with 12/8 value for
> interpolation and a FFT sink with 12MS/s of sample rate. (throttle
> block included).
> I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz
> cosine. If i put 8/12 (the inverse) i see the (correct) 1MHz cosine.
> Why?
> If i use the Rational resampler, with interpolation 12 and decimation
> 8, i see the correct 1MHz cosine. What’s wrong with fractional
> interpolator block?
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>   
Because the fractional interpolator takes the *inverse* as the desired
fraction--think of it as a decimation
  ratio.



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

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

[Discuss-gnuradio] Fw: Odd behaviur of "Fractional Interpolator"

[Mattia Rizzi]

Uhm, so it’s a little bit confusing.
Another strange problem is that if i put a 0.64 value of interpolation, and my 
flow graph is a file souce->fractional interpolator->file sink, and my source 
file is 1GB of data, i’m expecting a 1GB*1/0.64 output filesize. But when i run 
the graph i get a 800MB of output filesize, minor than the source file. I 
cannot undestand this...
Thank you.

From: Marcus D. Leech 
Sent: Tuesday, October 18, 2011 7:45 PM
To: discuss-gnuradio@gnu.org 
Subject: Re: [Discuss-gnuradio] Odd behaviur of "Fractional Interpolator"

On 18/10/11 01:38 PM, Mattia Rizzi wrote: 
  I’m using gnuradio-3.3.0 with GRC.
  I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1 MHz of 
frequency), the fractional interpolator with 12/8 value for interpolation and a 
FFT sink with 12MS/s of sample rate. (throttle block included).
  I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz cosine. 
If i put 8/12 (the inverse) i see the (correct) 1MHz cosine.
  Why?
  If i use the Rational resampler, with interpolation 12 and decimation 8, i 
see the correct 1MHz cosine. What’s wrong with fractional interpolator block?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
  Because the fractional interpolator takes the *inverse* as the desired 
fraction--think of it as a decimation
  ratio.




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


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

Re: [Discuss-gnuradio] Odd behaviur of "Fractional Interpolator"

[Mattia Rizzi]

Sorry, the filesize is my mistake. All okay now. Thank you.

From: Mattia Rizzi 
Sent: Tuesday, October 18, 2011 8:12 PM
To: gnu radio 
Subject: Fw: [Discuss-gnuradio] Odd behaviur of "Fractional Interpolator"

Uhm, so it’s a little bit confusing.
Another strange problem is that if i put a 0.64 value of interpolation, and my 
flow graph is a file souce->fractional interpolator->file sink, and my source 
file is 1GB of data, i’m expecting a 1GB*1/0.64 output filesize. But when i run 
the graph i get a 800MB of output filesize, minor than the source file. I 
cannot undestand this...
Thank you.

From: Marcus D. Leech 
Sent: Tuesday, October 18, 2011 7:45 PM
To: discuss-gnuradio@gnu.org 
Subject: Re: [Discuss-gnuradio] Odd behaviur of "Fractional Interpolator"

On 18/10/11 01:38 PM, Mattia Rizzi wrote: 
  I’m using gnuradio-3.3.0 with GRC.
  I’ve builded a graph with a Complex cosine (8Ms/s of sample rate and 1 MHz of 
frequency), the fractional interpolator with 12/8 value for interpolation and a 
FFT sink with 12MS/s of sample rate. (throttle block included).
  I’m expecting to see a 1MHz cosine with the FFT, but i see a 2.25MHz cosine. 
If i put 8/12 (the inverse) i see the (correct) 1MHz cosine.
  Why?
  If i use the Rational resampler, with interpolation 12 and decimation 8, i 
see the correct 1MHz cosine. What’s wrong with fractional interpolator block?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
  Because the fractional interpolator takes the *inverse* as the desired 
fraction--think of it as a decimation
  ratio.




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


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

Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1

[Marcus D. Leech]

>
> hi Marcus,
>
> I am attaching the screen shots and also block diagram of transmitter..
> right now i am just trying to look for transmission of OFDM signal via
> usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the
> typical ofdm signal but on the other hand in usrp sink on the spectrum
> analyser i saw only simple sine wave peak. please have a look and let me
> know if there is something else do i need to do to generate the proper ofdm
> signal on the spectrum analyser.
>
> /home/hp/Desktop/spectrumoutput.jpeg 
> http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg 
>
>
>
> Block diagram in GNU radio
> /home/hp/Documents/finaltesting.grc 
> http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc 
>   
Your flow-graph appears to be badly confused about bandwidths and
interpolations and sample rates
  --an interpolation ratio on your USRP1 sink of 100e6 is almost
certainly *not* what you had in mind.

You probably need to learn more about all of that, and get some better
notions of how the OFDM
  modulator block works.  At the very least you'll need to
fractionally-interpolate the baseband
  up to some sample rather that *can* reasonably be further interpolated
by the USRP1 hardware.

Given how simple this graph currently is, I'd *strongly* suggest that
you upgrade your "world" to UHD,
  since your investment in the "old world" is still rather small.


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


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

Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1

[Tom Rondeau]

On Oct 18, 2011, at 11:18 AM, "Marcus D. Leech"  wrote:

>> 
>> hi Marcus,
>> 
>> I am attaching the screen shots and also block diagram of transmitter..
>> right now i am just trying to look for transmission of OFDM signal via
>> usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see the
>> typical ofdm signal but on the other hand in usrp sink on the spectrum
>> analyser i saw only simple sine wave peak. please have a look and let me
>> know if there is something else do i need to do to generate the proper ofdm
>> signal on the spectrum analyser.
>> 
>> /home/hp/Desktop/spectrumoutput.jpeg 
>> http://old.nabble.com/file/p32675018/spectrumoutput.jpeg spectrumoutput.jpeg 
>> 
>> 
>> 
>> Block diagram in GNU radio
>> /home/hp/Documents/finaltesting.grc
>> http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc 
>> 
> Your flow-graph appears to be badly confused about bandwidths and
> interpolations and sample rates
>  --an interpolation ratio on your USRP1 sink of 100e6 is almost
> certainly *not* what you had in mind.
> 
> You probably need to learn more about all of that, and get some better
> notions of how the OFDM
>  modulator block works.  At the very least you'll need to
> fractionally-interpolate the baseband
>  up to some sample rather that *can* reasonably be further interpolated
> by the USRP1 hardware.
> 
> Given how simple this graph currently is, I'd *strongly* suggest that
> you upgrade your "world" to UHD,
>  since your investment in the "old world" is still rather small.
> 
> 
>> 
>> 
> -- 
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium

As of last night, the 'next' branch of GNU Radio (if you are using git) has the 
OFDM code and examples rewritten using UHD. 

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

Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1

[waqasme]

Hello Marcus thanks for your reply.. Well the problem is there is not much
documentation available on internet on usurp .. Also I am quite new to gnu
radio and usrp1 ... I tried to play with interpolation and decimation
settings but didnot get the desired ofdm signal .. I am not sure what else I
can do to fix this problem . If u know any documentation regarding that
please do let me know . U mentioned about UHd but I could not find any UHd
blocks in gnu radio .. As I saw in one example someone use UHd .. Iam using
Ubuntu 10.10 and gnu radio companion 3.2.2 version .. I will really
appreciate if u can guide me how to setup the settings or specs i need for
usrp 1 .. Thanks and regards...

Marcus D. Leech wrote:
> 
>>
>> hi Marcus,
>>
>> I am attaching the screen shots and also block diagram of transmitter..
>> right now i am just trying to look for transmission of OFDM signal via
>> usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see
>> the
>> typical ofdm signal but on the other hand in usrp sink on the spectrum
>> analyser i saw only simple sine wave peak. please have a look and let me
>> know if there is something else do i need to do to generate the proper
>> ofdm
>> signal on the spectrum analyser.
>>
>> /home/hp/Desktop/spectrumoutput.jpeg 
>> http://old.nabble.com/file/p32675018/spectrumoutput.jpeg
>> spectrumoutput.jpeg 
>>
>>
>>
>> Block diagram in GNU radio
>> /home/hp/Documents/finaltesting.grc 
>> http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc 
>>   
> Your flow-graph appears to be badly confused about bandwidths and
> interpolations and sample rates
>   --an interpolation ratio on your USRP1 sink of 100e6 is almost
> certainly *not* what you had in mind.
> 
> You probably need to learn more about all of that, and get some better
> notions of how the OFDM
>   modulator block works.  At the very least you'll need to
> fractionally-interpolate the baseband
>   up to some sample rather that *can* reasonably be further interpolated
> by the USRP1 hardware.
> 
> Given how simple this graph currently is, I'd *strongly* suggest that
> you upgrade your "world" to UHD,
>   since your investment in the "old world" is still rather small.
> 
> 
>>
>>   
> -- 
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32677135.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] OFDM Transmiter and receiver by using USRP1

[waqasme]

Hello Marcus thanks for your reply.. Well the problem is there is not much
documentation available on internet on usurp .. Also I am quite new to gnu
radio and usrp1 ... I tried to play with interpolation and decimation
settings but didnot get the desired ofdm signal .. I am not sure what else I
can do to fix this problem . If u know any documentation regarding that
please do let me know . U mentioned about UHd but I could not find any UHd
blocks in gnu radio .. As I saw in one example someone use UHd .. Iam using
Ubuntu 10.10 and gnu radio companion 3.2.2 version .. I will really
appreciate if u can guide me how to setup the settings or specs i need for
usrp 1 .. Thanks and regards...

Marcus D. Leech wrote:
> 
>>
>> hi Marcus,
>>
>> I am attaching the screen shots and also block diagram of transmitter..
>> right now i am just trying to look for transmission of OFDM signal via
>> usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see
>> the
>> typical ofdm signal but on the other hand in usrp sink on the spectrum
>> analyser i saw only simple sine wave peak. please have a look and let me
>> know if there is something else do i need to do to generate the proper
>> ofdm
>> signal on the spectrum analyser.
>>
>> /home/hp/Desktop/spectrumoutput.jpeg 
>> http://old.nabble.com/file/p32675018/spectrumoutput.jpeg
>> spectrumoutput.jpeg 
>>
>>
>>
>> Block diagram in GNU radio
>> /home/hp/Documents/finaltesting.grc 
>> http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc 
>>   
> Your flow-graph appears to be badly confused about bandwidths and
> interpolations and sample rates
>   --an interpolation ratio on your USRP1 sink of 100e6 is almost
> certainly *not* what you had in mind.
> 
> You probably need to learn more about all of that, and get some better
> notions of how the OFDM
>   modulator block works.  At the very least you'll need to
> fractionally-interpolate the baseband
>   up to some sample rather that *can* reasonably be further interpolated
> by the USRP1 hardware.
> 
> Given how simple this graph currently is, I'd *strongly* suggest that
> you upgrade your "world" to UHD,
>   since your investment in the "old world" is still rather small.
> 
> 
>>
>>   
> -- 
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32677136.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] OFDM Transmiter and receiver by using USRP1

[waqasme]

Hello Marcus thanks for your reply.. Well the problem is there is not much
documentation available on internet on usurp .. Also I am quite new to gnu
radio and usrp1 ... I tried to play with interpolation and decimation
settings but didnot get the desired ofdm signal .. I am not sure what else I
can do to fix this problem . If u know any documentation regarding that
please do let me know . U mentioned about UHd but I could not find any UHd
blocks in gnu radio .. As I saw in one example someone use UHd .. Iam using
Ubuntu 10.10 and gnu radio companion 3.2.2 version .. I will really
appreciate if u can guide me how to setup the settings or specs i need for
usrp 1 .. Thanks and regards...

Marcus D. Leech wrote:
> 
>>
>> hi Marcus,
>>
>> I am attaching the screen shots and also block diagram of transmitter..
>> right now i am just trying to look for transmission of OFDM signal via
>> usrp1. As i mentioned earlier in the fft scope plot in gnu radio i see
>> the
>> typical ofdm signal but on the other hand in usrp sink on the spectrum
>> analyser i saw only simple sine wave peak. please have a look and let me
>> know if there is something else do i need to do to generate the proper
>> ofdm
>> signal on the spectrum analyser.
>>
>> /home/hp/Desktop/spectrumoutput.jpeg 
>> http://old.nabble.com/file/p32675018/spectrumoutput.jpeg
>> spectrumoutput.jpeg 
>>
>>
>>
>> Block diagram in GNU radio
>> /home/hp/Documents/finaltesting.grc 
>> http://old.nabble.com/file/p32675018/finaltesting.grc finaltesting.grc 
>>   
> Your flow-graph appears to be badly confused about bandwidths and
> interpolations and sample rates
>   --an interpolation ratio on your USRP1 sink of 100e6 is almost
> certainly *not* what you had in mind.
> 
> You probably need to learn more about all of that, and get some better
> notions of how the OFDM
>   modulator block works.  At the very least you'll need to
> fractionally-interpolate the baseband
>   up to some sample rather that *can* reasonably be further interpolated
> by the USRP1 hardware.
> 
> Given how simple this graph currently is, I'd *strongly* suggest that
> you upgrade your "world" to UHD,
>   since your investment in the "old world" is still rather small.
> 
> 
>>
>>   
> -- 
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OFDM-Transmiter-and-receiver-by-using-USRP1-tp32662445p32677138.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] GrBlock

[Josh Blum]

On 10/18/2011 11:18 AM, Jason Bonior wrote:
> That worked. We will also try your next version whenever it is available on

Glad to hear it works; I guess zip() cant be used with swig'd vectors on
some platforms (my best guess).

I reworked the code a bit to my liking and it should also fix this
issue. Just grab the latest master branch.

> git. We will also begin building some custom blocks using grblock and numpy
> and can let you know how it goes if you wish.
> 

of course. It would be interesting to see what you come up with and
possibly how performance compares.

-Josh


> Thanks again,
> Jason
> 
> 
> 
> On Tue, Oct 18, 2011 at 9:38 AM, Josh Blum  wrote:
> 
>>
>>
>> On 10/18/2011 06:54 AM, Jason Bonior wrote:
>>> We added some print statements to try and narrow down the problem. This
>> is
>>> what we changed:
>>>
>>> def pointer_to_ndarray(addr, dtype, nitems):
>>>print "pointer_to_ndarray() start"
>>>class array_like:
>>>print "pointer_to_ndarray array_like class start"
>>>__array_interface__ = {
>>>'data' : (addr, False),
>>>'typestr' : dtype.base.str,
>>>'descr' : dtype.base.descr,
>>>'shape' : (nitems,) + dtype.shape,
>>>'strides' : None,
>>>'version' : 3
>>>}
>>>print "pointer_to_ndarray array_like class end"
>>>print "pointer_to_ndarray() end"
>>>return numpy.asarray(array_like()).view(dtype.base)
>>>#a = numpy.asarray(array_like()).view(dtype.base)
>>>#return a.tolist()
>>>
>>> def pointers_to_ndarrays(addrs, dtypes, nitems):
>>>print "pointers_to_ndarrays() start, end"
>>>print "addrs = ", addrs
>>>print "dtypes = ", dtypes
>>>print "nitems = ", nitems
>>>
>>> This is what we get:
>>>
>>> local@ch400l-laptop:~$ /usr/local/share/grblock/examples/adder_demo.py
>>> gateway_block.__init__() start
>>> gateway_handler.__init__() start
>>> gateway_handler.__init__() end
>>> gateway_block.__init__() end
>>> gateway_handler.handle() start
>>> gateway_block.__grblock_handle() start
>>> gateway_block.__grblock_handle() end
>>> gateway_handler.handle() end
>>> gateway_handler.handle() start
>>> gateway_block.__grblock_handle() start
>>> pointers_to_ndarrays() start, end
>>> addrs =  >> type 'std::vector< size_t > *' at 0x235a720> >
>>> dtypes =  [dtype('float32'), dtype('float32')]
>>> nitems =  [5, 5]
>>> handler caught exception: Unknown exception
>>> Traceback (most recent call last):
>>>  File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line
>> 65,
>>> in handle
>>>try: self._callback()
>>>  File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line
>> 137,
>>> in __grblock_handle
>>>[self.__message.work_args.ninput_items]*len(self.__in_sig),
>>>  File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line
>> 51,
>>> in pointers_to_ndarrays
>>>return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes,
>> nitems)]
>>>  File
>>>
>> "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py",
>>> line 118, in next
>>>return _gnuradio_core_hier.SwigPyIterator_next(self)
>>> RuntimeError: Unknown exception
>>> gateway_handler.handle() start
>>> gateway_block.__grblock_handle() start
>>> gateway_block.__grblock_handle() end
>>> gateway_handler.handle() end
>>> thread[thread-per-block[2]: ]: caught
>> unrecognized
>>> exception
>>> ^Cexcepted (1, 5, 9, 13, 17)
>>> actual ()
>>> gateway_block.__init__() start
>>> gateway_handler.__init__() start
>>> gateway_handler.__init__() end
>>> gateway_block.__init__() end
>>> gateway_handler.handle() start
>>> gateway_block.__grblock_handle() start
>>> gateway_block.__grblock_handle() end
>>> gateway_handler.handle() end
>>> gateway_handler.handle() start
>>> gateway_block.__grblock_handle() start
>>> pointers_to_ndarrays() start, end
>>> addrs =  >> type 'std::vector< size_t > *' at 0x235aa20> >
>>> dtypes =  [dtype('complex64'), dtype('complex64')]
>>> nitems =  [5, 5]
>>> handler caught exception: Unknown exception
>>> Traceback (most recent call last):
>>>  File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line
>> 65,
>>> in handle
>>>try: self._callback()
>>>  File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line
>> 137,
>>> in __grblock_handle
>>>[self.__message.work_args.ninput_items]*len(self.__in_sig),
>>>  File "/usr/local/lib/python2.6/dist-packages/grblock/gateway.py", line
>> 51,
>>> in pointers_to_ndarrays
>>>return [pointer_to_ndarray(*args) for args in zip(addrs, dtypes,
>> nitems)]
>>>  File
>>>
>> "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_hier.py",
>>> line 118, in next
>>>return _gnuradio_core_hier.SwigPyIterator_next(self)
>>> RuntimeError: Unknown exception
>>> gateway_handler.handle() start
>>> gateway_block.__grblock_handle() start
>>> gateway_block.__grblock_handle() end
>>> gateway_handler.handle() end
>>> thread[thread-per-block[2]: ]: caught
>> unreco

Re: [Discuss-gnuradio] OFDM Transmiter and receiver by using USRP1

[Marcus D. Leech]

>
> Hello Marcus thanks for your reply.. Well the problem is there is not much
> documentation available on internet on usurp .. Also I am quite new to gnu
> radio and usrp1 ... I tried to play with interpolation and decimation
> settings but didnot get the desired ofdm signal .. I am not sure what else I
> can do to fix this problem . If u know any documentation regarding that
> please do let me know . U mentioned about UHd but I could not find any UHd
> blocks in gnu radio .. As I saw in one example someone use UHd .. Iam using
> Ubuntu 10.10 and gnu radio companion 3.2.2 version .. I will really
> appreciate if u can guide me how to setup the settings or specs i need for
> usrp 1 .. Thanks and regards...
>
>   
Try using:

http://www.sbrac.org/files/build-gnuradio

On your Ubuntu platform.  It will build and install everything required
for a modern
  UHD-supporting Gnu Radio environment.

While I agree that documentation is sparse, the problems with your
flow-graph indicate to me
  problems at a conceptual level.  Have you looked at the GRC Tutorials?

www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_*tutorial*1.pdf


Also:

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

And:

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

And:


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

And:

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


But if you don't really have a clear notion of what interpolation and
decimation are all about, none of
  the above will be of much help.  You need a basic introduction to
Digital Signal Processing, and
  going down the Gnu Radio path isn't a substitute for such background.


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

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

[Discuss-gnuradio] Postdoctoral position open at the University of Utah

[Neal Patwari]

Dear Colleagues,

The following postdoctoral position at the University of Utah is now
open, and we are accepting applications.

The Department of Electrical and Computer Engineering and the Sensing
and Processing Across Networks (SPAN) Lab at the University of Utah
(http://span.ece.utah.edu/) invites applications for an open
postdoctoral fellow position for research in radio tomography, a
research area at the intersection of statistical signal processing,
radio wave propagation, and wireless networking. The SPAN lab, led by
Prof. Neal Patwari, has significant expertise in radio channel signal
processing for location estimation in wireless networks, including the
2008 ACM MobiCom Best Student Research Demo Award, a 2009 IEEE Signal
Processing Magazine Best Paper Award, and significant popular press,
including articles in MIT Technology Review, ScienceNOW, CNET,
Engadget, Wired, Discover, Der Speigel, and The Economist. The SPAN
lab is at the forefront of the area of device-free localization,
having published six journal papers and three conference papers on the
topic in the past three years. We have also developed methods to use
wireless networks for breathing monitoring. This postdoctoral position
would expand the state-of-the-art in the capability of wireless
networks to learn about the positions and context of people in an
environment, for both emergency situations, and for everyday
applications.

About the Position:

The postdoctoral fellow position would start as soon as November,
2011, or as late as January, 2012, and would last from one to two
years, based on research performance.

The candidate must have a strong publication record including a
history of presenting / publishing in the top conferences and
journals. We are looking for a candidate with:

-  A Ph.D. in Electrical Engineering or Computer Science.
-  A strong background in statistical signal processing and/or
wireless networking.

Other skills that would benefit a candidate include: experimental
experience, understanding of radio wave propagation, and leadership or
mentoring experience.

About the University of Utah:

The University of Utah is located in Salt Lake City, Utah, which is
unique for the outdoor activities available within a short drive of a
major city. There are seven ski resorts within a 45 minute drive, six
US national parks within the state borders, and many other public
lands, including national forests accessible within minutes of Salt
Lake.

The University of Utah is well known for its research and
entrepreneurial success. The U. of Utah is ranked 1st in the nation
for creating new startup companies from research-based inventions, by
the Association of University Technology Managers. More than 100 local
companies have been founded by engineering graduates and faculty. In
the last fiscal year, the University of Utah received $451 million in
federal research funding, twice what it was six years ago. The
University is particularly known for sensor network research, and has
put significant resources into an cross-disciplinary group of faculty
and facilities.

To Apply:

Application materials include (1) CV, (2) Link to homepage where most
significant publications are available, and (3) contact information
for three references. Send materials via email to Prof. Neal Patwari,
npatwari at ece dot utah dot edu, with the subject, Postdoc
Application.

Regards,

Prof. Neal Patwari
University of Utah
Department of Electrical and Computer Engineering
Director, Sensing and Processing Across Networks (SPAN) Lab
http://span.ece.utah.edu/

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

[Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Nowlan, Sean]

Perhaps this is the wrong place to post this error, but I'm hoping for a quick 
response :)

I'm getting a "network unreachable" error on an E100 when trying to run 
benchmark_tx.py from the gnuradio "next" branch (Tom Rondeau?). Command line & 
error, and output of uhd_usrp_probe are attached.

Thanks!
Sean
root@usrp-e1xx:/usr/local/share/gnuradio/examples/digital# ./benchmark_tx.py -f 
9 --tx-amplitude=0.36 -v --tx-gain=0.0 -r 4 -m bpsk

linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
UHD_003.003.000-e0a7b8a

Traceback (most recent call last):
  File "./benchmark_tx.py", line 148, in 
main()
  File "./benchmark_tx.py", line 112, in main
tb = my_top_block(mods[options.modulation], options)
  File "./benchmark_tx.py", line 49, in __init__
options.antenna, options.verbose)
  File "/usr/local/share/gnuradio/examples/digital/uhd_interface.py", line 135, 
in __init__
freq, gain, antenna)
  File "/usr/local/share/gnuradio/examples/digital/uhd_interface.py", line 51, 
in __init__
num_channels=1)
  File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/__init__.py", line 
84, in constructor_interceptor
return old_constructor(*args, **kwargs)
  File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line 
2003, in usrp_sink
return _uhd_swig.usrp_sink(*args, **kwargs)
RuntimeError: Network is unreachable
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
UHD_003.003.000-e0a7b8a

-- Opening device node /dev/usrp_e0...
-- Initializing FPGA clock to 64.00MHz...
-- USRP-E100 clock control: 6
--   r_counter: 1
--   a_counter: 0
--   b_counter: 12
--   prescaler: 8
--   vco_divider: 2
--   chan_divider: 15
--   vco_rate: 1920.00MHz
--   chan_rate: 960.00MHz
--   out_rate: 64.00MHz
-- 
-- Performing wishbone readback test... pass
-- Found a Jackson Labs GPS
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
  _
 /
|   Device: E-Series Device
| _
|/
|   |   Mboard: E100 (euewanee)
|   |   vendor: 3
|   |   device: 1
|   |   revision: 4
|   |   content: 0
|   |   model: E100
|   |   serial: E2R11Y3E1
|   |   
|   |   Time sources: none, external, _external_
|   |   Clock sources: internal, external, auto
|   |   Sensors: ref_locked, gps_gpgga, gps_gprmc, gps_gpgsa, gps_time, 
gps_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |   Freq range: -32.000 to 32.000 Mhz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |   Freq range: -32.000 to 32.000 Mhz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: RFX900 (0x0025)
|   |   |   Serial: E0R11X1R9
|   |   | _
|   |   |/
|   |   |   |   RX Subdev: 0
|   |   |   |   Name: RFX900 (0x0025)
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: lo_locked, rssi
|   |   |   |   Freq range: 750.000 to 1050.000 Mhz
|   |   |   |   Gain range PGA0: 0.0 to 70.0 step 0.0 dB
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ad9522
|   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |   Freq range: -32.000 to 32.000 Mhz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: RFX900 (0x0029)
|   |   |   Serial: E0R11X1R9
|   |   | _
|   |   |/
|   |   |   |   TX Subdev: 0
|   |   |   |   Name: RFX900 (0x0029)
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 750.000 to 1050.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: Yes
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: ad9522
|   |   |   |   Gain range pga: -20.0 to 0.0 step 0.1 dB

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

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Marcus D. Leech]

Perhaps this is the wrong place to post this error, but I'm hoping for 
a quick response J


I'm getting a "network unreachable" error on an E100 when trying to 
run benchmark_tx.py from the gnuradio "next" branch (Tom Rondeau?). 
Command line & error, and output of uhd_usrp_probe are attached.


Thanks!

Sean

Probably needs a --args that tells UHD to go looking for the e100 
interface, rather than whatever its default is.


Perhaps Josh can comment on the search order that UHD uses when you 
don't explicitly specify a device, and is that order

  different on an e100?

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

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

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Nowlan, Sean]

I tried with the E100's actual address and the loopback address (127.0.0.1) and 
both worked. I should also say it's a bit confusing to call the command line 
switch "--address" when it's actually handling the arguments the same way as 
uhd_find_devices, etc. handle the "--args" switch. For instance, I also got it 
to run with --address="type=e100". Also it'd be nice (but not necessary) to 
have the program automatically detect if it's an E100 since it will never be 
controlling devices other than itself.

Sean

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Marcus D. Leech
Sent: Tuesday, October 18, 2011 6:30 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

Perhaps this is the wrong place to post this error, but I'm hoping for a quick 
response :)

I'm getting a "network unreachable" error on an E100 when trying to run 
benchmark_tx.py from the gnuradio "next" branch (Tom Rondeau?). Command line & 
error, and output of uhd_usrp_probe are attached.

Thanks!
Sean


Probably needs a --args that tells UHD to go looking for the e100 interface, 
rather than whatever its default is.

Perhaps Josh can comment on the search order that UHD uses when you don't 
explicitly specify a device, and is that order
  different on an e100?



--

Marcus Leech

Principal Investigator

Shirleys Bay Radio Astronomy Consortium

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

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Tom Rondeau]

On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean
wrote:

>  I tried with the E100’s actual address and the loopback address
> (127.0.0.1) and both worked. I should also say it’s a bit confusing to call
> the command line switch “--address” when it’s actually handling the
> arguments the same way as uhd_find_devices, etc. handle the “--args” switch.
> For instance, I also got it to run with --address=”type=e100”. Also it’d be
> nice (but not necessary) to have the program automatically detect if it’s an
> E100 since it will never be controlling devices other than itself.
>
> ** **
>
> Sean
>

You're right about the address-->args thing. I started doing all of this on
a USRP N210, so it was always the systems IP address for me, so that's what
it became. Now, to remember all of the places where I did it and correct for
it...

As for the auto-detection, I suppose it's possible to tap into the UHD's
find_devices feature and just default to the first one it finds as opposed
to a static default. I'll talk with Josh about doing this.

Tom



>
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf
> Of *Marcus D. Leech
> *Sent:* Tuesday, October 18, 2011 6:30 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from
> "next" branch
>
> ** **
>
> Perhaps this is the wrong place to post this error, but I’m hoping for a
> quick response J
>
>  
>
> I’m getting a “network unreachable” error on an E100 when trying to run
> benchmark_tx.py from the gnuradio “next” branch (Tom Rondeau?). Command line
> & error, and output of uhd_usrp_probe are attached.
>
>  
>
> Thanks!
>
> Sean
>
> ** **
>
>  Probably needs a --args that tells UHD to go looking for the e100
> interface, rather than whatever its default is.
>
> Perhaps Josh can comment on the search order that UHD uses when you don't
> explicitly specify a device, and is that order
>   different on an e100?
>
>
> 
>
> -- 
>
> Marcus Leech
>
> Principal Investigator
>
> Shirleys Bay Radio Astronomy Consortium
>
> http://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Josh Blum]

On 10/18/2011 04:02 PM, Nowlan, Sean wrote:
> I tried with the E100's actual address and the loopback address
> (127.0.0.1) and both worked. I should also say it's a bit confusing
> to call the command line switch "--address" when it's actually
> handling the arguments the same way as uhd_find_devices, etc. handle
> the "--args" switch. For instance, I also got it to run with
> --address="type=e100". Also it'd be nice (but not necessary) to have
> the program automatically detect if it's an E100 since it will never
> be controlling devices other than itself.
> 

I think this will help clear some things up:
http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps

So, e100 will not actually respond to the addr key. I believe that the
error stems from the usrp2 find routine trying to send a discovery
packet on the address that you specified, which may be invalid to do.

So I guess my question is, what device address arguments are being
passed into the uhd source/sink constructor?

I recommend using an empty device address. But if you have other usrps
attached to the e100 somehow, and you build uhd with support for those
usrps, you may want to specify type=e100 as a way to filter the other
devices.

-Josh

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

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Nowlan, Sean]

Also in benchmark_tx.py I noticed that calling "-m qpsk" and "-m bpsk" still 
default to their differential versions unless I explicitly use the 
"--non-differential" switch. Was this intended? I assumed that specifying 
"*psk" vs. "d*psk" would do the right thing.

Thanks,
Sean

P.S. - Thank you for your hard work moving the gnuradio examples to UHD!

From: Tom Rondeau [mailto:trondeau1...@gmail.com]
Sent: Tuesday, October 18, 2011 7:06 PM
To: Nowlan, Sean
Cc: Marcus D. Leech; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean 
mailto:sean.now...@gtri.gatech.edu>> wrote:
I tried with the E100's actual address and the loopback address (127.0.0.1) and 
both worked. I should also say it's a bit confusing to call the command line 
switch "--address" when it's actually handling the arguments the same way as 
uhd_find_devices, etc. handle the "--args" switch. For instance, I also got it 
to run with --address="type=e100". Also it'd be nice (but not necessary) to 
have the program automatically detect if it's an E100 since it will never be 
controlling devices other than itself.

Sean

You're right about the address-->args thing. I started doing all of this on a 
USRP N210, so it was always the systems IP address for me, so that's what it 
became. Now, to remember all of the places where I did it and correct for it...

As for the auto-detection, I suppose it's possible to tap into the UHD's 
find_devices feature and just default to the first one it finds as opposed to a 
static default. I'll talk with Josh about doing this.

Tom



From: 
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
 On Behalf Of Marcus D. Leech
Sent: Tuesday, October 18, 2011 6:30 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

Perhaps this is the wrong place to post this error, but I'm hoping for a quick 
response :)

I'm getting a "network unreachable" error on an E100 when trying to run 
benchmark_tx.py from the gnuradio "next" branch (Tom Rondeau?). Command line & 
error, and output of uhd_usrp_probe are attached.

Thanks!
Sean


Probably needs a --args that tells UHD to go looking for the e100 interface, 
rather than whatever its default is.

Perhaps Josh can comment on the search order that UHD uses when you don't 
explicitly specify a device, and is that order
  different on an e100?


--

Marcus Leech

Principal Investigator

Shirleys Bay Radio Astronomy Consortium

http://www.sbrac.org

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

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

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Tom Rondeau]

On Tue, Oct 18, 2011 at 4:18 PM, Nowlan, Sean
wrote:

>  Also in benchmark_tx.py I noticed that calling “-m qpsk” and “-m bpsk”
> still default to their differential versions unless I explicitly use the
> “--non-differential” switch. Was this intended? I assumed that specifying
> “*psk” vs. “d*psk” would do the right thing.
>

No intentional, and I thought I had it working correctly. It's an issue with
the OptionParser and having two options with the same name. They step on
each other. I need to figure out a better way to handle that.


>  Thanks,
>
> Sean
>
> ** **
>
> P.S. – Thank you for your hard work moving the gnuradio examples to UHD!
>

You're welcome!

Tom



>
>
> *From:* Tom Rondeau [mailto:trondeau1...@gmail.com]
> *Sent:* Tuesday, October 18, 2011 7:06 PM
> *To:* Nowlan, Sean
> *Cc:* Marcus D. Leech; discuss-gnuradio@gnu.org
>
> *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from
> "next" branch
>
> ** **
>
> On Tue, Oct 18, 2011 at 4:02 PM, Nowlan, Sean 
> wrote:
>
> I tried with the E100’s actual address and the loopback address (127.0.0.1)
> and both worked. I should also say it’s a bit confusing to call the command
> line switch “--address” when it’s actually handling the arguments the same
> way as uhd_find_devices, etc. handle the “--args” switch. For instance, I
> also got it to run with --address=”type=e100”. Also it’d be nice (but not
> necessary) to have the program automatically detect if it’s an E100 since it
> will never be controlling devices other than itself.
>
>  
>
> Sean
>
> ** **
>
> You're right about the address-->args thing. I started doing all of this on
> a USRP N210, so it was always the systems IP address for me, so that's what
> it became. Now, to remember all of the places where I did it and correct for
> it...
>
> ** **
>
> As for the auto-detection, I suppose it's possible to tap into the UHD's
> find_devices feature and just default to the first one it finds as opposed
> to a static default. I'll talk with Josh about doing this.
>
> ** **
>
> Tom
>
> ** **
>
>  
>
>   
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf
> Of *Marcus D. Leech
> *Sent:* Tuesday, October 18, 2011 6:30 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from
> "next" branch
>
>  
>
> Perhaps this is the wrong place to post this error, but I’m hoping for a
> quick response J
>
>  
>
> I’m getting a “network unreachable” error on an E100 when trying to run
> benchmark_tx.py from the gnuradio “next” branch (Tom Rondeau?). Command line
> & error, and output of uhd_usrp_probe are attached.
>
>  
>
> Thanks!
>
> Sean
>
>  
>
>  Probably needs a --args that tells UHD to go looking for the e100
> interface, rather than whatever its default is.
>
> Perhaps Josh can comment on the search order that UHD uses when you don't
> explicitly specify a device, and is that order
>   different on an e100?
>
> 
>
> -- 
>
> Marcus Leech
>
> Principal Investigator
>
> Shirleys Bay Radio Astronomy Consortium
>
> http://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  ** **
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Tom Rondeau]

On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum  wrote:

>
>
> On 10/18/2011 04:02 PM, Nowlan, Sean wrote:
> > I tried with the E100's actual address and the loopback address
> > (127.0.0.1) and both worked. I should also say it's a bit confusing
> > to call the command line switch "--address" when it's actually
> > handling the arguments the same way as uhd_find_devices, etc. handle
> > the "--args" switch. For instance, I also got it to run with
> > --address="type=e100". Also it'd be nice (but not necessary) to have
> > the program automatically detect if it's an E100 since it will never
> > be controlling devices other than itself.
> >
>
> I think this will help clear some things up:
>
> http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps
>
> So, e100 will not actually respond to the addr key. I believe that the
> error stems from the usrp2 find routine trying to send a discovery
> packet on the address that you specified, which may be invalid to do.
>
> So I guess my question is, what device address arguments are being
> passed into the uhd source/sink constructor?
>
> I recommend using an empty device address. But if you have other usrps
> attached to the e100 somehow, and you build uhd with support for those
> usrps, you may want to specify type=e100 as a way to filter the other
> devices.
>
> -Josh


So does an empty string default to the first UHD device found? If so, then
that solves the problem, and I'll change all of the defaults to that (along
with the change to args).

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

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Josh Blum]

On 10/18/2011 04:23 PM, Tom Rondeau wrote:
> On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum  wrote:
> 
>>
>>
>> On 10/18/2011 04:02 PM, Nowlan, Sean wrote:
>>> I tried with the E100's actual address and the loopback address
>>> (127.0.0.1) and both worked. I should also say it's a bit confusing
>>> to call the command line switch "--address" when it's actually
>>> handling the arguments the same way as uhd_find_devices, etc. handle
>>> the "--args" switch. For instance, I also got it to run with
>>> --address="type=e100". Also it'd be nice (but not necessary) to have
>>> the program automatically detect if it's an E100 since it will never
>>> be controlling devices other than itself.
>>>
>>
>> I think this will help clear some things up:
>>
>> http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps
>>
>> So, e100 will not actually respond to the addr key. I believe that the
>> error stems from the usrp2 find routine trying to send a discovery
>> packet on the address that you specified, which may be invalid to do.
>>
>> So I guess my question is, what device address arguments are being
>> passed into the uhd source/sink constructor?
>>
>> I recommend using an empty device address. But if you have other usrps
>> attached to the e100 somehow, and you build uhd with support for those
>> usrps, you may want to specify type=e100 as a way to filter the other
>> devices.
>>
>> -Josh
> 
> 
> So does an empty string default to the first UHD device found? If so, then
> that solves the problem, and I'll change all of the defaults to that (along
> with the change to args).
> 

Yea, empty device address will find everything it can. And the first
device found will be the one thats instantiated.

-josh

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

[Discuss-gnuradio] Segmentation Fault

[Sriharsha Puranik]

Hi all,

I am facing "Segmentation Fault" error.

My setup is - Ubuntu 11.04, USRP2 with WBX board, gnuradio.

The scenario is - When I run uhd_fft.py, I get the following -

(gdb) run /usr/local/bin/uhd_fft.py
Starting program: /usr/bin/python /usr/local/bin/uhd_fft.py
[Thread debugging using libthread_db enabled]
linux; GNU C++ version 4.5.2; Boost_103700; UHD_003.003.000-25f0bd5

[New Thread 0x7fffe1adf700 (LWP 26034)]
[New Thread 0x7fffe12de700 (LWP 26035)]
usrp_source make
Making
-- Opening a USRP2/N-Series device...
[New Thread 0x7fffe0add700 (LWP 26036)]

UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000

UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000

UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576

Program received signal SIGSEGV, *Segmentation fault*.
[Switching to Thread 0x7fffe0add700 (LWP 26036)]
0x757d6973 in std::_Rb_tree_increment(std::_Rb_tree_node_base*) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) backtrace
#0  0x757d6973 in std::_Rb_tree_increment(std::_Rb_tree_node_base*)
()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x7419bc68 in tls_destructor ()
   from /usr/lib/libboost_thread.so.1.42.0
#2  0x7419e177 in thread_proxy ()
   from /usr/lib/libboost_thread.so.1.42.0
#3  0x77bc4d8c in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#4  0x76a8a04d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x in ?? ()
(gdb)

*
*
The UHD logs file has been attached with the mail.

Also, USRP1 with uhd_fft.py is working fine. USRP2 works fine if there is no
UI involved (that is - /usr/local/share/uhd/examples/rx_ascii_art_dft
 --freq 900e6 --rate 1e6 --dyn-rng 120 works fine).

Can some one please take a look at this problem?

Thanks,
Sriharsha Puranik.


-- 2011-Oct-18 19:27:04.286141 - level 1
-- static void uhd::device::register_device(const uhd::device::find_t&, const uh
-- lib/device.cpp:69

registering device



-- 2011-Oct-18 19:27:04.286302 - level 1
-- static void uhd::device::register_device(const uhd::device::find_t&, const uh
-- lib/device.cpp:69

registering device



-- 2011-Oct-18 19:27:04.286346 - level 1
-- static void uhd::device::register_device(const uhd::device::find_t&, const uh
-- lib/device.cpp:69

registering device



-- 2011-Oct-18 19:27:04.286481 - level 1
-- void register_dboard_key(const dboard_key_t&, uhd::usrp::dboard_base::sptr (*
-- lib/usrp/dboard_manager.cpp:94

registering: TVRX2



-- 2011-Oct-18 19:27:04.286532 - level 1
-- void register_dboard_key(const dboard_key_t&, uhd::usrp::dboard_base::sptr (*
-- lib/usrp/dboard_manager.cpp:94

registering: DBSRX2



-- 2011-Oct-18 19:27:04.286574 - level 1
-- void register_dboard_key(const dboard_key_t&, uhd::usrp::dboard_base::sptr (*
-- lib/usrp/dboard_manager.cpp:94

registering: TVRX



-- 2011-Oct-18 19:27:04.286600 - level 1
-- void register_dboard_key(const dboard_key_t&, uhd::usrp::dboard_base::sptr (*
-- lib/usrp/dboard_manager.cpp:94

registering: Unknown TX



-- 2011-Oct-18 19:27:04.286623 - level 1
-- void register_dboard_key(const dboard_key_t&, uhd::usrp::dboard_base::sptr (*

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Nowlan, Sean]

One more thing - it looks like BITRATE refers to the USRP sample rate as 
opposed to the bitrate of the modulation scheme. I think this is a little 
confusing. Please correct me if I'm wrong with this math, using QPSK as an 
example:

actual_bitrate = (2 bits/symbol) * 1/(SPS) * BITRATE,where 
SPS=(samples/symbol) and BITRATE is the USRP sample rate.

Thanks,
Sean

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Tom Rondeau
Sent: Tuesday, October 18, 2011 7:24 PM
To: j...@ettus.com
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum 
mailto:j...@ettus.com>> wrote:


On 10/18/2011 04:02 PM, Nowlan, Sean wrote:
> I tried with the E100's actual address and the loopback address
> (127.0.0.1) and both worked. I should also say it's a bit confusing
> to call the command line switch "--address" when it's actually
> handling the arguments the same way as uhd_find_devices, etc. handle
> the "--args" switch. For instance, I also got it to run with
> --address="type=e100". Also it'd be nice (but not necessary) to have
> the program automatically detect if it's an E100 since it will never
> be controlling devices other than itself.
>
I think this will help clear some things up:
http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps

So, e100 will not actually respond to the addr key. I believe that the
error stems from the usrp2 find routine trying to send a discovery
packet on the address that you specified, which may be invalid to do.

So I guess my question is, what device address arguments are being
passed into the uhd source/sink constructor?

I recommend using an empty device address. But if you have other usrps
attached to the e100 somehow, and you build uhd with support for those
usrps, you may want to specify type=e100 as a way to filter the other
devices.

-Josh

So does an empty string default to the first UHD device found? If so, then that 
solves the problem, and I'll change all of the defaults to that (along with the 
change to args).

Tom

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

Re: [Discuss-gnuradio] fan replacement for usrp1?

[Mark Cetilia]

ok so this has been working just fine at home,
but i am actually beginning to use the usrp in performances fairly regularly,
and you never know what might happen in such situations…

so just to be on the safe side, i'd really rather replace the fan.

unfortunately i'm not having much luck finding the exact fan that came with it 
in stock anywhere,
but i've found a possible replacement that seems to basically meet the specs:
http://search.digikey.com/us/en/products/F410T-05LC/563-1130-ND/1165524

the only thing that doesn't match up is the air flow—
it's rated at 3.9CFM rather than the cooltron's 4.6CFM.

anyone have a clue as to whether or not this would be enough of a difference to 
cause concern?

otherwise the specs look fine, and it's supposed to have a noise floor of 12 
dBA instead of ~21, 
so we're talking roughly half the volume… could really make a difference.

thanks in advance,
mark

p.s. does anyone else have this same issue or is it just me? i'm wondering if 
maybe it's just that my fan is defective…
20 dBA should be "a whisper" and mine seems to be much louder than that.

--
mark.cetilia.org | mem1.com | reduxproject.com

On Oct 9, 2011, at 2:04 PM, Mark Cetilia wrote:

> ah yes, i feel it coming back, slowly.
> thank you :)
> 
> m
> 
> --
> mark.cetilia.org | mem1.com | reduxproject.com
> 
> On Oct 9, 2011, at 3:39 AM, Mike Jameson wrote:
> 
>> Hi Mark,
>> 
>> If you take off the top of the enclosure on the USRP1 then you don't even 
>> need a fan!
>> 
>> Your sanity should then return :)
>> 
>> Mike
>> M0MIK
>> 
>> 
>> On 9 October 2011 06:43, Mark Cetilia  wrote:
>> wondering if anybody out there has replaced their usrp1 fan with something a 
>> bit quieter?
>> i find myself listening to its incessant whine many hours a day, and it's 
>> starting to make me a little crazy—
>> especially when i am trying to listen to subtle details… anybody have a 
>> suggestion for a decent replacement?
>> 
>> cheers,
>> mark
>> 
>> --
>> mark.cetilia.org | mem1.com | reduxproject.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

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

Re: [Discuss-gnuradio] fan replacement for usrp1?

[Robert McGwier]

Yes I have.  I disconnected it.  In my opinion, it is overkill for anything
going on in a USRP1.

YMMV,
Bob


On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia  wrote:

> wondering if anybody out there has replaced their usrp1 fan with something
> a bit quieter?
> i find myself listening to its incessant whine many hours a day, and it's
> starting to make me a little crazy—
> especially when i am trying to listen to subtle details… anybody have a
> suggestion for a decent replacement?
>
> cheers,
> mark
>
> --
> mark.cetilia.org | mem1.com | reduxproject.com
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Bob McGwier
Facebook: N4HYBob
ARS: N4HY
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error running benchmark_tx.py from "next" branch

[Tom Rondeau]

On Tue, Oct 18, 2011 at 4:40 PM, Nowlan, Sean
wrote:

>  One more thing – it looks like BITRATE refers to the USRP sample rate as
> opposed to the bitrate of the modulation scheme. I think this is a little
> confusing. Please correct me if I’m wrong with this math, using QPSK as an
> example:
>
> actual_bitrate = (2 bits/symbol) * 1/(SPS) * BITRATE,where
> SPS=(samples/symbol) and BITRATE is the USRP sample rate.
>
> ** **
>
> Thanks,
>
> Sean
>

I thought it was the bitrate; must have been another oversight when I was
working on it. I'll fix that, too.

Thanks for the bug reports (and useful suggestions)!

Tom




>  *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf
> Of *Tom Rondeau
> *Sent:* Tuesday, October 18, 2011 7:24 PM
> *To:* j...@ettus.com
> *Cc:* discuss-gnuradio@gnu.org
>
> *Subject:* Re: [Discuss-gnuradio] Error running benchmark_tx.py from
> "next" branch
>
> ** **
>
> On Tue, Oct 18, 2011 at 4:19 PM, Josh Blum  wrote:
>
>
>
> On 10/18/2011 04:02 PM, Nowlan, Sean wrote:
> > I tried with the E100's actual address and the loopback address
> > (127.0.0.1) and both worked. I should also say it's a bit confusing
> > to call the command line switch "--address" when it's actually
> > handling the arguments the same way as uhd_find_devices, etc. handle
> > the "--args" switch. For instance, I also got it to run with
> > --address="type=e100". Also it'd be nice (but not necessary) to have
> > the program automatically detect if it's an E100 since it will never
> > be controlling devices other than itself.
> >
>
> I think this will help clear some things up:
>
> http://files.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps
>
> So, e100 will not actually respond to the addr key. I believe that the
> error stems from the usrp2 find routine trying to send a discovery
> packet on the address that you specified, which may be invalid to do.
>
> So I guess my question is, what device address arguments are being
> passed into the uhd source/sink constructor?
>
> I recommend using an empty device address. But if you have other usrps
> attached to the e100 somehow, and you build uhd with support for those
> usrps, you may want to specify type=e100 as a way to filter the other
> devices.
>
> -Josh
>
> ** **
>
> So does an empty string default to the first UHD device found? If so, then
> that solves the problem, and I'll change all of the defaults to that (along
> with the change to args).
>
> ** **
>
> Tom
>
> ** **
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Developers' Call, Oct. 20, 2011

[Tom Rondeau]

We will be having our monthly Developers' conference call this Thursday,
Oct. 20, 2011.

Time: 10 PM UTC (6 PM EDT, 3 PM PDT)
SIP: sip:gnura...@digitalbazaar.com
IRC: #gnuradio on freenode

Agenda:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20111020

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

Re: [Discuss-gnuradio] fan replacement for usrp1?

[Mark Cetilia]

Ah good, glad to hear it's not just me…
Do you run it with the top on or leave it open?

Cheers,
Mark

--
mark.cetilia.org | mem1.com | reduxproject.com

On Oct 18, 2011, at 11:02 PM, Robert McGwier wrote:

> Yes I have.  I disconnected it.  In my opinion, it is overkill for anything 
> going on in a USRP1.
> 
> YMMV,
> Bob
> 
> 
> On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia  wrote:
> wondering if anybody out there has replaced their usrp1 fan with something a 
> bit quieter?
> i find myself listening to its incessant whine many hours a day, and it's 
> starting to make me a little crazy—
> especially when i am trying to listen to subtle details… anybody have a 
> suggestion for a decent replacement?
> 
> cheers,
> mark
> 
> --
> mark.cetilia.org | mem1.com | reduxproject.com
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> -- 
> Bob McGwier
> Facebook: N4HYBob
> ARS: N4HY
> 
> 

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