|
From: | George Nychis |
Subject: | Re: [Discuss-gnuradio] inband timestamp issues |
Date: | Tue, 19 Aug 2008 09:43:27 -0700 |
User-agent: | Thunderbird 2.0.0.16 (X11/20080724) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |