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

[Josh Blum]

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
> something?

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.

-Josh