# Active Reflector **URL:** \ **Category:** GNU Radio\ **Created:** [June 18, 2015, 6:50pm UTC](https://www.ruby-forum.com/t/active-reflector/242360 "2015-06-18T18:50:48Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [June 18, 2015, 6:50pm UTC](https://www.ruby-forum.com/t/active-reflector/242360/1 "2015-06-18T18:50:48Z")
Hello all, I’m trying to do ranging using two USRPs N210. The idea is that the first USRP sends a signal and then the second USRP recognize it and send the signal back. Looking to the turnaround time I would be able to know the ranging. Despite some problems that I already had, right now I’m stuck with the second USRP. To measure the time I’m synchronizing the rx ant tx from the first USRP using the following code: ``` now = self.uhd_usrp_sink_0.get_time_now() self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(0.1) + ``` now) self.uhd\_usrp\_sink\_0.set\_start\_time(uhd.time\_spec\_t(0.1) + now) Using the fisrt USRP I can do ranging, connecting both (rx and tx) together, with a good precision. However I couldn’t make the second USRP work yet. When I try to synchronize the tx and rx like I did in the first USRP I get a bunch of Ls (late packages) in the terminal. The code drop all the packages. My gnuRadioCompanion blocks for the second USRP looks roughly like USRP Source -\> threshold -\> USRP Sink There’s a better way to solve that problem? Why do I get the late packages? Thanks in advance, Rafael. PS: To analyze the data that I’m sending I’m using File Sink block and analyzing the data after the transmission. ---
**Author:** ![Rafael\_Acurcio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a698b9/32.png) [@Rafael\_Acurcio](https://www.ruby-forum.com/u/Rafael_Acurcio)\ **Post date:** [June 18, 2015, 7:01pm UTC](https://www.ruby-forum.com/t/active-reflector/242360/2 "2015-06-18T19:01:55Z")
Hi Rafael, what you’re trying to build is not a causal system – you tell the sink to start transmitting the first sample right at the same moment that your source receives the first sample – but between that, the samples have to flow through your PC! Add a bit of delay between rx and tx. Also, what daughterboard are you using? Unless you use one of the daughterboards that support static phase after tuning, and tune as a timed command, the LO phase between the RX and TX will be random [1] Best regards, Marcus [1] [USRP Hardware Driver and USRP Manual: Device Synchronization](http://files.ettus.com/manual/page_sync.html#sync_phase_lo) ---
**Author:** ![Rafael\_Acurcio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a698b9/32.png) [@Rafael\_Acurcio](https://www.ruby-forum.com/u/Rafael_Acurcio)\ **Post date:** [June 18, 2015, 8:14pm UTC](https://www.ruby-forum.com/t/active-reflector/242360/3 "2015-06-18T20:14:57Z")
Hi Marcus, I’m using the WBX daughter board. I though the late packages problem could be because of the processing time between receiving a sample and sending it back. And I have tried to I used the delay difference like this: ``` now = self.uhd_usrp_sink_0.get_time_now() self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(1) + now) self.uhd_usrp_sink_0.set_start_time(uhd.time_spec_t(1.001) + ``` now) And the results are very reasonable. However in the second USRP sometimes an underflow occurs (U printed in the terminal) followed by a few late packages (Ls printed in the terminal) that I believe that happens because of some queue being filed. It happen apparently in random times (every few seconds). Thanks a lot for you help Marcus! ---
**Author:** ![Rafael\_Acurcio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/a698b9/32.png) [@Rafael\_Acurcio](https://www.ruby-forum.com/u/Rafael_Acurcio)\ **Post date:** [June 18, 2015, 8:35pm UTC](https://www.ruby-forum.com/t/active-reflector/242360/4 "2015-06-18T20:35:24Z")
Rafael, 1ms delay is pretty good, considering that you need to pack one complete ethernet packet of samples, send it to the PC, unpack that package, repack it, and send it to the USRP – the main delay here is probably your OS. Since both of your USRP are time-synced, I assume both are frequency- and hence sampling-rate-synced, too, so the U’s are an indication for the delay not being large enough for the PC to _guarantee_ that it can keep up with the samples. Greetings, Marcus