For using the 3.2 release with the BBN code, you can use my branch on
CGRAN:
https://www.cgran.org/browser/projects/bbn_80211/branches/douggeiger
Thanks Doug. I will try to get it running today on 3.2.
I have no idea if there’s enough room left
on the FPGA to implement that, but if you’re comfortable with Verilog, it’s
worth a shot.
I feel fairly comfortable trying that. As far as space on the FPGA goes,
I remember seeing something in the Mail list archive about
disabling/removing logic for Side B to make room. If possible, it would
work fine in my case as I have two USRP1s with RFX2400 boards, one to
receive, one to transmit. I’ll install QuartusII and start looking more
into it.
Phil Walsh
On Wed, Jun 24, 2009 at 1:44 PM, Phillip W.[email protected]
wrote:
I feel fairly comfortable trying that. As far as space on the FPGA goes, I remember seeing something in the Mail list archive about disabling/removing logic for Side B to make room. If possible, it would work fine in my case as I have two USRP1s with RFX2400 boards, one to receive, one to transmit. I’ll install QuartusII and start looking more into it.
Setting the CIC filter to a constant value instead of being variable
will also help out since you get rid of a lot of the massive muxing
going on.
Brian
One other change I made in that branch, that other people may be
interested
in: I now build a C+±only accessible library, so people building
gnuradio
apps just in C++ can access the BBN blocks. I’ve followed the gnuradio
naming convention and call it libgnuradio-bbn. I think that it’s
appropriate, but can easily change it should anyone object/suggest
another
name.
And for those working with 802.11b and the USRP2, I now have my version
of
the bbn_80211b_rx.py in there (called bbn_80211b_rx_usrp.py). I believe
it’s
similar to the one Colby has in the usrp2_version branch, and I don’t
think
mine had any additional features, but it’s there in case anyone wants to
take a look.
Doug