Forum: GNU Radio full daughterboard support added to in-band code & in-band update

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ac73d95c8ccddff9ecae369bcb80a923?d=identicon&s=25 George Nychis (Guest)
on 2009-01-16 19:55
(Received via mailing list)
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
A725014f091bcd9e8ff16e9f2a0d7e20?d=identicon&s=25 Stefan Bruens (Guest)
on 2009-01-18 18:11
(Received via mailing list)
On Friday 16 January 2009 19:52:47 George Nychis wrote:
> 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));

Hm, MAX_LONG= (2^31)-1 = 2147 483 648
2450e6 = 2450 000 000 > MAX_LONG

Stefan
Ac73d95c8ccddff9ecae369bcb80a923?d=identicon&s=25 George Nychis (Guest)
on 2009-01-18 18:13
(Received via mailing list)
Stefan Bruens wrote:
>> 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));
>
> Hm, MAX_LONG= (2^31)-1 = 2147 483 648
> 2450e6 = 2450 000 000 > MAX_LONG
>

You're correct, I caught this the other day and already applied a patch
for it.  Thanks for pointing it out too!  It's now pmt_from_real(2450e6)

- George
This topic is locked and can not be replied to.