Hi Mehmet - As nobody else has responded in any capacity, let me do so from an Ettus Support perspective.
The reason your query isn't being answered is that it is highly technical, with lots of details, and a very specific use-case that would require someone many hours of work to process. Sometimes we get lucky and there are folks who are already experts in the multiple domains required and who have thus already put in the hours to understand the intersecting domains well enough to be able to respond quickly. Sometimes not -- and, this seems to be one of those cases. It is not clear to me that this issue is related to UHD / USRP; I'm guessing it has more to do with the GNU Radio / data processing side of things. General advice for minimizing latency in GNU Radio can be found online include: * Use C++, not Python, for blocks. Broadly speaking: Python will be slower. GNU Radio uses Python for graph connectivity & other non-speed-critical logistics. * Reduce the maximum number of items to be processed to whatever minimum is possible. There are options in the block settings to do this, plus or minus. Broadly speaking: Processing fewer samples per block reduces latency. * If GNU Radio still supports block profiling then reinstall GR with that option enabled (and if I recall the required Thrift dependency) and run your flowgraph to see where the high-CPU use blocks are and then try to create alternative implementations that reduce CPU usage. Broadly speaking: Higher CPU usage results in more latency. I hope this is useful! - MLD --- Dr Michael L Dickens Principal NI/Ettus Technical Support Engineer On Thu, May 5, 2022 at 4:48 PM Mehmet Fatih Ayten <mehmet.fatih.ay...@vub.be> wrote: > 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 "1111" and "1000" transmit, the delay is > 73 ms; where 2 Tx nodes with arbitration field "1111" 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 Regards, > > Mehmet Fatih Ayten > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows > > > _______________________________________________ > Commit-gnuradio mailing list > commit-gnura...@gnu.org > https://lists.gnu.org/mailman/listinfo/commit-gnuradio >
