Re: [Discuss-gnuradio] GRC [Errno 13] Permission denied for No GUI graphs

[Cinaed Simson]

On 07/06/2017 04:54 PM, Jozef Lošonský wrote:
> OK, again, python script is successfully created/written, and it is
> runnable outside of GRC, the errno13 comes from execve call which is
> incomplete, can you see that, please?

Send the flowchart and the python code if you want help.

-- Cinaed

> 
> On Jul 7, 2017 01:27, "Cinaed Simson"  > wrote:
> 
> On 07/06/2017 02:57 PM, Jozef Lošonský wrote:
> > I'm not behind my pc, but I think that it is possible to understand my
> > issue, that py file is generated from any flowgraph OK, but "play
> > button" press fails with Errno13 when "No GUI" (of course I'm not
> using
> > any WX or QT block in such case).
> 
> Without at least an error message, e.g., Errno13, it's impossible to
> figure out what the problem is since your explanations make no sense.
> 
> In fact, you've never indicated there was an error message.
> 
> Typically, an Errno13 is a write permission problem - it's not a
> gnuradio or grc problem.
> 
> And the error should have included
> 
>   Generate Error: [Errno 13] Permission denied:
> 
> and then it prints out the location of where you're writing to.
> 
> The obvious solution is to find another play to write the file.
> 
> -- Cinaed
> 
> 
> >
> > On Jul 6, 2017 11:48 PM, "Cinaed Simson"  
> > >>
> wrote:
> >
> > On 07/06/2017 02:14 PM, Jozef Lošonský wrote:
> > > Hi, there are no GUI elements and graf generated py file works
> > fine from
> > > console, but GRC only is unable to execute that already
> generated
> > file.
> >
> > Then post the flowgraph and the python code - it's the only
> way we can
> > help you.
> >
> > -- Cinaed
> >
> > >
> > > On Jul 6, 2017 11:08 PM, "Cinaed Simson"
> 
> > >
> > >     > wrote:
> > >
> > > On 07/06/2017 12:10 AM, Jozef Lošonský wrote:
> > > > Hello,
> > > > my GRC is unable to execute graphs (no GUI elements)
> when I
> > switch
> > > > option to No GUI, everything else seems to be working.
> > >
> > > The option "No GUI" means no GUI elements, i.e., no graphs.
> > >
> > > If you had a graphical element in your flowgraph, GRC
> should have
> > > complained and printed an error message in the GRC console
> > when you
> > > clicked on the button "Generate the flow graph".
> > >
> > > In order to generate python code from GRC you have
> disable the GUI
> > > elements in the flowgraph in order to generate python code.
> > >
> > > > In addition "No
> > > > GUI" py script (generated by same GRC) is running fine in
> > console
> > > of the
> > > > same user which is running GRC what is interesting.
> > >
> > > I didn't find other
> > > > way how to try get more info about issue than run
> whole GRC
> > under
> > > strace
> > > > -ffy and read the strace file.
> > > > Comparing strace files with working GRC instance on
> another PC
> > > @jcorgan
> > > > did suggest that in execve python is missing.
> > >
> > > And most likely the gnuradio software and the required
> > software packages
> > > needed to run gnuradio on PC @jcorgan are probably
> missing too.
> > >
> > > A working installation of python is one of the
> perquisite to run
> > > gnuradio.
> > >
> > > >
> > > > Bad:
> > > > [pid  2704] execve("/usr/local/bin/", ["", "-e",
> > "/usr/bin/python",
> > > > "-u", "/home/pi/top_block.py"]...= -1 EACCES
> (Permission denied)
> > > > Good:
> > > > [pid 12112] execve("/usr/bin/python",
> ["/usr/bin/python", "-u",
> > > > "/home/loso/top_block.py"], [/* 75 vars */]
> 
> > > >
> > > > I'm trying to find which env variable or what option am I
> > missing/have
> > > > wrongly configured in GRC config or somewhere else.
> > > Based on the content of this post, everything on your
> machine
> > is working
> > > correctly.
> > >
> > > If 

Re: [Discuss-gnuradio] GRC [Errno 13] Permission denied for No GUI graphs

[Jozef Lošonský]

OK, again, python script is successfully created/written, and it is
runnable outside of GRC, the errno13 comes from execve call which is
incomplete, can you see that, please?

On Jul 7, 2017 01:27, "Cinaed Simson"  wrote:

> On 07/06/2017 02:57 PM, Jozef Lošonský wrote:
> > I'm not behind my pc, but I think that it is possible to understand my
> > issue, that py file is generated from any flowgraph OK, but "play
> > button" press fails with Errno13 when "No GUI" (of course I'm not using
> > any WX or QT block in such case).
>
> Without at least an error message, e.g., Errno13, it's impossible to
> figure out what the problem is since your explanations make no sense.
>
> In fact, you've never indicated there was an error message.
>
> Typically, an Errno13 is a write permission problem - it's not a
> gnuradio or grc problem.
>
> And the error should have included
>
>   Generate Error: [Errno 13] Permission denied:
>
> and then it prints out the location of where you're writing to.
>
> The obvious solution is to find another play to write the file.
>
> -- Cinaed
>
>
> >
> > On Jul 6, 2017 11:48 PM, "Cinaed Simson"  > > wrote:
> >
> > On 07/06/2017 02:14 PM, Jozef Lošonský wrote:
> > > Hi, there are no GUI elements and graf generated py file works
> > fine from
> > > console, but GRC only is unable to execute that already generated
> > file.
> >
> > Then post the flowgraph and the python code - it's the only way we
> can
> > help you.
> >
> > -- Cinaed
> >
> > >
> > > On Jul 6, 2017 11:08 PM, "Cinaed Simson"  > 
> > > >>
> > wrote:
> > >
> > > On 07/06/2017 12:10 AM, Jozef Lošonský wrote:
> > > > Hello,
> > > > my GRC is unable to execute graphs (no GUI elements) when I
> > switch
> > > > option to No GUI, everything else seems to be working.
> > >
> > > The option "No GUI" means no GUI elements, i.e., no graphs.
> > >
> > > If you had a graphical element in your flowgraph, GRC should
> have
> > > complained and printed an error message in the GRC console
> > when you
> > > clicked on the button "Generate the flow graph".
> > >
> > > In order to generate python code from GRC you have disable the
> GUI
> > > elements in the flowgraph in order to generate python code.
> > >
> > > > In addition "No
> > > > GUI" py script (generated by same GRC) is running fine in
> > console
> > > of the
> > > > same user which is running GRC what is interesting.
> > >
> > > I didn't find other
> > > > way how to try get more info about issue than run whole GRC
> > under
> > > strace
> > > > -ffy and read the strace file.
> > > > Comparing strace files with working GRC instance on another
> PC
> > > @jcorgan
> > > > did suggest that in execve python is missing.
> > >
> > > And most likely the gnuradio software and the required
> > software packages
> > > needed to run gnuradio on PC @jcorgan are probably missing too.
> > >
> > > A working installation of python is one of the perquisite to
> run
> > > gnuradio.
> > >
> > > >
> > > > Bad:
> > > > [pid  2704] execve("/usr/local/bin/", ["", "-e",
> > "/usr/bin/python",
> > > > "-u", "/home/pi/top_block.py"]...= -1 EACCES (Permission
> denied)
> > > > Good:
> > > > [pid 12112] execve("/usr/bin/python", ["/usr/bin/python",
> "-u",
> > > > "/home/loso/top_block.py"], [/* 75 vars */] 
> > > >
> > > > I'm trying to find which env variable or what option am I
> > missing/have
> > > > wrongly configured in GRC config or somewhere else.
> > > Based on the content of this post, everything on your machine
> > is working
> > > correctly.
> > >
> > > If you can actually generate an error message using gnuradio -
> > other
> > > then enclosed operator errors - post the error message, the
> > flowgraph
> > > and the python code.
> > >
> > > >
> > > > Thank you.
> > > > Jozef
> > > >
> > > >
> > > >
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org 
> > >
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > >  > 

Re: [Discuss-gnuradio] GRC [Errno 13] Permission denied for No GUI graphs

[Cinaed Simson]

On 07/06/2017 02:57 PM, Jozef Lošonský wrote:
> I'm not behind my pc, but I think that it is possible to understand my
> issue, that py file is generated from any flowgraph OK, but "play
> button" press fails with Errno13 when "No GUI" (of course I'm not using
> any WX or QT block in such case).

Without at least an error message, e.g., Errno13, it's impossible to
figure out what the problem is since your explanations make no sense.

In fact, you've never indicated there was an error message.

Typically, an Errno13 is a write permission problem - it's not a
gnuradio or grc problem.

And the error should have included

  Generate Error: [Errno 13] Permission denied:

and then it prints out the location of where you're writing to.

The obvious solution is to find another play to write the file.

-- Cinaed


> 
> On Jul 6, 2017 11:48 PM, "Cinaed Simson"  > wrote:
> 
> On 07/06/2017 02:14 PM, Jozef Lošonský wrote:
> > Hi, there are no GUI elements and graf generated py file works
> fine from
> > console, but GRC only is unable to execute that already generated
> file.
> 
> Then post the flowgraph and the python code - it's the only way we can
> help you.
> 
> -- Cinaed
> 
> >
> > On Jul 6, 2017 11:08 PM, "Cinaed Simson"  
> > >>
> wrote:
> >
> > On 07/06/2017 12:10 AM, Jozef Lošonský wrote:
> > > Hello,
> > > my GRC is unable to execute graphs (no GUI elements) when I
> switch
> > > option to No GUI, everything else seems to be working.
> >
> > The option "No GUI" means no GUI elements, i.e., no graphs.
> >
> > If you had a graphical element in your flowgraph, GRC should have
> > complained and printed an error message in the GRC console
> when you
> > clicked on the button "Generate the flow graph".
> >
> > In order to generate python code from GRC you have disable the GUI
> > elements in the flowgraph in order to generate python code.
> >
> > > In addition "No
> > > GUI" py script (generated by same GRC) is running fine in
> console
> > of the
> > > same user which is running GRC what is interesting.
> >
> > I didn't find other
> > > way how to try get more info about issue than run whole GRC
> under
> > strace
> > > -ffy and read the strace file.
> > > Comparing strace files with working GRC instance on another PC
> > @jcorgan
> > > did suggest that in execve python is missing.
> >
> > And most likely the gnuradio software and the required
> software packages
> > needed to run gnuradio on PC @jcorgan are probably missing too.
> >
> > A working installation of python is one of the perquisite to run
> > gnuradio.
> >
> > >
> > > Bad:
> > > [pid  2704] execve("/usr/local/bin/", ["", "-e",
> "/usr/bin/python",
> > > "-u", "/home/pi/top_block.py"]...= -1 EACCES (Permission denied)
> > > Good:
> > > [pid 12112] execve("/usr/bin/python", ["/usr/bin/python", "-u",
> > > "/home/loso/top_block.py"], [/* 75 vars */] 
> > >
> > > I'm trying to find which env variable or what option am I
> missing/have
> > > wrongly configured in GRC config or somewhere else.
> > Based on the content of this post, everything on your machine
> is working
> > correctly.
> >
> > If you can actually generate an error message using gnuradio -
> other
> > then enclosed operator errors - post the error message, the
> flowgraph
> > and the python code.
> >
> > >
> > > Thank you.
> > > Jozef
> > >
> > >
> > >
> > > ___
> > > 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] GRC [Errno 13] Permission denied for No GUI graphs

[Jozef Lošonský]

I'm not behind my pc, but I think that it is possible to understand my
issue, that py file is generated from any flowgraph OK, but "play button"
press fails with Errno13 when "No GUI" (of course I'm not using any WX or
QT block in such case).

On Jul 6, 2017 11:48 PM, "Cinaed Simson"  wrote:

> On 07/06/2017 02:14 PM, Jozef Lošonský wrote:
> > Hi, there are no GUI elements and graf generated py file works fine from
> > console, but GRC only is unable to execute that already generated file.
>
> Then post the flowgraph and the python code - it's the only way we can
> help you.
>
> -- Cinaed
>
> >
> > On Jul 6, 2017 11:08 PM, "Cinaed Simson"  > > wrote:
> >
> > On 07/06/2017 12:10 AM, Jozef Lošonský wrote:
> > > Hello,
> > > my GRC is unable to execute graphs (no GUI elements) when I switch
> > > option to No GUI, everything else seems to be working.
> >
> > The option "No GUI" means no GUI elements, i.e., no graphs.
> >
> > If you had a graphical element in your flowgraph, GRC should have
> > complained and printed an error message in the GRC console when you
> > clicked on the button "Generate the flow graph".
> >
> > In order to generate python code from GRC you have disable the GUI
> > elements in the flowgraph in order to generate python code.
> >
> > > In addition "No
> > > GUI" py script (generated by same GRC) is running fine in console
> > of the
> > > same user which is running GRC what is interesting.
> >
> > I didn't find other
> > > way how to try get more info about issue than run whole GRC under
> > strace
> > > -ffy and read the strace file.
> > > Comparing strace files with working GRC instance on another PC
> > @jcorgan
> > > did suggest that in execve python is missing.
> >
> > And most likely the gnuradio software and the required software
> packages
> > needed to run gnuradio on PC @jcorgan are probably missing too.
> >
> > A working installation of python is one of the perquisite to run
> > gnuradio.
> >
> > >
> > > Bad:
> > > [pid  2704] execve("/usr/local/bin/", ["", "-e", "/usr/bin/python",
> > > "-u", "/home/pi/top_block.py"]...= -1 EACCES (Permission denied)
> > > Good:
> > > [pid 12112] execve("/usr/bin/python", ["/usr/bin/python", "-u",
> > > "/home/loso/top_block.py"], [/* 75 vars */] 
> > >
> > > I'm trying to find which env variable or what option am I
> missing/have
> > > wrongly configured in GRC config or somewhere else.
> > Based on the content of this post, everything on your machine is
> working
> > correctly.
> >
> > If you can actually generate an error message using gnuradio - other
> > then enclosed operator errors - post the error message, the flowgraph
> > and the python code.
> >
> > >
> > > Thank you.
> > > Jozef
> > >
> > >
> > >
> > > ___
> > > 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] GRC [Errno 13] Permission denied for No GUI graphs

[Cinaed Simson]

On 07/06/2017 02:14 PM, Jozef Lošonský wrote:
> Hi, there are no GUI elements and graf generated py file works fine from
> console, but GRC only is unable to execute that already generated file.

Then post the flowgraph and the python code - it's the only way we can
help you.

-- Cinaed

> 
> On Jul 6, 2017 11:08 PM, "Cinaed Simson"  > wrote:
> 
> On 07/06/2017 12:10 AM, Jozef Lošonský wrote:
> > Hello,
> > my GRC is unable to execute graphs (no GUI elements) when I switch
> > option to No GUI, everything else seems to be working.
> 
> The option "No GUI" means no GUI elements, i.e., no graphs.
> 
> If you had a graphical element in your flowgraph, GRC should have
> complained and printed an error message in the GRC console when you
> clicked on the button "Generate the flow graph".
> 
> In order to generate python code from GRC you have disable the GUI
> elements in the flowgraph in order to generate python code.
> 
> > In addition "No
> > GUI" py script (generated by same GRC) is running fine in console
> of the
> > same user which is running GRC what is interesting.
> 
> I didn't find other
> > way how to try get more info about issue than run whole GRC under
> strace
> > -ffy and read the strace file.
> > Comparing strace files with working GRC instance on another PC
> @jcorgan
> > did suggest that in execve python is missing.
> 
> And most likely the gnuradio software and the required software packages
> needed to run gnuradio on PC @jcorgan are probably missing too.
> 
> A working installation of python is one of the perquisite to run
> gnuradio.
> 
> >
> > Bad:
> > [pid  2704] execve("/usr/local/bin/", ["", "-e", "/usr/bin/python",
> > "-u", "/home/pi/top_block.py"]...= -1 EACCES (Permission denied)
> > Good:
> > [pid 12112] execve("/usr/bin/python", ["/usr/bin/python", "-u",
> > "/home/loso/top_block.py"], [/* 75 vars */] 
> >
> > I'm trying to find which env variable or what option am I missing/have
> > wrongly configured in GRC config or somewhere else.
> Based on the content of this post, everything on your machine is working
> correctly.
> 
> If you can actually generate an error message using gnuradio - other
> then enclosed operator errors - post the error message, the flowgraph
> and the python code.
> 
> >
> > Thank you.
> > Jozef
> >
> >
> >
> > ___
> > 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] Observing Random Jitter in HackRF One in High Bandwidth with High Carrier Modulation

[Cinaed Simson]

Post the gnuradio flowgraph you used.

If you have a complaint with the HackRF hardware, post the complain on
the HackRF mailing list

  https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

And if you're only getting 2 MSPS with the HackRF on your computer then
you just have a slow computer - or it's operator error.

See

  https://greatscottgadgets.com/sdr/

for a tutorial on the HackRF.

-- Cinaed

On 07/06/2017 07:14 AM, Stack Programer wrote:
> Yet i work on DVB-T in HackRF one, in TX we can send DVB-T and we
> receive it with a hardware dongle DVB-T. but for receiving with SDR
> Based we had error: see this link for our older
> 
> work or this
>  link.
> 
> DVBT project receiver probelm OOrestart aquisition d_freq_offset: -5
> Od_freq_offset: -5
> 
> So for examine my problem i created a new issue on hackrfone github
> project see this  link,
> every thing i found i will update there. In older our post we define
> jitter error , for more info you can see this
> 
> link.
> 
> Fig1:Jitter error diagram description
> 
>   * *So we start examine that how we observed HackRF One has Random
> jitter errors??* 
> 
> my reason why HackRF One has random jitter error, In protocol like
> gr-dvbt ,gr-ofdm,gr-atsc that they
> are ofdm based modulation, we had not any response in receiver mode in
> dvb-t we had famous error: but frequency offset instantly from -5,3,2,7,….
> 
> restart aquisition d_freq_offset: -5 Od_freq_offset: -5
> 
> So we  had a error in uncertianly frequency and other hand it is random,
> so we had radom jitter errror.for more info see this
>  link.
> 
>   * *reason of causing HackRF  One has Jitter error?*
>   * Low Resolution ADC: 
> 
> after some search i concluded that one of reason for random jitter error
> in HackRFOne is low resolution ADC, it has 8 bit ADC,please see this
>  link
> that describe how low resolution ADC can create jitter errors .
> 
>   * Low SNR in  HackRF One: 
> 
> For problem long switch diode stage in RF HackRF One it is more noisy vs
> USRP. So it use long way RF, it should edited in newer version.
> 
> you can see in below image and link that how bad SNR and low ADC
> resolution can caused jitter errros.
> 
> for more info please seethis
>  link.
> 
>  
> 
> jitterADC
> 
> Fig2:low resolution ADC can cause jitter errors
> 
>  
> 
> So we saw that HackRF One in OFDM based modulation and high carrier or
> in high bandwidth it sucks and it has random jitter errors, so we should
> ask myself that we need new design opensource hardware SDR hardware?
> 
> But some question is need to answered??
> 
> *why is mention HackRFOne has bandwidth 20 MSPS…..*??
> we should define bandwidth and sps in high carrier modulation
> it has problem in high carrier modulation?.So really HackRF One have
> Bandwidth more than 2 MSPS?
> 
> *but what's solution?*
> 
>   *
> 
> 
> using a external clock for hackrf one???
>   *
> 
> design a new hardware………? 
> 
> i liked hackrfone for reason that is opensource and hardware, but with
> this condition i concluded that
> we should think a new way for future sdr hardware opensource?
> 
> best regards stackprogramer
> 
> Fig3:HackRFOne a opensource hardware SDR hardware
> 
>  
> 
> 
> 
> ___
> 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] GRC [Errno 13] Permission denied for No GUI graphs

[Jozef Lošonský]

Hi, there are no GUI elements and graf generated py file works fine from
console, but GRC only is unable to execute that already generated file.

On Jul 6, 2017 11:08 PM, "Cinaed Simson"  wrote:

> On 07/06/2017 12:10 AM, Jozef Lošonský wrote:
> > Hello,
> > my GRC is unable to execute graphs (no GUI elements) when I switch
> > option to No GUI, everything else seems to be working.
>
> The option "No GUI" means no GUI elements, i.e., no graphs.
>
> If you had a graphical element in your flowgraph, GRC should have
> complained and printed an error message in the GRC console when you
> clicked on the button "Generate the flow graph".
>
> In order to generate python code from GRC you have disable the GUI
> elements in the flowgraph in order to generate python code.
>
> > In addition "No
> > GUI" py script (generated by same GRC) is running fine in console of the
> > same user which is running GRC what is interesting.
>
> I didn't find other
> > way how to try get more info about issue than run whole GRC under strace
> > -ffy and read the strace file.
> > Comparing strace files with working GRC instance on another PC @jcorgan
> > did suggest that in execve python is missing.
>
> And most likely the gnuradio software and the required software packages
> needed to run gnuradio on PC @jcorgan are probably missing too.
>
> A working installation of python is one of the perquisite to run gnuradio.
>
> >
> > Bad:
> > [pid  2704] execve("/usr/local/bin/", ["", "-e", "/usr/bin/python",
> > "-u", "/home/pi/top_block.py"]...= -1 EACCES (Permission denied)
> > Good:
> > [pid 12112] execve("/usr/bin/python", ["/usr/bin/python", "-u",
> > "/home/loso/top_block.py"], [/* 75 vars */] 
> >
> > I'm trying to find which env variable or what option am I missing/have
> > wrongly configured in GRC config or somewhere else.
> Based on the content of this post, everything on your machine is working
> correctly.
>
> If you can actually generate an error message using gnuradio - other
> then enclosed operator errors - post the error message, the flowgraph
> and the python code.
>
> >
> > Thank you.
> > Jozef
> >
> >
> >
> > ___
> > 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] GRC [Errno 13] Permission denied for No GUI graphs

[Cinaed Simson]

On 07/06/2017 12:10 AM, Jozef Lošonský wrote:
> Hello,
> my GRC is unable to execute graphs (no GUI elements) when I switch
> option to No GUI, everything else seems to be working.

The option "No GUI" means no GUI elements, i.e., no graphs.

If you had a graphical element in your flowgraph, GRC should have
complained and printed an error message in the GRC console when you
clicked on the button "Generate the flow graph".

In order to generate python code from GRC you have disable the GUI
elements in the flowgraph in order to generate python code.

> In addition "No
> GUI" py script (generated by same GRC) is running fine in console of the
> same user which is running GRC what is interesting.

I didn't find other
> way how to try get more info about issue than run whole GRC under strace
> -ffy and read the strace file.
> Comparing strace files with working GRC instance on another PC @jcorgan
> did suggest that in execve python is missing.

And most likely the gnuradio software and the required software packages
needed to run gnuradio on PC @jcorgan are probably missing too.

A working installation of python is one of the perquisite to run gnuradio.

> 
> Bad:
> [pid  2704] execve("/usr/local/bin/", ["", "-e", "/usr/bin/python",
> "-u", "/home/pi/top_block.py"]...= -1 EACCES (Permission denied)
> Good:
> [pid 12112] execve("/usr/bin/python", ["/usr/bin/python", "-u",
> "/home/loso/top_block.py"], [/* 75 vars */] 
> 
> I'm trying to find which env variable or what option am I missing/have
> wrongly configured in GRC config or somewhere else.
Based on the content of this post, everything on your machine is working
correctly.

If you can actually generate an error message using gnuradio - other
then enclosed operator errors - post the error message, the flowgraph
and the python code.

> 
> Thank you.
> Jozef
> 
> 
> 
> ___
> 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] Spurious Spikes in RX Data

[Sean Horton]

Hi,

I've recently gotten someone with Matlab to help me look at what's going on
in my receiver. The image was created with matlab from data from a file
sink connected directly to a usrp source. I am seeing spurious spikes when
plotting I or Q, and I'm not sure where they could be coming from, or how
to get rid of them. I know what I think I'm about to transmit doesn't have
those spikes.

Some info that might be helpful:
Using a N210 with a UBX connected directly to my desktop.
I have tried a few sample rates (96000, 201613).
I am currently doing a loopback test, though working on getting the sdr to
listen to a signal generated by another piece of equipment.
This doesn't stop me from being able to decode what is transmitted, but
since my issue is I can't decode messages with as low of an SNR as I
expect, I'm trying to examine everything as closely as possible. I'm off by
20-30 dB.
The entire path to get to matlab is: usrp_source -> file_sink -> Python's
scipy in order to read in the raw data and store it in a .mat.

Also, if any responder would be kind enough to also point out how I
properly respond, that'd be great. I know I can't just hit reply to the
digest, and I also can't change the subject line when I hit reply in the
digest, so I'm sort of stumped. I have had digest mode on, so I'll turn
that off for now.

Thanks,
Sean

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

Re: [Discuss-gnuradio] How does Rx Gain affect the incoming signal? GNURadio IEEE 802.11a/g/p

[Cristian Rodríguez]

Thanks a lot for your answer Derek.


2017-07-06 6:32 GMT-05:00 Derek Kozel :

> Hello Christian,
>
> The RX gain value controls the analog gain of the USRP's receiver. If you
> run uhd_usrp_probe on the command line you will see lines such as the
> following which show the gain range and step size:
>
> |   |   |   RX Dboard: A
> |   |   |   ID: TwinRX v1.0 (0x0091)
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: TwinRX RX0
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
>
>
I run it and, as you indicated, the values are in that range.



> For every dB of gain you add at the frontend you should see a 1 dB
> increase in signal power amplitude. I recommend using uhd_fft or the USRP
> source, Frequency Sink, and a Range widget controlling RX gain to look
> directly at the signal. This should give you an intuitive sense of how RX
> gain affects your signal amplitude.
>

There's my doubt. I'm working over the Bastian's flowgraph of
IEEE802.11a/g/p. Bastian put two slicers from 0 to 1 for Rx and Tx gain,
the default value is 0.75. That's what i though the range of the gain was
from 0 to 1, because it was normalized. In the USRP_source.cc they declare
two functions:

usrp_source_impl::*set_gain*(double gain, const std::string , size_t
chan)
{
...
}

void usrp_source_impl::*set_normalized_gain*(double norm_gain, size_t
chan)
{
...
  if (norm_gain > 1.0 || norm_gain < 0.0) {
throw std::runtime_error("Normalized gain out of range, must be in
[0, 1].");
  }
   
}

If I try to put in the Gain of the block "2" then it appears:

[image: Imágenes integradas 1]

So, the interval is  normalized (between 0 to 1), that means the flowgraph
is using the second function. But maybe i have to denormalize it in dB and
later get the new signal.

I'm going to write you again, if I found how the mathematical relation is
build.

However, if you have an idea of how it could look, I would be very grateful
if you let me know.

Thanks for your time.

Best regards,

Cristian


>
> From your table it looks like you are trying to change the RX gain in
> steps smaller than the USRP supports.
>
> This document looks like a quick intro to power and voltage changes with
> dB.
> https://neurophysics.ucsd.edu/courses/physics_120/A%
> 20Practical%20Guide%20to%20Decibels.pdf
>
>
> On Wed, Jul 5, 2017 at 10:24 PM, Cristian Rodríguez <
> cristian.rodriguez...@gmail.com> wrote:
>
>> Hi all.
>>
>> I'm trying to understand how Rx gain, the paremeter that is set in the
>> USRP Source block, affects the input signal. I would like to have an
>> equation for that.
>>
>> I'm doing the next experiment:
>>
>>- I take the input signal from the USRP Source block to a MAG^2 block.
>>- From MAG^2 block to a moving average with a window of 50K.
>>- My sample rate is 10M that means that my moving average is
>>calculated over 5ms.
>>- I'm sending a signal from a transmitter each 5ms.
>>- Finally I capture the value of the moving average, which is always
>>around an average value.
>>
>> Now, I change Rx gain and it is what i get:
>>
>> [image: Imágenes integradas 1]
>>
>> The value of the output of the moving average is changing very strange. I
>> was trying to write an equation for that, but i wasn't able, i used Rx gain
>> in dB, in dBm as a constant, but i wasn't able to build a relation. In an
>> equation i'm doing as follow:
>>
>> [image: Imágenes integradas 2]
>>
>> Then I think that if I include Gtx, my equation results in:
>>
>> [image: Imágenes integradas 3]
>>
>> But that doesn't make sense with the data that I get.
>>
>>
>> I would really greatful if someone can explain where is my mistake.
>>
>>
>> Thanks in advance.
>>
>>
>> Best regards,
>>
>>
>> Cristian
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Successful installation of GNURadio 3.6.4.1 on Window XP and Windows 8

[Geof Nieboer]

I have built windows installers for gnuradio that have been available for a
bit over a year.  They include 3.7.11.1 and just last week updated them to
version 1.3,  and include a wide variety of drivers and packages all
purpose built for windows 10 64-bit.

Hopefully that will save you some trouble.  They are located at:

www.gcndevelopment.com/gnuradio/downloads.htm

Geof


On Wed, Jul 5, 2017 at 17:45 Bhaskar11  wrote:

> I've been out of touch with this work for some years, but find that many
> are still searching for the drivers referred to in this guide. As a help to
> all, I've uploaded all these drivers to a shared folder on Google Drive
> here: https://drive.google.com/open?id=0Byk3JPiq4KUKY3B1enR6djAyX1k
>
> I hope this will remain as an active archive for many years to come, even
> if the original driver links break.
>
> If I can make time, I hope someday to update these instructions for
> working under Windows 10 -- if it has not already been done by then! :)
>
> B.
>
>
> On Thu, Dec 26, 2013 at 9:40 PM, Bhaskar11  wrote:
>
>> *After much experimentation I have finally found a way to successfully
>> install and fully run GRC 3.6.4.1 both under Windows XP and Windows 8.*
>> I presume it should therefore work equally well under Vista and 7.
>>
>> First a few comments on the common causes of problems that most people
>> have had:
>>
>> a. It is critical to have the correct *matching* and *complete* versions
>> of the various required libraries. Most installations instructions online
>> fail because of this reason. The Ettus installation instructions officially
>> recommended on GNURadio website and provided here
>>  fail
>> now because many of the original binary versions referred to are no longer
>> available. Hence those instructions are now outdated and should be replaced
>> by the instructions provided in this email.
>>
>> b. Although it is possible to successfully install GNURadio binaries for
>> versions 3.7.x, none of them include runtime DLLs for WX GUI blocks. Hence
>> these blocks are not displayed, and so most of the example files available
>> cannot be used as they need WX GUI blocks. Moreover, some of the QT GUI
>> blocks do not work in certain versions. Since I do not know how to make
>> these binaries, I request those who have created these version 3.7.x
>> Windows binaries to repack them so that we can run the latest versions of
>> GNURadio in Windows. Until that is done, there is no point trying to
>> install those versions.
>>
>> c. Only GNURadio version 3.6.x binaries have WX GUI blocks. But versions
>> 3.6.2 does not allow moving the blocks. Only 3.6.4.1 is usable, and works
>> perfectly well for all available examples tested so far including all QT
>> GUI and WX GUI blocks.
>>
>> d. The required Python libraries versions are available only for Python
>> version 2.7.3 and are NOT all available for versions 2.7.6 or above, or at
>> least I could not find them online. Hence we have to use libraries
>> compatible only with Python 2.7.3.
>>
>> e. Some library versions have their quirks or bugs. For example PyGTK
>> 2.24.0 does not allow you to add blocks in GRC. Only version PyGTK 2.24.2
>> works ok. Also wxPython binary called
>> "wxPython2.8-win32-unicode-2.8.12.1-py27" just does not work, but the same
>> version but different binary called "wxPython-2.8.12.1.win32-py2.7" works
>> correctly. Most online instructions do not mention the need for
>> "wxPython-common" library, which is absolutely necessary. Also some odd
>> problems such as this
>> 
>> cease to exist when the correct libraries are matched.
>>
>> f. In the instructions below I have listed all the correct working
>> libraries and binaries with links from which to download them. Please use
>> only the binaries from these links and install them in the sequence
>> provided. Other versions or binaries may not work. Keep all default options
>> unless otherwise specified here. If you have problems working with the
>> instructions below, check your binaries, and ensure that you are doing a
>> clean install.
>>
>> Finally, please share your experiences with success and failures on this
>> list so that others may benefit.
>>
>> *Instructions to install GNURadio in Windows XP and Windows 8:*
>>
>> 1. Uninstall all earlier installations and libraries of GNURadio and
>> Python and their add-ons. Ensure that the GNURadio directory and Python
>> directory are entirely removed by the uninstalls.
>> For Windows XP GNURadio default directory is: C:\Program Files\gnuradio
>> For Windows 8 it is: C:\Program Files (x86)\gnuradio
>> For all platforms the Python default directory is: C:\Python27
>> Both the GNURadio and Python directories should be non-existent. If they
>> still exist, then delete them and reboot. We 

Re: [Discuss-gnuradio] Observing Random Jitter in HackRF One in High Bandwidth with High Carrier Modulation

[Nick Foster]

Do you actually have any evidence or plots showing excess jitter in the
HackRF One and its effect on gr-dvbt demodulation, or are you just making
it up?

It sounds like you have come to a conclusion without understanding the
problem.

--n

On Thu, Jul 6, 2017, 7:15 AM Stack Programer 
wrote:

> Yet i work on DVB-T in HackRF one, in TX we can send DVB-T and we receive
> it with a hardware dongle DVB-T. but for receiving with SDR Based we had
> error: see this link for our older
> 
> work or this
>  link.
>
> DVBT project receiver probelm OOrestart aquisition d_freq_offset: -5
> Od_freq_offset: -5
>
> So for examine my problem i created a new issue on hackrfone github
> project see this  link,
> every thing i found i will update there. In older our post we define jitter
> error , for more info you can see this
> 
> link.
>
> Fig1:Jitter error diagram description
>
>- *So we start examine that how we observed HackRF One has Random
>jitter errors??*
>
> my reason why HackRF One has random jitter error, In protocol like gr-dvbt
> ,gr-ofdm,gr-atsc that they are ofdm
> based modulation, we had not any response in receiver mode in dvb-t we had
> famous error: but frequency offset instantly from -5,3,2,7,….
>
> restart aquisition d_freq_offset: -5 Od_freq_offset: -5
>
> So we  had a error in uncertianly frequency and other hand it is random,
> so we had radom jitter errror.for more info see this
>  link.
>
>- *reason of causing HackRF  One has Jitter error?*
>- Low Resolution ADC:
>
> after some search i concluded that one of reason for random jitter error
> in HackRFOne is low resolution ADC, it has 8 bit ADC,please see this
>  link
> that describe how low resolution ADC can create jitter errors .
>
>- Low SNR in  HackRF One:
>
> For problem long switch diode stage in RF HackRF One it is more noisy vs
> USRP. So it use long way RF, it should edited in newer version.
>
> you can see in below image and link that how bad SNR and low ADC
> resolution can caused jitter errros.
>
> for more info please see this
>  link.
>
>
>
> [image: jitterADC]
>
> Fig2:low resolution ADC can cause jitter errors
>
>
>
> So we saw that HackRF One in OFDM based modulation and high carrier or in
> high bandwidth it sucks and it has random jitter errors, so we should ask
> myself that we need new design opensource hardware SDR hardware?
>
> But some question is need to answered??
>
> *why is mention HackRFOne has bandwidth 20 MSPS…..*??
> we should define bandwidth and sps in high carrier modulation
> it has problem in high carrier modulation?.So really HackRF One have
> Bandwidth more than 2 MSPS?
>
> *but what's solution?*
>
>-
>using a external clock for hackrf one???
>-
>design a new hardware………?
>
> i liked hackrfone for reason that is opensource and hardware, but with
> this condition i concluded that
> we should think a new way for future sdr hardware opensource?
>
> best regards stackprogramer
>
> Fig3:HackRFOne a opensource hardware SDR hardware
>
>
> ___
> 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] Observing Random Jitter in HackRF One in High Bandwidth with High Carrier Modulation

[Stack Programer]

Yet i work on DVB-T in HackRF one, in TX we can send DVB-T and we receive
it with a hardware dongle DVB-T. but for receiving with SDR Based we had
error: see this link for our older

work or this
 link.

DVBT project receiver probelm OOrestart aquisition d_freq_offset: -5
Od_freq_offset: -5

So for examine my problem i created a new issue on hackrfone github project
see this  link, every thing
i found i will update there. In older our post we define jitter error , for
more info you can see this

link.

Fig1:Jitter error diagram description

   - *So we start examine that how we observed HackRF One has Random jitter
   errors??*

my reason why HackRF One has random jitter error, In protocol like gr-dvbt
,gr-ofdm,gr-atsc that they are ofdm
based modulation, we had not any response in receiver mode in dvb-t we had
famous error: but frequency offset instantly from -5,3,2,7,….

restart aquisition d_freq_offset: -5 Od_freq_offset: -5

So we  had a error in uncertianly frequency and other hand it is random, so
we had radom jitter errror.for more info see this
 link.

   - *reason of causing HackRF  One has Jitter error?*
   - Low Resolution ADC:

after some search i concluded that one of reason for random jitter error in
HackRFOne is low resolution ADC, it has 8 bit ADC,please see this
 link that
describe how low resolution ADC can create jitter errors .

   - Low SNR in  HackRF One:

For problem long switch diode stage in RF HackRF One it is more noisy vs
USRP. So it use long way RF, it should edited in newer version.

you can see in below image and link that how bad SNR and low ADC resolution
can caused jitter errros.

for more info please see this
 link.



[image: jitterADC]

Fig2:low resolution ADC can cause jitter errors



So we saw that HackRF One in OFDM based modulation and high carrier or in
high bandwidth it sucks and it has random jitter errors, so we should ask
myself that we need new design opensource hardware SDR hardware?

But some question is need to answered??

*why is mention HackRFOne has bandwidth 20 MSPS…..*??
we should define bandwidth and sps in high carrier modulation
it has problem in high carrier modulation?.So really HackRF One have
Bandwidth more than 2 MSPS?

*but what's solution?*

   -
   using a external clock for hackrf one???
   -
   design a new hardware………?

i liked hackrfone for reason that is opensource and hardware, but with this
condition i concluded that
we should think a new way for future sdr hardware opensource?

best regards stackprogramer

Fig3:HackRFOne a opensource hardware SDR hardware
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How does Rx Gain affect the incoming signal? GNURadio IEEE 802.11a/g/p

[Derek Kozel]

Hello Christian,

The RX gain value controls the analog gain of the USRP's receiver. If you
run uhd_usrp_probe on the command line you will see lines such as the
following which show the gain range and step size:

|   |   |   RX Dboard: A
|   |   |   ID: TwinRX v1.0 (0x0091)
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: TwinRX RX0
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB

For every dB of gain you add at the frontend you should see a 1 dB increase
in signal power amplitude. I recommend using uhd_fft or the USRP source,
Frequency Sink, and a Range widget controlling RX gain to look directly at
the signal. This should give you an intuitive sense of how RX gain affects
your signal amplitude.

>From your table it looks like you are trying to change the RX gain in steps
smaller than the USRP supports.

This document looks like a quick intro to power and voltage changes with dB.
https://neurophysics.ucsd.edu/courses/physics_120/A%20Practical%20Guide%20to%20Decibels.pdf


On Wed, Jul 5, 2017 at 10:24 PM, Cristian Rodríguez <
cristian.rodriguez...@gmail.com> wrote:

> Hi all.
>
> I'm trying to understand how Rx gain, the paremeter that is set in the
> USRP Source block, affects the input signal. I would like to have an
> equation for that.
>
> I'm doing the next experiment:
>
>- I take the input signal from the USRP Source block to a MAG^2 block.
>- From MAG^2 block to a moving average with a window of 50K.
>- My sample rate is 10M that means that my moving average is
>calculated over 5ms.
>- I'm sending a signal from a transmitter each 5ms.
>- Finally I capture the value of the moving average, which is always
>around an average value.
>
> Now, I change Rx gain and it is what i get:
>
> [image: Imágenes integradas 1]
>
> The value of the output of the moving average is changing very strange. I
> was trying to write an equation for that, but i wasn't able, i used Rx gain
> in dB, in dBm as a constant, but i wasn't able to build a relation. In an
> equation i'm doing as follow:
>
> [image: Imágenes integradas 2]
>
> Then I think that if I include Gtx, my equation results in:
>
> [image: Imágenes integradas 3]
>
> But that doesn't make sense with the data that I get.
>
>
> I would really greatful if someone can explain where is my mistake.
>
>
> Thanks in advance.
>
>
> Best regards,
>
>
> Cristian
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,

On 07/06/2017 07:55 AM, sumitstop wrote:

Hello Bastian,
Sorry for late response.
I am attaching the files for your reference. There are 2 grc files

1. wifi_zigbee.grc : wifi and zigbee loopbacks are running in parallel >>
works good

2. wifi_zigbee_interference.grc : Here I interpolate the zigbee output by 5,
feed to channel, add to 20 MHz wifi signal. Added signal is fed directly to
wifi receiver however I decimate it by 5 before feeding it to zigbee
receiver.

I see the following on the terminal for the 2nd grc file.

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-283-g7ff43262
MAPPER: encoding: 0
set_min_output_buffer on block 9 to 397056
set_min_output_buffer on block 11 to 397056
set_min_output_buffer on block 13 to 397056
set_min_output_buffer on block 14 to 397056
set_min_output_buffer on block 16 to 397056
sender started
set_min_output_buffer on block 58 to 96000


After that nothing happens, just the cursor keeps blinking.

wifi_zigbee.grc


wifi_zigbee_interference.grc




I was playing a bit around with the flow graph. Forgot what the actual 
problem was, but this adapted version works for me:


http://www.ccs-labs.org/~bloessl/wifi_zigbee_interference.grc

Best,
Bastian

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

[Discuss-gnuradio] burst_tagger trigger type

[Johannes Demel]

Hi everyone,

I've been working with 'blocks::burst_tagger' for a while now and I 
wonder why the trigger input expects shorts. The impl only checks if 
'trigger[i] > 0'.
I would expect the trigger type to be 'char'. This would fit with the 
output of blocks like 'Plateau Detector' or 'Peak Detector'. Also, these 
blocks are all located in the 'Peak Detectors' category. It would be 
great if their port types would fit.
I suggest to change the type of the trigger to 'char'. Maybe the 
original burst tagger can be moved to 'Deprecated'.


Johannes

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

[Discuss-gnuradio] GRC [Errno 13] Permission denied for No GUI graphs

[Jozef Lošonský]

Hello,
my GRC is unable to execute graphs (no GUI elements) when I switch option
to No GUI, everything else seems to be working. In addition "No GUI" py
script (generated by same GRC) is running fine in console of the same user
which is running GRC what is interesting. I didn't find other way how to
try get more info about issue than run whole GRC under strace -ffy and read
the strace file.
Comparing strace files with working GRC instance on another PC @jcorgan did
suggest that in execve python is missing.

Bad:
[pid  2704] execve("/usr/local/bin/", ["", "-e", "/usr/bin/python", "-u",
"/home/pi/top_block.py"]...= -1 EACCES (Permission denied)
Good:
[pid 12112] execve("/usr/bin/python", ["/usr/bin/python", "-u",
"/home/loso/top_block.py"], [/* 75 vars */] 

I'm trying to find which env variable or what option am I missing/have
wrongly configured in GRC config or somewhere else.

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[sumitstop]

Hello Bastian, 
Sorry for late response. 
I am attaching the files for your reference. There are 2 grc files 

1. wifi_zigbee.grc : wifi and zigbee loopbacks are running in parallel >>
works good

2. wifi_zigbee_interference.grc : Here I interpolate the zigbee output by 5,
feed to channel, add to 20 MHz wifi signal. Added signal is fed directly to
wifi receiver however I decimate it by 5 before feeding it to zigbee
receiver. 

I see the following on the terminal for the 2nd grc file.

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-283-g7ff43262
MAPPER: encoding: 0
set_min_output_buffer on block 9 to 397056
set_min_output_buffer on block 11 to 397056
set_min_output_buffer on block 13 to 397056
set_min_output_buffer on block 14 to 397056
set_min_output_buffer on block 16 to 397056
sender started
set_min_output_buffer on block 58 to 96000


After that nothing happens, just the cursor keeps blinking.

wifi_zigbee.grc
  

wifi_zigbee_interference.grc
  



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Running-gr-ieee-802-11-and-gr-ieee-802-15-4-under-same-flowgraph-interference-and-co-existence-tp64474p64483.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