New server and software at gnuradio.org

GNU Radio
#1

Hi Folks,

I’ve just cut us over to a new server running git and redmine instead
of trac and subversion. The DNS changes could take as long as 1 week
to propagate. In the meanwhile, this link unambiguously gets you to
the new server:

http://vps.gnuradio.org

To get to the trac installation on old server:
(While it lasts. Don’t add any new code or content here)

http://nyquist.gnuradio.org/trac

When all the DNS dust settles, gnuradio.org will point to the new
server.

All development is now taking place using git. All code that was in
subversion (with a few exceptions that we know about) have been in git
for a couple of months. The exceptions that we’re aware of and will
work with the right people to get resolved are:

Eric S.s’s ets/inband developer branch
The OpenBTS subversion code

We’re running “redmine” 0.8.7 on the new server. It serves the same
purposes as trac (wiki, project management, etc, etc), but supports
git as well as some other repo formats. The 0.8.7 version we’re
currently running is missing a few features that trac has. However,
the 0.9 version (which is down to 1 bug left to fix) should give us
everything we need, including the ability to browse git branches.

One thing to note about “redmine”: It is designed to support multiple
projects under a single installation. If you get confused as to where
you are, click on the “Jump to a project” link, and select “GNU Radio”

You can use “cgit” to browse the git repositories:

http://vps.gnuradio.org/cgit

All static content such as the releases, videos, etc has been moved to
the new server and appears in the same location as it had before:

http://vps.gnuradio.org/releases
http://vps.gnuradio.org/video

All of the information in trac, including tickets and wiki
content has been automatically imported into redmine. We haven’t lost
any information, though the conversion of the wiki pages isn’t
perfect. Many of them will need a bit of touch up. You can help
with this by either creating your own account on redmine or using the
guest login with password gnuradio.

To grab the latest GNU Radio development code use either:

$ git clone git://vps.gnuradio.org/gnuradio (fastest way)

or

$ git clone http://vps.gnuradio.org/git/gnuradio.git (works through
more firewalls)

When you want to grab any updates, use

$ git pull

Developers/Committers: more info coming soon on the git workflow, etc.

Eric

#2

Hi,

Thankyou Mr.Eric for your valuable advice.

Yes i studied and completely understood the example that you referred.

I have ,with your advice solved the problem of spatial demux.

Now i want to ask you that now as i have two independent streams of
data, what stategy should i adopt to ensure that the two streams are
transmitted simultaneously via two separate daughterboards mounted on
onse usrp1 which is plugged into a hostpc ?

Shoud i make two separate threads, one for each transmitter??

Each thead would take the physical layer packet (one stream of data) as
an input, and the perform modulation + transmission of data.

Or is there some other way that you can suggest??

Regards,

Nadia Raj

#3

Hi,

From: Eric B. [email protected]

Hi Folks,

I’ve just cut us over to a new server running git and redmine instead
of trac and subversion.

Eric

Thank you for your and Johnathan and Matt efforts to run this project.

The problem (from my point of view) in git is that we lost the meaning
of revision number. In past (with subversion), the gnuradio revision
number can (some how) point to the development process so we know that
some gnuradio developed projects can work without problems with a
specific gnuradio revision number (for example as do some projects in
CGRAN). Even some, revision numbers can be remembered (I remember rev
10165 for example) because there were major changes in gnuradio
project.

Now when I see a gnuradio revision with random hexadecimal number (is it
really random?), I totally miss the days of subversion!!.

Best Regards,

Firas

#4

On Mon, Jan 04, 2010 at 01:54:17AM -0800, Firas A. wrote:

Thank you for your and Johnathan and Matt efforts to run this project.

You’re welcome. For the record, Johnathan gets credit for the bulk of
the work :slight_smile:

The problem (from my point of view) in git is that we lost the
meaning of revision number. In past (with subversion), the gnuradio
revision number can (some how) point to the development process so
we know that some gnuradio developed projects can work without
problems with a specific gnuradio revision number (for example as do
some projects in CGRAN). Even some, revision numbers can be
remembered (I remember rev 10165 for example) because there were
major changes in gnuradio project.

We’ll still tag releases with an x.y.z version number, so all is not
lost.

Now when I see a gnuradio revision with random hexadecimal number
(is it really random?),

It’s actually a portion of the hash of changeset that it refers to.

I totally miss the days of subversion!!.

Git really frees up our ability to branch and merge compared to what
is possible with svn. It’s also an inherently distributed system.
The fact that it’s distributed makes the idea of a central counter of
revision nearly impossible to implement.

To get a handle on what’s going on, clone the repository (if you
haven’t already), then run “qgit” or one of the other git viewers on
it. It will show you all of the branching and merging, diffs, etc.

Best Regards,
Firas

Thanks Firas!
Eric

#5

Hi,
Thankyou for your help Mr.Eric.
I have been able to develop a flowgraph using your advice, however i
have two q’s:

  1. I have used two gr.hier_block2’s, one for each antenna. Now when ill
    create their instances one after the other, so will they execute
    simultaneously??

  2. If i want to send data to side A of usrp and in it TX/RX side whats
    the proper syntax for it.
    Is self.sink=usrp_sink.subdev(0,0) a correct syntax?

I have got two daughter boards on one usrp.

Thankyou in advance.

Regards,
Nadia.

#6

On Mon, Jan 04, 2010 at 06:06:51AM +0000, nadia raj wrote:

Hi,

Thank you Mr.Eric for your valuable advice.

You’re welcome.

Yes i studied and completely understood the example that you referred.

I have ,with your advice solved the problem of spatial demux.

Now i want to ask you that now as i have two independent streams of
data, what stategy should i adopt to ensure that the two streams are
transmitted simultaneously via two separate daughterboards mounted
on onse usrp1 which is plugged into a hostpc ?

Shoud i make two separate threads, one for each transmitter??

Each thead would take the physical layer packet (one stream of data)
as an input, and the perform modulation + transmission of data.

No, use a single flow graph (top_block) that contains both transmitter
paths (probably implemented as hier_block2’s). As long as both paths
produce samples at the same rate, the process of combining them with
the interleaver will ensure that they reach the USRP daughterboards at
the same time.

Eric

#7

Firas A. wrote:

of trac and subversion.
Best Regards,

Firas

Firas,
I’ve heard a lot from both developers and non-developers about the
issues from moving between subversion and git, and I understand the
initial reaction. However, having worked with git over the past few
months, it really does make things simpler and easier to work with other
developers. It’s not like changing your mindset from cvs to subversion.
The way git works is pretty different. However, once you’ve gotten used
to it, I think you’ll start to see the benefits. (almost) All of those
people that I have heard complaints from about the move to git, once
they get over the initial learning curve, have all come to see it as a
good thing.

For reference, I’ve found www.gitready.com to be a very useful resource.

Tom