Re: Python OOT module not showing up in GRC

[Roman A Sandler]

Hi,

I figured out the issue. As discussed in this previous thread,
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00194.html
<https://sgndr.online/click?redirect=https%3A%2F%2Flists.gnu.org%2Farchive%2Fhtml%2Fdiscuss-gnuradio%2F2015-08%2Fmsg00194.html=1595273972573=https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00194.html>,
I needed to make a config.cong file at ~/.gnuradio and add the following
lines to it:

```
[grc]
local_blocks_path = /usr/local/share/gnuradio/grc/blocks
```

Given how well gr_modtool automatically sets everything up, I am not sure
why this wasn't automatically done - but seems like it should be in the
future.

-Roman




On Sat, Jul 18, 2020 at 9:00 AM  wrote:

> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> <https://sgndr.online/click?redirect=https%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fdiscuss-gnuradio=1595273972573>
> https://lists.gnu.org/mailman/
> <https://sgndr.online/click?redirect=https%3A%2F%2Flists.gnu.org%2Fmailman%2F=1595273972573=https://lists.gnu.org/mailman/>
> listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. Re: Discuss-gnuradio Digest, Vol 213, Issue 17 (Anselm Karl)
>2. Python OOT module not showing up in GRC (Roman A Sandler)
>3. Re: Python OOT module not showing up in GRC (Ron Economos)
>4. GSoC 2020: New Blog Post for Week 8 (Alekh)
>5. Re: Python OOT module not showing up in GRC (Barry Duggan)
>
>
> --
>
> Message: 1
> Date: Fri, 17 Jul 2020 18:04:11 +0200
> From: Anselm Karl 
> To: discuss-gnuradio@gnu.org
> Subject: Re: Discuss-gnuradio Digest, Vol 213, Issue 17
> Message-ID:
> <
> cakcs5r0d+bufdh2fqasbm_z7zzyhf4_yzrpmbwxqbarqaxs...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>  schrieb am Fr., 17. Juli 2020, 18:03:
>
> > Send Discuss-gnuradio mailing list submissions to
> > discuss-gnuradio@gnu.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >
> <https://sgndr.online/click?redirect=https%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fdiscuss-gnuradio=1595273972573>
> https://lists.gnu.org/
> <https://sgndr.online/click?redirect=https%3A%2F%2Flists.gnu.org%2F=1595273972573=https://lists.gnu.org/>
> mailman/listinfo/discuss-gnuradio
> > or, via email, send a message with subject or body 'help' to
> > discuss-gnuradio-requ...@gnu.org
> >
> > You can reach the person managing the list at
> > discuss-gnuradio-ow...@gnu.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Discuss-gnuradio digest..."
> >
> >
> > Today's Topics:
> >
> >1. Project call today (Marcus Müller)
> >2. Re: Problem with Gnuradio convolution encoder/decoder! (rear1019)
> >3. Re: Project call today (Glen Langston)
> >4. Re: Problem with Gnuradio convolution encoder/decoder!
> >   (George Edwards)
> >5. Re: Project call today (Marcus Müller)
> >6. gnuradio (+ friends) packages for conda on Linux, macOS, and
> >   Windows (Ryan Volz)
> >7. Re: gnuradio (+ friends) packages for conda on Linux, macOS,
> >   and Windows (Glen Langston)
> >8. Creating synchronized USRP source block (Marcin Wachowiak)
> >9. problem in making a project  (Yasser Attarizi)
> >   10. Re: GPIO lines on RPi4 (jean-michel.fri...@femto-st.fr)
> >
> >
> > --
> >
> > Message: 1
> > Date: Thu, 16 Jul 2020 18:35:59 +0200
> > From: Marcus Müller 
> > To: GNURadio Discussion List 
> > Subject: Project call today
> > Message-ID: <68eff59d-ab19-cda4-eac1-962a3c024...@kit.edu>
> > Content-Type: text/plain; charset="utf-8"; format=flowed
> >
> > Hi bestest SDR community,
> >
> > Heads up: the July project all is happening in 30 minutes.
> >
> > Cheers,
> > Marcus
> >
> >
> >
> > --
> >
> > Message: 2
> > Date: Thu, 16 Jul 2020 18:53:38 +0200
> > From: rear1019 
> >

Python OOT module not showing up in GRC

[Roman A Sandler]

Hi,

I have followed Section 3.2 in the tutorial
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python to
setup an OOT python block in GRC.

I followed the instructions on a Linux machine running GNURadio 3.7 and it
worked exactly as described.

I then ran the tutorial on an NVIDIA Xavier Linux machine w/ GNURadio 3.8
and all the steps seemed to work. The QA test worked in python, and `cmake;
make; sudo make install; sudo ldconfig` all ran without any errors.
However, when I open GRC, I cannot see the block.

I am wondering if this tutorial is not up-to-date w/ GNURadio 3.8 or if
maybe there is something weird about the Xavier that is causing the bug.

Let me know,
Thanks!

Fwd: OTA Encoding/Decoding with Ettus SDR & GNURadio

[Roman A Sandler]

Here is a cleaner updated flowchart from my previous question:
https://imgur.com/1uuqT9J

(I removed lines running behind blocks - Thanks Marcus for the tip)

-Roman



-- Forwarded message -
From: Roman A Sandler 
Date: Wed, May 27, 2020 at 10:31 AM
Subject: OTA Encoding/Decoding with Ettus SDR & GNURadio
To: 
Cc: 


Hi, I am trying to do over-the-air (OTA) encoding and decoding using
GNURadio and an Ettus SDR. I used a basic flowgraph (shown at
https://imgur.com/a/P846OSe) which I know can correctly decode the encoded
signal w/ 0 BER in simulation (w/o/ the SDR blocks). However, using the SDR
sink/source blocks, I can no longer recover the correct bits. Here is how
the visualized recovered data looks like: https://imgur.com/a/Z5JfvjS. As
you can see I am unable to recover the original encoded bits.

So my questions are:
1) What am I doing wrong?
2) Are there any articles/tutorials which discuss how to encode/decode w/
GNURadio & Ettus SDR?

Thanks,
Roman

OTA Encoding/Decoding with Ettus SDR & GNURadio

[Roman A Sandler]

Hi, I am trying to do over-the-air (OTA) encoding and decoding using
GNURadio and an Ettus SDR. I used a basic flowgraph (shown at
https://imgur.com/a/P846OSe) which I know can correctly decode the encoded
signal w/ 0 BER in simulation (w/o/ the SDR blocks). However, using the SDR
sink/source blocks, I can no longer recover the correct bits. Here is how
the visualized recovered data looks like: https://imgur.com/a/Z5JfvjS. As
you can see I am unable to recover the original encoded bits.

So my questions are:
1) What am I doing wrong?
2) Are there any articles/tutorials which discuss how to encode/decode w/
GNURadio & Ettus SDR?

Thanks,
Roman

Custom constellation scheme

[Roman A Sandler]

Hi,

I am currently using `digital.generic_mod` with the included modulation
scheme from
https://www.gnuradio.org/doc/sphinx-3.7.1/digital/constellations.html

(e.g. digital.constellation_8psk, digital.constellation_16qam,
etc...) as such:

```
digital_constellation_modulator = digital.generic_mod(


constellation=digital.constellation_bpsk().base(),
differential=False,
samples_per_symbol=sps,
pre_diff_code=True,
excess_bw=excess_bw,
verbose=False,
log=False)

```

However, I would like to use modulation schemes which are not included in
digital. I have two questions in that regard:

1) How can I define my own phase-amplitude type modulation schemes such as
4PAM, 64QAM which are not included by default?
2) Can I use digital.generic_mod with FSK type modulations like GFSK? If
not how would I use them?

Thanks,
Roman

Re: GNURadio Leaking memory during repeated simulations

[Roman A Sandler]

Him Geof,

I am running GR using the standard install but from PyCharm (I imported all
the necessary environment variables from run_gr.bat into PyCharm myself). I
installed tqdm on top of the GR python via pip. I also confirmed that the
issue occurs even without tqdm. Could PyCharm be causing these problems?

-Roman

On Thu, Feb 13, 2020 at 7:10 PM Geof Nieboer  wrote:

> Roman,
>
> I was able to run your code, and got a consistent 150-160 it/s through the
> whole run, with about 65MB of memory in use (as reporting by Task
> Manager).  This was on Windows 10 running GR 3.8.0.0.
>
> I noticed there was another package installed (tqdm) that's not part of
> the GR install.  So I want to confirm... did you add that package to the
> python that installed as part of GR, or are you using a different python?
>
> If you are using a different python install, a possible explanation is
> compilers; the GR packages and binaries are all built with VS 2015, but the
> py2.7 standard is VS 2008 (which won't build GR any more), and mixing (VS)
> compilers can cause odd issues.  So for GR, the entire python 2.7 and every
> package is built from scratch w/ 2015.  tqdm doesn't seem to be affected, I
> added that to the GR python install using a pip install, nothing fancy, and
> it seems to have worked.
>
> If you are, however, running the script with the GR-installed python after
> opening with run_gr.bat, then I'm scratching my head what's happening.
>
> Geof
>
> On Thu, Feb 13, 2020 at 12:00 PM Roman A Sandler 
> wrote:
>
>> Hi Marcus,
>>
>> Thanks for the reply!
>>
>> My GNURadio version: *3.8.0.0 (Python 2.7.10)*
>> It is the Windows 3.8.0.0 version downloaded from:
>> http://www.gcndevelopment.com/gnuradio/downloads.htm
>>
>> Complete reproducible code is below. I use the tqdm package to monitor
>> iterations per second. On my PC, the it/sec declines very precipitously
>> (starts at 85it/sec, then down to 22it/s after 40s and keeps dropping.
>> Eventually as low as 1 it/sec).
>>
>>
>> ```
>>
>> import numpy as np
>> from gnuradio import gr, gr_unittest
>> from gnuradio import blocks
>> from gnuradio import digital
>> from gnuradio.filter import firdes
>> from gnuradio import channels
>> from tqdm import tqdm
>>
>>
>> def decode(channel_sigs):
>> tb = gr.top_block()
>>
>> ##
>> # Variables
>> ##
>> nfilts = 32
>> sps = 4
>> timing_loop_bw = 3 * 6.28 / 100.0  # NOTE: this controls convergence 
>> speed!
>> constellation_scheme = digital.constellation_8psk().base()
>> rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / float(sps), 
>> 0.35, 11 * sps * nfilts)
>>
>>  Actual blocks
>> channel_src = blocks.vector_source_c(channel_sigs, False)
>> digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, timing_loop_bw, 
>> rrc_taps, nfilts,
>> nfilts / 2, 1.5, 1)
>> constellation_soft_decoder = 
>> digital.constellation_soft_decoder_cf(constellation_scheme)
>> binary_slicer = digital.binary_slicer_fb()
>> blocks_char_to_float = blocks.char_to_float(1, 1)
>> recovered_bits_dst = blocks.vector_sink_f()
>>
>> ##
>> # Connections
>> ##
>> tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0))
>> tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_decoder, 0))
>> tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0))
>> tb.connect((binary_slicer, 0), (blocks_char_to_float, 0))
>> tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0))
>>
>> tb.run()
>> recovered_bits = np.array(recovered_bits_dst.data())
>>
>> return recovered_bits
>>
>>
>> if __name__ == '__main__':
>> n_trls = 1
>> n_samples = 
>> sig = np.random.normal(size=(n_samples,)) + 1j * 
>> np.random.normal(size=(n_samples,))
>>
>> for n in tqdm(range(n_trls)):
>> decode(sig)
>>
>> ```
>>
>>
>> On Thu, Feb 13, 2020 at 2:11 AM Müller, Marcus (CEL) 
>> wrote:
>>
>>> Hi,
>>>
>>> huh. That looks hard to debug; also, the slow down is suspicious (as
>>> long as there's memory available, it shouldn't take significantly
>>> longer to get some – usually, memory fragmenta

Re: GNURadio Leaking memory during repeated simulations

[Roman A Sandler]

Hi Marcus,

Thanks for the reply!

My GNURadio version: *3.8.0.0 (Python 2.7.10)*
It is the Windows 3.8.0.0 version downloaded from:
http://www.gcndevelopment.com/gnuradio/downloads.htm

Complete reproducible code is below. I use the tqdm package to monitor
iterations per second. On my PC, the it/sec declines very precipitously
(starts at 85it/sec, then down to 22it/s after 40s and keeps dropping.
Eventually as low as 1 it/sec).


```

import numpy as np
from gnuradio import gr, gr_unittest
from gnuradio import blocks
from gnuradio import digital
from gnuradio.filter import firdes
from gnuradio import channels
from tqdm import tqdm


def decode(channel_sigs):
tb = gr.top_block()

##
# Variables
##
nfilts = 32
sps = 4
timing_loop_bw = 3 * 6.28 / 100.0  # NOTE: this controls convergence speed!
constellation_scheme = digital.constellation_8psk().base()
rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 /
float(sps), 0.35, 11 * sps * nfilts)

 Actual blocks
channel_src = blocks.vector_source_c(channel_sigs, False)
digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps,
timing_loop_bw, rrc_taps, nfilts,
nfilts / 2, 1.5, 1)
constellation_soft_decoder =
digital.constellation_soft_decoder_cf(constellation_scheme)
binary_slicer = digital.binary_slicer_fb()
blocks_char_to_float = blocks.char_to_float(1, 1)
recovered_bits_dst = blocks.vector_sink_f()

##
# Connections
##
tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0))
tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_decoder, 0))
tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0))
tb.connect((binary_slicer, 0), (blocks_char_to_float, 0))
tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0))

tb.run()
recovered_bits = np.array(recovered_bits_dst.data())

return recovered_bits


if __name__ == '__main__':
n_trls = 1
n_samples = 
sig = np.random.normal(size=(n_samples,)) + 1j *
np.random.normal(size=(n_samples,))

for n in tqdm(range(n_trls)):
decode(sig)

```


On Thu, Feb 13, 2020 at 2:11 AM Müller, Marcus (CEL) 
wrote:

> Hi,
>
> huh. That looks hard to debug; also, the slow down is suspicious (as
> long as there's memory available, it shouldn't take significantly
> longer to get some – usually, memory fragmentation isn't *that* bad,
> and this shouldn't be doing *that* much memory allocation).
>
> Could you put all your code in one .py file (or a set of these) that
> one can simply execute right away? That would allow us to reproduce.
> Also, could you tell us your specific GNU Radio version (all four
> digits of it?).
>
> Best regards,
> Marcus
>
> On Tue, 2020-02-11 at 16:34 -0800, Roman A Sandler wrote:
> > Hi,
> >
> > I am using GNURadio to decode a large amount of 1024-sample complex
> > vectors of different modulation schemes. Thus, I have a for loop
> > which runs gr.top_block.run() at each iteration and uses a vector
> > sink to collect the results. The issue is that as the simulation
> > keeps going, each itertion takes longer (e.g. starts of at 120it/sec,
> > and then after 5000 iterations slows down to 10it/sec). I can see in
> > task manager (I am on windows) that memory is increasing so clearly
> > there is a memory leak where somehow the results of the iterations
> > arent being deleted.
> >
> > Is there an explicit way to delete runs or is this a bug?
> >
> > CODE:
> >
> > calling code:
> > ```
> > for _ in range(1):
> > decode(sig)
> > ```
> >
> > decode func:
> > ```
> > def decode(channel_sigs):
> > tb = gr.top_block()
> >
> > ##
> > # Variables
> > ##
> > nfilts = 32
> > sps = 4
> > timing_loop_bw = 3 * 6.28 / 100.0  # NOTE: this controls
> > convergence speed!
> > constellation_scheme, bps = get_constellation_scheme(scheme)
> > rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 /
> > float(sps), 0.35, 11 * sps * nfilts)
> > phase_bw = 6.28 / 100.0
> > eq_gain = 0.01
> > arity = 4
> >
> >  Actual blocks
> > channel_src = blocks.vector_source_c(channel_sigs, False)
> > digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps,
> > timing_loop_bw, rrc_taps, nfilts,
> >

GNURadio Leaking memory during repeated simulations

[Roman A Sandler]

Hi,

I am using GNURadio to decode a large amount of 1024-sample complex vectors
of different modulation schemes. Thus, I have a for loop which runs
gr.top_block.run() at each iteration and uses a vector sink to collect the
results. The issue is that as the simulation keeps going, each itertion
takes longer (e.g. starts of at 120it/sec, and then after 5000 iterations
slows down to 10it/sec). I can see in task manager (I am on windows) that
memory is increasing so clearly there is a memory leak where somehow the
results of the iterations arent being deleted.

Is there an explicit way to delete runs or is this a bug?

CODE:

calling code:
```
for _ in range(1):
decode(sig)
```

decode func:
```
def decode(channel_sigs):
tb = gr.top_block()

##
# Variables
##
nfilts = 32
sps = 4
timing_loop_bw = 3 * 6.28 / 100.0  # NOTE: this controls convergence
speed!
constellation_scheme, bps = get_constellation_scheme(scheme)
rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / float(sps),
0.35, 11 * sps * nfilts)
phase_bw = 6.28 / 100.0
eq_gain = 0.01
arity = 4

 Actual blocks
channel_src = blocks.vector_source_c(channel_sigs, False)
digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps,
timing_loop_bw, rrc_taps, nfilts,
nfilts / 2, 1.5, 1)
constellation_soft_decoder =
digital.constellation_soft_decoder_cf(constellation_scheme)
binary_slicer = digital.binary_slicer_fb()
blocks_char_to_float = blocks.char_to_float(1, 1)
recovered_bits_dst = blocks.vector_sink_f()

##
# Connections
##
tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0))
tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_decoder, 0))
tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0))
tb.connect((binary_slicer, 0), (blocks_char_to_float, 0))
tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0))

tb.run()

recovered_bits = np.array(recovered_bits_dst.data())
return recovered_bits
```

GNURadio with Python 3 for Windows

[Roman A Sandler]

Hi,

Currently, the windows precompiled GNUradio installers found here
feature GNURadio 3.8,
but only with Python 2.7. My questions are:

   1. Is there a currently precompiled Windows version of GNURadio 3.8 w/
   Python 3?
   2. If there is not, is there a relatively easy way that I could compile
   one myself?
   3. If also not, how could I interface my current Python 3 codebase w/
   the GNURadio Python 2 output?

Thanks!