[Discuss-gnuradio] Beacon frames of BBN 802.11

[Jane Chen]

Hi all,
 
I ran bbn_80211b_rx.py and got the information as follows:
PKT: len=163, rssi=-18, src=00:15:aa:55:6C:82, time=13720, rate=1 Mbps
PKT: len=163, rssi=-23, src=00:15:aa:55:6C:D2, time=21272, rate=1 Mbps
..
 
 
According to the information of packets, I don't think I can know if these 
packets are beacon frames or not because I don't know the subtype of the frame. 
However, on the [Discuss-gnuradio] 802.11 on USRP+GNURadio : "Looking at the 
archives, I understand that I can receive 1 Mbps  probe/beacon packets with 
code developed by BBN", it seems I can know if the packets are beacon frames.  
Can anyone tell me how to know if these packets are beacon frames if it is 
possible? Thank you!
 
Jane


  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: from a function generator into the LF-RX (maximum load)

[Karthik]

On Fri, Feb 20, 2009 at 3:05 PM, feldmaus  wrote:

> Markus Feldmann  gmx.de> writes:
>
> >
> > Hi All,
> >
> > as i read in the documentation,
> Is there additional documentation for the LF-RX
> Daughterboard ?
>
> Regards Markus
>

If you look at the LFRX the input consists of AD813x fully differential
amplifier with unity gain and a input impedance of 50 ohm. I am not sure if
there are diodes which limit the signal swing, maybe looking at the
schematics can help you with this.

>From what I understand the LFRX and Basic-RX are very similar, so the same
rules for safety apply. I have used 2V pk-pk voltages as input from a signal
with a source impedance of 50 ohms without any problems. If your source
doesn't have a 50 ohm source impedance, the DC voltage will be incorrect by
about 106mV (there are some threads which discuss this issue in greater
detail).

Karthik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Questino on Gnuradio as the client and VLC as the server

[Brook Lin]

Hi All,

I am using USRP to receive video streaming, and feed the data to a socket as
the client. Then, I open a vlc as the server to open the network stream via
UDP. The code is shown below.

# the server
vlc udp://@:2002

# the client, which is inserted into benchmark_rx.py in
/gnuradio-example/python/digital
def main():
..
def rx_callback(ok, payload):
..
print "ok = %5s  pktno = %4d  n_rcvd = %4d  n_right = %4d" % (ok,
pktno, n_rcvd, n_right)

rxdata.append(payload[2:])
clientHost = 'localhost'   # servername is localhost'
clientPort = 2002   # use arbitrary port > 1024 
dgramSock = socket.socket( socket.AF_INET, socket.SOCK_DGRAM )#
create a UDP socket

dgramSock.connect((clientHost,clientPort)) # connect to server on
the port
for ndx_data in rxdata:
dgramSock.sendto( ndx_data, (clientHost, clientPort) )  
# send the data
data = dgramSock.recv(4096) # receive up to 4096
bytes
#print data
dgramSock.close()

...

