discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] packets to the usrp and loopback


From: Thibaud Hottelier
Subject: Re: [Discuss-gnuradio] packets to the usrp and loopback
Date: Fri, 20 Apr 2007 17:07:33 -0400
User-agent: Thunderbird 2.0.0.0 (X11/20070413)

Brian Padalino wrote:
> There should be absolutely no glue logic between the modules within a
> top entity possibly called mblock_processing.  The inputs should feed
> the specialized USB FIFOs, and the outputs should feed the separate
> CIC channel filters (complex).
>
> Everything else from there should be straight forward with strobing
> samples in and out.
>

Yes, that's what I wanted to say :)

>> A what rate should I send the samples to the tx_chains? Every 4 clock
>> cycles? They seems to be controlled by tx_strobe, but I failed to
>> understand what this signal actually mean.
>
> The minimum interpolation rate is 4 due to the CIC filter limitations,
> so once every 4 will yield one side of the spectrum.  I believe 128 is
> the other end of the spectrum, but you should set a constant for the
> rate so we can test with different ones.

Ok, so my usb_chan_reader needs some more work to handle that. I will try to get this and some of the missing functionalities like reporting overrun/underrun done tomorrow.


> The tx_strobe happens once every rate clock cycles - with which it
> will send in a new sample.  That strobe sends a new value down the TX
> stream and reads a new one ready for the next tx_strobe.
>
>> What is the point of the bus_reset and the clear_status signal? They are
>> both input to current tx_buffer.
>
> I am not sure of this - but I am assuming to stop/reset the transmit
> path and clear any status messages respectively. :)  I'll try to have
> a look at the code and find out more later.
>

Thanks.

>> As we report overrun/underrun in packet header, are we gonna get rid of
>> the tx_empty, have_space and tx_underrun signal ?
>
> have_space is used by the feeding FX2 to know if the FPGA can handle
> one more packet.  This signal shouldn't go anywhere.  The other
> signals should probably stick around for now.
>
>> Comments on the code I checked in are welcome...
>
> I'll look it over this weekend and give comments and feedback.
>

That would be awesome :)

> Brian
>

Thibaud





reply via email to

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