Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

[Dennis Glatting]

On Wed, 2017-03-22 at 09:34 +0500, Usman Haider wrote:
> 
> 
> On Wed, Mar 22, 2017 at 2:52 AM, Dennis Glatting 
> wrote:
> > On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote:
> > > Hi,
> > >
> > > I am currently building GNU Radio 3.7.10.1 on Beaglebone black
> > > running Debian 8.6.  I have disable some components for testing
> > and
> > > to speed up the process. After installing the dependencies when I
> > run
> > > cmake I am getting following messages. Are these messages okay?
> > Do I
> > > have to pass any flags to cmake like -march etc or not?
> > >
> > > 
> > > -- Performing Test have_msse2
> > > -- Performing Test have_msse2 - Failed
> > > -- Performing Test have_msse3
> > > -- Performing Test have_msse3 - Failed
> > > -- Performing Test have_mssse3
> > > -- Performing Test have_mssse3 - Failed
> > > -- Performing Test have_msse4a
> > > -- Performing Test have_msse4a - Failed
> > > -- Performing Test have_msse4_1
> > > -- Performing Test have_msse4_1 - Failed
> > > -- Performing Test have_mavx
> > > -- Performing Test have_mavx - Failed
> > > -- Performing Test have_mavx2
> > > -- Performing Test have_mavx2 - Failed
> > > -- Architecture is not x86 or x86_64, Overruled arch 3dnow
> > > -- Architecture is not x86 or x86_64, Overruled arch mmx
> > > -- Architecture is not x86 or x86_64, Overruled arch sse
> > > -- Architecture is not x86 or x86_64, Overruled arch sse2
> > > -- Architecture is not x86 or x86_64, Overruled arch sse3
> > > -- Architecture is not x86 or x86_64, Overruled arch ssse3
> > > -- Architecture is not x86 or x86_64, Overruled arch sse4_a
> > > -- Architecture is not x86 or x86_64, Overruled arch sse4_1
> > > -- Architecture is not x86 or x86_64, Overruled arch sse4_2
> > > -- Architecture is not x86 or x86_64, Overruled arch avx
> > > -- Available architectures: generic;hardfp;neon;orc;norc
> > > -- Available machines: generic_orc;neon_hardfp_orc
> > > -- BUILD TYPE = RELEASE
> > > -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
> > -Wsign-
> > > compare -Wall -Wno-uninitialized -Wall
> > > -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -
> > std=gnu99
> > > -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
> > -Wall 
> > > -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -
> > > std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-
> > uninitialized
> > > -Wall -mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
> > > -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
> > > Copyright (C) 2014 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions. 
> > There
> > > is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A
> > PARTICULAR
> > > PURPOSE.
> > > --  Adding ASM files
> > > -- -- Detected neon architecture; enabling ASM
> > > -- Adding source file:
> > >
> > /home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_
> > ho
> > > rizontal_16i.s
> > >
> > > ...
> > > ...
> > > Complete output
> > >
> > > http://pastebin.com/t3KSu0f5
> > >
> > >
> > >
> > 
> > You can build from source on the Beagle. I have done it. 
> Great!
>  
> > However, the
> > Beagle has only a single core processor, you will have to mount
> > swap
> > space, the 4G of memory isn't roomy - at all, and you will have to
> > install a bunch of additional packages. 
> > 
> Can you point me to those packages so that I do not miss something? I
> installed pre-reqs for GNU Radio and cmake seems to run fine with
> some warnings/messages as shown in my first email. 
>  

Pybombs is a more robust solution but at the time I did a lot of trial
and error - I ran configure, looked at the results, then installed what
satisfied the errors and missing features.


> > I don't recommend native builds but it can be done. Cross develop
> > if
> > you can. I seem to recall it took a few /days/ to build, multiply
> > if
> > there is a failure. You should also mount an external USB disk for
> > swap, /tmp, etc. 
> >  
> 
> The compiler on the Beagle is old. I installed a more modern version.
> 
> I tried to cross develop but was not able to do so. I am still
> working on that approach. If you have done it or have any pointers
> please do share.  What compiler did you use? Did you do a full
> install of GNU Radio on BBB?  

I only found one cross solution but it required custom tweaks to qemu.
It was pain.

I satisfied as many GNURadio dependencies as I could. I also built and
ran gnuradio-companion on the Beagle. The real SoC target was a
CubieBoard4 whereas the Beagle was for proof of concept. Neither of
those targets supported OpenCL, which we also wanted to do for another
proof of concept. I wanted an OpenACC capable compiler but nothing
useful was found.

The real development work was done on a 5GHz AMD box (over clocked,
liquid cooled). I simply ported my blocks and the run graph to the SoCs
(after I installed GNURadio). Since I was using OpenMP and C++11
features, I 

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

[Usman Haider]

On Wed, Mar 22, 2017 at 2:52 AM, Dennis Glatting  wrote:

> On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote:
> > Hi,
> >
> > I am currently building GNU Radio 3.7.10.1 on Beaglebone black
> > running Debian 8.6.  I have disable some components for testing and
> > to speed up the process. After installing the dependencies when I run
> > cmake I am getting following messages. Are these messages okay? Do I
> > have to pass any flags to cmake like -march etc or not?
> >
> > 
> > -- Performing Test have_msse2
> > -- Performing Test have_msse2 - Failed
> > -- Performing Test have_msse3
> > -- Performing Test have_msse3 - Failed
> > -- Performing Test have_mssse3
> > -- Performing Test have_mssse3 - Failed
> > -- Performing Test have_msse4a
> > -- Performing Test have_msse4a - Failed
> > -- Performing Test have_msse4_1
> > -- Performing Test have_msse4_1 - Failed
> > -- Performing Test have_mavx
> > -- Performing Test have_mavx - Failed
> > -- Performing Test have_mavx2
> > -- Performing Test have_mavx2 - Failed
> > -- Architecture is not x86 or x86_64, Overruled arch 3dnow
> > -- Architecture is not x86 or x86_64, Overruled arch mmx
> > -- Architecture is not x86 or x86_64, Overruled arch sse
> > -- Architecture is not x86 or x86_64, Overruled arch sse2
> > -- Architecture is not x86 or x86_64, Overruled arch sse3
> > -- Architecture is not x86 or x86_64, Overruled arch ssse3
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_a
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_1
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_2
> > -- Architecture is not x86 or x86_64, Overruled arch avx
> > -- Available architectures: generic;hardfp;neon;orc;norc
> > -- Available machines: generic_orc;neon_hardfp_orc
> > -- BUILD TYPE = RELEASE
> > -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden -Wsign-
> > compare -Wall -Wno-uninitialized -Wall
> > -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> > -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
> > -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -
> > std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
> > -Wall -mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
> > -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
> > Copyright (C) 2014 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There
> > is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > --  Adding ASM files
> > -- -- Detected neon architecture; enabling ASM
> > -- Adding source file:
> > /home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_ho
> > rizontal_16i.s
> >
> > ...
> > ...
> > Complete output
> >
> > http://pastebin.com/t3KSu0f5
> >
> >
> >
>
> You can build from source on the Beagle. I have done it.


Great!


> However, the
> Beagle has only a single core processor, you will have to mount swap
> space, the 4G of memory isn't roomy - at all, and you will have to
> install a bunch of additional packages.
>
>
Can you point me to those packages so that I do not miss something? I
installed pre-reqs for GNU Radio and cmake seems to run fine with some
warnings/messages as shown in my first email.


> I don't recommend native builds but it can be done. Cross develop if
> you can. I seem to recall it took a few /days/ to build, multiply if
> there is a failure. You should also mount an external USB disk for
> swap, /tmp, etc.
>

The compiler on the Beagle is old. I installed a more modern version.
>
> I tried to cross develop but was not able to do so. I am still working on
that approach. If you have done it or have any pointers please do share.
What compiler did you use? Did you do a full install of GNU Radio on BBB?

> The Beagle isn't suited for GNURadio unless you have a low data rate
> and low memory requirements, but it can work.
>
> I'll also use low data-rates :)


> Regarding VOLK, you may have to tune the build. You will have to look
> up the processor specifics and tune the build appropriately.
>
>
I'll look how can I do it. Thanks for your time.

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

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

[Usman Haider]

Hi Marcus,

I tried to setup a cross-compile environment on a PC but was not able to do
so for BBB although I am able to do so for E310, thanks to people@ettus
for providing the SDK :). I am still learning how can I do it for BBB. But
at the same time I am trying to build GNU Radio, with some components
disabled to reduce the build time, on BBB. Thanks for your inputs you are
always helpful.

--
Usman

On Tue, Mar 21, 2017 at 11:24 PM, Marcus Müller 
wrote:

> Also, the jessie-backports Debian Repo contains GNU Radio 3.7.10.1 (thanks
> Maitland!) and that is pretty current, so I don't really see a reason to
> compile such a massive piece of software on the beaglebone.
>
> Best regards,
>
> Marcus
>
> On 21.03.2017 19:21, Marcus Müller wrote:
>
> Hi Usman,
>
> so, is there anything wrong?
>
> By the way, it's usually not a good idea to build software *on* an
> embedded device itself; you'd typically try to get your software built on a
> "proper" PC, because compiling C++ is a very RAM and disk IO intense
> operation, and takes O(forever) time on a Beaglebone.
>
> Best regards,
>
> Marcus
>
> On 21.03.2017 18:59, Usman Haider wrote:
>
> Hi,
>
> I am currently building GNU Radio 3.7.10.1 on Beaglebone black running
> Debian 8.6.  I have disable some components for testing and to speed up the
> process. After installing the dependencies when I run cmake I am getting
> following messages. Are these messages okay? Do I have to pass any flags to
> cmake like -march etc or not?
>
> 
> -- Performing Test have_msse2
> -- Performing Test have_msse2 - Failed
> -- Performing Test have_msse3
> -- Performing Test have_msse3 - Failed
> -- Performing Test have_mssse3
> -- Performing Test have_mssse3 - Failed
> -- Performing Test have_msse4a
> -- Performing Test have_msse4a - Failed
> -- Performing Test have_msse4_1
> -- Performing Test have_msse4_1 - Failed
> -- Performing Test have_mavx
> -- Performing Test have_mavx - Failed
> -- Performing Test have_mavx2
> -- Performing Test have_mavx2 - Failed
> -- Architecture is not x86 or x86_64, Overruled arch 3dnow
> -- Architecture is not x86 or x86_64, Overruled arch mmx
> -- Architecture is not x86 or x86_64, Overruled arch sse
> -- Architecture is not x86 or x86_64, Overruled arch sse2
> -- Architecture is not x86 or x86_64, Overruled arch sse3
> -- Architecture is not x86 or x86_64, Overruled arch ssse3
> -- Architecture is not x86 or x86_64, Overruled arch sse4_a
> -- Architecture is not x86 or x86_64, Overruled arch sse4_1
> -- Architecture is not x86 or x86_64, Overruled arch sse4_2
> -- Architecture is not x86 or x86_64, Overruled arch avx
> -- Available architectures: generic;hardfp;neon;orc;norc
> -- Available machines: generic_orc;neon_hardfp_orc
> -- BUILD TYPE = RELEASE
> -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
> -mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
> -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> --  Adding ASM files
> -- -- Detected neon architecture; enabling ASM
> -- Adding source file: /home/debian/gnuradio/volk/
> kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s
>
> ...
> ...
> Complete output
>
> http://pastebin.com/t3KSu0f5
>
>
> Thanks.
>
> --
> Usman
>
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Kartik Patel]

Oh! Excellent. Never thought about this. So, basically we may want to develop
a read-only version of webgui in future. Let me see how can I add the webGui
block with QT. If it is not possible during GSoC, I think we can easily extend
the current structure to make it read-only and by using a external block without
any ports. I hope that's fine.
Thank you very much for the suggestion. This is definitely worth a try now or
later.
Regards,Kartik Patel  






On Wed, Mar 22, 2017 4:21 AM, Sylvain Munaut 246...@gmail.com  wrote:

If we see from the user perspective, why would someone need two displays ?





You're assuming it would be the same people ... or at the same time.




* I could use QT locally but still expose a web UI for people to

remotely see what I'm describing. The local Qt UI could be more

complete and just have a basic read-only version exposed to others.

* I could use Qt locally with advanced visualization (fosphor for

instance) but still want a basic spectrum available on my phone so I

can go outside, tweak the antenna and see improvements live then come

back to my local station.




That's just off the top of my mind.




Cheers,




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

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

[Sylvain Munaut]

> If we see from the user perspective, why would someone need two displays ?

You're assuming it would be the same people ... or at the same time.

* I could use QT locally but still expose a web UI for people to
remotely see what I'm describing. The local Qt UI could be more
complete and just have a basic read-only version exposed to others.
* I could use Qt locally with advanced visualization (fosphor for
instance) but still want a basic spectrum available on my phone so I
can go outside, tweak the antenna and see improvements live then come
back to my local station.

That's just off the top of my mind.

Cheers,

   Sylvain

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

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

[Kartik Patel]

Hello Sylvain,  
One thing that I find a bit weird in the proposal is to use a new "generate

option" webui.

For the qt/wx/... that makes more sense because :
(1) they're exclusive, you can't be both WX and QT, trying to link multiple
graphics framework in the same app is just not practical (possible).
(2) because of some fundamental ways the app is going to be run when links to a
local gui toolkit, it's hard to do otherwise.
However, I don't see why having both a local QT GUI _and_ exposing a Web UI
would have to be exclusive.
The "global" options for a Web UI could be in a block without port (much like
there is a xmlrpc server block, or also the Device3 block in RFNoC). That block
instance would take care of setting up all the global stuff that can be used by
the actual UI blocks sending data to clients.





If we see from the user perspective, why would someone need two displays ? One
using QT/WX and other from web. So, using multiple graphics framework in the
same app is not practical and not possible but on the other hand, using QT/WX
simultaneously is possible but not practical.
Also, top_block.py will be keep running until QT window is closed. In case of
web based GUI, top_block will be keep running until the server stops. Now,
merging this two is critical. I hope you understand what I mean.
Just my 2ct.Thanks for that. Pennies make dollars.
Regards,Kartik Patel___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Sylvain Munaut]

Hi,


One thing that I find a bit weird in the proposal is to use a new "generate
option" webui.

For the qt/wx/... that makes more sense because :

 (1) they're exclusive, you can't be both WX and QT, trying to link
multiple graphics framework in the same app is just not practical
(possible).
 (2) because of some fundamental ways the app is going to be run when links
to a local gui toolkit, it's hard to do otherwise.

However, I don't see why having both a local QT GUI _and_ exposing a Web UI
would have to be exclusive.

The "global" options for a Web UI could be in a block without port (much
like there is a xmlrpc server block, or also the Device3 block in RFNoC).
That block instance would take care of setting up all the global stuff that
can be used by the actual UI blocks sending data to clients.


Just my 2ct.


Cheers,

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

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

[Dennis Glatting]

On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote:
> Hi,
> 
> I am currently building GNU Radio 3.7.10.1 on Beaglebone black
> running Debian 8.6.  I have disable some components for testing and
> to speed up the process. After installing the dependencies when I run
> cmake I am getting following messages. Are these messages okay? Do I
> have to pass any flags to cmake like -march etc or not?
> 
> 
> -- Performing Test have_msse2
> -- Performing Test have_msse2 - Failed
> -- Performing Test have_msse3
> -- Performing Test have_msse3 - Failed
> -- Performing Test have_mssse3
> -- Performing Test have_mssse3 - Failed
> -- Performing Test have_msse4a
> -- Performing Test have_msse4a - Failed
> -- Performing Test have_msse4_1
> -- Performing Test have_msse4_1 - Failed
> -- Performing Test have_mavx
> -- Performing Test have_mavx - Failed
> -- Performing Test have_mavx2
> -- Performing Test have_mavx2 - Failed
> -- Architecture is not x86 or x86_64, Overruled arch 3dnow
> -- Architecture is not x86 or x86_64, Overruled arch mmx
> -- Architecture is not x86 or x86_64, Overruled arch sse
> -- Architecture is not x86 or x86_64, Overruled arch sse2
> -- Architecture is not x86 or x86_64, Overruled arch sse3
> -- Architecture is not x86 or x86_64, Overruled arch ssse3
> -- Architecture is not x86 or x86_64, Overruled arch sse4_a
> -- Architecture is not x86 or x86_64, Overruled arch sse4_1
> -- Architecture is not x86 or x86_64, Overruled arch sse4_2
> -- Architecture is not x86 or x86_64, Overruled arch avx
> -- Available architectures: generic;hardfp;neon;orc;norc
> -- Available machines: generic_orc;neon_hardfp_orc
> -- BUILD TYPE = RELEASE
> -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden -Wsign-
> compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall 
> -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -
> std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized 
> -Wall -mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
> -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> --  Adding ASM files
> -- -- Detected neon architecture; enabling ASM
> -- Adding source file:
> /home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_ho
> rizontal_16i.s
> 
> ...
> ...
> Complete output
> 
> http://pastebin.com/t3KSu0f5
> 
> 
> 

You can build from source on the Beagle. I have done it. However, the
Beagle has only a single core processor, you will have to mount swap
space, the 4G of memory isn't roomy - at all, and you will have to
install a bunch of additional packages. 

I don't recommend native builds but it can be done. Cross develop if
you can. I seem to recall it took a few /days/ to build, multiply if
there is a failure. You should also mount an external USB disk for
swap, /tmp, etc. 

The compiler on the Beagle is old. I installed a more modern version.

The Beagle isn't suited for GNURadio unless you have a low data rate
and low memory requirements, but it can work.

Regarding VOLK, you may have to tune the build. You will have to look
up the processor specifics and tune the build appropriately.



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

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

[Kartik Patel]

Hello all,
Thank you very much for the discussions and feedbacks. I will try to answer all
of them one-by-one.
Mail from Marcus: * said server has a REST API, i.e. ispolled from the client 
only? Or can there
   be pushing data from server -> client? What is the model you'd prefer? Your
   proposal says "stream to the clients", but I can't find that in Bokeh (but
   then again: no experience on interactive Web dev on my side at all, so this
   might be really easy for you, if possible).

Although server has a REST API, the bokeh use sockets to transfer the data.
Websockets are like pipelines of data which can be used by both server and
client. This is not based on typical request-response model of the web. "Stream
to the client" means server will sent data to the client without client asking
it. The data transfer can be continuous until socket is not broken (from either
side). For an example: Video streaming asks for the video once, and then a
simple socket will stream the data in frames (without client asking for more
data at every frame). * I've no idea how to talk GR data -> bokeh-server. Maybe
   you could elaborate on how you do that?

Consider the #L62 in time_sink_f.py in my prototype [1]. The function stream of
the DataSource object will stream data to respective socket. This data source is
initialised at #L50 in same file and connected to the plot in the line #L51. So,
every time after processing the data through GR, it can be streamed through the
function to the server. This streaming can be handled by Bokeh library. * the
   JSON is relatively verbose, and contains basically all imaginable settings
   for a plot. However, I presume a data update from the bokeh-server would only
   consist of the model data, which, for a 5-point line graph would consist of
   (this is pretty-printed, Bokeh omits all the whitespace/line breaks):

Correct. * Hence, if performance of the python server is doubted, or integration
   into GR is complicated, you could also just write a C++ block that takes
   numerical values from GNU Radio and serves them via Websocket (how does one
   do that?), and point BokehJS at that instead? (example from [0], found the
   embed_items declaration in [1])
   

Although we can do that, but I don't think it is necessary. We are not doing
anything in Python except the streaming. All processing is done by C++. But I
have never used Python where its speed is the constraint. So, may be you can
suggest me more on this. I don't think that the Socket will limit the dataflow.
Also, since for now we are limiting the use-case to the local network, the speed
of network will not be the problem. * However, when running and changing the
   data source, I see all the plot JSON being transferred, the ColumnDataSource
   object just being about half of the 12 kB response object (amongst dozens of
   requests made to react to this change of model, but that might be an effect
   of this being a feature-rich plot).
   

Although I did not understand the point you are making, but considering our
use-case, we don't need to change the data source. * Can you please explain the
   user work flow? I would have imagined that the users design their "plot
   layout" either
 * implicitly (by just using
   your sinks in their flow graph), so that gr-bokehgui builds a HTML page
   containing the plots they want on its own, orexplicitly by designing an HTML
   page with  placeholders on their own and tell gr-bokehgui "hey, use
   that; the plot  IDs are [list of IDs]",
 * but I'm not sure you'd
   support the second method, since you mention the ability to add labels and
   such, which would be relatively redundant with that.

The user will add a sink fromgr-bokehgui. On the user side, everything is
exactly same as using the current QT GUI sinks. About layout and all, I agree on
the first point. Again, it will be similar to what gr-qtgui is doing as of now.
It will automatically adjust the layout of the plots. We can have some CSS or
Javascript tricks on the frontend to adjust the plots layout and all. But that
can be added later.Now the things I'm not sure about:


 * Bokeh is Python library that produces plots
 * It's plotting frontend is HTML & Javascript
 * This enables interactive plotting (ie. you can zoom in, pan etc without
   updating the dataset visualized)
 * The frontend Javascript is a library (BokehJS) used in a "standard" piece of
   code that you feed two things:
 * The ID of the HTML  tag to be filled with the graphThe data and plot
   settings to be visualized as JSON
 * Bokeh (the python library) comes with a Python-implemented server that you're
   planning to use

All of these points are correct.
I hope these queries are probably solved. Let me know if you have more queries.
I will also address these in my proposal because I think it is the fundamental
concept of the module.

The mail from Sebastian:While bokeh (and plotly) were mentioned in the proposal
only because the idea was inspired from 

Re: [Discuss-gnuradio] installing a python package without elevated privileges

[Marcus Müller]

Huh, that seems a bit *too* permissive – other users might thus have
modified freely a script that you run as your user!


On 21.03.2017 21:39, Naceur wrote:
> Thanks. I just circumvented it by getting rid of pip requirement and asking
> the recipe to get the deb/rpm requirements instead.
> FYI, my /home/nae/.local/bin/pip was already allowed 777.
>
> Regards,
> Naceur
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/installing-a-python-package-without-elevated-privileges-tp63183p63229.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] examples of use of command ports for usrp sink and source

[Naceur]

Hello GR,

Are there any grc flowgraphs showing use of looped USRP Source/Sink for
examples if in the middle of some flowgraphs I needed to re-tune the Radio.

I just saw in the corresponding grc blocks "command" port but I don't know
what are they expecting.

Regards,
Naceur



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/examples-of-use-of-command-ports-for-usrp-sink-and-source-tp63230.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] installing a python package without elevated privileges

[Naceur]

Thanks. I just circumvented it by getting rid of pip requirement and asking
the recipe to get the deb/rpm requirements instead.
FYI, my /home/nae/.local/bin/pip was already allowed 777.

Regards,
Naceur



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/installing-a-python-package-without-elevated-privileges-tp63183p63229.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] no payload length passed from header data

[lbyhp]

I have figured it out myself. 
The length tag key in the Head Payload Demux block must match the key value
in the header. In my case, it is "payload symbols".





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/no-payload-length-passed-from-header-data-tp63160p63228.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] installing a python package without elevated privileges

[Marcus Müller]

Personal two cents: On most modern linuxes, you shouldn't be installing
mako via pip, and much less even numpy (because that's a huge compile
including fortran interfaces).

I just go and remove pip from the list of preferred packagers on my
systems¹. Never ran into problems with that. Now, I've never had the
need to install a python package that wasn't there as a distro package
in the last months on my recent systems, and on my retro systems I
typically not use pybombs, but your needs seem to be different. But
that's the problem here: PyBOMBS has to make sume assumptions on how you
want to install packages, and these include that pip needs to run as
root. Now, it seems that your ~/.local/bin/pip doesn't have the file
priorities set to allow others (including root, as it seems) to execute
it. You could check with "stat /home/nae/.local/bin/pip" what the
"Access" rights are. Should be something like 0755 / -rwxr-xr-x; my
guess is the last r-x is missing.

Best regards,

Marcus

¹ I'm even in personal disagreement with the folks maintaining Pybombs
on whether pip should be allowed to install things globally at all if a
package could potentially also be installed via native methods. But
generally, Pybombs is an awesome tool, and so is pip.

On 21.03.2017 19:45, Naceur wrote:
> Thank you for your reply. However, I don't want to have anything done
> manually. 
> Maybe I need rephrasing my initial post: 
>
> It is not that I want PyBOMBS to to do a pip --user but I am more wondering
> why it is saying:
>
>> PyBOMBS.PackageManager - DEBUG - Using packager pip 
>> PyBOMBS.Packager.pip - DEBUG - Calling `/home/nae/.local/bin/pip install
>> pytun' 
>> PyBOMBS.monitor_process() - DEBUG - Running with elevated privileges. 
>> PyBOMBS._process_thread() - DEBUG - Executing command `['sudo', '-H',
>> '/home/nae/.local/bin/pip', 'install', 'pytun']' 
>> sudo: unable to execute /home/nae/.local/bin/pip: Permission denied 
>> PyBOMBS.monitor_process() - DEBUG - Thread signaled termination or
>> returned 
>> PyBOMBS.monitor_process() - DEBUG - Return value: 1 
> why is it going straight to elevated priviliges.
> I looked for a package that needs installation through pip and found mako
> and numpy. 
> I realized that when uhd was installed it needed mako as a prerequesite and
> it did install it without the elevation and error.
>
> Thanks,
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/installing-a-python-package-without-elevated-privileges-tp63183p63226.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] installing a python package without elevated privileges

[Naceur]

Thank you for your reply. However, I don't want to have anything done
manually. 
Maybe I need rephrasing my initial post: 

It is not that I want PyBOMBS to to do a pip --user but I am more wondering
why it is saying:

> PyBOMBS.PackageManager - DEBUG - Using packager pip 
> PyBOMBS.Packager.pip - DEBUG - Calling `/home/nae/.local/bin/pip install
> pytun' 
> PyBOMBS.monitor_process() - DEBUG - Running with elevated privileges. 
> PyBOMBS._process_thread() - DEBUG - Executing command `['sudo', '-H',
> '/home/nae/.local/bin/pip', 'install', 'pytun']' 
> sudo: unable to execute /home/nae/.local/bin/pip: Permission denied 
> PyBOMBS.monitor_process() - DEBUG - Thread signaled termination or
> returned 
> PyBOMBS.monitor_process() - DEBUG - Return value: 1 

