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 <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