My questions are:
1, I don't think the client(Gnuradio) and the server(VLC) are connected via
UDP
2, Is it correct that I write the received data to a client UDP socket?
3, If I change the server to the following(don't use VLC as the server), I
can play serverfile.mpeg using VLC. However, I don't want vlc to open from
file. 
serverHost = ''
serverPort = 2002
dgramSock = socket.socket( socket.AF_INET, socket.SOCK_DGRAM )
dgramSock.bind( (serverHost, serverPort) )
msggot=[]
while 1:
  msg, (addr, port) = dgramSock.recvfrom(4096)
  print 'Server connected by', addr,port
  #print 'Server got ',msg
  dgramSock.sendto( msg, (addr, port) )
  
  fd = open('serverfile.mpeg','a')
  fd.write(msg)
  fd.close
dgramSock.close()

Overall, I want to play the realtime video that I received from USRP. Can
anyone help me with these questions? I really appreciate.

Thanks,
Brook
-- 
View this message in context: 
http://www.nabble.com/Questino-on-Gnuradio-as-the-client-and-VLC-as-the-server-tp22130820p22130820.html
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: from a function generator into the LF-RX (maximum load)

[feldmaus]

Markus Feldmann  gmx.de> writes:

> 
> Hi All,
> 
> as i read in the documentation,
Is there additional documentation for the LF-RX
Daughterboard ?

Regards Markus



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Behrouz Farhang-Bourjeny and his book

[Robert McGwier]

Behrouz has improved his booked with editing and errata repair and
having the material tried out on students.

I used the book in a class in an early form, at work, and I am very
happy to report that Behrouz continues to improve on the work.

It does not yet have the OFDM chapter in it.  I need to send Behrouz
my comments on it but at this time as do others who have received the
chapter, but at $16 for the pdf,  it is a must have in its current
form.  I am honored he recognized the feedback I gave him from the
classes Frank Brickle and I taught together and the use I have been
making of it at the University of Maryland.

Again, I am very happy to recommend this book in its updated form:

http://www.lulu.com/content/1620824

Bob McGwier


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: [Flexradio] [dttsp-linux] Intel ATOM WHOOAAAAA Nellie

[Robert McGwier]

http://www.nvidia.com/object/sff_ion.html

I think it is pretty clear that almost anyone with any real experience
would take Nvidia's restricted distribution graphics drivers about 100
to 1 over the open source CRAP that comes from ATI, and forget
completely any of their competitors.  I have removed from service
every single ATI device which I am able to remove in the last few
months because of the utter horror of their driver support.

I have yet to have a single Nvidia restricted driver download fail once.

BEWARE:  YMMV.

I attempted to make the point and Frank made it much more clearly.  If
you need Firewire,  the ATOM D945GCLFx  family (intel motherboard) is
required to get the PCI slot.  I am very happy with mine.  I use it
all the time.  There is nothing wrong with it.  Like all things,
better things come along rapidly these days.  What I am personally
happy about is how cheap these offerings have been.  I have NO IDEA
what the price point will be on the Nvidia ION.

I think the marketing hype video on the nvidia web page, showing the
joint impact of the 2 GB of DDR3 and the Nvidia GeoForce 9300, is
about right on target.

In addition, the specs show that GigE is supported.  I am expecting
excellent performance because of the clear concentration of IO support
in this box.  The small footprint desktops have nearly 100% of the
usable back covered with IO connectors.  That bare space is not really
bare.  You need it to get your fingers in on the connectors!


Bob


On Fri, Feb 20, 2009 at 12:36 AM, Frank Brickle  wrote:
> On Thu, Feb 19, 2009 at 11:17 PM, Bob McGwier  wrote:
>
> ...HOWEVER, for those folks who want to build an small board computer for
>> supporting the Flex family of firewire devices,  the Intel motherboards
>> are your only choice.  You need the PCI slot to get the firewire support...
>
>
> For DttSP apps it's not a real choice. You will need a PCI slot, either for
> FireWire audio like the Edirol FA-66 or the PreSonus FireBox, or merely for
> some other halfway decent soundcard like the M-Audio Delta 44. This is a
> required configuration for effectively using sdr-shell, sdr-core, and the
> sdrTEC board, for example. A reference Linux implementation for this
> combination, with a cost of around $800US total for the RF front end +
> computer, is about ready to go up on CGRAN.
>
> The FireWire+Flex option is moot for dttsp-linux and vrk, but the other
> FireWire/PCI addons are critical. DttSP apps using the USRP1+GNU Radio are
> fine. USRP2 is an open question, for now.
>
> Short form: for dttsp-linux and general RF hardware, the Atom 330 is
> unquestionably the more utilitarian alternative. This is especially so when,
> given Nvidia's history regarding Open drivers, Linux support for ION is very
> uncertain in the near term (6-9 months).
>
> 73
> Frank
> AB2KT
>
> --
> Some people are like slinkies...not really good for anything, but they still
> bring a smile to your face when you push them down a flight of stairs. --
> Anon.
> ___
> FlexRadio Systems Mailing List
> flexra...@flex-radio.biz
> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
> Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/
> Knowledge Base: http://kc.flex-radio.com/  Homepage: 
> http://www.flex-radio.com/
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help with OpenBTS

[Fabian Uehlin]

Hello!

There is an OpenBTS discussion list (-> http:// 
openbts.sourceforge.net/).


I think the problem is solved by changing file Thread.h (folder  
CommonLibs) line

const static size_t mStackSize=65536;
to
const static size_t mStackSize=4*65536;

Regards -Fabian-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Help with OpenBTS

[Bruno Engelbert]

I have problem with segmentation fault when executing the binary 
./transceiver and ./OpenBTSxxx together...


the output binary's:

./transceiver:
1235159974.196907 3084109504: creating USRP device...
1235159974.197083 3084109504: making USRP device..
1235159975.017775 3084037008: set RX: 780.00 actual RX: 
779.997020
1235159975.030025 3084037008: set TX: -320.00 actual TX: 
-320.762939

1235159975.099702 3084037008: starting radio interface...
1235159975.116884 3084037008: radio interface started!
1235159975.121985 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 0:0
1235159975.122125 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 1:0
1235159975.122158 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 2:0
1235159975.122197 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 3:0

1235159975.122417 3083897744: Starting USRP
1235159975.122429 3083897744: starting USRP...
1235159975.124900 3083897744: TX pgas: 0.00, 0.00
1235159975.129035 3083897744: USRP started
1235159975.129143 3083897744: radioInterface.cpp:173 converted 585 
transceiver samples into 864 radio samples
1235159975.129171 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 4:0
1235159975.129190 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 5:0
1235159975.129206 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 6:0
1235159975.129224 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 7:0
1235159975.129432 3083897744: radioInterface.cpp:173 converted 585 
transceiver samples into 864 radio samples
1235159975.129449 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 0:1
1235159975.129464 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 1:1
1235159975.129480 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 2:1
1235159975.129496 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 3:1
1235159975.129718 3083897744: radioInterface.cpp:173 converted 585 
transceiver samples into 864 radio samples
1235159975.129739 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 4:1
1235159975.129755 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 5:1
1235159975.129770 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 6:1
1235159975.129946 3083897744: radioInterface.cpp:173 converted 585 
transceiver samples into 864 radio samples
1235159975.129962 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 7:1
1235159975.131227 3083828112: radioInterface.cpp:250 converted 864 radio 
samples into 585 transceiver samples
1235159975.131280 3083828112: radioInterface.cpp:382 receiveFIFO: wrote 
radio vector at time: 1:0, new size: 0
1235159975.131295 3083828112: radioInterface.cpp:382 receiveFIFO: wrote 
radio vector at time: 2:0, new size: 0
1235159975.131308 3083828112: radioInterface.cpp:382 receiveFIFO: wrote 
radio vector at time: 3:0, new size: 0
1235159975.131374 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 0:2
1235159975.131413 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 1:2
1235159975.131444 3083897744: radioInterface.cpp:336 transmitFIFO: read 
radio vector at time: 2:2
1235159975.131632 3083897744: radioInterface.cpp:173 converted 585 
transceiver samples into 864 radio samples

Falha de segmentação (core dumped)


the dump file from GDB:

#0  0xb7db6bb6 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1  0x4e00 in ?? ()
#2  0xb7feb851 in usrp_basic_rx::read (this=0xb7ce7000, buf=0xb7ce2210, 
len=82432, overrun=0x9e61749) at usrp_basic.cc:942
#3  0x08058ef2 in USRPDevice::readSamples (this=0x9e311d0, 
buf=0xb7cf6550, len=864, overrun=0x9e61749, timestamp=20864, 
underrun=0xb7cf72e7, RSSI=0x0)

   at USRPDevice.cpp:314
#4  0x0804b46f in RadioInterface::pullBuffer (this=0x9e61550) at 
radioInterface.cpp:208
#5  0x0804ecb2 in RadioInterface::driveReceiveRadio (this=0x9e61550) at 
radioInterface.cpp:353
#6  0x0804f780 in ReceiveRadioServiceLoopAdapter 
(radioInterface=0x9e61550) at radioInterface.cpp:310

#7  0xb802b50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7e1fa0e in clone () from /lib/tls/i686/cmov/libc.so.6

any help??


--


*Bruno Engelbert*
/Estagiário Nível Superior/
/DDT - PSN - Produtos e Serviços Networking/

*DÍGITRO TECNOLOGIA*
*E-mail:* bruno.engelb...@digitro.com.br 


*Fone:* +55 48 3281- / +55 48 3281-7000
*Fax:* +55 48 3281-7299
*Site:* www.digitro.com 

/"Antes de imprimir pense na sua responsabilidade e compromisso com o 
meio ambiente"/



--
Esta mensagem foi verificada pelo sistema de antivírus da Dígitro Tecnologia

Re: [Discuss-gnuradio] Required Hardware

[Eric Blossom]

On Fri, Feb 20, 2009 at 12:02:45PM -0800, Trevor Bosaw wrote:
> Hey,
>
> I'm trying to set up a transmitter that simply broadcasts voice (AM  
> quality is fine) over a range of a few miles.  It would be implemented  
> in developing world situations, such as rural India or Africa, and  
> therefore must be constructed with very cheap hardware.  We currently  
> have selected a suitable computer to deal with the software necessities 
> (saving and queueing audio files to be transmitted), but what other 
> hardware is necessary for the transmission?  I am new to gnu-radio, and 
> can probably convince the sponsor to pay for a USRP for research 
> purposes, but of course this definitely would not be able to be used in 
> the actual implementation.
>
> Trevor

