date:20221026

Re: How can you force the Scheduler to deliver appropriate vector size input

2022-10-26 Thread Marcus Müller

Hi George,

I can't really follow. A block in GNU Radio has a *fixed* output item size. So, the Stream
To Vector block *can* only produce items of size (448*sizeof(entry in the vector)). That
can't change!

Same with your block: it has an io_signature (you set it in the constructor), which fixes
its input size. There's nothing that could change that; unless GNU Radio really has a
*fatal* bug.

So please tell us how exactly you notice / observe this change in input vector
length!

Best regards,
Marcus

On 26.10.22 03:24, George Edwards wrote:

Hello GNURadio Community,

I designed an OOT block to accept vectors of size 448 samples. In the flowgraph, my block
is preceded a Stream-to-Vector block with the vector size set to 448 samples. My OOT block
expects vector data that are of length 448 or multiple of 448 samples for signal
processing. I dumped the output of my block to a file and noticed that the first 1000
values were correct and the rest garbage. I put a print statement in the code to see the
length of the input samples that the Scheduler provided on each iteration. I found out
that the inputs were 496 and multiples of 496 (obviously not integer multiple of my
vector length of 448 samples). Is there a way to force the Scheduler to deliver input data
samples that are the exactly 448 and multiple of 448 samples (which I thought I would be
getting by setting the vector size parameter to 448)?

I am aware that the alternative may be to pad the data entering the Stream-to-Vector block
which precedes my OOT Block with 48 dummy samples and in my signal processing remove them.

I will appreciate any response that leads to me keeping the vector size at 448 and having
the Scheduler provide input data that are of size 448 or integer multiples of 448.

Regards,
George

smime.p7s
Description: S/MIME Cryptographic Signature

Help Needed for "Channel Model" Block

2022-10-26 Thread Shuvodip Majumdar

Hello all,

Greetings of the day!

I am going through the GNU Radio tutorials and currently I am at the "QPSK
Mod and Demod" chapter.

Here, in the "mpsk_stage_2.grc" project, a "Channel Model" block has been
used. My question is about some fields of this block:

*1.* I checked from the details of that particular block that "frequency
offset" is entered in terms of a fraction of the "symbol rate". Now my
doubt is about the fact that nowhere in the block the "symbol rate" is
input. Then how can this block calculate the "frequency offset" having the
fraction data only in hand?

I am aware of the fact that there are variables "sample rate" and "sps
(samples per symbol)" in the design. However, when the data enters the
"Channel Model" block, they are entering as samples at a particular
"sampling rate". This "Channel Model" does not have any information about
how many samples represent one symbol.

*2.* In the "Taps" field, "1" has been given in the example. However, I
checked from the details of that particular block that for no multipath
case it should be "1+1j". I have also observed changes in the
"Constellation Sink" plot for these two values. What is the difference
between the "1" and "1+1j" applied in the "Taps" field?

Thank you.

With regards,
Shuvodip Majumdar

Re: Help Needed for FREQUENCY SINK Block of GNU Radio

2022-10-26 Thread Shuvodip Majumdar

Dear Kyeong,

Thank you very much. It worked perfect.

Regards,
Shuvodip


On Wed, 26 Oct, 2022, 17:43 Kyeong Su Shin,  wrote:

> Hello Shuvodip:
>
> It simply takes STFT of the raw input data after applying a windowing
> function to them. No further calibrations or amplitude corrections are
> applied.
>
> You will get an 0 dB peak if you turn off the windowing function (set it
> to "rectangular") and if the signal is not leaking into multiple bins.
>
> Regards,
> Kyeong Su Shin
> --
> *보낸 사람:* Shuvodip Majumdar  대신 Discuss-gnuradio <
> discuss-gnuradio-boun...@gnu.org>
> *보낸 날짜:* 2022년 10월 26일 수요일 오후 8:45
> *받는 사람:* discuss-gnuradio@gnu.org 
> *제목:* Help Needed for FREQUENCY SINK Block of GNU Radio
>
> Hello all,
>
> The Frequency Sink block of GNU Radio gives a spectrum plot where the
> y-axis is labelled as "Relative Gain (dB)".
>
> My question is that with respect to what this "relative" data is being
> taken?
>
> I plotted one 1*e^(j*2*pi*f*t) and in the spectrum response I got -8.7 dB
> at frequency f. I am confused about how this calculation is being done.
>
> Thank you.
>
> With regards,
> Shuvodip
>

Re: How can you force the Scheduler to deliver appropriate vector size input

2022-10-26 Thread George Edwards

Good morning Marcus,

Thanks for your response and sharing your thoughts.

My understanding is that things should work exactly as you say. My
flowgraph has two custom built OOT blocks. Based on my signal processing
algorithms, one takes in vectors of size 200 and the other 448. The one
that takes input vectors of size 200 works beautifully and the input is
either 200 or integer multiples of 200. The OOT block that was designed to
take a vector of size 448 which I specified in its input signature and the
stream-to-vector block which connects to its input was specified to have a
vector of 448 items, however, the OOT signal processing fails. I inserted a
print statement in the code and found the reason for the failure was due to
the number of input items being 496 or multiples of 496 and not 448 or
multiples of 448 which the signal processing algorithm expects.

Thanks again for sharing your thoughts,  I appreciate it.
George

On Wed, Oct 26, 2022, 5:16 AM Marcus Müller  wrote:

> Hi George,
>
> I can't really follow. A block in GNU Radio has a *fixed* output item
> size. So, the Stream
> To Vector block *can* only produce items of size (448*sizeof(entry in the
> vector)). That
> can't change!
>
> Same with your block: it has an io_signature (you set it in the
> constructor), which fixes
> its input size. There's nothing that could change that; unless GNU Radio
> really has a
> *fatal* bug.
>
> So please tell us how exactly you notice / observe this change in input
> vector length!
>
> Best regards,
> Marcus
>
> On 26.10.22 03:24, George Edwards wrote:
> > Hello GNURadio Community,
> >
> > I designed an OOT block to accept vectors of size 448 samples. In the
> flowgraph, my block
> > is preceded a Stream-to-Vector block with the vector size set to 448
> samples. My OOT block
> > expects vector data that are of length 448 or multiple of 448 samples
> for signal
> > processing. I dumped the output of my block to a file and noticed that
> the first 1000
> > values were correct and the rest garbage. I put a print statement in the
> code to see the
> > length of the input samples that the Scheduler provided on each
> iteration. I found out
> > that the inputs were 496 and multiples of 496 (obviously not integer
> multiple of my
> > vector length of 448 samples). Is there a way to force the Scheduler to
> deliver input data
> > samples that are the exactly 448 and multiple of 448 samples (which I
> thought I would be
> > getting by setting the vector size parameter to 448)?
> >
> > I am aware that the alternative may be to pad the data entering the
> Stream-to-Vector block
> > which precedes my OOT Block with 48 dummy samples and in my signal
> processing remove them.
> >
> > I will appreciate any response that leads to me keeping the vector size
> at 448 and having
> > the Scheduler provide input data that are of size 448 or integer
> multiples of 448.
> >
> > Regards,
> > George
>

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

2022-10-26 Thread 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://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 ..
> > -- Buil

Re: How can you force the Scheduler to deliver appropriate vector size input

2022-10-26 Thread George Edwards

Hi Marcus,
I have egg on my face! I messed up, Gnuradio works fine. I accidentally set
one of the variables in the grc which contributes to the computation of the
vector length incorrectly and made the size 496. Sometimes in the midst of
these problems, we overlook the obvious. My mistake!
Sorry for taking up your time and the community time.
Thanks again for your feedback!
George

On Wed, Oct 26, 2022, 5:16 AM Marcus Müller  wrote:

> Hi George,
>
> I can't really follow. A block in GNU Radio has a *fixed* output item
> size. So, the Stream
> To Vector block *can* only produce items of size (448*sizeof(entry in the
> vector)). That
> can't change!
>
> Same with your block: it has an io_signature (you set it in the
> constructor), which fixes
> its input size. There's nothing that could change that; unless GNU Radio
> really has a
> *fatal* bug.
>
> So please tell us how exactly you notice / observe this change in input
> vector length!
>
> Best regards,
> Marcus
>
> On 26.10.22 03:24, George Edwards wrote:
> > Hello GNURadio Community,
> >
> > I designed an OOT block to accept vectors of size 448 samples. In the
> flowgraph, my block
> > is preceded a Stream-to-Vector block with the vector size set to 448
> samples. My OOT block
> > expects vector data that are of length 448 or multiple of 448 samples
> for signal
> > processing. I dumped the output of my block to a file and noticed that
> the first 1000
> > values were correct and the rest garbage. I put a print statement in the
> code to see the
> > length of the input samples that the Scheduler provided on each
> iteration. I found out
> > that the inputs were 496 and multiples of 496 (obviously not integer
> multiple of my
> > vector length of 448 samples). Is there a way to force the Scheduler to
> deliver input data
> > samples that are the exactly 448 and multiple of 448 samples (which I
> thought I would be
> > getting by setting the vector size parameter to 448)?
> >
> > I am aware that the alternative may be to pad the data entering the
> Stream-to-Vector block
> > which precedes my OOT Block with 48 dummy samples and in my signal
> processing remove them.
> >
> > I will appreciate any response that leads to me keeping the vector size
> at 448 and having
> > the Scheduler provide input data that are of size 448 or integer
> multiples of 448.
> >
> > Regards,
> > George
>

Re: How can you force the Scheduler to deliver appropriate vector size input

2022-10-26 Thread Marcus Müller

Haha! Perfect :) Glad you solved the issue! And absolutely no reason to be 
sorry!

On 26.10.22 17:04, George Edwards wrote:

Hi Marcus,
I have egg on my face! I messed up, Gnuradio works fine. I accidentally set one of the 
variables in the grc which contributes to the computation of the vector length incorrectly 
and made the size 496. Sometimes in the midst of these problems, we overlook the obvious. 
My mistake!

Sorry for taking up your time and the community time.
Thanks again for your feedback!
George

On Wed, Oct 26, 2022, 5:16 AM Marcus Müller mailto:muel...@kit.edu>> wrote:

Hi George,

I can't really follow. A block in GNU Radio has a *fixed* output item size. 
So, the
Stream
To Vector block *can* only produce items of size (448*sizeof(entry in the 
vector)). That
can't change!

Same with your block: it has an io_signature (you set it in the 
constructor), which fixes
its input size. There's nothing that could change that; unless GNU Radio 
really has a
*fatal* bug.

So please tell us how exactly you notice / observe this change in input 
vector length!

Best regards,
Marcus

On 26.10.22 03:24, George Edwards wrote:
 > Hello GNURadio Community,
 >
 > I designed an OOT block to accept vectors of size 448 samples. In the 
flowgraph, my
block
 > is preceded a Stream-to-Vector block with the vector size set to 448 
samples. My
OOT block
 > expects vector data that are of length 448 or multiple of 448 samples 
for signal
 > processing. I dumped the output of my block to a file and noticed that 
the first 1000
 > values were correct and the rest garbage. I put a print statement in the 
code to
see the
 > length of the input samples that the Scheduler provided on each 
iteration. I found out
 > that the inputs were 496 and multiples of 496 (obviously not integer 
multiple of my
 > vector length of 448 samples). Is there a way to force the Scheduler to 
deliver
input data
 > samples that are the exactly 448 and multiple of 448 samples (which I 
thought I
would be
 > getting by setting the vector size parameter to 448)?
 >
 > I am aware that the alternative may be to pad the data entering the
Stream-to-Vector block
 > which precedes my OOT Block with 48 dummy samples and in my signal 
processing
remove them.
 >
 > I will appreciate any response that leads to me keeping the vector size 
at 448 and
having
 > the Scheduler provide input data that are of size 448 or integer 
multiples of 448.
 >
 > Regards,
 > George

smime.p7s
Description: S/MIME Cryptographic Signature

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

2022-10-26 Thread Marcus Müller


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://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://xahlee.info/UnixResource_dir/_/ldpath.html

 >

Re: How can you force the Scheduler to deliver appropriate vector size input

2022-10-26 Thread George Edwards

Thank you very much! George

On Wed, Oct 26, 2022, 9:51 AM Marcus Müller  wrote:

> Haha! Perfect :) Glad you solved the issue! And absolutely no reason to be
> sorry!
>
> On 26.10.22 17:04, George Edwards wrote:
> > Hi Marcus,
> > I have egg on my face! I messed up, Gnuradio works fine. I accidentally
> set one of the
> > variables in the grc which contributes to the computation of the vector
> length incorrectly
> > and made the size 496. Sometimes in the midst of these problems, we
> overlook the obvious.
> > My mistake!
> > Sorry for taking up your time and the community time.
> > Thanks again for your feedback!
> > George
> >
> > On Wed, Oct 26, 2022, 5:16 AM Marcus Müller  muel...@kit.edu>> wrote:
> >
> > Hi George,
> >
> > I can't really follow. A block in GNU Radio has a *fixed* output
> item size. So, the
> > Stream
> > To Vector block *can* only produce items of size (448*sizeof(entry
> in the vector)). That
> > can't change!
> >
> > Same with your block: it has an io_signature (you set it in the
> constructor), which fixes
> > its input size. There's nothing that could change that; unless GNU
> Radio really has a
> > *fatal* bug.
> >
> > So please tell us how exactly you notice / observe this change in
> input vector length!
> >
> > Best regards,
> > Marcus
> >
> > On 26.10.22 03:24, George Edwards wrote:
> >  > Hello GNURadio Community,
> >  >
> >  > I designed an OOT block to accept vectors of size 448 samples. In
> the flowgraph, my
> > block
> >  > is preceded a Stream-to-Vector block with the vector size set to
> 448 samples. My
> > OOT block
> >  > expects vector data that are of length 448 or multiple of 448
> samples for signal
> >  > processing. I dumped the output of my block to a file and noticed
> that the first 1000
> >  > values were correct and the rest garbage. I put a print statement
> in the code to
> > see the
> >  > length of the input samples that the Scheduler provided on each
> iteration. I found out
> >  > that the inputs were 496 and multiples of 496 (obviously not
> integer multiple of my
> >  > vector length of 448 samples). Is there a way to force
> the Scheduler to deliver
> > input data
> >  > samples that are the exactly 448 and multiple of 448 samples
> (which I thought I
> > would be
> >  > getting by setting the vector size parameter to 448)?
> >  >
> >  > I am aware that the alternative may be to pad the data entering
> the
> > Stream-to-Vector block
> >  > which precedes my OOT Block with 48 dummy samples and in my
> signal processing
> > remove them.
> >  >
> >  > I will appreciate any response that leads to me keeping the
> vector size at 448 and
> > having
> >  > the Scheduler provide input data that are of size 448 or integer
> multiples of 448.
> >  >
> >  > Regards,
> >  > George
> >
>

unsubscribe

2022-10-26 Thread Teyssier, Luke

unsubscribe

Re:unsubscribe

2022-10-26 Thread cto


   unsubscribe

Re: unsubscribe

2022-10-26 Thread Marcus Müller


You're so close!

Write that email with subject "unsubscribe" to discuss-gnuradio-requ...@gnu.org , INSTEAD 
of to discuss-gnuradio@gnu.org , or use the self-administration website: 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 



Best,
Marcus

On 26.10.22 20:28, c...@origosat.com wrote:

unsubscribe


smime.p7s
Description: S/MIME Cryptographic Signature

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

2022-10-26 Thread 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://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 ( > >) 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 t

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

2022-10-26 Thread Marcus Müller

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 (>) 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://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

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

2022-10-26 Thread 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 ( > >) 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
> > 
> >  >  > >
> >  > 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:
> >  >
> >

Re: How can you force the Scheduler to deliver appropriate vector size input

Help Needed for "Channel Model" Block

Re: Help Needed for FREQUENCY SINK Block of GNU Radio

Re: How can you force the Scheduler to deliver appropriate vector size input

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

Re: How can you force the Scheduler to deliver appropriate vector size input

Re: How can you force the Scheduler to deliver appropriate vector size input

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

Re: How can you force the Scheduler to deliver appropriate vector size input

unsubscribe

Re:unsubscribe

Re: unsubscribe

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

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

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

15 matches

Site Navigation

Mail list logo

Footer information