Re: [Discuss-gnuradio] USB packet format / inband signaling

[Thibaud Hottelier]

Brian Padalino wrote:
> Hi Thibaud,
> 
> Here is my response as to how I understand things to work - which
> could be completely wrong.
> 
> On 2/27/07, Thibaud Hottelier <address@hidden> wrote:
>> Hi all,
>>
>> First of all, I would like to make sure that I have understood what is
>> going to be modified. I have made a diagram with the whole Gnuradio
>> component stack: http://img168.imageshack.us/img168/415/groveralleb2.png
>>
>> 1) The new usb packet will be encoded/decoded in the gnuradio uspr
>> driver and in the FX2 firmare right?
> 
> On the host side, the message blocks will queue up the commands and
> create the packet structure that will go down to the USRP driver and
> be delivered by libusb.
> 
> A specific endpoint within the FX2 will be used to figure out if it's
> an m-block packet or something else (like a packet to tell the FX2 to
> program the FPGA).
> 
> The FX2 firmware will then be pretty transparent and pass along the
> information over the same datapath as the current TX/RX samples.
> 
> Once inside the FPGA, some command parsing happens and the samples are
> sent on through to a FIFO where they sit until their timestamp comes
> up while the control words go on to some kind of control FSM that will
> take care of all those commands based on timestamp.
> 
> The packets going from the USRP to the host will be created within the
> FPGA and send on out through the m-block FIFO that the FX2 will read.
> 
> Again - I am not sure if this is how it is supposed to be, but this is
> how I have read it thus far.

So the usb packets will be decoded/encoded in the fpga itself. The tx
fifo would store 512 bytes of usb data and then parse it, send the
samples and execute the command right? This could be a first thing to
work on.
> 
>> 2) The FX2 and the fpga communicate using the serial bus (SDI/SDO) (plus
>> some control signal like usb_ctl, usb_rdy) and the usb_data bus. Will
>> the commands be sent trough the serial bus or through the usb_data bus ?
> 
> I suppose I answered this a bit up above.
> 
>> What is exactly the daughter board role and its responsibilities ? Is it
>> only a physical interface for the antenna ?
> 
> For the most part, it's our link to the outside world.  When doing a
> frequency hopping scheme or a TDMA scheme, you have to transmit at
> extremely specific times, or change frequencies very quickly and
> accurately.  To do this, you need tight control over the PLL,
> synthesizer, mixer, any tuners, etc that will govern how and where
> your signal shows up in the spectrum.  The role of the daugherboard is
> really to make sure the signal gets out as cleanly as possible.
> 
>> I also a few question about the format itself:
>>
>> I don't understand the purpose of the Tag field. Can you explain it a
>> little bit ?
> 
> I think this is just a specific identifier for future use.  I am not
> exactly certain myself.
> 
>> I don't understand how the timestamps will work on OUT packets: How the
>> host will know what the value of the 32 bits counter incremented by the
>> A/D sample clock ? Is the timestamps the absolute value of the clock or
>> a delta?
> 
> Usually a TDMA sequence will do a search first to try to get a lock on
> a signal.  Once that happens, it's synchronized to the system.  It
> will probably search for a signal, and once a signal is detected -
> reset the free-running counter in the FPGA to be aligned with the
> start of the TDMA epoch.
> 
>> SPI is used to write to the AD9862 register but what is I2C ?
> 
> SPI is basically the same thing with a different physical interface.
> SPI uses 3 wires where I2C uses 2, if I am not mistaken.
> 
> Currently, the SPI bus is used to write to both the FPGA and the
> AD9862.  Since the FPGA will be writing to the SPI, the in-band
> signaling code should only have to write to the AD9862.
> 
> The I2C bus is used to control the daugherboard.  I believe the USRP
> does not have a connection to the I2C bus right now, and will possibly
> require a modification of the board to connect it up.
> 
> If I have screwed up, I am sorry and please, someone correct me.
> 
> Brian
> 

Thanks for this detailed explanation :)
Thibaud