"Marcus D. Leech" writes:
> Using the scope display, I measured the detector output difference
> between nothing connected (which on the BASIC_RX means that
> the A/D is "seeing" the 50-ohm termination across the input-half of
> the balun transformer), and my -46dBm signal connected.
I see yo
Jeffrey Lambert writes:
> What's up with all the LinkedIN Requests?!
linkedin seems to have the same problem as many other services of
letting people upload an address book and mass-invite.
Everyone should forward invitations received on the list to
ab...@linkedin.com, which will cause them to
Doug Geiger writes:
> As far as my understanding goes, there is not a complete
> implementation of the 802.11b-spec MAC. The files you've found are, to
> the best of my knowledge, the only released code out there
> implementing a partial MAC (i.e. it performs some carrier-sensing
> functions in
Juan Ramon Gutierrez Agullo writes:
> Hi all,
>
> I want to develop 802.11 a from b. I have the BBN 802.11 b code from
> CGRAN (https://www.cgran.org/wiki/BBN80211) but it comes without doxygen
> documentation or something else.
> I'm unable to identify MAC/PHY layer and the flow graphs (for T
I'm writing a report on gnu radio and I had a question... I believe
most everyone uses Ubuntu compared to other Linux systems for GNU
radios why is this? Is it simply because Ubuntu is easier/more
user friendly or does it have to do with the way Ubuntu works?
You should also realize t
From my side I decided to spend some more time in understanding why
the bbn_802.11_tx.py doesn't work when trying to receive with real
802.11 chipsets in monitor mode (modified to disable the mac CRC
check).
I am now fuzzy on the details, but I think the basic problem is that the
USRP doe
Several months ago I installed bbn 802.11 code and got it running. but today
when I wanted to download it in my new PC (according to what I've done
before http://gnuradio.org/trac/wiki/OtherCode)
cvs -d anon...@acert.ir.bbn.com:/cvs/adroitgrdevel co adroitgrdevel
the problem is
cvs
2) Why doesn't gnu radio team include BBN 802.11 code in their office
release, just same as what they have done to the m-block codes? Then these
codes would be better maintained and utilized.
The BBN code has copyright assigned to FSF, so it's just a question of
somebody doing the integrati
Eric Blossom <[EMAIL PROTECTED]> writes:
> On Mon, Nov 03, 2008 at 03:46:56PM -0500, Ed Criscuolo wrote:
>> The tun/tap pseudo device is implemented very differently
>> on OSX vs LINUX, UNIX, et al.
>
> OK.
>
> Take a look at how we handle the "Fast USB" technique selection.
> See config/usrp_fus
Eric Blossom <[EMAIL PROTECTED]> writes:
> Let me try that without adding anything else:
>
> All code in the gnuradio.org svn repository shall be GPL and
> assigned to FSF.
Just to stir the pot: it's the copyright holder that chooses the
license. So it's really
(Note that the GNU Radio
[Discussion about gr-ucla's BSD license and GPLv3 compatibility.]
http://www.gnu.org/licenses/gpl-3.0.html
http://www.softwarefreedom.org/resources/2008/compliance-guide.html
I have looked at these.
UCLA has placed code under a 3-clause BSD licenes. As far as I
understand, that's a "GPL
For me, I don't think this is a problem - as I've just recently
submitted my assignment for patches to gnuradio. So as long as the BBN
code is considered part of gnuradio - it should fall under that (as
far as I understand my assignment statement). Either way, if the code
gets hosted so
I request that anybody that has questions or comments about any of
this first take the time to read the text of the GPL and the
compliance guide before posting (links at the top). It'll save us all
a lot of time.
Fair enough, but two observations:
my memory is that GNU Radio switching
George Nychis <[EMAIL PROTECTED]> writes:
> George Nychis 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 t
I'll be adding the GNU Scientific Library (GSL) as a new dependency
on the trunk. GSL is a huge numerical library that's been under
active development for more than 10 years:
http://www.gnu.org/software/gsl
FYI this is in pkgsrc as math/gsl and it's at 1.11.
pgp7l7KkpdYAx.pgp
Descr
BTW, what does that guy mean "Not sure when you updated, but we have changed
the checked in code to default to 2437, and run it like this (as a NetBSD
rc.d start script)", following the above link?
details if you care, but surely they have little to do with your issues.
http://www.netbsd.
BTW, what does that guy mean "Not sure when you updated, but we have changed
the checked in code to default to 2437, and run it like this (as a NetBSD
rc.d start script)", following the above link?
It means there is somewhere checked in a script that fits into the
NetBSD rc.d framework so th
"Jeff Brower" <[EMAIL PROTECTED]> writes:
> Joel-
>
> Your question doesn't make sense to me. If your clients pay you to
> develop source code that derives from, or partially incorporates, GPL
> licensed code then they own the developed source, not you. They are
> responsible for license issues
First, you seem to be in need of actual legal advice from someone
qualified and licensed to provide it.
Your question has a serious misconception, that code has a single
license. The GPL cannot require that other code be under the GPL; it
can only prohibit distribution of a derived work unless so
We've had similar issues. Please see our 802.11 receiver implementation:
http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver
Indeed - you should definitely try the others. Ours sort of works, and
has a c ool hack to fit within USRP USB bus bandwidth, but I expect
implementatio
Looking at the archives, I understand that I can receive 1 Mbps
probe/beacon packets with code developed by BBN. I use their code and
see packets at 1 Mbps from different nodes.
However, I don't know of a way to have the USRP as a destination for a
flow using standard packet generation to
"Pu, Di" <[EMAIL PROTECTED]> writes:
> I am trying to figure out the Matlab interface to USRP. Although I
> could enable the communications between Matlab and GNU Radio, I am
> wondering whether it is possible to make Matlab hook to USRP directly
> without GNU radio. Thank you very much!
(This is
Dev Ramudit <[EMAIL PROTECTED]> writes:
>> I wonder if you could make this work with octave. MATLAB is decidedly
>> non-Free, and thus I'd expect that any support to interoperate with
>> MATLAB probably wouldn't be eligble for integration into the tree.
>>
>> How do you link this in such a way th
I've been working with a colleague who works mostly in MATLAB
to prototype and test the work we're doing, so I've written a block
that uses the MATLAB engine interface to execute MATLAB code as part
of a flowgraph. It's based on the howto-write-a-block example, and can
be built and
My take is that after we have some content, and it becomes too much to
be listed on the front page, then it will make sense to have more
organized intro pages.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/list
In gnuradio-core/src/lib/general/random.h, RNADOM_MAX is defined
unconditionally:
Recently NetBSD-current has added RANDOM_MAX, for essentially the same
reason, to parallel with RAND_MAX. (random(3)'s definition is 0 to
2**31-1, so this shouldn't be different).
So, is it ok to commit this patc
"Johnathan Corgan" <[EMAIL PROTECTED]> writes:
> On 3/15/08, Greg Troxel <[EMAIL PROTECTED]> wrote:
>
>> See README.components for how to deal with this. This splits all of the
>> pieces of GNU Radio into independent builds. It probably does not make
The svn comment is harmless; it's a side effect of using a tarball
instead of an svn checked out source tree.
Why does configure look for svn at all?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/
BTW: Which package does provide libgromnithread?
See README.components for how to deal with this. This splits all of the
pieces of GNU Radio into independent builds. It probably does not make
sense to have one pkgsrc package per component, and probably
"gnuradio-core" should have a bunch of co
Has there been any successes regarding WiFi implementation with higher
bandwidths (upto 20MHz)?...
(Your email was not line-wrapped and I fixed it.)
The BBN 802.11 implementation received 1 Mb/s fairly reliably and 2 Mb/s
spottily. I don't think we ever got 11 Mb/s working. A 20 MHz signal
GNU Radio builds fine on NetBSD, and only minor fixes were needed to get
it to that point. So it shouldn't be that hard to make it work on
OpenBSD. I realize you are probably using OpenBSD ports and not pkgsrc,
but there is a pkg_chk.conf file in the root directory of gnuradio that
lists what is
Thanks for catching the typo - committed and a new README.components
build started.
-D on NetBSD is about stripping DESTDIR from pathnames logged to METALOG
for unpriveleged installs - and it takes an argument. The use of
automakes dir/data declaratoin is simpler anyway.
I am now able to build
gr-gpio won't install on NetBSD because the Makefile.am uses the -D
option to install, and BSD install doesn't have -D. I tried to find a
man page for the GNU version, but didn't manage to.
The following fixes the problem, and moves this back closer to standard
automake. OK to commit, or am I ov
rereading, I see this:
--with-omnithread Use package omnithread if installed in
$prefix/lib/pkgconfig; otherwise revert back to
--enable-omnithread
--with-gnuradio-coreUse package gnuradio-core if installed in
I'm trying to do a build of all the pieces separately, to mimic what
pkgsrc would do. Here's my script, which seems to build omnithread N
times. I'm a bit tired so may be overlooking something obvious:
The bug seems to be that I'm not specifying where omnithread comes from
during the core build,
DiX <[EMAIL PROTECTED]> writes:
> Mohammad Hamed Firooz wrote:
>> I've tried to use BBN code to transmit 802.11 packets by using RFX2400
>> dautherboard. When I run "bbn_80211b_tx.py" I get the following message:
>>
>> It seems that BBN codes doesnot work with MIMO dautherboards, has
>> anyb
I am using bbn_80211b_rx.py code and I am getting error
No module named bbn_80211b_pkt
I think, I don't have the above mention module.
can some one tell me where I can find this module.
It's in the same directory as the file you mentioned:
acert-netbsd gdt 9 ~/ADROIT-public/adroitgrd
We found that 1 Mb/s reception was fairly reliable and that 2 Mb/s was
not. I would suggest that you log all the bits and then compare them to
the bits as received by a regular receiver and see how far off they are.
The CRC being different just means they are different - it doesn't let
you disting
I think the answer you want is:
cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel
then ./bootstrap && ./configure as you wish from the gr-bbn subdirectory.
Thanks. Snarfed into:
http://gnuradio.org/trac/wiki/OtherCode
___
Discuss
Mohammad Hamed Firooz <[EMAIL PROTECTED]> writes:
> Hi everyone,
> I am going to use BBN code on IEEE802.11b. But these codes need to
> import a module named bbn from gnuradio package. My gnuradio has not
> this module. Where can I find it and how I can add it to my gnuradio
> package.
Several pe
Frank Brickle <[EMAIL PROTECTED]> writes:
>> Given that new versions of python can be installed and made default
>> (meaning invoked as 'python'), it's necessary to bind the scripts to the
>> same version of python used to build .so modules and install .py files
>> in site-packages...
>
> I'm curi
Johnathan Corgan <[EMAIL PROTECTED]> writes:
> Greg Troxel wrote:
>
>> But that will only really work if the version of python found as
>> 'python' is the same one as the version gnuradio found when it was
>> compiled, and the packaging system installs
Removing the '.py' works fine on OSX 10.4.10, so long as the file is
executable (a+x) and has "#!/usr/bin/env python" as the first line to
get the runtime environment correct. - MLD
Agreed.
But that will only really work if the version of python found as
'python' is the same one as the vers
However, a common convention on Linux, at least on Debian, Ubuntu, and
derived systems (probably Redhat too), is to strip the language specific
extension off scripts in the path.
Would anyone have any heartache if we did this for the gr-utils scripts
as well as the relatively few other s
DiX <[EMAIL PROTECTED]> writes:
>With BBN codes and FLEX2400 d'borads, now I can received 802.11b
> packets from standard wireless cards, and communicate between two USRPs with
> barker spreading off. These make me really excited :)
That's good to hear - that matches where we got to.
Perhaps this shouldn't be news, but I have been busy with other things
and haven't tried to build GNU Radio in a long time, so I thought I'd
try it and see if anything needed fixing. I just did a build of the
head of svn on a system that's basically the old 4.0 branch from last
january and it buil
DiX <[EMAIL PROTECTED]> writes:
> Is there anyone using bbn 802.11 codes?
>
> I find the tx path cannot output anything to the usrp board. I connect
> the packet_transmitter to a file sink by adding two lines in
> bbn_80211b_transmit_path.py
> "
> self.fsink=gr.file_sink(gr.sizeof
Many people had implemented some prototypes of 802.11
protocol. For example, BBN
(http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/gr-bbn/src/examples/)
had shared the code of 802.11. However, the BBN's code seem only
focus on physical layer of IEEE 802.11 (coding and modulatio
My quick reaction is that you are having problems from using different
paths from (cross-)building and running. Try making an ARM destdir and
installing everything into it in the same place you will have it when
you run. Lots of programs configure in (via @prefix@ in foo.in) the
prefix,and then l
Also, you almost certainly do not want to put an adaptor on the SMA
connector on the USRP; that will cause too much strain. Instead, use an
SMA to SMA cable and put the adaptor (BNC male to SMA female) on the
scope.
___
Discuss-gnuradio mailing list
Di
Teun <[EMAIL PROTECTED]> writes:
> has anyone tried to capture live 802.11b - 1mbit packets using the 802.11BBN
> source code in SuSE ?
I am pretty sure we did this under some kind of Linux, and I think it
was SuSE.
> I'm trying to do so, but I'm encountering problems. First of all, when I run
>
Is the gr-radio-astronomy patch a FreeBSD fix, or generic?
ppdev.c:
I don't see why the include of sstream is conditional on the various pp
methods.
The diff seems to add code for Linux as well, but I wonder if that's an
artifact of how diff chose to deal with before/after.
Other than that ques
gnuradio/trunk/usrp/host/lib/legacy/usrp_bytesex.h includes byteswap.h,
which appears to be a Linux-specific header file. I looked briefly, and
didn't see any POSIX/SUSv3 definitions of these macros. I just fixed
this to build on NetBSD, which I suspect also fixes it on several other
non-Linux sy
Matt Ettus <[EMAIL PROTECTED]> writes:
> Daniel O'Connor wrote:
>>
>> I think you could use DC-DC converter that outputs 5V.
>>
>> The dropout on the regulator used is 1.5V, and 3.3 + 1.5 = 4.8V. Not
>> a lot of headroom but it should work OK.. Right? :)
>
> Most of the daughterboards regulate th
I'm thinking about requiring GNU make (gmake), instead of trying to
work with whatever make we find.
If we do require gmake, is anybody going to have any heartburn?
I don't think it's that big a deal to require GNU make. There are lots
of dependencies already, and it's likely that some of
I have a problem with insufficent shared memory. I'm running GNU Radio
from SVN, and keep getting these messages:
You didn't mention what operating system you are running, but it could
well be that you are hitting a limit on the number of segments rather
than the total size.
See the end of th
Dan Halperin <[EMAIL PROTECTED]> writes:
> Sorry; I was unclear. Yes, if I put my laptop into 1Mbps mode then I can
> see data packets. Even in 2Mbps mode (especially if I use the -p
> option). I just don't expect there to _be_ any 1Mbps traffic on a modern
> network.
That makes sense. The envir
I think you should see real data packets at 1 Mb/s if there are any. I
would expect multicast in IBSS mode to be like this.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.g
Could you explain more precisely what you are doing, and what happens?
I have run the code under NetBSD with modified tap(4) driver that
handles 802.11 in addition to Ethernet. I am not clear on the state of
802.11 support in the Linux tap driver.
--
Greg Troxel <[EMAIL PROTEC
Eric Blossom <[EMAIL PROTECTED]> writes:
> On Wed, Mar 28, 2007 at 09:39:14PM -0700, Dan Halperin wrote:
>> Same loopback code I emailed about earlier; this time I attached the
>> complete file (modulo some cleanup).
>>
>> Here's my input file (in stupid x86 short ordering..):
>>
>>$ hexdum
ject is part of a PhD thesis at France
> Telecom R&D (French telecommunications company) focusing on integrating
> cognitive mechanisms into radios.
>
> Thank you in advance for your answer (and for the work done with this
> extension, particularly attractive for cognitive ap
"Rohit Gupta" <[EMAIL PROTECTED]> writes:
> What if I use "two" GNURAdio boards at the same time, one for TX and another
> for RX. However, they are now placed very close to each other(say <10cm). Do
> you think this will be a good idea to achieve isolation between TX and RX
> chains??
That will
"Rohit Gupta" <[EMAIL PROTECTED]> writes:
> I have question regarding the full duplex operation of RFX2400 board.
> Looking at the circuit diagram of the board, I understand that each RFX2400
> board has seperate receive AND transmit chain. Hence, if I connect one
> antenna to "RX" port and anoth
It would be good to see benchmarks of the blocks that dominate
receivers on various processors. I think for our 802.11 receiver the
most time went to FIR filters.
You didn't specify if your workload was floating point or integer; I
suspect that the chip with best performance will be different.
+This is preliminary design document on the organization of the host
+component of the USRP inband signaling implementation over USB.
+
+Assumptions: we'll have a single usrp_usb_daemon, implemented as an
+mblock, that will provide the high-level message based interface to
+the USRP. T
looked at the m-block design (discussion in list archives)
and work in progress? I realize it's not ready yet, and that you
might want to do something before it is, but it seems like this is an
ad hoc version of the more general scheme.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpqRu
John Clark <[EMAIL PROTECTED]> writes:
> Greg Troxel schrieb:
>> You left out a lot, like what operating system you are using. But
>> I'll guess that gr_vmcircbuf_createfilemapping is trying to mmap a
>> file in tmp to get shared memory, and it needs to be writabl
I am able to build svn head on NetBSD, including mblock. It seems to
be using the new .la references for pmt and omnithread.
(I have up-to-date auto* and swig and gcc 4.1.2.)
Making all in src
gmake[1]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/mblock/src'
Making all in lib
gmake
ay be that the diagnostics are not quite right. Try
ktrace/truss/etc.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
e number of data streams to/from the USRP, each with
it's own destination on the host. They then could each have
over/underrun flags.
If it's mainly about tx vs rx, or separate data streams, then that's
something that could be muxed on udp port.
This likely requires a lot more tho
Eric Blossom <[EMAIL PROTECTED]> writes:
> On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg Troxel wrote:
>> I'm thinking layer 2 with a unique Ethernet packet type (probably use
>> some abandoned packet type). That said, there's nothing stopping us
>>
ia pause frames.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Eric Blossom <[EMAIL PROTECTED]> writes:
> On Mon, Feb 26, 2007 at 09:13:15PM -0500, Greg Troxel wrote:
>>
>> I wonder how hard it could be to have each component define an
>> autoconf variable
>>
>> LIBS_GR_FOO
>>
>> to be either
>
intended library.
(I can hear you saying to create a trial fix branch with this :-)
--
Greg Troxel <[EMAIL PROTECTED]>
pgpxlhalU74qg.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/m
Do the packages install the .la file? Perhaps some sort of
conditional that uses in-tree for configured component and in-$libdir
for unconfigured components would be the right thing.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gn
build tree and then the installed system at build time, and that then
avoids the build tree when final installation happens is sufficient.
It may be that there is a -lfoo instead of libfoo.la in a Makefile
now.
Greg Troxel <[EMAIL PROTECTED]>
___
Eric Blossom <[EMAIL PROTECTED]> writes:
> The build tree should be linking against the build tree
> (non-installed) libs.
I agree, and pretty clearly it wasn't.
> I understand your goal, but that's not how we're currently doing it.
> If you've got a suggestion (and a patch) to handle this robu
I updated and tried to build the head of svn recently after not having
done so for several weeks. The block code failed to build,
complaining about several pmt_foo functions not being found. I did a
'make -k install' from top level, and then it built fine. So it seems
that the build is linking
"marcus estes" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I am a volunteer with a local non-profit based in Portland, OR that is
> preparing an license application for a full-power station as soon as a
> mysterious 5 day filing window is opened by the FCC later this year.
>
> We are currently inves
Eric Blossom <[EMAIL PROTECTED]> writes:
> On Wed, Jan 31, 2007 at 03:01:51PM -0500, Greg Troxel wrote:
>> I looked into this more, and conclude that there is no evidence for
>> bugs in NetBSD shm support, just perhaps resource defaults that aren't
>> big e
;t know if the test is intended to consume that many resources.
Eric and I have recently beat on the few known NetBSD nits; now make
check passes on NetBSD 4.0_BETA2 with up-to-date packages from pkgsrc
(including jack, port-audio, SDL, py-ephem so most components are
built).
--
Greg Trox
I fixed a memory leak in an error case in the sysv shm vmcircbuf
tests. Now the test leaves no shm turds in either success or error
cases.
I found that I had to set the number of shm segment names and segments
per process to what seem unreasonably high values. This is documented in
http://gnura
Following up to Jonathan's request for tickets, please see
85: memory test fails
133: build failure without "python" in path
134: build failure without exp10
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing
The current subversion build is broken on NetBSD, and probably on
other systems that don't support the non-standard "exp10" function
(posix defines exp and log and log10, but not exp10).
config.h is trying to provide exp10 when it doesn't exist by defining
an inline procedure using pow. This is f
In case anyone's having mail trouble, note that the gnu.org mx is
acting odd, which doesn't give me a warm fuzzy that it won't do
further odd things. Greylisting is one thing, and I can certainly
understand that, but I don't know how they think my NetBSD box running
postfix is windows. I haven't
"Brett L. Trotter" <[EMAIL PROTECTED]> writes:
> I saw the fragments not making it, but by didn't see anything of note, I
> meant I didn't see anything that caused that condition.
You really should have explained what you found; in debugging it's
critical to share all the facts.
>> Could you se
nd is
always dropped? Using TCP may avoid this problem, since it will back
off more aggressively.
It may be that you are finding bugs in your system's fragment
reassembly code.
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mail
there is some
bit pattern that results in them always not arriving, and you can
debug that at the MAC/PHY layer without understanding why the upper
layer is sending that pattern.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing l
Brett Trotter <[EMAIL PROTECTED]> writes:
> Replying to myself, it seems that if I do an ssh and cat a bunch of data
> from /dev/urandom through strings, eventually, the tunnel cant keep up and
> data stops streaming. Funny enough though, if I hit a key, it still sends
> data. It seems as if the
Eric Blossom <[EMAIL PROTECTED]> writes:
> I've just checked code into the trunk that speeds up compilation of
> the swig generated code, as well as reducing the number of
> dependencies for each piece.
I did a make clean, updated, and then rebuilt (autogen, configure,
make) on NetBSD/i386 4.99.1
nuradio import _audio_oss
Traceback (most recent call last):
File "", line 1, in ?
ImportError:
/usr/adroit/lib/python2.4/site-packages/gnuradio/_audio_oss.so:
Undefined PLT symbol "_ZN14gr_basic_block11basic_blockEv" (symnum =
81)
>>>
--
Greg Troxel <[EMAIL
object has no attribute 'max_streams'
swig/python detected a memory leak of type 'gr_io_signature_sptr *', no
destructor found.
python in free(): warning: modified (chunk-) pointer.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
This was recently pointed out to me:
http://www.vtnews.vt.edu/story.php?relyear=2006&itemno=660
I'd be curious if someone from the VT team would like to comment on
the ways SDR code is different from protocol code in terms of
vulnerabilities. I can certainly see the ability to jam at lower
lay
If you have some 1 or 2 Mbps 802.11 devices to use, the BBN guys have done
work on receiving those (search the list, it's been addressed a number of
times in the past).
Yes, and also note that normally an AP will send beacons at 1 Mbps
even if it is a b/g AP.
Comments are welcome on README.
For those of you that don't read the commit logs:
--- Begin Message ---
Author: gdt
Date: 2006-12-04 11:19:59 -0700 (Mon, 04 Dec 2006)
New Revision: 4051
Added:
gnuradio/trunk/README.organization
Log:
Describe issues surrounding integrating BBN's 802.11 code.
Added: gnuradio/trunk/README.o
Thanks, i'll try to look into this.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the
following message:
usb_control_msg failed: error sending control message: Input/output
error
I haven't tracked this down, but I'd be interested in fixing it. I
suspect it's either something missing in NetBSD or some O
fusb_block_size is the size in bytes of the maximum transfer that we
will ask the kernel to make to/from user-space. fusb_nblocks is the
maximum number of transfers (of maximum size fusb_block_size) that we
can have in flight at any given time.
I think this is Linux-specific. The NetSBD
This code is a bit rough and not yet integrated, but you should be
able to get it to run:
cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel
look in gr-bbn/src/bbn, which is quite misnamed but has 802.11 demod
for the 1 Mb/s rate.
___
Disc
patch applied, thanks.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
1 - 100 of 164 matches
Mail list logo