why is it going straight to elevated priviliges.
I looked for a package that needs installation through pip and found mako
and numpy. 
I realized that when uhd was installed it needed mako as a prerequesite and
it did install it without the elevation and error.

Thanks,



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/installing-a-python-package-without-elevated-privileges-tp63183p63226.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] Python/SWIG problems

[Martin Braun]

Awesome! Thanks, Dan!

-- M

On 03/21/2017 10:25 AM, Daniel P. Martin wrote:
> I will volunteer to do that! I've got a deadline this week keeping me
> very busy and then a week on vacation, so it may be two weeks before I
> get to it.
> 
> Regards,
> 
> Dan
> 
> 
> On 3/21/17 12:09 PM, Martin Braun wrote:
>> Dan,
>>
>> would you like to add the info the wiki? Maybe onto the FAQ?
>>
>> -- M
>>
>> On 03/20/2017 01:46 AM, Daniel P. Martin wrote:
>>> I found the answer to this post in the discuss-gnuradio archive. The
>>> answer was posted by Patrick Sathyanathan:
>>>
>>> [Discuss-gnuradio] OOT Module Attribute Error module object has no
>>> attribute 'blockname'
>>> 
>>>
>>> The problem I had was exactly as Patrick describs, as was the solution.
>>>
>>> I'd recommend putting this information on the new Wiki!
>>>
>>> Dan Martin
>>>
>>>
>>> On 3/19/17 10:11 PM, Daniel P. Martin wrote:
 I periodically run into problems with the Python/SWIG portion of my
 out-of-tree module builds. Wrapper modules are built by swig but
 appear empty.

 I'm running Ubuntu 16.04.

 The error I get when I try to run a typical flowgraph that uses my
 "abc_module" from GRC is

 
 Using Volk machine: avx2_64_mmx_orc
 [...]
 AttributeError: 'module' object has no attribute 'periodic_burst_source'
 ---

 SWIG appears to run and generate the wrapper files during the make,
 but the wrapper files don't have the interface. I thought I'd fixed
 this by reinstalling GNU radio, but now a module that once built
 properly is failing as above. I can run python and "import abc_module"
 but "Dir(abc_module)" shows it to be empty.

 There are multiple SWIG distribution/versions available. At one point
 I thought switching to SWIG 3.0 fixed this issue but the last time it
 cropped up switching to 3.0 had no effect.

 Also, the "make install" installing wrappers in
 /usr/local/lib/python2.7/dist-packages, though on another machine I
 have it has installed wrappers in /usr/lib/python2.7/dist-packages.

 Does anyone have tips or advice on debugging these issues?

 Thanks,
 Dan
>>> -- 
>>> Dr. Daniel Martin
>>> Acadia Controls, LLC
>>> 110 Gateway Commons Dr
>>> Gorham, ME
>>> 207 838-6465 mobile
>>> 207 839-6303 fax, office
>>> www.acadiacontrols.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
>>
> 
> -- 
> Dr. Daniel Martin
> Acadia Controls, LLC
> 110 Gateway Commons Dr
> Gorham, ME
> 207 838-6465 mobile
> 207 839-6303 fax, office
> www.acadiacontrols.com
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

[Marcus Müller]

Also, the jessie-backports Debian Repo contains GNU Radio 3.7.10.1
(thanks Maitland!) and that is pretty current, so I don't really see a
reason to compile such a massive piece of software on the beaglebone.

Best regards,

Marcus


On 21.03.2017 19:21, Marcus Müller wrote:
>
> Hi Usman,
>
> so, is there anything wrong?
>
> By the way, it's usually not a good idea to build software *on* an
> embedded device itself; you'd typically try to get your software built
> on a "proper" PC, because compiling C++ is a very RAM and disk IO
> intense operation, and takes O(forever) time on a Beaglebone.
>
> Best regards,
>
> Marcus
>
>
> On 21.03.2017 18:59, Usman Haider wrote:
>> Hi,
>>
>> I am currently building GNU Radio 3.7.10.1 on Beaglebone black
>> running Debian 8.6.  I have disable some components for testing and
>> to speed up the process. After installing the dependencies when I run
>> cmake I am getting following messages. Are these messages okay? Do I
>> have to pass any flags to cmake like -march etc or not?
>>
>> 
>> -- Performing Test have_msse2
>> -- Performing Test have_msse2 - Failed
>> -- Performing Test have_msse3
>> -- Performing Test have_msse3 - Failed
>> -- Performing Test have_mssse3
>> -- Performing Test have_mssse3 - Failed
>> -- Performing Test have_msse4a
>> -- Performing Test have_msse4a - Failed
>> -- Performing Test have_msse4_1
>> -- Performing Test have_msse4_1 - Failed
>> -- Performing Test have_mavx
>> -- Performing Test have_mavx - Failed
>> -- Performing Test have_mavx2
>> -- Performing Test have_mavx2 - Failed
>> -- Architecture is not x86 or x86_64, Overruled arch 3dnow
>> -- Architecture is not x86 or x86_64, Overruled arch mmx
>> -- Architecture is not x86 or x86_64, Overruled arch sse
>> -- Architecture is not x86 or x86_64, Overruled arch sse2
>> -- Architecture is not x86 or x86_64, Overruled arch sse3
>> -- Architecture is not x86 or x86_64, Overruled arch ssse3
>> -- Architecture is not x86 or x86_64, Overruled arch sse4_a
>> -- Architecture is not x86 or x86_64, Overruled arch sse4_1
>> -- Architecture is not x86 or x86_64, Overruled arch sse4_2
>> -- Architecture is not x86 or x86_64, Overruled arch avx
>> -- Available architectures: generic;hardfp;neon;orc;norc
>> -- Available machines: generic_orc;neon_hardfp_orc
>> -- BUILD TYPE = RELEASE
>> -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
>> -Wsign-compare -Wall -Wno-uninitialized -Wall
>> -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
>> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall 
>> -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG
>>  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
>> -Wno-uninitialized -Wall -mfpu=neon -funsafe-math-optimizations
>> -mfloat-abi=hard
>> -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There
>> is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>> --  Adding ASM files
>> -- -- Detected neon architecture; enabling ASM
>> -- Adding source file:
>> /home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s
>>
>> ...
>> ...
>> Complete output
>>
>> http://pastebin.com/t3KSu0f5
>>
>>
>> Thanks.
>>
>> --
>> Usman
>>
>>
>>
>>
>>
>> ___
>> 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] GNU Radio on Beaglebone black

[Marcus Müller]

Hi Usman,

so, is there anything wrong?

By the way, it's usually not a good idea to build software *on* an
embedded device itself; you'd typically try to get your software built
on a "proper" PC, because compiling C++ is a very RAM and disk IO
intense operation, and takes O(forever) time on a Beaglebone.

Best regards,

Marcus


On 21.03.2017 18:59, Usman Haider wrote:
> Hi,
>
> I am currently building GNU Radio 3.7.10.1 on Beaglebone black running
> Debian 8.6.  I have disable some components for testing and to speed
> up the process. After installing the dependencies when I run cmake I
> am getting following messages. Are these messages okay? Do I have to
> pass any flags to cmake like -march etc or not?
>
> 
> -- Performing Test have_msse2
> -- Performing Test have_msse2 - Failed
> -- Performing Test have_msse3
> -- Performing Test have_msse3 - Failed
> -- Performing Test have_mssse3
> -- Performing Test have_mssse3 - Failed
> -- Performing Test have_msse4a
> -- Performing Test have_msse4a - Failed
> -- Performing Test have_msse4_1
> -- Performing Test have_msse4_1 - Failed
> -- Performing Test have_mavx
> -- Performing Test have_mavx - Failed
> -- Performing Test have_mavx2
> -- Performing Test have_mavx2 - Failed
> -- Architecture is not x86 or x86_64, Overruled arch 3dnow
> -- Architecture is not x86 or x86_64, Overruled arch mmx
> -- Architecture is not x86 or x86_64, Overruled arch sse
> -- Architecture is not x86 or x86_64, Overruled arch sse2
> -- Architecture is not x86 or x86_64, Overruled arch sse3
> -- Architecture is not x86 or x86_64, Overruled arch ssse3
> -- Architecture is not x86 or x86_64, Overruled arch sse4_a
> -- Architecture is not x86 or x86_64, Overruled arch sse4_1
> -- Architecture is not x86 or x86_64, Overruled arch sse4_2
> -- Architecture is not x86 or x86_64, Overruled arch avx
> -- Available architectures: generic;hardfp;neon;orc;norc
> -- Available machines: generic_orc;neon_hardfp_orc
> -- BUILD TYPE = RELEASE
> -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall 
> -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
> -mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
> -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> --  Adding ASM files
> -- -- Detected neon architecture; enabling ASM
> -- Adding source file:
> /home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s
>
> ...
> ...
> Complete output
>
> http://pastebin.com/t3KSu0f5
>
>
> Thanks.
>
> --
> Usman
>
>
>
>
>
> ___
> 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] GNU Radio on Beaglebone black

[Usman Haider]

Hi,

I am currently building GNU Radio 3.7.10.1 on Beaglebone black running
Debian 8.6.  I have disable some components for testing and to speed up the
process. After installing the dependencies when I run cmake I am getting
following messages. Are these messages okay? Do I have to pass any flags to
cmake like -march etc or not?


-- Performing Test have_msse2
-- Performing Test have_msse2 - Failed
-- Performing Test have_msse3
-- Performing Test have_msse3 - Failed
-- Performing Test have_mssse3
-- Performing Test have_mssse3 - Failed
-- Performing Test have_msse4a
-- Performing Test have_msse4a - Failed
-- Performing Test have_msse4_1
-- Performing Test have_msse4_1 - Failed
-- Performing Test have_mavx
-- Performing Test have_mavx - Failed
-- Performing Test have_mavx2
-- Performing Test have_mavx2 - Failed
-- Architecture is not x86 or x86_64, Overruled arch 3dnow
-- Architecture is not x86 or x86_64, Overruled arch mmx
-- Architecture is not x86 or x86_64, Overruled arch sse
-- Architecture is not x86 or x86_64, Overruled arch sse2
-- Architecture is not x86 or x86_64, Overruled arch sse3
-- Architecture is not x86 or x86_64, Overruled arch ssse3
-- Architecture is not x86 or x86_64, Overruled arch sse4_a
-- Architecture is not x86 or x86_64, Overruled arch sse4_1
-- Architecture is not x86 or x86_64, Overruled arch sse4_2
-- Architecture is not x86 or x86_64, Overruled arch avx
-- Available architectures: generic;hardfp;neon;orc;norc
-- Available machines: generic_orc;neon_hardfp_orc
-- BUILD TYPE = RELEASE
-- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -Wall
-- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
-- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
-mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
-- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--  Adding ASM files
-- -- Detected neon architecture; enabling ASM
-- Adding source file:
/home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s

...
...
Complete output

http://pastebin.com/t3KSu0f5


Thanks.

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

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

[Moritz Luca Schmid]

Hi Ben,

thanks a lot for your helpful advice!

Most typos should be fixed by now and I am going to add the paragraph 
breaks.


The chapter "Deliverable Features" - you are right - does not clearly 
separate the deliverables from the existing stuff.


I am going to improve that.


Thanks again! I am really glad to receive so much feedback from the 
community!


Luca



On 21.03.2017 18:30, Ben Hilburn wrote:

Hi Moritz -

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

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


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

Cheers,
Ben

On Mon, Mar 20, 2017 at 1:46 PM, Moritz Luca Schmid 
> 
wrote:


Hi Bastian,

thanks for the tip! The projects of opendigitalradio association
seem really interesting for the DAB project, and welle.io
 in particular for the GUI. Matthias from
opendigitalradio wrote me as well.

I am planning to reuse some code especially for the implementation
of MPEG Audio Layer II and HE-ACC-v2 coding, as I wrote in my
proposal. These projects seem the perfect source for this case.


Thanks and Regards

Luca



On 20.03.2017 18:00, Bastian Bloessl wrote:

Hi Luca,

great proposal.

Apart from gr-dab, there seem to be several other DAB
implementations. Opendigitalradio lists a few:
http://wiki.opendigitalradio.org/DAB_reception


Did you have a look at them? welle.io , in
particular, seems to be interesting in that context.
Maybe you could reuse (some of) their code and mainly
integrate it into GNU Radio.

Best,
Bastian




On 18 Mar 2017, at 15:59, Luca Schmid
> wrote:

Hi everyone,
my name is Moritz Luca Schmid and I am a third-year
student of electrical engineering at KIT. I also work as
an assistant at the Communications Engineering Lab (CEL)
in Karlsruhe.

I am going to propose for the GSoC 17 DAB/DAB+ transceiver
app project. It would be very kind of you to take a look
at my proposal and give me some feedback.
You can find the draft proposal on my GitHub:
https://github.com/MoritzLucaSchmid/GSoC-proposal


Thanks and Regards
Luca



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





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

[Discuss-gnuradio] GNU Radio on Beaglebone black

[Usman Haider]

Hi

I am currently building GNU Radio 3.7.10.0 on Beaglebone black. When I run
cmake I  am getting
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Audio Synchronization

[Benny Alexandar]

Hi Marcus,


Yes, we had long discussions and I had discussion
with Fons separately as well.

I tried to implement his paper
http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf
on an embedded platform to quickly check the behavior as
well, were I can adjust the audio sample rate in hardware.
So, I don't need an adaptive re-sampler.

Because of the limitations in implementing the paper
as such, I had to modify it and Fons stopped supporting me!

Instead of controlling the average  number of samples
control the average time any particular sample
stays in the buffer.Please find the attached
figure modified to control the average time.

In the fig,
'W(k)' and 'R(k)'  are functions  which can take an arbitrary sample
number as their argument and returns the corresponding write and read time.

If a straight line is drawn horizontally the intersection points
corresponds to the Write and Read timings for the same number of samples.

During callback the delay error is calculated as
 err = t_R - t_W + aDec_t - D

 where,
 t_R   = time at read side callback when it finished
 DMAing the k samples.
 t_W   = write time of buffer when it wrote k samples.
 aDec_t  =  average decoding time.
 D   = target delay.

If ‘err’ is positive we need to increase the read sample
rate. If it is negative we need to decrease it.

This approach is a very good optimization in terms of
computation. On the write side I have to apply
the DLL to smooth time and send only the
write timestamp as meta data to callback.
I don't need to compute the sample rate at
 write side and even number of samples written
 also. The interpolation of time at read side
 is just the previous buffer timestamp for the
 same number of samples written and read
assuming the buffering is only two buffers
between write and read.

Unlike other broadcast standards such as DVB-T where
the transmitter sends a reference TimeStamp counter
(CTS,PTS) as a global reference clock information to receiver,
in digital radio standards such as DAB there are
no reference timestamp from transmitter. Only by using
the local clock the receiver estimates a worst case delay.

Please review this proposal, I would like to implement
it for GNU radio as a GSoC project as well.
I'm planning this for broadcast receivers such as
DAB/DAB+ , DRM/DRM+ etc.

 -ben


From: Marcus Müller 
Sent: Monday, March 20, 2017 11:42:50 PM
To: Benny Alexandar; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Synchronization


Hi Ben,


please keep discussions on the list.


I don't fully understand your question. You, Fons and I (as well as others) had 
a very very lengthy discussion on why this is hard and how to do that on the 
mailing list a while back.


Best regards,

Marcus


On 03/19/2017 07:13 AM, Benny Alexandar wrote:

Hi Marcus,


I'm using digital radio (DRM) receiver.


How to synchronize the audio in digital radio reception with transmitter audio 
clock to avoid buffer over flow and under run ?


Audio In-> DRM Tx --->..--->USRP> gr-drm---> Audio out


-ben


From: USRP-users 
 
on behalf of Marcus Müller via USRP-users 

Sent: Sunday, March 19, 2017 12:03:11 AM
To: usrp-us...@lists.ettus.com
Subject: Re: [USRP-users] Audio Synchronization


Hi Benny,


what kind of broadcast are you referring to? AM, FM (which are analog audio, so 
you'd not have any audio clock), DRM, DAB/DAB+?

maybe a really quick block diagram would help me understand the issue at hand.


Best regards,

Marcus

On 18.03.2017 14:03, Benny Alexandar via USRP-users wrote:

Hi,


I'm implementing the broadcast receiver using USRP & GNU Radio. For audio 
synchronization with transmitter clock, should I use the RF local clock base 
band arriving sample time or estimate the audio clock after audio decoding ?


How to do the synchronization with audio transmitter clock ?


-ben



___
USRP-users mailing list
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



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

Re: [Discuss-gnuradio] [USRP-users] B210 - file transmit using ofdm

[Marcus Müller]

Hi Julian,

in the future, please try to keep your questions on the mailing lists,
so that it's not like only one person can contribute experience.

In your case, maybe the discuss-gnuradio mailing list would be
interesting, sign up is under [1]. You'll find an archive there that
also answers your questions.

Now, in the interest of helping you as quickly as possible:

1. No, a USRP can only be owned by a single process, so yes, you'll have
to have it in one flow graph. You might use things like the GNU Radio
zeromq blocks to communicate data between flowgraphs – even running on
different machines!

2. Physics! Just because you don't screw on an antenna doesn't mean you
don't transmit signal out of your SMA connector (just much worse), and
also, there's inevitably a bit crosstalk between TX and RX on the same PCB.

Best regards,

Marcus

[1]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


On 21.03.2017 18:29, Tschuls Lebarski wrote:
> Hi Marcus,
>
> thank's a lot for your help.
>
> 1. Can I round 2 differnent flowgraph? One for receiving the other for
> transmitting? Or do I have to put UHD-Sink and Source together in one
> graph?
>
> 2.I tried playing with this examples and I modified tx_ofdm example to
> transmit a file.
> Instead of Random-Source I implemented File-Source and I added a
> File-Sink at the end of the receiving part.
> I replaced Chanel-Modulation with UHD-Sink and UHD-Source so there is
> no connection in flow graph between
> Transmitter and receiver part.
> The file was transmitted somewhere but I didn't use the antennas.
> How can that be?
>
> Thanks in advance
>


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

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

[Ben Hilburn]

Hi Moritz -

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

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

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

Cheers,
Ben

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

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

Re: [Discuss-gnuradio] Python/SWIG problems

[Daniel P. Martin]

I will volunteer to do that! I've got a deadline this week keeping me 
very busy and then a week on vacation, so it may be two weeks before I 
get to it.


Regards,

Dan


On 3/21/17 12:09 PM, Martin Braun wrote:

Dan,

would you like to add the info the wiki? Maybe onto the FAQ?

-- M

On 03/20/2017 01:46 AM, Daniel P. Martin wrote:

I found the answer to this post in the discuss-gnuradio archive. The
answer was posted by Patrick Sathyanathan:

[Discuss-gnuradio] OOT Module Attribute Error module object has no
attribute 'blockname'


The problem I had was exactly as Patrick describs, as was the solution.

I'd recommend putting this information on the new Wiki!

Dan Martin


On 3/19/17 10:11 PM, Daniel P. Martin wrote:

I periodically run into problems with the Python/SWIG portion of my
out-of-tree module builds. Wrapper modules are built by swig but
appear empty.

I'm running Ubuntu 16.04.

The error I get when I try to run a typical flowgraph that uses my
"abc_module" from GRC is


Using Volk machine: avx2_64_mmx_orc
[...]
AttributeError: 'module' object has no attribute 'periodic_burst_source'
---

SWIG appears to run and generate the wrapper files during the make,
but the wrapper files don't have the interface. I thought I'd fixed
this by reinstalling GNU radio, but now a module that once built
properly is failing as above. I can run python and "import abc_module"
but "Dir(abc_module)" shows it to be empty.

There are multiple SWIG distribution/versions available. At one point
I thought switching to SWIG 3.0 fixed this issue but the last time it
cropped up switching to 3.0 had no effect.

Also, the "make install" installing wrappers in
/usr/local/lib/python2.7/dist-packages, though on another machine I
have it has installed wrappers in /usr/lib/python2.7/dist-packages.

Does anyone have tips or advice on debugging these issues?

Thanks,
Dan

--
Dr. Daniel Martin
Acadia Controls, LLC
110 Gateway Commons Dr
Gorham, ME
207 838-6465 mobile
207 839-6303 fax, office
www.acadiacontrols.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



--
Dr. Daniel Martin
Acadia Controls, LLC
110 Gateway Commons Dr
Gorham, ME
207 838-6465 mobile
207 839-6303 fax, office
www.acadiacontrols.com

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

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

[Ben Hilburn]

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

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

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

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

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

[Discuss-gnuradio] Want to hire someone to build BPSK/QPSK receiver

[Chris Cook]

I posted this last year, but didn’t really have any takers, so I thought
I’d try again and increase the pay.

I have a project that requires a gnu radio receiver that can receive,
demodulate, and decode BPSK and QPSK data coming from a satellite modem.
The modem also has FEC that will need to be handled.

I can provide remote access to our lab machine that has a USRP connected to
our modem for testing.

I am willing to pay $1500 USD for a solution.

Please let me know if you’re interested and we can move the conversation
offline.

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

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

[Koslowski, Sebastian (CEL)]

Hello,

good to see so much feedback to this proposal. This feature is clearly
something that we all want to see become reality!
I have discussed this idea with Kartik beforehand offline and I am glad
to see all of you have the same issues/objections.

While bokeh (and plotly) were mentioned in the proposal only because the
idea was inspired from these libraries, they maybe not the be a natural
fit for us after all - at least on the server side. Maybe, at this
point, it would be useful to specify what we actually want out this and
then look at what Bokeh and others provide us to get there. Even if that
means, that this module will not have all features after 3 months of
coding that we want long term.

My rough idea of this is
- a server that runs an event-loop to push push data to clients and
receives/handles events from them
- a single websocket connection per client which the data (for all
plots) is multiplexed using messages
- each sink block holds a number plot data buffers ("O"s may happen)
that the event loop async pulls from and sends to clients
- metadata is a separate message?

As far as I can tell this is pretty much what Bokeh does, except that we
want a more direct path from our blocks to the websocket stream.  I'm
not sure if the Bokeh server has an lower-level API that we could we.
The other thing I am unsure about is the flow of data, that Marcus
mentioned. Ideally we could have something with the event loop in Python
that allowed us to stream data stored in buffer object (build in at the
C level).

Kartik, I think you should include a more detailed description on how
you plan to control the data flow and maybe, expand on the planned
options of the placement of widgets.

Sebastian

On 03/21/2017 02:09 PM, Marcus Müller wrote:
>
> Hi Kartik,
>
> thanks for the feedback!
>
> so, I took the time and tried to read up a bit on what Bokeh does, how
> it's partitioned. I'd like to describe this here as shortly as
> possible, mostly for my own understanding and to foster more
> discussion with others that can't find the time, and would kindly ask
> you to confirm this is your understanding, too:
>
>   * Bokeh is Python library that produces plots
>   * It's plotting frontend is HTML & Javascript
>   * This enables interactive plotting (ie. you can zoom in, pan etc
> without updating the dataset visualized)
>   * The frontend Javascript is a library (BokehJS) used in a
> "standard" piece of code that you feed two things:
>   o The ID of the HTML  tag to be filled with the graph
>   o The data and plot settings to be visualized as JSON
>   * Bokeh (the python library) comes with a Python-implemented server
> that you're planning to use
>
> Now the things I'm not sure about:
>
>   * said server has a REST API, i.e. is /polled/ from the client only?
> Or can there be pushing data from server -> client? What is the
> model you'd prefer? Your proposal says "stream to the clients",
> but I can't find that in Bokeh (but then again: no experience on
> interactive Web dev on my side at all, so this might be really
> easy for you, if possible).
>   * I've no idea how to talk GR data -> bokeh-server. Maybe you could
> elaborate on how you do that?
>   * the JSON is relatively verbose, and contains basically all
> imaginable settings for a plot. However, I presume a data update
> from the bokeh-server would only consist of the model data, which,
> for a 5-point line graph would consist of (this is pretty-printed,
> Bokeh omits all the whitespace/line breaks):
> {
>"type" : "ColumnDataSource",
>"id" : "ce58de4d-0ef2-43cf-b15a-23d431781c1a",
>"attributes" : {
>   "callback" : null,
>   "column_names" : [
>  "y",
>  "x"
>   ],
>   "data" : {
>  "x" : [
> 1,
> 2,
> 3,
> 4,
> 5
>  ],
>  "y" : [
> 6,
> 7,
> 2,
> 4,
> 5
>  ]
>   }
>}
> },
>   * Hence, if performance of the python server is doubted, or
> integration into GR is complicated, you could also just write a
> C++ block that takes numerical values from GNU Radio and serves
> them via Websocket (how does one do that?), and point BokehJS at
> that instead? (example from [0], found the embed_items declaration
> in [1])
>   * However, when running [2] and changing the data source, I see all
> the plot JSON being transferred, the ColumnDataSource object just

Re: [Discuss-gnuradio] Python/SWIG problems

[Martin Braun]

Dan,

would you like to add the info the wiki? Maybe onto the FAQ?

-- M

On 03/20/2017 01:46 AM, Daniel P. Martin wrote:
> I found the answer to this post in the discuss-gnuradio archive. The
> answer was posted by Patrick Sathyanathan:
> 
> [Discuss-gnuradio] OOT Module Attribute Error module object has no
> attribute 'blockname'
> 
> 
> The problem I had was exactly as Patrick describs, as was the solution.
> 
> I'd recommend putting this information on the new Wiki!
> 
> Dan Martin
> 
> 
> On 3/19/17 10:11 PM, Daniel P. Martin wrote:
>>
>> I periodically run into problems with the Python/SWIG portion of my
>> out-of-tree module builds. Wrapper modules are built by swig but
>> appear empty.
>>
>> I'm running Ubuntu 16.04.
>>
>> The error I get when I try to run a typical flowgraph that uses my
>> "abc_module" from GRC is
>>
>> 
>> Using Volk machine: avx2_64_mmx_orc
>> [...]
>> AttributeError: 'module' object has no attribute 'periodic_burst_source'
>> ---
>>
>> SWIG appears to run and generate the wrapper files during the make,
>> but the wrapper files don't have the interface. I thought I'd fixed
>> this by reinstalling GNU radio, but now a module that once built
>> properly is failing as above. I can run python and "import abc_module"
>> but "Dir(abc_module)" shows it to be empty.
>>
>> There are multiple SWIG distribution/versions available. At one point
>> I thought switching to SWIG 3.0 fixed this issue but the last time it
>> cropped up switching to 3.0 had no effect.
>>
>> Also, the "make install" installing wrappers in
>> /usr/local/lib/python2.7/dist-packages, though on another machine I
>> have it has installed wrappers in /usr/lib/python2.7/dist-packages.
>>
>> Does anyone have tips or advice on debugging these issues?
>>
>> Thanks,
>> Dan
> 
> -- 
> Dr. Daniel Martin
> Acadia Controls, LLC
> 110 Gateway Commons Dr
> Gorham, ME
> 207 838-6465 mobile
> 207 839-6303 fax, office
> www.acadiacontrols.com
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] installing a python package without elevated privileges

