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

[ValentinG]

And the offset seems to be positive, i.e. the packet timestamp is the time of
the first sample in the packet and not of the last one (referring to my
previous calculation: for the sample number 300 in the first packet the
timestamp is 35564266+300*16=35569066). I've come up to this conclusion by
applying a PPS signal to the boards and calling
u2->set_time_at_next_pps(5,0) and the output was:
...
Got packet: 212 secs, 12258426 ticks
Got packet: 212 secs, 12264266 ticks
Got packet: 5 secs, 2244 ticks
Got packet: 5 secs, 8084 ticks
...
where 2244 is not divisible by 16, hence represents some sort of delay
before the first sample gets received after the clock reset. Or am I missing
something?

Valentin


Josh Blum-2 wrote:
> 
>> 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.
> 
> -Josh
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27785768.html
Sent from the GnuRadio mailing list archive at Nabble.com.