On Wed, Jan 31, 2007 at 08:43:22PM +0000, George Nychis wrote: > Eric Blossom wrote: > > On Mon, Jan 29, 2007 at 07:31:43PM -0500, George Nychis wrote: > >> Hey Eric, > >> > >> Is this still on track to finish by the end of the month? > >> > > It's pretty close, but could be a week late. That's for the > > fundamental mblock support. > > > > It'll take longer to get the USRP in-band signaling (and precision > > timing) working. > > > > That's a step forward :) > > So I have a question, and am looking for your opinion. > > [ Project on Detailed MAC ] > I am working with another student on building a more detailed MAC > protocol for packet based applications on the GNU Radio platform and > USRP. We have found two projects which got sort of a stop and wait MAC > working, one of which was done here and the other is here: > http://typo3.cs.uni-paderborn.de/en/research-group/research-group-computer-networks/projects/gsr.html
Good. > We are looking to take these MAC's to the next level and get fine > grained timeouts, exponential backoff, rate adaptation... etc. Great. We need that stuff! > [ Can we Help w/Signaling & Timing ] > As you mentioned, its going to take longer for USRP in-band signaling > and precision timing to be done. How much work is this and what kind of > knowledge does it require? Considering our goal is to build a base MAC > first, with the long term goal of modifying it and making improvements, > we can't get much further without this functionality. Therefore we were > wondering if we should and can help with this? > > Let us know what you think! > > - George Implementing the in-band signaling is going to require substantial changes to the USRP verilog code and the host library. It may require some minor tweaks to the FX2 firmware, but not much. Mostly we're going to be removing functionality from the FX2 firmware. You'll need to understand from a high-level point of view how the existing host, fx2 and fpga code interact. Otherwise it's going to be tough sledding ;) You're almost certainly going to need access to a logic analyzer to debug the new code in the FPGA. The low-level details of getting data across the USB won't change. That is, we'll continue to use the fusb.h interface, and will communicate between the host and FX2 using fixed-length 512 byte USB packets. Likewise, we'll keep the exact same method for bursting packets between the FX2 and FPGA over the GPIF bus. The interpretation of the contents of the packets on the FPGA will be different, but the low level details related to flow control will remain unchanged. I suspect that starting on the host side we'll create a new base class similar to usrp_basic (possibly by refactoring it) that will support the in-band signaling. I think we're going to end up with a new hierarchy of classes on the host, but it would be nice if we can avoid changing the interfaces to the various methods. The implementations will change, but we want to avoid gratuitous interface changes. Since virtually all commands (exceptions: loading firmware into the FX2 using endpoint zero, could be others related to I2C and/or SPI) will be in-band in the TX stream on endpoint 2, and all responses will be in-band in the RX stream on endpoint 6, there may need to be a separate process that handles muxing/demuxing of commands and status from the logical Tx and Rx high-level users to the USB connection to the USRP. That is, we want to retain the ability to have separate (or the same) processes open either or both the logical Tx and Rx paths. If this sounds within your comfort (or stretch) zone, let me know, and Matt and I will spend some time working out a proposed format for the packets across the wire. It's a non-trivial piece of work, but with two of you working on it, it should go pretty quickly, and you'll learn a lot besides ;) FYI, I've taken the liberty of copying the list on this response. This is a good conversation to have in public. There may be collaborators lurking! Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio