[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] inband timestamp issues

From: George Nychis
Subject: Re: [Discuss-gnuradio] inband timestamp issues
Date: Tue, 19 Aug 2008 09:43:27 -0700
User-agent: Thunderbird (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

reply via email to

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