[Top][All Lists]

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

Re: [Discuss-gnuradio] inband timestamp issues

From: Steve Peters
Subject: Re: [Discuss-gnuradio] inband timestamp issues
Date: Wed, 20 Aug 2008 17:45:16 -0500

> 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.

Correct me if I misunderstand, but you're not actually clocking
anything this way.  Theoretically it should work, but there's nothing
telling me there weren't actually a million clock cycles between two
packets.  There should definitely be a timestamp clock tied to the
master clock, in my opinion.

Ketan and I discussed a couple possibilities earlier today.  One might
be to have a timestamp buffer in parallel with the RX FIFO.  Although
problems arise with making sure the timestamp changes at the border of
packets, unless there is one timestamp per sample, which is almost
certainly too excessive.

Another idea is to move the FIFO to the other side of the packet
builder, as long as the packet builder can keep up with the
ADC/decimator output.  It then outputs to the buffer.  This was
Ketan's idea, so I apologize if I'm communicating it incorrectly.

> - George


reply via email to

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