[Martin Braun]

The answer would be virtualenvs, but virtualenvs are not fully supported
in PyBOMBS. You might be able to to this by hand, but I've never tried it:

- Create a prefix using the --virtualenv switch
- Manually pip install the package into the virtualenv
- Maybe you need to manually set the package as installed

When the prefix is enabled, so is the virtualenv, so the package should
get picked up.

-- M

On 03/20/2017 09:02 AM, Naceur wrote:
> Hello GR,
> 
> I am creating a recipe for pytun as a dependency for an OOT module.
> Is there a way I can tell pybombs to install that while passing --user to
> pip because testing the install tells: pip is using elevated privileges 
> .
> .
> .
> PyBOMBS.PackageManager - DEBUG - Checking if package pytun is installed.
> PyBOMBS.install_manager - INFO - Installing package: pytun
> PyBOMBS.PackageManager - DEBUG - install(pytun, static=False)
> PyBOMBS.PackageManager - DEBUG - Using packager pip
> PyBOMBS.Packager.pip - DEBUG - Calling `/home/nae/.local/bin/pip install
> pytun'
> PyBOMBS.monitor_process() - DEBUG - Running with elevated privileges.
> PyBOMBS._process_thread() - DEBUG - Executing command `['sudo', '-H',
> '/home/nae/.local/bin/pip', 'install', 'pytun']'
> sudo: unable to execute /home/nae/.local/bin/pip: Permission denied
> PyBOMBS.monitor_process() - DEBUG - Thread signaled termination or returned
> PyBOMBS.monitor_process() - DEBUG - Return value: 1
> .
> .
> .
> 
> Thanks,
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/installing-a-python-package-without-elevated-privileges-tp63183.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

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

[Marcus Müller]

Hi Kartik,

thanks for the feedback!

so, I took the time and tried to read up a bit on what Bokeh does, how
it's partitioned. I'd like to describe this here as shortly as possible,
mostly for my own understanding and to foster more discussion with
others that can't find the time, and would kindly ask you to confirm
this is your understanding, too:

  * Bokeh is Python library that produces plots
  * It's plotting frontend is HTML & Javascript
  * This enables interactive plotting (ie. you can zoom in, pan etc
without updating the dataset visualized)
  * The frontend Javascript is a library (BokehJS) used in a "standard"
piece of code that you feed two things:
  o The ID of the HTML  tag to be filled with the graph
  o The data and plot settings to be visualized as JSON
  * Bokeh (the python library) comes with a Python-implemented server
that you're planning to use

Now the things I'm not sure about:

  * said server has a REST API, i.e. is /polled/ from the client only?
Or can there be pushing data from server -> client? What is the
model you'd prefer? Your proposal says "stream to the clients", but
I can't find that in Bokeh (but then again: no experience on
interactive Web dev on my side at all, so this might be really easy
for you, if possible).
  * I've no idea how to talk GR data -> bokeh-server. Maybe you could
elaborate on how you do that?
  * the JSON is relatively verbose, and contains basically all
imaginable settings for a plot. However, I presume a data update
from the bokeh-server would only consist of the model data, which,
for a 5-point line graph would consist of (this is pretty-printed,
Bokeh omits all the whitespace/line breaks):

{
   "type" : "ColumnDataSource",
   "id" : "ce58de4d-0ef2-43cf-b15a-23d431781c1a",
   "attributes" : {
  "callback" : null,
  "column_names" : [
 "y",
 "x"
  ],
  "data" : {
 "x" : [
1,
2,
3,
4,
5
 ],
 "y" : [
6,
7,
2,
4,
5
 ]
  }
   }
},

  * Hence, if performance of the python server is doubted, or
integration into GR is complicated, you could also just write a C++
block that takes numerical values from GNU Radio and serves them via
Websocket (how does one do that?), and point BokehJS at that
instead? (example from [0], found the embed_items declaration in [1])
  * However, when running [2] and changing the data source, I see all
the plot JSON being transferred, the ColumnDataSource object just
being about half of the 12 kB response object (amongst dozens of
requests made to react to this change of model, but that might be an
effect of this being a feature-rich plot).
  * Can you please explain the user work flow? I would have imagined
that the users design their "plot layout" either
  o implicitly (by just using your sinks in their flow graph), so
that gr-bokehgui builds a HTML page containing the plots they
want on its own, or
  o explicitly by designing an HTML page with  placeholders on
their own and tell gr-bokehgui "hey, use that; the plot 
IDs are [list of IDs]",
  * but I'm not sure you'd support the second method, since you mention
the ability to add labels and such, which would be relatively
redundant with that.

Best regards,

Marcus

[0] https://demo.bokehplots.com/apps/movies
[1]
https://github.com/bokeh/bokeh/blob/0.12.4/bokehjs/src/coffee/embed.coffee#L161
[2] https://demo.bokehplots.com/apps/crossfilter



On 21.03.2017 12:07, Kartik Patel wrote:
> Dear Ben and Bastian,
>
> Thank you very much for the feedback.
>
> @Ben: Thank you for this error. I have not tried to dig deep in this
> error because it was just a prototype.
>
> @Bastian: You got the server architecture correct. I am planning to do
> exactly same.
>
> _Coming to queries about using Bokeh:_
> I agree that we are all-in to Bokeh. I also agree that it is good to
> have different modules for frontend and backend. But in that case we
> will be simply replicating Bokeh's backend (with much less features)
> and Bokeh's frontend (independently this time). I believe it will be
> like re-inventing the wheel. 
>
> Also, the features like simultaneous change in parameters in all
> connected documents are necessary when working with the hardware or
> even during simulation. Implementing this feature and some more like
> these will not be 

Re: [Discuss-gnuradio] GPU accelerated Viterbi decoder?

[Marcus Müller]

Hi Mehmeto,

On 21.03.2017 10:24, Mehmeto wrote:
> Dera All,
>  In almost all cases the Viterbi decoder block eats a lot of CPU time. 
True, but only for higher rates. But yeah, channel coding is a major CPU
load, always.
> The
> best alternative is a GPU solution. 
That *is* a bold claim. Note that doing things on a GPU not only incurs
quite some overhead due to copying data in and out of GPU memory, but
also, Viterbi decoders are algorithms that typically need to find the
maximum across a lot of different branches of computation – maximum
finding is usually something that can only be partly implemented in
parallel; however, the fact that you can compute a lot of probabilities
in parallel is very sexy, indeed.

> I have searched for an open source GPU implementation but could not find one.
>  There is a MATLAB implementation but
> that one is far from open source.
> Any Ideas? Is it easy to port gr-fec to a CUDA/ openCL based platform?
I don't know whether porting makes much sense – the things would be
implemented specifically different on a GPU, so you'd more likely to
write it from ground up, and use gr-fec to check it.

Best regards,
Marcus

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

Re: [Discuss-gnuradio] GPU accelerated Viterbi decoder?

[Dan CaJacob]

What data rates are you working at?  I haven't had so much trouble with
Viterbi being a limiting factor up to about 1 Mbps QPSK with concatenated
coding.

Sadly, I have no experience moving this to GPU.

On Tue, Mar 21, 2017 at 5:25 AM Mehmeto  wrote:

> Dera All,
>  In almost all cases the Viterbi decoder block eats a lot of CPU time. The
> best alternative is a GPU solution. I have searched for an open source GPU
> implementation but could not find one. There is a MATLAB implementation but
> that one is far from open source.
> Any Ideas? Is it easy to port gr-fec to a CUDA/ openCL based platform?
> Thanks
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/GPU-accelerated-Viterbi-decoder-tp63205.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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

Bah, I messed up my filter designs in that last flowgraph.
(Transition BW != Stopband Freq).
Never drink beer while designing filters. :)

See the attached, fixed flowgraph (v4).

-Andy

