Re: [Discuss-gnuradio] Sampling glitch in the RX path

[John Malsbury]

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

On Wed, Jun 5, 2013 at 8:58 AM, Miklos Maroti <address@hidden> wrote:

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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio