Re: [Discuss-gnuradio] inband timestamp issues

[Brian Padalino]

On Wed, Aug 20, 2008 at 6:45 PM, Steve Peters <address@hidden> wrote:
>> 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.

The current inband RX chain looks like:

    N RX Sample Streams -> N RX Sample FIFOs -> 1 Packet Builder -> 1
USB FIFO -> FX2 USB Interface

What it should look like (in my opinion):

    N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1
FIFO MUX -> FX2 USB Interface

I believe the TX chain looks more like this, except with the arrows
going in the opposite direction.

On a side note, it might be interesting to have a command that can
turn on the receiver and receive a specific number of inband packets.
For example, if you know you may be receiving a transmission that is
only 2ms long in a specific slot, it might be beneficial to only
schedule 2ms (+/- a guard time) worth of samples to be delivered to
the host, freeing up more CPU cycles for signal processing and using
the USB bandwidth a little more efficiently.

Comments or suggestions?

Brian