On Mon, Mar 20, 2017 at 9:30 PM, Andy Walls  wrote:
> Hi Dirk:
>
> On Mon, Mar 20, 2017 at 1:04 PM, Dirk Gorissen  wrote:
>> Hi Andy,
>>
>> I have been experimenting with the flowgraphs, tried with some live
>> data and it all works as expected. Just had to switch the threshold to
>> 2 orders of magnitude smaller when using an airspy.
>
> Yeah, that's expected really.
> You might want to write a block that implements a (F)CME algorithm in the
> time domain, to periodically determine an adapted threshold between correlator
> noise output vs correlator signal output.  I mention FMCE and CME because
> it has a well defined Pfa input parameter.
>
> Or you you could just grab 3 seconds of
> correlator output every 1.5 seconds and use CME, or your favorite statistical
> measure or distance metric for outlier detection, to find correlator
> output signal
> peaks.
>
>> So thank you again for your time on this, I will ensure to give credit
>> when the final thing is tested & operational :)
>
> Thank you.
>
>> Some comments/questions inline below:
>>
>>>To get faster lock in, you may want your frequency range of interest to
>>>be somewhere in between Fs/4 and Fs/2; and not near DC.
>>
>> Actually my channel is 2khz wide, not 10khz so that does make life a
>> bit easier. So in this case I should be decimating Fs down to
>> something like 4k say. Correct?
>
> Yes.  See the attached flowgraph, version 3, where I knock it down to
> 4ksps and have the filter starting to roll off at +/- 1kHz
>
>
>> As you say this should also let me lower the pll bandwidth. Though I
>> haven't quite grasped the intuition behind this. Experimenting a bit
>> it seems a bit smaller than you set is better, definitely not larger.
>
> Well yes, but too small is bad as well.
>
>
>> How did you pick your ranges, they dont align with what the docs are
>> saying ( around pi/200 - 2pi/100).
>
> Empirically.  :)  Mostly...
>
> So the theory behind what the parameters mean is a lecture on second order
> control systems, which I will spare you.  (Also GNRadio is funny in that
> the user specifies 2nd order *analog* control system parameters for
> poles in the complex s-plane [Laplace transform plane] and then
> approximately warps them over to the z-plane [Z transform plane]
> into poles for a discrete 2nd order control system - it's kind of silly 
> really.)
>
> The short story is GNURadio picks the damping factor of 1.0/sqrt(2.0)
> for a maximally flat second order PLL filter response, and then the user
> sets loop_bw (aka. omega_n_T) to set how wide the PLL loop filter response
> is.
>
> The maximum loop_bw could really be is pi/(1.0/sqrt(2)), and that would be
> a wide filter going from +/- the Nyquist rate of the phase detector
> error signal;
> which is useless.  So you need a smaller number.
>
> Smaller loop_bw values result in a more sluggish PLL.
> Larger loop_bw values result in a more reactive PLL.
>
> For rapid locking on to an intermittent pulse that pops up with random
> initial phase (compared to the PLL's currently unlocked wandering phase),
> we want a more reactive PLL so a larger loop bandwidth.
>
> If the PLL is too reactive it wont lock.
> If the PLL is too slow, the pulse will be gone before it gets into lock.
>
>
>>
>>>b. Once you find some pulses, extract what frequency they were at from
>>>the PLL's loop filter state at the time it was locked on the pulse.  You
>>>can then use this exact frequency information for a dedicated
>>>correlation filter to pull even weaker pulses out of the noise, and
>>>maintain track.
>>
>> Yes this is what I had in mind as well. I looked around the carrier
>> block docs, source code, and wider gr wiki but couldn't find how I can
>> get my hands on that internal state?
>
> It's not easy.  From python, you can call the get_frequency() method of
> the block and get it asynchronously, but the units are funny (and it might
> even be the period vs the frequency, I have to take a harder look).
>
> An easier thing to do is to take the properly scaled d(phi)/dt of the
> PLL's locked output and use that as an instantaneous frequency
> value that is sample synchronous with the main sample stream.
> That number is clean for strong pulses, and a meandering mess for
> weak pulses.
>
> See the lowest, disabled branch of the attached flowgraph.
> I converted the Carrier Tracking PLL to a Reference Out PLL
> block followed by a Multiply Conjugate.  It is functionally
> identical, but now we have the PLL's locked
> output available.
>
>>>I wasn't intending to tweak the flowgraph, but today I decided to try
>>>with a correlation filter with -5 kHz to +5 kHz chirp taps.  That
>>>method turned out to be inferior to the PLL, so I didn't leave it in
>>>the flowgraph.
>>
>> Thats good to 

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

[Kartik Patel]

Dear Ben and Bastian,
Thank you very much for the feedback.
@Ben: Thank you for this error. I have not tried to dig deep in this error
because it was just a prototype.
@Bastian: You got the server architecture correct. I am planning to do exactly
same.
Coming to queries about using Bokeh:I agree that we are all-in to Bokeh. I also
agree that it is good to have different modules for frontend and backend. But in
that case we will be simply replicating Bokeh's backend (with much less
features) and Bokeh's frontend (independently this time). I believe it will be
like re-inventing the wheel.
Also, the features like simultaneous change in parameters in all connected
documents are necessary when working with the hardware or even during
simulation. Implementing this feature and some more like these will not be easy.
Also, considering that Bokeh library includes all these in itself, I think it's
implementation will be more efficient than what I will make. (This last
statement is an assumption. Not sure how valid.)
So, I think now only issue is unreliability of the library. In other terms, if
somehow in future Bokeh become obsolete, then this entire module will die. In
order to become less dependent on this, we have to make a independent manual
python based server and Plotly based frontend as suggested.
It means we have a trade-off between the scope of the project and reliability of
Bokeh. I am not sure how good it is to develop something which already exists
because of the possibility that the library will be obsolete one day. We can
discuss on this.
Only reason, I am resistant to the idea of not using the Bokeh server is that
the existing features and scope of the project will be reduced. Since, all the
plots and widgets are necessary in order to make the module usable, limiting the
plots will not be good enough. Although I am open to contributions on this
module even after GSoC, this is not valid statement for the proposal in GSoC.
I am fully aware with the probable issues of having the external library as core
dependency. I can also imagine the module having independent frontend and
backend. But is it worth rewriting the code that exist in Bokeh?
If we still decide to go for independent backend and frontend, I will need one
weekend to write full proposal for that. So, it would be good if we can conclude
the discussion before this Friday.
Thank you very much for the suggestions.
Regards,Kartik Patel  





On Tue, Mar 21, 2017 5:18 AM, Ben Hilburn bhilb...@gnuradio.org  wrote:
Hi Kartik -
I apologize for the delayed response! Nice work getting this out last week, and
great proposal. I gave your prototype a whirl - it generated some output (see
attached screenshot), but then died with this error (I'm not worried about the
error, just giving you a heads-up):
Created new window in existing browser session.handler caught exception: Set
changed size during iterationTraceback (most recent call last):  File
"/home/bhilburn/usr/lib64/python2.7/site-packages/gnuradio/gr/gateway.py", line
55, in eval    try: self._callback()  File "/home/bhilburn/usr/lib64/pyth
on2.7/site-packages/gnuradio/gr/gateway.py", line 160, in __gr_block_handle    )
for i in self.__out_indexes],  File "/home/bhilburn/usr/lib64/pyth
on2.7/site-packages/htmlgui/time_sink_f.py", line 62, in work   
self.ds.stream(new_data, rollover = 1000)  File "/usr/lib/python2.7/site-packa
ges/bokeh/models/sources.py", line 287, in stream   
self.data._stream(self.document, self, new_data, rollover, setter)  File
"/usr/lib/python2.7/site-packages/bokeh/core/property/containers.py", line 345,
in _stream    hint=ColumnsStreamedEvent(doc, source, new_data, rollover,
setter))  File "/usr/lib/python2.7/site-packages/bokeh/core/property/contai
ners.py", line 106, in _notify_owners    for (owner, prop) in self._owners:
RuntimeError: Set changed size during iterationthread[thread-per-block[2]:
]: SWIG director method error. Error detected when
calling 'feval_ll.eval'
Regarding the proposal, as Martin and Bastian said, this is looking really good.
Expanding a bit on the point about being "all-in" on Bokeh, that's not
necessarily a bad thing, but it would be good to understand exactly where the
line is between Bokeh and GNU Radio. If someone came along after you to
implement something in a different web framework, would they start in the same
place as you are starting, now, or would they build on something you are
creating? If there is a way to architect this such that can be built on with
non-bokeh frameworks later, that would be preferable to locking everything down.
I also am a fan of the `gr-bokehgui` suggestion that Martin gave.
Another benefit of a web-based front-end is the ability to visualize data while
remote from whatever computer actually has the hardware connected to it and
interact with the flowgraph. It would be good to call this out in your
"Features" list and add detail regarding this where appropriate.
Cheers,Ben
On Mon, Mar 20, 2017 at 12:02 PM, Bastian 

[Discuss-gnuradio] GPU accelerated Viterbi decoder?

[Mehmeto]

Dera All,
 In almost all cases the Viterbi decoder block eats a lot of CPU time. The
best alternative is a GPU solution. I have searched for an open source GPU
implementation but could not find one. There is a MATLAB implementation but
that one is far from open source.
Any Ideas? Is it easy to port gr-fec to a CUDA/ openCL based platform?
Thanks



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GPU-accelerated-Viterbi-decoder-tp63205.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