Re: Group name of python scripts generated by GRC

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

You might be interested in the unix command newgrp, that can change the group 
id of your session such that new files greated should have this group. 

The normal behavior for any program is to create files with the group of the 
current session. It would of course be possible for grc to have such an option 
but it seems like a very niche request.

/Elof

> 7 feb. 2024 kl. 17:37 skrev kron...@tiscali.it:
> 
> 
> Hello guys!
> I am searching for a GRC option such that the group name of the generated 
> python scripts is automatically set.
> I do not know if this option is already available, but i would like the 
> generated python scripts belong to the same group name of the relative grc 
> file.
> Thanks for help.
> Ivan
> 

Discussion about gnu radio

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi I am Nithin
i want to discuss about gnu radio
please give response


[https://intranet.cb.amrita.edu/sig/RankingLogo.png]

Disclaimer

Fwd: multi file Tx/Rx over OFDM

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hey all,
trying to send a text file using B200 and receive it using B210 or PLUTO
over OFDM Tx/Rx blocks.
the setup works fine, but I need this setup to be repeated for 100
different text files. So, I modified the python code to read, send and
transmit the files one by one. the code works good for the first two
(sometimes three) files and after that the files written at receiver side
are all of size zero byte. I used another SDR on a nearby machine and could
detect that there is transmission going there.
attached is :
- the flow graph to illustrate the idea
-python code files (main one is ofdmrx_processor)

I wonder if it is related to buffering issues, you kind help is appreciated.

Moath Sulaiman
#!/usr/bin/env python3
# -*- coding: utf-8 -*-

#
# SPDX-License-Identifier: GPL-3.0
#
# GNU Radio Python Flow Graph
# Title: FullDupx_OFDM_forCode
# Author: Moath Sulaiman
# Description: send and receive a file using OFDM over USRPs
# GNU Radio version: v3.11.0.0git-393-ga07ced54

from packaging.version import Version as StrictVersion
from PyQt5 import Qt
# from gnuradio import qtgui
from gnuradio import digital

from gnuradio import blocks
import pmt,os
from gnuradio import gr
from gnuradio.filter import firdes
from gnuradio.fft import window
import sys
import signal
from PyQt5 import Qt
from argparse import ArgumentParser
from gnuradio.eng_arg import eng_float, intx
from gnuradio import eng_notation
from gnuradio import uhd
import time
import numpy as np
from gnuradio import iio



class ofdm_rxblock(gr.top_block):

def __init__(self,fname):

gr.top_block.__init__(self, "ofdm_block_code", catch_exceptions=True)

##
# Variables
##
self.samp_rate = samp_rate = 150
self.rf_rate = rf_rate = 150
self.rand = rand = np.random.randint(0, 2, 100)
self.packet_len = packet_len = 48
self.len_tag_key = len_tag_key = "packet_len"
self.fft_len = fft_len = 64
self.cfreq = cfreq = int(2.8e9)
self.BW = BW = 2e6

GR_FIXED_BUFFER_SIZE = 128e6



##
# Blocks
##



# Rx Part 30D3F3D ##

#  B200 series receiver ##
# self.uhd_usrp_source_0 = uhd.usrp_source(
# ",".join(('serial=30D3F3D', '')),
# uhd.stream_args(
# cpu_format="fc32",
# args='',
# channels=list(range(0,1)),
# ),
# )
# self.uhd_usrp_source_0.set_samp_rate(samp_rate)
# self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec(0))
# self.uhd_usrp_source_0.set_center_freq(cfreq, 0)
# self.uhd_usrp_source_0.set_antenna("TX/RX", 0)
# self.uhd_usrp_source_0.set_bandwidth(BW, 0)
# self.uhd_usrp_source_0.set_gain(75, 0)

 PLUTO Receiver ##


self.iio_pluto_source_0 = iio.fmcomms2_source_fc32('ip:192.168.2.1' if 'ip:192.168.2.1' else iio.get_pluto_uri(), [True, True], 32768)
self.iio_pluto_source_0.set_len_tag_key('packet_len')
self.iio_pluto_source_0.set_frequency(cfreq)
self.iio_pluto_source_0.set_samplerate(samp_rate)
self.iio_pluto_source_0.set_gain_mode(0, 'slow_attack')
self.iio_pluto_source_0.set_gain(0, 64)
self.iio_pluto_source_0.set_quadrature(True)
self.iio_pluto_source_0.set_rfdc(True)
self.iio_pluto_source_0.set_bbdc(True)
self.iio_pluto_source_0.set_filter_params('Auto', '', 0, 0)


# OFDM Rcvr #


self.digital_ofdm_rx_0 = digital.ofdm_rx(
fft_len=fft_len, cp_len=(fft_len//4),
frame_length_tag_key='frame_'+"rx_len",
packet_length_tag_key="rx_len",
occupied_carriers=((-4,-3,-2,-1,1,2,3,4),),
pilot_carriers=((-6,-5,5,6),),
pilot_symbols=((-1,1,-1,1),),
sync_word1=None,
sync_word2=None,
bps_header=1,
bps_payload=2,
debug_log=False,
scramble_bits=False)

# self.digital_ofdm_rx_0.set_min_output_buffer(65536)
# self.digital_ofdm_rx_0.set_max_output_buffer(int(65536))


os.chdir(r'//home/moath/Documents/OFDM/ofdm_block/RandVector/Code/files/Rx_data')

# self.blocks_vector_source_x_0_0 = blocks.vector_source_f(rand, True, 1, [])
# self.blocks_sub_xx_0 = blocks.sub_ff(1)
# self.blocks_float_to_char_1 = blocks.float_to_char(1, 1)

# outfile = fname.replace('txt','out')
# self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_char*1, outfile, False)
# self.blocks_file_sink_0.set_unbuffered(False)
# self.blocks_char_to_float_1 = blocks.char_to_floa

Missings packets on OFDM system simulation

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone, I have some question related with a OFDM transmission
simulation, in particular, about losing packets.

I am using the OFDM Transmitter and Receiver blocks to do the transmission
(if you need more details, I can upload an image of the flowgraph).

The problem that I get is when put some noise (to get some level of SNR),
when I have about 20dB (or more) of SNR I don't lose any packet, but if I
put less than 20dB of SNR, almost all packets gets lost, (just 1 or 2
packets are received), all of this happen over simulation.

Any suggestions on why this might happen?

static ip on E312 not working

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi all

i want to assign a static ip address to my E312, i have modify the
eth0.network file in /data/network, this is the content:

[Match]
Name=eth0
KernelCommandLine=!nfsroot

[Network]
Address=192.168.10.42
IPForward=ipv4

[DHCP]
UseHostname=true
UseDomains=true
ClientIdentifier=mac

But I rebooted the E312 and did not have the ip assigned, ¿does anyone know
why this is not happening?

udp source - too much data warning message

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi all, I have a problem with the UDP sink and UDP source blocks, i am
working on a USRP E312 and i made a copy of a .wav file and a python script
on the USRP, the script is from the GRC 3.8 and it is only a wav file
source block and the UDP sink block, in another flowgraph i have the
correspondent UDP source and the audio sink, but i can't hear the file just
like a instant and then noise, when i run the host part of the test i get
this error:
gr::log :WARN: udp_source0 - Too much data; dropping packet.


What can I do?? i did a quick google search and all i could find was that i
have to modify the dp_source_impl.cc file, but i don't even know where that
file is

Re: E312 RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function 'get_num_xbars'

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

then i should have uhd 3.9LTS both in the host and the e312? because i've
been using GNU-Radio 3.8 with UHD 4.3.

i apologize if i make basics questions, im new using GNU-Radio and the e312

El mié, 12 abr 2023 a las 11:22, Marcus D. Leech ()
escribió:

> On 12/04/2023 10:49, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
> Open-Source Toolkit for Software Radio wrote:
> > Hello everyone
> >
> > I was fixing a problem with the mpm version, for some reason, I had
> > different versions both in my host and in the e312, i fixed that
> > problem by installing GNU-radio on the host but now when I try to use
> > the e312 I get this error.
> >
> You should probably read this:
>
> https://files.ettus.com/manual/page_usrp_e3xx.html#e31x_migration
>
> In particular, network mode is no longer supported on E3xx after the MPM
> migration and UHD 3.15
>
>
> >
> >
> --
> > Generating: '/home/uno/GNURADIO EJEMPLOS/Analizador.py'
> >
> > Executing: /usr/bin/python3 -u /home/uno/GNURADIO EJEMPLOS/Analizador.py
> >
> > /home/uno/GNURADIO EJEMPLOS/Analizador.py:168: DeprecationWarning:
> > distutils Version classes are deprecated. Use packaging.version instead.
> >   if StrictVersion("4.5.0") <= StrictVersion(Qt.qVersion()) <
> > StrictVersion("5.0.0"):
> > /home/uno/GNURADIO EJEMPLOS/Analizador.py:66: DeprecationWarning:
> > distutils Version classes are deprecated. Use packaging.version instead.
> >   if StrictVersion(Qt.qVersion()) < StrictVersion("5.0.0"):
> > [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100;
> > UHD_3.15.0.0-2build5
> > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> >
> mgmt_addr=192.168.10.42,type=e3xx,product=e310_sg3,serial=32132F0,name=ni-e31x-32132F0,fpga=n/a,claimed=False,addr=192.168.10.42
> > Traceback (most recent call last):
> >   File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 195, in 
> > main()
> >   File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 173, in main
> > tb = top_block_cls()
> >   File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 92, in __init__
> > self.uhd_usrp_source_0 = uhd.usrp_source(
> >   File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line
> > 125, in constructor_interceptor
> > return old_constructor(*args)
> >   File "/usr/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line
> > 2787, in make
> > return _uhd_swig.usrp_source_make(device_addr, stream_args,
> > issue_stream_cmd_on_start)
> > RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC
> > function 'get_num_xbars'
> >
> > >>> Done (return code 1)
> >
> ---
> >
> > does anyone know what could it be? i look up on google and everything
> > i found it was for the N3xx series and does not seems to work
> >
> > thanks for your time
>
>
>

E312 RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function 'get_num_xbars'

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone

I was fixing a problem with the mpm version, for some reason, I had
different versions both in my host and in the e312, i fixed that problem by
installing GNU-radio on the host but now when I try to use the e312 I get
this error.


--
Generating: '/home/uno/GNURADIO EJEMPLOS/Analizador.py'

Executing: /usr/bin/python3 -u /home/uno/GNURADIO EJEMPLOS/Analizador.py

/home/uno/GNURADIO EJEMPLOS/Analizador.py:168: DeprecationWarning:
distutils Version classes are deprecated. Use packaging.version instead.
  if StrictVersion("4.5.0") <= StrictVersion(Qt.qVersion()) <
StrictVersion("5.0.0"):
/home/uno/GNURADIO EJEMPLOS/Analizador.py:66: DeprecationWarning: distutils
Version classes are deprecated. Use packaging.version instead.
  if StrictVersion(Qt.qVersion()) < StrictVersion("5.0.0"):
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100;
UHD_3.15.0.0-2build5
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.10.42,type=e3xx,product=e310_sg3,serial=32132F0,name=ni-e31x-32132F0,fpga=n/a,claimed=False,addr=192.168.10.42
Traceback (most recent call last):
  File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 195, in 
main()
  File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 173, in main
tb = top_block_cls()
  File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 92, in __init__
self.uhd_usrp_source_0 = uhd.usrp_source(
  File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line 125,
in constructor_interceptor
return old_constructor(*args)
  File "/usr/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line
2787, in make
return _uhd_swig.usrp_source_make(device_addr, stream_args,
issue_stream_cmd_on_start)
RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function
'get_num_xbars'

>>> Done (return code 1)
---

does anyone know what could it be? i look up on google and everything i
found it was for the N3xx series and does not seems to work

thanks for your time

MPM major compat number mismatch ERROR

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi everyone.

i have been working with the USRP E312 in gnu-radio 3.8, but recently this
error appear:

RuntimeError: RuntimeError: MPM major compat number mismatch. Expected: 3.0
Actual: 4.2. Please update the version of MPM on your USRP device.

i dont been able to find a solution on google so i'm asking if someone know
what can it be

custom source block in python

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

hi everyone

I have been working on a block that takes measurements from a device
but when I connect it
to a QT gui time sink block, I only get the instantaneous measurement
(just a flat line)
and the shape of the curve over time is not recorded.

Does anyone know how to get the curve to be displayed and not just the
last instantaneous value?

i can attach the code that i have been working on if you need you see it

good day

Re: OOT import module error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

it's GNU-RADIO 3.8.5.0 my mistake

El mié, 22 mar 2023 a las 11:18, JORGE GONZALEZ ORELLANA (<
jorge.gonzale...@mail.pucv.cl>) escribió:

> Hello everyone
>
> I have been trying to create OOT modules following this guide
> https://wiki.gnuradio.org/index.php?title=Creating_Python_OOT_with_gr-modtool
>
> but when i try to run de custom module, i get this error:
> Traceback (most recent call last):
>   File "/home/uno/GNURADIO EJEMPLOS/testOOT.py", line 36, in 
> import customModule
> ModuleNotFoundError: No module named 'customModule'
>
> Any help you can give me would be appreciated.
>
> i'm working on GNU-RADIO 3.8.10 by the way
>
>

OOT import module error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone

I have been trying to create OOT modules following this guide
https://wiki.gnuradio.org/index.php?title=Creating_Python_OOT_with_gr-modtool

but when i try to run de custom module, i get this error:
Traceback (most recent call last):
  File "/home/uno/GNURADIO EJEMPLOS/testOOT.py", line 36, in 
import customModule
ModuleNotFoundError: No module named 'customModule'

Any help you can give me would be appreciated.

i'm working on GNU-RADIO 3.8.10 by the way

FFT Size and Signal & Vector Sources Amplitude Unit

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Dear All,

Changing only FFT size of the freq sink block during simulation drops
signal power drastically, screenshots are given in the attachments. I am
providing the pulse burst from the vector source as 6144 points (6 ones and
the rest of the points are zero). Since FFT sink blocks show the
average power of the points on freq domain, increasing FFT size would
increase the number of zeros in the buffer so power is reduced.

What do you think about this approach, is it ok? and there are fluctuations
in the 32k example, that's why it is thicker than 4k plot, what is the
reason for this?

Moreover, no unit is written in vector or signal sources amplitude
sections. Are units assumed as volts?

Regards,
dea

-- 


*Yasal Uyarı: MEF ÜNİVERSİTESİ bu mesajın içeriği ile ilgili hiçbir yasal 
sorumluluk taşımaz.*
*Legal Disclaimer: MEF UNIVERSITY does not accept any 
legal liability or responsibility for the content of this message.*

Re: gmp and mpir missing package when Cross-Compiling gr-ettus

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

yes exactly, but could it be possible that when i cross built gnuradio
something went wrong but didn't give notice about?

i also notice that the packege are install in me PC, so maybe the
environment variables are no set right

I'm new in this whole cross compiling process so i could (most likely) be
wrong

El mié., 26 de oct. de 2022 16:45, Marcus Müller  escribió:

> But the log you share is about building gr-ettus, which depends on an
> already cross-built
> GNU Radio, right?
>
> On 26.10.22 20:56, JORGE GONZALEZ ORELLANA wrote:
> > Could it be the cross-compiling of GNURADIO the problem then??
> >
> > I did this to cross compile GNURADIO as the guide says.
> >
> > El mié, 26 oct 2022 a las 13:02, Marcus Müller ( > <mailto:muel...@kit.edu>>) escribió:
> >
> > Hey Jorge,
> >
> > saw it :)
> > Still a bit confused by it, because:
> > while you only need *either* GMP *or* MPIR (basically, the same
> thing), that should be in
> > there as dependency of GNU Radio.
> >
> > Best,
> >Marcus
> >
> > On 26.10.22 16:15, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
> Open-Source Toolkit
> > for Software Radio wrote:
> >  > in case that you couldn't see what it says in the screenshot,
> here is it:
> >  >
> >  > {{{
> >  > uno@uno-laptop:~$  .
> >  >
> >
>  
> ~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
> >  > Your environment is misconfigured, you probably need to 'unset
> LD_LIBRARY_PATH'
> >  > but please check why this was set in the first place and that
> it's safe to unset.
> >  > The SDK will not operate correctly in most cases when
> LD_LIBRARY_PATH is set.
> >  > For more references see:
> >  >
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
> > <
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80>
> >  > <
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
> > <
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80>>
> >  > http://xahlee.info/UnixResource_dir/_/ldpath.html
> > <http://xahlee.info/UnixResource_dir/_/ldpath.html>
> >  > <http://xahlee.info/UnixResource_dir/_/ldpath.html
> > <http://xahlee.info/UnixResource_dir/_/ldpath.html>>
> >  > uno@uno-laptop:~$ ^C
> >  > uno@uno-laptop:~$ unset LD_LIBRARY_PATH
> >  > uno@uno-laptop:~$  .
> >  >
> >
>  
> ~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
> >  > uno@uno-laptop:~$ which cmake
> >  >
> >
>  
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/x86_64-oesdk-linux/usr/bin/cmake
> >  > uno@uno-laptop:~$ echo $CC
> >  > arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
> -mcpu=cortex-a9
> >  >
> >
>  
> --sysroot=/home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi
> >  > uno@uno-laptop:~$ gnuradio --version
> >  > bash: gnuradio: orden no encontrada
> >  > uno@uno-laptop:~$ gnuradio-config-info --version
> >  > 3.8.5.0
> >  > uno@uno-laptop:~$ cd ~/rfnoc/src/gr-ettus/build-arm
> >  > uno@uno-laptop:~/rfnoc/src/gr-ettus/build-arm$ cmake
> >  >
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> >  > -DCMAKE_INSTALL_PREFIX=/usr ..
> >  > -- Build type not specified: defaulting to release.
> >  > -- Checking for module 'gmp'
> >  > --   No package 'gmp' found
> >  > -- Checking for module 'mpir >= 3.0'
> >  > --   No package 'mpir' found
> >  > -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY
> MPIR_INCLUDE_DIR)
> >  > -- User set python executable
> >  >
> >
>  
> /__w/83/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gnuradio/3.8.3.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3
> >  > CMake Error at
> >  >
> >
>  
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/gnuradio/GrPython.cmake:40
> (if):
> >  >if given arguments:
> >  >
> >

Re: gmp and mpir missing package when Cross-Compiling gr-ettus

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Could it be the cross-compiling of GNURADIO the problem then??

I did this to cross compile GNURADIO as the guide says.

El mié, 26 oct 2022 a las 13:02, Marcus Müller () escribió:

> Hey Jorge,
>
> saw it :)
> Still a bit confused by it, because:
> while you only need *either* GMP *or* MPIR (basically, the same thing),
> that should be in
> there as dependency of GNU Radio.
>
> Best,
>   Marcus
>
> On 26.10.22 16:15, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
> Open-Source Toolkit
> for Software Radio wrote:
> > in case that you couldn't see what it says in the screenshot, here is it:
> >
> > {{{
> > uno@uno-laptop:~$  .
> >
> ~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
> > Your environment is misconfigured, you probably need to 'unset
> LD_LIBRARY_PATH'
> > but please check why this was set in the first place and that it's safe
> to unset.
> > The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is
> set.
> > For more references see:
> > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
> > <http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
> >
> > http://xahlee.info/UnixResource_dir/_/ldpath.html
> > <http://xahlee.info/UnixResource_dir/_/ldpath.html>
> > uno@uno-laptop:~$ ^C
> > uno@uno-laptop:~$ unset LD_LIBRARY_PATH
> > uno@uno-laptop:~$  .
> >
> ~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
> > uno@uno-laptop:~$ which cmake
> >
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/x86_64-oesdk-linux/usr/bin/cmake
> > uno@uno-laptop:~$ echo $CC
> > arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
> -mcpu=cortex-a9
> >
> --sysroot=/home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi
> > uno@uno-laptop:~$ gnuradio --version
> > bash: gnuradio: orden no encontrada
> > uno@uno-laptop:~$ gnuradio-config-info --version
> > 3.8.5.0
> > uno@uno-laptop:~$ cd ~/rfnoc/src/gr-ettus/build-arm
> > uno@uno-laptop:~/rfnoc/src/gr-ettus/build-arm$ cmake
> >
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>
> > -DCMAKE_INSTALL_PREFIX=/usr ..
> > -- Build type not specified: defaulting to release.
> > -- Checking for module 'gmp'
> > --   No package 'gmp' found
> > -- Checking for module 'mpir >= 3.0'
> > --   No package 'mpir' found
> > -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY
> MPIR_INCLUDE_DIR)
> > -- User set python executable
> >
> /__w/83/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gnuradio/3.8.3.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3
> > CMake Error at
> >
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/gnuradio/GrPython.cmake:40
> (if):
> >if given arguments:
> >
> >  "VERSION_EQUAL" "3"
> >
> >Unknown arguments specified
> > Call Stack (most recent call first):
> >
> >
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/gnuradio/GnuradioConfig.cmake:51
> (include)
> >CMakeLists.txt:59 (find_package)
> >
> >
> > -- Configuring incomplete, errors occurred!
> > See also
> "/home/uno/rfnoc/src/gr-ettus/build-arm/CMakeFiles/CMakeOutput.log".
> > See also
> "/home/uno/rfnoc/src/gr-ettus/build-arm/CMakeFiles/CMakeError.log".
> > uno@uno-laptop:~/rfnoc/src/gr-ettus/build-arm$
> >
> > }}}
> >
> > this was the SDK that i download:
> >
> > {{{
> > wget
> >
> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.2.0.1/e3xx_e310_sdk_default-v4.2.0.1.zip
> <
> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.2.0.1/e3xx_e310_sdk_default-v4.2.0.1.zip
> >
> > }}}
> >
> > It is different from the one in the guide I'm following.
> >
> > {{{
> >
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Cross-Compiling_gr-ettus
> <
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Cross-Compiling_gr-ettus
> >
> > }}}
> >
> >
> > thanks for your time
> >
> > El mar, 25 oct 2022 a las 17:07, Marcus Müller ( > 

Re: gmp and mpir missing package when Cross-Compiling gr-ettus

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

in case that you couldn't see what it says in the screenshot, here is it:

{{{
uno@uno-laptop:~$  .
~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
Your environment is misconfigured, you probably need to 'unset
LD_LIBRARY_PATH'
but please check why this was set in the first place and that it's safe to
unset.
The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is
set.
For more references see:
  http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
  http://xahlee.info/UnixResource_dir/_/ldpath.html
uno@uno-laptop:~$ ^C
uno@uno-laptop:~$ unset LD_LIBRARY_PATH
uno@uno-laptop:~$  .
~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
uno@uno-laptop:~$ which cmake
/home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/x86_64-oesdk-linux/usr/bin/cmake
uno@uno-laptop:~$ echo $CC
arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9
--sysroot=/home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi
uno@uno-laptop:~$ gnuradio --version
bash: gnuradio: orden no encontrada
uno@uno-laptop:~$ gnuradio-config-info --version
3.8.5.0
uno@uno-laptop:~$ cd ~/rfnoc/src/gr-ettus/build-arm
uno@uno-laptop:~/rfnoc/src/gr-ettus/build-arm$ cmake
-DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr ..
-- Build type not specified: defaulting to release.
-- Checking for module 'gmp'
--   No package 'gmp' found
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY
MPIR_INCLUDE_DIR)
-- User set python executable
/__w/83/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gnuradio/3.8.3.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3
CMake Error at
/home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/gnuradio/GrPython.cmake:40
(if):
  if given arguments:

"VERSION_EQUAL" "3"

  Unknown arguments specified
Call Stack (most recent call first):

/home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/gnuradio/GnuradioConfig.cmake:51
(include)
  CMakeLists.txt:59 (find_package)


-- Configuring incomplete, errors occurred!
See also
"/home/uno/rfnoc/src/gr-ettus/build-arm/CMakeFiles/CMakeOutput.log".
See also "/home/uno/rfnoc/src/gr-ettus/build-arm/CMakeFiles/CMakeError.log".
uno@uno-laptop:~/rfnoc/src/gr-ettus/build-arm$

}}}

this was the SDK that i download:

{{{
wget
https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.2.0.1/e3xx_e310_sdk_default-v4.2.0.1.zip
}}}

It is different from the one in the guide I'm following.

{{{
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Cross-Compiling_gr-ettus
}}}


thanks for your time

El mar, 25 oct 2022 a las 17:07, Marcus Müller ()
escribió:

> Don't worry at all :) I'm happy we're having this conversation!
>
> On 25.10.22 21:33, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
> Open-Source Toolkit
> for Software Radio wrote:
> > sorry i reply to you directly before.
> > here is the text from the screenshot
> >
> > {{{
> > uno@uno-laptop:~$  .
> >
> ~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
> > Your environment is misconfigured, you probably need to 'unset
> LD_LIBRARY_PATH'
> > but please check why this was set in the first place and that it's safe
> to unset.
> > The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is
> set.
> > For more references see:
> > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
> > <http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
> >
> > http://xahlee.info/UnixResource_dir/_/ldpath.html
> > <http://xahlee.info/UnixResource_dir/_/ldpath.html>
> > uno@uno-laptop:~$ ^C
> > uno@uno-laptop:~$ unset LD_LIBRARY_PATH
> > uno@uno-laptop:~$  .
> >
> ~/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/environment-setup-cortexa9t2hf-neon-oe-linux-gnueabi
> > uno@uno-laptop:~$ which cmake
> >
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/x86_64-oesdk-linux/usr/bin/cmake
> > uno@uno-laptop:~$ echo $CC
> > arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
> -mcpu=cortex-a9
> >
> --sysroot=/home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi
> > uno@uno-laptop:~$ gnuradio --versi

Re: gmp and mpir missing package when Cross-Compiling gr-ettus

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

king for module 'mpir >= 3.0'
> --   No package 'mpir' found
> -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY
> MPIR_INCLUDE_DIR)
> -- User set python executable
> /__w/83/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gnuradio/3.8.3.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3
> CMake Error at
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/gnuradio/GrPython.cmake:40
> (if):
>   if given arguments:
>
> "VERSION_EQUAL" "3"
>
>   Unknown arguments specified
> Call Stack (most recent call first):
>
> /home/uno/rfnoc/src/e3xx_e310_sdk_default-v4.2.0.1/OE_SDK/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/gnuradio/GnuradioConfig.cmake:51
> (include)
>   CMakeLists.txt:59 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/home/uno/rfnoc/src/gr-ettus/build-arm/CMakeFiles/CMakeOutput.log".
> See also
> "/home/uno/rfnoc/src/gr-ettus/build-arm/CMakeFiles/CMakeError.log".
> uno@uno-laptop:~/rfnoc/src/gr-ettus/build-arm$
> }}}
>
> El mar, 25 oct 2022 a las 14:14, Marcus Müller ()
> escribió:
>
>> Hi Jorge,
>>
>> I sadly can't read your screenshot. Would you mind Copy and Pasting the
>> text?
>> GMP and MPIR are the same thing. You only need one of them, not both!
>>
>> Best regards,
>> Marcus
>>
>>
>> On 25.10.22 18:57, Marcus D. Leech wrote:
>> > On 2022-10-25 12:17, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
>> Open-Source Toolkit
>> > for Software Radio wrote:
>> >> hi, i'm trying to install a usrp E312 using the follow guide:
>> >>
>> >> {{{
>> >>
>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Cross-Compiling_gr-ettus
>> >> }}}
>> >>
>> >> when i get to the cross-compiling gr-ettus step i get this error:
>> >>
>> >> image.png
>> >>
>> >> I make sure to set the environment correctly to use the SDK, and as
>> far as i know, the
>> >> gmp and mpir package are installed, so if someone can help me, i will
>> appreciate it a lot.
>> >>
>> >> thanks for your time
>> >>
>> >> JGO
>> > Are those two packages installed into your *HOST* environment or your
>> *CROSS DEV*
>> > environment?
>> >
>> >
>>
>

Cross-Compiling UHD Cmake version error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi, i'm trying to Cross-Compiling UHD a USRP E312 following this guide

but
i get a cmake version error message, the problem is that i have the 3.22.1
version.

Please can someone help me with this problem?

Dimensions parameter in Chunks to Symbols bloc

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
Can someone explain to me what is the purpose of Dimension parameter in the
Chunks to Symbols block? I was trying to use it as Pi/2-BPSK modulator but
it can't work in that mode.
Thanks in advance

-- 

Marcin Puchlik

Re: Adalm Pluto's Generic Blocks in GNU Radio

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello,
What do you mean by saying 'PLL randomization' ? Any web link will also do.
I am just curious.
Marcin

pon., 8 sie 2022 o 13:19 DİREN ERDEM AYDIN via GNU Radio, the Free &
Open-Source Toolkit for Software Radio 
napisał(a):

> Dear Users,
>
> I have a flow graph that is given in the figure. I am using generic pluto
> blocks to avoid PLL randomization in each frequency update. In the given
> received signal graph 800 - 900 MHz bandwidth is scanned by 20 MHz steps.
> As you can see, the acquired signal form is changed in each step.
> Therefore, I may say that PLLs are updated even if I have used generic
> blocks.
>
> What went wrong in this particular case? Is there a way that I can
> maintain the received signal form through a certain band?
>
> Regards,
>
> dea
>

Adalm Pluto's Generic Blocks in GNU Radio

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Dear Users,

I have a flow graph that is given in the figure. I am using generic pluto
blocks to avoid PLL randomization in each frequency update. In the given
received signal graph 800 - 900 MHz bandwidth is scanned by 20 MHz steps.
As you can see, the acquired signal form is changed in each step.
Therefore, I may say that PLLs are updated even if I have used generic
blocks.

What went wrong in this particular case? Is there a way that I can maintain
the received signal form through a certain band?

Regards,

dea

Re: Is there any way to tell scheduler, that our block needs certain amount of items on input?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hey,
Yes, use that function:
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a63d67fd758b70c6f2d7b7d4edcec53b3

pt., 5 sie 2022 o 13:44 Nikoloz Glonti  napisał(a):

> Dear Gnuradio community,
>
> Is there ability to tell scheduler to call work functions only when
> ninput_items will have value I set manually in constructor?
>
> thanks in advance!
>
> Niko
>
>
>

Re: Modulate Vector block and double filtration

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Marcus,
Clear for me now, thank you very much!
Have a good day,
Marcin

czw., 4 sie 2022 o 13:38 Marcus Müller  napisał(a):

> Hi Marcin,
>
> well, that flow graph only serves the purpose of pre-modulating things,
> e.g. for preamble
> correlation, I'd speculate that's for when you want to e.g. simulate a
> channel impulse
> response, or some external band-limiting filtering on your already
> pulse-shaped signal.
>
> However, you're right, neither in the GRC examples nor in any test cases
> we have do we
> make use of that taps vector (other than `[1]` as the perfect channel).
>
> Cheers,
> Marcus
>
> On 04.08.22 09:43, Marcin Puchlik via GNU Radio, the Free & Open-Source
> Toolkit for
> Software Radio wrote:
> > Hello Community,
> > Recently I investigated Modulate Vector
> > <https://wiki.gnuradio.org/index.php?title=Modulate_Vector> block and
> my observations are
> > that this block has two filtering stages - firstly in the modulator (RRC
> filter) and
> > secondly in itself (user providing the filter taps). The simple scheme
> of operation looks
> > like in the below picture.
> > So the question is: what is the purpose of the filter in
> modulate_vector_bc
> > <
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc
> > function?
> > Is this a bug or is there a reason for this?
> > Modulate vector question.png
> > --
> > BR,
> >
> > Marcin Puchlik
> >
> >
>
>

Modulate Vector block and double filtration

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello Community,
Recently I investigated Modulate Vector
 block and my
observations are that this block has two filtering stages - firstly in the
modulator (RRC filter) and secondly in itself (user providing the filter
taps). The simple scheme of operation looks like in the below picture.
So the question is: what is the purpose of the filter in modulate_vector_bc

 function?
Is this a bug or is there a reason for this?
[image: Modulate vector question.png]
--
BR,

Marcin Puchlik

Re: Controlling flowgraph

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Vamshi,
I just gave you an example in the last message. To get more information
about the stream tags, please check out the GNU Radio wiki website
https://wiki.gnuradio.org/index.php/Stream_Tags
Marcin

pon., 6 cze 2022 o 15:46 Vamshi Sainath Gavani 
napisał(a):

> can you give me an example of what the tags have to be?
> also, take a look at how I'm implementing the example you provided in my
> flowgraph.
>
>
> On Mon, Jun 6, 2022 at 6:31 PM Marcin Puchlik 
> wrote:
>
>> Hey,
>> So lets say that your hardware expects you to send samples at 1 MSPS rate
>> (1 million samples per second). Lets also assume that your bursts
>> always have 100k (one hundred thousand) samples. Let's also assume that you
>> want to send you bursts at 1 second period. What you have to do is to add
>> 900k additional null or noise samples after your burst samples to satisfy
>> the hardware. You can do that by using *Tagged Stream Mux* block where
>> you apply two tagged streams: burst stream (burst samples on the image) and
>> null stream (null samples on the image). Remember that both streams have to
>> be tagged.
>> I hope that helped
>> [image: image.png]
>>
>> pon., 6 cze 2022 o 13:50 Vamshi Sainath Gavani 
>> napisał(a):
>>
>>> Hey Marcin,
>>> Can you explain to me in short how to send null samples to the soapy
>>> sink or a link maybe? Sorry, I'm new to the GNU environment.
>>> Thanks.
>>>
>>> On Mon, Jun 6, 2022 at 2:00 PM Marcin Puchlik 
>>> wrote:
>>>
 Vamshi,
 I don't think that HackRF One supports bursty transmission (like USRP
 UHD does). If you want to achieve a 3 seconds period bursty Tx you have to
 provide an adequate amount of 'null' samples between the transmission
 bursts to drive DAC. To verify that information I think you can ask on
 HackRF mailing list. I think that people there will provide you more
 reliable info.
 Best,
 Marcin

 pon., 6 cze 2022 o 10:12 Vamshi Sainath Gavani 
 napisał(a):

> So what I'm doing is transmitting with a HackRF One and when I run the
> flowgraph the transmission starts and frames are sent as bursts and
> between the bursts, the transmitter stays on and I would like to turn it
> off at tx_eob and turn on tx at tx_sob
> Below is the screenshot of the current flowgraph I'm implementing.
>
> On Mon, Jun 6, 2022 at 1:14 PM Marcin Puchlik <
> m.puch...@is-wireless.com> wrote:
>
>> Hi Vamshi,
>> First, what do you mean by turning off/on the transmitter?
>> Marcin
>>
>> pon., 6 cze 2022 o 09:14 Vamshi Sainath Gavani 
>> napisał(a):
>>
>>> Hello Folks,
>>>
>>> Here I'm implementing the transmission of LoRa Frames and I want to
>>> be able to stop the flowgraph(Stop Transmitting) between frames say the
>>> packet is set to transmit every 3s so at tx_eob turn off tx and tx_sob
>>> start tx.
>>> Below is my Flow graph code snippet can you let me know how I can
>>> turn off/on tx between the frames?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *def main(top_block_cls=lora_TX, options=None):tb =
>>> top_block_cls()def sig_handler(sig=None, frame=None):
>>> tb.stop()
>>>   tb.wait()sys.exit(0)signal.signal(signal.SIGINT,
>>> sig_handler)signal.signal(signal.SIGTERM, sig_handler)tb.start()
>>> try:input('Press Enter to quit: ')except EOFError:
>>> pass
>>>   tb.stop()tb.wait()if __name__ == '__main__':main()*
>>> Thanks and Regards,
>>> Sainath Vamshi
>>>
>>

Re: Controlling flowgraph

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Vamshi,
I don't think that HackRF One supports bursty transmission (like USRP UHD
does). If you want to achieve a 3 seconds period bursty Tx you have to
provide an adequate amount of 'null' samples between the transmission
bursts to drive DAC. To verify that information I think you can ask on
HackRF mailing list. I think that people there will provide you more
reliable info.
Best,
Marcin

pon., 6 cze 2022 o 10:12 Vamshi Sainath Gavani 
napisał(a):

> So what I'm doing is transmitting with a HackRF One and when I run the
> flowgraph the transmission starts and frames are sent as bursts and
> between the bursts, the transmitter stays on and I would like to turn it
> off at tx_eob and turn on tx at tx_sob
> Below is the screenshot of the current flowgraph I'm implementing.
>
> On Mon, Jun 6, 2022 at 1:14 PM Marcin Puchlik 
> wrote:
>
>> Hi Vamshi,
>> First, what do you mean by turning off/on the transmitter?
>> Marcin
>>
>> pon., 6 cze 2022 o 09:14 Vamshi Sainath Gavani 
>> napisał(a):
>>
>>> Hello Folks,
>>>
>>> Here I'm implementing the transmission of LoRa Frames and I want to be
>>> able to stop the flowgraph(Stop Transmitting) between frames say the packet
>>> is set to transmit every 3s so at tx_eob turn off tx and tx_sob start tx.
>>> Below is my Flow graph code snippet can you let me know how I can
>>> turn off/on tx between the frames?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *def main(top_block_cls=lora_TX, options=None):tb = top_block_cls()
>>>   def sig_handler(sig=None, frame=None):tb.stop()tb.wait()
>>>   sys.exit(0)signal.signal(signal.SIGINT, sig_handler)
>>> signal.signal(signal.SIGTERM, sig_handler)tb.start()try:
>>> input('Press Enter to quit: ')except EOFError:pass
>>> tb.stop()tb.wait()if __name__ == '__main__':main()*
>>> Thanks and Regards,
>>> Sainath Vamshi
>>>
>>

Re: Controlling flowgraph

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Vamshi,
First, what do you mean by turning off/on the transmitter?
Marcin

pon., 6 cze 2022 o 09:14 Vamshi Sainath Gavani 
napisał(a):

> Hello Folks,
>
> Here I'm implementing the transmission of LoRa Frames and I want to be
> able to stop the flowgraph(Stop Transmitting) between frames say the packet
> is set to transmit every 3s so at tx_eob turn off tx and tx_sob start tx.
> Below is my Flow graph code snippet can you let me know how I can
> turn off/on tx between the frames?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *def main(top_block_cls=lora_TX, options=None):tb = top_block_cls()
> def sig_handler(sig=None, frame=None):tb.stop()tb.wait()
> sys.exit(0)signal.signal(signal.SIGINT, sig_handler)
> signal.signal(signal.SIGTERM, sig_handler)tb.start()try:
> input('Press Enter to quit: ')except EOFError:pass
> tb.stop()tb.wait()if __name__ == '__main__':main()*
> Thanks and Regards,
> Sainath Vamshi
>

Re: Vector Block Sample Rate

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Diren
As for CPU load: the easiest way is to run *htop *or any other program to
check how much of resources are being consumed by the process that you are
running.
As for your last question regarding sample rate: There is no chance you
will provide samples at 61.44 MSPS to Pluto (USB interface limitations). Here
<https://plutosdr.org/adalm-pluto-performance-metrics/>you can find the
performance metrics. To understand more how sample rate impacts your
design, please read:
- https://wiki.gnuradio.org/index.php/Sample_Rate_Tutorial
-
https://wiki.gnuradio.org/index.php/FAQ#What_does_sample_rate_mean_in_GNU_Radio
?
Regards

niedz., 5 cze 2022 o 13:53 DİREN ERDEM AYDIN  napisał(a):

> Thanks for the response Fabian.
>
> Actually, there is no "actual" problem, the system is working properly.
>
> My question is related to what you said in your mail "*One exception here
> is for example your PlutoSDR Source/Sink - both will actually
> provide/require the sample rate you specify.*" In this case, I'm not sure
> Pluto Sink is provided with 61.44 M samples. Vector source outputs 6.144 k
> samples since LPF interpolation is 1 Pluto sink block receives that number.
>
> I think that the input sample rate is not related to sample rate
> parameter in the Pluto Sink block. It is related to the data transfer rate
> between AD9363 and FPGA.
>
> Regards,
> Diren
>
> On Sun, Jun 5, 2022 at 12:13 PM Fabian Schwartau 
> wrote:
>
>> Hi Diren,
>>
>> I am not exactly sure what your problem is.
>> What you should know: gnuradio does not inherently has any sample rate
>> (unlike Simulink for example). Each block receives samples, processes
>> them, and outputs the same number of samples as fast as it can (except
>> if the block is interpolating/decimating - which is not the case for you
>> LPF). Between the blocks are buffers, which buffer the samples until the
>> next block will process it. The sample rate you set in most blocks is
>> just to calculate stuff (like the filter response) based on other
>> frequency settings (like your cut-off frequency). One exception here is
>> for example your PlutoSDR Source/Sink - both will actually
>> provide/require the sample rate you specify.
>> So, as your LPF has an interpolation of 1, it does not interpolate and
>> will output the same number of samples it receives. Your vector source
>> will provide samples as fast as possible until some buffer is full and
>> it will then keep it full.
>> One problem might be that your CPU cannot keep up filtering the
>> 61.44MSPS, which is quite a bit. Try increasing the transition width of
>> the filter, which will reduce the filter order and thus the CPU load.
>>
>> Hope that helps,
>> Fabian
>>
>> Am 04.06.22 um 23:09 schrieb DİREN ERDEM AYDIN via GNU Radio, the Free &
>> Open-Source Toolkit for Software Radio:
>> > Hello All,
>> >
>> > I'm working with Adalm Pluto SDR, trying to transmit and receive a
>> > custom burst signal given in the figure. To create the signal I'm using
>> > a vector block that creates a pulse and then due to a low pass filter I
>> > can extract the desired waveform. Flowgraph is also added.
>> >
>> > As far as I know, input/output sample rates of connected blocks should
>> > be matched. However, I'm providing 10k fewer samples to LPF because of
>> > the high sample rate of pluto, 61.44 M. When I tried to increase the
>> > samples in the vector source to Mega ranges frequency response of the
>> > signal drops drastically. I have also tried to use interpolation in
>> > between vector block and LPF, but it doesn't work either.
>> >
>> > My question is the LPF block normalizes the input sample rate to 61.44
>> > M? The whole system works OK but this thing stays unclear for me. Thank
>> you.
>> >
>> > Regards,
>> > Diren
>>
>>
>>

Re: Vector Block Sample Rate

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Daren and Fabian,
Fabian: Daren is using cyclic transmission so starting from the moment when
the Pluto hardware buffer is full it repeats the samples over and over
again. I think that CPU load has nothing to do here since as I said,
samples are not being calculated in a real time manner.
Marcin

niedz., 5 cze 2022 o 11:14 Fabian Schwartau  napisał(a):

> Hi Diren,
>
> I am not exactly sure what your problem is.
> What you should know: gnuradio does not inherently has any sample rate
> (unlike Simulink for example). Each block receives samples, processes
> them, and outputs the same number of samples as fast as it can (except
> if the block is interpolating/decimating - which is not the case for you
> LPF). Between the blocks are buffers, which buffer the samples until the
> next block will process it. The sample rate you set in most blocks is
> just to calculate stuff (like the filter response) based on other
> frequency settings (like your cut-off frequency). One exception here is
> for example your PlutoSDR Source/Sink - both will actually
> provide/require the sample rate you specify.
> So, as your LPF has an interpolation of 1, it does not interpolate and
> will output the same number of samples it receives. Your vector source
> will provide samples as fast as possible until some buffer is full and
> it will then keep it full.
> One problem might be that your CPU cannot keep up filtering the
> 61.44MSPS, which is quite a bit. Try increasing the transition width of
> the filter, which will reduce the filter order and thus the CPU load.
>
> Hope that helps,
> Fabian
>
> Am 04.06.22 um 23:09 schrieb DİREN ERDEM AYDIN via GNU Radio, the Free &
> Open-Source Toolkit for Software Radio:
> > Hello All,
> >
> > I'm working with Adalm Pluto SDR, trying to transmit and receive a
> > custom burst signal given in the figure. To create the signal I'm using
> > a vector block that creates a pulse and then due to a low pass filter I
> > can extract the desired waveform. Flowgraph is also added.
> >
> > As far as I know, input/output sample rates of connected blocks should
> > be matched. However, I'm providing 10k fewer samples to LPF because of
> > the high sample rate of pluto, 61.44 M. When I tried to increase the
> > samples in the vector source to Mega ranges frequency response of the
> > signal drops drastically. I have also tried to use interpolation in
> > between vector block and LPF, but it doesn't work either.
> >
> > My question is the LPF block normalizes the input sample rate to 61.44
> > M? The whole system works OK but this thing stays unclear for me. Thank
> you.
> >
> > Regards,
> > Diren
>
>
>

OOT unit testing: ImportError: cannot import name '' GNU Radio 3.9.3

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello,
I know that this issue was posted in the past but I haven't found any
information about if it was fixed in any of the 3.9.x versions of GNU
Radio. So the problem is with importing my custom module while running unit
tests. While running *ctest -VV -R square *I got the output:

*UpdateCTestConfiguration  from
:/home/ubuntu/prefixes/gnuradio39/OOTs/gr-hornet/build/DartConfiguration.tcl*










*UpdateCTestConfiguration  from
:/home/ubuntu/prefixes/gnuradio39/OOTs/gr-hornet/build/DartConfiguration.tclTest
project /home/ubuntu/prefixes/gnuradio39/OOTs/gr-hornet/buildConstructing a
list of testsDone constructing a list of testsUpdating test list for
fixturesAdded 0 tests to meet fixture requirementsChecking test dependency
graph...Checking test dependency graph endtest 4Start 4: qa_square_ff*














*4: Test command: /usr/bin/sh
"/home/ubuntu/prefixes/gnuradio39/OOTs/gr-hornet/build/python/qa_square_ff_test.sh"4:
Test timeout computed to be: 10004: Traceback (most recent call
last):4:   File
"/home/ubuntu/prefixes/gnuradio39/OOTs/gr-hornet/python/qa_square_ff.py",
line 12, in 4: from hornet import square_ff4: ImportError:
cannot import name 'square_ff' from 'hornet' (unknown location)4: 4: During
handling of the above exception, another exception occurred:4: 4: Traceback
(most recent call last):4:   File
"/home/ubuntu/prefixes/gnuradio39/OOTs/gr-hornet/python/qa_square_ff.py",
line 18, in 4: from hornet import square_ff4: ImportError:
cannot import name 'square_ff' from 'hornet' (unknown location)1/1 Test #4:
qa_square_ff .***Failed0.28 sec*

*0% tests passed, 1 tests failed out of 1*

*Total Test time (real) =   0.29 sec*


*The following tests FAILED:  4 - qa_square_ff (Failed)*

Anyone know how to solve that issue? Or does anyone know which version of
GNU Radio has a fix for that issue? I am kinda forced to use 3.9.x version
in my dev work.

Re: Re: Performance counters in GNU Radio

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

P.S.
Ryan: You were right! It's enabled by default

śr., 11 maj 2022 o 11:47 Marcin Puchlik 
napisał(a):

> Jim,
> Thank you very much. Indeed, enabling this feature in the config.conf
> helped
> Cheers!
>
> wt., 10 maj 2022 o 20:13 Jim Melton  napisał(a):
>
>> You need:
>>
>> [PerfCounters]
>> on = True
>>
>> in $HOME/.gnuradio/config.conf
>>
>> ---
>> Jim Melton
>>
>>
>>
>>
>>
>>
>> -Original Message-
>> From: Discuss-gnuradio > sncorp@gnu.org> On Behalf Of Ryan Volz
>> Sent: Tuesday, May 10, 2022 12:08
>> To: Marcin Puchlik ; GNURadio Discussion List
>> 
>> Subject: [EXTERNAL] Re: Performance counters in GNU Radio
>>
>> Hi Marcin,
>>
>> On 5/10/22 9:40 AM, Marcin Puchlik via GNU Radio, the Free & Open-Source
>> Toolkit for Software Radio wrote:
>> > Hi,
>> > I am using GNU Radio which I installed from binary (3.10.1.1). I am
>> > creating my own OOT and I would like to use /Performance Counters/
>> > features like pc_nproduced() function. Here
>> > <https://wiki.gnuradio.org/index.php/Performance_Counters> I found
>> > that they are not enabled by default and I saw that this function
>> > returns 0.0 . Does it force me to install GNU Radio from source and
>> > during compile time enable the /Performance Counters? / Thanks
>> >
>>
>> Despite what the wiki page says, it appears that performance counters are
>> ENABLED during build by default:
>>
>>
>> https://github.com/gnuradio/gnuradio/blob/c6e8dae799b7dc0fecff1081fdd9ef4e405bfde4/CMakeLists.txt#L168
>>
>> So it is likely that your binaries have been built with them enabled, and
>> that you just need to enable them at runtime through your configuration. I
>> don't have any experience with that, unfortunately.
>>
>> Cheers,
>> Ryan
>>
>>
>> CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are
>> confidential, may contain proprietary, protected, or export controlled
>> information, and are intended for the use of the intended recipients only.
>> Any review, reliance, distribution, disclosure, or forwarding of this email
>> and/or attachments outside of Sierra Nevada Corporation (SNC) without
>> express written approval of the sender, except to the extent required to
>> further properly approved SNC business purposes, is strictly prohibited. If
>> you are not the intended recipient of this email, please notify the sender
>> immediately, and delete all copies without reading, printing, or saving in
>> any manner. --- Thank You.
>>
>

Re: Re: Performance counters in GNU Radio

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Jim,
Thank you very much. Indeed, enabling this feature in the config.conf helped
Cheers!

wt., 10 maj 2022 o 20:13 Jim Melton  napisał(a):

> You need:
>
> [PerfCounters]
> on = True
>
> in $HOME/.gnuradio/config.conf
>
> ---
> Jim Melton
>
>
>
>
>
>
> -Original Message-
> From: Discuss-gnuradio  sncorp@gnu.org> On Behalf Of Ryan Volz
> Sent: Tuesday, May 10, 2022 12:08
> To: Marcin Puchlik ; GNURadio Discussion List <
> discuss-gnuradio@gnu.org>
> Subject: [EXTERNAL] Re: Performance counters in GNU Radio
>
> Hi Marcin,
>
> On 5/10/22 9:40 AM, Marcin Puchlik via GNU Radio, the Free & Open-Source
> Toolkit for Software Radio wrote:
> > Hi,
> > I am using GNU Radio which I installed from binary (3.10.1.1). I am
> > creating my own OOT and I would like to use /Performance Counters/
> > features like pc_nproduced() function. Here
> > <https://wiki.gnuradio.org/index.php/Performance_Counters> I found
> > that they are not enabled by default and I saw that this function
> > returns 0.0 . Does it force me to install GNU Radio from source and
> > during compile time enable the /Performance Counters? / Thanks
> >
>
> Despite what the wiki page says, it appears that performance counters are
> ENABLED during build by default:
>
>
> https://github.com/gnuradio/gnuradio/blob/c6e8dae799b7dc0fecff1081fdd9ef4e405bfde4/CMakeLists.txt#L168
>
> So it is likely that your binaries have been built with them enabled, and
> that you just need to enable them at runtime through your configuration. I
> don't have any experience with that, unfortunately.
>
> Cheers,
> Ryan
>
>
> CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are
> confidential, may contain proprietary, protected, or export controlled
> information, and are intended for the use of the intended recipients only.
> Any review, reliance, distribution, disclosure, or forwarding of this email
> and/or attachments outside of Sierra Nevada Corporation (SNC) without
> express written approval of the sender, except to the extent required to
> further properly approved SNC business purposes, is strictly prohibited. If
> you are not the intended recipient of this email, please notify the sender
> immediately, and delete all copies without reading, printing, or saving in
> any manner. --- Thank You.
>

Performance counters in GNU Radio

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
I am using GNU Radio which I installed from binary (3.10.1.1). I am
creating my own OOT and I would like to use *Performance Counters* features
like pc_nproduced() function. Here
 I found that
they are not enabled by default and I saw that this function returns 0.0 .
Does it force me to install GNU Radio from source and during compile time
enable the *Performance Counters? *
Thanks

Re: Reconfiguring the flowgraph after processing N samples

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Paul,
But there is a requirement that switching has to be done after N samples,
how to control that from the external app?

On Thu, May 5, 2022, 17:25 Paul Atreides  wrote:

> You can also use a selector block and switch the input at runtime from a
> separate application if you don’t want to incur the downtime of locking,
> reconfiguring and unlocking.
>
> 
>
> On May 5, 2022, at 06:11, Marcin Puchlik via GNU Radio, the Free &
> Open-Source Toolkit for Software Radio  wrote:
>
> 
> Hello,
> To WarMonkey: I know how to make OOT and it seems that you don't
> understand my question.
> To Gregory: That's a brilliant idea. I just need a counter and based on
> that just switch the branch in my flowgraph. I am going to try this.
> Thanks!
>
> śr., 4 maj 2022 o 19:03 Gregory Warnes  napisał(a):
>
>> How about configuring two parallel data flows, with a switch that diverts
>> from one to the other after N samples?
>>
>> —
>> Gregory R. Warnes, Ph.D.
>> (Sent from a mobile device, please excuse any typographical issues.)
>>
>> On May 4, 2022, at 11:32 AM, Marcin Puchlik via GNU Radio, the Free &
>> Open-Source Toolkit for Software Radio  wrote:
>>
>> 
>> Hello,
>> As far as I know, the "Head" block finishes the operation of a flowgraph
>> which I don't want to do. What OOT has to do? Any details?
>>
>>
>> śr., 4 maj 2022 o 17:21 WarMonkey  napisał(a):
>>
>>> use "Head" N samples, or create your own OOT module.
>>>
>>> Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for
>>> Software Radio  于2022年5月4日周三 22:11写道：
>>>
>>>> Hello Everyone,
>>>> I want to reconfigure my flowgraph after receiving N samples. I am
>>>> following this example:
>>>> https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure
>>>> Instead of using *sleep(0.1) *I want my flowgraph to lock after
>>>> consumption of N samples. Then I want to rearrange the flowgraph blocks. Do
>>>> you have any idea how to do this?
>>>> My guess is that I can use *Performance Counters *like *nproduced *for
>>>> the first block in my flowgraph and base on that, call *lock() *function
>>>> on my *top_block()*. What do you think?
>>>> Cheers
>>>> Marcin
>>>>
>>>>
>>>>

Re: Reconfiguring the flowgraph after processing N samples

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello,
To WarMonkey: I know how to make OOT and it seems that you don't understand
my question.
To Gregory: That's a brilliant idea. I just need a counter and based on
that just switch the branch in my flowgraph. I am going to try this.
Thanks!

śr., 4 maj 2022 o 19:03 Gregory Warnes  napisał(a):

> How about configuring two parallel data flows, with a switch that diverts
> from one to the other after N samples?
>
> —
> Gregory R. Warnes, Ph.D.
> (Sent from a mobile device, please excuse any typographical issues.)
>
> On May 4, 2022, at 11:32 AM, Marcin Puchlik via GNU Radio, the Free &
> Open-Source Toolkit for Software Radio  wrote:
>
> 
> Hello,
> As far as I know, the "Head" block finishes the operation of a flowgraph
> which I don't want to do. What OOT has to do? Any details?
>
>
> śr., 4 maj 2022 o 17:21 WarMonkey  napisał(a):
>
>> use "Head" N samples, or create your own OOT module.
>>
>> Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for Software
>> Radio  于2022年5月4日周三 22:11写道：
>>
>>> Hello Everyone,
>>> I want to reconfigure my flowgraph after receiving N samples. I am
>>> following this example:
>>> https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure
>>> Instead of using *sleep(0.1) *I want my flowgraph to lock after
>>> consumption of N samples. Then I want to rearrange the flowgraph blocks. Do
>>> you have any idea how to do this?
>>> My guess is that I can use *Performance Counters *like *nproduced *for
>>> the first block in my flowgraph and base on that, call *lock() *function
>>> on my *top_block()*. What do you think?
>>> Cheers
>>> Marcin
>>>
>>>
>>>

Re: Reconfiguring the flowgraph after processing N samples

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello,
As far as I know, the "Head" block finishes the operation of a flowgraph
which I don't want to do. What OOT has to do? Any details?


śr., 4 maj 2022 o 17:21 WarMonkey  napisał(a):

> use "Head" N samples, or create your own OOT module.
>
> Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for Software
> Radio  于2022年5月4日周三 22:11写道：
>
>> Hello Everyone,
>> I want to reconfigure my flowgraph after receiving N samples. I am
>> following this example:
>> https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure
>> Instead of using *sleep(0.1) *I want my flowgraph to lock after
>> consumption of N samples. Then I want to rearrange the flowgraph blocks. Do
>> you have any idea how to do this?
>> My guess is that I can use *Performance Counters *like *nproduced *for
>> the first block in my flowgraph and base on that, call *lock() *function
>> on my *top_block()*. What do you think?
>> Cheers
>> Marcin
>>
>>
>>

Reconfiguring the flowgraph after processing N samples

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello Everyone,
I want to reconfigure my flowgraph after receiving N samples. I am
following this example:
https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure
Instead of using *sleep(0.1) *I want my flowgraph to lock after consumption
of N samples. Then I want to rearrange the flowgraph blocks. Do you have
any idea how to do this?
My guess is that I can use *Performance Counters *like *nproduced *for the
first block in my flowgraph and base on that, call *lock() *function on my
*top_block()*. What do you think?
Cheers
Marcin

Re: Interpolating FIR Filter - sample delay

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Daniel,
Thank you for your detailed response. Indeed, that's what I do now is to
set the Sample Delay equal to: filter group delay divided by an
interpolation factor. One thing I don't understand in your response
is: *"However,
I don't think this is a very good solution, because it forces*


*the output delay to be a multiple of the interpolation factor.
Typicallywe'd like to set the output delay to the FIR group delay, which
is(len(taps)-1)/2. This need not be a multiple of the interpolation
factor."*

But that is the current situation, to compensate for the improper delay
introduced by the FIR filter you have to divide the *Sample Delay *by the
interpolation factor - that's how it looks right now.
Your proposal is correct IMO, and works but current behavior of the block
is misleading and at least should be noted in the documentation or wiki.
Cheers,
Marcin

niedz., 24 kwi 2022 o 10:45 Daniel Estévez  napisał(a):

> El 22/4/22 a las 11:32, Marcin Puchlik via GNU Radio, the Free &
> Open-Source Toolkit for Software Radio escribió:
> > Hello
> > I was playing with the Interpolating FIR Filter Block and noticed that
> > the mentioned filter delays tags not properly. What I mean is that when
> > the interpolation factor is different than 1, then the filter delays the
> > tags by the /Sample Delay * Interpolation factor/ value. In my opinion
> > this is not correct behavior. Group delay of the filter is constant and
> > the interpolation factor shouldn't affect the process of delaying the
> > tags. Below, I am attaching the plot and GRC flowgraph which demonstrate
> > the problem and where you can see the observed behavior.
> > Number of the taps in RRC filter used in the simulation: 41
> > Group delay: 20
> > Actual group delay: 40
> > What do you think?
>
> Hi Marcin,
>
> I've done a small flowgraph to test this and agree with what you've
> found. Looking at how this is handled in code, I see that the sample
> delay in the GRC block is used to call the declare_sample_delay() method
> of the block.
>
>
> https://github.com/gnuradio/gnuradio/blob/main/gr-filter/grc/filter_interp_fir_filter_xxx.block.yml#L46
>
> This sets the delay referred to the input:
>
>
> https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/lib/block.cc#L68
>
> Basically, delays for tags seem to be considered at the input always:
>
>
> https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/lib/buffer_reader.cc#L138
>
> So I can see why for an interpolator block you would get sample_delay *
> interpolation_factor at the output.
>
> A way to fix this would be to modify the GRC block to call
>
> self.${id}.declare_sample_delay(${samp_delay}//${interp})
>
> However, I don't think this is a very good solution, because it forces
> the output delay to be a multiple of the interpolation factor. Typically
> we'd like to set the output delay to the FIR group delay, which is
> (len(taps)-1)/2. This need not be a multiple of the interpolation factor.
>
> I think that the proper solution would let us set the output delay with
> a granularity of one output sample. It seems this would require more
> work. I'm not sure whether the tag propagation schemes already support
> this.
>
> Best,
> Daniel.
>

Interpolating FIR Filter - sample delay

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello
I was playing with the Interpolating FIR Filter Block and noticed that the
mentioned filter delays tags not properly. What I mean is that when the
interpolation factor is different than 1, then the filter delays the tags
by the *Sample Delay * Interpolation factor* value. In my opinion this is
not correct behavior. Group delay of the filter is constant and the
interpolation factor shouldn't affect the process of delaying the tags.
Below, I am attaching the plot and GRC flowgraph which demonstrate the
problem and where you can see the observed behavior.
Number of the taps in RRC filter used in the simulation: 41
Group delay: 20
Actual group delay: 40
What do you think?
[image: Rysunek bez nazwy.jpg]


filter_group_delay_compensation.grc
Description: Binary data

Re: Python problem..

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

David,
Your code is not available anymore.
What you want to achieve?
I don't understand your problem.
Marcin


On Sat, Mar 19, 2022, 12:49 tech k1ng  wrote:

> Hello Marcin,
>
> Thanks for getting back to me. Sorry for the last response!!
>
> I tried to do it another way using basic block, but this time just
> checking condition over thresh, and between other up and low. I tried to
> graph it and it doesn't seem to show anything. I got no errors. Any ideas
> what I may have done wrong?
>
> https://pastebin.com/w7uZyQjE
>
>
>
> tir. 15. mar. 2022 kl. 14:19 skrev Marcin Puchlik <
> m.puch...@is-wireless.com>:
>
>> Hi David,
>> Problem is in the line:
>> output_items[0] = outvec
>> There is a type mismatch here, you cannot write a list of tuples (outvec)
>> to the numpy array.
>> BR,
>> Marcin
>>
>>
>>
>>
>>
>> wt., 15 mar 2022 o 00:28 tech k1ng  napisał(a):
>>
>>> Hello again.
>>>
>>> Here is the python code: https://pastebin.com/waUMgRSD
>>>
>>> I patiently await your response. By the way, this is my first time using
>>> a mailing list:)
>>>
>>> Regards,
>>> David.
>>>
>>>
>>>
>>> tir. 15. mar. 2022 kl. 00:15 skrev tech k1ng :
>>>
 Hi there,

 This is my first mailing post, so please excuse me if there are any
 errors.

 I'm trying to make a block that gives me the bins with corresponding
 its energy ([bins, energy]) when over a thresh, so input vector is from
 "log power fft" block. With the output, I'm hoping to store it as a file
 for further use, or perhaps use it to visualize it. Marcus Müller has
 already proposed something similar while describing a technique to another
 person: here
 


 The python code is shown here: The output does not seem to represent it
 properly. I'm lost right now, and I'm not sure how to proceed. I've
 attempted to troubleshoot it and experiment with other things before coming
 here to ask for help.

 Thank you; I'm hoping that someone can check into this and give me some
 advice on what I can do.

 Best Regards,
 David

Re: Python problem..

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi David,
Problem is in the line:
output_items[0] = outvec
There is a type mismatch here, you cannot write a list of tuples (outvec)
to the numpy array.
BR,
Marcin





wt., 15 mar 2022 o 00:28 tech k1ng  napisał(a):

> Hello again.
>
> Here is the python code: https://pastebin.com/waUMgRSD
>
> I patiently await your response. By the way, this is my first time using a
> mailing list:)
>
> Regards,
> David.
>
>
>
> tir. 15. mar. 2022 kl. 00:15 skrev tech k1ng :
>
>> Hi there,
>>
>> This is my first mailing post, so please excuse me if there are any
>> errors.
>>
>> I'm trying to make a block that gives me the bins with corresponding its
>> energy ([bins, energy]) when over a thresh, so input vector is from "log
>> power fft" block. With the output, I'm hoping to store it as a file for
>> further use, or perhaps use it to visualize it. Marcus Müller has already
>> proposed something similar while describing a technique to another person:
>> here
>> 
>>
>>
>> The python code is shown here: The output does not seem to represent it
>> properly. I'm lost right now, and I'm not sure how to proceed. I've
>> attempted to troubleshoot it and experiment with other things before coming
>> here to ask for help.
>>
>> Thank you; I'm hoping that someone can check into this and give me some
>> advice on what I can do.
>>
>> Best Regards,
>> David
>>
>>
>>
>>
>>

Re: Is there a Gnuradio C++ function that is the equivalent of SciPy firls LP filter

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi George,
Can you describe in more detail what you are trying to achieve?
If your coefficients are going to be set just at the beginning while
starting the flowgraph, why don't you use SciPy or firdes from GNU Radio?
If you are interested in C++ library which provides you with some filtering
function you might be interested in liquidsdr :
https://liquidsdr.org/ especially here: https://liquidsdr.org/doc/firdes/
Does that help?
BR,

Marcin


pon., 28 lut 2022 o 22:27 George Edwards 
napisał(a):

> Hello GNURadio Community,
>
> I would like a Gnuradio C++ equivalent to SciPy's firls LP filter to find
> the filter coefficients for a C++ OOT block I am designing. Also, if there
> is a way to incorporate the SciPy firls filter package in a Gnuradio C++
> OOT, I am open to that.
>
> Thank you!
>
> Regards,
> George
>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi George,
You are welcome.

> Q1. If I write a line of code to extract the remez taps, say:
>lpfilter =
> gr::filter::pm_remez ( int  order,
> const std::vector< double > &  bands,
> const std::vector< double > &  ampl,
> const std::vector< double > &  error_weight,
> const std::string  filter_type = "bandpass",
> int  grid_density = 16
> )
> The pm_remez has a squidly line under it and if I hover it with the mouse,
> it says gr::filter has no member function pm_remez. (I tried a bunch of
> different variations of things, but the squidly line remains.)


Marcin: Have you included the appropriate header file in your code? You
should declare: *#include *

Q2. The doc write up states that the pm_remez filter_types are  one of:
> bandpass, hilbert or differentiator. It seems like a natural for all these
> filters to provide a lowpass option, what do you think? If I can get rid of
> the squidly line, I would be able to test if "lowpass" works.


Marcin: I think that this depends on what you want to achieve. I cannot
help here because of the lack of exact knowledge about that, sorry.

Marcin

śr., 23 lut 2022 o 19:31 George Edwards  napisał(a):

> Hi Marcin,
>
> Thank you very much! I found my error, I forgot the "gain" which is the
> first parameter to the filter. The first parameter I wrote in the filter
> method was the "sample_rate" (which was a large number), hence the filter
> function could not converge. It is all good now, thank you.
>
> I have two questions related to the remez filter (you may or maynot be
> able to give me an answer(s)):
> Q1. If I write a line of code to extract the remez taps, say:
>lpfilter =
> gr::filter::pm_remez ( int  order,
> const std::vector< double > &  bands,
> const std::vector< double > &  ampl,
> const std::vector< double > &  error_weight,
> const std::string  filter_type = "bandpass",
> int  grid_density = 16
> )
> The pm_remez has a squidly line under it and if I hover it with the mouse,
> it says gr::filter has no member function pm_remez. (I tried a bunch of
> different variations of things, but the squidly line remains.)
>
> Q2. The doc write up states that the pm_remez filter_types are  one of:
> bandpass, hilbert or differentiator. It seems like a natural for all these
> filters to provide a lowpass option, what do you think? If I can get rid of
> the squidly line, I would be able to test if "lowpass" works.
>
> Thanks again for all your help.
>
> Regards,
> George
>
> On Wed, Feb 23, 2022 at 2:02 AM Marcin Puchlik 
> wrote:
>
>> George,
>> Running the below code:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *#include #include using namespace
>> std;int main() { cout << "!!!Hello World!!!" << endl; // prints !!!Hello
>> World!!! std::vector taps = gr::filter::firdes::low_pass(1, 1, 0.3,
>> 0.1); for(int i = 0; i < taps.size(); i++) cout << "tap " << i << ":" <<
>> "\t" << taps[i] << "\n"; return 0;}*
>>
>> *I get the output:*
>>
>> !!!Hello World!!!
>> tap 0: -0.00124749
>> tap 1: 0.0026334
>> tap 2: -3.313e-18
>> tap 3: -0.00722382
>> tap 4: 0.00725102
>> tap 5: 0.0112526
>> tap 6: -0.0272494
>> tap 7: 1.54168e-17
>> tap 8: 0.0582835
>> tap 9: -0.0539706
>> tap 10: -0.0877955
>> tap 11: 0.298026
>> tap 12: 0.600081
>> tap 13: 0.298026
>> tap 14: -0.0877955
>> tap 15: -0.0539706
>> tap 16: 0.0582835
>> tap 17: 1.54168e-17
>> tap 18: -0.0272494
>> tap 19: 0.0112526
>> tap 20: 0.00725102
>> tap 21: -0.00722382
>> tap 22: -3.313e-18
>> tap 23: 0.0026334
>> tap 24: -0.00124749
>>
>>
>>
>>
>> śr., 23 lut 2022 o 02:39 George Edwards 
>> napisał(a):
>>
>>> Hi Marcin and Vasil,
>>>
>>> Thank you guys very much!
>>>
>>> Marcin: I did as you suggested and left out win_type and beta.
>>> Vasil: Based on the conversation exchanges between you Marcin, I
>>> followed your suggestion to link in the gnuradio-filter library - in
>>> lib/CMakeLists.txt in target_link_libraries() by adding gnuradio-filter.
>>> Thus, the target_link_libraries in the original OOT lib/CMakeLists.txt
>>> file was:
>>> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime)
>>> and I added to it as shown below:
>>> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime
>>> gnuradio-filter)
>>> The OOT program compiles and makes the intended Gnuradio block for me to
>>> load in a GRC flowgraph. For experimental purposes, I made the OOT block to
>>> output the filter coefficients. When I run the grc, the lowpass filter
>>> outputs all zeros, so something is wrong!
>>> Marcin: You had written a piece of code to print "Hello World". Please
>>> run your code to print out the returned filter coefficients and let me know
>>> if it works well because mine is having some problems.
>>>
>>> This is how I invoked the filter method (all parameters are defined):
>>> vector  lpfilter; //vector variable will contain the filter
>>> coeff's
>>> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
>>> cutoff_freq, transition_bandwidth);
>>>
>>> Thank you guys!
>>>
>>> George
>>>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

George,
Running the below code:












*#include #include using namespace
std;int main() { cout << "!!!Hello World!!!" << endl; // prints !!!Hello
World!!! std::vector taps = gr::filter::firdes::low_pass(1, 1, 0.3,
0.1); for(int i = 0; i < taps.size(); i++) cout << "tap " << i << ":" <<
"\t" << taps[i] << "\n"; return 0;}*

*I get the output:*

!!!Hello World!!!
tap 0: -0.00124749
tap 1: 0.0026334
tap 2: -3.313e-18
tap 3: -0.00722382
tap 4: 0.00725102
tap 5: 0.0112526
tap 6: -0.0272494
tap 7: 1.54168e-17
tap 8: 0.0582835
tap 9: -0.0539706
tap 10: -0.0877955
tap 11: 0.298026
tap 12: 0.600081
tap 13: 0.298026
tap 14: -0.0877955
tap 15: -0.0539706
tap 16: 0.0582835
tap 17: 1.54168e-17
tap 18: -0.0272494
tap 19: 0.0112526
tap 20: 0.00725102
tap 21: -0.00722382
tap 22: -3.313e-18
tap 23: 0.0026334
tap 24: -0.00124749




śr., 23 lut 2022 o 02:39 George Edwards  napisał(a):

> Hi Marcin and Vasil,
>
> Thank you guys very much!
>
> Marcin: I did as you suggested and left out win_type and beta.
> Vasil: Based on the conversation exchanges between you Marcin, I followed
> your suggestion to link in the gnuradio-filter library - in
> lib/CMakeLists.txt in target_link_libraries() by adding gnuradio-filter.
> Thus, the target_link_libraries in the original OOT lib/CMakeLists.txt
> file was:
> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime)
> and I added to it as shown below:
> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime
> gnuradio-filter)
> The OOT program compiles and makes the intended Gnuradio block for me to
> load in a GRC flowgraph. For experimental purposes, I made the OOT block to
> output the filter coefficients. When I run the grc, the lowpass filter
> outputs all zeros, so something is wrong!
> Marcin: You had written a piece of code to print "Hello World". Please run
> your code to print out the returned filter coefficients and let me know if
> it works well because mine is having some problems.
>
> This is how I invoked the filter method (all parameters are defined):
> vector  lpfilter; //vector variable will contain the filter
> coeff's
> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq, cutoff_freq,
> transition_bandwidth);
>
> Thank you guys!
>
> George
>
>
> On Tue, Feb 22, 2022 at 3:41 PM Marcin Puchlik 
> wrote:
>
>> Geroge,
>> I posted the working code a few messages ago. Try to check this out. BTW
>> as far as I can see those two arguments are optional (window type and
>> beta). Try to run your code without them and check if it works.
>>
>>
>> wt., 22 lut 2022 o 19:25 George Edwards 
>> napisał(a):
>>
>>> Hello Vasil and Marcin,
>>>
>>> Thanks very much for your help.
>>>
>>> I have all the relevant #include header files and invoke the low_pass
>>> filter as follows:
>>> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
>>> cutoff_freq, transition_bandwidth,
>>> fft::window::win_type::WIN_HAMMING, beta);
>>>
>>> Observations:
>>> Using the mouse to hover over WIN_HAMMING, I can see that it interprets
>>> the win_type enum variable and correctly assigns it a value of "0" (which
>>> is the value stated in the Gnuradio C++ API Reference manual). However,
>>> there is a squidly under beta. Hovering over beta, the error message
>>> is:
>>> Argument of type "double" is incompatible with parameter of type
>>> "gr::fft::window::win_type"
>>>
>>> If one of you has a working code fragment using one of the C++ Gnuradio
>>> filter methods that you can cut, paste and send in your next email I would
>>> appreciate it.
>>>
>>> Thanks for your help.
>>>
>>> George
>>>
>>> On Tue, Feb 22, 2022 at 6:15 AM Vasil Velichkov 
>>> wrote:
>>>
 Hi George,

 On 21/02/2022 18.31, George Edwards wrote:
 > lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
 cutoff_freq, transition_bandwidth,
 > fft::window::win_type <
 https://www.gnuradio.org/doc/doxygen/classgr_1_1fft_1_1window.html#a599d7e9625d6cc77203a8b877c4911e2>window
 = fft::window::win_type::WIN_HAMMING, beta = 6.76);
 >
 > This failed and showed a squidly across the line with
 fft::window::win_type!

 Try adding "gr::" before "fft::window" and make sure
 gnuradio/fft/window.h is included.

   #include 

   lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
 cutoff_freq, transition_bandwidth,
 gr::fft::window::win_type window =
 fft::window::win_type::WIN_HAMMING, beta = 6.76);

 If this does not fix it then provide the exact error you are getting.

 Regards,
 Vasil

>>>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Geroge,
I posted the working code a few messages ago. Try to check this out. BTW as
far as I can see those two arguments are optional (window type and beta).
Try to run your code without them and check if it works.


wt., 22 lut 2022 o 19:25 George Edwards  napisał(a):

> Hello Vasil and Marcin,
>
> Thanks very much for your help.
>
> I have all the relevant #include header files and invoke the low_pass
> filter as follows:
> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq, cutoff_freq,
> transition_bandwidth,
> fft::window::win_type::WIN_HAMMING, beta);
>
> Observations:
> Using the mouse to hover over WIN_HAMMING, I can see that it interprets
> the win_type enum variable and correctly assigns it a value of "0" (which
> is the value stated in the Gnuradio C++ API Reference manual). However,
> there is a squidly under beta. Hovering over beta, the error message is:
> Argument of type "double" is incompatible with parameter of type
> "gr::fft::window::win_type"
>
> If one of you has a working code fragment using one of the C++ Gnuradio
> filter methods that you can cut, paste and send in your next email I would
> appreciate it.
>
> Thanks for your help.
>
> George
>
> On Tue, Feb 22, 2022 at 6:15 AM Vasil Velichkov 
> wrote:
>
>> Hi George,
>>
>> On 21/02/2022 18.31, George Edwards wrote:
>> > lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
>> cutoff_freq, transition_bandwidth,
>> > fft::window::win_type <
>> https://www.gnuradio.org/doc/doxygen/classgr_1_1fft_1_1window.html#a599d7e9625d6cc77203a8b877c4911e2>window
>> = fft::window::win_type::WIN_HAMMING, beta = 6.76);
>> >
>> > This failed and showed a squidly across the line with
>> fft::window::win_type!
>>
>> Try adding "gr::" before "fft::window" and make sure
>> gnuradio/fft/window.h is included.
>>
>>   #include 
>>
>>   lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
>> cutoff_freq, transition_bandwidth,
>> gr::fft::window::win_type window =
>> fft::window::win_type::WIN_HAMMING, beta = 6.76);
>>
>> If this does not fix it then provide the exact error you are getting.
>>
>> Regards,
>> Vasil
>>
>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

That's strange, in this order it doesn't work for me.
Thank you anyways :)
Marcin

wt., 22 lut 2022 o 14:47 Vasil Velichkov  napisał(a):

> On 22/02/2022 15.39, Marcin Puchlik wrote:
> > So while running: *g++ -gnuradio-filter main.cpp*   I get:
>
> You are missing an l between - and gnuradio
>
> > */bin/ld: /tmp/ccChkcfC.o: in function `main':main.cpp:(.text+0x8d):
> > undefined reference to `gr::filter::firdes::low_pass(double, double,
> > double, double, gr::fft::window::win_type, double)'collect2: error: ld
> > returned 1 exit status*
>
> Works on my machine :)
>
> $ g++ -lgnuradio-filter main.cpp
> $ ll
> total 32
> -rwxrwxr-x. 1 vasko vasko 27112 Feb 22 15:41 a.out
> -rw-rw-r--. 1 vasko vasko   325 Feb 22 15:40 main.cpp
>
> $ ./a.out
> !!!Hello World!!!
>
> $ ldd a.out | grep filter
> libgnuradio-filter.so.3.8.2 => /lib64/libgnuradio-filter.so.3.8.2
> (0x7fbf4984d000)
>
> $ objdump -TC a.out  | grep filter
>   DF *UND*  
> gr::filter::firdes::low_pass(double, double, double, double,
> gr::filter::firdes::win_type, double)
>
>
>
>
>
>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

So while running: *g++ -gnuradio-filter main.cpp*   I get:



*/bin/ld: /tmp/ccChkcfC.o: in function `main':main.cpp:(.text+0x8d):
undefined reference to `gr::filter::firdes::low_pass(double, double,
double, double, gr::fft::window::win_type, double)'collect2: error: ld
returned 1 exit status*

main.cpp is:












*#include #include #include
#include using namespace
std;int main() {cout << "!!!Hello World!!!" << endl; // prints
!!!Hello World!!!std::vector taps =
gr::filter::firdes::low_pass(1, 1, 0.3, 0.1);return 0;}*

wt., 22 lut 2022 o 14:34 Vasil Velichkov  napisał(a):

> On 22/02/2022 15.31, Marcin Puchlik wrote:
> > You are right, it helped thank you.
>
> You are welcome.
>
> > One more question, do you know why the command: *g++ main.cpp
> > -lgnuradio-filter *works correctly but in different order: *g++
> > -lgnuradio-filter main.cpp* crashes?
>
> No idea. Give me the full output (the exact error).
>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Vasil,
You are right, it helped thank you.
One more question, do you know why the command: *g++ main.cpp
-lgnuradio-filter *works correctly but in different order: *g++
-lgnuradio-filter main.cpp* crashes?

wt., 22 lut 2022 o 14:19 Vasil Velichkov  napisał(a):

> Hi Marcin,
>
> On 22/02/2022 14.32, Marcin Puchlik wrote:
> > But I am not creating the OOT module, I want to get filter taps using
> > *low_pass()*  function in simple C++ program (Hello World).
>
> It does not really matter what you are building, if you want to use this
> function then you need to link this library.
> > I even ran this from cmd with the command: *g++
> > -I/usr/include/gnuradio/filter -L/usr/lib/x86_64-linux-gnu/ main.cpp *
>
> You need to add -lgnuradio-filter parameter
>
>   g++ -I/usr/include/gnuradio/filter -L/usr/lib/x86_64-linux-gnu/
> -lgnuradio-filter main.cpp
>
> Cheers,
> Vasil
>
>
> > and the error is:
> >
> >
> >
> > */bin/ld: /tmp/ccTlKCri.o: in function `main':main.cpp:(.text+0xc7):
> > undefined reference to `gr::filter::firdes::low_pass_2(double, double,
> > double, double, double, gr::fft::window::win_type, double)'collect2:
> error:
> > ld returned 1 exit status*
> >
> >
> >
> > wt., 22 lut 2022 o 13:22 Vasil Velichkov 
> napisał(a):
> >
> >> Hi Marcin,
> >>
> >> On 22/02/2022 13.09, Marcin Puchlik via GNU Radio, the Free &
> Open-Source
> >> Toolkit for Software Radio wrote:
> >>> I also tried to use *low_pass() *function in my C++ program but with no
> >>> luck. My linker shouts that there is undefined reference to this
> function
> >>> but headers where recognized.
> >>
> >> You need to link your OOT module to gnuradio-filter library - in
> >> lib/CMakeLists.txt in target_link_libraries() add gnuradio-filter.
> >>
> >> target_link_libraries(gnuradio-test gnuradio::gnuradio-runtime
> >> gnuradio-filter)
> >>
> >> Regards,
> >> Vasil
> >>
> >
>
>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Vasil,
But I am not creating the OOT module, I want to get filter taps using
*low_pass()*  function in simple C++ program (Hello World).
I just want to link gnuradio library and use its function in custom C++
program, here is the code of main.cpp:

#include 
#include 
#include 
#include 

using namespace std;

int main() {
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
std::vector taps = gr::filter::firdes::low_pass(1, 1, 0.3, 0.1);
return 0;
}

I even ran this from cmd with the command: *g++
-I/usr/include/gnuradio/filter -L/usr/lib/x86_64-linux-gnu/ main.cpp *
and the error is:



*/bin/ld: /tmp/ccTlKCri.o: in function `main':main.cpp:(.text+0xc7):
undefined reference to `gr::filter::firdes::low_pass_2(double, double,
double, double, double, gr::fft::window::win_type, double)'collect2: error:
ld returned 1 exit status*



wt., 22 lut 2022 o 13:22 Vasil Velichkov  napisał(a):

> Hi Marcin,
>
> On 22/02/2022 13.09, Marcin Puchlik via GNU Radio, the Free & Open-Source
> Toolkit for Software Radio wrote:
> > I also tried to use *low_pass() *function in my C++ program but with no
> > luck. My linker shouts that there is undefined reference to this function
> > but headers where recognized.
>
> You need to link your OOT module to gnuradio-filter library - in
> lib/CMakeLists.txt in target_link_libraries() add gnuradio-filter.
>
> target_link_libraries(gnuradio-test gnuradio::gnuradio-runtime
> gnuradio-filter)
>
> Regards,
> Vasil
>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi George,
I also tried to use *low_pass() *function in my C++ program but with no
luck. My linker shouts that there is undefined reference to this function
but headers where recognized.
How did you install the GNU Radio? Was it installation from PPA or
building from source?
Marcin

pon., 21 lut 2022 o 18:28 George Edwards 
napisał(a):

> Hi Marcin,
>
> Thanks again for your help! I was a little busy and finally got around to
> looking at the two C++ fir filter documents you sent me.
>
> I tried to design an OOT C++ FIR lowpass filter block based on my
> understanding of these documents but my code shows error (squidly). In the
> OOT C++ code, I included all the #include header files shown in the
> documents. Then using the first document above for the lowpass design, I
> wrote the following:
> vector  lpfilter;
> then, I defined all the filter parameters (give them value) and tried to
> use the filter method:
> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq, cutoff_freq,
> transition_bandwidth,
> fft::window::win_type
> 
> window = fft::window::win_type::WIN_HAMMING, beta = 6.76);
>
> This failed and showed a squidly across the line with
> fft::window::win_type! I also tried leaving off the gr::filter::firdes
>
> nothing worked and I included the fft window header file!
> Please send me code examples if you have any that shows how to use these
> functions/methods.
>
> One more question: on a search on the second document, it says the remez 
> filter_types
> are: one of "bandpass", "hilbert" or "differentiator", I would have
> thought lowpass filters would be included??
>
> Thank you!
>
> George
>
> On Mon, Feb 14, 2022 at 12:05 AM Marcin Puchlik 
> wrote:
>
>> Hello George,
>> Yes, there is. Check this out:
>> https://www.gnuradio.org/doc/doxygen/firdes_8h_source.html
>> https://www.gnuradio.org/doc/doxygen/pm__remez_8h.html
>> BR,
>> Marcin
>>
>> pon., 14 lut 2022 o 00:07 George Edwards 
>> napisał(a):
>>
>>> Hello GNURadio Community,
>>>
>>> I am designing a Gnuradio OOT block in C++. Are there firls and kaiser
>>> filter methods (analogous to the scipy package methods that one would use
>>> in Python OOT) that I can call to generate coefficients.
>>>
>>> Thank you!
>>>
>>> Regards,
>>> George
>>>
>>

Re: Are there firls and kaiser filter methods for C++ OOT?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello George,
Yes, there is. Check this out:
https://www.gnuradio.org/doc/doxygen/firdes_8h_source.html
https://www.gnuradio.org/doc/doxygen/pm__remez_8h.html
BR,
Marcin

pon., 14 lut 2022 o 00:07 George Edwards 
napisał(a):

> Hello GNURadio Community,
>
> I am designing a Gnuradio OOT block in C++. Are there firls and kaiser
> filter methods (analogous to the scipy package methods that one would use
> in Python OOT) that I can call to generate coefficients.
>
> Thank you!
>
> Regards,
> George
>

GNU Radio modules and its contents

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Community,
I am quite new to GNU Radio ecosystem and I am wondering how you guys are
getting to know about many functions that the library and submodules offer?
For example, it's relatively easy to make a flowgraph based on the blocks
but the blocks (and hided object behind them) are one thing but the other
thing are variety of functions in each of the module e.g. gr-digital. I
didn't know about the digital.psk_4() function that returns mappings from
symbols to bit words before I run the examples from the gr-digital module.
I was always putting those values as lists by hand, cause I didn't
know that such a function exists. So my main question is: how to get to
know about a variety of functions/classes that GNU Radio provides? Should I
read the source code of each module starting in lib/ and /python directory
or is there a less cumbersome way?
Thanks
-- 

Marcin Puchlik

DSP Engineer



mobile +48 504 716 843


IS-Wireless

ul. Puławska 45b

05-500 Piaseczno/near Warsaw

Poland, EU

http://is-wireless.com

Re: segfault in 3.10.1.1

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Howdy Josh.
Thank you for your reply, sorry i should have provided more detail.
OS is bootstrapped, "always roll your own" (tm) , old school stubborn :)
i've several iterations done this way over the years.
As a minimalist, ever amazed at all the bloat that can accompany various
packages, the myriad option available to configure such.
We all know headaches associated  the cruft of stale headers and whatnot.
My goal, absolute minimum to have gnuradio - no "unnecessary"  -
especially, the overhead of desktops and doctools, systemd and ... getting
more difficult as time passes... an appliance so to speak.
i've told myself i'd document the steps and order but, alas, i never seem
to have the patience.
pip3 seems to work it's magic, all other packages were compiled accordingly
- think all dependencies have been met.
attached gr config and a (partial) list of packages if that's of any help.
as i said, GUI shows up briefly. way over my head all things things work
together.
Thank you are all you patience and help.



On Tue, Feb 8, 2022 at 5:39 AM Josh Morman  wrote:

> Hi Steve,
>
> Can you please share more information about how GR is installed in your
> case
> - OS/distribution?
> - Installation method (compiled from source, distro packages?
>
> Thanks!
> Josh
>
> On Mon, Feb 7, 2022 at 7:58 PM Steven Barbo  wrote:
>
>> Hello all, hope this day finds you well.
>> Having issue with gnuradio-companion, GUI comes up briefly...
>>
>> dmesg
>> [ 1341.843803] traps: gnuradio-compan[372] general protection fault
>> ip:7f81ca4f77c8 sp:7f81c7137010 error:0 in
>> libgirepository-1.0.so.1.0.0[7f81ca4ed000+2]
>>
>>
>> have compiled various gr versions over the years, they have always just
>> worked :)
>>
>> any help or pointers are very much appreciated. what an amazing tool,
>> thank you.
>>
>> gnuradio-config --print-all
>> /usr/
>> /etc
>> /etc/gnuradio/conf.d
>> /.gnuradio
>> Mon, 07 Feb 2022 03:07:35Z
>> testing-support;python-support;post-install;man-pages;gnuradio-runtime;common-precompiled-headers;gr-ctrlport;*
>> thrift;gnuradio-companion;gr-blocks;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-audio;*
>> alsa;*
>> oss;gr-channels;gr-pdu;gr-qtgui;gr-trellis;gr-utils;gr_modtool;gr_blocktool;gr-video-sdl;gr-vocoder;*
>> gsm;gr-wavelet;gr-network;gr-soapy
>> 3.10.1.1
>> cc (The Illustrious Industries, Ltd.) 10.3.0
>> Copyright (C) 2020 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.
>> c++ (The Illustrious Industries, Ltd.) 10.3.0
>> Copyright (C) 2020 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.
>> /usr/bin/cc:::-g -O2  -fvisibility=hidden -Wsign-compare -Wall
>> -Wno-uninitialized
>> /usr/bin/c++:::-g -O2  -fvisibility=hidden -Wsign-compare -Wall
>> -Wno-uninitialized
>> 2.9.0
>>
>>
>> apologies for the ugly script and gdb output, tried to disable control
>> characters...
>> shorten so as to not pollute
>>
>> sh-5.1# gdb -q /bin/python3 core
>> ^[[?2004l^MReading symbols from ^[[32m/bin/python3^[[m...
>> ^M
>> warning: Can't open file /SYSV (deleted) during file-backed
>> mapping note processing^M
>> ^M
>> warning: core file may not match specified executable file.^M
>> [New LWP 372]^M
>> [New LWP 358]^M
>> [New LWP 359]^M
>> [New LWP 361]^M
>> [New LWP 360]^M
>> [New LWP 363]^M
>> [New LWP 362]^M
>> [New LWP 370]^M
>> [New LWP 364]^M
>> [New LWP 369]^M
>> [New LWP 367]^M
>> [New LWP 368]^M
>> [New LWP 387]^M
>> [New LWP 365]^M
>> [New LWP 366]^M
>> [New LWP 395]^M
>> [New LWP 357]^M
>> ^M
>> warning: Cannot parse .gnu_debugdata section; LZMA support was disabled
>> at compile time^M
>> [Thread debugging using libthread_db enabled]^M
>> Using host libthread_db library "^[[32m/lib64/libthread_db.so.1^[[m".^M
>> Core was generated by `/usr/bin/python3 /usr/bin/gnuradio-companion --log
>> critical'.^M
>> Program terminated with signal SIGSEGV, Segmentation fault.^M
>> ^[[?2004h--Type  for more, q to quit, c to continue without
>> paging--^M
>> ^[[?2004l^M#0  ^[[34m0x7f81ca4f77c8^[[m in
>> ^[[33mg_callable_info_free_closure^[[m (^M
>> ^[[36mcallable_info^[[m=0x7f81c00034f0,
>> ^[[36mclosure^[[m=0x7f81c9cf3f20)^M
>> at ^[[32m../girepository/girffi.c^[[m:428^M
>> 428   g_free (wrapper->ffi_closure.cif->arg_types);^M
>> [Current thread is 1 (Thread 0x7f81c7138640 (LWP 372))]^M
>> ^[[?2004h(gdb) bt^M
>> ^[[?2004l^M#0  ^[[34m0x7f81ca4f77c8^[[m in
>> ^[[33mg_callable_info_free_closure^[[m (^M
>> ^[[36mcallable_info^[[m=0x7f81c00034f0,
>> ^[[36mclosure^[[m=0x7f81c9cf3f20)^M
>> at ^[[32m../girepository/girffi.c^[[m:428^M
>> #1  ^[[34m0x7f81c9a83a56^[[m in ^[[33m_pygi_invoke_closure_free^[[m
>> (^[[36mdata^[[m=0x7f81c0001630)^M
>> at ^[[32mgi/pygi-closure.c^[[m:635^M
>> #2  ^[[34m0x7f81c9a8e3e5^[

Re: PDU - cdr format

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Jacob,
Assuming that data are encoded text values how to print it as a test using
Message Debug block? My goal is to print the data in the console.

czw., 3 lut 2022 o 14:34 jacob  napisał(a):

> A PDU is a special type of PMT pair object that consists of a PMT
> Dictionary (of metadata) and a PMT Uniform Vector (of data). This is
> defined as such to make operating on PDU type data somewhat standardized.
>
> Depending on what you are actually trying to do you have a few options. If
> the string is metadata you can add it to the PMT metadata dictionary; if
> the string _is_ the data, you can save the encoded text values as a U8
> uniform vector.
>
> Jacob
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, February 3rd, 2022 at 2:28 AM, Marcin Puchlik via "GNU Radio,
> the Free & Open-Source Toolkit for Software Radio" <
> discuss-gnuradio@gnu.org> wrote:
>
> Hi Community,
> Does the cdr part of the PDU has to be a PMT uniform vector? What if I
> want to fill the cdr with string type of data?
>
>
>
>
>

Message Debug - printing in ASCII mode

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Community,
I am following tutorial about Packet Communications
 and I am
able to replicate all steps but one where the Message Debug block prints
the message in verbose mode. I don't see this mode in my configuration. I
see the output as numbers not letters. Has the verbose mode been disabled
in GNU Radio 3.9.3 ?
Thanks in advance
Marcin

PDU - cdr format

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Community,
Does the cdr part of the PDU has to be a PMT uniform vector? What if I want
to fill the cdr with string type of data?

Proper BFSK modulation

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Community,
Since I have no one to verify me, maybe there is someone who would find a
minute and verify my flowgraph
for
the BFSK modulation, demodulation and synchronization. My goal is to wrap
bits into packets and create end to end simulation with custom data
transmission (e.g. test or file). My main concern in the attached flowgraph
is the *outer_deviation *parameter. What do you think? I am wondering if
this parameter should be chosen with some earlier calculations (e.g. to
make smooth phase changes in VCO). I have no goal of obtaining any bitrate
or baud rate, just playing with different modulation schemes and getting
familiar with the tool and its features.
Also additional questions:
- is the minimum frequency spacing between changing carriers is 1/2T where
T is the symbol duration?
- is there a rule how to choose proper frequency spacing in the FSK for
higher order (4FSK, 16 FSK etc)?
Thanks in advance
Marcin

https://gist.github.com/marcinsztajn/c713ec33fa3e3c5bdb9c467d8487d4fc

-- 

Marcin Puchlik

Re: QAM module

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Mario,
Please, share the flowgraph code so it will be easier to find the issue.
BR,
Marcin

pon., 17 sty 2022 o 22:00 Mario Moran 
napisał(a):

> Hello everyone,
>
> I have a question on using the QAM module. I am using a random source
> block to make byte values,
>
> Random block settings:
> Output Type: Byte
> Min: 0
> Max: 4
> Num Samples: 1
> Repeat: no
>
> Then I have it connected to a throttle block with a sample rate of 32k.
> Then it is connected to a QAM mod block with the settings of,
>
> Num of constellation Points: 4
> Gray Code: yes
> Differential Encoding: no
> samples/symbol: 2
> Excess BW: 0.35
> verbose: off
> log: off
>
> When I run this, I get AttributeError: module gnuradio.digital.qam has no
> attribute 'qam_mod'. I am not sure why I am getting this error message.
> What can I do to fix this? Thank you for your time. Happy new year
> everyone.
>

Re: QT GUI Time Sink graph refresh rate

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Marcus,
That was a great answer. Now I know that this time mismatch is caused by
buffer sizes.
Thanks for these interesting materials.
BR,
Marcin

wt., 4 sty 2022 o 14:14 Marcus Müller  napisał(a):

> Hi Marcin,
>
> the mechanism is very simple:
>
>  > - sampling frequency
>
> That's just variable. It doesn't *mean* something to the GNU Radio
> scheduling mechanism –
> GNU Radio has no notion of "time". It just tries to process as much
> samples as quickly as
> possible.
>
> Now, what happens by default is:
> You set up your flow graph, and start it. That means GNU Radio goes and
> allocates buffers
> between these blocks – exactly these memory regions that your
> (general_)work functions
> write into, and read out of. For technical reasons[1], these buffers need
> to be multiples
> of 4 kB in size.
>
> After the buffers have been allocated, GNU Radio figures out the sources
> in the flow graph
> - these are the first blocks that need to do anything, so that any other
> blocks actually
> have something to do – and calls their (general_)work function, asking
> them to fill up
> half their output buffer (or as much they can do). Depending on the size
> of the buffer
> (typical default, I think, currently is 16 kB), and the size of each item
> (e.g. 8 bytes),
> that can be thousands of samples.
>
> So the source goes and calculates that many samples, puts them in the
> output buffer, and
> tells GNU Radio how much it has produced. GNU Radio then informs its
> downstream neighbor
> that there's these many samples in the buffer to be processed, and calls
> the
> (general_)work function of that block. In your case, that's the Throttle.
>
> Now, the throttle block sees, let's say, 2048 samples, and knows it should
> be doing a rate
> of 1000 samples a second. It thus calculates that these samples should
> take 2.048 s, so it
> copies over the samples from its in- to its output, and sleep()s for 2.048
> s, then tells
> GNU Radio it produced 2.048 samples. Thus, the next downstream neighbor
> gets notified that
> there's 2048 items waiting to be processed.
>
> While the Throttle was copying and sleeping, the source has already been
> asked to produce
> more items (remember, the second half of the buffer is still free), so
> it's realistic it
> produced another 2048 items in the time. So, Throttle is immediately after
> being done with
> its work() being called again – since there's already new input waiting,
> it copies, sleeps
> for 2.048 s, and so on.
>
> In effect, that means that the Sink gets data once every 2.048 s, and in
> chunks of 2048
> items, not in nice small packages. *In average*, the rate is 1 kS/s, but
> that just means
> it's "no data to be processed for what seems to be eternity" followed by
> "a large amount
> of samples".
>
> I've done a talk trying to illustrate this a bit back on the European GNU
> Radio days in
> Besançon¹, I hope it's not to confused and too confusing, but maybe it's
> of interest to
> you[2].
>
> Best regards,
> Marcus
>
> [1] https://www.gnuradio.org/blog/2017-01-05-buffers/
> [2] https://www.youtube.com/watch?v=cTGxhsSvZ9c
> ¹ it was nce there!
>
> On 04.01.22 13:23, Marcin Puchlik via GNU Radio, the Free & Open-Source
> Toolkit for
> Software Radio wrote:
> > Dear Cyrille and Marcus
> > Thanks for your answers.
> > Cyrille: I get that there is no exact timing and the refresh rate on the
> Time Sink block
> > can deviate from one second (in this particular example) but what is the
> margin? Now, in
> > this configuration it takes apx 10 seconds to refresh the graph on the
> Time Sink, is this
> > correct observation? How exactly does the Throttle block behave then
> (assuming no timing)?
> >
> > Marcus: YES! Great! Now, the Time Sink behaves as expected! But let me
> understand what
> > happened:
> > - sampling frequency: 1000
> > - maximum number of output items for the Throttle block (during a call
> to work): 1000/100 = 10
> > - update period for the Time Sink: 1
> > - number of points for the Time Sink: 100
> >
> > In this configuration now, the Time Sink receives the data at a proper
> speed and is able
> > to refresh the graph at a rate 1 (one time per second). Can you tell me
> the rationale for
> > this? Can we say how often the work function is called when there is the
> Throttle in the
> > flowgraph? Simple calculations would help.
> >
> > BR,
> > Marcin
> >
> >
> >
> > czw., 30 gru 2021 o 15:28 Marcus Müller  > <mailto:mmuel...

Re: QT GUI Time Sink graph refresh rate

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Dear Cyrille and Marcus
Thanks for your answers.
Cyrille: I get that there is no exact timing and the refresh rate on the
Time Sink block can deviate from one second (in this particular example)
but what is the margin? Now, in this configuration it takes apx 10 seconds
to refresh the graph on the Time Sink, is this correct observation? How
exactly does the Throttle block behave then (assuming no timing)?

Marcus: YES! Great! Now, the Time Sink behaves as expected! But let me
understand what happened:
- sampling frequency: 1000
- maximum number of output items for the Throttle block (during a call to
work): 1000/100 = 10
- update period for the Time Sink: 1
- number of points for the Time Sink: 100

In this configuration now, the Time Sink receives the data at a proper
speed and is able to refresh the graph at a rate 1 (one time per second).
Can you tell me the rationale for this? Can we say how often the
work function is called when there is the Throttle in the flowgraph? Simple
calculations would help.

BR,
Marcin



czw., 30 gru 2021 o 15:28 Marcus Müller  napisał(a):

> Ah, by the way, could you try the following dirty hack:
>
> 1. Copy the generated update_period.py file.
> 2. Find the place where self.blocks_throttle_0 = ... is done
> 3. after that, insert
> self.blocks_throttle_0.set_max_noutput_items(int(samp_rate/100))
>
> and report whether that works?
>
> Best regards,
> Marcus
>
> On 30.12.21 13:54, Marcus Müller wrote:
> > Exactly! Chances are even that the Throttle regularly sees very large
> input blocks, e.g.
> > 8192 items at once, and then decides to sleep for loong before
> telling GNU Radio it's
> > done copying the input to the output.
> >
> > Best regards,
> > Marcus
> >
> > On 30.12.21 12:32, Cyrille Morin wrote:
> >> Hi Marcin,
> >> In this graph, the Time sink waits for chunks of 100 samples to display
> at a time.
> >> Since the Throttle is set to forward 1000 samples per second, it should
> be able to
> >> update up to 10 times per second.
> >>
> >> Keep in mind that this is an estimate since the Throttle block does not
> enforce its
> >> timing exactly. It depends on the size of sample blocks it operates on.
> >> So it could be possible that the scheduler gives it a chunk of 1000
> samples at a time.
> >> In this case, it would forward it whole, and the Time sink would only
> display the 100
> >> samples out of these 1000.
> >> If that repeats, you would only get 1 update per second.
> >>
> >> Hope this makes sense,
> >> Cyrille
> >>
> >>
> >> Le 30 décembre 2021 10:38:06 GMT+01:00, "Marcin Puchlik via GNU Radio,
> the Free &
> >> Open-Source Toolkit for Software Radio"  a
> écrit :
> >>
> >> Hi Marcus,
> >> Thanks for your answer. Please, check out this flowgraph.
> >> Shouldn't the Time Sink update its graph content every second in
> this configuration?
> >>
> >> image.png
> >>
> https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426
> >> <
> https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426>
> >> BR,
> >> Marcin
> >>
> >>
> >> śr., 29 gru 2021 o 19:27 Marcus Müller  >> <mailto:mmuel...@gnuradio.org>> napisał(a):
> >>
> >> Hi Marcin,
> >>
> >> only if there's no other component that limits the speed of
> processing. For
> >> example, if
> >> the samples come from an SDR, than that has a sampling rate, so
> there's only so
> >> many
> >> samples per second that can reach your sink.
> >>
> >>   > I noticed that when I am using
> >>   > throttle block along with QT GUI Time Sink the update
> period is not working
> >> properly (I
> >>   > have to wait much longer to see the updated graph).
> >>
> >> That only happens when the number of samples reaching the sink
> isn't sufficient to
> >> get one
> >> full vector of samples per update period.
> >>
> >> Best regards,
> >> Marcus
> >>
> >>
> >>
>
>

Re: QT GUI Time Sink graph refresh rate

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Marcus,
Thanks for your answer. Please, check out this flowgraph.
Shouldn't the Time Sink update its graph content every second in this
configuration?

[image: image.png]
https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426
BR,
Marcin


śr., 29 gru 2021 o 19:27 Marcus Müller  napisał(a):

> Hi Marcin,
>
> only if there's no other component that limits the speed of processing.
> For example, if
> the samples come from an SDR, than that has a sampling rate, so there's
> only so many
> samples per second that can reach your sink.
>
>  > I noticed that when I am using
>  > throttle block along with QT GUI Time Sink the update period is not
> working properly (I
>  > have to wait much longer to see the updated graph).
>
> That only happens when the number of samples reaching the sink isn't
> sufficient to get one
> full vector of samples per update period.
>
> Best regards,
> Marcus
>
>
>

QT GUI Time Sink graph refresh rate

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi community,
Should I use throttle block while using QT GUI Time Sink? I noticed that
when I am using throttle block along with QT GUI Time Sink the update
period is not working properly (I have to wait much longer to see the
updated graph).

RE: fosphor sink block error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,


I install the package but before testing it I see a new problem.

Gnuradio is in version 3.9.4.0.


The fosphor sink block is in error so I can't run the flowgraph.

No matter what Window type I put, I have this error in block parameters:


Param - Window Type(wintype):
Value "firdes.WIN_BLACKMAN_hARRIS" cannot be evaluated:
type object 'gnuradio.filter.filter_python.firdes' has no attribute 
'WIN_BLACKMAN_hARRIS'

Param - Window Type(wintype):
Expression None is invalid for type 'int'.

Is it because of how I install gr-fosphor ?

Regards,
Gwendoline



De : Sylvain Munaut <246...@gmail.com>
Envoyé : jeudi 23 décembre 2021 12:13:53
À : Gwendoline Hochet Derevianckine
Cc : discuss-gnuradio@gnu.org
Objet : Re: fosphor sink block error

Warning - External Email


Hi,


If you're using Ubuntu, you can try the intel-opencl-icd package which
is the binary package for https://github.com/intel/compute-runtime
which is the OpenCL driver for Intel GPUs.
However, I'm not sure anyone has ever run fosphor with it ... not sure
if it supports the features required, I only tried on AMD and NVidia
GPUs as I don't have any Intel GPU supporting that driver.

Cheers,

  Sylvain

To view our privacy policy, including the types of personal information we 
collect, process and share, and the rights and options you have in this 
respect, see www.semtech.com/legal.

RE: fosphor sink block error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Sylvain,


I realize that I'm not sure of how I install the gr-fosphor package. I download 
the .deb (gr-fosphor_3.8~2.2d4fe78-1build3_amd64.deb) and I install it. I did 
that because I don't really understand what to do by reading the wiki fosphor.


So I'm back in Gnuradio 3.9 😊


> What GPU do you have in your machine ?

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 
(Whiskey Lake) [8086:3ea0] (prog-if 00 [VGA controller])
Kernel driver in use: i915
Kernel modules: i915

> Also, list the files in `/etc/OpenCL/vendors/` which gives the
installed drivers.

I don't have such a repository ... I guess the problem comes from here.

Thanks for helping 😊
Gwendoline



De : Sylvain Munaut <246...@gmail.com>
Envoyé : jeudi 23 décembre 2021 11:29:58
À : Gwendoline Hochet Derevianckine
Cc : discuss-gnuradio@gnu.org
Objet : Re: fosphor sink block error

Warning - External Email


Hi Gwendoline,


> I tried various versions of Gnuradio but fosphor sink block doesn't work 
> under 3.8 or 3.9.

Definitely go for 3.9
I only maintain it for the latest version of gnuradio ( so it might be
3.10 only soon ... ).


> [!] CL Error (-1001, 
> /build/gr-fosphor-1DVbtt/gr-fosphor-3.8~2.2d4fe78/lib/fosphor/cl.c:299): 
> Unable to fetch platform IDs
> [!] No suitable OpenCL device found
> gr::log :ERROR: qt_sink_c0 - Failed to initialize fosphor

So that's a sign that it found no valid OpenCL device.
Most distribution don't install proper OpenCL drivers by default.

The OpenCL stack is composed of two elements :
 - The "Dispatcher" : which is just a shim to dispatch OpenCL requests
to multiple "platforms" (i..e vendors basically) in case you have
several OpenCL devices in your system.
 - The actual driver that talks to the hardware.

Obviously you have the dispatcher installed (called "ICD Loader"), but
there was no driver (caled "ICD") found (or if there was drivers,
those drivers reported no valid/available devices).

What GPU do you have in your machine ?
Also, list the files in `/etc/OpenCL/vendors/` which gives the
installed drivers.

Cheers,

   Sylvain

To view our privacy policy, including the types of personal information we 
collect, process and share, and the rights and options you have in this 
respect, see www.semtech.com/legal.

Re: ofdm adalm-pluto

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
Is this a periodic problem with the same packets?
Marcin


czw., 16 gru 2021 o 14:54 Özkan Sezer  napisał(a):

> Hi Marcus,
> Thanks for your answer, yes it's unexpected because the transmitter and
> receiver are so
> close. OFDM block same as gr-digital; is the extra spec for Adalm-pluto
> SDR?
>

Re: Problems when passing messages to a source block

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Jeff,
Are you mailing with yourself?

wt., 30 lis 2021 o 00:46 Jeff Long  napisał(a):

> Sounds good. Only look at the C++ to figure out the general idea. I'd
> learn Python threading first in a standalone program so you're not learning
> (debugging) GR and python threading at the same time. Good luck - let us
> know how it goes.
>
> Also, please respond to the mailing list so everyone can benefit from the
> conversation.
>
> On Mon, Nov 29, 2021 at 5:11 PM Michelle  wrote:
>
>> Hi Jeff,
>>
>> thank you for your help and sorry for the delay, I was in class.
>>
>> it is now that I start to work on it. My first step is to master how the
>> c++ code of the strobe message block work, specially the functions:
>>
>> -bool message_strobe_impl::start()
>>
>> -bool message_strobe_impl::stop()
>>
>> -void message_strobe_impl::run()
>>
>> Then I will implement the python version following your advice. I will
>> write to you to show you the result.
>>
>> Once again thank you, I was really lost.
>>
>> Have a good afternoon.
>>
>> OK, it does work, as long as there is a message port defined and
>> connected in a flowgraph. I was trying too simple an example. You would do
>> your thread management in the start() and stop() functions.
>>
>> """
>> Embedded Python Blocks:
>>
>> Each time this file is saved, GRC will instantiate the first class it
>> finds
>> to get ports and parameters of your block. The arguments to __init__  will
>> be the parameters. All of them are required to have default values!
>> """
>>
>> import numpy as np
>> from gnuradio import gr
>> import pmt
>>
>> class blk(gr.sync_block):  # other base classes are basic_block,
>> decim_block, interp_block
>> """Embedded Python Block example - a simple multiply const"""
>>
>> def __init__(self):  # only default arguments here
>> """arguments to this function show up as parameters in GRC"""
>> gr.sync_block.__init__(
>> self,
>> name='Embedded Python Block',   # will show up in GRC
>> in_sig=[],
>> out_sig=[]
>> )
>> self.message_port_register_out(pmt.intern("msgout"))
>> print('init')
>>
>> def start(self):
>> print('start')
>> return True
>>
>> def stop(self):
>> print('stop')
>> return True
>>
>> On Mon, Nov 29, 2021 at 2:13 PM Jeff Long  wrote:
>>
>>> Issue submitted: https://github.com/gnuradio/gnuradio/issues/5358
>>>
>>> On Mon, Nov 29, 2021 at 1:58 PM Jeff Long  wrote:
>>>
 It does not seem that python blocks can override start() and stop(),
 which they should be able to do. So, don't go too far down that path. I do
 not see anywhere in the code where this is used or would have been caught.

 The embedded blocks are easier, be beware that GRC calls the init
 function to learn about the block. Therefore, you don't want any action
 taken as a result of a call to init, for instance spawning a thread and
 starting to send messages. Embedded python block are sort of a toy that
 turned out to be useful. In general, an OOT is a better idea, but an
 embedded block can work if it's simple enough.

 Maybe someone else has figured this out. With just a quick look, I
 don't see how a Message Strobe kind of block can be implemented in python
 without start() and stop().

 Here's kind of a hack: make a python block with a message handler that
 gets a periodic strobe from the existing Message Strobe block. In the
 handler, send out the message that you would have sent in the thread.

>>>

Re: 回复： How to configure the TensorFlow environment so that it can be used on gnuradio?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
One workaround is to add the path of the "util_model.py" to the sys.path
(PYTHONPATH environment variable), then python should find the file.
Your warings are regarding doxygen.
BR,
Marcin

czw., 25 lis 2021 o 08:22 能书能言 <2127629...@qq.com> napisał(a):

> Hi
> Thank you for your reply. I have tried this operation method, but the
> problem still exists. I will re-describe my operation process:
> First, I used the gr_modtool tool to create an OOT module
> Then, I used the gr_modtool tool again to add a .py file (this is my block
> file)
> Since the .py file in the previous step needs to use the "util_model.py"
> file, I will copy this file directly to the /python directory
> Then execute, cmake, make, make install, make ldconfig, create a simple
> flow diagram to test this module, but an error "no module named util_model"
> is reported
> So according to your method, change the CMaketxt file, delete the build
> directory and create a new one, re-execute cmake..., but "no module named
> util_model" still exists
> In addition, I found that two warnings appeared when I executed the make
> command（Attached picture）
> I don’t know if the reason for this error is related to it
> Regards,
> linge93
>
>
> -- 原始邮件 --
> *发件人:* "Vasil Velichkov" ;
> *发送时间:* 2021年11月24日(星期三) 晚上10:20
> *收件人:* "能书能言"<2127629...@qq.com>;
> *抄送:* "discuss-gnuradio";
> *主题:* Re: 回复： How to configure the TensorFlow environment so that it can
> be used on gnuradio?
>
> Hi linge93,
>
> On 24/11/2021 15.24, 能书能言 wrote:
> > I copied the "util_model.py" file directly to the /python directory
>
> >  I now know that I can’t just put it under the gr_oot/python folder
>
> Open gr_oot/python/CMakeLists.txt and add util_model.py in the
> GR_PYTHON_INSTALL files, something similar to
>
> GR_PYTHON_INSTALL(
> FILES
> __init__.py
> util_model.py
> DESTINATION ${GR_PYTHON_DIR}/oot
> )
>
> Add in case you are using git for source control don't forget to add it to
> the repository.
>
> git add python/util_model.py
>
> Regards,
> Vasil
>

Re: How to configure the TensorFlow environment so that it can be used on gnuradio?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
To be able to use TensorFlow in GNU Radio you just have to install
TensorFlow according to the following instruction:
https://www.tensorflow.org/install/pip
Then just import the module and play with it.
Does it help?
BR,
Marcin


śr., 24 lis 2021 o 08:49 能书能言 <2127629...@qq.com> napisał(a):

> Hello everyone,
> I recently want to implement a Python version of the OOT module on
> GNURadio, so that it can run the TensorFlow framework, because my original
> code is written in Python, so I wonder if I can directly create a Python
> OOT module to make it work properly . But i have a problem.
> My original code uses the environment configured by miniConda, but when I
> use GNURadio, TensorFlow does not exist in my environment, that is to say,
> "no module named tensorflow" will be displayed when I run the GRC flow
> graph. I should How to install TensorFlow framework in gnuradio? Do I need
> to reinstall GNURadio? (That's too bad) I don't know how to do it. Has
> anyone had a similar experience? Any information i would be very grateful！
> Sincerely
> linge93
>

Re: gr-fosphor (pybombs): CMake Error: The following variables are used in this project, but they are set to NOTFOUND

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Thanks, take care.
Marcin

wt., 23 lis 2021 o 12:31 Vasil Velichkov  napisał(a):

> On 23/11/2021 13.27, Marcin Puchlik wrote:
> > So do you usually build and install from source manually?
>
> Yes, this is what I do.
>

Re: gr-fosphor (pybombs): CMake Error: The following variables are used in this project, but they are set to NOTFOUND

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Vasil,
So do you usually build and install from source manually?


wt., 23 lis 2021 o 12:26 Vasil Velichkov  napisał(a):

> Hi Marcin,
>
> On 23/11/2021 13.16, Marcin Puchlik wrote:
> > It seems like I cannot use pybombs recipes to install the OOTs.
>
> Not all receipes are well/regularly tested on all platforms so you are
> going to face some problems but generally you can install OOTs with pybombs.
>
> P.S.
> I'm not very familiar with pybombs as I'm not using it.
>
> Regards,
> Vasil
>

Re: gr-fosphor (pybombs): CMake Error: The following variables are used in this project, but they are set to NOTFOUND

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Vasil,
Thanks for your answer.
What helped was passing -DCMAKE_FIND_ROOT_PATH=/usr option, while
configuring the OOT module.
It seems like I cannot use pybombs recipes to install the OOTs.
Best regards,
Marcin

pon., 22 lis 2021 o 15:11 Vasil Velichkov 
napisał(a):

> Hi Marcin,
>
> On 21/11/2021 20.48, Marcin Puchlik via GNU Radio, the Free & Open-Source
> Toolkit for Software Radio wrote:
> > Please set them or make sure they are set and tested correctly in the
> CMake files:
> > /home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/lib/Boost_INCLUDE_DIR
> >used as include directory in directory
> /home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/lib/
>
> Usually such errors indicate that the development files for a library are
> not installed (Boost in your case)
>
> > -- Found Boost:
> /lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable
> version "1.71.0", minimum required is "1.65") found components: system
> chrono thread
>
> But it seems that you do have them. Also as you are using pybombs it
> should install the boost development packages in case they are not
> installed.
>
> First check what is the value of the various boost variables in
> CMakeCache.txt
>
>   grep -i boost
> /home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/build/CMakeCache.txt
>
> Then make sure that you have libboost-all-dev package installed and
> installed it if missing. Then delete the build directory (or
> CMakeCache.txt) and try a clean rebuild.
>
> > GNU Radio version: 3.9.2.0
>
> Which Ubuntu version are you using?
>
> Regards,
> Vasil
>

gr-fosphor (pybombs): CMake Error: The following variables are used in this project, but they are set to NOTFOUND

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
While installing gr-fosphor I got a following error:

Command: *pybombs install gr-fosphor*




































































*[INFO] Prefix Python version is: 3.8.10[INFO] PyBOMBS Version 2.3.5[INFO]
Phase 1: Creating install tree and installing binary packages:Install
tree:|\- gr-fosphor[INFO] Phase 1 complete: All binary dependencies
installed.[INFO] Phase 2: Recursively installing source packages to
prefix:[INFO] Installing package: gr-fosphor[WARNING] Build dir already
exists: /home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/buildConfiguring:
(100%)
[==][WARNING]
Configuration failed. Re-trying with higher verbosity.-- Using GMP.-- Found
Boost: /lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found
suitable version "1.71.0", minimum required is "1.71.0") found components:
date_time program_options filesystem system regex thread
unit_test_framework -- User set python executable /usr/bin/python3-- Found
PythonInterp: /usr/bin/python3 (found version "3.8.10") -- Found
PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so
 (found suitable exact version "3.8.10") --
Extracting version information from git describe...-- Found Boost:
/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable
version "1.71.0", minimum required is "1.65") found components: system
chrono thread -- Found PythonLibs:
/usr/lib/x86_64-linux-gnu/libpython3.8.so  (found
suitable version "3.8.10", minimum required is "3") -- -- The build system
will automatically enable all components.-- Use -DENABLE_DEFAULT=OFF to
disable components by default.-- -- Configuring Python support...--
Dependency PYTHONLIBS_FOUND = TRUE--   Dependency pybind11_FOUND = 1--
Enabling Python support.--   Override with -DENABLE_PYTHON=ON/OFF-- --
Configuring GLFW support...--   Dependency GLFW3_FOUND = TRUE--   Enabling
GLFW support.--   Override with -DENABLE_GLFW=ON/OFF-- -- Configuring QT
support...--   Dependency Qt5_FOUND = 1--   Enabling QT support.--
Override with -DENABLE_QT=ON/OFF-- Found PythonInterp: /usr/bin/python3
(found suitable version "3.8.10", minimum required is "3") -- Using install
prefix: /home/ubuntu/prefixes/gnuradio39-- Building for version: 974ab2fe /
3.9.0git-- Python checking for pygccxml - not found-- --
##-- # Gnuradio enabled
components --
##--   * Python--   *
GLFW--   * QT-- -- ##--
# Gnuradio disabled components--
##-- -- Using install
prefix: /home/ubuntu/prefixes/gnuradio39CMake Error: The following
variables are used in this project, but they are set to NOTFOUND.Please set
them or make sure they are set and tested correctly in the CMake
files:/home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/lib/Boost_INCLUDE_DIR
 used as include directory in directory
/home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/lib-- Configuring
incomplete, errors occurred!See also
"/home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/build/CMakeFiles/CMakeOutput.log".See
also
"/home/ubuntu/prefixes/gnuradio39/src/gr-fosphor/build/CMakeFiles/CMakeError.log".[ERROR]
Configuration failed after running at least twice.[ERROR] Problem occurred
while building package gr-fosphor:Configuration failed[ERROR] Error
installing package gr-fosphor. Aborting.*

GNU Radio version: 3.9.2.0

Does anyone know what could cause the problem?
-- 

Marcin Puchlik

Re: .ci_support folder in gnuradio tree

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Marcus,
Thanks for the information. It's very interesting. What PR stands for?


niedz., 21 lis 2021 o 17:30 Marcus Müller 
napisał(a):

> Hi Marcin,
>
> these are the files generated by conda-smithy during setup of the CI
> infrastructure, which
> allows us to do test builds on every PR on github on the windows, OS X and
> Linux conda
> target platforms :)
>
> Best regards,
> Marcus
>
> On 20.11.21 18:16, Marcin Puchlik via GNU Radio, the Free & Open-Source
> Toolkit for
> Software Radio wrote:
> > Hi,
> > What are these files located under .ci_support in the gnuradio source
> tree? Any
> > explanation would be appreciated.
> > Thanks
> >
> > Marcin Puchlik
> >
> >
>

.ci_support folder in gnuradio tree

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
What are these files located under .ci_support in the gnuradio source tree?
Any explanation would be appreciated.
Thanks

Marcin Puchlik

Re: Message debug block

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Dear Vasil, Jacob
Very thank you for your clarification. In my opinion there are lacks in the
documentation so I will add a few more sentences about the PDUs and what it
means exactly and how to interpret it compared to the standard messages in
GNU Radio. In the issue 4191
 provided by Vasil, it is
explained beautifully what are the differences. In my opinion, Jacob's
explanation should be copied and pasted somewhere in the wiki because it's
simple and easy.
Best regards,
Marcin

pt., 19 lis 2021 o 15:58 jacob  napisał(a):

> In this case, there is an extra bit of confusion because an empty PMT
> dictionary `pmt.make_dict()` is represented by (and the same as)
> `pmt.PMT_NIL`. An interned string, as in your first example, is not a
> dictionary type object and thus you get the warning message.
>
> Jacob
>
> ‐‐‐ Original Message ‐‐‐
>
> On Friday, November 19th, 2021 at 3:30 AM, Vasil Velichkov <
> vvvelich...@gmail.com> wrote:
>
> > Hi Marcin,
> >
> > On 18/11/2021 15.23, Marcin Puchlik wrote:
> >
> > > *pmt.cons(pmt.intern(""), pmt.make_u8vector(16, 0xFF)) - *where Debug
> > >
> > > block cannot extract the PDU - gr::log :WARN: message_debug0 - Non PDU
> type
> > >
> > > message received. Dropping.
> >
> > Not every message is a PDU [1]. Have a look at is_pdu() in pmt.h [2] and
> read the discussion in issue #4191 [3].
> >
> > /*!
> >
> > -   Returns true if the object is a PDU meaning:
> > -   the object is a pair
> > -   the car is a dictionary type object (including an empty dict)
> > -   the cdr is a uniform vector of any type
> >
> > */
> >
> > PMT_API bool is_pdu(const pmt_t& obj);
> >
> > [1] https://wiki.gnuradio.org/index.php/Message_Passing#PDUs
> >
> > [2]
> https://github.com/gnuradio/gnuradio/blob/maint-3.9/gnuradio-runtime/include/pmt/pmt.h#L707-L713
> >
> > [3] https://github.com/gnuradio/gnuradio/issues/4191
>

Message debug block

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
While getting into the messaging system in GNU Radio I noticed that the
Message Debug block doesn't print PDU for messages if a message has
metadata (key value or car) different than pmt.PMT_NIL. So I have a Message
Strobe connected to Message Debug where message is:
*pmt.cons(pmt.intern(""), pmt.make_u8vector(16, 0xFF))  - *where Debug
block cannot extract the PDU - gr::log :WARN: message_debug0 - Non PDU type
message received. Dropping.
*pmt.cons(pmt.PMT_NIL, pmt.make_u8vector(16, 0xFF)) - *where the Message
Debug block prints PDU as I would expect.
Does it mean that the Message Debug block is not working properly or my
understanding is wrong?
Best regards,
-- 

Marcin Puchlik

DSP Engineer



mobile +48 504 716 843


IS-Wireless

ul. Puławska 45b

05-500 Piaseczno/near Warsaw

Poland, EU

http://is-wireless.com

Re: gr-tutorial error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

> Good afternoon,
> 
> I am working on the tutorial for creating My QPSK Demodulator block and it
> seems that I have run into an error when I execute the flow graph. The
> error:
> Traceback (most recent call last):
>   File "/home/mariom/gr-tutorial/build/top_block.py", line 191, in 
> main()
>   File "/home/mariom/gr-tutorial/build/top_block.py", line 167, in main
> tb = top_block_cls()
>   File "/home/mariom/gr-tutorial/build/top_block.py", line 82, in __init__
> self.tutorial_my_qpsk_demod_cb_0 = tutorial.my_qpsk_demod_cb(True)
> AttributeError: module 'tutorial' has no attribute 'my_qpsk_demod_cb'
> 
> In case you in the link for the tutorial here it is: Click here
> 
> 
> I have been looking at the My QPSK Demodulator code blocks to see if there
> was something I missed but it does not seem so. I'm using Ubuntu 20.04.3
> LTS and I downloaded Gnuradio 3.8.4.0. I'm not sure where to go after this.
> Any suggestions? Thank you for your time. Have a nice day.
> 
> -Mario Moran

Gr-tutorial is GR-3.7 only and will not build with version 3.8 or 3.9.
If you want to follow QPSK demodulation tutorial, there is a link to 
mpsk_stage6.grc flowgraph there that does not require My QPSK Demodulator 
block. 
-- 

Wojciech Kazubski

Re: ModuleNotFoundError while running unit test of the OOT

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Thanks Jeff!
BR

niedz., 24 paź 2021 o 22:33 Jeff Long  napisał(a):

> That workaround doesn't make sense. The idea, though, is that some files
> need to be moved/symlinked so Python can see them. Or the PYTHONPATH needs
> adjustment.
>
> On Sun, Oct 24, 2021 at 4:23 PM Jeff Long  wrote:
>
>> This is also true on the latest dev/master, and it was possible to do a
>> "make test" before "make install" in 3.8. This has been noted in
>> https://github.com/gnuradio/gnuradio/issues/4825, which also includes a
>> workaround.
>>
>> On Sun, Oct 24, 2021 at 1:47 PM Marcin Puchlik via GNU Radio, the Free &
>> Open-Source Toolkit for Software Radio  wrote:
>>
>>> Hi,
>>> While creating a squaring OOT module (just as an example), my unit test
>>> failed because of *ModuleNotFoundError.*
>>> This error occurs before running *make install*. After running *make
>>> install* module is available and test is passing ok but it doesn't make
>>> sense to do that.
>>> I am using *3.9.3.0 *version of GNU Radio. I expect that after running *make
>>> *there will be a python module called *square *(as I named my OOT, am I
>>> correct?)
>>> Below is the output after running *ctest -VV *command:
>>>
>>> Note: below output is obtained after running *make install *and then *make
>>> uninstall *(after make install, module is available and the is no error)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *UpdateCTestConfiguration  from
>>> :/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/build/DartConfiguration.tclUpdateCTestConfiguration
>>>  from
>>> :/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/build/DartConfiguration.tclTest
>>> project /home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/buildConstructing a
>>> list of testsDone constructing a list of testsUpdating test list for
>>> fixturesAdded 0 tests to meet fixture requirementsChecking test dependency
>>> graph...Checking test dependency graph endtest 1Start 1: qa_square_ff1:
>>> Test command: /usr/bin/sh
>>> "/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/build/python/qa_square_ff_test.sh"1:
>>> Test timeout computed to be: 10001: Traceback (most recent call
>>> last):1:   File
>>> "/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/python/qa_square_ff.py",
>>> line 12, in 1: from square import square_ff1: ImportError:
>>> cannot import name 'square_ff' from 'square' (unknown location)1: 1: During
>>> handling of the above exception, another exception occurred:1: 1: Traceback
>>> (most recent call last):1:   File
>>> "/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/python/qa_square_ff.py",
>>> line 18, in 1: from square import square_ff1: ImportError:
>>> cannot import name 'square_ff' from 'square' (unknown location)1/1 Test #1:
>>> qa_square_ff .***Failed0.26 sec0% tests passed, 1
>>> tests failed out of 1Total Test time (real) =   0.27 secThe following tests
>>> FAILED:  1 - qa_square_ff (Failed)Errors while running CTest*
>>>
>>

Unknown CMake command "pybind11_add_module" while cmake

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
I am using GNU Radio version: 3.9.1.0 and I want to compile my OOT module.
While running *cmake *I encounter following message:








































*-- The CXX compiler identification is GNU 9.3.0-- The C compiler
identification is GNU 9.3.0-- Check for working CXX compiler:
/usr/bin/c++-- Check for working CXX compiler: /usr/bin/c++ -- works--
Detecting CXX compiler ABI info-- Detecting CXX compiler ABI info - done--
Detecting CXX compile features-- Detecting CXX compile features - done--
Check for working C compiler: /usr/bin/cc-- Check for working C compiler:
/usr/bin/cc -- works-- Detecting C compiler ABI info-- Detecting C compiler
ABI info - done-- Detecting C compile features-- Detecting C compile
features - done-- Build type not specified: defaulting to release.-- Found
LOG4CPP: /usr/lib/x86_64-linux-gnu/liblog4cpp.so-- Found PkgConfig:
/usr/bin/pkg-config (found version "0.29.1") -- Checking for module 'gmp'--
  Found gmp, version 6.2.0-- Found GMP:
/usr/lib/x86_64-linux-gnu/libgmpxx.so  -- Checking for module 'mpir >=
3.0'--   No package 'mpir' found-- Could NOT find MPIR (missing:
MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR) -- Found MPLIB:
/usr/lib/x86_64-linux-gnu/libgmpxx.so  -- Found Boost:
/home/ubuntu/anaconda3/envs/hornet2/lib/cmake/Boost-1.74.0/BoostConfig.cmake
(found suitable version "1.74.0", minimum required is "1.74.0") found
components: date_time program_options filesystem system regex thread --
Found Volk: Volk::volk  -- User set python executable
/home/ubuntu/anaconda3/envs/hornet2/bin/python-- Found PythonInterp:
/home/ubuntu/anaconda3/envs/hornet2/bin/python (found version "3.9.2") --
Found PythonLibs: /home/ubuntu/anaconda3/envs/hornet2/lib/libpython3.9.so
 (found suitable exact version "3.9.2") -- Found
Git: /usr/bin/git  -- Found Doxygen: /usr/bin/doxygen (found version
"1.8.17") found components: doxygen dot -- Using install prefix:
/usr/local-- Building for version: 1.0.0.0 / 1.0.0-- No C++ unit tests...
skipping-- PYTHON and GRC components are enabled-- Python checking for
pygccxml - not foundCMake Error at
/home/ubuntu/anaconda3/envs/hornet2/lib/cmake/gnuradio/GrPybind.cmake:243
(pybind11_add_module):  Unknown CMake command "pybind11_add_module".Call
Stack (most recent call first):  python/bindings/CMakeLists.txt:35
(GR_PYBIND_MAKE_OOT)*

Any guidance is appreciated
Cheers,
Marcin


*-- Configuring incomplete, errors occurred!*
*See also
"/db/Marcin/Gnu_Radio/gr-modulators/build/CMakeFiles/CMakeOutput.log".*
*See also
"/db/Marcin/Gnu_Radio/gr-modulators/build/CMakeFiles/CMakeError.log".*

ModuleNotFoundError while running unit test of the OOT

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
While creating a squaring OOT module (just as an example), my unit test
failed because of *ModuleNotFoundError.*
This error occurs before running *make install*. After running *make
install* module is available and test is passing ok but it doesn't make
sense to do that.
I am using *3.9.3.0 *version of GNU Radio. I expect that after running *make
*there will be a python module called *square *(as I named my OOT, am I
correct?)
Below is the output after running *ctest -VV *command:

Note: below output is obtained after running *make install *and then *make
uninstall *(after make install, module is available and the is no error)


































*UpdateCTestConfiguration  from
:/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/build/DartConfiguration.tclUpdateCTestConfiguration
 from
:/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/build/DartConfiguration.tclTest
project /home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/buildConstructing a
list of testsDone constructing a list of testsUpdating test list for
fixturesAdded 0 tests to meet fixture requirementsChecking test dependency
graph...Checking test dependency graph endtest 1Start 1: qa_square_ff1:
Test command: /usr/bin/sh
"/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/build/python/qa_square_ff_test.sh"1:
Test timeout computed to be: 10001: Traceback (most recent call
last):1:   File
"/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/python/qa_square_ff.py",
line 12, in 1: from square import square_ff1: ImportError:
cannot import name 'square_ff' from 'square' (unknown location)1: 1: During
handling of the above exception, another exception occurred:1: 1: Traceback
(most recent call last):1:   File
"/home/ubuntu/prefixes/gnuradio39/OOTs/gr-square/python/qa_square_ff.py",
line 18, in 1: from square import square_ff1: ImportError:
cannot import name 'square_ff' from 'square' (unknown location)1/1 Test #1:
qa_square_ff .***Failed0.26 sec0% tests passed, 1
tests failed out of 1Total Test time (real) =   0.27 secThe following tests
FAILED:  1 - qa_square_ff (Failed)Errors while running CTest*

Re: UnicodeDecodeError while creating OOT GRC 3.9.1.0

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Vasil,
* py3clean  *helped
Thanks a lot again,
Marcin

śr., 20 paź 2021 o 13:59 Vasil Velichkov  napisał(a):

> Hi Marcin,
>
> On 20/10/2021 14.20, Marcin Puchlik via GNU Radio, the Free & Open-Source
> Toolkit for Software Radio wrote:
>
> > "/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/codecs.py", line 322,
> in
> > decode(result, consumed) = self._buffer_decode(data, self.errors,
> > final)UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe3 in
> position
> > 16: invalid continuation byte*
> >
> > Is this an encoding problem?
>
> See
>
> https://github.com/gnuradio/gnuradio/issues/5068
> https://github.com/gnuradio/gnuradio/issues/2912
>
> Regards,
> Vasil
>

UnicodeDecodeError while creating OOT GRC 3.9.1.0

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
While creating new module using command: *gr_modtool newmod square* I
receive such an error message:

























*Creating out-of-tree module in ./gr-square...Traceback (most recent call
last):  File "/home/ubuntu/anaconda3/envs/hornet2/bin/gr_modtool", line 18,
in cli()  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/click/core.py",
line 829, in __call__return self.main(*args, **kwargs)  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/click/core.py",
line 782, in mainrv = self.invoke(ctx)  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/click/core.py",
line 1259, in invokereturn
_process_result(sub_ctx.command.invoke(sub_ctx))  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/click/core.py",
line 1066, in invokereturn ctx.invoke(self.callback, **ctx.params)
File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/click/core.py",
line 610, in invokereturn callback(*args, **kwargs)  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/gnuradio/modtool/cli/base.py",
line 133, in wrapperreturn func(*args, **kwargs)  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/gnuradio/modtool/cli/newmod.py",
line 47, in clirun(self)  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/gnuradio/modtool/cli/base.py",
line 152, in runmodule.run()  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/site-packages/gnuradio/modtool/core/newmod.py",
line 79, in runs = filetext.read()  File
"/home/ubuntu/anaconda3/envs/hornet2/lib/python3.9/codecs.py", line 322, in
decode(result, consumed) = self._buffer_decode(data, self.errors,
final)UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe3 in position
16: invalid continuation byte*

Is this an encoding problem?

My locale:














*LANG=en_US.UTF-8LANGUAGE=LC_CTYPE="en_US.UTF-8"LC_NUMERIC="en_US.UTF-8"LC_TIME="en_US.UTF-8"LC_COLLATE="en_US.UTF-8"LC_MONETARY="en_US.UTF-8"LC_MESSAGES="en_US.UTF-8"LC_PAPER="en_US.UTF-8"LC_NAME="en_US.UTF-8"LC_ADDRESS="en_US.UTF-8"LC_TELEPHONE="en_US.UTF-8"LC_MEASUREMENT="en_US.UTF-8"LC_IDENTIFICATION="en*
_US.UTF-8"
LC_ALL=en_US.UTF-8

*Additional information:*
*- *GNU Radio version: 3.9.1.0 (installed in anaconda3 environment)
- System: Ubuntu 20.04.3 LTS

Thanks in advance
Marcin

Re: PyBOMBs - available modules

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Jeff,
Thanks for answering my question.
So how would people know about those other recipes like: gnuradio39,
gnuradio-master, gnuradio-stable if they are not present in the recipe list?



pt., 15 paź 2021 o 18:36 Jeff Long  napisał(a):

> The gnuradio39 recipe is used like
>
>pybombs prefix init -R gnuradio39 
>
> and is not a normal recipe. No, there's no real way you would have known
> that, except to look at the recipes that contain
>
>inherit: prefix
>
> As far as I can see, the following recipes are like that
>
>gnuradio39
>gnuradio-default
>gnuradio-master
>gnuradio-stable
>
>
> On Fri, Oct 15, 2021 at 11:17 AM Marcin Puchlik via GNU Radio, the Free &
> Open-Source Toolkit for Software Radio  wrote:
>
>> Hi,
>> Does the command: *pybombs recipes list *gives me a list of all
>> available software I can install using PyBOMBs? If yes, why I cannot see
>> the gnuradio39 recipe but I can still run this recipe and install the GNU
>> Radio 3.9?
>> Thanks in advance,
>> Marcin
>>
>>

PyBOMBs - available modules

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,
Does the command: *pybombs recipes list *gives me a list of all available
software I can install using PyBOMBs? If yes, why I cannot see the
gnuradio39 recipe but I can still run this recipe and install the GNU Radio
3.9?
Thanks in advance,
Marcin

Re: Releases v3.8.4.0 and v3.9.3.0

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

> That's not a boost problem, it's a gcc problem. You have to use at least
> gcc 8 for v3.9.3.0.
> 
> Ron
> 
Thanks for quick help.
 The compiler is GCC 7.5 and there is a warning, it worked somehow with GR 
3.9.2. but now isn't.

--
Wojciech Kazubski

Re: Releases v3.8.4.0 and v3.9.3.0

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

> GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target
> date with hours to spare. For details, see the Github release pages:
> 
> https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0
> https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0
> 
> Next releases are expected in December.

What minimum version of boost is accepted for GNU Radio 3.9.3.0?

It fails to build on both openSUSE 15.2 and 15.3 with boost 1.66. It looks 
like cmake is accepting that version, but no proper boost include dirs are 
passed to the compiler:
...
[  246s] -- Found Boost: /usr/include (found version "1.66.0") found 
components: date_time program_options filesystem system regex thread 
unit_test_framework chrono atomic 
...
[  692s] FAILED: gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/
logger.cc.o 
[  692s] /usr/bin/c++  -DGR_MPLIB_GMP -DGR_PERFORMANCE_COUNTERS -DHAVE_COSF -
DHAVE_GETPAGESIZE -DHAVE_MMAP -DHAVE_PTHREAD_SETSCHEDPARAM -
DHAVE_PTHREAD_SIGMASK -DHAVE_SCHED_SETSCHEDULER -DHAVE_SHM_OPEN -
DHAVE_SIGACTION -DHAVE_SIGNAL_H -DHAVE_SINCOS -DHAVE_SINCOSF -DHAVE_SINF -
DHAVE_SYSCONF -DHAVE_SYS_IPC_H -DHAVE_SYS_MMAN_H -DHAVE_SYS_RESOURCE_H -
DHAVE_SYS_SHM_H -DHAVE_SYS_TYPES_H -DTRY_SHM_VMCIRCBUF -
Dgnuradio_runtime_EXPORTS -Ignuradio-runtime/lib/math -I../gnuradio-runtime/
lib/../include -Ignuradio-runtime/lib/../include -I../gnuradio-runtime/lib -
I../gnuradio-runtime/lib/pmt/../../include -isystem /usr/include/python3.6m -
fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-
protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-
protection -DNDEBUG -fvisibility=hidden -Wsign-compare -Wno-uninitialized -
fcx-limited-range -O2 -g -DNDEBUG -fPIC   -std=c++14 -MD -MT gnuradio-runtime/
lib/CMakeFiles/gnuradio-runtime.dir/logger.cc.o -MF gnuradio-runtime/lib/
CMakeFiles/gnuradio-runtime.dir/logger.cc.o.d -o gnuradio-runtime/lib/
CMakeFiles/gnuradio-runtime.dir/logger.cc.o -c ../gnuradio-runtime/lib/
logger.cc
[  692s] ../gnuradio-runtime/lib/logger.cc:33:10: fatal error: filesystem: No 
such file or directory
[  692s]  #include 
[  692s]   ^~~~
[  692s] compilation terminated.
...

--
Wojciech Kazubski

Regarding an error in the gr-packetizer

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone,
I am currently working on the project "'Implementation of a packet
encoder/decoder pair in the GNU radio framework'".I am getting some an
error while running the project shown as:
Showing:
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug_differential.grc"

Generating:
'/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py'

Executing: /usr/bin/python -u
/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py

Using Volk machine: avx2_64_mmx_orc
Traceback (most recent call last):
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 810, in 
main()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 798, in main
tb = top_block_cls()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 506, in __init__
self.packetizer_preamble_header_payload_demux_0 =
packetizer.preamble_header_payload_demux(32/constel_header.bits_per_symbol(),
1, 0, "packet_len", "corr_est", False, gr.sizeof_gr_complex, "rx_time",
samp_rate, ("phase_est","time_est"), 0, len(preamble),
constel_payload.bits_per_symbol())
AttributeError: 'module' object has no attribute
'preamble_header_payload_demux'

Hence, I am not able to generate any type of data. So, any leads will be
thankful.

- Thanks and Regards
Yash Agrawal
Electrical Engineering and Computer Sciences Department
18410

Regarding an error in the gr-packetizer

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone,
I am currently working on the project "'Implementation of a packet
encoder/decoder pair in the GNU radio framework'".I am getting some an
error while running the project shown as:
Showing:
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug_differential.grc"

Generating:
'/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py'

Executing: /usr/bin/python -u
/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py

Using Volk machine: avx2_64_mmx_orc
Traceback (most recent call last):
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 810, in 
main()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 798, in main
tb = top_block_cls()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 506, in __init__
self.packetizer_preamble_header_payload_demux_0 =
 packetizer.preamble_header_payload_demux(32/constel_header.bits_per_symbol(),
1, 0, "packet_len", "corr_est", False, gr.sizeof_gr_complex, "rx_time",
samp_rate, ("phase_est","time_est"), 0, len(preamble),
constel_payload.bits_per_symbol())
AttributeError: 'module' object has no attribute
'preamble_header_payload_demux'

Hence, I am not able to generate any type of data. So, any leads will be
thankful.

-* Thanks and Regards*
*Yash Agrawal*

*Electrical Engineering and Computer Sciences Department*
*18410*

Regarding an error in the gr-packetizer

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

  Hello everyone,
I am currently working on the project "'Implementation of a packet
encoder/decoder pair in the GNU radio framework'".I am getting some an
error while running the project shown as:
Showing:
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug_differential.grc"

Generating:
'/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py'

Executing: /usr/bin/python -u
/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py

Using Volk machine: avx2_64_mmx_orc
Traceback (most recent call last):
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 810, in 
main()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 798, in main
tb = top_block_cls()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 506, in __init__
self.packetizer_preamble_header_payload_demux_0 =
 packetizer.preamble_header_payload_demux(32/constel_header.bits_per_symbol(),
1, 0, "packet_len", "corr_est", False, gr.sizeof_gr_complex, "rx_time",
samp_rate, ("phase_est","time_est"), 0, len(preamble),
constel_payload.bits_per_symbol())
AttributeError: 'module' object has no attribute
'preamble_header_payload_demux'

Hence, I am not able to generate any type of data. So, any leads will be
thankful.

-* Thanks and Regards*
*Yash Agrawal*

*Electrical Engineering and Computer Sciences Department*
*18410*

Regarding an error in the gr-packetizer

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone,
I am currently working on the project "'Implementation of a packet
encoder/decoder pair in the GNU radio framework'".I am getting some an
error while running the project shown as:
Showing:
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug_differential.grc"

Generating:
'/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py'

Executing: /usr/bin/python -u
/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py

Using Volk machine: avx2_64_mmx_orc
Traceback (most recent call last):
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 810, in 
main()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 798, in main
tb = top_block_cls()
  File
"/home/dragon/chchc/gnuradioproject-master/gr-packetizer/examples/chain_rx_debug.py",
line 506, in __init__
self.packetizer_preamble_header_payload_demux_0 =
 packetizer.preamble_header_payload_demux(32/constel_header.bits_per_symbol(),
1, 0, "packet_len", "corr_est", False, gr.sizeof_gr_complex, "rx_time",
samp_rate, ("phase_est","time_est"), 0, len(preamble),
constel_payload.bits_per_symbol())
AttributeError: 'module' object has no attribute
'preamble_header_payload_demux'

Hence, I am not able to generate any type of data. So, any leads will be
thankful.

-* Thanks and Regards*
*Yash Agrawal*

*Electrical Engineering and Computer Sciences Department*
*18410*

Regarding the error in creating an OOT module in GR3.9

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone,
 am currently working on the project "'Implementation of a packet
encoder/decoder pair in the GNU radio framework'".I am getting some serious
errors while running the project on the above mentioned environment shown
as:
merlin@merlin:~/chchc/gnuradioproject-master/gr-packetizer/build$ make
Scanning dependencies of target gnuradio-packetizer
[  3%] Building CXX object
lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o
/home/merlin/chchc/gnuradioproject-master/gr-packetizer/lib/preamble_header_payload_demux_impl.cc:
In static member function ‘static
gr::packetizer::preamble_header_payload_demux::sptr
gr::packetizer::preamble_header_payload_demux::make(int, int, int, const
string&, const string&, bool, size_t, const string&, double, const
std::vector >&, size_t, int, int)’:
/home/merlin/chchc/gnuradioproject-master/gr-packetizer/lib/preamble_header_payload_demux_impl.cc:90:9:
error: could not convert ‘gnuradio::get_initial_sptr(T*) [with T =
gr::packetizer::preamble_header_payload_demux_impl]()’ from
‘std::shared_ptr’ to
‘gr::packetizer::preamble_header_payload_demux::sptr {aka
boost::shared_ptr}’
   return gnuradio::get_initial_sptr
  ~~
 (new preamble_header_payload_demux_impl(
 ^~~~
   header_len,
   ~~~
   items_per_symbol,
   ~
   guard_interval,
   ~~~
   length_tag_key,
   ~~~
   trigger_tag_key,
   
   output_symbols,
   ~~~
   itemsize,
   ~
   timing_tag_key,
   ~~~
   samp_rate,
   ~~
   special_tags,
   ~
   header_padding,
   ~~~
   preamble_len,
   ~
   header_len_divider
   ~~
 ));
 ~~
lib/CMakeFiles/gnuradio-packetizer.dir/build.make:62: recipe for target
'lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o'
failed
make[2]: ***
[lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o]
Error 1
CMakeFiles/Makefile2:174: recipe for target
'lib/CMakeFiles/gnuradio-packetizer.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-packetizer.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

My current working environment is gnuradio 3.9 on ubuntu 18.04. Hence any
leads will be thankful.
-* Thanks and Regards*
*Yash Agrawal*

*Electrical Engineering and Computer Sciences Department*
*18410*

Regarding the error in creating an OOT module in GR3.9

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello everyone,
I am currently working on gnuradio 3.9 on ubuntu 18.04 and currently facing
an error while creating an OOT module using the terminal which is shown as:
merlin@merlin:~/yash$ gr_modtool newmod packetizer
Creating out-of-tree module in ./gr-packetizer...
Traceback (most recent call last):
  File "/usr/bin/gr_modtool", line 18, in 
cli()
  File "/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
133, in wrapper
return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/newmod.py",
line 47, in cli
run(self)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
152, in run
module.run()
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/newmod.py",
line 79, in run
s = filetext.read()
  File "/usr/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbf in position 4:
invalid start byte

Hence, I want to resolve this issue as soon as possible.

Also, I am currently working on the project "'Implementation of a packet
encoder/decoder pair in the GNU radio framework'".I am getting some serious
errors while running the project on the above mentioned environment shown
as:
merlin@merlin:~/chchc/gnuradioproject-master/gr-packetizer/build$ make
Scanning dependencies of target gnuradio-packetizer
[  3%] Building CXX object
lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o
/home/merlin/chchc/gnuradioproject-master/gr-packetizer/lib/preamble_header_payload_demux_impl.cc:
In static member function ‘static
gr::packetizer::preamble_header_payload_demux::sptr
gr::packetizer::preamble_header_payload_demux::make(int, int, int, const
string&, const string&, bool, size_t, const string&, double, const
std::vector >&, size_t, int, int)’:
/home/merlin/chchc/gnuradioproject-master/gr-packetizer/lib/preamble_header_payload_demux_impl.cc:90:9:
error: could not convert ‘gnuradio::get_initial_sptr(T*) [with T =
gr::packetizer::preamble_header_payload_demux_impl]()’ from
‘std::shared_ptr’ to
‘gr::packetizer::preamble_header_payload_demux::sptr {aka
boost::shared_ptr}’
   return gnuradio::get_initial_sptr
  ~~
 (new preamble_header_payload_demux_impl(
 ^~~~
   header_len,
   ~~~
   items_per_symbol,
   ~
   guard_interval,
   ~~~
   length_tag_key,
   ~~~
   trigger_tag_key,
   
   output_symbols,
   ~~~
   itemsize,
   ~
   timing_tag_key,
   ~~~
   samp_rate,
   ~~
   special_tags,
   ~
   header_padding,
   ~~~
   preamble_len,
   ~
   header_len_divider
   ~~
 ));
 ~~
lib/CMakeFiles/gnuradio-packetizer.dir/build.make:62: recipe for target
'lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o'
failed
make[2]: ***
[lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o]
Error 1
CMakeFiles/Makefile2:174: recipe for target
'lib/CMakeFiles/gnuradio-packetizer.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-packetizer.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

Hence, any leads will be thankful.
-Thanks and *Regards*
*Yash Agrawal*

*Electrical Engineering and Computer Sciences Department*
*18410*

Regarding installation of gnuradio 3.7.10

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello Everyone,
I am a beginner to this community and currently started working on a
project of gnuradio named 'Implementation of a packet encoder/decoder pair
in the GNU radio framework'. I am using Ubuntu version 16.04 currently. I
am facing an issue installing a particular version (3.7.10) of gnu radio.
Although I tried to follow the command for installing gnuradio 3.7, I
always get installed the 3.7.9 version of it. But I want version 3.7.10 or
greater for the gnuradio 3.7. Hence, I am really stuck here. I will be
thankful for any leads.

Thanks in advance.
-* Regards*
*Yash Agrawal*

*Electrical Engineering and Computer Sciences Department*
*18410*

Re: Transport stream source

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello.
If the question is, how can one receive an multicast udp transport stream
into udp  gr source block?

as a test, i've an encoder that encodes a transport stream to udp://
239.255.42.42:5004  -

 socat udp4-recv:5004,ip-add-membership=239.255.42.42.0:0.0.0
udp4-sendto:192.168.12.12:5006

now send it back out using multicast address 239.255.99.99: 5008 from gr
block -

[image: mc.png]


On Sat, Apr 3, 2021 at 2:48 PM Ralf Gorholt  wrote:

> Dear all,
>
> instead of using a file source, I would like to get data from a video
> stream into GNU Radio. Is this possible?
>
> With VLC, I can connect to the stream using a URL like
> udp://230.0.0.10:1234. How can I do this in GNU Radio? I have tried to
> use a UDP source with this address and payload size 1316 (needed for VLC
> when it connects to a UDP sink in GNU Radio) and to pass the data to a
> UDP sink at address 230.0.0.20:1 and payload size 1316 to which I
> can connect with VLC to see if it works but when I start the flow graph,
> nothing seems to come out, VLC tries in vain to connect.
>
> Thank you very much and happy easter!
>
> Kind regards,
>
> Ralf
>
>

-- 
If something is requisite, how can it possibly be, prerequisite?

vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo

Cross compile gnuradio in E312 error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

How to change the IP address of E312.

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Re: Problem initializing parameters in Gnuradio Python Block?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

 George,
What is happening is that when you try to change the variable Python is 
interpreting that as a local variable and has no value yet for the equation you 
are attempting. I believe could use:
global vv[0] += v[0]
(Research the Python global keyword)
However, in the GNURadio universe I really think you may be better off using 
self.v instead.
Tim

On Thursday, January 14, 2021, 11:42:46 AM EST, George Edwards 
 wrote:  
 
 Hell Tim and Jeff,
Problem, so when I make v global in my_init() method and use it is the work() 
method, it works good if I do not try to change the values in the vector v, 
let's say v came down as v = np.array([1.0 , 1.0 , 1.0]). If I try to change 
the values say  v[0] += v[0], etc. the program breaks with the message local 
variable v changes before assignment. I thought it was global and already 
assigned.
Thanks for your help.
George 

On Thu, Jan 14, 2021 at 9:17 AM George Edwards  wrote:

Hi Tim and Jeff,
Thanks for your help and insights. Being new to Python, I was looking at some 
Python videos and found my solution, I will make the numpy parameter vectors in 
the my_init() method "global" and that should solve the problem.
Thank you!
Regards,George
On Thu, Jan 14, 2021 at 9:57 AM Tim Huggins  wrote:

 George,
"My understanding is the self.x, etc. is used to initialize param arguments in 
the def __init__() method and in my case, the only argument in this method is 
start"


This is not correct, you can add a self.v in there so it looks like:
def __init__(self,  start = True):  # only default arguments here    
gr.sync_block.__init__(
    self,
    name='text',   # will show up in GRC
    in_sig=[()],
    out_sig=[()]
    )
    # if an attribute with the same name as a parameter is found,
    # a callback is registered (properties work, too).
    self.start = start
    self.v = self.my_init() #or whatever you want the  initial value to be

Tim


On Thursday, January 14, 2021, 10:38:36 AM EST, George Edwards 
 wrote:  
 
 Hi Jeff,
So I am new to Python programming, so some of the nuances I am not up on yet. 
My understanding is the self.x, etc. is used to initialize param arguments in 
the def __init__() method and in my case, the only argument in this method is 
start, there is no v for me to use self.v = v. v is used the work() and 
my_init() methods. At program startup work() calls my_init() method to get the 
initial values for the numpy array v (my_init() function will be called once 
only at startup when self.start is True). After initialization and v is passed 
back to the work(), the values in the numpy array v inside work will change on 
a sample to sample computation basis. My problem is how do I assign v its 
initial seed value at start up. If my program was simple with only one 
parameter v, I would initialize it inside the work() method, however, I have a 
bunch of other vector variables to initialize which is why I want to initialize 
all parameters inside a my_init() method that work() calls at startup. 
Thanks for the help.
George
On Thu, Jan 14, 2021 at 8:14 AM Jeff Long  wrote:

You are already initializing self.start in exactly the same way you should be 
initializing self.v, right?
On Wed, Jan 13, 2021 at 10:46 PM George Edwards  wrote:

Hi Jeff,
Thanks for your answer. You are right, it crashes on the second call.
So how do I write the program to initialize a bunch of vectors in a "method 
strictly for initialization" when it first starts running? If this cannot be 
done, then I guess the only solution is to initialize them in the work() method 
even though it would make the work() method bulky?

Thanks again for your help.
Regards,George
On Wed, Jan 13, 2021 at 8:12 PM Jeff Long  wrote:

'v' is a local variable in work(). It is probably crashing on the second call, 
where my_init() is not called, and thus there is no 'v'.
On Wed, Jan 13, 2021 at 7:38 PM George Edwards  wrote:

Hello,

I am using a Gnuradio Python Block in my GRC signal processing and am having 
problems initializing my parameters. My system has a number of vector 
parameters to be initialized at startup. I will provide the gist of my goal in 
a scaled down version of my work. 1. In the def __init__(self, start = True)  
method, "start" is the parameter that will be used in the program to run the 
initialization process and is set as follows:         self.start = start 2. In 
the work(self, input_items, output_items)  method, I have the following at the 
start of the method:         if self.start == True:                v = 
self.my_init()    # go initialize all vectors
         output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2]  #computation 
using v                                                     # with 3-inputs to 
the block 
3. In the my_init(self) method I have:         self.start = False            # 
set start to False         v = np.array([1., 2., 3.])  #hypothetical to make 
this simple         return v
Whe

Gnu radio achieves rounding?

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Re: R: Cannot run a command

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

 That simply means that you need to install PIP on your machine which should be 
accomplished with:
sudo apt update
sudo apt install python-pipMost of these errors that you are encountering with 
this script seem to be from missing packages.
Tim

On Tuesday, September 1, 2020, 9:43:44 AM EDT, Vincenzo Mone 
 wrote:  
 
 Hello Fabian,
thanks for your reply/help
tried to give the command:

pip2 install PyQt5 

but I get this:

Command "pip2" not found, perhaps it meant:

  command "pipx" from deb pipx (0.12.3.1-2ubuntu1)
  command "pip3" from deb python3-pip (20.0.2-5ubuntu1)
  command "nip2" from deb nip2 (8.7.0-1)

Try: sudo apt install 

Any advices?
Thanks

73’s de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




  *
  **   GSM  +39 328 7110193  **
  *     SMS  +39 328 7110193    *
  *

> -Messaggio originale-
> Da: Discuss-gnuradio 
> Per conto di Fabian Schwartau
> Inviato: martedì 1 settembre 2020 15:31
> A: discuss-gnuradio@gnu.org
> Oggetto: Re: Cannot run a command
> 
> Hi Vincenzo,
> 
> urllib2 is not available in Python3 any more, as far as I know. So this
seens to
> be a Python2 script. Use
> pip2 install PyQt5
> to install PyQt, then it should work. Keep in mind that Python2 is out of
date
> and should not be used any more.
> 
> Best regards,
> Fabian
> 
> Am 01.09.20 um 11:22 schrieb Vincenzo Mone:
> > Hello ,
> >
> > I have installed UBUNTU 20.4 and have to run one of these commands:
> >
> >
> >
> > python2
> > ~/gr-lilacsat-pyqt5/examples/BY70-2/DSLWP-Downlink-
> Proxy/mun_downlink_
> > proxy.py
> >
> > or
> >
> > python3
> > ~/gr-lilacsat-pyqt5/examples/BY70-2/DSLWP-Downlink-
> Proxy/mun_downlink_
> > proxy.py
> >
> >
> >
> > but no one works for my purpose.
> >
> > If I run:
> >
> >
> >
> > python2
> > ~/gr-lilacsat-pyqt5/examples/BY70-2/DSLWP-Downlink-
> Proxy/mun_downlink_
> > proxy.py
> >
> >
> >
> > I get:
> >
> >
> >
> > Traceback (most recent call last):
> >
> >   File
> > "/home/enzo/gr-lilacsat-pyqt5/examples/BY70-2/DSLWP-Downlink-
> Proxy/mun
> > _downlink_proxy.py",
> > line 31, in 
> >
> >     from PyQt5 import QtGui, QtCore, Qt, QtWidgets
> >
> > ImportError: No module named PyQt5
> >
> >
> >
> > If I run:
> >
> >
> >
> > python3
> > ~/gr-lilacsat-pyqt5/examples/BY70-2/DSLWP-Downlink-
> Proxy/mun_downlink_
> > proxy.py
> >
> >
> >
> > I get:
> >
> >
> >
> > Traceback (most recent call last):
> >
> >   File
> > "/home/enzo/gr-lilacsat-pyqt5/examples/BY70-2/DSLWP-Downlink-
> Proxy/mun
> > _downlink_proxy.py",
> > line 29, in 
> >
> >     import urllib2
> >
> > ModuleNotFoundError: No module named 'urllib2'
> >
> >
> >
> > Please which is the correct command and how to solve the error?
> >
> > Thanks
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 73’s de Enzo IK8OZV
> > EasyLog 5 BetaTester
> > EasyLog PDA BetaTester
> > WinBollet BetaTester
> > D.C.I. CheckPoint Regione Campania
> > Skype: ik8ozv8520
> >
> >
> >
> >
> >   *
> >
> >   **   GSM  +39 328 7110193  **
> >
> >   * SMS  +39 328 7110193    *
> >
> >   *
> >
> >
> >


  

Re: GSoC 2020: gr-dpd - New blogpost for Week 4

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hello Alekh,

glad to hear about your progress on this topic that interests me much
even though I don't have time to work on it anymore.

I did work on DPD for Digital Audio Broadcasting some time ago.[1]


Regarding what you mention here:

> - Getting to work upon the synchronisation of signal for making this
> module useful for real-world physicals applications.

This is quite important, and (at least in our application), I found out
that aligning samples wasn't sufficient. Subsample alignment was necessary.


We tried two ways:

1. upsample - find correlation peak - downsample, which was quite costly

2. coarse correlation to sample accuracy using correlation peak, then
subsample delay estimation, inspired by this:
https://www.dsprelated.com/showarticle/26.php
https://www.dsprelated.com/showcode/207.php

The second option worked better.

All this to say that it's worth looking into subsample alignment.


I'm very curious to hear about your findings on this aspect, and of
course on the whole topic of DPD. All the best!
mpb

[1]
Application: 8192 ksps samplerate, 1.5MHz effective signal bandwidth,
transmitted in Band III (around 200MHz)

We went so far as to do a memoryless polynomial predistorter, in C++
inside odr-dabmod, and the alignment and coefficient calculation was
done using SciPy.
https://github.com/Opendigitalradio/ODR-DabMod/tree/master/python