RFNOC gain example warning
Hi, I followed step by step the oot gain tutorial for RFNOC and was able to generate the image with the 0/Block#0. I loaded it onto the X310 and uhd_usrp_probe returned the expected result displaying the newly added block but with a warning stating the block with noc id 0xb16, 0x was not found. Is this normal? And also, if a cpp application would make use of that particular block, would it even be able to instantiate it? I am having trouble right now because my program cannot find the 0/Block#0. Am I missing anything? Maxime
Re: How to get information on number of input data samples in C++ OOT
Hi George, On 14/04/2022 01.19, George Edwards wrote: > I am writing a Gnuradio C++ OOT block and need to get the number of complex > input data samples fed into my block by the scheduler on each iteration of > data delivery. > In Python, it is easy, I can find the value by doing: numInputs = > len(input_items[0]). In the C++ general_work method which I paste below, I > have not been able to extract the number of input samples from any of the > parameters. > [image: image.png] The ninput_items[0] contains the length of input_items[0]. From https://wiki.gnuradio.org/index.php/BlocksCodingGuide#Basic_Block The general work has a parameter: ninput_items ninput_items is a vector describing the length of each input buffer Regards, Vasil
Re: Options - QT GUI window size and placement
Hi Gavin, that's not a functionality of GNU Radio itself (at least we don't have any calls to the Qt-typical "saveGeometry"/"restoreGeometry" in our source code); it must be your window manager? So, I sadly can't advise on how to achieve that, sorry. Best, Marcus On 13.04.22 18:50, Gavin Jacobs wrote: I recently built a laptop with Ubuntu 20.04 and then built gnuradio 3.10.2 from source. I noticed that the Hackrf is now supported through the SoapySDR source/sink blocks (rather than the Osmocom blocks), so I made some examples & tests of hackrf rx and tx. Works fine, but I have a question. Previously the window that starts when the flowgraph is executed (i.e. the popup window with the QT GUI widgets and instrumentation), would remember the window size and placement; but now it doesn't. In 3.10.2 how do I control the window size and placement? Thanks, Jake smime.p7s Description: S/MIME Cryptographic Signature
About Reducing Latency When Implementing CSMA/NDA Protocol on Wireless Systems Using USRP Devices
Hello Dear Forum Members,
I am Fatih from Vrije Universiteit Brussels, and writing to ask for any
suggestion about the Reducing Latency When Implementing CSMA/NDA Protocol on
Wireless Systems Using USRP Devices.
Firstly, I would like to briefly mention about CSMA/NDA protocol so, my
question means more for you.
CSMA/NDA (Carrier Sense Multiple Access/Non Destructive Arbitration) protocol
is employed mainly in Control Area Network (CAN) buses. If 2 or more
transceiver nodes want to broadcast simultaneously, the winner node is
determined by arbitration fields of transceivers. The winner node continues
transmitting, while other nodes become silent. Arbitration fields are generally
composed of 12 bits, and recessive and dominant bits can be chosen by the
designer. To give an example, lets assume length of arbitration field is
decided as 4 bits and 2 transceivers want to broadcast their message on the bus
network. Also, dominant bit is selected as "1":
Node 1: -start of arbitration field- 1 1 1 1 -end of arbitration field- -start
of meaningful message- 1 0 0 1 0 0 1 0 1 -end of meaningful message-
Node 2: -start of arbitration field- 1 0 0 0 -end of arbitration field- -start
of meaningful message- 0 1 0 1 1 1 0 1 0 -end of meaningful message-
Since arbitration field of Node 1 includes more 1's, it is more dominant than
Node 2, therefore as time goes on, Node 2 will become silent and message of
Node 1 will appear on the bus.
In my project, I am trying to implement this protocol in a wireless fashion. I
use two USRP X310
SDRs, one OctoClock CDA-2990 Clock Distribution Device in order to maintain
synchronization between
SDRs, one Gigabit ethernet switch in order to make connection between PC and
SDRs. Wireless communication between SDRs has been maintained using VERT2450
Vertical Antennas. Also, experiments have been conducted in real-time on the
host PC using the GNU Radio framework.
The flowgraph that I use is in this link:
https://drive.google.com/file/d/1iBkg8wWBPxVkYtm8LsT2qiPHqlvlZ6mj/view?usp=sharing
As you can see from the flowgraph, two Tx nodes transmit their bits, one
receiver reveives bits, then according to resulting received bits, command is
sent to transmitters. In order to create this command, I have created an
Embedded Python Block and its content is as follows (or you can check
screenshot from the link:
https://drive.google.com/file/d/1NCLQIKK_qp1Ltdf3fswCUsjxGKay1HKH/view?usp=sharing):
import numpy as np
from gnuradio import gr
import pmt
class blk(gr.basic_block):
def __init__(self, check=1.0):
gr.sync_block.__init__(
self,
name='Embedded Python Block',
in_sig=[np.int32,np.int32],
out_sig=[np.int32]
)
self.check = check
self.message_port_register_out(pmt.intern('Gain Changer Message Port'))
def work(self, input_items,output_items):
if self.check ==1:
if (not (sum(input_items[0][0:4]) == sum(input_items[1][0:4]))):
self.message_port_pub(pmt.intern('Gain Changer Message Port') ,
pmt.dict_add( pmt.make_dict() , pmt.intern("gain") , pmt.from_double(0)))
self.check =2
if self.check ==2:
pass
return(len(output_items[0]))
By doing so, I am trying to compare first 4 bits of message (arbitration field
of the corresponding node) and the first 4 bits of the received bits. If they
are equal, gain is kept same (or high); otherwise gain is set to 0 dB, i.e,
transmission stops.
Also, I maintain the synchronization by adding the flollowing commands to
generated Python file:
self.uhd_usrp_source_0.set_time_next_pps(uhd.time_spec_t(0.0));
self.uhd_usrp_sink_0.set_time_next_pps(uhd.time_spec_t(0.0));
self.uhd_usrp_sink_0_0.set_time_next_pps(uhd.time_spec_t(0.0));
time.sleep(1)
self.uhd_usrp_sink_0.set_start_time(uhd.time_spec_t(2))
self.uhd_usrp_sink_0.clear_command_time()
self.uhd_usrp_sink_0_0.set_start_time(uhd.time_spec_t(2))
self.uhd_usrp_sink_0_0.clear_command_time()
self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(2))
self.uhd_usrp_source_0.clear_command_time()
By doing so, I aim to make the SDRs start transmission at the same time.
In this configuration, I have faced 2 problems:
1. Delay is not as low as I desired: The data rate is kept in 1 kbps. After
this methods, the effect of CSMA/NDA appears in 74th received bit which means
nearly 74 ms delay.
2. For different arbitration fields, the delay changes. For example, when 2 Tx
nodes with arbitration field "" and "1000" transmit, the delay is 73 ms;
where 2 Tx nodes with arbitration field "" and "1100" transmit, the delay
is 167 ms. Therefore, the delay could not be standardized and it does not offer
a fit implementation.
With all this information, I would like to kindly ask for your suggestions to
reduce and fix the delay. Any idea about the flowgraph and Embedded Python
Block is highly appreciated.
Kind Reg
Re: Options - QT GUI window size and placement
I looked in the Python code generated by grc, and the call to saveGeometry is there in closeEvent() ! But, it is not working in my flowgraph because the flowgraph exits with: >>> Done (return code -11) which means that the closeEvent doesn't get a chance to save the geometry. The -11 return codes happen if the flowgraph includes the "Soapy HackRF Source" or "Soapy HackRF Sink" block. I think this is a bug that no one noticed. The workaround is to disable those blocks and connect a null source or sink, run the flowgraph, set the desired geometry, exit the flowgraph, then disable the null and re-enable the Soapy Hackrf. Date: Thu, 14 Apr 2022 12:59:18 +0200 From: Marcus Müller To: Subject: Re: Options - QT GUI window size and placement Message-ID: Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi Gavin, that's not a functionality of GNU Radio itself (at least we don't have any calls to the Qt-typical "saveGeometry"/"restoreGeometry" in our source code); it must be your window manager? So, I sadly can't advise on how to achieve that, sorry. Best, Marcus On 13.04.22 18:50, Gavin Jacobs wrote: > I recently built a laptop with Ubuntu 20.04 and then built gnuradio 3.10.2 > from source. I > noticed that the Hackrf is now supported through the SoapySDR source/sink > blocks (rather > than the Osmocom blocks), so I made some examples & tests of hackrf rx and > tx. Works fine, > but I have a question. > > Previously the window that starts when the flowgraph is executed (i.e. the > popup window > with the QT GUI widgets and instrumentation), would remember the window size > and > placement; but now it doesn't. In 3.10.2 how do I control the window size and > placement? > > Thanks, > Jake
Re: Options - QT GUI window size and placement
Hi Gavin, On 14/04/2022 20.45, Gavin Jacobs wrote: > I looked in the Python code generated by grc, and the call to saveGeometry is > there in closeEvent() ! > But, it is not working in my flowgraph because the flowgraph exits with: Done (return code -11) Return code -11 means SIGSEGV Segmentation Fault. >From >https://docs.python.org/3/library/subprocess.html#subprocess.Popen.returncode A negative value -N indicates that the child was terminated by signal N (POSIX only). and from "man 7 signal" SIGSEGV 11 CoreInvalid memory reference To investigate the problem you need to run your flowgraph under gdb. In your terminal go in the directory where your flowgraph .py file is and execute gdb --ex run --args /usr/bin/python3 ./flowgraph.py When it crash you are going to see the gdb prompt, then run (gdb) bt Provide the full output if you need some more help with this. Regards, Vasil > which means that the closeEvent doesn't get a chance to save the geometry. > The -11 return codes happen if the flowgraph includes the "Soapy HackRF > Source" or "Soapy HackRF Sink" block. > I think this is a bug that no one noticed. > > The workaround is to disable those blocks and connect a null source or sink, > run the flowgraph, set the desired geometry, exit the flowgraph, then disable > the null and re-enable the Soapy Hackrf. > > > > > > Date: Thu, 14 Apr 2022 12:59:18 +0200 > From: Marcus Müller > To: > Subject: Re: Options - QT GUI window size and placement > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Gavin, > > that's not a functionality of GNU Radio itself (at least we don't have any > calls to the > Qt-typical "saveGeometry"/"restoreGeometry" in our source code); it must be > your window > manager? > So, I sadly can't advise on how to achieve that, sorry. > > Best, > Marcus > > On 13.04.22 18:50, Gavin Jacobs wrote: >> I recently built a laptop with Ubuntu 20.04 and then built gnuradio 3.10.2 >> from source. I >> noticed that the Hackrf is now supported through the SoapySDR source/sink >> blocks (rather >> than the Osmocom blocks), so I made some examples & tests of hackrf rx and >> tx. Works fine, >> but I have a question. >> >> Previously the window that starts when the flowgraph is executed (i.e. the >> popup window >> with the QT GUI widgets and instrumentation), would remember the window size >> and >> placement; but now it doesn't. In 3.10.2 how do I control the window size >> and placement? >> >> Thanks, >> Jake > >
Re: How to get information on number of input data samples in C++ OOT
Hi Jeff and Vasil, Thank you very much! George On Wed, Apr 13, 2022 at 7:21 PM Jeff Long wrote: > The C++ API gives you ninput_items explicitly, so ninput_items[0] is the > number of items in input_items[0]. > > On Wed, Apr 13, 2022 at 7:18 PM George Edwards > wrote: > >> Hello GNURadio Community, >> >> I am writing a Gnuradio C++ OOT block and need to get the number of >> complex input data samples fed into my block by the scheduler on each >> iteration of data delivery. I need to know this information because the >> relationship between my input and output stream is not as simple as say a >> one to one I/O as the "sync" block. >> >> In Python, it is easy, I can find the value by doing: numInputs = >> len(input_items[0]). In the C++ general_work method which I paste below, >> I have not been able to extract the number of input samples from any of the >> parameters. >> [image: image.png] >> >> I will appreciate any help provided. >> Thank you! >> George >> >> >
