Hello,
Has anyone updated the BBN 80211 code to work with the current trunk? I
would like to use the BBN code in conjunction with the XCVR2450
daughterboard, which doesnt seem to be supported in the last stable
release.
If nobody has modified the code BBN code, how difficult would it be? Is
there any documentation regarding updating old code for use with the
trunk?
Regards,
Dustin M.
Dustin wrote:
The latest trunk doesn’t include hier_block; instead, it uses
hier_block2 exclusively. This causes errors with BBN 80211b. I believe
there are several other changes as well, but I’m looking for a list.-Dustin
Right - I had forgotten about those changes. I have made my local copy
of the 80211b code work with the hier_block2. I have on my list of
things to do to make sure I can publish these changes so other folks can
make it work with the latest gnuradio code. Sounds like I now have a
good reason to get on top of that task (along with pushing out my local
updates to the multi_usrp code to work with hier_block2 as well).
Doug
I have only some experience with gnuradio…how hard was it to get your
local copy of BBN 80211b to work? Were the only changes in regard to
hier_block2 or were their other namespace changes you had to make?
Thanks for your help,
-Dustin
Dustin wrote:
I have only some experience with gnuradio…how hard was it to get your
local copy of BBN 80211b to work? Were the only changes in regard to
hier_block2 or were their other namespace changes you had to make?Thanks for your help,
-Dustin
For the BBN code I believe the main changes were: first change all the
hier_block to hier_block2, then you have dig a little bit into the
internal flow graph code and figure out what the inputs and outputs are,
as you need to set the io signature
(http://gnuradio.org/trac/wiki/Tutorials/WritePythonApplications helps -
about half way down you can find the instructions on creating a
hierarchical block). The flowgraph code then gets connected a bit
differently, as you connect from self (input) to the internal blocks
back to self (output). Unfortunately I’ve been pretty bad about keeping
track of my changes, so I need to reorganize a bit before I could just
send you a nice patch to apply, but the main changes are in
bbn_80211b.py, bbn_80211b_pkt.py, and either bbn_80211b_rx.py or
bbn_80211b_tap.py (depending on how you want to look at the traffic - or
both). In other words it’s the code in the gr-bbn/src/examples directory
George N. wrote:
out my local updates to the multi_usrp code to work with hier_block2
Thanks!
George
Working on it - I made a whole bunch of changes, and I need to find
which ones were just to get it working with the hier_block2, and which
were my messing around with things. If you don’t hear from me by the
end of the week feel free to bug me again!
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
On Sep 22, 2008, at 2:03 PM, Douglas G. wrote:
Sounds like I now have a good reason to get on top of that task
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
Hello Doug,
Just thought I’d check and see if you had put together a list of
changes for updating the BBN code yet. Even an incomplete list would
be helpful.
Many thanks,
Dustin
Dustin M. wrote:
You’re in luck - I just back back from some traveling, and have managed
to gather up a patch. However - this is a patch to the version from the
U of Utah, SPAN Lab version
(SPAN Lab) -
which does the despreading in the FPGA (which therefore disables that
part of the flowgraph in the python code). So if you want a patch versus
the original BBN code, you’ll need to back those changes out (maybe
doing a reverse patch from the Utah version?). In any event, I’ll have
time in the next few weeks to return to this, if you need help figuring
out what I did (the hier2 conversion wasn’t too complicated).
The unified diff is attached.
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
Douglas G. wrote:
Hi Doug,
Any chance you could push a diff to the list for updating the BBN code
for the newest GNU Radio trunk?
Thanks!
George
Dustin M. wrote:
Apparently when I made that diff I was inside my own svn area, and the
diff had a bunch of extraneous stuff in there. Here’s a cleaned up
version
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
Dustin M. wrote:
(maybe doing a reverse patch from the Utah version?). In any event,
Dustin
Have you tried out my patch yet? I’m just getting back to working on
this again - and unfortunately it seems I left my version in an
unworking state. I’m fairly confident the patch I sent you is not a
working version - but I could be wrong. I have a couple different
versions of my code laying around here, and I’m not sure if I still have
one that works now. So I will likely be repeating some of my work from
this summer, figuring out exactly how I got the hier_block2 and BBN code
to work nice with each other.
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
Dustin
Have you tried out my patch yet? I’m just getting back to working on
this
again - and unfortunately it seems I left my version in an unworking state.
I’m fairly confident the patch I sent you is not a working version - but I
could be wrong. I have a couple different versions of my code laying around
here, and I’m not sure if I still have one that works now. So I will likely
be repeating some of my work from this summer, figuring out exactly how I
got the hier_block2 and BBN code to work nice with each other.Doug
Hello Doug,
Sorry it took me some time to get back to you. I somehow missed this
last
post. You are correct…the patch did not work. I assumed you had made
other changes to the UofUtah code for your own purposes before creating
the
patch, so I have been working on making my own patch. I am currently
getting a “cannot coerce endpoint” error, so I must be building the
flowgraph incorrectly, but I will continue to work on it. When I am
successful, I will post my patch. If you come up with a working patch
before you hear from me, let me know.
Best regards,
Dustin
Hi all,
I have gotten permission to upload the SPAN 802.11b full-bandwidth
receiver code to CGRAN:
https://www.cgran.org/wiki/SPAN80211b
This gives us a central repository where we can all edit/maintain the
code so that it runs with current version of GNU Radio. If you make
changes to the SPAN code, could you register an account on CGRAN and
update it in the repository? That way people always have access to the
newest version of the code.
I think you’re also making BBN 802.11 code changes to make it run with
the current trunk. I haven’t gotten permission to add the BBN code to
CGRAN yet, but if so it would be great if we could keep it up to date
there also.
Thanks!
George
On Tue, Oct 14, 2008 at 10:08:52PM -0400, George N. wrote:
newest version of the code.
I think you’re also making BBN 802.11 code changes to make it run with
the current trunk. I haven’t gotten permission to add the BBN code to
CGRAN yet, but if so it would be great if we could keep it up to date
there also.
George, I’ve got permission to add the BBN code to the main GR
repository. Perhaps we should just add it there.
Eric
Eric B. wrote:
George, I’ve got permission to add the BBN code to the main GR
repository. Perhaps we should just add it there.
Since it’s under the GPL I don’t think permission is really needed
(ability to redistribute), it was kind of a courtesy thing 
I’m OK
with this if 1) I’m not adding it, and 2) I’m not maintaining it. If
somebody else wants to, go for it. I offered to put it in CGRAN since
it doesn’t require more than an hour of my time to upload the code and
create the project page. Then, others can apply patches they’ve been
working on 
George N. wrote:
somebody else wants to, go for it. I offered to put it in CGRAN since
it doesn’t require more than an hour of my time to upload the code and
create the project page. Then, others can apply patches they’ve been
working on
Another alternative is it residing in CGRAN for Doug and Dustin to
update it to work with the current trunk, and once complete it can be
integrated in to the main GR repo by you or whoever.
George N. wrote:
Another alternative is it residing in CGRAN for Doug and Dustin to
update it to work with the current trunk, and once complete it can be
integrated in to the main GR repo by you or whoever.
Side note, how does this work with FSF copyright? If someone develops
something outside of the GR repo, and then you want to integrate it. Do
you need an FSF copyright from them to pull in their code that is
already under GPLv3?
On Sep 27, 2008, at 12:10 PM, Douglas G. wrote:
wasn’t too complicated).
The unified diff is attached.
Doug
Thanks a lot Doug, I really appreciate it. This is perfect, because
we are actually using the UofU version.
Dustin
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Wed, Oct 15, 2008 at 9:11 AM, Greg T. [email protected] wrote:
So I think the top-level question is whether CGRAN is for code that
isn’t assigned. I think that’s the only thing that makes sense; people
with assignments can more or less work directly in the gnuradio.org
repository.
Maybe there are some overlapping issues here.
Suppose, for example, I have some code that’s more
Cognitive-Radio-related
than Software-Defined-Radio, really. It uses Orange <
http://www.ailab.si/orange>, which is GPL but not assigned to FSF. At
least
for now it can’t go into the GNU Radio tree. Probably it never will.
It’s also true that this (my) code is experimental and provisional. It’s
nothing more than a steppingstone. (The obvious place to put it would be
a
developer branch, but that’s part of the tree.) Perhaps I doubt whether,
in
its current form, it should go into the tree. But that’s no reason not
to
make it visible and easily accessible, if only as a scaffolding for
later
code destined for the tree.
There is also some quantity of code which is useful and usable right
now,
but which doesn’t currently fit well with the unified installation
procedure
for the GR tree. I’m thinking here primarily of Linux audio subsystem
code
that uses scons.
It seems obvious there has to be a place for GNU Radio code that’s GPL
but
will not be assigned to FSF, with certainty. I believe there should also
be
a place for code whose status is uncertain – in short, a place with
minimal obstacles to publishing early and often.
Frank
Douglas G. wrote:
inclusion into the mainline gnuradio repository.
Thanks for the responses Greg and Doug. The issue I am trying to
address with CGRAN is the fact that a significant amount of code never
makes it in to the GR repo, because the GR powers to be don’t want it
there or the authors don’t have the time to go through the loops, and
the code gets lost. Additionally, not everyone cares enough to get an
FSF assignment and actually spend the time actually trying to contribute
it into the GR repo.
It seems as though the BBN code is a special case. It already has an
FSF copyright assignment, its mature, and Eric wants it in the
repository. This is not the case with the majority of GR projects,
which CGRAN is meant to cater.
So… I don’t see it as much of a tug and pull between the two
repositories, more as a special case.
As Frank mentioned, he has not-so-mature code which can be useful to
others, but not primetime for the GR repo. It’s a good example of
something that would go to CGRAN.
In direct reponse to Greg, I think CGRAN is more than just for people
who aren’t FSF assignment. Some people don’t want to go through the
hassle of following the GR conventions, writing the QA code, cleaning up
the code, and actually trying to integrate it. A lot of students work
on GNU Radio, and we work towards a deadline and our goal is typically
to get it to work as fast as possible, not as fast and as clean as
possible. Once that deadline hits, we’re typically done 
CGRAN is a
good place for this code and if someone wants to fix it up for the repo,
someone has to get assignments and it goes in. Without CGRAN, the code
is probably going to be lost in between, in a dead SVN repo or the
author has no place to put it.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs