Re: Round trip time calculation - simulation

Hi Jiya,

some inline comments.

On 31.08.23 12:35, Jiya Johnson wrote:
> Hi Johannes,
> Thanks in advance for your valuable inputs!
> I appreciate your help so much.
>
> 1.I want to measure the time taken by 1 sample from the random source to
> the decoder unit-endpoint.
My previous comment was targeted at the fact that FEC encoders and
decoders work on blocks or frames. The concept of single samples or bits
and how long they take to propagate through a flowgraph is probably not
a good measure. It would probably make more sense to look at FEC frames
and how long they take to propagate through a flowgraph.
Depending on the exact position in your flowgraph, an FEC frame might
imply that these are the info bits or a codeword.

> 2.Need more clarifications in throttle usage in terms of latency.
The throttle block measures how many samples it passed to the output
during a time period and will just stall if more samples could pass through.
The GR buffer architecture tries to fill buffers. If you stall in any
part of the flowgraph, it might take longer until your blocks where you
want to measure latency are called by the scheduler.

> 3.Time stamp i have used is with two stamping before encoding and after
> decoding whether it will make sense ,what i understood is time delta if
> i am using it will be taking only the latest time key added.
The "Add System Time" block is intended to be used together with
https://github.com/gnuradio/gnuradio/blob/main/gr-pdu/include/gnuradio/pdu/time_delta.h
There's a nice explanation in the wiki:
https://wiki.gnuradio.org/index.php/Time_Delta

> 4.How can i use the control performance monitor for this FG.
> GNU Radio Companion 3.10.7.0
performance monitor is intended for things like load and buffer state.
Latency needs extra info (the discussed timestamps). Thus, performance
monitor won't report latency.

> I will upload a PDF of the flowgraph.

i have question about uhd:usrp sink block 's bandwidth

hello

i have a question about relation between sample rate of UHD USRP SINK block and CPU

 

i am currently implement MIMO OFDM Radar system at gnuradio(ubuntu) and USRP X310 and UBX160 daughter board with 10gbit ethernet with connected by sfp cable as i read at ettus official manual it can handle 160Mhz Bandwith and usrp's bw is related with sample rate as this equation bw=0.8 x (samplerate) 

when i using 100Mhz sample rate for single input single output radar system it works well

but when i using same sample rate at MIMO version of same radar then Gnuradio stops with error code LLLLLLLLLLLLLLLLLLLLLLLL  

as i under stand this error code means L: Tx: "Late data (arrived after indicated time)". Rx (RFNoC only?): "Late command (stream command arrived after indicated time)

then i changed sample rate by 50Mhz then MIMO system works well 

so i asked about this to NI(ettus)

as i know my USRP x310 and ubx160 daughter board can handle 160Mhz but why it stops?

they answered that i could be your desktops performance can't handle that sample rate

then i checked my computer's cpu usage when using 100Mhz 

it really using every resource of my cpu

so i can figure it out that for more sample rate high spec CPU is needed

but i can't find which spec(clock rate, number of core, threads....) is important for more 100Mhz sample rate and what's the minimum CPU spec for running my system using 100Mhz samplerate

so....if anyone knows about this... 

I understand everyone must be busy, but I would greatly appreciate it if you could spare a little time to help. 

and Thanks for read this long text...

Round trip time calculation - simulation

Hi Johannes,

Thanks in advance for your valuable inputs!

I appreciate your help so much.

1.I want to measure the time taken by 1 sample from the random source to the decoder unit-endpoint.

2.Need more clarifications in throttle usage in terms of latency.

3.Time stamp i have used is with two stamping before encoding and after decoding whether it will make sense ,what i understood is time delta if i am using it will be taking only the latest time key added.

4.How can i use the control performance monitor for this FG.

GNU Radio Companion 3.10.7.0

I will upload a PDF of the flowgraph.

Re: RuntimeError: invalid msg port in connect() or disconnect()

Hi Theo,

I assume this setup is part of a very old experiment that you want to
reboot. However, something must have changed since it's broken at the
moment.

It is very difficult to spot the issue without any context but just a
traceback.

The message itself tells you that you try to connect a message port
that's not an actual message port.

GRC generates a Python file for your flowgraph. In your case you also
have a hier block that receives a second Python file. The error happens
in there:
File "/home/theow/.grc_gnuradio/RX_SC_PHY.py", line 91, in __init__
self.msg_connect((self, 'time_per_angle_message'),
(self.theomodule_set_array_and_tt_RX_0, 'time_per_angle_message'))

This hier block is potentially called "RX_SC_PHY". You might want to
check what happened there.

Cheers
Johannes

On 29.08.23 15:28, theowire@web.de wrote:
> Hey everybody,
> I am currently facing the following error:
> Could not find port: time_per_angle_message in:
> system
> Traceback (most recent call last):
>   File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line
> 561, in <module>
>     main()
>   File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line
> 549, in main
>     tb = top_block_cls()
>   File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line
> 398, in __init__
>     usrp_tx_address="addr=192.168.10.4",
>   File "/home/theow/.grc_gnuradio/phy_transceiver.py", line 90, in __init__
>     threshold=detector_threshold,
>   File "/home/theow/.grc_gnuradio/RX_SC_PHY.py", line 91, in __init__
>     self.msg_connect((self, 'time_per_angle_message'),
> (self.theomodule_set_array_and_tt_RX_0, 'time_per_angle_message'))
>   File
> "/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 59, in wrapped
>     func(self, src.to_basic_block(), srcport, dst.to_basic_block(),
> dstport)
>   File
> "/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 131, in msg_connect
>     self.primitive_msg_connect(*args)
>   File
> "/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 3586, in primitive_msg_connect
>     return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self,
> *args)
> RuntimeError: invalid msg port in connect() or disconnect()
> I googled a lot, but I did not really find an answer to that problem...
> I am on an older setup with gnuradio 3.7 and ubuntu 16.04. I know for
> sure, that this setup was already working...so I am even more confused
> about that error.
> Would be very great if anyone had maybe a quick idea, how to solve this
> error. If you need any more information, I will gladly provide it.
> Thanks in advance,
> Theo

Re: Round trip time calculation - simulation

Hi Jiya,

It seems like you want to measure the DSP latency in a flowgraph without
hardware.

For better readability, I suggest to use a service that lets you upload
screenshots in higher resolution and you just share the link.

In said screenshot, I suggest to mark your start end endpoint for your
measurement. Thus, we all know exactly what you want to do.

The "Throttle" block will have an influence on your measurement even if
it is before your measurement starting point because it influences GR
scheduler behavior.

The timestamp and latency measurement approach seems sensible. I used
the same approach for such investigations.

How do you want to track the timing for 1 sample?
Especially FEC works on blocks. A lot of blocks do. Not just in GR but
just in principle.
I assume that you want to measure the time it takes for a frame of
specific size to be processed.

Since I don't know which GR version you use, you might want to double
check if all the rate changing blocks place the tags on the correct
sample in the output.

These are a few thoughts that came to mind when I looked at your flowgraph.

Cheers
Johannes

On 30.08.23 11:40, Jiya Johnson wrote:
>
> Hello, community. I have attempted to create a system that uses
> 1. A random source as input
> 2. A time stamper.These inputs are provided to the encoder, which
> performs the modulation and demodulation
> 3.I want to track back the timing for 1 sample (latency) after using the
> decoder; can somebody tell me whether my flowgraph is correct?
> Screenshot from 2023-08-26 11-24-39.png
>
>

Round trip time calculation - simulation

Hello, community. I have attempted to create a system that uses 

1. A random source as input

2. A time stamper.These inputs are provided to the encoder, which performs the modulation and demodulation

3.I want to track back the timing for 1 sample (latency) after using the decoder; can somebody tell me whether my flowgraph is correct?

Re: How send message with when message is less than sample rate?

Hi sp,

like many of your questions here and on usrp-users, this only makes sense once we ask for
context in a chain of emails.
I think we could do with slightly better rounded-off questions that give a reader that
doesn't know what you're doing insight without having to ask back.

Best,
Marcus

RuntimeError: invalid msg port in connect() or disconnect()

Hey everybody,

 

I am currently facing the following error:

 

Could not find port: time_per_angle_message in:
system

Traceback (most recent call last):
  File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line 561, in <module>
    main()
  File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line 549, in main
    tb = top_block_cls()
  File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line 398, in __init__
    usrp_tx_address="addr=192.168.10.4",
  File "/home/theow/.grc_gnuradio/phy_transceiver.py", line 90, in __init__
    threshold=detector_threshold,
  File "/home/theow/.grc_gnuradio/RX_SC_PHY.py", line 91, in __init__
    self.msg_connect((self, 'time_per_angle_message'), (self.theomodule_set_array_and_tt_RX_0, 'time_per_angle_message'))
  File "/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 59, in wrapped
    func(self, src.to_basic_block(), srcport, dst.to_basic_block(), dstport)
  File "/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 131, in msg_connect
    self.primitive_msg_connect(*args)
  File "/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 3586, in primitive_msg_connect
    return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

 

I googled a lot, but I did not really find an answer to that problem...

I am on an older setup with gnuradio 3.7 and ubuntu 16.04. I know for sure, that this setup was already working...so I am even more confused about that error.

 

Would be very great if anyone had maybe a quick idea, how to solve this error. If you need any more information, I will gladly provide it.

 

Thanks in advance,

Theo

How send message with when message is less than sample rate?

When every 3 seconds I call msqq->inserttail, messageTempI is only 64 bytes but the sample rate is 500khz...

I know that 64-byte string is more than 500khz samples....but usrp and uhd in gnuradio send it....!!!

my question is how message is sent to USRP and how does USRP send it? when samplerate is not completed?!!!

it waits to receive 500k samples or it sends it with fault...

Sending is correct? using message source in this structure true?

            message_source = gr::blocks::message_source::make(sizeof(gr_complex));

            this->tb->connect(message_source, 0, multiplyControl, 0);

            this->tb->connect(multiplyControl, 0, this->sinkUHD, 0);

            //every 3 second i call insert tail....

            message_source->msgq()->insert_tail(gr::message::make_from_string(messageTempI));
  

how can we implement a pool/worker structure in gnuradio?

In programming, I need to define a pooling layer that updates the last usrp samples

and other blocks use these pool samples and compute some operations, I emphasize that my means from pool,the pool is shared for all blocks(the blocks that use pool name as worker....)

Can anyone guide me? thanks in advance

more info: https://en.wikipedia.org/wiki/Thread_pool

Re: Error loading OOT

Hahh, yes, that did it! I don't know what went wrong the previous time. I removed the build directory and re-run the cmake with the env variables and now everything is in order. I have a full, absolute path with the correct CONDA_PREFIX in GR_PYTHON_PATH and the CMAME_BUILD_PREFIX is correct too.

I also stumbled upon what was wrong with the missing gr::block. To add insult to injury I'm also trying to use vs.code and I got a mixed release/debug build due to that. Sorting that out fixed it and my module runs fine now.

Ryan, thank you again!

Bagojfalvi Bagoj <bagojfalvibagoj@gmail.com> ezt írta (időpont: 2023. aug. 28., H, 14:55):

Hi Ryan, thank you very much for your response!

I think I traced it back to something fishy with the initial cmake step mentioned by you in the condainstall tutorial, setting the env variables. I'm not sure if I messed up or if it goes even further, but it seems like my %CONDA_PREFIX% variable wasn't set. E.g. my GR_PYTHON_DIR is just "\Lib\site-packages", thus it gets prefixed by CMAKE_BUILD_PREFIX (which I manually patched) and that's where the extra "\Library" comes from. I'll try a clean install and pay more attention when running that first cmake.

I wonder if that helps with the load issue too, missing a definition for gr::block.

Ryan Volz <ryan.volz@gmail.com> ezt írta (időpont: 2023. aug. 28., H, 10:00):

Hi,

On 8/27/23 10:46 PM, Bagojfalvi Bagoj wrote:
> Hi all,
>
> Apologies in advance as I have no idea what I'm doing on multiple levels.
> I'm trying to build my own OOT module. I managed to clear a number of
> issues already but I got stuck.
>
> I have a clean install of the latest released GNURadio following the
> CondaInstall tutorial on the website, including the steps needed for
> building OOT modules. I used gr_modtool as described in the C++ OOT
> tutorial to create the template for my module.
>
> Build works seemingly fine, but install places stuff in some crazy
> location in my Program Files(x86) folder. (obviously I'm on windows)
> E.g.: C:/Program Files (x86)/gr-ni_modinst_rf/bin/gnuradio-ni_modinst_rf.dll
> I changed the top level CMakeList.txt to set CMAKE_INSTALL_PREFIX to the
> CONDA_PREFIX env variable + /Library.
> This puts everything where it should be,
> E.g.:
> C:/Users/Admin/.conda/envs/gnuradio-env/Library/bin/gnuradio-ni_modinst_rf.dll
> except for the python output.
> The python output is installed to
> E.g.:
> C:/Users/Admin/.conda/envs/gnuradio-env/Library/Lib/site-packages/gnuradio/ni_modinst_rf/ni_modinst_rf_python.cp311-win_amd64.pyd
> but looking at where GR is expecting and where other stuff is it should
> be in
> C:/Users/Admin/.conda/envs/gnuradio-env/Lib/site-packages/gnuradio/ni_modinst_rf/ instead
> (note gnuradio-env/Lib vs gnuradio-env/Library/Lib )
> Any ideas...
> 1. why was I missing the correct cmake install location?
> 2. why the difference between the Library/Lib and /Lib locations
> 3. how to tell cmake properly where to install?

1. CMake guesses on where to put the Python files based on your prefix,
but it happens to guess wrong because of how the conda environment is
structured.

2. %CONDA_PREFIX%/Library/Lib is not anything that anybody uses, except
by mistake, whereas %CONDA_PREFIX%/Lib is where Anaconda decided to put
all the Python files when they released conda, and the ecosystem is
stuck with that split now.

3. The part you're (probably) missing is to add the cmake argument to
set GR_PYTHON_DIR to "%CONDA_PREFIX%\Lib\site-packages", i.e.

     cmake -DGR_PYTHON_DIR="%CONDA_PREFIX%\Lib\site-packages" (the rest)

By the way, this is documented on the CondaInstall wiki in the Building
OOT modules section:
https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio

>
> Anyway, my temporary fix was to simply copy over the python files where
> they should be and this way GR got one step closer to running my module.
> I can drop the block in GRC, however I can't get over the following
> error when running.
> from .ni_modinst_rf_python import *
> ImportError: generic_type: type "ni_rfsa_source" referenced unknown base
> type "gr::block"

This feels like an issue with using a different version of pybind or
compiler than what GNU Radio was built with. Maybe look into using the
`gnuradio-build-deps` metapackage to install the same versions of those
as were used to compile gnuradio?

>
> I found this thread here: gr 3.9 OOT execution error: unknown base type
> gr::block (gnu.org)
> <https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00023.html>
> It sounds like the same issue, but there is no resolution.
>
> Anybody can point me in the right direction please?
> I think I'm doing pretty good considering I didn't know what cmake was 2
> days ago, but I understand I'm lacking some basics. Please be gentle. :D
>
> Thank you!
>

Cheers,
Ryan

Re: Error loading OOT

Hi Ryan, thank you very much for your response!

I think I traced it back to something fishy with the initial cmake step mentioned by you in the condainstall tutorial, setting the env variables. I'm not sure if I messed up or if it goes even further, but it seems like my %CONDA_PREFIX% variable wasn't set. E.g. my GR_PYTHON_DIR is just "\Lib\site-packages", thus it gets prefixed by CMAKE_BUILD_PREFIX (which I manually patched) and that's where the extra "\Library" comes from. I'll try a clean install and pay more attention when running that first cmake.

I wonder if that helps with the load issue too, missing a definition for gr::block.

Ryan Volz <ryan.volz@gmail.com> ezt írta (időpont: 2023. aug. 28., H, 10:00):

Hi,

On 8/27/23 10:46 PM, Bagojfalvi Bagoj wrote:
> Hi all,
>
> Apologies in advance as I have no idea what I'm doing on multiple levels.
> I'm trying to build my own OOT module. I managed to clear a number of
> issues already but I got stuck.
>
> I have a clean install of the latest released GNURadio following the
> CondaInstall tutorial on the website, including the steps needed for
> building OOT modules. I used gr_modtool as described in the C++ OOT
> tutorial to create the template for my module.
>
> Build works seemingly fine, but install places stuff in some crazy
> location in my Program Files(x86) folder. (obviously I'm on windows)
> E.g.: C:/Program Files (x86)/gr-ni_modinst_rf/bin/gnuradio-ni_modinst_rf.dll
> I changed the top level CMakeList.txt to set CMAKE_INSTALL_PREFIX to the
> CONDA_PREFIX env variable + /Library.
> This puts everything where it should be,
> E.g.:
> C:/Users/Admin/.conda/envs/gnuradio-env/Library/bin/gnuradio-ni_modinst_rf.dll
> except for the python output.
> The python output is installed to
> E.g.:
> C:/Users/Admin/.conda/envs/gnuradio-env/Library/Lib/site-packages/gnuradio/ni_modinst_rf/ni_modinst_rf_python.cp311-win_amd64.pyd
> but looking at where GR is expecting and where other stuff is it should
> be in
> C:/Users/Admin/.conda/envs/gnuradio-env/Lib/site-packages/gnuradio/ni_modinst_rf/ instead
> (note gnuradio-env/Lib vs gnuradio-env/Library/Lib )
> Any ideas...
> 1. why was I missing the correct cmake install location?
> 2. why the difference between the Library/Lib and /Lib locations
> 3. how to tell cmake properly where to install?

1. CMake guesses on where to put the Python files based on your prefix,
but it happens to guess wrong because of how the conda environment is
structured.

2. %CONDA_PREFIX%/Library/Lib is not anything that anybody uses, except
by mistake, whereas %CONDA_PREFIX%/Lib is where Anaconda decided to put
all the Python files when they released conda, and the ecosystem is
stuck with that split now.

3. The part you're (probably) missing is to add the cmake argument to
set GR_PYTHON_DIR to "%CONDA_PREFIX%\Lib\site-packages", i.e.

     cmake -DGR_PYTHON_DIR="%CONDA_PREFIX%\Lib\site-packages" (the rest)

By the way, this is documented on the CondaInstall wiki in the Building
OOT modules section:
https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio

>
> Anyway, my temporary fix was to simply copy over the python files where
> they should be and this way GR got one step closer to running my module.
> I can drop the block in GRC, however I can't get over the following
> error when running.
> from .ni_modinst_rf_python import *
> ImportError: generic_type: type "ni_rfsa_source" referenced unknown base
> type "gr::block"

This feels like an issue with using a different version of pybind or
compiler than what GNU Radio was built with. Maybe look into using the
`gnuradio-build-deps` metapackage to install the same versions of those
as were used to compile gnuradio?

>
> I found this thread here: gr 3.9 OOT execution error: unknown base type
> gr::block (gnu.org)
> <https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00023.html>
> It sounds like the same issue, but there is no resolution.
>
> Anybody can point me in the right direction please?
> I think I'm doing pretty good considering I didn't know what cmake was 2
> days ago, but I understand I'm lacking some basics. Please be gentle. :D
>
> Thank you!
>

Cheers,
Ryan

Re: Error loading OOT

Hi,

On 8/27/23 10:46 PM, Bagojfalvi Bagoj wrote:
> Hi all,
>
> Apologies in advance as I have no idea what I'm doing on multiple levels.
> I'm trying to build my own OOT module. I managed to clear a number of
> issues already but I got stuck.
>
> I have a clean install of the latest released GNURadio following the
> CondaInstall tutorial on the website, including the steps needed for
> building OOT modules. I used gr_modtool as described in the C++ OOT
> tutorial to create the template for my module.
>
> Build works seemingly fine, but install places stuff in some crazy
> location in my Program Files(x86) folder. (obviously I'm on windows)
> E.g.: C:/Program Files (x86)/gr-ni_modinst_rf/bin/gnuradio-ni_modinst_rf.dll
> I changed the top level CMakeList.txt to set CMAKE_INSTALL_PREFIX to the
> CONDA_PREFIX env variable + /Library.
> This puts everything where it should be,
> E.g.:
> C:/Users/Admin/.conda/envs/gnuradio-env/Library/bin/gnuradio-ni_modinst_rf.dll
> except for the python output.
> The python output is installed to
> E.g.:
> C:/Users/Admin/.conda/envs/gnuradio-env/Library/Lib/site-packages/gnuradio/ni_modinst_rf/ni_modinst_rf_python.cp311-win_amd64.pyd
> but looking at where GR is expecting and where other stuff is it should
> be in
> C:/Users/Admin/.conda/envs/gnuradio-env/Lib/site-packages/gnuradio/ni_modinst_rf/ instead
> (note gnuradio-env/Lib vs gnuradio-env/Library/Lib )
> Any ideas...
> 1. why was I missing the correct cmake install location?
> 2. why the difference between the Library/Lib and /Lib locations
> 3. how to tell cmake properly where to install?

1. CMake guesses on where to put the Python files based on your prefix,
but it happens to guess wrong because of how the conda environment is
structured.

2. %CONDA_PREFIX%/Library/Lib is not anything that anybody uses, except
by mistake, whereas %CONDA_PREFIX%/Lib is where Anaconda decided to put
all the Python files when they released conda, and the ecosystem is
stuck with that split now.

3. The part you're (probably) missing is to add the cmake argument to
set GR_PYTHON_DIR to "%CONDA_PREFIX%\Lib\site-packages", i.e.

cmake -DGR_PYTHON_DIR="%CONDA_PREFIX%\Lib\site-packages" (the rest)

By the way, this is documented on the CondaInstall wiki in the Building
OOT modules section:
https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio

>
> Anyway, my temporary fix was to simply copy over the python files where
> they should be and this way GR got one step closer to running my module.
> I can drop the block in GRC, however I can't get over the following
> error when running.
> from .ni_modinst_rf_python import *
> ImportError: generic_type: type "ni_rfsa_source" referenced unknown base
> type "gr::block"

This feels like an issue with using a different version of pybind or
compiler than what GNU Radio was built with. Maybe look into using the
`gnuradio-build-deps` metapackage to install the same versions of those
as were used to compile gnuradio?

>
> I found this thread here: gr 3.9 OOT execution error: unknown base type
> gr::block (gnu.org)
> <https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00023.html>
> It sounds like the same issue, but there is no resolution.
>
> Anybody can point me in the right direction please?
> I think I'm doing pretty good considering I didn't know what cmake was 2
> days ago, but I understand I'm lacking some basics. Please be gentle. :D
>
> Thank you!
>

Cheers,
Ryan

RE: Selector error - "IndexError: output_index must be < noutputs"

Don’t you need to instantiate “Receive”?

 

---

Jim Melton

Non-Sensitive

 

From: discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org <discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org> On Behalf Of Elmore's
Sent: Monday, August 28, 2023 09:15
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Selector error - "IndexError: output_index must be < noutputs"

 

I am attempting to use a Selector block with 2 outputs. I want to select the output programmatically. When I run the flowgraph, I get the subject error.

 

The following is my abbreviated code which is pertinent to the question interspersed with explanatory comments:

 

import Receive Receive is a Hier Block which I import in to my Python file

blocks_selector_0 = Receive.blocks.selector(gr.sizeof_float*1,0,0) Instantiation of blocks_selector_0. The Selector block is in the Receive Hier Block.

 

blocks_selector_0.set_output_index(0) I am trying to select the 0 output. This is where the error occurs.

 

0 is certainly less than 2 so what is happening?

 

Jim

 

 

Virus-free.www.avg.com

 

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.

Selector error - "IndexError: output_index must be < noutputs"

I am attempting to use a Selector block with 2 outputs. I want to select the output programmatically. When I run the flowgraph, I get the subject error.

 

The following is my abbreviated code which is pertinent to the question interspersed with explanatory comments:

 

import Receive Receive is a Hier Block which I import in to my Python file

blocks_selector_0 = Receive.blocks.selector(gr.sizeof_float*1,0,0) Instantiation of blocks_selector_0. The Selector block is in the Receive Hier Block.

 

blocks_selector_0.set_output_index(0) I am trying to select the 0 output. This is where the error occurs.

 

0 is certainly less than 2 so what is happening?

 

Jim

Virus-free.www.avg.com

Re: History and forecast

You are correct! The code I was looking at takes advantage of the math done in a lower layer (the sync/interp/decim implementation).

Separately, having the (-1) exposed to the user is confusing. We really shouldn't bother the user with that. It may be left over from some assumption about how FIR filters work, or may just be "the way it's done".

On Mon, Aug 28, 2023 at 8:52 AM Marco Menchise <marco.menchise@gmail.com> wrote:

On Mon, Aug 28, 2023 at 1:08 PM Jeff Long <willcode4@gmail.com> wrote:

See fir_filter_blok.impl.cc for an example ...

forecast() does not include history. For a sync, interp or decim block, forecast is not required at all.

 

Sorry I can't find the code you pointed out. 

I saw this:

https://github.com/n-west/gnuradio-volk/blob/master/gnuradio-runtime/python/gnuradio/gr/gateway.py

I don't know what block is but it seems that default forecast implementation does include history. 

history() should be the number of previous items required, without the (-1).

If history=1 (default) there are no items prepended. So the number of prepended items should be history-1

This post 

https://lists.gnu.org/archive/html/discuss-gnuradio/2011-02/msg00480.html

seems to state the same thing: 

"If you set the history to 'N', this means you always have the last (N-1) input values kept in your buffer."

Am I wrong?

Thanks,

Marco

 

On Mon, Aug 28, 2023 at 5:08 AM Marco Menchise <marco.menchise@gmail.com> wrote:

Hi, I'm a gnuradio newbie. 

I'm trying to write a block that calculates output at time k based on three input samples: one at time k-N-1 (in the past), one at time k (the current sample) and one at k+M (in the future).

I spent some hours struggling against "history" and forecast function.

Here:  https://lists.gnu.org/archive/html/discuss-gnuradio/2016-04/msg00520.html

I found a good visualization of  the history concept. As I said, I also need to process "future" samples so I also investigated the "forecast" function.

Here is what I understood:

1) history=N tells the scheduler to prepend N-1 "old" samples to the input_items buffer. The oldest prepended sample has relative index = 0, so the "current" buffer starts at index N-1. 

2) The forecast function must return N-1 + noutput_items+ M, where M is the number of samples required in the future. Forecast *must* take into account history. Each general_work call is guaranteed to have *at least* N-1 + noutput_items+ M samples in input_items buffer.

3) I did some tests and noticed that the scheduler may pass to general_work *more* than N-1+noutput_items+M samples. Extra samples should be ignored by general_work. They will be passed again in the next call.

4) general_work must "consume" just noutput_items samples

I tried to collect all those concepts in the attached figure where I used both absolute and relative indexes to mark samples. I assumed history=4 and M=2. The input_items in the first general_work call has at least 9 samples. I must process input samples from 103 to 106 (included) using samples from 100 to 108 (included) and I must generate 4 output_samples. In the next call I must process samples from 107 to 110 (included) and, again, I must generate 4 output samples. I must ignore "extra" samples in both cases.

Is that correct? I'm I missing something?

Thanks,

Marco

 

Re: History and forecast

On Mon, Aug 28, 2023 at 1:08 PM Jeff Long <willcode4@gmail.com> wrote:

See fir_filter_blok.impl.cc for an example ...

forecast() does not include history. For a sync, interp or decim block, forecast is not required at all.

 

Sorry I can't find the code you pointed out. 

I saw this:

https://github.com/n-west/gnuradio-volk/blob/master/gnuradio-runtime/python/gnuradio/gr/gateway.py

I don't know what block is but it seems that default forecast implementation does include history. 

history() should be the number of previous items required, without the (-1).

If history=1 (default) there are no items prepended. So the number of prepended items should be history-1

This post 

https://lists.gnu.org/archive/html/discuss-gnuradio/2011-02/msg00480.html

seems to state the same thing: 

"If you set the history to 'N', this means you always have the last (N-1) input values kept in your buffer."

Am I wrong?

Thanks,

Marco

 

On Mon, Aug 28, 2023 at 5:08 AM Marco Menchise <marco.menchise@gmail.com> wrote:

Hi, I'm a gnuradio newbie. 

I'm trying to write a block that calculates output at time k based on three input samples: one at time k-N-1 (in the past), one at time k (the current sample) and one at k+M (in the future).

I spent some hours struggling against "history" and forecast function.

Here:  https://lists.gnu.org/archive/html/discuss-gnuradio/2016-04/msg00520.html

I found a good visualization of  the history concept. As I said, I also need to process "future" samples so I also investigated the "forecast" function.

Here is what I understood:

1) history=N tells the scheduler to prepend N-1 "old" samples to the input_items buffer. The oldest prepended sample has relative index = 0, so the "current" buffer starts at index N-1. 

2) The forecast function must return N-1 + noutput_items+ M, where M is the number of samples required in the future. Forecast *must* take into account history. Each general_work call is guaranteed to have *at least* N-1 + noutput_items+ M samples in input_items buffer.

3) I did some tests and noticed that the scheduler may pass to general_work *more* than N-1+noutput_items+M samples. Extra samples should be ignored by general_work. They will be passed again in the next call.

4) general_work must "consume" just noutput_items samples

I tried to collect all those concepts in the attached figure where I used both absolute and relative indexes to mark samples. I assumed history=4 and M=2. The input_items in the first general_work call has at least 9 samples. I must process input samples from 103 to 106 (included) using samples from 100 to 108 (included) and I must generate 4 output_samples. In the next call I must process samples from 107 to 110 (included) and, again, I must generate 4 output samples. I must ignore "extra" samples in both cases.

Is that correct? I'm I missing something?

Thanks,

Marco

 

GSoC 2023 Qt Widgets Improvement Journey- Blog Post

Dear GNU Radio Community,

I hope this email finds you well. I am excited to announce that my blog post, "GSoC 2023 Qt Widgets Improvement Recap [Complete Journey]," is now live! It has been an incredible experience working on this project, and I am thrilled to share the progress and achievements made over the summer.

In this blog post, I provide a comprehensive overview of the project, including the goals, new GUI sinks developed, refactoring of existing Qt GUI sinks, and the integration of Qt Designer with GNU Radio. I also discuss the lessons learned and the impact these improvements will have on the GNU Radio community.

I invite you all to check out the blog post at the following link: https://www.gnuradio.org/blog/2023-08-28-GSoC-2023-Complete-Journey/

Throughout this journey, I have gained valuable technical skills, collaborated with the GNU Radio community, and learned the art of open-source development. I am immensely grateful for the support, guidance, and encouragement I have received from the GNU Radio community, my mentors, and the GSoC program.

Thank you once again for being a part of this incredible journey. Your encouragement and the vibrant GNU Radio community have made this experience truly exceptional. I look forward to hearing your thoughts and feedback on the blog post.

Best regards,
Rohit Bisht

GSoC 2023 Participant
GNU Radio
Email: rbtunes02@gmail.com

GitHub: https://github.com/R-ohit-B-isht
LinkedIn: https://www.linkedin.com/in/rohit-bisht-a96b581bb/

Re: How can i designed a FSM and conditional logic control in gnuradio?

Google turns up some previous work using GNU Radio for RFID. Older software (e.g., https://github.com/nkargas/Gen2-UHF-RFID-Reader) may need porting to a newer version of GNU Radio.

On Mon, Aug 28, 2023 at 6:57 AM sp <stackprogramer@gmail.com> wrote:

Hi, Today I worked on RFID articles, and I had some questions. It is possible to design an RFID reader for frequency 13.56 or 125khz with gnuradio?

I read the RFID standards According to RFID flowchart I need to design an FSM (Finite State Machine) for RFID Reader.

can anyone guide me? how can write and design a real-time RFID in gnuradio?

thanks in advance

Re: History and forecast

See fir_filter_blok.impl.cc for an example ...

forecast() does not include history. For a sync, interp or decim block, forecast is not required at all.

history() should be the number of previous items required, without the (-1).

On Mon, Aug 28, 2023 at 5:08 AM Marco Menchise <marco.menchise@gmail.com> wrote:

Hi, I'm a gnuradio newbie. 

I'm trying to write a block that calculates output at time k based on three input samples: one at time k-N-1 (in the past), one at time k (the current sample) and one at k+M (in the future).

I spent some hours struggling against "history" and forecast function.

Here:  https://lists.gnu.org/archive/html/discuss-gnuradio/2016-04/msg00520.html

I found a good visualization of  the history concept. As I said, I also need to process "future" samples so I also investigated the "forecast" function.

Here is what I understood:

1) history=N tells the scheduler to prepend N-1 "old" samples to the input_items buffer. The oldest prepended sample has relative index = 0, so the "current" buffer starts at index N-1. 

2) The forecast function must return N-1 + noutput_items+ M, where M is the number of samples required in the future. Forecast *must* take into account history. Each general_work call is guaranteed to have *at least* N-1 + noutput_items+ M samples in input_items buffer.

3) I did some tests and noticed that the scheduler may pass to general_work *more* than N-1+noutput_items+M samples. Extra samples should be ignored by general_work. They will be passed again in the next call.

4) general_work must "consume" just noutput_items samples

I tried to collect all those concepts in the attached figure where I used both absolute and relative indexes to mark samples. I assumed history=4 and M=2. The input_items in the first general_work call has at least 9 samples. I must process input samples from 103 to 106 (included) using samples from 100 to 108 (included) and I must generate 4 output_samples. In the next call I must process samples from 107 to 110 (included) and, again, I must generate 4 output samples. I must ignore "extra" samples in both cases.

Is that correct? I'm I missing something?

Thanks,

Marco

 

How can i designed a FSM and conditional logic control in gnuradio?

Hi, Today I worked on RFID articles, and I had some questions. It is possible to design an RFID reader for frequency 13.56 or 125khz with gnuradio?

I read the RFID standards According to RFID flowchart I need to design an FSM (Finite State Machine) for RFID Reader.

can anyone guide me? how can write and design a real-time RFID in gnuradio?

thanks in advance

Re: when in gnuradio top block is started can we change connect blocks?

Call tb.lock() before making changes, then call tb.unlock() to resume. There are some cases where this does not work correctly and the entire flowgraph needs to be stopped.

On Mon, Aug 28, 2023 at 6:30 AM sp <stackprogramer@gmail.com> wrote:

I have a question about gnuradio blocks when I define gnuradio blocks on a top block and start top block can we changed connection between blocks when tp is running with out stoping it.....

for  example i connect uhd to a null block, after some time i changed uhd to another block?????

can any one guide me?

thanks in advance

when in gnuradio top block is started can we change connect blocks?

I have a question about gnuradio blocks when I define gnuradio blocks on a top block and start top block can we changed connection between blocks when tp is running with out stoping it.....

for  example i connect uhd to a null block, after some time i changed uhd to another block?????

can any one guide me?

thanks in advance

History and forecast

Hi, I'm a gnuradio newbie. 

I'm trying to write a block that calculates output at time k based on three input samples: one at time k-N-1 (in the past), one at time k (the current sample) and one at k+M (in the future).

I spent some hours struggling against "history" and forecast function.

Here:  https://lists.gnu.org/archive/html/discuss-gnuradio/2016-04/msg00520.html

I found a good visualization of  the history concept. As I said, I also need to process "future" samples so I also investigated the "forecast" function.

Here is what I understood:

1) history=N tells the scheduler to prepend N-1 "old" samples to the input_items buffer. The oldest prepended sample has relative index = 0, so the "current" buffer starts at index N-1. 

2) The forecast function must return N-1 + noutput_items+ M, where M is the number of samples required in the future. Forecast *must* take into account history. Each general_work call is guaranteed to have *at least* N-1 + noutput_items+ M samples in input_items buffer.

3) I did some tests and noticed that the scheduler may pass to general_work *more* than N-1+noutput_items+M samples. Extra samples should be ignored by general_work. They will be passed again in the next call.

4) general_work must "consume" just noutput_items samples

I tried to collect all those concepts in the attached figure where I used both absolute and relative indexes to mark samples. I assumed history=4 and M=2. The input_items in the first general_work call has at least 9 samples. I must process input samples from 103 to 106 (included) using samples from 100 to 108 (included) and I must generate 4 output_samples. In the next call I must process samples from 107 to 110 (included) and, again, I must generate 4 output samples. I must ignore "extra" samples in both cases.

Is that correct? I'm I missing something?

Thanks,

Marco

 

Error loading OOT

Hi all,

Apologies in advance as I have no idea what I'm doing on multiple levels.

I'm trying to build my own OOT module. I managed to clear a number of issues already but I got stuck.

I have a clean install of the latest released GNURadio following the CondaInstall tutorial on the website, including the steps needed for building OOT modules. I used gr_modtool as described in the C++ OOT tutorial to create the template for my module.

Build works seemingly fine, but install places stuff in some crazy location in my Program Files(x86) folder. (obviously I'm on windows)

E.g.: C:/Program Files (x86)/gr-ni_modinst_rf/bin/gnuradio-ni_modinst_rf.dll

I changed the top level CMakeList.txt to set CMAKE_INSTALL_PREFIX to the CONDA_PREFIX env variable + /Library.
This puts everything where it should be,

E.g.: C:/Users/Admin/.conda/envs/gnuradio-env/Library/bin/gnuradio-ni_modinst_rf.dll

except for the python output.

The python output is installed to 

E.g.: C:/Users/Admin/.conda/envs/gnuradio-env/Library/Lib/site-packages/gnuradio/ni_modinst_rf/ni_modinst_rf_python.cp311-win_amd64.pyd

but looking at where GR is expecting and where other stuff is it should be in

C:/Users/Admin/.conda/envs/gnuradio-env/Lib/site-packages/gnuradio/ni_modinst_rf/ instead

(note gnuradio-env/Lib vs gnuradio-env/Library/Lib )

Any ideas...

1. why was I missing the correct cmake install location?

2. why the difference between the Library/Lib and /Lib locations

3. how to tell cmake properly where to install?

Anyway, my temporary fix was to simply copy over the python files where they should be and this way GR got one step closer to running my module. I can drop the block in GRC, however I can't get over the following error when running.

from .ni_modinst_rf_python import *

ImportError: generic_type: type "ni_rfsa_source" referenced unknown base type "gr::block"

I found this thread here: gr 3.9 OOT execution error: unknown base type gr::block (gnu.org)

It sounds like the same issue, but there is no resolution.

Anybody can point me in the right direction please?
I think I'm doing pretty good considering I didn't know what cmake was 2 days ago, but I understand I'm lacking some basics. Please be gentle. :D

Thank you!

GSoC: standalone GRC weekly blog update

Hello everyone,

This is my final update on the blog posts for the progress report of this project for the term of GSoC 23. I am truly grateful for the opportunity to contribute to the community under the constant guidance of my mentors and everyone else. I will continue to work and contribute to GNU Radio beyond this term, and I am genuinely thankful to everyone for joining me on this coding journey.

Week-9 and week-10 of my blog report note the focus of code changes for the week, while Week-11 gives a recap of the entire project. With the end of GSoC 23, I am confident to state that the project to make GRC a standalone project has made significant progress and is only a matter of a few steps before it can be used by the public. It would be my pleasure to hear your thoughts and suggestions on the future of this project.

Regards,

Rahul Balaji.

simulation

Hello, community. I have attempted to create a system that uses 

1. A random source as input

2. A time stamper.These inputs are provided to the encoder, which performs the modulation and demodulation

3.I want to track back the timing for 1 sample (latency) after using the decoder; can somebody tell me whether my flowgraph is correct?

Re: Transmit / Receive Text On VHF/UHF Frequency w/ HackRF One

Hi Adam,

The magic of GNU Radio is that wherever you put something like "Network sink/source + channel model", you could also put a hardware interface block.

So, the "Packet Communications" Tutorial from https://tutorials.gnuradio.org does apply :)

I'd recommend doing that tutorial; soon as it works through ZMQ network sockets, you can read the "Using GNU Radio with SDRs" tutorial (It's by far not as long!).

So here comes the part where I have a strong recommendations:

You want to use GNU Radio 3.8, but that's really in maintenance mode, and for people who want to interface HackRFs, is a pretty bad choice. If you get GNU Radio 3.10, you're automatically getting the gr-soapysdr interface, which means that, as soon as you install soapy-hackrf, you can talk to your hackrf – no external GNU Radio blocks needed. Also, you'll find that in the parts of the "Packet Communications" tutorial that differ between GNU Radio 3.8 and 3.9+, the 3.9+ parts are a bit shorter and "less confusing"; that is result of the GNU Radio developers trying to make packet communications less of a hassle. You really don't want to do this on 3.8.

It's not hard to install a newer version of GNU Radio; typically, all you need to do is either use a somewhat modern version of your Linux distro, or use the Radioconda installer (does also exist for Linux, not only Windows and MacOS).

Best,
Marcus

On 25.08.23 00:59, Arndt, Adam (LCDR) wrote:

Good Afternoon,

 

I am conducting research with the Naval Postgraduate School and we're experimenting with sending data from text files over VHF/UHF frequencies using GNU Radio with a HackRF One attached.  I have been searching through the internet and see many of the ways it used to be done have since been deprecated.  Furthermore, many of the example files provided within GNU use TCP streams or are self contained examples using artificial sources.

 

Is there anyone that can help walk through how to accomplish this using GNU Radio 3.8?

 

Thanks in advance.

 

V/r,

LCDR Adam Arndt

 

Sent from Mail for Windows

 

Transmit / Receive Text On VHF/UHF Frequency w/ HackRF One

Good Afternoon,

 

I am conducting research with the Naval Postgraduate School and we're experimenting with sending data from text files over VHF/UHF frequencies using GNU Radio with a HackRF One attached.  I have been searching through the internet and see many of the ways it used to be done have since been deprecated.  Furthermore, many of the example files provided within GNU use TCP streams or are self contained examples using artificial sources.

 

Is there anyone that can help walk through how to accomplish this using GNU Radio 3.8?

 

Thanks in advance.

 

V/r,

LCDR Adam Arndt

 

Sent from Mail for Windows

 

Re: puncturing pattern used

The delay before the decoder might be throwing off the alignment at the output. Might consider setting to 0 or removing.

Generally If you use a test input vector like the block of 0xff and 0x00 I mentioned before, you should be able to look at the relative delay between input and output by putting the source output and decoder output into a time sink and measuring the delay between the source signal being non 0 and the decoder output being non 0.

Jared.

On Wed, Aug 23, 2023, 4:58 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

I am getting constant BER through our the SNR ranges

On Tue, Aug 22, 2023, 7:15 PM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Ok, I will check. 

I was confused with this stack input (https://stackoverflow.com/questions/54946638/punctured-convolutional-codes-in-gnu-radio)

I will try with 1011 and delay blocks and will update you.

On Tue, Aug 22, 2023, 7:12 PM U L <jareddpub@gmail.com> wrote:

The extended en/decoder does puncturing and zero stuffing internally so you don't need an extra puncturing block. Like I mentioned, the puncturing string can only have 0s and 1s so 13 is invalid. I'd try '1011' instead. 

Finally I think you still need some delay between your source and the ber block to align your input bytes with those from your output. The output does not start with the first decoded bit, but some number of 0s. In one of your prior flowgraphs you did have a delay. What happened to it?

Jared.

On Tue, Aug 22, 2023, 4:13 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Hi Jared,

     Completed the flowgraph based on the inputs from you like i have taken code rate :2/3 and pattern 1101(0xD)-puncture size-4 as reference from (https://stackoverflow.com/questions/54946638/punctured-convolutional-codes-in-gnu-radio) bt still i am facing the issue.Always i am getting 10^-0.3 BER FROM 0 to 15 dB.

Python Block Callback Usage

In an attempt to understand the mechanism of resetting a Head block I developed the attached flowgraph as a test. I want to be able to reset the Head block using the Check Box.

 

The comments in the Python Block state:

# if an attribute with the same name as a parameter is found,          # a callback is registered

I don't understand what the callback method is called. I have tried using Reset and _Reset_callback but the callback is never called.

Also, you might comment on my attempt to call reset() in the Head block – is this correct? 

Jim

Virus-free.www.avg.com

Re: cmd time errors occurred - solution in gnuradio?

Hi Theo,

yep, that's a problem within the scope of UHD – GNU Radio doesn't see any of the low-level communications, and these are the only thing that has changed. (if you haven't, say high on the usrp-users mailing list[1], we usually don't bite.)

So, unless you're really setting time stamps in your own application too closely to the USRP's notion of "now", there's nothing GNU Radio can do about this.

Best,
Marcus

[1] Simply send a message from your email address to usrp-users-join@lists.ettus.com to join the mailing list; click on the confirmation link, and then you can write to usrp-users@lists.ettus.com

On 22.08.23 15:38, theowire@web.de wrote:

Dear all,

 

I am afraid my issue is actually a UHD issue, but I think it must be solved in gnuradio, and therefore I might also ask gnuradios great community.

 

I am working on a measurement setup with the USRP X410. Since we wanted a higher sampling rate, we sitched from ethernet to 10gbit/s thunderbold. 

With ethernet and a sampling rate of 2MHz, the flowgraph worked perfectly fine. Now, with 10gibt/s, also with 2MHz sampling rate (for the beginning), the setup does not work well anymore.

GNUradio prints now

"LLLLLLLLLLL" and

"usrp_sink :error: In the last 802 ms, 181 cmd time errors occurred."

I did all what the suggestions I found here: https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks

E.g., MTU rates in the network configuration to 9000 etc.

 

Because I did more or less all, that is possible in the PC configurations, I wonder if there is something I can do in gnuradio to fix this...

 

Thank you very much for every little help.

 

Best,

Theo

cmd time errors occurred - solution in gnuradio?

Dear all,

 

I am afraid my issue is actually a UHD issue, but I think it must be solved in gnuradio, and therefore I might also ask gnuradios great community.

 

I am working on a measurement setup with the USRP X410. Since we wanted a higher sampling rate, we sitched from ethernet to 10gbit/s thunderbold. 

With ethernet and a sampling rate of 2MHz, the flowgraph worked perfectly fine. Now, with 10gibt/s, also with 2MHz sampling rate (for the beginning), the setup does not work well anymore.

GNUradio prints now

"LLLLLLLLLLL" and

"usrp_sink :error: In the last 802 ms, 181 cmd time errors occurred."

I did all what the suggestions I found here: https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks

E.g., MTU rates in the network configuration to 9000 etc.

 

Because I did more or less all, that is possible in the PC configurations, I wonder if there is something I can do in gnuradio to fix this...

 

Thank you very much for every little help.

 

Best,

Theo

qt_gui_bercurvesink-inputs

Hi Community,

BER CURVE GEN

this block calculates the BER itself internally by comparing the original data (pre-distortion) from input i with the post-distortion and post-decoding data on input i+1. So input_items[i] ^ input_items[i+1] is the BER to plot for that particular Es/N0 point.

I Saw this explanation(https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00490.html) but I am not clear about the source section and the noise section. By default it will handle how we can trace those things to get the number samples it will be analysing.

Re: CCSDS BER PLOT

The puncture pattern looks like it's read using read_bitlist https://github.com/gnuradio/gnuradio/blob/main/gr-fec/python/fec/bitflip.py#L35C17-L35C17. I think the affect you want would be using puncture pattern 0111.

Jared.

On Sun, Aug 20, 2023, 10:43 PM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

I was trying to do the BER curve sink block in GNU radio but always by default BPSK-AWGN is coming in. how can we track the details of the same since we are not giving any input source (noise-gaussian channel).

for punctured ones I have given pattern '13' but it is always constant.

On Mon, Aug 21, 2023 at 10:04 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

On Sat, Aug 19, 2023 at 10:24 PM U L <jareddpub@gmail.com> wrote:

Import block: https://wiki.gnuradio.org/index.php?title=Import

On Sat, Aug 19, 2023 at 10:43 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Thanks for the advice!

Try to do but continuously it is showing error Param - Value(value):
Value "numpy.sqrt((10.0**(-esno/10.0))/2.0)" cannot be evaluated:
name 'numpy' is not defined

how can i rectify this?

is there any already done grc files for evaluating ccsds

On Sat, Aug 19, 2023 at 9:55 PM U L <jareddpub@gmail.com> wrote:

I'd try this:

1. Change the random source to a vector source with vector [ 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ] (that's 4 x 0xFF, 8 x 0x00)

2. Encoder output can go to the map input, then map to a charToFloat. CharToFloat to decoder.

3. Remove the entire noise branch. It doesn't make sense to add noise before the map anyways. Noise would normally be added as a float after charToFloat.

4. Vector source to a delay block, delay to one input of BER block. Decoder output to pack8 to BER block.

5. You'll have to experiment with the delay value. It's probably between 2 and 8 bytes.

6. If you want to try to observe the delay between the source and the decoder, make a 2 input time sink and connect the unpack8 output after the vector source to one time sink input, and the decoder output to the other sink input. You should be able to see the sample delay between each block of inputs and compute the right delay from the difference.

Good luck,

Jared.

On Sat, Aug 19, 2023 at 5:13 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Any suggestions 

On Sat, Aug 19, 2023, 9:15 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

But still  in  CCSDS case i am getting -0.3 only BER and not even saturating in FEC extended CC case(as per CCSDS Standard book it is dropping to 0 by 5dB)

On Sat, Aug 19, 2023 at 8:54 AM U L <jareddpub@gmail.com> wrote:

Hmm, this has gotten more complicated since your original post. Why?

A good place to start might be the example GRC as referenced on this page https://wiki.gnuradio.org/index.php?title=FEC_Extended_Decoder. You can change the FEC definitions from LDPC to CC and add a BER block with a delay b/w the input bytes and output bytes (bypass the char to float after the decoder). Once that's working, you can replace the FEC encoder with a CCSDS one.

Jared.

On Fri, Aug 18, 2023 at 9:05 PM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

I am getting need help pls look on the screenshot 

On Sat, Aug 19, 2023 at 8:23 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

I will try and let you know

On Sat, Aug 19, 2023, 8:08 AM U L <jareddpub@gmail.com> wrote:

Probably easier to use a vector source rather than text file. Vector source lets you specify the bytes exactly. So you could put in [ 0xdd, ] and be assured that byte will be output.

On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

What I tried is 11011101( by inputting a text file )it's hex version came in the output with (3131303131313031) like that with encoding by left shifting I got the value theoretically and decode I got dd (11011101) bt this worked over windows not in ubuntu,this output I have done using messag debug option I am not aware whether it is the correct way.

On Sat, Aug 19, 2023, 7:58 AM U L <jareddpub@gmail.com> wrote:

I don't understand what this means. How do you interpret it?

Jared.

On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

I have tried to do with a simple input 11011101 without noise and with noise noise also

On Sat, Aug 19, 2023, 7:52 AM U L <jareddpub@gmail.com> wrote:

Some ideas:

1. Remove the noise completely. Also use a fixed, repeating input vector rather than random bytes. Look at the actual error patterns between the input and output bits. Sometimes error patterns can clue you in.

2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)

3. Try the more general (non-CCSDS) extended encoder with the same params as the decoder.

4. Esp if 3 works, compare the output of CCSDS with general extended encoder.

Good luck.

Jared.

On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Hi,

Based on the given modifications still I am getting a -0.300 range of BER constantly from 0 to 15 dB range of SNR values.No variations are happening.

How can I check the functionality of the block(encoder and decoder to check whether it's encoding and decoding properly)with a sample input.

On Sun, Aug 13, 2023, 8:11 PM U L <jareddpub@gmail.com> wrote:

One other thing I noticed is that the encode CCSDS, decode, CCSDS, and BER blocks all  operate on packed bytes. (See e.g. https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do this you would change your random source to output from 0 to 256 byte values. Also, considering the output of the decoder block are packed bytes you should probably skip the byte->float and binary slicer after your decoder and just input it's output directly into the BER block. Finally, looking at the https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it seems the delay out of the decoder is 4 bytes, so you could add a delay of 4 between your source and BER block to align the two streams.

Jared.

On Sat, Aug 12, 2023 at 9:58 PM U L <jareddpub@gmail.com> wrote:

One thing I think might be an issue is that you have no delay between your source reference and your BER block. Usually the FEC decoders (and possibly the encoder?) may output blocks of 0s before they output the samples that correspond to your inputs. I don't know much about those FEC blocks specifically, but maybe the docs have some info on their delays. You can just insert a delay block b/w your random source and the ber block to align the input and output bits.

Hope that helps,

Jared.

On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:

Dear community

   Need help for BER plot using the above flowgraph its always coming 10^-1.17 and whenever I tried to change the noise voltage the values are not changing.

Please find the attached GRC file for your reference.

Regards, JIYA JOHNSON