discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] full daughterboard support added to in-band code & in


From: George Nychis
Subject: [Discuss-gnuradio] full daughterboard support added to in-band code & in-band update
Date: Fri, 16 Jan 2009 13:52:47 -0500
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Hi all,

Thanks to Eric, Jonathan, Tom, and whoever else worked on the C++ daughterboard code, we now have full daughterboard support for the in-band project. I only have BasicTX/RX and RFX2400 which I tested. If anyone wants to test others I would greatly appreciate it.

I have made modifications to usrp_usb_interface in usrp/host/lib/inband for the support, which are now checked in to the trunk.

You can specify a center frequency by adding an rf-freq element in the usrp_dict dictionary in any of the applications, for example to use 2.45G:
  pmt_dict_set(usrp_dict, pmt_intern("rf-freq"), pmt_from_long(2450e6));

It already exists in each of the applications, but is now commented out so that it picks a frequency based on your daughterboard. If no frequency is specified by rf-freq, it picks the frequency at the middle of the frequency range of the daughterboard (default).

Also, we made a ton of additional enhancements to the in-band project for MAC protocol support that we describe in a paper which was recently accepted by NSDI. We will be bug testing these enhancements and pushing them in to CGRAN over the next two months. This will allow you to build fine-grained CSMA and TDMA protocols, but are limited to using GMSK until the in-band project gets some integration with standard GNU Radio blocks.

We are also making changes to the architecture to support a full switch of the MAC layer on the fly. For example, switching from TDMA to CSMA. The first application for this is going to be a 2 channel radio (2 daughterboards), where 1 channel is used for monitoring (e.g., congestion: let's switch MACs) and coordination (e.g., switch to MAC X), while the 2nd channel is a data channel. This still needs a decent amount of work.

- George




reply via email to

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