Re: [Discuss-gnuradio] inband timestamp issues

[George Nychis]

Thanks Brian!

Brian Padalino wrote:
> Just to clarify the situation - the current packet_builder is hooked
> up after the sample buffers so as it is building one packet, it cannot
> build another.  That is why when 2 channels were used, they would be
> received 270+ samples from each other as that is around the time it
> takes to generate the full packet.  Moreover, the timestamp actually
> had nothing to do with the actual sample time - just the time the
> packet was built.  Therefore, no 2 packets could have the same
> timestamp (which should be possible).

I would think that if 2 channels are used, you would be getting a packet 
from each channel with the same timestamp.  I don't think there should 
be any offset between them.  Right, so the current timestamp is more of 
a "I built this packet at time X."

As a non-hardware person, I was thinking that a simple solution is to 
not really use the clock on the RX directly, but timestamp packets 
indirectly.  You have a signal when the sample buffer is empty, when 
that signal is de-asserted for the first time, read the clock and take 
this as your initial RX clock time.

Now, you go by the fact that you're sampling at a constant rate and 
timestamp packets based on that.  The next packet gets timestamped at 
last_timestamp + 126samples_per_packet * decimation_rate.

That way you're not timestamp on packet building, but logically the time 
the first sample of the packet arrived at the RX buffer.

- George