Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
Philip Balister wrote: > I've been working on getting the usrp working with a USB full speed > interface connected to an OMAP starter kit (OSK) board from TI. I'm > not using GNU Radio, but the OSSIE open source SCA. The OSK only has a > USB 11 controller that sends 64 byte packets, not the 512 byte packets > sent by USB2.0 high speed interfaces. > > The code I have uses the usrp-0.12 package to communicate with the > USRP. This email is mainly of interest to people interested in low > level USRP interfacing and the FPGA to FX2 interface. > > I have a waveform that generates random BPSK that works fine on a PC > with is USB high speed interface. The output is raised cosine pulse > shaped and I monitor it on a Tektronix signal analyzer. When I run the > waveform on a PC with a USB2.0 hidg speed interface I see a good eye > diagram. > > When I compile the code for the OSK, I see two symbols transmitted, > then dead air. Two symbols is 64 bytes (2 symbols x 8 sample/symbol x > 4 bytes/sample), then there are 512 - 64 bytes of no signal. It feels > like the 64 byte packets are read into a buffer of 512 bytes, where > all the un-written bytes are zeros. > > It feels like somewhere in the USB chain, I send the 64 byte packet, > then something reads the 64 bytes and zero pads the packet to 512 > bytes. I suspect the FPGA tries to read 512 bytes from the FX2 chip, > but that is only because this is the area of the code I least > understand :) Philip, If you go to http://gnuradio.utah.edu/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/tx_buffer.v And look at line 94, you will see the test for "end of packet". write_count[8] goes high when we have put 256 elements (512 bytes) into the fifo. You would need to modify this to write_count[5] which will go high when 32 elements (64 bytes) have been put into the fifo. You probably also need to modify some firmware. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any Octave/Matlab folks on the list?
On 11/29/06, Marcus Leech <[EMAIL PROTECTED]> wrote: I have some X,Y,Z data that I want to turn into a gray or colour mapped contour plot. The data aren't necessarily gridded, so I need interpolation. I'm a newbie to Octave/Matlab, and could use a hint. I've played with contourf(), which I can make work for functions, but I need to load external data that is organized as columns of X,Y,Z in ascii. A quick google search revealed a nice and informative page: http://www2.ohlone.edu/people2/bbradshaw/matlab/plotting3dsurfaces.html You can use the load command to get the data into Matlab for manipulation. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Any Octave/Matlab folks on the list?
I have some X,Y,Z data that I want to turn into a gray or colour mapped contour plot. The data aren't necessarily gridded, so I need interpolation. I'm a newbie to Octave/Matlab, and could use a hint. I've played with contourf(), which I can make work for functions, but I need to load external data that is organized as columns of X,Y,Z in ascii. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Some question about flow_graph
On Thu, Nov 30, 2006 at 02:30:08AM +0100, Davide Anastasia wrote: > Some question about the python flow_graph class. > Is it possible to: > 1. derive it? Yes. Virtually every example does this ;) > 2. connect the tail of a graph to the head of another one? Generally you have only a single flow graph. If you had more than one, they would not be connected. > 3. make a 1-to-N connection? If you mean may one output connect to multiple inputs, yes. This is frequently done in the examples. > Thanks, > Davide Anastasia Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FYI: Core 2 Duo CPU SBC
Found this new product very interesting for embedded applications: http://www.commell.com.tw/News/News/News_20061120_LS-371.htm cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Oussama Sekkat's FPGA development document
Eric Blossom wrote: > I found this in less than 30 seconds using the archives at Wow, 30 seconds at lists.gnu.org! We should use that instead of mail-archive.com which doesn't store attachments. Thanks, Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP and USB full speed (1.1) transmit
I've been working on getting the usrp working with a USB full speed interface connected to an OMAP starter kit (OSK) board from TI. I'm not using GNU Radio, but the OSSIE open source SCA. The OSK only has a USB 11 controller that sends 64 byte packets, not the 512 byte packets sent by USB2.0 high speed interfaces. The code I have uses the usrp-0.12 package to communicate with the USRP. This email is mainly of interest to people interested in low level USRP interfacing and the FPGA to FX2 interface. I have a waveform that generates random BPSK that works fine on a PC with is USB high speed interface. The output is raised cosine pulse shaped and I monitor it on a Tektronix signal analyzer. When I run the waveform on a PC with a USB2.0 hidg speed interface I see a good eye diagram. When I compile the code for the OSK, I see two symbols transmitted, then dead air. Two symbols is 64 bytes (2 symbols x 8 sample/symbol x 4 bytes/sample), then there are 512 - 64 bytes of no signal. It feels like the 64 byte packets are read into a buffer of 512 bytes, where all the un-written bytes are zeros. It feels like somewhere in the USB chain, I send the 64 byte packet, then something reads the 64 bytes and zero pads the packet to 512 bytes. I suspect the FPGA tries to read 512 bytes from the FX2 chip, but that is only because this is the area of the code I least understand :) I see that some people on this list (beyond Matt and Eric) are interested in the signal flow from the PC to the ADC/DAC's so I'm hoping someone has some suggestions. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Some question about flow_graph
Some question about the python flow_graph class. Is it possible to: 1. derive it? 2. connect the tail of a graph to the head of another one? 3. make a 1-to-N connection? Thanks, -- Davide Anastasia web: http://www.davideanastasia.com/ email: [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block.How to build?
> From: Jonas Hodel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 29, 2006 1:05 PM
> To: Eric Blossom
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Multiple C files required by single C++
> block.How to build?
>
>
> Hello,
>
> Thanks to both Eric and Daniel for your prompt help.
>
> Yes this does make sense and it was the first thing I tried. After it didn't
> work with my files I went right back to basics (I am building a la
> gr-howto-write-a-block). I created very simple .h/.c files as a test.
>
> Then:
> Within "howto_square2_ff.h" I added #include "test.h".
> Within "howto_square2_ff.cc" I added a call to jonas_test(), located in the
> constructor howto_square2_ff ().
> I added test.c to the "_howto_la_SOURCES" entry in "src/lib/Makefile.am".
>
> Finally: "make clean", "make" and "make check".
>
> This results in:
>
> ImportError:
> /home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
> undefined symbol: _Z10jonas_testv
This is because you included a C .h file into a C++ source file.
The compiler assumed (since you didn't tell it otherwise) that
jonas_test was a C++ function. Thus the name mangling.
The fix is to surround the inclusion of the C include file with:
extern "C" {
#include "jonas_test.h"
}
FWIW, this is standard C++, and has nothing to do with GNU Radio, SWIG
or Python.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb_nblock and fusb_block_size
Hi Eric,
Thank you for the clarifications. I traced the code back to
usrp_basic.cc, but got lost there. I will have a look at
fusb_linux.{h/cc}.
Thomas
On 11/29/06, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Wed, Nov 29, 2006 at 01:46:14PM -0800, Thomas Schmid wrote:
> Hi all,
>
> What do the parameters fusb_nblock and fusb_block_size exactly do in
> how data is transmitted over the USB to the USRP? I assume that
> fusb_nblock indicates how many blocks we have in each USB packet, and
> fusb_block_size indicates how big one block is.
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.
Take a look at fusb_linux.{h,cc} for the details.
> My question is, if there is less data available on the USRP (i.e. not
> fusb_nblock*fusb_block_size), does it still get sent over the USRP to
> the computer?
Yes. The USRP packages data into 512 byte USB packets and sends them
as soon as it can. That's 128 complex samples (16-bit I & Q).
> How is the smallest amount of data necessary in the USRP defined such
> that a packet is sent over the USB to the computer? Is it
> fusb_block_size?
It's 512 bytes. It's set in the FX2 firmware.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb_nblock and fusb_block_size
On Wed, Nov 29, 2006 at 01:46:14PM -0800, Thomas Schmid wrote:
> Hi all,
>
> What do the parameters fusb_nblock and fusb_block_size exactly do in
> how data is transmitted over the USB to the USRP? I assume that
> fusb_nblock indicates how many blocks we have in each USB packet, and
> fusb_block_size indicates how big one block is.
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.
Take a look at fusb_linux.{h,cc} for the details.
> My question is, if there is less data available on the USRP (i.e. not
> fusb_nblock*fusb_block_size), does it still get sent over the USRP to
> the computer?
Yes. The USRP packages data into 512 byte USB packets and sends them
as soon as it can. That's 128 complex samples (16-bit I & Q).
> How is the smallest amount of data necessary in the USRP defined such
> that a packet is sent over the USB to the computer? Is it
> fusb_block_size?
It's 512 bytes. It's set in the FX2 firmware.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block.How to build?
On Thursday 30 November 2006 06:35, Jonas Hodel wrote:
> Then:
> Within “howto_square2_ff.h” I added #include “test.h”.
> Within “howto_square2_ff.cc” I added a call to jonas_test(), located in
> the constructor howto_square2_ff ().
> I added test.c to the “_howto_la_SOURCES” entry in “src/lib/Makefile.am”.
>
> Finally: “make clean”, “make” and “make check”.
>
> This results in:
>
> ImportError:
> /home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
> undefined symbol: _Z10jonas_testv
I think this means that the compiler has generated a reference to a C++
symbol - note the mangling in front.
I think you need to tell the compiler it's dealing with C when you declare the
prototype for your C function.
I believe you do..
extern "C" {
#include "HeaderForMyCFunctions.h"
}
but my C++ fu is weak.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
pgpbeG6vIHuse.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Oussama Sekkat's FPGA development document
On Wed, Nov 29, 2006 at 11:36:56AM -0800, Chris Stankevitz wrote: > Hi, > > I recently found a reference to a document Oussama Sekkat attached to a > message on this board. Neither Oussama's email nor his attachment was > saved in the mail archive. Can someone please send that document to me > or provide a link? Here is a reference to a reply to the email I am > asking about: > > http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg06148.html > > Thank you! > > Chris I believe this may be the message that you are looking for. Oussama's file is attached to the bottom of it. http://lists.gnu.org/archive/html/discuss-gnuradio/2006-11/msg00081.html The attachment: http://lists.gnu.org/archive/html/discuss-gnuradio/2006-11/pdfzO6Ds9K8ui.pdf I found this in less than 30 seconds using the archives at http://lists.gnu.org/archive/html/discuss-gnuradio/ Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++block.Howto build?
Fantastic, works like a charm! I thought the problem was in the way I
was using SWIG but the culprit was the C/C++ linkage. Now I can try it
with my original files.
Thanks for all the help!
Jonas
Jan Schiefer wrote:
Finally: “make clean”, “make” and “make check”.
This results in:
ImportError:
/home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
undefined symbol: _Z10jonas_testv
What you need to do is to surround the declaration of jonas_testv()
with en extern "C" {} declaration. If you don't do this, then the
linker is looking for the "mangled name" , which is C++'s way to embed
type declarations in a function name. If the function is declared in
the .h as extern "C", it will just expect the function name with an
underscore in front of it, just like C does.
Cheers,
Jan
===
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Two Antenna Ports on RFX2400?
L Bao wrote: > Could someone please answer my question? > > There are two antenna ports on the RFX2400 daughter board -- "TX/RX" > and "RX2". I have only one "2400-2480 MHz ISM Band Vertical Antenna". > Will it be OK with the hardware board circuit if I leave the "RX2" > port open with no protector? Yes. Standard usage is TX and RX on one antenna. Optionally, you can use the second port for an alternate receive, but you don't need to. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block.How to build?
Finally: “make clean”, “make” and “make check”.
This results in:
ImportError:
/home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
undefined symbol: _Z10jonas_testv
What you need to do is to surround the declaration of jonas_testv() with
en extern "C" {} declaration. If you don't do this, then the linker is
looking for the "mangled name" , which is C++'s way to embed type
declarations in a function name. If the function is declared in the .h
as extern "C", it will just expect the function name with an underscore
in front of it, just like C does.
Cheers,
Jan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Multiple C files required by single C++ block.How to build?
Hi Jonas,
Here are the steps I use to add a block. I piggyback onto
gnuradio-core/src/lib/general.
NOTE: I'm not saying this is the "right" way, but it works for me.
1) Copy test.cc, test.h, and test.i to gnuradio-core/src/lib/general
2) Edit gnuradio-core/src/lib/general/general.i, and add 2 new "include"
lines (one for test.h and one for test.i)
3) Edit gnuradio-core/src/lib/general/Makefile.am, and add the 3 new file
names in the appropriate place
4) In gnuradio-core, run "make" and "make install"
Hope this helps!
Patrick
_
From: Jonas Hodel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 29, 2006 1:05 PM
To: Eric Blossom
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Multiple C files required by single C++
block.How to build?
Hello,
Thanks to both Eric and Daniel for your prompt help.
Yes this does make sense and it was the first thing I tried. After it didn't
work with my files I went right back to basics (I am building a la
gr-howto-write-a-block). I created very simple .h/.c files as a test.
/*test.h*/
#ifndef __TEST__
#define __TEST__
void jonas_test();
#endif
/*test.c*/
#include "test.h"
#include
void jonas_test()
{
printf("this is a test, proof is in the pudding\n");
}
Then:
Within "howto_square2_ff.h" I added #include "test.h".
Within "howto_square2_ff.cc" I added a call to jonas_test(), located in the
constructor howto_square2_ff ().
I added test.c to the "_howto_la_SOURCES" entry in "src/lib/Makefile.am".
Finally: "make clean", "make" and "make check".
This results in:
ImportError:
/home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
undefined symbol: _Z10jonas_testv
I tired other variations (creating test.i, included in howto.i etc) but I
must be missing something fundamental.
Thanks again for you help!
Eric Blossom wrote:
On Wed, Nov 29, 2006 at 10:39:20AM +1030, Daniel O'Connor wrote:
On Wednesday 29 November 2006 09:26, Jonas Hodel wrote:
I have some existing C-functions which I would like to include in a C+
signal processing block. The complication is that these C-functions are
located in a number of different files. I have created a C++ block which
uses these functions. It appears to build fine but when I come to
include the new block in my python script I get an "undefined symbol"
error referring to one of the low level C-functions (I think). In short,
is it possible to use my existing C-files unchanged (included in my C++
block)? If so what approach is necessary to make this work/build properly?
You need to compile those .c files into .o files and then link all your .o
files together then it should work fine.
I don't know how to get the GNURadio build system to do that for you though
(probably just appending the names of the .c files to the list of source
files will do it though)
This is correct. You just need to arrange so that those files end up
in the same shared library as the block that's using them.
Just add the the .c files to the _la_SOURCES entry in the
appropriate Makefile.am
Are you building this outside of the main tree a la
gr-howto-write-a-block, or in the main tree? The idea is the same in
both cases.
Does this make sense?
Eric
_
This email, including any attachments, is only for the intended addressee.
It is subject to copyright, confidential and may be the subject of legal or
other privilege, none of which is waived or lost by reason of this
transmission. If the receiver is not the intended addressee, please accept
our apologies, notify us by return, delete all copies and perform no other
act on the email. Unfortunately, we cannot warrant that the email has not
been altered or corrupted during transmission.
_
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Oussama Sekkat's FPGA development document
Thomas, Oussama, and group, Thanks. I'm working on a GPS receiver and plan to put some tracking loops on the FPGA. Chris Thomas Schmid wrote: Hi Chris, Thank you for that note. I didn't realize that attachments don't go into the mail archive. Following is a link which should point to the latest version of that document: http://acert.ir.bbn.com/viewvc/gr-ucla/trunk/doc/usrp.pdf?revision=HEAD Cheers, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fusb_nblock and fusb_block_size
Hi all, What do the parameters fusb_nblock and fusb_block_size exactly do in how data is transmitted over the USB to the USRP? I assume that fusb_nblock indicates how many blocks we have in each USB packet, and fusb_block_size indicates how big one block is. My question is, if there is less data available on the USRP (i.e. not fusb_nblock*fusb_block_size), does it still get sent over the USRP to the computer? How is the smallest amount of data necessary in the USRP defined such that a packet is sent over the USB to the computer? Is it fusb_block_size? Thank you very much, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Two Antenna Ports on RFX2400?
Could someone please answer my question? There are two antenna ports on the RFX2400 daughter board -- "TX/RX" and "RX2". I have only one "2400-2480 MHz ISM Band Vertical Antenna". Will it be OK with the hardware board circuit if I leave the "RX2" port open with no protector? Thanks. Luke ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block.How to build?
Hello,
Thanks to both Eric and Daniel for your prompt help.
Yes this does make sense and it was the first thing I tried. After it
didn't work with my files I went right back to basics (I am building a
la gr-howto-write-a-block). I created very simple .h/.c files as a test.
/*test.h*/
#ifndef __TEST__
#define __TEST__
void jonas_test();
#endif
/*test.c*/
#include "test.h"
#include
void jonas_test()
{
printf("this is a test, proof is in the pudding\n");
}
Then:
Within “howto_square2_ff.h” I added #include “test.h”.
Within “howto_square2_ff.cc” I added a call to jonas_test(), located in
the constructor howto_square2_ff ().
I added test.c to the “_howto_la_SOURCES” entry in “src/lib/Makefile.am”.
Finally: “make clean”, “make” and “make check”.
This results in:
ImportError:
/home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
undefined symbol: _Z10jonas_testv
I tired other variations (creating test.i, included in howto.i etc) but
I must be missing something fundamental.
Thanks again for you help!
Eric Blossom wrote:
On Wed, Nov 29, 2006 at 10:39:20AM +1030, Daniel O'Connor wrote:
On Wednesday 29 November 2006 09:26, Jonas Hodel wrote:
I have some existing C-functions which I would like to include in a C+
signal processing block. The complication is that these C-functions are
located in a number of different files. I have created a C++ block which
uses these functions. It appears to build fine but when I come to
include the new block in my python script I get an “undefined symbol”
error referring to one of the low level C-functions (I think). In short,
is it possible to use my existing C-files unchanged (included in my C++
block)? If so what approach is necessary to make this work/build properly?
You need to compile those .c files into .o files and then link all your .o
files together then it should work fine.
I don't know how to get the GNURadio build system to do that for you though
(probably just appending the names of the .c files to the list of source
files will do it though)
This is correct. You just need to arrange so that those files end up
in the same shared library as the block that's using them.
Just add the the .c files to the _la_SOURCES entry in the
appropriate Makefile.am
Are you building this outside of the main tree a la
gr-howto-write-a-block, or in the main tree? The idea is the same in
both cases.
Does this make sense?
Eric
===
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Oussama Sekkat's FPGA development document
Hi Chris, Thank you for that note. I didn't realize that attachments don't go into the mail archive. Following is a link which should point to the latest version of that document: http://acert.ir.bbn.com/viewvc/gr-ucla/trunk/doc/usrp.pdf?revision=HEAD Cheers, Thomas On 11/29/06, Chris Stankevitz <[EMAIL PROTECTED]> wrote: Hi, I recently found a reference to a document Oussama Sekkat attached to a message on this board. Neither Oussama's email nor his attachment was saved in the mail archive. Can someone please send that document to me or provide a link? Here is a reference to a reply to the email I am asking about: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg06148.html Thank you! Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Oussama Sekkat's FPGA development document
Hi, I recently found a reference to a document Oussama Sekkat attached to a message on this board. Neither Oussama's email nor his attachment was saved in the mail archive. Can someone please send that document to me or provide a link? Here is a reference to a reply to the email I am asking about: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg06148.html Thank you! Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scanning/Detecting Wifi
Thank you so much for the info. could you please tell me what makes us to believe that USRP board is able to detect wifi(802.11b ) . one more question is what kind of signals the siggen.py is generating? thank you in advance Ravi - Original Message - From: Dan Halperin <[EMAIL PROTECTED]> Date: Monday, November 27, 2006 10:36 pm Subject: Re: [Discuss-gnuradio] Scanning/Detecting Wifi > I found that I can see a lot of structured noise on, e.g., the > frequency2.467G (802.11b channel 6) using my RFX2400 and the > usrp_oscope script > in the gnuradio-examples/python/usrp directory. That gives me good > indication that the board works. > > Also, if you have two boards, run usrp_siggen on one and > usrp_oscope on > the other. You get nice sine waves. > > -Dan > > Ravi Kiran Yellepeddy wrote: > > Hello, > > > > I am looking to scan/detect a Wifi using RFX2400 USRP board. can > i find any such example to run . i just want to make sure that my > board is working by running such examples > > > > thanks, > > Ravi > > > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error in usrp_oscope.py example gnuradio-3.0.2
Hi George, The solution below worked just fine. I can run usrp_oscope.py example correctly now. Thanks, Rohit - Original Message - From: "George Nychis" <[EMAIL PROTECTED]> To: "Rohit Gupta" <[EMAIL PROTECTED]> Cc: Sent: Monday, November 27, 2006 8:20 PM Subject: Re: [Discuss-gnuradio] Error in usrp_oscope.py example gnuradio-3.0.2 They may have installed to somewhere not in your sys.path do this: python import sys print sys.path and make sure those got installed in one of those paths I also initially had problems with this... wxpython and gnuradio python modules were being installed to /usr/local rather than /usr Give it a shot. - George Rohit Gupta wrote: Hi George, I did install the three wxpython rpms from www.wxpython.org. wxPython2.6-devel-gtk2-ansi-2.6.3.3-rh9_py2.3 wxPython2.6-gtk2-ansi-2.6.3.3-rh9_py2.3 wxPython-common-gtk2-ansi-2.6.3.3-rh9_py2.3 Rohit - Original Message - From: "George Nychis" <[EMAIL PROTECTED]> To: "Rohit Gupta" <[EMAIL PROTECTED]> Cc: Sent: Monday, November 27, 2006 7:11 PM Subject: Re: [Discuss-gnuradio] Error in usrp_oscope.py example gnuradio-3.0.2 Hey, You need wxpython: http://www.wxpython.org/ I am not familiar with Enterprise Linux and the kind of package managers it has... but thats the package you need to create the python module. - George Rohit Gupta wrote: Hello, I am trying to install Gnuradio-3.0.2 on 2.6.9-22 Enterprise Linux running on x86 platform. I installed the following dependencies boost_1_33_1cppunit-1.10.2 fftw-3.1.2sdcc-2.6.0 cppunit-1.10.0numpy-1.0 swig-1.3.29 wxPython2.6-devel-gtk2-ansi-2.6.3.3-rh9_py2.3 wxPython2.6-gtk2-ansi-2.6.3.3-rh9_py2.3 wxPython-common-gtk2-ansi-2.6.3.3-rh9_py2.3 The commands "configure" , "make" , "make check" and "make install" run fine. I then ran the following commands, cd gnuradio-examples/python/usrp export PYTHONPATH=/usr/local/lib/python2.3/site-packages ./usrp_oscope.py Traceback (most recent call last): File "./usrp_oscope.py", line 29, in ? from gnuradio.wxgui import stdgui, fftsink, waterfallsink, scopesink, form, slider ImportError: No module named wxgui Any help in fixing this is much appreciated. Rohit ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block. How to build?
On Wed, Nov 29, 2006 at 10:39:20AM +1030, Daniel O'Connor wrote: > On Wednesday 29 November 2006 09:26, Jonas Hodel wrote: > > I have some existing C-functions which I would like to include in a C+ > > signal processing block. The complication is that these C-functions are > > located in a number of different files. I have created a C++ block which > > uses these functions. It appears to build fine but when I come to > > include the new block in my python script I get an “undefined symbol” > > error referring to one of the low level C-functions (I think). In short, > > is it possible to use my existing C-files unchanged (included in my C++ > > block)? If so what approach is necessary to make this work/build properly? > > You need to compile those .c files into .o files and then link all your .o > files together then it should work fine. > > I don't know how to get the GNURadio build system to do that for you though > (probably just appending the names of the .c files to the list of source > files will do it though) > This is correct. You just need to arrange so that those files end up in the same shared library as the block that's using them. Just add the the .c files to the _la_SOURCES entry in the appropriate Makefile.am Are you building this outside of the main tree a la gr-howto-write-a-block, or in the main tree? The idea is the same in both cases. Does this make sense? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
