[Top][All Lists]

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

RE: [Discuss-gnuradio] inband timestamp issues

From: Eric Schneider
Subject: RE: [Discuss-gnuradio] inband timestamp issues
Date: Thu, 21 Aug 2008 01:11:39 -0600

Hi all,  I'd really like to help with this.  I've been pouring over the
design (usrp_inband_usb), so my brain is a little mushy at the moment,
hopefully I'm not totally off track here.

1. Is it true that there are N RX Sample FIFOs?  It seems that the channels
are already muxed by the time they get to the packet_builder, no?

2. Can we just subtract the FIFO size (usedw?) from the timestamp in the
packet builder?

3. When checking timestamps for expired command/data packets, is an
overflow/wraparound on the timestamp_clock handled?  (ref cmd_reader.v:107,

4. I wholeheartedly agree that it would be nice to have a "read N samples at
time T command".


-----Original Message-----
From: Brian Padalino [mailto:address@hidden 
Sent: Wednesday, August 20, 2008 5:12 PM
To: Steve Peters
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] inband timestamp issues

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


Discuss-gnuradio mailing list

reply via email to

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