[Top][All Lists]

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

Re: [Discuss-gnuradio] USRP packet parsing

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] USRP packet parsing
Date: Fri, 23 Mar 2007 15:24:03 -0700
User-agent: Mutt/1.5.9i

On Fri, Mar 23, 2007 at 02:59:37PM -0400, Brian Padalino wrote:
> On 3/23/07, Thibaud Hottelier <address@hidden> wrote:
> >So, let me summarize:
> >
> >One dual clock fifo (usb_fifo) to buffer the packet from the FX2. One
> >process store the data from the usb while one other process read them
> >and splits commands (stored in cmd_fifo) from data (stored in
> >chan0_fifo, chan1_fifo, etc). The data in chanX_fifo would be stored
> >like this:
> >
> >:            :
> >|  sample 2  |
> >|  sample 1  |
> >|  #samples  |
> >| timestamps |
> >+------------+
> >
> >For each channel fifo, a process would wait for the timestamps to match
> >the time register and then write the next <#samples> to the
> >corresponding channel transmit chain at every tx_clock tick. So we end
> >up with (#channel + 1) fifos.
> >
> >The problem I see is that between to block of samples in the fifo, there
> >will be some processing delay to read the next timestamps and the
> >#samples. That's why I added a fifo between the usb_fifo and the
> >chanX_fifo in the diagram on the wiki. Is that a real problem?
> I was under the impression that if a timestamp is reached that is
> already in the past, but was not able to be sent out, a signal will be
> asserted stating that it could not be processed.  After that, the
> offset of the samples will be added to the read pointer, and the next
> timestamp should be read.  This shouldn't take longer than a few clock
> cycles at most.
> On a related note and to keep processing continuous, should the
> original packet header that starts the packet and identifies the first
> data samples have the actual number of data samples in the entire
> packet to be sent down and not just the current samples length?  That
> way you can have an uninterrupted stream of samples for each
> timestamp.

I was thinking that we could handle that with the S + E flags in the
packet header.  It seems like less state to deal with, and also allows
the host to begin transmitting a frame before it knows the full
length.  Lower latency too.

> There probably won't be any hiccups as long as the output sample rate
> is less than 64e6/3 since we will have to go from SENDING_SAMPLES ->
> state machine feeding the TX values.
> Brian


reply via email to

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