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