[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 12:18:12 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100217 Shredder/3.0.3pre

On 03/04/2010 11:56 AM, ValentinG wrote:

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

Yes, the timestamp that comes with the vrt header is the timestamp for the first sample in that packet.

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

Unless, you use the start streaming with a timestamp, the timestamp that you see above will be somewhat arbitrary as to where it starts.

In the above case, the pps event occurs within: "Got packet: 212 secs, 12264266 ticks" Which explains why the third packet "Got packet: 5 secs, 2244 ticks" has a significantly larger than zero ticks value.


reply via email to

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