discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP packet parsing


From: Thibaud Hottelier
Subject: Re: [Discuss-gnuradio] USRP packet parsing
Date: Fri, 23 Mar 2007 15:10:42 -0400
User-agent: Thunderbird 2.0b2 (X11/20070319)

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.

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 ->
CHECK_NEXT_TIMESTAMP -> READ_SAMPLE_LENGTH -> SENDING_SAMPLES in a
state machine feeding the TX values.

Ok, sounds good. By tomorrow, I will update the wiki page, add the state machines and figure out the fifo/ram sizes. Is there any other information that would be useful to state?

Thibaud


Brian






reply via email to

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