# Sampling glitch in the RX path **URL:** \ **Category:** GNU Radio\ **Created:** [June 5, 2013, 5:59pm UTC](https://www.ruby-forum.com/t/sampling-glitch-in-the-rx-path/235197 "2013-06-05T17:59:39Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![alcina](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a587f6/32.png) [@alcina](https://www.ruby-forum.com/u/alcina)\ **Post date:** [June 5, 2013, 5:59pm UTC](https://www.ruby-forum.com/t/sampling-glitch-in-the-rx-path/235197/1 "2013-06-05T17:59:39Z")
Hi Guys, I am using N210 with SBX at 5M sampling rate. I have one USRP Source running continuously (connected to the TX/RX antenna), and a USRP Sink (connected also to TX/RX) that sends timed packets with the tx\_time, tx\_sob, tx\_eob tags at a rate of 1 ms per packet. I am sending packets 10 ms prior to the USRP Sink and I use the sample counter of the USRP Source to monitor the time on the FPGA. After some time I am observing timing errors (L) that I cannot explain. The only possible explanation would be a sampling glitch in the RX path when switching between TX and RX. That is, it seems that a few samples are lost in the RX path when the switch is made, and therefore the FPGA time and the number of samples received are diverging over time (by a small amount for each switch). I do not observe this behavior at 500K sampling rate, there no RX samples seem to be lost. There are no underruns/overruns prior to the lots of L’s. Any ideas why this is happening and whether it can be prevented somehow? Miklos ---
**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\ **Post date:** [June 5, 2013, 6:17pm UTC](https://www.ruby-forum.com/t/sampling-glitch-in-the-rx-path/235197/2 "2013-06-05T18:17:46Z")
If there are no overruns, you are most likely not dropping samples. The switch from rx to tx and back will not impact the received sample stream. Increase your packet lead time from 10 ms. Keep in mind that the PC will have some process jitter so that actual transfer of the burst may vary from the nominal 10 ms lead you’re asking for. If the PC is a little slow, or the OS is busy doing something else, you might deliver a late packet. Anyway, once you’ve got the system working consistently, you can working on optimizing things for lower latency (lead time). -John ---
**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\ **Post date:** [June 5, 2013, 7:37pm UTC](https://www.ruby-forum.com/t/sampling-glitch-in-the-rx-path/235197/3 "2013-06-05T19:37:13Z")
Hi John, Thanks for the quick reply. Increasing the lead time will just delay the occurrence of the storm of L’s (when the host gets permanently behind the USRP). Here is some data which supports this claim and I think the TX/RX switch rate influences these: 1. I periodically send for 0.9 ms timed with tx\_time, tx\_sob, tx\_eob, followed by 0.1 ms gap. I use 20 ms lead time, and I measure the number of seconds the flowgraph can run before it falls behind (lots of L’s). I have run this 3 times, and got 43 sec, 44 sec, 37 sec. 2. 0.9 ms TX, 0.1 ms RX, 30 ms lead, runs for 60 sec, 53 sec, 67 sec 3. 0.9 ms TX, 0.1 ms RX, 40 ms lead, runs for 107 sec, 87 sec, 104 sec Thus run time increased linearly with the increase of the lead time. 1. 0.4 ms TX, 0.1 ms RX, 40 ms lead, runs for 55 sec, 62 sec, 54 sec Thus if you increase the rate of TX/RX switches then the run time decreases linearly 1. 1 ms TX, 1 ms RX, 20 ms lead, runs for 149 sec, 124 sec, 68 sec 2. 1 ms TX, 1 ms RX, 40 ms lead, runs for 391 sec, 219 sec, 283 sec Thus decreasing the packet rate will increase the run time. In scenario 5) and 6) it will gradually get more and more L’s (between packets) until it hits the wall. And I also observe U’s but no O’s overruns. Thus as we are eating up our lead time and getting closer to the edge the USRP is not getting enough data and the times are getting worse and worse until all of the packets are in the past. From this I deduce that there must be an RX sampling glitch when switching between TX/RX, no? Best, Miklos