About Reducing Latency When Implementing CSMA/NDA Protocol on Wireless Systems Using USRP Devices
Hello Dear Forum Members,
I have already posted at 14th April with the same issue, but since I could not
receive any reply, I decided to post again, sorry for inconvenience. 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
Re: Realtime Kernel, UHD 4.0, GNURadio
On 2022-05-05 14:52, Dobler, Anton wrote: Dear community, I am running UHD 4.0 and GNURadio 3.10 on a Ubuntu 20.04 with a N310 as a SDR. When I execute the benchmark_rate example with DPDK enabled, I do not see any under- or overruns even with the sampling rate set to 125 MHz, however using GNURadio - DPDK enabled here as well - I do not achieve that high sampling rate. The limit seems to be around 30MHz though. There's a very very large difference between the amount of "stuff" done with a typical Gnu Radio flow-graph, and the "benchmark_rate" example. The benchmark_rate example measures the *absolute maximum* you can expect to achieve while simply consuming/emitting samples that you otherwise do nothing with. Gnu Radio, even for a "trivial" example flow-graph tends to "touch" samples a lot more than benchmark_rate would. Just the nature of the framework. Do you know, apart from using taskset and isolcpus any other possibility to achieve higher sampling rates? Would it be an option to use the realtime kernel available for Ubuntu 20.04 and is this kernel compatible with GNURadio? I have never found the real-time options to be globally optimal, but, your mileage may vary. Any help also with regards to the usage of taskset and isolcpus would be highly appreciated! Thank you in advance! BR, Anton
GRC blocks become unresponsive w data stored in Variable Blocks
Hello GNURadio Community, Several Gnuradio tutorials show Variable Blocks that compute filter coefficients which are passed as input parameters to dsp signal processing blocks. In the past, I designed a GRC flow graph with a Variable Block that computes filter coefficients that were passed as an input parameter to a C++ OOT block I made. In the GRC, it is easy for me to import the scipy library and use a Variable Block to access the scipy library and conveniently design a filter that that does not exist in Gnuradio C++ library and pass the coefficients as an input parameter to my C++ signal processing block. I recently built a C++ OOT block which requires long filter lengths and four sets of filter coefficients rather than one. Problems are: Problem 1. When I type gnuradio-companion in the terminal and hit enter, it takes forever to load the GRC flow graph. Problem 2. When the GRC Flow Graph opens, if I click on any of the blocks, it takes forever to open and the same goes for editing and closing the block. Is it a problem that the GRC flow graph becomes unresponsive when there are filter coefficients to compute in Variable Blocks? Because if I disable these Variable Blocks, things become normal and responsive again. I would appreciate any suggestions! Regards, George
Re: Realtime Kernel, UHD 4.0, GNURadio
I have found that using chrt can make a big difference with USRP performance.When using rx hardware I will run my flowgraph with chrt -f 99 python3 my_flowgraph.py. Even when I run the ettus provided benchmarks, I have found that I will eventually drop data without realtime priority. If you are using GRC, there is an RT setting that you can apply. Either way, you have to have permissions set up properly to be able to elevate a process to have real time priority. I don't know about GNURadio compatibility with realtime linux, but I have never needed it. I've always been able to keep up using chrt and occasionally taskset. On Thu, May 5, 2022 at 4:13 PM Dobler, Anton wrote: > Dear community, > > > I am running UHD 4.0 and GNURadio 3.10 on a Ubuntu 20.04 with a N310 as > a SDR. > > > When I execute the benchmark_rate example with DPDK enabled, I do not see > any under- or overruns even with the sampling rate set to 125 MHz, however > using GNURadio - DPDK enabled here as well - I do not achieve that high > sampling rate. The limit seems to be around 30MHz though. > > > Do you know, apart from using taskset and isolcpus any other possibility > to achieve higher sampling rates? > > > Would it be an option to use the realtime kernel available for Ubuntu > 20.04 and is this kernel compatible with GNURadio? > > > Any help also with regards to the usage of taskset and isolcpus would be > highly appreciated! > > > Thank you in advance! > > > BR, > > > Anton >
Realtime Kernel, UHD 4.0, GNURadio
Dear community, I am running UHD 4.0 and GNURadio 3.10 on a Ubuntu 20.04 with a N310 as a SDR. When I execute the benchmark_rate example with DPDK enabled, I do not see any under- or overruns even with the sampling rate set to 125 MHz, however using GNURadio - DPDK enabled here as well - I do not achieve that high sampling rate. The limit seems to be around 30MHz though. Do you know, apart from using taskset and isolcpus any other possibility to achieve higher sampling rates? Would it be an option to use the realtime kernel available for Ubuntu 20.04 and is this kernel compatible with GNURadio? Any help also with regards to the usage of taskset and isolcpus would be highly appreciated! Thank you in advance! BR, Anton
Re: Reconfiguring the flowgraph after processing N samples
Oops, sorry. Wasn’t thinking about the whole application. I guess it would be impossible to do sample accurate control remotely since you’d have RPC propagation delay. You could however still switch the selector at runtime based on a counter though. > On May 5, 2022, at 11:51, Marcin Puchlik wrote: > > > Hi Paul, > But there is a requirement that switching has to be done after N samples, how > to control that from the external app? > >> On Thu, May 5, 2022, 17:25 Paul Atreides wrote: >> You can also use a selector block and switch the input at runtime from a >> separate application if you don’t want to incur the downtime of locking, >> reconfiguring and unlocking. >> >> >> On May 5, 2022, at 06:11, Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote: >>> >>> Hello, >>> To WarMonkey: I know how to make OOT and it seems that you don't understand >>> my question. >>> To Gregory: That's a brilliant idea. I just need a counter and based on >>> that just switch the branch in my flowgraph. I am going to try this. >>> Thanks! >>> >>> śr., 4 maj 2022 o 19:03 Gregory Warnes napisał(a): How about configuring two parallel data flows, with a switch that diverts from one to the other after N samples? — Gregory R. Warnes, Ph.D. (Sent from a mobile device, please excuse any typographical issues.) >> On May 4, 2022, at 11:32 AM, Marcin Puchlik via GNU Radio, the Free & >> Open-Source Toolkit for Software Radio wrote: >> > > Hello, > As far as I know, the "Head" block finishes the operation of a flowgraph > which I don't want to do. What OOT has to do? Any details? > > > śr., 4 maj 2022 o 17:21 WarMonkey napisał(a): >> use "Head" N samples, or create your own OOT module. >> >> Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for >> Software Radio 于2022年5月4日周三 22:11写道： >>> Hello Everyone, >>> I want to reconfigure my flowgraph after receiving N samples. I am >>> following this example: >>> https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure >>> Instead of using sleep(0.1) I want my flowgraph to lock after >>> consumption of N samples. Then I want to rearrange the flowgraph >>> blocks. Do you have any idea how to do this? >>> My guess is that I can use Performance Counters like nproduced for the >>> first block in my flowgraph and base on that, call lock() function on >>> my top_block(). What do you think? >>> Cheers >>> Marcin >>> >>>
Re: Reconfiguring the flowgraph after processing N samples
Hi Paul, But there is a requirement that switching has to be done after N samples, how to control that from the external app? On Thu, May 5, 2022, 17:25 Paul Atreides wrote: > You can also use a selector block and switch the input at runtime from a > separate application if you don’t want to incur the downtime of locking, > reconfiguring and unlocking. > > > > On May 5, 2022, at 06:11, Marcin Puchlik via GNU Radio, the Free & > Open-Source Toolkit for Software Radio wrote: > > > Hello, > To WarMonkey: I know how to make OOT and it seems that you don't > understand my question. > To Gregory: That's a brilliant idea. I just need a counter and based on > that just switch the branch in my flowgraph. I am going to try this. > Thanks! > > śr., 4 maj 2022 o 19:03 Gregory Warnes napisał(a): > >> How about configuring two parallel data flows, with a switch that diverts >> from one to the other after N samples? >> >> — >> Gregory R. Warnes, Ph.D. >> (Sent from a mobile device, please excuse any typographical issues.) >> >> On May 4, 2022, at 11:32 AM, Marcin Puchlik via GNU Radio, the Free & >> Open-Source Toolkit for Software Radio wrote: >> >> >> Hello, >> As far as I know, the "Head" block finishes the operation of a flowgraph >> which I don't want to do. What OOT has to do? Any details? >> >> >> śr., 4 maj 2022 o 17:21 WarMonkey napisał(a): >> >>> use "Head" N samples, or create your own OOT module. >>> >>> Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for >>> Software Radio 于2022年5月4日周三 22:11写道： >>> Hello Everyone, I want to reconfigure my flowgraph after receiving N samples. I am following this example: https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure Instead of using *sleep(0.1) *I want my flowgraph to lock after consumption of N samples. Then I want to rearrange the flowgraph blocks. Do you have any idea how to do this? My guess is that I can use *Performance Counters *like *nproduced *for the first block in my flowgraph and base on that, call *lock() *function on my *top_block()*. What do you think? Cheers Marcin
Re: Reconfiguring the flowgraph after processing N samples
You can also use a selector block and switch the input at runtime from a separate application if you don’t want to incur the downtime of locking, reconfiguring and unlocking. > On May 5, 2022, at 06:11, Marcin Puchlik via GNU Radio, the Free & > Open-Source Toolkit for Software Radio wrote: > > > Hello, > To WarMonkey: I know how to make OOT and it seems that you don't understand > my question. > To Gregory: That's a brilliant idea. I just need a counter and based on that > just switch the branch in my flowgraph. I am going to try this. Thanks! > > śr., 4 maj 2022 o 19:03 Gregory Warnes napisał(a): >> How about configuring two parallel data flows, with a switch that diverts >> from one to the other after N samples? >> >> — >> Gregory R. Warnes, Ph.D. >> (Sent from a mobile device, please excuse any typographical issues.) >> On May 4, 2022, at 11:32 AM, Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote: >>> >>> Hello, >>> As far as I know, the "Head" block finishes the operation of a flowgraph >>> which I don't want to do. What OOT has to do? Any details? >>> >>> >>> śr., 4 maj 2022 o 17:21 WarMonkey napisał(a): use "Head" N samples, or create your own OOT module. Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for Software Radio 于2022年5月4日周三 22:11写道： > Hello Everyone, > I want to reconfigure my flowgraph after receiving N samples. I am > following this example: > https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure > Instead of using sleep(0.1) I want my flowgraph to lock after consumption > of N samples. Then I want to rearrange the flowgraph blocks. Do you have > any idea how to do this? > My guess is that I can use Performance Counters like nproduced for the > first block in my flowgraph and base on that, call lock() function on my > top_block(). What do you think? > Cheers > Marcin > >
Announcing NEWSDR on Friday June 3
We would like to announce NEWSDR 2022 !! The event will be held on Friday June 3. NEWSDR is fully virtual this year. The event requires registration, but is completely free. Please see our website for the event agenda and more information: https://newsdr.org/workshops/newsdr2022/ Updates to the agenda will be coming next week! Please register at: https://forms.gle/CEbSFtaxBu8iARo87 Interested in presenting? Please submit an abstract for your poster / spotlight talk here: https://forms.gle/E6nLSsh9JhjFAED36
Re: Reconfiguring the flowgraph after processing N samples
Hello, To WarMonkey: I know how to make OOT and it seems that you don't understand my question. To Gregory: That's a brilliant idea. I just need a counter and based on that just switch the branch in my flowgraph. I am going to try this. Thanks! śr., 4 maj 2022 o 19:03 Gregory Warnes napisał(a): > How about configuring two parallel data flows, with a switch that diverts > from one to the other after N samples? > > — > Gregory R. Warnes, Ph.D. > (Sent from a mobile device, please excuse any typographical issues.) > > On May 4, 2022, at 11:32 AM, Marcin Puchlik via GNU Radio, the Free & > Open-Source Toolkit for Software Radio wrote: > > > Hello, > As far as I know, the "Head" block finishes the operation of a flowgraph > which I don't want to do. What OOT has to do? Any details? > > > śr., 4 maj 2022 o 17:21 WarMonkey napisał(a): > >> use "Head" N samples, or create your own OOT module. >> >> Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for Software >> Radio 于2022年5月4日周三 22:11写道： >> >>> Hello Everyone, >>> I want to reconfigure my flowgraph after receiving N samples. I am >>> following this example: >>> https://www.gnuradio.org/doc/doxygen-3.7.4/index.html#reconfigure >>> Instead of using *sleep(0.1) *I want my flowgraph to lock after >>> consumption of N samples. Then I want to rearrange the flowgraph blocks. Do >>> you have any idea how to do this? >>> My guess is that I can use *Performance Counters *like *nproduced *for >>> the first block in my flowgraph and base on that, call *lock() *function >>> on my *top_block()*. What do you think? >>> Cheers >>> Marcin >>> >>> >>>