A simpler, cheaper route is to use one of Ramsey (or somebody else's)
low power transmitters.  E.g., FM30B or FM100B

  http://www.ramseyelectronics.com/hk

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 and external clock (from GPS receiver)

[Eric Blossom]

On Fri, Feb 20, 2009 at 02:03:08PM -0600, Douglas Geiger wrote:

>  It looks like usrp2_impl.cc never passes on the argument when you call
> config_mimo - I've attached a quick patch that I believe does the job
> correctly.
>  When I run my host code now the clocks on my USRP2's remain
> synchronized to my external source.
>  Doug

Fixed in 10471.  Thanks!

Sorry for the trouble it caused you.

Eric

> Index: usrp2_impl.cc
> ===
> --- usrp2_impl.cc (revision 10441)
> +++ usrp2_impl.cc (working copy)
> @@ -995,6 +998,7 @@
>  cmd.op.opcode = OP_CONFIG_MIMO;
>  cmd.op.len = sizeof(cmd.op);
>  cmd.op.rid = d_next_rid++;
> +cmd.op.flags = flags;
>  cmd.eop.opcode = OP_EOP;
>  cmd.eop.len = sizeof(cmd.eop);
>  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: [dttsp-linux] Intel ATOM WHOOAAAAA Nellie

[rhubbell]

On Fri, 20 Feb 2009 14:55:26 -0500
Dan Halperin  wrote:

> thing `proprietary' about the newer Intel WiFi drivers is a binary  
> firmware component that, primarily, enforces the FCC regulations. **  
> See Disclaimer [1] **

"primarily", so what else does it do? Secondarily? Oh that's
proprietary information? Need an NDA?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Required Hardware

[Trevor Bosaw]

Hey,

I'm trying to set up a transmitter that simply broadcasts voice (AM  
quality is fine) over a range of a few miles.  It would be implemented  
in developing world situations, such as rural India or Africa, and  
therefore must be constructed with very cheap hardware.  We currently  
have selected a suitable computer to deal with the software  
necessities (saving and queueing audio files to be transmitted), but  
what other hardware is necessary for the transmission?  I am new to  
gnu-radio, and can probably convince the sponsor to pay for a USRP for  
research purposes, but of course this definitely would not be able to  
be used in the actual implementation.


Trevor


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 and external clock (from GPS receiver)

[Douglas Geiger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Douglas Geiger wrote:
> Matt Ettus wrote:
>> Sync_to_pps is all about timestamps and the pps input, so it is not
>> related to whether or not the clock is locked.
> 
> Right, got it.
> 
>> Just to clarify the clocking architecture on the USRP2, there are
>> basically 3 modes:
> 
>>  - Free running
>>  - Locked to the external SMA reference input
>>  - Locked to the clock which comes over the MIMO cable from another USRP2
> 
>> You need to make sure you are in the 2nd one, aka "we lock to SMA".  It
>> sounds like whatever code you are running is setting the mode to "we
>> lock to MIMO connector" mode.
> 
>> Matt
> 
> You're correct - it looks like as soon as I call config_mimo, it looses
> the lock to SMA. I'm a bit confused as to why that is - I'm calling it
> with MC_WE_LOCK_TO_SMA which is defined in usrp2_mimo_config.h - it
> basically comes out as 0x0001 (i.e. _MC_WE_LOCK | 0, where _MC_WE_LOCK
> is 0x0001).
> 

 It looks like usrp2_impl.cc never passes on the argument when you call
config_mimo - I've attached a quick patch that I believe does the job
correctly.
 When I run my host code now the clocks on my USRP2's remain
synchronized to my external source.
 Doug

- --
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.gei...@okstate.edu
doug.gei...@ieee.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnwx7gfOzzR5bXIgRAkgeAJ9c+Zt+R3Pp/iH2JAzI5ulAFPXEvQCfdfWM
CTWdJOXlQT1u8+R1zp4/kv8=
=ATyU
-END PGP SIGNATURE-
Index: usrp2_impl.cc
===
--- usrp2_impl.cc   (revision 10441)
+++ usrp2_impl.cc   (working copy)
@@ -995,6 +998,7 @@
 cmd.op.opcode = OP_CONFIG_MIMO;
 cmd.op.len = sizeof(cmd.op);
 cmd.op.rid = d_next_rid++;
+cmd.op.flags = flags;
 cmd.eop.opcode = OP_EOP;
 cmd.eop.len = sizeof(cmd.eop);
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: [dttsp-linux] Intel ATOM WHOOAAAAA Nellie

[Dan Halperin]

On Feb 19, 2009, at 9:44 PM, Gregory Maxwell wrote:

Nvidia video is a pretty poor choice for Linux too— you're tied to
their proprietary drivers which often cause weird bugs (usually the #1
cause of kernel panics on the kernelopps data collection project,
right ahead of a proprietary wifi driver), and that driver ties you to
whatever kernel and xorg versions they are willing to support.


I just have to jump in here and say that you're being pretty dogmatic.  
I'm not disagreeing with you on the fact that Nvidia doesn't support  
Linux in an ideal way, but you should rethink what you mean by  
proprietary or perhaps by the connotation in which you use it.


What is a 'proprietary wifi driver'? Better yet, what isn't a  
proprietary wifi driver? In particular, (assuming you were digging at  
iwlwifi, which has been near the top of kerneloops recently), the only  
thing `proprietary' about the newer Intel WiFi drivers is a binary  
firmware component that, primarily, enforces the FCC regulations. **  
See Disclaimer [1] **


The FCC's attitude towards enforcement is exactly the same thing that  
is worrying the SDR community [2], but which we currently get around  
it simply by ignoring it [3]; we can do that since Ettus Research  
isn't (yet :) exactly a huge multinational corporation. Intel, on the  
other hand, does have to worry about such things.


Here's what I do know about Intel & the iwlwifi drivers:
- Intel's corporate position (fairly newly revised) regarding WiFi  
drivers is that the day Windows drivers are released, functional Linux  
drivers need to be released as well
- They're developed by a small (ridiculously small, IMO) team that's  
relatively new to the Linux kernel game, but they're learning more  
about the process and 'doing more things right' every day
- They've proved willing to modify drivers to adopt suggestions from  
OS community, (e.g., adding support for injection mode)
- They've got a very happy set of users due to their being very  
responsive on the Linux driver mailing list
- iwlwifi is (IMO) the most mature and feature complete 802.11n driver  
implementation of any of the major vendors
- And because iwlwifi has implemented most of the new 802.11n features  
first, they work closely in tandem with the main kernel wireless guys  
(e.g., mac80211 developers) in defining the major interfaces in the  
networking stack and adapting them for universal compatibility [4]


What more could you want? Your flippant remark above is exactly that  
kind of muleheaded, black-and-white attitude that will keep other  
large corporations like Intel from warming up to the open source  
community faster. And that's a real shame, because when these policy  
shifts like Intel's do happen the results are often pretty great.


Dan

[1] ** Disclaimer ** I interned at Intel Research Seattle this past  
year, and have conducted research using the iwlwifi driver and also  
contributed bugfixes back to the same. Everything I say here is  
completely my own opinion and none of it represents Intel Corporation.  
[But some of this puts me in a good place to inform you about their  
process and attitude towards OSS and the Linux community.]

[2] See e.g. this old GNU Radio thread: 
http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg00559.html
[3] You can trivially bypass USRP FCC enforcement, and Matt will even  
tell you how :) e.g. http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg14203.html
[4] See aggregation support, which was in the iwlwifi drivers before  
Atheros announced open source ath9k drivers. However, the kernel  
network stack wasn't easily able to support this and they're still  
working on fitting it in.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 and external clock (from GPS receiver)

[Douglas Geiger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matt Ettus wrote:
> Sync_to_pps is all about timestamps and the pps input, so it is not
> related to whether or not the clock is locked.

Right, got it.

> 
> Just to clarify the clocking architecture on the USRP2, there are
> basically 3 modes:
> 
>  - Free running
>  - Locked to the external SMA reference input
>  - Locked to the clock which comes over the MIMO cable from another USRP2
> 
> You need to make sure you are in the 2nd one, aka "we lock to SMA".  It
> sounds like whatever code you are running is setting the mode to "we
> lock to MIMO connector" mode.
> 
> Matt

You're correct - it looks like as soon as I call config_mimo, it looses
the lock to SMA. I'm a bit confused as to why that is - I'm calling it
with MC_WE_LOCK_TO_SMA which is defined in usrp2_mimo_config.h - it
basically comes out as 0x0001 (i.e. _MC_WE_LOCK | 0, where _MC_WE_LOCK
is 0x0001).

- --
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.gei...@okstate.edu
doug.gei...@ieee.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnwaQgfOzzR5bXIgRAi2hAKCBOY2ijc1wo2MF/jFBRAEAqQpCigCgsEeS
xqHAjKz3SoLMYFG4JK2sefo=
=+Ulx
-END PGP SIGNATURE-


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] There is no ./configure in gr-bbn?

[Jane Chen]

Thank you for your reply. The problem is solved. Thank you!　I read the INSTALL 
file and it did not mention ./bootstrap step. 





From: Eric Blossom 
To: Jane Chen 
Cc: discuss-gnuradio@gnu.org
Sent: Thursday, February 19, 2009 5:28:25 PM
Subject: Re: [Discuss-gnuradio] There is no ./configure in gr-bbn?

On Thu, Feb 19, 2009 at 03:56:30PM -0800, Jane Chen wrote:
> Hi all,
> 
> I got the code through cvs -d anon...@acert.ir.bbn.com:/cvs/adroitgrdevel co 
> adroitgrdevel ,but there is no ./configure in gr-bbn. 
> 
> I ran autoconf, but got errors as follows:
> 
> # autoconf
> configure.ac:25: error: possibly undefined macro: AM_CONFIG_HEADER
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> configure.ac:27: error: possibly undefined macro: AM_INIT_AUTOMAKE
> configure.ac:40: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
> configure.ac:41: error: possibly undefined macro: AC_ENABLE_SHARED
> configure.ac:42: error: possibly undefined macro: AC_DISABLE_STATIC
> configure.ac:43: error: possibly undefined macro: AC_PROG_LIBTOOL
> 
> How can I install the BBN?
> 
> Thank you,
> Jane
> 

Did you

./bootstrap 

before trying to configure?

Eric


  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Intel ATOM WHOOAAAAA Nellie

[rhubbell]

Just say "no" to nvidia. See reasons provided by others.

> them!  I want to ask those who do not see an immediate need for them but 

I never saw a question anywhere.

Basically this email (cross-posted all over the place) is an
advertisement.

On Thu, 19 Feb 2009 23:20:21 -0500
Bob McGwier  wrote:

> Many of us have and love the Intel ATOM 330 boards we have.  I have 3 of 
> them!  I want to ask those who do not see an immediate need for them but 
> are thinking about getting one for SDR purposes,  I want to tell you 
> that "better things are arriving" as always.
> 
> The Nvidia ION will address almost 100% of the few gripes with the 
> D945GCLF2 and D945GCLF (Intel Mobo) computers.  The intel graphics chip, 
> 3D/2D acceleration, is okay, but it is not great.  The D945GCLF2 
> addressed the desire for 64 bit OS, but we still had pretty slow memory 
> supporting slow DDR2.  Unhappy with the PC VGA connector on the Intel?  
> The Nvidia ION has HDMI  output and 7.1 audio!
> 
> The Nvidia ION address both of these shortcomings.  The Nvidia ION has a 
> memory of Nvidia's very impressive GPU's with the GEO Force (9300/9400) 
> family.  It is also supports DDR3 memory.  Both of these factors will 
> represent MAJOR improvements in the performance.
> 
> Please, if you have not already purchased the Intel ATOM motherboards,  
> hold up a bit.  There is nothing wrong with the $80-$90 motherboards you 
> currently have but these new ones will represent bit steps in the right 
> direction. 
> 
> HOWEVER, for those folks who want to build an small board computer for 
> supporting the Flex family of firewire devices,  the Intel motherboards 
> are your only choice.  You need the PCI slot to get the firewire support.
> 
> For those of us who want to support USB 2.0 or better yet,  GigE,  the 
> Nvidia ION will provide more IO ports than the Intel motherboard and has 
> the other advantages already mentioned here.  You will need an external 
> drive case to hold the drives as the eSata ports are on the back of the 
> motherboard for Nvidia ION.
> 
> So,  no firewire needed?  better memory and graphics needed?  HDMI 
> needed or desired?  Wait for the Nvidia ION motherboards to become 
> available to you in the second quarter of this year in desktops and 
> motherboards.  The ASUS N10Jc notebook are, or soon will be available.
> 
> Bob
> 
> -- 
> (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
> Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
> NJQRP, QRP ARCI, QCWA, FRC.
> "It is human nature to think wisely and act in
> an absurd fashion.", Anatole France.
> Twitter:rwmcgwier
> Active: Facebook,Myspace,LinkedIn
> 
> 
> 
> 
> ___
> 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] Re: Re: Re: USRP2 and external clock (from GPS receiver)

[Eric Blossom]

On Fri, Feb 20, 2009 at 06:52:43AM +0100, Changkyu Seol wrote:
> Changkyu Seol wrote:
> > Matt Ettus wrote:
> > Thank you for the files.
> > I tested as you suggested with firmware and fpga files you sent me and 
> > it is locked!! I used it other USRP2s and all worked fine.
> > 
> > I modified and compiled "txrx.c" in gnuradio (revision 10464, fedora 9) 
> > trunk to generate "txrx.bin". What was the problem?
> > 
> > Changkyu Seol
> 
> I downloaded GNU radio by following command. (I am not used to linux.)
> 
> $ svn co http://gnuradio.org/svn/gnuradio/trunk gnuradio
> 
> "txrx.c" included seems to be very old version. Where can I get the 
> latest firmware/fpga source codes?

The trunk is the latest development code.

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 and external clock (from GPS receiver)

[Matt Ettus]

Douglas Geiger wrote:

 Ok - now that I've discovered I had some bad cabling - specifically a
bad T-splitter: the side going to my O-scope worked, the side going to
my USRP2's did *not* - which I suppose can be chalked up to user error.
I am now able to synchronize the clocks - both with the firmware/fpga
code you sent, and the version I had built locally.


Great!


 However - once I start running my code on the host PC, the clock loses
sync. I have to power down, and re-power-up the USRP2 for the clock to
lock onto my external source again. This is with the firmware/fpga from
svn r10441, and my host code. I've tried calling ->config_mimo and
- ->sync_to_pps() as soon as I create my USRP2 objects, but that didn't
seem to help.



Sync_to_pps is all about timestamps and the pps input, so it is not 
related to whether or not the clock is locked.


Just to clarify the clocking architecture on the USRP2, there are 
basically 3 modes:


 - Free running
 - Locked to the external SMA reference input
 - Locked to the clock which comes over the MIMO cable from another USRP2

You need to make sure you are in the 2nd one, aka "we lock to SMA".  It 
sounds like whatever code you are running is setting the mode to "we 
lock to MIMO connector" mode.


Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 and external clock (from GPS receiver)

[Douglas Geiger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matt Ettus wrote:
> Douglas Geiger wrote:
>> I'm at svn revision 10441 - with both the firmware and fpga code built
>> from that (using Xilinx ISE 10.1 to make the fpga). I've just modified
>> the txrx.c code - adding:
>> clocks_enable_test_clk(true, 2);
>> clocks_mimo_config(MC_WE_LOCK_TO_SMA);
>> just before the while(1) loop
>>
>> My rx_mimo.cc code also calls ->config_mimo(MC_WE_LOCK_TO_SMA), but
>> right now I've stepped back to just getting one USRP2 synchronized to my
>> external source - which in this case is a function generator with a
>> 10MHz sine with 2V P-P.
>>
>> Is it possible some of the hardware on my USRP2's isn't working?
> 
> Unlikely, since it was tested before shipping.
> 
> I will send you code to run in a separate email.
> 
> Matt

 Ok - now that I've discovered I had some bad cabling - specifically a
bad T-splitter: the side going to my O-scope worked, the side going to
my USRP2's did *not* - which I suppose can be chalked up to user error.
I am now able to synchronize the clocks - both with the firmware/fpga
code you sent, and the version I had built locally.
 However - once I start running my code on the host PC, the clock loses
sync. I have to power down, and re-power-up the USRP2 for the clock to
lock onto my external source again. This is with the firmware/fpga from
svn r10441, and my host code. I've tried calling ->config_mimo and
- ->sync_to_pps() as soon as I create my USRP2 objects, but that didn't
seem to help.
  Doug

- --
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.gei...@okstate.edu
doug.gei...@ieee.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnupogfOzzR5bXIgRAk+zAKCOijHE3lvJxrKAsjfD4rsoygDe6ACgrdU0
UxaHmnOjOccW7w31MglgJWE=
=pdqN
-END PGP SIGNATURE-


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with "How-to-write-a-block"-tutorial

[Mir Ali]

It happened to me once and I found that there was a problem with the way I
wrote the SWIG interface file. Make sure that the .i file is correct. I hope
it helps.

Thanks,
Ali

On Fri, Feb 20, 2009 at 7:55 AM, Martin Braun wrote:

> On Fri, Feb 20, 2009 at 10:32:03AM +0100, Emil Molin wrote:
> > Im still baning my head against the wall here, ive linked everything
> exactly
> > like in the example but it just gives the same error message on running
> the
> > tests.
> >
>
> If banging your head doesn't help (I find a wooden table most
> effective), check that the Makefile gets generated properly. If not,
> restart from scratch with 'make distclean && ./bootstrap &&
> ./configure'.
>
> MB
>
> --
> Dipl.-Ing. Martin Braun   Phone: +49-(0)721-608 3790
> Institut fuer Nachrichtentechnik  Fax:   +49-(0)721-608 6071
> Universitaet Karlsruhe (TH)   http://www.int.uni-karlsruhe.de/
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Mir Murtuza Ali
Graduate Student
Center for Wireless Communications
University of Mississippi
University, MS 38677
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DPSK Demodulation Output

[Johnathan Corgan]

On Wed, 2009-02-18 at 09:59 -0800, Charles Judah wrote:

> My question is, if I were to open and read a binary file of only
> alternating 1s and 0s into the DPSK modulator then immediately feed
> that back into the demodulator, what format is the demodulator putting
> byte data back out? Is it padding the information with 0s? Any insight
> into "how" the demodulation block submits the byte data to the
> subsequent connecting block would be greatly appreciated. 

The demodulator blocks output demodulated bits in what we call
"unpacked" form, which sends demodulated symbols in the LSBs of 1 byte
items.  In the case of dbpsk, these 1 byte items will have only the LSB
toggled to represent a decoded 1 or 0.

Johnathan




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with "How-to-write-a-block"-tutorial

[Martin Braun]

On Fri, Feb 20, 2009 at 10:32:03AM +0100, Emil Molin wrote:
> Im still baning my head against the wall here, ive linked everything exactly
> like in the example but it just gives the same error message on running the
> tests.
> 

If banging your head doesn't help (I find a wooden table most
effective), check that the Makefile gets generated properly. If not,
restart from scratch with 'make distclean && ./bootstrap &&
./configure'.

MB

-- 
Dipl.-Ing. Martin Braun   Phone: +49-(0)721-608 3790
Institut fuer Nachrichtentechnik  Fax:   +49-(0)721-608 6071
Universitaet Karlsruhe (TH)   http://www.int.uni-karlsruhe.de/


pgpf18Jvj9V6F.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 Gnuradio 3.1.3 and BBN 802.11 Code Working?

[Dimitris Symeonidis]

christine, eric already answered your question

Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with
a mosquito!" - Amnesty International



On Thu, Feb 19, 2009 at 22:18, Miklos Christine  wrote:
> If I revert to an old version of Gnuradio, would the USRP2 work with that?
> The Gnuradio code and BBN code that worked on the USRP, would it work on the
> USRP2?
> Is it backwards compatible?
>
> Thanks,
> Miklos Christine
>
> On Thu, Feb 19, 2009 at 11:26 AM, Eric Blossom  wrote:
>>
>> On Thu, Feb 19, 2009 at 10:40:42AM -0800, Miklos Christine wrote:
>> > Hello,
>> >
>> > I'm working on a project that involves the USRP2. I've downloaded the
>> > lastest version of Gnuradio and the BBN 802.11 code. I've come to
>> > realize
>> > that the newest release of Gnuradio is not compatible with the BBN code.
>> > Is there an earlier version of gnuradio that will work with the USRP2
>> > and
>> > the BBN code?
>> >
>> > Thanks,
>> > Miklos Christine
>>
>> The USRP2 is new.  No early version of GNU Radio supports it.
>> A bit of googling will find you several discussions about people
>> updating the BBN code to work with the latest GR code.
>>
>> Eric
>
>
> ___
> 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

R: [Discuss-gnuradio] Intel ATOM WHOOAAAAA Nellie

[Alberto Trentadue]

Hi Bob

Your detailed description below triggers one question.

I'm about to setup a desktop (non portable) platform for GNURadio.
I know how to assemble a PC, but actually not expert in selectin HW.
ATOM is a good new product.
But as long as I'm not interested in portability, low power and in nifty 
graphics (but of course nifty sound), and 
not interested in supporting a lot of periferals (a bunch of good USB2 will 
do), and only interested in outstanding CPU 
power and RAM access speed, is ATOM still the choice?
I may not wait for the NVidia ION to arrive.

Any suggestion?

Thanks in advance
Alberto

>Messaggio originale
>Da: rwmcgw...@gmail.com
>Data: 20/02/2009 5.17
>A: "dttsp-linux"
>Cc: "q...@yahoogroups.com", 
>"flexradio", "mep", "GNURadio Discussion List", "High Performance 
Software Defined Radio Discussion List"

>Ogg: [Discuss-gnuradio] Intel ATOM  WHOOA Nellie
>
>Many of us have and love the Intel ATOM 330 boards we have.  I have 3 of 
>them!  I want to ask those who do not see an immediate need for them but 
>are thinking about getting one for SDR purposes,  I want to tell you 
>that "better things are arriving" as always.
>
>The Nvidia ION will address almost 100% of the few gripes with the 
>D945GCLF2 and D945GCLF (Intel Mobo) computers.  The intel graphics chip, 
>3D/2D acceleration, is okay, but it is not great.  The D945GCLF2 
>addressed the desire for 64 bit OS, but we still had pretty slow memory 
>supporting slow DDR2.  Unhappy with the PC VGA connector on the Intel?  
>The Nvidia ION has HDMI  output and 7.1 audio!
>
>The Nvidia ION address both of these shortcomings.  The Nvidia ION has a 
>memory of Nvidia's very impressive GPU's with the GEO Force (9300/9400) 
>family.  It is also supports DDR3 memory.  Both of these factors will 
>represent MAJOR improvements in the performance.
>
>Please, if you have not already purchased the Intel ATOM motherboards,  
>hold up a bit.  There is nothing wrong with the $80-$90 motherboards you 
>currently have but these new ones will represent bit steps in the right 
>direction. 
>
>HOWEVER, for those folks who want to build an small board computer for 
>supporting the Flex family of firewire devices,  the Intel motherboards 
>are your only choice.  You need the PCI slot to get the firewire support.
>
>For those of us who want to support USB 2.0 or better yet,  GigE,  the 
>Nvidia ION will provide more IO ports than the Intel motherboard and has 
>the other advantages already mentioned here.  You will need an external 
>drive case to hold the drives as the eSata ports are on the back of the 
>motherboard for Nvidia ION.
>
>So,  no firewire needed?  better memory and graphics needed?  HDMI 
>needed or desired?  Wait for the Nvidia ION motherboards to become 
>available to you in the second quarter of this year in desktops and 
>motherboards.  The ASUS N10Jc notebook are, or soon will be available.
>
>Bob
>
>-- 
>(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
>Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
>NJQRP, QRP ARCI, QCWA, FRC.
>"It is human nature to think wisely and act in
>an absurd fashion.", Anatole France.
>Twitter:rwmcgwier
>Active: Facebook,Myspace,LinkedIn
>
>
>
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>




Attiva Tiscali Tutto Incluso: telefoni e navighi senza limiti A SOLI €10 AL 
MESE FINO ALL’ESTATE. Attiva entro il 26/02/09! 
http://abbonati.tiscali.it/promo/tuttoincluso/


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with "How-to-write-a-block"-tutorial

[Emil Molin]

Im still baning my head against the wall here, ive linked everything exactly
like in the example but it just gives the same error message on running the
tests.

2009/2/19 Emil Molin 

>
>
> 2009/2/18 Eric Blossom 
>
> On Wed, Feb 18, 2009 at 03:39:52PM +0100, Emil Molin wrote:
>> > Hi and thanks for the help, yes ive run it (and ive renamed the block to
>> > 'test' instead of 'howto_2' but i still get something wrong obviously
>> > because when running the test script i get this error:
>> >
>> >   File "./qa_test.py", line 6, in 
>> > from gnuradio import gr, gr_unittest, test
>> >   File "/Library/Python/2.5/site-packages/gnuradio/test.py", line 21, in
>> > 
>> > import _test
>> > ImportError: dlopen(/Library/Python/2.5/site-packages/gnuradio/_test.so,
>> 2):
>> > Symbol not found: __ZTV14test_double_ff
>> >   Referenced from: /Library/Python/2.5/site-packages/gnuradio/_test.so
>> >   Expected in: dynamic lookup
>> >
>> > it seems like there is something wrong in the swig-generated _test.so
>> file
>> > but how to fix that i have no idea?
>> >
>>
>>
>> $ c++filt _ZTV14test_double_ff
>> vtable for test_double_ff
>>
>> Are you sure you've got code for the class named test_double_ff linked
>> into the shared library you're building?
>>
>> Eric
>>
>
>
> Ive linked everythin in the same way as in the howto_square_ff example,
> what files could i have missed something in to not get the test_double_ff
> class linked?
>
> And well if its any reason to the problem this is how my makefile looks:
>
> #
> # Copyright 2004,2005,2006,2008 Free Software Foundation, Inc.
> #
> # This file is part of GNU Radio
> #
> # GNU Radio is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> # the Free Software Foundation; either version 3, or (at your option)
> # any later version.
> #
> # GNU Radio is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> # GNU General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License
> # along with GNU Radio; see the file COPYING.  If not, write to
> # the Free Software Foundation, Inc., 51 Franklin Street,
> # Boston, MA 02110-1301, USA.
> #
>
> include $(top_srcdir)/Makefile.common
>
> # Install this stuff so that it ends up as the gnuradio.test module
> # This usually ends up at:
> #   ${prefix}/lib/python${python_version}/site-packages/gnuradio
>
> ourpythondir = $(grpythondir)
> ourlibdir= $(grpyexecdir)
>
> AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) $(PYTHON_CPPFLAGS)
>
> SWIGPYTHONARGS = $(SWIGPYTHONFLAGS) $(SWIGGRFLAGS)
>
> ALL_IFILES = \
> $(LOCAL_IFILES)\
> $(NON_LOCAL_IFILES)
>
> NON_LOCAL_IFILES =\
> $(GNURADIO_CORE_INCLUDEDIR)/swig/gnuradio.i
>
>
> LOCAL_IFILES = \
> $(top_srcdir)/src/lib/test.i
>
> # These files are built by SWIG.  The first is the C++ glue.
> # The second is the python wrapper that loads the _test shared library
> # and knows how to call our extensions.
>
> BUILT_SOURCES = \
> test.cc\
> test.py
>
> # This gets howto.py installed in the right place
> ourpython_PYTHON =\
> test.py
>
> ourlib_LTLIBRARIES = _test.la
>
> # These are the source files that go into the shared library
> _test_la_SOURCES = \
> test.cc\
> test_double_ff.cc
>
> # magic flags
> _test_la_LDFLAGS = $(NO_UNDEFINED) -module -avoid-version
>
> # link the library against some comon swig runtime code and the
> # c++ standard library
> _test_la_LIBADD = \
> $(PYTHON_LDFLAGS)\
> -lstdc++
>
> test.cc test.py: $(LOCAL_IFILES) $(ALL_IFILES)
> $(SWIG) $(SWIGPYTHONARGS) -module test -o test.cc $(LOCAL_IFILES)
>
> # These headers get installed in ${prefix}/include/gnuradio
> grinclude_HEADERS =\
> test_double_ff.h
>
>
> # These swig headers get installed in ${prefix}/include/gnuradio/swig
> swiginclude_HEADERS = \
> $(LOCAL_IFILES)
>
>
> MOSTLYCLEANFILES = $(BUILT_SOURCES) *.pyc
>
> # Don't distribute output of swig
> dist-hook:
> @for file in $(BUILT_SOURCES); do echo $(RM) $(distdir)/$$file; done
> @for file in $(BUILT_SOURCES); do $(RM) $(distdir)/$$file; done
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio