ned the pybombs
git repo. That is where you should find the setup_env.sh script.
- Greg
On Sat, Apr 11, 2015 at 2:16 PM, Keyur Parikh wrote:
> Hello,
>
> I'm trying to get GNU Radio installed on a Zedboard and decided to give
> pybombs a shot. It's a take on Ubuntu 12.04 c
50 in test_usrp_standard_tx
and recompile, the tx. transfer rate jumps to 32meg/sec.
Line 250 was printf("tx_underrun\n"); now is //printf("tx_underrun\n");
I hope this helps,
Greg Spanel
___
Discuss-gnuradio mailing list
Disc
amp;num=2
to get this if the url gets mangled, google('shm_open netbsd'), and
look at first google groups hit.
I'm just starting to get up to speed on the codebase; I'll try to look
at this soon.
--
Greg Troxel <[EMAIL PROTECTED]>
_
continue
d_option = cvs_d_option[repository]['anon']
-login_required = re.match (':pserver:', d_option)
+login_required = 0 and re.match (':pserver:', d_option)
if login_required:
sys.stderr.write
: 64 9 42 288 0xbfbfd340 4 1000
usb_control_msg: 64 9 26 288 0xbfbfd340 4 1000
usb_control_msg: 64 9 8 544 0xbfbfdad3 1 1000
usb_control_msg: 64 9 20 544 0xbfbfdad3 1 1000
usb_control_msg: 64 9 8 1056 0xbfbfdac3 1 1000
usb_control_msg: 64 9 20 1056 0xbfbfdac3 1 1000
usb_control_msg: 64 9 3 288 0xbfb
I do
hear quieting.
I have the EHCI spec on my reading pile...
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Berndt Josef Wulf <[EMAIL PROTECTED]> writes:
> I noticed a problem when building GNU Radio on x86_64 platforms. GNU
> Radio for some reasons insists to install them into ${prefix}/lib64
> where as pkgsrc expects them in ${prefix}/lib.
>
>
> # GR_X86_64()
> #
> # Checks to see if we're on a x86_
Larry Doolittle <[EMAIL PROTECTED]> writes:
> On Mon, Dec 19, 2005 at 09:16:10AM -0500, Greg Troxel wrote:
>
> > - if test "$host_cpu" = "x86_64"; then
> > + if test "$host_os" = "Linux" -a "$host_cpu" = "x86_64&
Eric Blossom <[EMAIL PROTECTED]> writes:
> On Fri, Dec 16, 2005 at 03:59:39PM -0500, Greg Troxel wrote:
>
> > 1) buildit assumes that everything is in /usr, or perhaps that
> >everything is in the compiler's default paths.
>
> Yes. ./configure --help s
ent
levels on other systems (e.g. sparc64).
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
ndle data between
calls to work() and/or something in the butterfly setup? If so,
suggestions on debugging?
- Something else blatantly obvious that I've overlooked?
Thanks,
Greg
greg_fec_decoder_test.grc
Description: Binary data
___
Discu
repo that would correspond to the latest available images file, or how
to compile the correct image?
Possibly the default image now contains the RFNoC content?
Please advise. Thanks.
Greg Rendon
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
the device, but still
uhd_find_devices can't locate it.
I have the B210 plugged into a Via VL800 USB 3.0 card. lspci identifies it as
Device 3483 (rev 01).
What step am i missing?
Thanks,
Greg
___
Discuss-gnuradio mailing list
Discuss-gnu
I added the Ettus repo and installed 003.007.001 and yet when I run the
uhd_find_devices command it shows the 003.005.003 version.
Do you recommend building from source?
Thanks,
Greg
On May 5, 2014, at 10:58 AM, Marcus D. Leech wrote:
> On 05/05/2014 01:52 PM, Greg Hulands wrote:
>>
deleted it
and then reinstalled and it now finds the device and loads the firmware.
Thanks for the help,
Greg
On May 5, 2014, at 11:26 AM, Marcus Müller wrote:
> You seem to have an old, residual version installed. Can you search for
> packets that start with uhd and verify you've only
gnu radio and sdr so I’m not yet sure how to dig in to debug these
issues.
Anything help is greatly appreciated.
Thanks,
Greg
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio
It just looks like noise.
On May 5, 2014, at 4:59 PM, Marcus D. Leech wrote:
> On 05/05/2014 07:52 PM, Greg Hulands wrote:
>> Hi,
>> I built all the code today using the build-gnuradio script and when I create
>> a simple GRC flow graph going from the USRP source to
I changed antenna’s and I see a signal now in uhd_fft. I just noticed that when
in GRC and I run the flow graph, i don’t see the RX light come on the board
like when running uhd_fft.
I have put the grc file up here http://test.utr-software.com/sdr/test.grc
Thanks,
Greg
On May 5, 2014, at 5:03
7MHz? Do you have an antenna
> plugged in to the correct port on the device?
>
>
>> On May 5, 2014, at 4:59 PM, Marcus D. Leech wrote:
>>
>>> On 05/05/2014 07:52 PM, Greg Hulands wrote:
>>>> Hi,
>>>> I built all the code today using the bui
gt;> board like when running uhd_fft.
>>
>> I have put the grc file up here http://test.utr-software.com/sdr/test.grc
>>
>> Thanks,
>> Greg
>>
> The default antenna port if you don't specify one is always TX/RX -- because
> you might be wanting
Still no go. :-(
I have also added device adde = name,serial=F4,type=b200,uhd and Mb0:
Subdev Spec = A:A A:B
both still having no effect.
Thanks,
Greg
On May 5, 2014, at 5:58 PM, Marcus D. Leech wrote:
>> I changed to RX2 and still not activating the receiver on the board.
>
I just worked it out - the run parameter in the Options block was set to Off
instead of autostart. Doh.
Thanks so much for your help. I really appreciate it.
Cheers,
Greg
On May 5, 2014, at 6:17 PM, Marcus D. Leech wrote:
> On 05/05/2014 09:11 PM, Greg Hulands wrote:
>> St
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
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
"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
particular corner of the communications market.
Please reply or sign up for an interview timeslot at
https://calendly.com/warnesg/20-minute-communications-industry-interview
Thanks for your help!
-Greg
Gregory R. Warnes, Ph.D.
g...@warnes.net
Eternity is a long time, take a friend!
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
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
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
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
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
lphas.
Probably the best bet is to have an autoconf test for , and
include and use those types to define gr_foo if it is present, and if
not have OS-specific workarounds. stdint is C99, so it's unlikely
that any system that can build all of GNU Radio's dependencies won't
have it
GPL
rather than the BSD/X11-like Click license. More importantly, it
avoids difficult and hard to maintain cross-project software
dependencies.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnura
802.11 demodulation is entirely welcome, and I too
would like to see your code.
The server runs cvs and svn, mail, bugtracker etc. under savane on
NetBSD, and has RAID-1 storage and tape backups. Please feel free to
email me if you have any issues using the
s down low that it's a more interesting problem,
at least to me.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
ads/adroit/NetBSD-USB-continuous.pdf
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
sync and the read system call is in tsleep. But it's
harder to do that than continuous read mode.
Thanks for pointing out aio, though - I had forgotten about that.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
ust skip the reads? I don't see
what you are trying to find out from this experiment.
> The transfer rate calculated is very fast so the overrun error
> count seems to be a function of the USRP code rather than actual
> overruns.
I don't see how this follows.
--
ly be
part of setting the read buffer size. For write, one also needs to
set the write transaction size, and limit the amount of buffered write
data, so perhaps a symmetric ioctl would be good; this would allow
different read and write sizes, and totally decouple reading and
writing.
--
G
re goofy examples, but it's nice
that the base system is cross buildable and it's occasionally annoying
that packages aren't. Building for ppc or sparc64 on i386 is a less
goofy example.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpSNtPvGgHAB.pgp
Description: PGP signature
_
different results, but I would
expect a big improvement.
--
Greg Troxel <[EMAIL PROTECTED]>
pgp5Kb7n2xypv.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
E.g.:
/usr/pkg/lib/python2.4/site-packages/_curses.so: ELF 32-bit LSB shared object,
Intel 80386, version 1 (SYSV), for NetBSD 3.0, not stripped
2) Presumably the point of lib64 is that programs/libraries compiled
for 32 bits can be installed to lib. So someone should be able to
install
tting pipelining closer to the hardware is
needed - this is being pushed upstream since it works and gets ~80% of
the likely speed gain.
From: Greg Troxel <[EMAIL PROTECTED]>
Subject: CVS commit: src
To: [EMAIL PROTECTED]
Date: Mon, 24 Jul 2006 14:24:50 + (UTC)
Reply-To: [EMAIL PROTECTED]
he 32 MB/s speed is really 16 MB/s
in each direction.
It would be cool if benchmark_usrp.py tried decimation 14, 12, and 10
also, rather than stopping at 16 (and interpolation values with those
rates).
--
Greg Troxel <[EMAIL PROTECTED]>
pgpTx5LBjnVgP.pgp
Descriptio
else
the makefile would have been fixed long ago). This can probably be
figured out quickly with logs of failures when building with -j2 or
-j4.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpcXKIB81LJC.pgp
Description: PGP signature
___
Discuss-gnuradi
f the named targets, except where recur-
sive interpretation of the ordering would cause a cycle in the
ordering graph.
I couldn't figure out the GNU make syntax to do this.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpSgJN84mluE.pgp
Descriptio
. (Of course, the dependencies are
recorded so they will be satisfied.) From that point of view, it
would be nice to be able to enable and disable components and cause
configure to fail if the dependencies are not satisfied. The default
behavior if not given --enable-foo can of course be
build-
it's ok to insist that a depending
component be either
already installed where it belongs
or
built in this build tree.
I'm not sure about other systems, or if this is hard.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpIOKgCI4psa.pgp
Description: PGP signature
"Johnathan Corgan" <[EMAIL PROTECTED]> writes:
> On Thu, August 10, 2006 11:52, Greg Troxel wrote:
>
>> What I really want is an easy way to build each component by
>> downloading some tarball (can be same for all) and doing some sort of
>> ./configu
try a different debug format
/var/tmp//ccWtqH2F.s:4425: Warning: .stabs: description field '1edbf' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4426: Warning: .stabs: description field '1edbf' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4430: Warning: .stabn: description field '1edbf' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4437: Warning: .stabn: description field '1edc1' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4449: Warning: .stabs: description field '1edc2' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4450: Warning: .stabs: description field '1edc2' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4454: Warning: .stabn: description field '1edc2' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4461: Warning: .stabn: description field '1edc4' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4473: Warning: .stabs: description field '1edc5' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4474: Warning: .stabs: description field '1edc5' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4478: Warning: .stabn: description field '1edc5' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4485: Warning: .stabn: description field '1edc7' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4497: Warning: .stabs: description field '1edc8' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4498: Warning: .stabs: description field '1edc8' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4502: Warning: .stabn: description field '1edc8' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4509: Warning: .stabn: description field '1edca' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4521: Warning: .stabs: description field '1edcb' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4522: Warning: .stabs: description field '1edcb' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4526: Warning: .stabn: description field '1edcb' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4533: Warning: .stabn: description field '1edcd' too big,
try a different debug format
/var/tmp//ccWtqH2F.s:4545: Warning: .stabs: description field '1edce' too big,
try a different debug format
--
Greg Troxel <[EMAIL PROTECTED]>
pgpeZLUeyoWmS.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
2 20060628 prerelease (NetBSD nb2 20060711)
--
Greg Troxel <[EMAIL PROTECTED]>
pgpKcDs8Q1Ih9.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
ct*, Type**) [with Type
= std::vector,
std::allocator > >]'
ecc.cc:5137: instantiated from here
ecc.cc:3208: warning: dereferencing type-punned pointer will break
strict-aliasing rules
gmake[2]: *** [ecc.lo] Error 1
gmake[2]: Leaving directory
`/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib'
gmake: *** [all] Error 2
--
Greg Troxel <[EMAIL PROTECTED]>
pgpgMkpSgMyES.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
sr/pkg/bin/swig -c++ -fvirtual -python -modern
-I../../../gnuradio-core/src/lib/runtime
-I../../../gnuradio-core/src/lib/general
-I../../../gnuradio-core/src/lib/general
-I../../../gnuradio-core/src/lib/filter
-I../../../gnuradio-core/src/lib/filter
-I../../../gnuradio-core/src/lib/reed-solomon
-I../../../gnuradio-core/src/lib/io -I../../../gnuradio-core/src/lib/g72x
-I../../../gnuradio-core/src/lib/omnithread
-I../../../gnuradio-core/src/lib/swig -I../../../gnuradio-core/src/lib/swig
-I/usr/pkg/include -module trellis -o trellis.cc
Must specify an input file. Use -help for available options.
*** Error code 1 (continuing)
`all' not remade because of errors.
Making all in python
--
Greg Troxel <[EMAIL PROTECTED]>
pgpezFbG0LyFl.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
full_block.h:57: error: in passing argument 5 of
'ecc_metrics_decode_viterbi_full_block_feedback_sptr
ecc_make_metrics_decode_viterbi_full_block_feedback(int, int, int, int,
std::vector >&, std::vector
>&, bool, int, int)'
There is one potential issue with BSD make that Greg Troxel
the make rule isn't at all generic, I don't see the point in
using $< at all.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpSCsfr2fJ3A.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
$(DEFINES) -c $< -o $@
%.rel : %.a51
$(XAS) $<
I put a diff into trac to use old-fashioned suffix rules, which seem
powerful enough to express how to build a .rel from a .c.
http://gnuradio.utah.edu/trac/ticket/35
--
Greg Troxel <[EMAIL PROTECTED]>
pgphSlDWu8Elx.pgp
D
I've added a patch that lets me compile the components that configure
enabled.
http://gnuradio.utah.edu/trac/attachment/ticket/35/bsdmake.patch
--
Greg Troxel <[EMAIL PROTECTED]>
pgpkIYSlasbFG.pgp
Description: PGP signature
a USRP and RFX-2400.
(The plan is to put our fusb and 802.11 code in the main SVN, as soon
as our papers are in order (pending). In the meantime you need to
grab it separately from
https://acert.ir.bbn.com/projects/adroitgrdevel/
).
--
Greg Troxel <[EMAIL PROTECTED]>
pgplfdXpB7lVl
ust insert the explicit template expansions at
> the end of each .cc file. (See, e.g. "gr-ecc/src/lib/libecc/
> code_metrics.cc"). - MLD
That worked (gcc 4.1.2), and with my BSD make patches as well make
check succeeded with BSD make. Thanks for fixing.
--
Greg Troxel
f(stderr, "nsamples_to_skip must be >= 0\n");
@@ -213,7 +213,7 @@
break;
case 'd':
- max_doppler = strtof(optarg, 0);
+ max_doppler = strtod(optarg, 0);
if (max_doppler < 0 || max_doppler >= 0.5){
usage(argv[0]);
fprint
would support the common case of
having most of the prereqs from some packaging system but building GNU
Radio to a different place.
Thanks for all your work on the build system - it seems to be in quite
good shape now.
--
Greg Troxel <[EMAIL PROTECTED]>
pgp3PHVqgyCnR.pgp
Description:
UUID: 221aa14e-8319-0410-a670-987f0aec2ac5
Revision: 3361
Node Kind: directory
Schedule: normal
Last Changed Author: jcorgan
Last Changed Rev: 3357
Last Changed Date: 2006-08-20 13:47:10 -0400 (Sun, 20 Aug 2006)
Properties Last Updated: 2006-08-14 08:40:44 -0400 (Mon, 14 Aug 2006)
--
Greg T
r/pkg and adds it in would be ok too, on systems with /usr/pkg present.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpu35D7FERaH.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
/patch-aj
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
--- End Message ---
--
Greg Troxel <[EMAIL PROTECTED]>
pgpZ0V3rp8Prl.pgp
Description: PGP signature
___
Discuss-gnurad
Rev 2(0x0002), Free
Software Folks(0xfffe), rev 1.02, serial 0000
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
oops. Thanks, and we'll get new converters.
(It would be really cool if you had something that took 11-16V with a
powerpole for sale :-)
--
Greg Troxel <[EMAIL PROTECTED]>
pgpNWPT0F28DY.pgp
Description: PGP signature
___
Discu
BBN's code to receive 1 Mbps 802.11 packets will shortly be eligible
for merging in to the real repository (we've sent a signed assignment
to FSF and are just watiting for a countersignature). In thinking
about where to put it, I realize there's a bit of complexity.
Eventually, many blocks will
This means more people are working in 400MHz, 900MHz and 1800MHz bands. If
yes, then why?
You are jumping to unwarranted conclusions; there's no rule that
production runs are all the same size.
My anecdotal evidence is that the 2400 boards are most popular, but I
don't have a count. I suspec
3 15:36 usrp_prims.h
-rw-r--r-- 1 gdt ir 1101 Oct 3 15:36 usrp_slots.h
-rw-r--r-- 1 gdt ir 19970 Oct 3 15:36 usrp_standard.cc
-rw-r--r-- 1 gdt ir 10825 Oct 3 15:36 usrp_standard.h
--
Greg Troxel <[EMAIL PROTECTED]>
pgplCNx8r5DYK.pgp
Description:
The problem is that fusb_ra_wb.h isn't listed in noinst_HEADERS. I
suppose make distcheck would catch this in svn if run on recent-enough
NetBSD. I'll run that tomorrow.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpi0LhZeghE5.pgp
Descriptio
This has been fixed in r3697 on the SVN trunk and r3698 in the
release-3.0 branch, which will eventually make it into a new 3.0rc2 tarball.
Thanks. I just ran 'make distcheck' on a pretty-recent NetBSD system
with up-to-date svn and ran into only a few problems (the first two of
which aren't
S="-I/usr/pkg/include -I/usr/adroit/include"
./configure --prefix=/usr/adroit $CONF_ARGS
# build
make
;;
# check)
# TMP=/home/tmp
# ;;
install)
sudo make install
;;
esac
--
Greg Troxel <[EMAIL PR
hey didn't pass configuration checks:
gr-audio-alsa
gr-audio-jack
gr-audio-osx
gr-audio-portaudio
gr-audio-windows
These components will not be built.
Greg Troxel <[EMAIL PROTECTED]>
pgp172GsiPqxj.pgp
Description: PGP signature
_
may be that some systems work like he
suggested, with a thread, and others have the kernel do it. I suspect
that the issue of multiple readers can be separated from the
timeliness issues.
--
Greg Troxel <[EMAIL PROTECTED]>
pgpSduX1
.g. send a CTS after only SIFS time
after the RTS.
> BBN has code (for NetBSD) which implements 802.11 receive -- is this a
> separate branch or is it going to be merged with gnuradio release?
The 802.11 receive code is not OS specific. It's been tested on
Linux and NetBSD.
--
GNU Radio 3.0 works fine wtih Python 2.4.
> Tarun Tiwari wrote:
> I found my Python.h file is in /usr/local/include/python2.4 whereas .
> /configure command alwasy look for /usr/linclude/python2.4
> I used export PYTHONPATH=/usr/local/include/python2.4 but that is not
> working. Can so
[moved to correct list]
A radio club in the Boston Area (MMRA.org) would like a presentation
and may be a demo of GNU Radio on November 15 in the evening. Is
there someone that is will and able to do this presentation? Or is
there someone who has put together a presentation that I can u
Will we see a release candidate tarball before the final release? It was the
tarballed version that caused me grieve last time.
Jonathan already said yes and posted it, but you can make your own
tarball with 'make dist' or even better make and test it with 'make
distcheck'. I've made this wo
I am indeed reading the list :-)
desired freq = 243700.0
baseband frequency 243200.0
This looks ok - I think it's trying to grab from above and below
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 s
I cvs updated this afternoon just before trying it. Have you moved to
a different (svn) repository? I'm using
[EMAIL PROTECTED]:/cvs/adroitgrdevel.
That's still where the best code is, and what we're building from.
That said, it may not be quite right -- our team has been doing things
other
generate_all is also executed after a "gmake clean" since it removes
several files that are supplied in the tarball, which need to be
regenerated, causing the same problem.
So if we need generate_all to work anyway, probably the files it makes
shouldn't be in the tarball.
One of the things
As GNU Radio now ships in a mega-tarball, which version numbers are assigned
to the individual modules? Are they pulled inline with the version number of
the release, e.g. gr-audio-oss-3.0.1?
That's the way I'd do it. (version set in Makefil.common, and pull
from that in individual pkg Ma
cope to show ambient - try 2437 MHz.
Your question about a standard test is a good one, though - it would
be nice if people with procedures put them on the wiki.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Disc
not sure about the doc issues, but a bug report is probably in order.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I got a Griffin Powermate for testing, as Berndt reports it isn't
found by the examples on NetBSD. I suspect we need to abstract out
the OS-dependent access and also knob types - this should really be
support of generic usbhidev on all systems. I'll see what it takes;
NetBSD reads it ok:
uhidev0
For those running NetBSD, I've updated the NetBSD Packages Collection to
accommodate the release of GNU Radio 3.0.2. GNU Radio is split into modular
packages, see below, giving users maximum control over the installation
process. Those that are lazy may issue "make install" inside the
We are using the RFX-400 board (without housing) with an appropriate
aerial connected to TX/RX.
I'll assume appropriate means a 1/4 lambda vertical without a real
ground plain. Still, that's ok.
Using various examples (usrp_fft.py,
usrp_wfm_rcv.py and usrp_nbfm_rcv.py) we attempted to r
patch applied, thanks.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
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
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
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
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
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.
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
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
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
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
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
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
1 - 100 of 188 matches
Mail list logo
