[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of sam

From: Josh Blum
Subject: Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
Date: Thu, 04 Mar 2010 11:36:02 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100217 Shredder/3.0.3pre

Couple more questions if you don't mind:
1) Where does the number of items per packet (which is 365 in my case) comes
from? Or is it the format USRP2 always uses to send the data to the host?

Its probably the MTU (1500 bytes) minus the ip/udp/ethernet headers sizes minus the size of the vrt headers. Basically, the maximum number of samples per frame.

2) After specifying -N as 1000 I got the following output:

Got packet: 1267693414 secs, 35564266 ticks
Got packet: 1267693414 secs, 35570106 ticks
Got packet: 1267693414 secs, 35575946 ticks

So the number of ticks between the packets is 5840, dividing by 365 we get
16-the number of ticks per sample, and the decimation is 16 which is
consistent. My question is: if I want to extract the timestamps for each
sample individually I would need to take the timestamp of the packet and
subtract the required number of 16*N (e.g. for the sample number 300 in the
first packet the timestamp is 35564266-65*16=35563226) or is there a
different way the get hold of timestamps for individual samples?

That's correct:
The Nth sample will be N*usrp2_clock_rate/samp_rate ticks offset from the timestamp or in this case N*16 ticks offset. Each sample has a temporal ambiguity equal to the width of 16 clock ticks.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]