Re: [Discuss-gnuradio] ModuleNotFoundError

[Ron Economos]

The PYTHONPATH should be:

/usr/local/lib/python3.7/dist-packages

The LD_LIBRARY_PATH should be:

/usr/local/lib

A couple more notes. Make sure you do a sudo ldconfig after the build. 
Also, there was a bug in the 3.8.0.0-rc1 tag. Make sure you build the 
latest 3.8.0.0-rc2 tag (or anything after commit 0ab6a74).


Ron

On 7/22/19 18:47, Barry Duggan wrote:
Now that I have built and installed gnuradio on a Raspberry Pi, I am 
getting the following screen when I try to start gnuradio-companion:


"""
ModuleNotFoundError

Cannot import gnuradio.

Is the model path environment variable set correctly?

Is the library path environment variable set correctly?

(No module named '_runtime_swig')
"""

I added the following lines to ~/.bashrc
# for gnuradio
PYTHONPATH="/usr/bin/python3.7"; export PYTHONPATH
LD_LIBRARY_PATH="/usr/local/include/gnuradio"; export LD_LIBRARY_PATH

Does it matter in what folder I start gnuradio?
What else do I need to do?

Thank you for all of your continued support with my questions!


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

[Discuss-gnuradio] ModuleNotFoundError

[Barry Duggan]

Now that I have built and installed gnuradio on a Raspberry Pi, I am 
getting the following screen when I try to start gnuradio-companion:


"""
ModuleNotFoundError

Cannot import gnuradio.

Is the model path environment variable set correctly?

Is the library path environment variable set correctly?

(No module named '_runtime_swig')
"""

I added the following lines to ~/.bashrc
# for gnuradio
PYTHONPATH="/usr/bin/python3.7"; export PYTHONPATH
LD_LIBRARY_PATH="/usr/local/include/gnuradio"; export LD_LIBRARY_PATH

Does it matter in what folder I start gnuradio?
What else do I need to do?

Thank you for all of your continued support with my questions!
--
Barry Duggan

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

Re: [Discuss-gnuradio] Build GR 3.8 from source

[Ron Economos]

You need scipy for the polar code tests. Not sure about the qa_pmt failure.

sudo apt-get install python3-scipy

Ron

On 7/22/19 13:51, Barry Duggan wrote:

Hi Michael,

Success! Based on Ron's suggestion, I was able to finish the last half 
of the make in 3 hours.


Then I did a 'make test' and got the following failures:

"""
98% tests passed, 6 tests failed out of 362

Total Test time (real) = 1465.99 sec

The following tests FAILED:
150 - qa_pmt (Failed)
243 - qa_polar_decoder_sc (Failed)
244 - qa_polar_decoder_sc_list (Failed)
245 - qa_polar_decoder_sc_systematic (Failed)
246 - qa_polar_encoder (Failed)
247 - qa_polar_encoder_systematic (Failed)
Errors while running CTest
make: *** [Makefile:86: test] Error 8
"""

I don't think it will impact what I need, but thought you might want 
to know.


I really appreciate all the help you have provided.

Best regards,
---
Barry Duggan


On 2019-07-22 09:02, Michael Dickens wrote:

Good morning, Barry! Progress ... keep it coming!

Reviewing your cmake log: My guess is that you just need to give it
longer. A -lot- longer. The point of delay is when C++ is compiling
the SWIG-generated Python interface for gr::filter. SWIG C++ code is
horrendous to read through, and takes a log time to compile when it of
any reasonable amount of complexity. If your RPi can't handle the
compilation, it'll crash -- not just hang, but totally crash. Way back
with the RPi 1, we did get GR to compile on it ... but it took like 2
days! Patience sometimes works here!

All of that said: Did you look at Ron's recommendation? The RPi is
notoriously difficult to compile GR directly on; sometimes you need to
tweak file / memory settings to get "reasonable" compiles.

Also: You could try using OpenEmbedded to build GR on your host
computer, cross-compiled for your RPi. That would take some work, but
might be worth the effort as once it works it would be easily
repeatable!

Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 7:30 AM, Barry Duggan wrote:

Good Morning!

Well, good news and bad news. The good news is that it got past the 13%
mark with no problems. The bad news is that it got stuck again in an
even tighter loop at 53%. I couldn't even move the cursor or interrupt
it with a control-C. The activity light was on solid.

I started at 17:05 and at 20:35 it was at 53%, so I projected it should
finish around midnight. I left it running overnight, but it was 
still at

53%. The output didn't capture the last of what was on the screen.

Let me know what to try next. Thank you for your help.

Best regards,
---
Barry Duggan


On 2019-07-21 13:41, Michael Dickens wrote:
> Hi Barry - OK; good progress! Can you do the following, from the
> top-level "build" directory (looks like "/home/pi/gnuradio/build"):
> {{{
> make clean
> make VERBOSE=ON 2>&1 | tee make_out.txt
> }}}
> and then walk away & let it go until it's done. You'll be able to see
> the build going along via the 'tee' command. Please be patient! It
> might work; it might not! Either way on an RPi it'll take some 
time to

> build whatever it can! - MLD
>



Attachments:
* make_out.txt


___
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] Build GR 3.8 from source

[Ron Economos]

Looks like dphys-swapfile is an alternative way to configure a swap 
file. I'll guess my "classic" way will still work though. You can test 
things with the following commands:


swapon -s

or

free

I would reboot and see if dphys-swapfile (or any swap space) is active 
with swapon -s or free. I'll guess it isn't, so try editing /etc/fstab 
as instructed and make sure that works on the next reboot.


Ron

On 7/22/19 13:37, Barry Duggan wrote:

Hi Ron,

Thank you for your excellent suggestion! I was able finish the last 
half of the make in 3 hours with no problems :)


In looking at your suggestion to make it permanent, I am concerned 
about the comments in fstab:


"""
proc    /proc   proc    defaults  0 0
PARTUUID=e625713b-01  /boot   vfat    defaults 0   2
PARTUUID=e625713b-02  /   ext4    defaults,noatime 0   1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
"""

Do I need to do something else?

Thanks again.

Barry KV4FV

On Sun, 21 Jul 2019 12:53:24 -0700, Ron Economos wrote:

When building GNU Radio on small systems, it's very easy to run out of 
memory (especially when building swig files). The remedy is to create 
a swap file.


sudo fallocate -l 2G /swapfile

sudo chmod 600 /swapfile

sudo mkswap /swapfile

sudo swapon /swapfile

To make is permanent, add this line to /etc/fstab

/swapfile  none  swap  sw  0  0

Ron



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

Re: [Discuss-gnuradio] Build GR 3.8 from source

[Michael Dickens]

Hi Barry - That's great! You're very welcome! Good luck with your GR work! - MLD

On Mon, Jul 22, 2019, at 4:51 PM, Barry Duggan wrote:
> Hi Michael,
> 
> Success! Based on Ron's suggestion, I was able to finish the last half 
> of the make in 3 hours.
> 
> Then I did a 'make test' and got the following failures:
> 
> """
> 98% tests passed, 6 tests failed out of 362
> 
> Total Test time (real) = 1465.99 sec
> 
> The following tests FAILED:
>   150 - qa_pmt (Failed)
>   243 - qa_polar_decoder_sc (Failed)
>   244 - qa_polar_decoder_sc_list (Failed)
>   245 - qa_polar_decoder_sc_systematic (Failed)
>   246 - qa_polar_encoder (Failed)
>   247 - qa_polar_encoder_systematic (Failed)
> Errors while running CTest
> make: *** [Makefile:86: test] Error 8
> """
> 
> I don't think it will impact what I need, but thought you might want to 
> know.
> 
> I really appreciate all the help you have provided.
> 
> Best regards,
> ---
> Barry Duggan
> 
> 
> On 2019-07-22 09:02, Michael Dickens wrote:
> > Good morning, Barry! Progress ... keep it coming!
> > 
> > Reviewing your cmake log: My guess is that you just need to give it
> > longer. A -lot- longer. The point of delay is when C++ is compiling
> > the SWIG-generated Python interface for gr::filter. SWIG C++ code is
> > horrendous to read through, and takes a log time to compile when it of
> > any reasonable amount of complexity. If your RPi can't handle the
> > compilation, it'll crash -- not just hang, but totally crash. Way back
> > with the RPi 1, we did get GR to compile on it ... but it took like 2
> > days! Patience sometimes works here!
> > 
> > All of that said: Did you look at Ron's recommendation? The RPi is
> > notoriously difficult to compile GR directly on; sometimes you need to
> > tweak file / memory settings to get "reasonable" compiles.
> > 
> > Also: You could try using OpenEmbedded to build GR on your host
> > computer, cross-compiled for your RPi. That would take some work, but
> > might be worth the effort as once it works it would be easily
> > repeatable!
> > 
> > Hope this is useful! - MLD
> > 
> > On Mon, Jul 22, 2019, at 7:30 AM, Barry Duggan wrote:
> >> Good Morning!
> >> 
> >> Well, good news and bad news. The good news is that it got past the 
> >> 13%
> >> mark with no problems. The bad news is that it got stuck again in an
> >> even tighter loop at 53%. I couldn't even move the cursor or interrupt
> >> it with a control-C. The activity light was on solid.
> >> 
> >> I started at 17:05 and at 20:35 it was at 53%, so I projected it 
> >> should
> >> finish around midnight. I left it running overnight, but it was still 
> >> at
> >> 53%. The output didn't capture the last of what was on the screen.
> >> 
> >> Let me know what to try next. Thank you for your help.
> >> 
> >> Best regards,
> >> ---
> >> Barry Duggan
> >> 
> >> 
> >> On 2019-07-21 13:41, Michael Dickens wrote:
> >> > Hi Barry - OK; good progress! Can you do the following, from the
> >> > top-level "build" directory (looks like "/home/pi/gnuradio/build"):
> >> > {{{
> >> > make clean
> >> > make VERBOSE=ON 2>&1 | tee make_out.txt
> >> > }}}
> >> > and then walk away & let it go until it's done. You'll be able to see
> >> > the build going along via the 'tee' command. Please be patient! It
> >> > might work; it might not! Either way on an RPi it'll take some time to
> >> > build whatever it can! - MLD
> >> >
> >> 
> >> 
> >> 
> >> Attachments:
> >> * make_out.txt
>

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

Re: [Discuss-gnuradio] Build GR 3.8 from source

[Barry Duggan]

Hi Michael,

Success! Based on Ron's suggestion, I was able to finish the last half 
of the make in 3 hours.


Then I did a 'make test' and got the following failures:

"""
98% tests passed, 6 tests failed out of 362

Total Test time (real) = 1465.99 sec

The following tests FAILED:
150 - qa_pmt (Failed)
243 - qa_polar_decoder_sc (Failed)
244 - qa_polar_decoder_sc_list (Failed)
245 - qa_polar_decoder_sc_systematic (Failed)
246 - qa_polar_encoder (Failed)
247 - qa_polar_encoder_systematic (Failed)
Errors while running CTest
make: *** [Makefile:86: test] Error 8
"""

I don't think it will impact what I need, but thought you might want to 
know.


I really appreciate all the help you have provided.

Best regards,
---
Barry Duggan


On 2019-07-22 09:02, Michael Dickens wrote:

Good morning, Barry! Progress ... keep it coming!

Reviewing your cmake log: My guess is that you just need to give it
longer. A -lot- longer. The point of delay is when C++ is compiling
the SWIG-generated Python interface for gr::filter. SWIG C++ code is
horrendous to read through, and takes a log time to compile when it of
any reasonable amount of complexity. If your RPi can't handle the
compilation, it'll crash -- not just hang, but totally crash. Way back
with the RPi 1, we did get GR to compile on it ... but it took like 2
days! Patience sometimes works here!

All of that said: Did you look at Ron's recommendation? The RPi is
notoriously difficult to compile GR directly on; sometimes you need to
tweak file / memory settings to get "reasonable" compiles.

Also: You could try using OpenEmbedded to build GR on your host
computer, cross-compiled for your RPi. That would take some work, but
might be worth the effort as once it works it would be easily
repeatable!

Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 7:30 AM, Barry Duggan wrote:

Good Morning!

Well, good news and bad news. The good news is that it got past the 
13%

mark with no problems. The bad news is that it got stuck again in an
even tighter loop at 53%. I couldn't even move the cursor or interrupt
it with a control-C. The activity light was on solid.

I started at 17:05 and at 20:35 it was at 53%, so I projected it 
should
finish around midnight. I left it running overnight, but it was still 
at

53%. The output didn't capture the last of what was on the screen.

Let me know what to try next. Thank you for your help.

Best regards,
---
Barry Duggan


On 2019-07-21 13:41, Michael Dickens wrote:
> Hi Barry - OK; good progress! Can you do the following, from the
> top-level "build" directory (looks like "/home/pi/gnuradio/build"):
> {{{
> make clean
> make VERBOSE=ON 2>&1 | tee make_out.txt
> }}}
> and then walk away & let it go until it's done. You'll be able to see
> the build going along via the 'tee' command. Please be patient! It
> might work; it might not! Either way on an RPi it'll take some time to
> build whatever it can! - MLD
>



Attachments:
* make_out.txt


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

Re: [Discuss-gnuradio] Build GR 3.8 from source

[Barry Duggan]

Hi Ron,

Thank you for your excellent suggestion! I was able finish the last half 
of the make in 3 hours with no problems :)


In looking at your suggestion to make it permanent, I am concerned about 
the comments in fstab:


"""
proc/proc   procdefaults  0   0
PARTUUID=e625713b-01  /boot   vfatdefaults  0   
2
PARTUUID=e625713b-02  /   ext4defaults,noatime  0   
1

# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
"""

Do I need to do something else?

Thanks again.

Barry KV4FV

On Sun, 21 Jul 2019 12:53:24 -0700, Ron Economos wrote:

When building GNU Radio on small systems, it's very easy to run out of 
memory (especially when building swig files). The remedy is to create a 
swap file.


sudo fallocate -l 2G /swapfile

sudo chmod 600 /swapfile

sudo mkswap /swapfile

sudo swapon /swapfile

To make is permanent, add this line to /etc/fstab

/swapfile  none  swap  sw  0  0

Ron

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

Re: [Discuss-gnuradio] pybombs gnuradio install and sudo

[Marcus D Leech]

Because your PYTHONPATH and other environment variables aren’t inherited by a 
sudo shell by default. 

Use the -E option to sudo. 



Sent from my iPhone

> On Jul 22, 2019, at 11:54 AM, Müller, Marcus (CEL)  wrote:
> 
> Your sudo call resets the environment, and that includes things like
> PYTHONPATH, PATH and LD_LIBRARY_PATH.
> 
> You need to add the right options to sudo.
> 
> I'll carefully point out that the code in tuntap_pdu isn't really safe
> by any means. You generally should probably avoid running GNU Radio as
> root.
> 
> The easiest whilst-still-safe way forward:
> 
> just run `sudo ip tuntap add grtunnel mode tun user  sumit` (assuming
> sumit is your unprivileged user) and then, run your program as normal
> user.
> 
> Sadly, haven't tested that.
> 
> Best regards,
> Marcus
> 
>> On Mon, 2019-07-22 at 16:55 +0200, sumit kumar wrote:
>> Hi, 
>> When I try to run any gnuradio program with sudo (inside pybombs 
>> environment), it simply throws the error 
>> 
>> ImportError: No module named gnuradio
>> 
>> For example when I try to run tunnel based programs, which need ioctl calls 
>> and hence sudo or root. 
>> 
>> Without sudo it says operation not permitted and with sudo it says 
>> ImportError: No module named gnuradio
>> 
>> Solution ? :-/ 
>> 
>> 
>> 
>> 
>> ___
>> 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] Can't create Out of Tree Tagged Stream Blocks?

[Michael Dickens]

Hi DL - One possible option that I think would handle both TDMA and FDMA and 2 
streams of data: use a PFB with 2 channels (or 2 separate rotators / filters), 
to create 2 parallel paths each at baseband. Each path represents complex data 
that was modulated at some frequency and bandwidth & is now at baseband. For 
each path, detect the signal of interest, and once found package it as a 
tagged_stream. Each path leads into a different input of the tagged_stream_mux 
block as before (assuming that worked before, it should work now). In this 
manner, the mux will wait until it has 2 such tagged_streams. Maybe this would 
do what you want? Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 2:25 PM, Lundberg, Daniel wrote:
> Hi, thanks. To elaborate a bit…

> I need to be able to absolutely align the start of two signals and add them 
> in an FDMA sense (so I will construct the signals in different parts of the 
> band and just add them together as complex numbers). The receiving system 
> requires that I do the alignment for it. It is also important that one of the 
> two signals be created and transmitted in a timely manner (I have a 
> requirement for the time between when the second signal is created and when 
> it is transmitted, because it contains some real-time diagnostic information).

> I have previously solved a similar problem, but instead of FDMA I was doing 
> TDMA. The basic code structure is:

> Convert the first of the two signals to a tagged stream via stream to tagged 
> stream block. 

> Custom trigger block waits for the packet_len tag in this signal, and when it 
> sees it, sends a message to trigger the creation of a PDU with the second 
> signal within another custom block. 

> PDU goes into PDU to tagged stream block

> Combine two signals (now both tagged streams) in a tagged stream mux block. 

> To the USRP and beyond!

> Using one signal to trigger the other, combined with the tagged stream mux 
> waiting until it has both signals in memory to proceed, means that the 
> latency of the whole process is naturally controlled, because the first 
> signal will not pass another packet_len tag through my custom trigger block 
> until the first packet is clear of the tagged stream mux. This did require 
> explicit adjustment to minimum buffer sizes to accommodate the big packets, 
> but things are stable and working on a pretty standard dell laptop, so I 
> don’t have any performance worries at this point, even with a bunch of custom 
> code written in python.

> So back to FDMA:

> I can do the same sort of thing, where I trigger the creation of the second 
> signal off of the first, but I don’t have an explicit way to control the flow 
> without the tagged stream mux introducing the (desirable!) bottleneck. 
> Without that backpressure, there is nothing to stop the first signal from 
> triggering the second signal a large number of times until a non-tagged 
> stream block’s buffer is filled up. This is undesirable for me, because it 
> means I will have a bunch of diagnostic signals generated right away, and 
> then the system will eventually settle into some steady-state latency that is 
> longer than my requirement. So if I had an OOT “tagged stream add” block that 
> does a simple complex add, but waits for both tagged stream packets to be 
> present before proceeding, I think I would be more or less done.

> Thank you for the OOT compiling tips, I’ll give it a go. C++ is not my forte…

> DL

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

Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks?

[Lundberg, Daniel via Discuss-gnuradio]

Hi, thanks.  To elaborate a bit…
I need to be able to absolutely align the start of two signals and add them in 
an FDMA sense (so I will construct the signals in different parts of the band 
and just add them together as complex numbers).  The receiving system requires 
that I do the alignment for it.  It is also important that one of the two 
signals be created and transmitted in a timely manner (I have a requirement for 
the time between when the second signal is created and when it is transmitted, 
because it contains some real-time diagnostic information).

I have previously solved a similar problem, but instead of FDMA I was doing 
TDMA.  The basic code structure is:
Convert the first of the two signals to a tagged stream via stream to tagged 
stream block.
Custom trigger block waits for the packet_len tag in this signal, and when it 
sees it, sends a message to trigger the creation of a PDU with the second 
signal within another custom block.
PDU goes into PDU to tagged stream block
Combine two signals (now both tagged streams) in a tagged stream mux block.
To the USRP and beyond!

Using one signal to trigger the other, combined with the tagged stream mux 
waiting until it has both signals in memory to proceed, means that the latency 
of the whole process is naturally controlled, because the first signal will not 
pass another packet_len tag through my custom trigger block until the first 
packet is clear of the tagged stream mux.  This did require explicit adjustment 
to minimum buffer sizes to accommodate the big packets, but things are stable 
and working on a pretty standard dell laptop, so I don’t have any performance 
worries at this point, even with a bunch of custom code written in python.

So back to FDMA:
I can do the same sort of thing, where I trigger the creation of the second 
signal off of the first, but I don’t have an explicit way to control the flow 
without the tagged stream mux introducing the (desirable!) bottleneck.  Without 
that backpressure, there is nothing to stop the first signal from triggering 
the second signal a large number of times until a non-tagged stream block’s 
buffer is filled up.  This is undesirable for me, because it means I will have 
a bunch of diagnostic signals generated right away, and then the system will 
eventually settle into some steady-state latency that is longer than my 
requirement.  So if I had an OOT “tagged stream add” block that does a simple 
complex add, but waits for both tagged stream packets to be present before 
proceeding, I think I would be more or less done.

Thank you for the OOT compiling tips, I’ll give it a go.  C++ is not my forte…
DL

From: Michael Dickens 
Sent: Monday, July 22, 2019 1:52 PM
To: Lundberg, Daniel ; Discuss GNURadio 

Subject: Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks?

Hi DL - 2 primary thoughts:

1) To "create" a tagged stream block in your OOT using gr_modtool (if it 
doesn't do that as you desire), find an already existing tagged_stream block 
that you understand the programming of. Use gr_modtool to create a new "sync" 
block, then copy/paste from the existing tagged_stream block into your new one: 
3 files: include/OOT/NAME.h ; lib/NAME_impl.h ; lib/NAME_impl.cc . The 
CMakeLists.txt will already be setup for compiling, assuming you don't need any 
special definitions or linkage or whatever. Then, edit those files to do what 
you want.

2) 1 million data points is a lot of points to do using a data stream! And even 
more if you used a tagged stream for all 1e6 samples! Do you need them all at 
the same time, or are the offsets small enough that you just need a small 
number of data samples stored before you can alight them? Alternative 
implementations might include using PDUs ... but much depends on what exactly 
you're trying to accomplish beyond what you wrote (what the actual algorithm is 
you're trying to implement).

Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 11:28 AM, Lundberg, Daniel via Discuss-gnuradio wrote:

I am working within Gnuradio version 3.7.13.4.  As far as I can tell, 
gr_modtool does not support tagged stream blocks for either python or C++.  
Trying to make a new tagged stream block in C++ will create QA code, but does 
not make files for the actual block.  For python it will throw a hard error.  
This appears to be a known issue:  
https://github.com/gnuradio/gnuradio/issues/2489



Can someone point me to some documentation on how to implement an out of tree 
module without gr_modtool?



If this is a non-starter, then here is my problem description.  I am open to 
suggestions on how to solve the problem without an OOT tagged stream block:

I need to implement a block that takes two generated signals with defined, very 
large (~ million sample) packet lengths that are produced at different times, 
align them on a sample-by-sample basis, and adds them.  I know how to do this 
within a tagged stream block.  I am open to ideas on how to do this 

Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks?

[Michael Dickens]

Hi DL - 2 primary thoughts:

1) To "create" a tagged stream block in your OOT using gr_modtool (if it 
doesn't do that as you desire), find an already existing tagged_stream block 
that you understand the programming of. Use gr_modtool to create a new "sync" 
block, then copy/paste from the existing tagged_stream block into your new one: 
3 files: include/OOT/NAME.h ; lib/NAME_impl.h ; lib/NAME_impl.cc . The 
CMakeLists.txt will already be setup for compiling, assuming you don't need any 
special definitions or linkage or whatever. Then, edit those files to do what 
you want.

2) 1 million data points is a lot of points to do using a data stream! And even 
more if you used a tagged stream for all 1e6 samples! Do you need them all at 
the same time, or are the offsets small enough that you just need a small 
number of data samples stored before you can alight them? Alternative 
implementations might include using PDUs ... but much depends on what exactly 
you're trying to accomplish beyond what you wrote (what the actual algorithm is 
you're trying to implement).

Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 11:28 AM, Lundberg, Daniel via Discuss-gnuradio wrote:
> I am working within Gnuradio version 3.7.13.4. As far as I can tell, 
> gr_modtool does not support tagged stream blocks for either python or C++. 
> Trying to make a new tagged stream block in C++ will create QA code, but does 
> not make files for the actual block. For python it will throw a hard error. 
> This appears to be a known issue: 
> https://github.com/gnuradio/gnuradio/issues/2489

> 

> Can someone point me to some documentation on how to implement an out of tree 
> module without gr_modtool? 

> 

> If this is a non-starter, then here is my problem description. I am open to 
> suggestions on how to solve the problem without an OOT tagged stream block:

> I need to implement a block that takes two generated signals with defined, 
> very large (~ million sample) packet lengths that are produced at different 
> times, align them on a sample-by-sample basis, and adds them. I know how to 
> do this within a tagged stream block. I am open to ideas on how to do this 
> without tagged streams, but I’m not sure how to do sample alignment of large 
> packets without having them contained in a tagged stream block work function.

> 

> Thank you,

> DL

> 

> ___
> 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] pybombs gnuradio install and sudo

[CEL]

Your sudo call resets the environment, and that includes things like
PYTHONPATH, PATH and LD_LIBRARY_PATH.

You need to add the right options to sudo.

I'll carefully point out that the code in tuntap_pdu isn't really safe
by any means. You generally should probably avoid running GNU Radio as
root.

The easiest whilst-still-safe way forward:

just run `sudo ip tuntap add grtunnel mode tun user  sumit` (assuming
sumit is your unprivileged user) and then, run your program as normal
user.

Sadly, haven't tested that.

Best regards,
Marcus

On Mon, 2019-07-22 at 16:55 +0200, sumit kumar wrote:
> Hi, 
> When I try to run any gnuradio program with sudo (inside pybombs 
> environment), it simply throws the error 
> 
> ImportError: No module named gnuradio
> 
> For example when I try to run tunnel based programs, which need ioctl calls 
> and hence sudo or root. 
> 
> Without sudo it says operation not permitted and with sudo it says 
> ImportError: No module named gnuradio
> 
> Solution ? :-/ 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks?

[Lundberg, Daniel via Discuss-gnuradio]

I am working within Gnuradio version 3.7.13.4.  As far as I can tell, 
gr_modtool does not support tagged stream blocks for either python or C++.  
Trying to make a new tagged stream block in C++ will create QA code, but does 
not make files for the actual block.  For python it will throw a hard error.  
This appears to be a known issue:  
https://github.com/gnuradio/gnuradio/issues/2489

Can someone point me to some documentation on how to implement an out of tree 
module without gr_modtool?

If this is a non-starter, then here is my problem description.  I am open to 
suggestions on how to solve the problem without an OOT tagged stream block:
I need to implement a block that takes two generated signals with defined, very 
large (~ million sample) packet lengths that are produced at different times, 
align them on a sample-by-sample basis, and adds them.  I know how to do this 
within a tagged stream block.  I am open to ideas on how to do this without 
tagged streams, but I'm not sure how to do sample alignment of large packets 
without having them contained in a tagged stream block work function.

Thank you,
DL

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

[Discuss-gnuradio] pybombs gnuradio install and sudo

[sumit kumar]

Hi,
When I try to run any gnuradio program with sudo (inside pybombs
environment), it simply throws the error

*ImportError: No module named gnuradio*

For example when I try to run tunnel based programs, which need ioctl calls
and hence sudo or root.

Without sudo it says operation not permitted and with sudo it says
ImportError: No module named gnuradio

Solution ? :-/




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

[Discuss-gnuradio] [GSoC19] Weekly report of Verilog simulation phase 2 week 3

[Bowen Hu]

Hi all,
​
You can find my weekly report 
here(https://b0wen-hu.github.io/2019/07/21/GSoC-weekly-report-P2W3/).​

​
The following content is the abstract  of report, please find the full report 
at the link above.​
​​
##Progress this week
I moved the verilog_axi_ii block to a new branch axi, you can find it here.

With the help of Marcus, I add some extra code to make sure the block could 
find the path of templates. In the new branch axi, you can find the templates 
in the ./templates folder.

I modified some of the code of cpp template axi_module.cpp, instead of just 
offer a single void AXI_transfer(const unsigned int &gr_input, unsigned int 
&gr_output, unsigned int &time), I think there should be more kinds of 
interactives between the block and the verilog module, so I offer more function 
in this template.

verilog_axi_ii assumes the input and output should be synchronized, which may 
not be the real case in the AXI-stream interface. I am working on the general 
case of AXI-stream situation.

I am working on some more test cases as well, including doubler.v, which 
generates the x2 of input, and a FIFO_sync.v

##Plan next week
Implement the general case of AXI-stream, using general block.

##Issue(s)
I am not sure how to implement forecast of the block, with so little knowledge 
of user verilog module.
​
Best regards,​
Bowen​

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

[Discuss-gnuradio] [job posting] Looking for Researchers for 5G SDR work @ANT/Uni Bremen

[Johannes Demel]

Hi all,

I'd like to let you know that we have open positions for SDR-related 
work at our department [0]. The goal would be to eventually graduate as 
a PhD (Dr.-Ing.).
The research focus will be on 5G baseband signal processing and SDR 
implementations.

Applications should go directly to our head, Prof. Dr.-Ing. Armin 
Dekorsy 

Cheers
Johannes


[0] 
https://www.uni-bremen.de/de/universitaet/die-uni-als-arbeitgeber/offene-stellen/detailansicht/joblist/Job/show/div-wissenschaftliche-mitarbeiterinnen-wmd-5832/

PS: This is my second try to post this email on the mailing list. I did 
not receive a copy of my first try.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio