Re: [Discuss-gnuradio] anyone have success with USRP2 @ 20MHz to the host cleanly?

[Dan Halperin]

On Nov 22, 2009, at 10:11 AM, George Nychis wrote:
> Has anyone here had any success with receiving 16-bit samples from the USRP2 
> @ 20MHz to the host without an onslaught of overruns?  I did some searching 
> on the list and some people suggested a RAID configuration, but this is my 
> poor little laptop.  Just wanted to get a general consensus. 

20 MHz @16bps is 80 MB/s right? That's just not going to work on a laptop hard 
drive without doing some major compression. I wrote a gzip_file_sink at some 
point in the past but the libz compression was too slow to even keep up with 8 
MHz @ 16bps. You could try looking for an alternate compression algorithm. I 
hear LZO is faster for instance.

IMO the best option for a laptop is an SSD. I do get about ~80 MB/s sequential 
write with my Intel SSD. But 160 GB isn't a lot if you're going to be doing 20 
MHz sampling!

Dan



___
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] Newbie need help with installing gnuradio 3.1.3

[Dan Halperin]

On Feb 15, 2009, at 12:11 PM, Chris Stankevitz wrote:


Pete,

How did you solve this problem:


While running ./bootstrap, I am getting the following error:
[r...@fodora gnuradio-3.1.3]# ./bootstrap
gr-trellis/doc/Makefile.am:51: `%'-style pattern rules are a GNU
make extension


AFAIK it's not a problem. It's just a message that crops up every time  
you bootstrap, at least on Ubuntu.


Dan


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

Re: [Discuss-gnuradio] inconsistency in the PER versus distance using USRP

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 20, 2008, at 6:40 PM, George Nychis wrote:




Bill Stevenson wrote:

In door environment; the temperature are the same in these two  
experiments; center frequency is 2479MHz because on one hand, I  
want to avoid the 2400MHz to 2483MHz band which is the working band  
of 802.11, on the other hand the bandpass filter on the 2400MHz  
daugterboard (2400M to 2483M) and the bandwidth of USB port which  
is 8MHz together forced me to chose the center frequency to be at  
most 2479MHz; all other conditions in these two experiments are the  
same: chairs and desks are fastened, not being moved, etc.




Didn't you just answer your own question?  You're operating within  
802.11 interference range.  The frequency band of channel 12 is  
2456-2478MHz.  You're sitting at 2479MHz and with 8MHz bandwidth,  
your bottom 4MHz are within 802.11 interference range.   
Additionally, you could use usrp_fft.py to actually inspect the  
channel and determine if there is any noise on it.


To be fair, assuming 20 MHz wifi, he should be fairly interference  
free. Channel 11 (2.462G) is pretty well attenuated at 2.479G  
according to the standard. I suspect you're going to have to dig in  
Bill. Note that multipath can have a huge effect, as well as frequency  
offsets and other variables, like the output power changing on the  
card. There's usually not an obvious easy answer for these things  
without digging into the RF.


If I move my leg I can knock the PRR from 100% to 5% easily -- using  
commercial WiFi.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkmIZQACgkQy9GYuuMoUJ6UJwCfV73j1smggESY+WKqn6C8UzhH
K1EAnAgnSmZ0YT2hrW3tmZos2MPONkyY
=Vigv
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] New (potential) user + question

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 17, 2008, at 10:44 AM, Peter O'Doherty wrote:


This is my first post to this list.
I'm a sound artist and I've just started to explore the world of  
software radio and have been eavesdropping on this list for a while  
and have a few questions. There seems to be a large body of  
dedicated users out there. I'm curious as to what kinds of things  
people use gnuradio for. Are there any other sound artists or the  
like here using software radio in their work?


Also, I'm worried about diving into the deep-end and buying a USRP  
package without being really sure it's what I need. Are there any  
cheaper alternatives or other possibilities to get a taste of what  
software radio is all about?


Welcome!

You really only need a USRP if you're going to be using __radio__. For  
__sound__ your sound card (and maybe you'll want a good one, but  
that's up to your needs) will work.


So if you want to work with sound, all you need is the free, open  
source software GNU Radio which is available for download on the wiki  
(at http://gnuradio.org). There are several examples in there that  
don't use the USRP (e.g., dialtone which plays a dial tone through  
your sound card). And most scripts can be modified to work w/o the  
USRP. For instance, we have made a narrowband wireless network using  
sound card & microphone on each machine instead of 2 USRPs.


Don't be fooled by the "radio" in "GNU Radio", most of the code is  
just signal processing which works with other types of signals too.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkhy44ACgkQy9GYuuMoUJ58GwCeKIbZyq4uToWsYrBnvIFSTDNm
ZrAAnR1nvFdVqIyHyJt7oH5UfwKeYZPv
=s0Bq
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] How to start to run the bbn code?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Nov 15, 2008, at 8:14 AM, Angie Ll wrote:


I am just starting to learn the GNU radio and bn code.
I want to test some sample bbn code, however, can anybody tell me  
where

and how can I run this code?


Look at CGRAN: https://www.cgran.org/ . The projects page should link  
to BBN code.


If you're really new to GNU Radio, you'll want to make sure you have  
some background on python, and signal processing basics, or this code  
may not make much sense to you.


- -Dan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkke/4sACgkQy9GYuuMoUJ5/cwCfep88gXClCua7wh4eC1KSGfZ2
ajAAn2AqCsym5FTSSlf5kNYccAZ2Snrh
=Qbyl
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] a simple qustion about the attenuator for the SMA cable

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 4, 2008, at 2:31 PM, Bill Stevenson wrote:

I have a rudimentary question about the attenuator. When I was  
searching some questions in the archive, I found that some guys  
mentioned when testing the transmitter and receiver for daughter  
board, the antenna should be connect by Tx/Rx SMA, the Tx and Rx can  
NOT be connected directly by cable and we need a attenuator about  
40-50 dB!! What is the meaning of attenuator here? Is it a hardware?  
Thanks a lot for all!


An attenuator is a piece of hardware that weakens ("attenuate" means  
weaken) the power of a signal transmitted along a wire. When you  
directly wire a TX board to an RX board, the power transmitted is much  
stronger than receiver expects (even a tiny bit of air gap induces a  
lot of attenuation) and can fry the circuitry. So we simulate this air  
gap with an attenuator.


Fixed RF attenuators can be had for fairly cheap ($10-20) I think.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkR4SkACgkQy9GYuuMoUJ5w4ACeONoqxFnQ+EEquRngohFnpN9v
j6AAoKE20VQNzDoDSOAx4oIaA/KPkOxA
=Satt
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Re: RFID data packet

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 28, 2008, at 4:10 PM, George Nychis wrote:


C.cc Jay wrote:

Dear andrea
I want to develop ISO 14443-A,
Can you tell me, how to find ASK100% python module. Or I must  
rewrite this part of the code.


Do you know if any of the RFID code done at UDub/Intel is going to  
be published soon? :)


I hope so! I know it's in the roadmap. The author (not me ;) is on  
post-NSDI vacation right now.


Note his code is for the EPC Gen 2 915 MHz standard. I suspect it may  
be different than the above mentioned standard (433 MHz) but I know  
basically nothing about RFID.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkHtOUACgkQy9GYuuMoUJ4CpACgucCGxnzRkpFr0/vTNMg2HsmN
qfsAn30LwT4/eFY8+JX0IzpGqmxKP1A9
=CFOc
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Problem feeding garbage to GNU Radio

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 10, 2008, at 11:59 AM, Philip Balister wrote:


My data file is 16bit complex shorts in big-endian format. It looks
like the file source block reads data from the file and sends it to
the fm demod which is expecting a complex float data. I attempted a
quick test by using the original data file (wrong format) which caused
the flow graph to crash with a seg fault. After converting the data to
a complex float representation the flowgraph works.


IIRC, (from doing the same thing :) ), it's really easy to get  
file_source to read invalid float/double values and get a bunch of  
NaNs in the input.


Is it worth the overhead of checking every single read for this?  
Probably not. But maybe we should do something about it... add an  
option for instance. Or more graceful handling of NaNs in some of the  
processing blocks.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjvqCYACgkQy9GYuuMoUJ6uugCaAt42i6ZIVp3dqcZUAU96WGiz
pkUAn0hpOw1O7KtGk1dCA2cUFSbTITK5
=jL2i
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] OOK reception

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 9, 2008, at 8:39 AM, Dan wrote:

Hi, I am working on an OOK receiver but am having some problems with  
the squelch.


I wrote a script with the following flow graph:

USRP.source_c -> complex_to_mag -> add_const_ff( -const ) ->  
binary_slicer_fb -> file_sink


This works fine, but I would like to have some sort of  
discrimination for when there is no signal.  I looked into adding a  
pwr_squelch_cc block after the source but this led to a lot of  
buffer overruns as the processing increased.  I am attempting to  
receive a bandwidth of 16 MHz using 8-bit samples so any more  
processing I add can make a difference.  The bandwidth is important  
as I am trying to maximize the data rates it can handle.




If you're doing complex_to_mag anyway, why not use that output for  
squelching instead of a pwr_squelch_cc ? The squelch algorithm is  
pretty simple.


Also, complex_to_mag has a sqrt in it which it looks like your flow  
graph doesn't need. All the following blocks would work just as well  
in the mag^2 domain. So maybe you should do that too.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjuLmIACgkQy9GYuuMoUJ5O5wCfYiDrzSWzZtNZiqkDmXkPN14x
v3MAn2c8phlTZ4jAnmlyj7a96891DAo0
=PjRd
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] How can I check usrp.sink_c

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 2, 2008, at 7:34 AM, kaleem ahmad wrote:


Hi,

I want to transmit some data using usrp.sink_c and immediately after  
the
data is sent I want to start receiver mode, but my problem is if I  
do like

this:

Send using 'usrp.sink_c'
start receive mode

My USRP immediately goes into receive mode and the data sent is not
successful, so I want to do something like following:

Send using 'usrp.sink_c'
check 'usrp.sink_c' if the data is sent then
 start receive mode


There is an automatic switching between transmit and receive modes  
that does what you want -- whenever there is something being  
transmitted, it disables the receive chain, and switches back once  
that buffer is empty. Look through the examples for flow graphs with  
both transmit and receive chains. It's called something like auto_tr.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjk9eQACgkQy9GYuuMoUJ5VnACbBRdFmIQcD0JF5hQThV6Z5oe7
tksAoICpSompAsP4d5Wq6TytrLqNyX6+
=AWGx
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] 3rd party software

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 11, 2008, at 1:14 PM, George P Nychis wrote:


The slightly longer response:

I think these are all great ideas, and I think they'd be a valuable
contribution to the GNU Radio community.  CPAN (The Comprehensive  
Perl
Archive Network) and CEAN (the Comprehensive Erlang Archive  
Network) are
but two implementations of similar ideas.  CPAN has been wildly  
successful

and is part of what has driven Perl's popularity.

If you want to try git -- or whatever -- please do, and keep us  
informed!


OK, since this is for "us," and us being the GNU Radio community,  
this should be up for discussion with everyone here.


What would people like to see?  Do people have preferences in  
version control systems?  It seems as though most people familiar  
with GNU Radio are already familiar with SVN, so would sticking with  
SVN be a good idea?


What do people think of trac+SVN for a website and documentation of  
code/projects?


Eric has already provided us with a domain name, and I'm 100% sure  
CMU could host whatever we want... I just want some feedback from  
the community since it's for you (and me ;)) and it should be  
something people want to use.  Once we come up with a basic design  
and policy, we can move forward.  I just don't want to pop up with  
some website and system that nobody likes, and have to then have  
this discussion and reimplement.


My impression is that SVN+trac is working pretty well. My experience  
with git has been everything but positive; maybe because I _still_  
haven't found that simple, elegant reference that explains it well,  
but I'm just not a fan. Plus it would be nice to keep the same model  
as the existing repo so that the checkout and build process is as easy.


Just my 7c :).

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjJg0sACgkQy9GYuuMoUJ7M9ACggVcqrdxroGJalRlSM2LYxic/
CpUAnA1rO4w4eQUXRnOaQxmzp+tnNvZw
=v2QF
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] 802.11a source codes? or any OFDM implementation on GNU Radio

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 11, 2008, at 11:26 AM, Mohsen Baratvand wrote:

Guy, all I need to do is changing some parameters such as preamble,  
LTF, STF, modulation and etc of the OFDM transmitter and then send a  
predefined pattern to the OFDM receiver, then estimate the channel.  
So I'm not gonna pass all the information and data to PC via the USB  
link. Just sending some report to my PC.


It's conceivable that by putting the modulation in the FPGA, you could  
get 802.11a OFDM modulation to work using the USRP -- just send the  
data across the bus. But no one has written such a firmware image yet  
- -- feel free! (Disclaimer: I have no idea whether an 802.11a modulator  
would fit into the small FPGA on USRP1, and haven't tried).


If you want to do modulation in the host, which doesn't involve FPGA  
coding and might allow you to use some of the existing OFDM code,  
you're going to be limited by the bandwidth of the USB -- 8 MHz isn't  
really enough. If you used 8-bit mode to get 16 MHz of bandwidth AND  
used one of the low bitrate encodings, high-SNR packets MIGHT get  
received by a good receiver. I don't know enough about 802.11's use of  
OFDM to decide. Maybe Kyle or Tom has a comment here.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjJaHsACgkQy9GYuuMoUJ6QFQCgrtkB7qISfljFS4mlxfZ7+4gL
gvgAn3OEN1ZhcZTGQqh/QljouhIjdiRK
=ksDR
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] USRP2 Price

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 9, 2008, at 12:11 PM, Brian Padalino wrote:

On Tue, Sep 9, 2008 at 3:08 PM, isaacgerg <[EMAIL PROTECTED]>  
wrote:


Any ideas in US dollars?


http://www.ettus.com/orderpage.html

List price seems to be $1400, but don't forget the accessories!



Whoa; are these actually purchaseable yet? Last I heard Matt wasn't  
taking preorders and there weren't any announcements to the contrary.


- -Dan


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjGyzoACgkQy9GYuuMoUJ7JuQCgtXau5HqdbKi6lDclWgIPUoBA
PDAAoIU2co6mi6nmMDqpRcg9RQDkKer2
=gXDe
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] RFX2400 bypassing the 2.4-2.483 GHz filter

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 9, 2008, at 10:04 AM, Rana Basheer wrote:


How do I go about bypassing this filter?


Check out this thread: 
http://www.nabble.com/FSK-with-RFX2400-td18587205.html#a18587205

which I found via a simple search: http://www.nabble.com/GnuRadio-f1878.html 
 "rfx2400 filter"





- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjGxrUACgkQy9GYuuMoUJ5XsgCeMUMFgZ7r8dZrS4dA5/ovt8Vp
GR4AoKRmMSbP6R6B5UsSkLMy7hbW+XvT
=c/Bj
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] atan2 problem

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 2, 2008, at 8:58 AM, Brian Padalino wrote:

On Tue, Sep 2, 2008 at 11:51 AM, Engin Karabulut <[EMAIL PROTECTED]>  
wrote:

hi all,

I have two signal which is float and I want to use
atan2 fuction like this,

self.arctan = math.atan2(x_hyd_filter, y_hyd_filter)

but gnuradio gives error given below,

...
self.arctan = math.atan2(x_hyd_filter, y_hyd_filter)
TypeError: a float is required.

In your opinion what is the problem?


Are you sure x_hyd_filter and y_hyd_filter are, in fact, floats?


If you're trying to do arctan on 2 __streams__ of floats, you can't  
use the Python math.atan2 function to do this operation -- you need a  
gnuradio processing block. I'm not even sure we have such a block yet,  
you might have to write it yourself.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAki9aZAACgkQy9GYuuMoUJ6HbwCfYFLDiXARaiz0mR+4/Zt4wwdC
ZiMAnRsLLldSLsbfM2Eq5X020LccWgI9
=jU0p
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] comedilib question

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 25, 2008, at 10:37 AM, Johnathan Corgan wrote:


On Fri, Aug 22, 2008 at 2:00 AM, Ulf Lindgren A
<[EMAIL PROTECTED]> wrote:


I have made a fix for the change in comedilib.


Thanks for the update.

We'll have to figure out a way to conditionalize the code between the
two libcomedi versions so the component works for either one.  Since
you are the only one who has reported this, and you've figured out an
workaround, this will likely go on the back burner until we start
cleaning up for the final push to release 3.2.


On this note, but slightly tangential, there are a bunch of third  
party gnuradio plugins that are not being kept up to date and even no  
longer work with gnuradio without significant changes. (E.g., top  
block vs flow graph). Do you think we can create space in SVN  
somewhere for the updated versions of these codes? I'm thinking about  
gr-ucla and maybe the BBN 802.11 stuff as well.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiy71AACgkQy9GYuuMoUJ4nIwCgqJ8+ON82GOutoHYdokz8tqQh
+HYAn0kAZIoCaGmPkpPBiHKwlaiXLB9o
=xva5
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] USRP External clocking

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 18, 2008, at 10:43 AM, Dan Halperin wrote:

http://gnuradio.org/trac/wiki/UsrpFAQ/Clocking



And there is another way of clocking if you want to solder on an SMA  
connector instead, connect an external clock, and disable the onboard  
clock.


http://gnuradio.org/trac/wiki/USRPClockingNotes

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkipthgACgkQy9GYuuMoUJ5PSACgj61nk3KZwvUIQE/6M/J+Qvgo
z4kAoMwys1a1nSCnVr1Sp/ziLGQdRE83
=fbpq
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] USRP External clocking

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 18, 2008, at 9:10 AM, Wireless Monster wrote:
Is any modification needed to the USRP board to use an external  
clock generator instead of the on board 64MHz one?


A trivial search of the Wiki, or the mailing list, should be executed  
before simple and common queries like this.


wiki search: http://gnuradio.org/trac/search
mailing list via Nabble: http://www.nabble.com/GnuRadio-f1878.html

(the answer is in a FAQ on Wiki and all over the mailing list)

http://gnuradio.org/trac/wiki/UsrpFAQ/Clocking

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiptL8ACgkQy9GYuuMoUJ6CJACfW5Id0MDNfmt0nfy3yqBj
WLIAnjCko/jL70MR/tQ3UMb04A3NYwFf
=0GG4
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] GNU Radio mention in DEFCON subway presentation

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 11, 2008, at 4:58 PM, Daniel O'Connor wrote:


On Mon, 11 Aug 2008, Philip Balister wrote:

New appication for USRP+GNU radio, free subway rides :)

http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf

Well, at least until people learn to deploy secure systems.


There's also..
http://venturebeat.com/2008/08/08/defcon-excuse-me-while-i-turn-off-your-pacemaker/

A bit more scary :(



Please please please don't be scared by this. Yet :). We believe that  
the risk to patients with today's technology is basically nil. Our  
attacks took tens of seconds to minutes and required very close range.  
From there it's much easier just to punch you.


The sentence that the article misquotes was closer to "With today's  
hardware, these attacks are mostly academic. We need to develop  
effective security solutions now before these types of attacks become  
easier to mount."


If I needed a pacemaker/cardiac defibrillator, I would get one without  
hesitation -- including the model we investigated.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkig1XsACgkQy9GYuuMoUJ7SIQCfbzcDsw48+rm6QdRaNBRFmxc+
DM8AoNZMCyMPUBz56Vv8lMbapUQOuivP
=E36k
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] 64MHz USRP Oscillator

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 31, 2008, at 12:15 PM, Wireless Monster wrote:

All,
I've been trying to set both Tx and Rx to the same frequency and  
sending a sinusoid to try to measure the frequency offset, but it  
does not seem to work... it looks like as both Tx and Rx are driven  
by the same clock, the frequency the offset gets compensated on the  
Rx signal so it can not be measured... (???)


Anyone has any clue on how to measure it dynamically at the code  
startup?



You have to measure frequency offset between different crystals --  
e.g., 2 USRPs. There's no way to calculate an absolute. Maybe if you  
have the RFX version where each DB has (and uses) its own crystal you  
could do this between two DBs on the USRP, but this would still only  
be their relative offsets.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiSEOcACgkQy9GYuuMoUJ6nhQCgoOXeqTykV1sj8ClohR/1jjdV
IJYAn1XG433cA2mXEfrGFeA/hcxS3o6h
=n9M9
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 29, 2008, at 6:14 PM, yyzhuang wrote:


That's the point. But to unpack a packet, we have to know exactly  
its format.
Hope someone can tell what format of the packet is. And what  
information can

we get from the packets.



The 802.11 packet format is non-trivial. You'll want to look at the  
spec for that. It's available for free download @ http://standards.ieee.org/getieee802/


If I had one piece of advice, it would be "be careful of endianness"

- -Dan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiPwhoACgkQy9GYuuMoUJ7wbACfUJsoUULKhZWR0oe8tL7y4aPQ
m5cAoLsdscdjvGVao6OHUMEkaE908QgB
=FQ73
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Possible residual carrier not reported correctly

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 28, 2008, at 2:09 PM, isaacgerg wrote:



Eric,
 When you talk about the FPGA, do you mean that I can repull and  
reinstall
the FPGA code for the USRP?  This I have never done since the radio  
has been

purchased 2 years ago.

Isaac


The FPGA code is dynamically loaded when the USRP is initialized. As  
long as you have an installed copy of GNU radio newer than 10/2007 you  
should already be using the updated RBF file which is the FPGA code  
image.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiONz8ACgkQy9GYuuMoUJ7eawCfQJpQOh+bxylHBQkopBXtfZ1E
gWcAnjeboTx3qzehHKDJ2nEVxo3fIOAh
=kqM2
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Frontend for the 470Mhz UHF band

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

From Matt's recent announcement email:

""
2   Upcoming Daughterboard Status

The WBX0510, a transceiver which will cover 50 MHz to 1 GHz, has been  
delayed a bit,

but we hope to have it ready for purchase some time in July.

The WBX0822, a transceiver which will cover 800 MHz to 2.2 GHz, should  
be available

by the end of 2008.
""

- -Dan

On Jul 15, 2008, at 10:35 AM, Rafael Diniz wrote:


Hi there!
I'd like to know if there is in development or already available a
daughterboard for the USRP that could transmit in the UHF band of  
470Mhz ~

700Mhz.

I'd like something like a TVTX :)

Thanks,
Rafael Diniz




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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkh84NoACgkQy9GYuuMoUJ53QACgyW2S/TLGEBCaJ4LuB9FOxAxG
7qIAnAqF0YO3PX3cGIkZTn9kU0TTAUh7
=YZWL
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] 8 bit samples have an odd spectrum

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 11, 2008, at 11:24 AM, Chris Stankevitz wrote:

Matt Ettus wrote:
Remember that while the ADCs are 12 bits, we carry 16+ bits of  
precision throughout the signal processing.


How do you get 16 bits of precision from a 12 bit ADC?  What does  
16+ mean?  I'm looking at the shorts coming from the USRP and I'm  
seeing values in the range [-3296 3264] which implies more than 12  
bits... curious.


Decimation.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkh3p60ACgkQy9GYuuMoUJ5A2gCgzvVpt/bL4zoyqWv9dHEQN3bM
FBQAnjuxZb2N5n2MonvJERJRzZHRWuBY
=rn8P
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Deterministic TX phase on a pair of RFX400

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Jun 2, 2008, at 3:20 PM, Matt Ettus wrote:
The RFX400s have PLL chips on them.  The PLL chips on the 2 boards  
are fed the same reference clock since it comes from the  
motherboard.  However, they both divide the clock down by the "R  
Divider" value, which is typically 8.   The RFX400 has a second  
divide-by-2 as well for a total of 16.  Thus there would be an 8-way  
ambiguity, since the dividers could be at different phases.  Thus  
the relative phases between 2 boards can only be one of 16 discrete  
values.  This value will stay constant as long as you don't retune  
to a different frequency or allow the pll enable pin to go low.


If you set your RF frequency to a multiple of 64 MHz, however, there  
will be no ambiguity.


What of the above is {the same, different} for the RFX2400's?

I'm using Rev 4.2 USRPs with RFX2400 Rev 30s. Presumably with Rev 4  
USRPs but older RFX2400s with 64 MHz oscillators I could make the mods  
necessary to use the FPGA refclk.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhpPpAACgkQy9GYuuMoUJ5pcgCgj2zM2y9cTykmLuPLz0/48zuS
XogAn1md0M6e8dG+Ns2ofgSV6UKN0dBE
=axdn
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] multiple antennas and multiple usrps

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 25, 2008, at 4:28 PM, Eric Blossom wrote:
2) I have a transmitter USRP and a receiver USRP attached to the  
same

machine. I use usrp.serial_number() as suggested by Eric in many
previous mails to distinguish between them. I have a code loop like
this:


Are you loading a different fpga image into the different USRPs?


Yes, one is (was, I guess?) using std_4rx_0tx.rbf (see 1) and the
other was using the default.
Thanks,

Dan


That would do it :-)

Please let me know if the (untested) code fragment I sent works out.


I ended up using the following code:

from usrpm import usrp_prims

def find_serial_number(serial):
which = 0
d = usrp_prims.usrp_find_device(which)
while True:
if not d:   # No USRP connected
raise RuntimeError, "Unable to find USRP with Serial #  
%s" %(serial)
if usrp_prims.usrp_unconfigured_usrp_p(d):  # Needs firmware/ 
FPGA image

usrp_prims.usrp_load_standard_bits(which, False)
# Turn the usb_device into a usb_device_handle
handle = usrp_prims.usrp_open_cmd_interface(d)
# Get the Serial # (SN) out, then close device handle
SN = usrp_prims.usrp_serial_number(handle)
usrp_prims.usrp_close_interface(handle)
# Compare to desired
if SN == serial:
return which
# Next USRP
which += 1
d = usrp_prims.usrp_find_device(which)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhkCTEACgkQy9GYuuMoUJ64sgCeJXZQqCWsG5lJQNSWkL6KnWw0
6k8AoIf++crasusKNHC0BPlq2l9OjZBC
=SSyF
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] multiple antennas and multiple usrps

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 25, 2008, at 3:20 PM, Eric Blossom wrote:


On Wed, Jun 25, 2008 at 02:37:48PM -0700, Dan Halperin wrote:
1) I notice that multi-antenna.py claims to only work with the  
BasicRX

boards. Any reason I can't use the 2 RX paths on each of 2 RFX2400s
assuming the d'board is powered up and configured correctly?


The RFX boards don't actually have two receive paths.  They have two
antenna ports.  The boards output analog I & Q to the usrp
motherboard, and thus two A/D's are required to handle each
daughterboard.  With a single USRP and two RFX2400s you can handle two
inputs and two outputs.


So what you're saying is you can't use the TX/RX and the RX2 both for  
receive at the same time? I guess that jives with the figure here:


http://gnuradio.org/trac/wiki/UsrpRfxDiagrams

Instead, that's only to enable concurrent transmit on TX and receive  
on RX2... that doesn't exactly seem that useful.



2) I have a transmitter USRP and a receiver USRP attached to the same
machine. I use usrp.serial_number() as suggested by Eric in many
previous mails to distinguish between them. I have a code loop like
this:


Are you loading a different fpga image into the different USRPs?


Yes, one is (was, I guess?) using std_4rx_0tx.rbf (see 1) and the  
other was using the default.

Thanks,

Dan


You can get the serial numbers without actually opening them by using
the low level usrp prims.  Take a look at usrp/host/swig/prims.i


from usrpm import usrp_prims

def get_serial_number(which):
   d = usrp_prims.usrp_find_device(which)
   if not d:
   raise RuntimeError, "Unable to find USRP #%d" % (which,)
   if usrp_prims.usrp_unconfigured_usrp_p(d):   # no  
firmware loaded yet
   usrp_prims.usrp_load_standard_bits(which, False) # load the  
firmware

   return usrp_prims.usrp_usrp_serial_number(d)



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhiyFIACgkQy9GYuuMoUJ6h5QCghGbyreXs4bMYFmHtOt9fLvmw
wPIAn3sHnuUyCzKQhvuVRIfaowzz8/Dz
=GMAx
-END PGP SIGNATURE-


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

[Discuss-gnuradio] multiple antennas and multiple usrps

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Two not-that-related questions... but here goes.

1) I notice that multi-antenna.py claims to only work with the BasicRX  
boards. Any reason I can't use the 2 RX paths on each of 2 RFX2400s  
assuming the d'board is powered up and configured correctly?


2) I have a transmitter USRP and a receiver USRP attached to the same  
machine. I use usrp.serial_number() as suggested by Eric in many  
previous mails to distinguish between them. I have a code loop like  
this:


which = 0
self.u = usrp.source_c(which, )
while self.u.serial_number() != "RX Serial":
del self.u
which += 1
self.u = usrp.source_c(which, )

and the analogous loop in the transmitter code. If I start the program  
that runs USRP #1 first, then this works fine; if I start the program  
that runs USRP #0 first, then when the other gnu radio script opens  
USRP #0 again, finds the wrong SN, and then opens #1, the  
functionality of USRP #0 breaks. (I think). For instance, I can't Ctrl- 
C out of usrp_siggen.py any more if it's the transmitter running on  
USRP #0.


Any suggestions?

Thanks,

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhiuqwACgkQy9GYuuMoUJ5JgACggRcBQBHwJfTO6rGXR0wVcO6i
MWAAoIYELnUj1Ivo840cPX6tul9J/DpN
=hSaq
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Losing data during long collects

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 4, 2008, at 10:59 PM, Chris Stankevitz wrote:

USRP's cfile utility cannot write my data without overruns, so I use  
my own app which I have attached to this email in case anyone is  
interested.  I will try Juha's recorder to see if it performs better.


FWIW (maybe you've fixed the problem already), I would think that if  
this is the case then you're using the cfile script wrong. Are you  
using the '-s' switch (to halve the required disk bandwidth)?


- - - - -Dan
- - - -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhIZygACgkQy9GYuuMoUJ5BsgCfYduc32l6EqBYFsWv4NwvraCI
QHEAn3oyMLBzzjt+UnYZUxpPKQWvsqOs
=/cw9
- - - -END PGP SIGNATURE-
- - -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhIZzgACgkQy9GYuuMoUJ7OKgCgkJeiokb3X8A8ycAkiTi9Ed70
17IAoMtDwlbTFdfLKPV1qzVT85sWCGT1
=GQuU
- - -END PGP SIGNATURE-
- -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhIZ2kACgkQy9GYuuMoUJ6cTACfeAlD6lKRH8iwTu5tmRVts3t5
id8AoKHTnvTKCYMaWPk40XT7I7YHv5Ts
=eLJB
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhIaSIACgkQy9GYuuMoUJ5oDQCgjEFuuToFAQjP2Xh3p2C3Jngw
FvsAoKOrA30Ku+/F3SUySeF6Q1Ck0WH0
=z9Y8
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] buffer allocation failed

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 9, 2008, at 9:21 AM, Eric Blossom wrote:


You're probably running into a limit on the total number of shared
memory segments in the system (SHMMNI) or the max segs per process
(SHMMSEG).  You can check the current values by:

 $ cat /sys/proc/kernel/shmmni

You can set the value one time using

 $ cat 4096 >/sys/proc/kernel/shmni

or arrange to have it always set by editing /etc/sysctl.conf


Yeah, that must be it. (I don't have root on the cluster but once I  
get support to change it I'll see if that works.)


Just FYI, I found the file at /proc/sys/kernel not /sys/proc/kernel.  
And presumably it's echo 4096>shmmni not cat 4096>shmmni ?


Thanks!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgkfL0ACgkQy9GYuuMoUJ7PAQCfesQyL03uj7TBXGVae2IT+gXx
kH8AnAuSz/qwF9VkVgN3Pkpljr/pae2Q
=wWJQ
-END PGP SIGNATURE-


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

[Discuss-gnuradio] buffer allocation failed

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey,

I know that the buffer allocation uses some memory mapping tricks to  
make it efficient; is there some shared resource that this process  
uses of which a computer should have a finite amount? I'm running a  
process with, oh, say 500 buffers (estimate) or so and once I get past  
7 parallel instances running I get std::bad_alloc errors allocating  
the buffers. Each process used only about 32m of virtual memory...


Is this expected?

Thanks,

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgkcOsACgkQy9GYuuMoUJ68fACffFAUFQCNeUCWTTXe82fwGK7p
FEMAnjRVIiEL/wZWXf5SCkgMafjirKOW
=Ygfm
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] What does the USRP transmit after I've done tx->stop.

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I don't know how relevant this is, but I have fixed similar problems  
in the past by making sure that the host app sends data that's an even  
multiple of 512 bytes. (This is harder than you think :))


I found that if you send a number of sample bytes equivalent to 1 same  
mod 512 bytes, for instance, the last sample is repeated for some time  
and can be observed as a short pilot tone. I never did too much  
digging into this, however -- I just modified the transmitting app to  
pad.


- -Dan

On Apr 25, 2008, at 7:31 AM, George Nychis wrote:




Per Zetterberg wrote:

Hi All,
I am transmitting a stream of buffers from the USRP (based on  
libusrp with
standard .rbf file). After I've done tx->stop (where tx is a  
pointer to
usrp_standard_tx) it seems that the USRP is repeating the last  
transmitted

buffer (or couple of buffers ?). Is this correct ?



Continually, until you unplug the board?  If so, I've noticed this  
behavior too as of recent... I used to be able to replicate it 100%  
of the time, but haven't tried for a couple weeks.


Are you using the current GNU Radio trunk?

- George


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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgSBP4ACgkQy9GYuuMoUJ7gqgCg1D9y0VS5kACJP2n1HNJoLphD
u+oAniv+yi/QK3L19WDcRZ077xHh0ebO
=LbHy
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] CPU load

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 19, 2008, at 2:24 PM, Eric Blossom wrote:

On Fri, Apr 18, 2008 at 10:25:07AM -0400, Brian Padalino wrote:

On Fri, Apr 18, 2008 at 10:21 AM, Wireless Monster
<[EMAIL PROTECTED]> wrote:

Thank Martin,
However I was thinking in a way to measure the load of each  
gnuradio block.

Any clue?
Rgds,


I know Eric likes to use oprofile:

   http://oprofile.sourceforge.net/about/

You will definitely get a real sense as to what's eating up your
cycles, but it may be a bit too granular for most people.  I have
never used it, personally.

Brian


It breaks it down per function, plenty fine for most uses.


You can also do per line.

UNfortunately, the call-graph method is broken on 64-bit linux (AFAI  
can tell from really poor documentation and mailing lists), so if two  
blocks use the same subroutines (atan2f, fft methods, etc) you can't  
distinguish CPU usage by block.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgKaJYACgkQy9GYuuMoUJ6LsQCgkN51+lBziZAgwe9yPpTj7TgS
WXgAnAtjZzjIjC2k0G9B/B2Zdgro2SXT
=n0SP
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] USRP Tx Rate Conversion

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


 At hat point can I send the samples (for example from a file with
> gr.file_source) and guarantee they will be treated as a 270.8333Ks/ 
s stream?

> (assuming there will be enough samples to process)

No.  They will be treated like a 2Msps stream which is what you
interpolated your 270.8333Ksps stream to.  You will have interpolated
your original signal by exactly 96/13 which will give you a 2Msps
stream.


I think you and Brian are experiencing notational confusion with Ks/s.  
If you treat the post-processed signal as a 2 Msamples/sec signal then  
the output signal will be a 270.733 Ksyms/sec. I believe that the USRP  
settings you describe will do just that.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgFCpoACgkQy9GYuuMoUJ5RJgCfcq8ShxoFNmhvWNLFxET0V1CC
4nMAoKb4DyL8RyBxWCCntsfMwKZssUoQ
=dC0T
-END PGP SIGNATURE-


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

[Discuss-gnuradio] disable 3dnow, etc

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is there an way to disable the (usually good) automatic recognition of
advanced CPU features by the filter libraries, etc?

Thanks!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0KG3y9GYuuMoUJ4RAndmAJ4j7c2qW2QjRK/5O6szdCfVZ7cZjgCgjH3S
zH/zVQUN+q/2hzn0o/8G1Fg=
=OpPs
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] usrp_rx_cfile usage

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Phaysal Khan wrote:
> I get the msg 
> Using RX d'board A:
> USB sample rate 4M

It's using side A, not side B. Try with the "-R B" option. (see the
usage message shown below)

$ usrp_rx_cfile.py
Usage: usrp_rx_cfile.py: [options] output_filename

Options:
  -h, --helpshow this help message and exit
  -R RX_SUBDEV_SPEC, --rx-subdev-spec=RX_SUBDEV_SPEC
select USRP Rx side A or B (default=A)
  -d DECIM, --decim=DECIM
set fgpa decimation rate to DECIM [default=16]
  -f FREQ, --freq=FREQ  set frequency to FREQ
  -g GAIN, --gain=GAIN  set gain in dB (default is midpoint)
  -8, --width-8 Enable 8-bit samples across USB
  --no-hb   don't use halfband filter in usrp
  -s, --output-shorts   output interleaved shorts in stead of complex floats
  -N NSAMPLES, --nsamples=NSAMPLES
number of samples to collect [default=+inf]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHz16dy9GYuuMoUJ4RAnooAJ9PzrkjOHAaUBL3KZtjERARdC4DUgCeMqRp
bw6GeA/8VwSgqN+jdpezNKM=
=U3KX
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] global CXXFLAGS?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Blossom wrote:
> On Mon, Mar 03, 2008 at 12:29:45PM -0800, Dan Halperin wrote:
>> I've tried to change the global CXXFLAGS by modifying
>> gnuradio/configure.ac, but the changes are not propagated to the rest of
>> the tree even after a configure. I've had some success modifying all of
>> the Makefile.am files in the directories of interest, but is there a
>> better way?
>>
>> [The goal would be to force -O0 and -g1, for instance]
> 
> I think you should be able to set them using
> 
>   ./configure CXXFLAGS="-O0 -g1" ...

Indeed! Thanks.

As a practical matter, we also had to set CCFLAGS, CPPFLAGS, CCASFLAGS,
and FFLAGS. For anyone else out there :).

[On a Mac running Leopard with GR 3.1.1].

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHzIXty9GYuuMoUJ4RAnQXAJwMZbK4c5NDmn5CFhSLlljkv9LMlACeOfPx
vAf4Ud7qXO6gCNgh8MDnAYc=
=kOIW
-END PGP SIGNATURE-


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

[Discuss-gnuradio] global CXXFLAGS?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry for the dumb question :).

I've tried to change the global CXXFLAGS by modifying
gnuradio/configure.ac, but the changes are not propagated to the rest of
the tree even after a configure. I've had some success modifying all of
the Makefile.am files in the directories of interest, but is there a
better way?

[The goal would be to force -O0 and -g1, for instance]

Thanks!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzF+5y9GYuuMoUJ4RAsbJAKCer+1j/YUWPrCM1TsDlePEkl3WNACcCegv
MXEIxQ4pJIvpCvX/+Ul4PpY=
=1/xh
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] OFDM packets

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

George Nychis wrote:
> it seems to me like you're using antennas, you can try coax to isolate
> the problem maybe you're getting interference at 2.4GHz.  But answer
> Eric's questions too.

With suitable attenuation of course -- I think Matt says at least 30 dB.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHxzTQy9GYuuMoUJ4RAki7AJ98iYlWjoRTvjA21nMsOZQKKFnewACgq6nX
BFb3UQtYJRc36QesNydjKbI=
=km2M
-END PGP SIGNATURE-


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

[Discuss-gnuradio] VTune and GNU Radio

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Has anyone had success using VTune (or pin, or another linux profiler)
with GNU Radio? I'm experiencing a difficulty in that VTune segfaults
when trying to process libgnuradio-core and pin produces no output at
all, although both programs work on other binaries, e.g. /bin/ls.

I even removed all of the python from the loop by writing a C++ app that
builds and runs the flow graph.

Information we're looking for includes things like instruction mix and
{CPU time, cache misses, etc etc etc} overhead in a callgraph-like
format which I couldn't figure out how to get out of oprofile.

Thanks,

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHv0Ouy9GYuuMoUJ4RAojiAJ9aP1kKMpoaPfqfznPguPyHpEXZ+QCePfag
Gm5iRTDIcUF54KWKikAkDso=
=pLIj
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] C++ gnuradio apps

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dan Halperin wrote:
> Suppose I want to build a C++ application to drive GNU Radio, using
> captured trace data -- so I don't need the USRP.

Another observation: It looks like right now there's no
super-header-file like "gr.h" that does the same thing for C++ that
"import gr" does for Python. This would also be useful :).

Also, from my code it looks pretty straightforward that we should be
able to integrate this with GRC.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvwTcy9GYuuMoUJ4RAq8uAJwJk2+F13mM3bCy4sTUdEuDqjQoMgCffoUC
fR/QiSvjQFdqvSttRdCEC9g=
=T/pr
-END PGP SIGNATURE-


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

[Discuss-gnuradio] C++ gnuradio apps

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Suppose I want to build a C++ application to drive GNU Radio, using
captured trace data -- so I don't need the USRP.

With the new top_block stuff we should be ready for this now, correct?
Here's a short program towards going down that path:

#include 
#include 
#include 
#include 

int main()
{
gr_top_block_sptr tb = gr_make_top_block("topblock");
tb->connect(gr_make_null_source(sizeof(gr_complex)),
gr_make_null_sink(sizeof(gr_complex)));
tb->run();
}

A few questions/observations:

1) Since most blocks don't have public constructors, we have to indirect
through the _make_ friend functions. Is this what we want?

2) This example doesn't compile. There are two candidates for connect:

/usr/local/include/gnuradio/gr_hier_block2.h:61: note: candidates are:
void gr_hier_block2::connect(gr_basic_block_sptr)
/usr/local/include/gnuradio/gr_hier_block2.h:64: note:
void gr_hier_block2::connect(gr_basic_block_sptr, int,
gr_basic_block_sptr, int)

What does the first one do?? It only takes a single block...

The second one is presumably with ports? I will try that next. Can we
add a connect method that takes two blocks and assumes the ports are both 0?

Thoughts? Thanks,

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvv94y9GYuuMoUJ4RAiV4AJ9VRjbz8dxiOPmqJh4ETZjuxiLhpQCgwd0Y
CdXVyDwdj1zHJxOhuhrM6Dw=
=oV3h
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] OFDM Updates

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Shravan Rayanchu wrote:
> Basically, I seem to completely lose some of the packets in the air.
> Of the packets I receive, almost all the packets are received
> correctly. Initially, the error rate was too high (The packets were
> getting lost and also among the packets received, lot of them were in
> errors), so I increased tx-amplitude to ~3000.
> 
> Am I using the right version of the code ? Is the tarball release
> better to use ? Can you please let me know if there are any parameters
> which I need to change ?

Tom mentioned an existing problem in the email you replied to, which you
didn't address in your response. Could that be the problem or have you
ruled it out?

For debugging these types of errors, I really do suggest (from
experience!) that you start saving the outputs of the intermediate
stages to disk and seeing what they look like. It might require some
understanding of the receiver, but then again you probably want that
knowledge anyway...

It's likely (as I found with older versions of the DBPSK code, for
instance) that some of the synchronization and/or timing algorithms
aren't working in your setup. But maybe there's lots of cochannel
interference. Maybe the RSSI is low. Maybe the frequency offset of your
daughterboards is too large to be handled by the PLLs...

The way that you can tell these things is by analyzing the output --
it's really hard for Tom to debug it offline. And he can't test his code
in all possible environments.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHs3iGy9GYuuMoUJ4RAtSyAJ9pyTdRSiJONyTSWtHZErCtzH8FrwCdFYNu
NMAnpoUeOInoFo1U2hRFSZs=
=Y0Jt
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] FIR filters and set_history()

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

George Nychis wrote:
> What general_work() would do is use the first ntaps() samples as
> "history" and start producing output at in+ntaps().  I would then
> consume ninput_items-ntaps() to then keep those last ntaps() samples in
> the input queue as the "history" for the next series of input.
> 
> I'm sorry if my logic is slightly or completely off.  But then I look at
> most of the FIR filters, and see the use of set_history(), great!  This
> sounds like it is exactly what I want.  Furthermore, looking at the
> documentation it states that it is what I want:
> http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/runtime/gr_block.h#L62

What set_history actually does is prepend that many zero samples. But it
still adds forecast(noutput_items) samples to the input buffer before
calling work... So when work() is called with noutput_items,
history+forecast(noutput_items) samples are ready in the input buffer,
starting from index 0.

If you look at the implementation of filterN, it reads at samples
0..ntaps-1. So when you call filterN with noutput_items as the length
parameter it will eventually read items 0..noutput_items+ntaps-1. Here
you've set ntaps = history.

In the normal code in the trunk, this works just as expected. But when
you make your custom vectors, you only pull noutput_items out of the
input buffer, not noutput_items+history.

Also, my understanding of a normal matched filter is that it does the
normal complex multiplication (by the conjugate, but I'm assuming you've
done that already before building the taps), not the real-wise and
complex-wise ... inner product, I guess? ... as you've defined it.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHqXwCy9GYuuMoUJ4RApVoAKDC3Xrm7spiGzCZZNaS5tvYuPXzzwCfbQzN
pjjttuBVpMgY4vPo6l5/KLc=
=QVtD
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Problems when receiving after transmit

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Interesting. I don't have a logic analyzer handy but after the holiday I
may find someone who knows how to use one. More importantly, do you have
suspicions about the solution? ;)

As another data point, I've found that performing the second receive at
different frequencies can bring the noise floor back to normal. If I
transmit at 2.48G and receive at 2.485G the noise floor is normal. With
some other RX frequencies, (I think 2.445G) the same problem persists.

- -Dan

Johnathan Corgan wrote:
> Dan Halperin wrote:
>> Just-powered on USRP rev 4.2 with RFX2400 rev 2-6-2006. Current SVN.
>>
>> usrp_rx_cfile.py -f 2.485G -d 8 -s pre.dat
>> usrp_siggen.py -i 16 -f 2.485G
>> usrp_rx_cfile.py -f 2.485G -d 8 -s post.dat
>>
>> In the first set of data, the noise level is what I'd expect and
>> everything works hunky-dory. After the siggen, however, it all goes
>> haywire, the noise floor becomes huge even though an adjacent USRP sees
>> nothing.
> 
> I wonder if somehow the USRP transmitter is getting left powered up.
> The mixer would be getting random noise and upconverting it to your
> passband.  This would feed through from the blocked side of the TX/RX
> switch (about 30dB of attenuation) into the receiver.
> 
> You'd have to measure the logic level at the mixer chip enable pin to be
> sure.
> 
> If this is the case, I have a suspicion about the cause.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHlOKoy9GYuuMoUJ4RAumXAKCv+cDlNFgGxorc7Wpwc4LNZ7ApWQCgxarx
SV6hXvvtbb2Bri+0XsHynHU=
=t3l7
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Problems when receiving after transmit

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I should add that I've duplicated this with multiple USRPs of different
revisions and different revisions of the RFX 2400 (the 12-26-2006
version as well). So I don't think I broke my hardware... I've also
duplicated it at multiple frequencies.

- -Dan

Dan Halperin wrote:
> Just-powered on USRP rev 4.2 with RFX2400 rev 2-6-2006. Current SVN.
> 
> usrp_rx_cfile.py -f 2.485G -d 8 -s pre.dat
> usrp_siggen.py -i 16 -f 2.485G
> usrp_rx_cfile.py -f 2.485G -d 8 -s post.dat
> 
> In the first set of data, the noise level is what I'd expect and
> everything works hunky-dory. After the siggen, however, it all goes
> haywire, the noise floor becomes huge even though an adjacent USRP sees
> nothing. See
> <http://www.cs.washington.edu/homes/dhalperi/random/pre_and_post.jpg>
> for graphs of the raw sample amplitudes.
> 
> Can anyone duplicate / explain this? Thanks!
> 
> -Dan

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHlD/+y9GYuuMoUJ4RAuWXAKCzQocG4GrfjBIkSQtow+s7fTbX2wCeJthO
PiMD8UFR4GQKmST96EjM7TA=
=T8aJ
-END PGP SIGNATURE-


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

[Discuss-gnuradio] Problems when receiving after transmit

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Just-powered on USRP rev 4.2 with RFX2400 rev 2-6-2006. Current SVN.

usrp_rx_cfile.py -f 2.485G -d 8 -s pre.dat
usrp_siggen.py -i 16 -f 2.485G
usrp_rx_cfile.py -f 2.485G -d 8 -s post.dat

In the first set of data, the noise level is what I'd expect and
everything works hunky-dory. After the siggen, however, it all goes
haywire, the noise floor becomes huge even though an adjacent USRP sees
nothing. See

for graphs of the raw sample amplitudes.

Can anyone duplicate / explain this? Thanks!

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHlD78y9GYuuMoUJ4RAk3bAJ9AONim3nGAapElcL5odPvyUww7tQCePGCM
3rmw0m3rTsKFgb1TYSb8H6o=
=25GS
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] choosing start of frame bits, studies?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

George Nychis wrote:
> Was the access code picked randomly, or was there some basic rule of
> thumb for generating it?  What about the threshold of 12?  What about
> choosing a 64bit access as opposed to 32bit?

Standards for access codes are interesting. The Barker spreading code
use in 802.11 1 and 2Mbps rates, for instance, is one of a set of
optimal codes where B (dot) B = |B| while
B (dot) (B rotated by any nonzero number of bits) = 1. This means that
if you're sliding a correlator along a set of Barker-modulated bits, you
get strong peaks at the correct offset and (basically) nothing at any
other offset.

Usually access codes have a property somewhat like that. I think the
nuances of this choice are strongly tied in, however, with what
modulation scheme you're using.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHh5/0y9GYuuMoUJ4RAny5AKCNQy0t5SY+sD0qwg5qpLfK9/jhmgCeLyDC
0Wf5PDIkwM8GDUZY0Aa0cmM=
=z/qB
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] URGENT (Requires immediate reply) PROBLEM: Can't make howto example.

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

You want to remove the installed files of GNU radio, you're going to
replace them from source.

- -Dan

Jonas wrote:
> Will I not remove the installed files of GNU Radio? Do I just remove its
> directory?
> 
> =)
> 
> On Jan 11, 2008 10:50 AM, Dan Halperin <[EMAIL PROTECTED]> wrote:
> 
> Jonas wrote:
>>>> Yes, I did that (with an added sudo, see below). However, error messages
>>>> appear as shown below.
>>>>
>>>> sudo svn co http://gnuradio.org/svn/gnuradio/trunk gnuradio
>>>> svn: REPORT request failed on '/svn/!svn/vcc/default'
>>>> svn: REPORT of '/svn/!svn/vcc/default': 400 Bad Request (
> http://gnuradio.org
>>>> )
> Try rm -fr gnuradio (i.e., removing the old gnuradio folder) first.
> 
> -Dan
>>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHht2Dy9GYuuMoUJ4RAgjuAJ9GgY4JKa9tktqVThc6iB9S78MQYwCbBdMW
1jOyokHn3sJNlQz+uV9k76o=
=APHk
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Question regarding vector_sink_c

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Wee Shinhan wrote:
> Hi eric, 
> 
> Thanks for the reply, i have connected it to the
> channel filters, i trying to do an estimate on
> wireless channel coefficient. Therefore i'm trying to
> capture the complex data received before
> de-modulation. I havent have much success using vector
> sink even when i set a range for the data captured,
> all doesnt seems right.
> 
> Is there any blks that will be useful for my
> experiment? Or do i have to write my own C++ blk to
> process my needs. Thanks again.

Look at blocks like gr.probe_* (ingnuradio/gnuradio-core/src/lib/general/)

These will tell you some properties of the raw signal (namely,
amplitude). Something like that might be the kind of thing you want --
you could easily write a block in a similar style that computed some
other metric.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHhXwmy9GYuuMoUJ4RAuInAJwO+boI3cmHIXW9S1c276Is3JcHCwCfdAYI
i8RL+rkXxQ6DZNnI/wQmKBE=
=uQ/3
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

sri ram wrote:
> P.S. I am attaching the output of the rx side.

uOok =  True  pktno =   47  n_rcvd =   48  n_right =   48
ok =  True  pktno =   48  n_rcvd =   49  n_right =   49
ok =  True  pktno =   49  n_rcvd =   50  n_right =   50
ok =  True  pktno =   50  n_rcvd =   51  n_right =   51
uOok =  True  pktno =   51  n_rcvd =   52  n_right =   52
ok = False  pktno =   52  n_rcvd =   53  n_right =   52
ok = False  pktno =   54  n_rcvd =   54  n_right =   52
uOok = False  pktno =   56  n_rcvd =   55  n_right =   52
ok = False  pktno =   58  n_rcvd =   56  n_right =   52

- --

The USRP Overruns (the 'uO's indicated above) mean that your computer is
not fast enough to process this data. Is the processor too slow? Are you
running other applications in the background?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHcA9ry9GYuuMoUJ4RAgAHAKDQ+eAYlPfur+vSr+OGdxrCZHbNSwCfWC/L
G7g4Eh02xuO44VpTl/KtFr4=
=CSgi
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] RuntimeError: audio_alsa_source

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brook Lin wrote:
> plughw:0,0 to record the FM radio to my computer. It gives me almost the
> same error: audio_alsa_sink[plughw:0,0]: Device or resource busy. Can you

Is some other application locking the sound card? An IM client, a media
player, even a browser? Also, are you in the relevant groups? (audio,
whatever)?

Incidentally, is your end goal to do something that involves sound? If
you're doing RF stuff alone and are only looking to test some basic GNU
Radio functionality, you might be better off skipping the ALSA issues
(which seem to be fairly common on this list and often difficult to work
out). You can use things like benchmark_tx.py and benchmark_rx.py to
test transceiver functionality, etc.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaDuZy9GYuuMoUJ4RAriAAJ9wwLgIVaQLJDbdtI6VYREW8Fot4QCff4iy
ZlPWYPl2LBcKBkvuZrhVkh0=
=umyT
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] GMSK receiver question, USRP tuning?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

George Nychis wrote:
> The decimation should not affect the amplitude of the waves, right?
> Which if you look at the graph, the GMSK receiver has ~4x the amplitude.

Actually, it may. Imagine you decimate by a factor of 4, that's sort of
like adding every 4 samples together -- amplitude grows by 4.

Now, I think there is (or there ought to be) some code that, at lower
decimation levels, shifts which bits of the register it outputs
(presumably, takes 2 more significant bits) to keep the amplitude
constant, but that code may not be there in your new version, or the
FPGA might do it differently that I imagine.

> I agree that the decimation has affected what looks like the frequency,
> but otherwise it should look the same and not affect my ability to
> decode it.  Something else seems different between test_usrp_standard_rx
> and the GMSK receiver.

If the decimation factor is not correct there's no way it's going to work.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaDWoy9GYuuMoUJ4RAqA+AKCxTe9CwmLMa+Q78nDQbVclZFeSLQCgzixz
s69aw69eVhxAf4j2cy1NUmo=
=MpH6
-END PGP SIGNATURE-


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

[Discuss-gnuradio] oprofile help

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

By default, oprofile tracks CPU usage of each process/function/whatever.
I'm trying to do some cache analysis now but I can't get it to change
events. My setup command looks like this (trying different events):

sudo opcontrol --setup --no-vmlinux --separate=library
--event=L2_RQSTS:10
--event=DATA_CACHE_MISSES:10
--event=L2_RQSTS:7500:0x7:1:1
--event=LLC_MISSES:7500:0x7:1:1

as taken from a bunch of different online sources and man pages.
However, when I run the profile command:

sudo opcontrol --reset && sudo opcontrol --start && ./mycode.py && sudo
opcontrol --stop

I still always get CPU_CLK_UNHALTED events. My CPU type is "Core 2". Any
suggestions? I've tried sticking the setup command after the --reset, to
no effect.

Thanks,

Dan

P.S. George and I were discussing setting up a Wiki page for general
OProfile stuff... it's not exactly straightforward. Would anyone else
like to contribute?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaCsFy9GYuuMoUJ4RAkD1AJ44Ctl5DKO01BuTpMwYlNDFr/vaEwCfeLVw
Iilao9jEM4bulA06n+Vsnwg=
=5AqV
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] GMSK receiver question, USRP tuning?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The default decim in the C++ program (which, IIRC, is deprecated) is 8.
What decim (what bitrate?) are you using for GMSK?

- From the graphs, it looks like data from the C++ app is coming in about
4x too fast.

- -Dan

George Nychis wrote:
> Hi all,
> 
> I'm using benchmark_tx.py to transmit a GMSK sequence at 10MHz.  As some
> of you know, I'm trying to debug my own GMSK m-block receiver.
> 
> If I use test_usrp_standard_rx -F 1000 (not the in-band receiver) to
> capture the incoming signal and plot it, I get the graph on the top, and
> if I dump the data coming out of the usrp1_source_c block when running
> benchmark_rx.py -f 1000, i get the bottom graph:
> http://www.andrew.cmu.edu/user/gnychis/std_gmsk.png
> 
> I can successfully decode the transmission with my receiver using the
> data output from usrp1_source_c and benchmark_rx.py ... however I cannot
> decode it using the samples from test_usrp_standard_rx.
> 
> So I'm wondering, what is benchmark_rx.py tuning on the USRP differently
> than test_usrp_standard_rx?  Of course, my goal is to duplicate this
> action because my in-band code is also dumping data similar to the top
> graph.
> 
> Thanks!
> George
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaCW8y9GYuuMoUJ4RAq6KAJ9x/+6giS5yTx0or7u+x7HdckW3jgCgtbfw
CaRXWRqSIabSD6HaqF2+loI=
=PZlq
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] I&Q on same or separate channels?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I suspect this comment:

http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/inband_lib/rx_buffer_inband.v#L120
"TODO write this genericly"

is where the interleaving should be done... maybe :).

- -Dan

George Nychis wrote:
> 
>>
>> I and Q are not on separate channels.  They are interleaved, I0, Q0,
>> I1, Q1...
>>
> 
> Are we sure of this?  Based on Brian's pointer to here:
> http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/toplevel/usrp_inband_usb/usrp_inband_usb.v#L235
> 
> 
> ... it seems as though they are wired to separate channels.  We then use
> them as inputs to rx_buffer_input here:
> http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/toplevel/usrp_inband_usb/usrp_inband_usb.v#L260
> 
> 
> ... but only ever read from channel 0 (I).
> 
> Is there a module we are missing that interleaves them?
> 
> - George
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYi/py9GYuuMoUJ4RAsv6AJ9BQiQXbuwj4zxo0XhiKfBa8AOQLACdGXcf
zBJa1RnYZ5ivm6PDvRCTHdk=
=9JGF
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] make check errors

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Johnathan Corgan wrote:
> On 12/11/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
> 
>> I see this as well now.  It can be attributed to a check-in on the trunk
>> 2 days ago that Martin did to fix an iir bug (r7089).  I suspect the iir
>> QA needs to be updated.
> 
> The changeset for r7089 has been reverted on the trunk.

I looked through that code and the formulas in the header file and did
the QA by hand and it seems that the reverted version is/was correct.
Perhaps there was an error forgetting to prepend a 0 into the fb_taps
that made someone think there was a bug?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHX2CZy9GYuuMoUJ4RAjKgAJ4l5cQ6B8vJUqyEbuMvZhfoQZRbSQCdFJTG
QiFBO/PjvRX1y96QvGT43Vs=
=x9HD
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Re-writing blocks using intel libraries

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eugene Grayver wrote:
> Please see answers in-line.
>   Which blocks are causing you the biggest problem?
> 
> I got a 2x improvement on all the filtering blocks.  About a 40% 
> improvement for sine/cosine generation blocks.  This includes gr_expj, 
> gr_rotate.

I should mention that gr_rotate's performance can be _greatly improved_
by a simple change that, rather than rescaling the multiplier every
iteration, rescales every k, e.g. k=1000. I think I have an earlier
mailing list post about this. IIRC, the patch didn't go in because there
seemed to be no consensus about what k to use...
> We would not accept the changes.  Part of what we're up to is building
> an ever expanding universe of free code.  Instead of using the
> non-free IPP code, please consider using a free library such as ATLAS,
> or help us find and fix performance challenges in a way that doesn't
> require non-free code.  Also, are you sure that your performance
> issues can't be better addressed with an algorithmic change?  If
> you're using a lot of very low-level blocks (e.g., add, multiply,
> etc.) you're probably better off writing a block that aggregates some
> of the operations into a single block.
> 
> That's what I expected.  We'll try to contribute the more dsp-centric 
> blocks such as demodulators. 

That said, if you put the code (and/or the modified makefiles) up
somewhere, I'm sure there are some users that would benefit even if it
doesn't make it into the main release.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHXyVQy9GYuuMoUJ4RAjSfAKDWVOeMbGteN+BQhl71tG5mo2D3CgCfdzCO
34TYmHjgnijbENsfxECZNwo=
=v01V
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wuest Brandon-WTVR47 wrote:
> I am having a problems with disk writing not being able to keep up with
> the high data rate, so I am trying to do a little manipulation of the IQ
> data to get around this.  What I am trying to do it get 8-bit samples
> from the usrp (which my disk can keep up with) and then before I feed
> that in to interp.py, I convert every pair of bytes to a complex.

A logical approach if your disk can't handle 32MBps linear write.

I'll answer question #0 first:

For converting pairs of bytes to complex, this might seem a bit (really,
a lot) silly, but a simple way to do it in GNU Radio would be

gr.file_source(gr.sizeof_char,"file") ->
gr.char_to_float() ->
gr.float_to_short() ->
gr.interleaved_short_to_complex()

You could also write a gr.interleaved_char_to_complex() block (which
appears to not exist in gnuradio-core/src/lib/general) which would be a
MUCH better solution but would require effort :-D.

> 1. What is going on with byte order?  From looking at the output of
> usrp_rx_cfile.py, it looks like everything is little endian, but if this
> is the case, I do not see where the ATSC demodulator converts little
> endian to big endian to ensure for cross platform compatibility  (the
> GNU Radio website does indicate that this is possible to run on windows
> and I have not found any information regarding byte order concerns).  I
> am running Ubuntu on an x86 processor which is big endian and it sounds
> like most users machines are big endian, so is there some conversion
> going on or am I just reading the output of usrp_rx_cfile.py incorrectly
> (when set to stream complex floats)?  Or is it that the USRP does send
> down floats in little endian and the ATSC demodulator expects that the
> input is of the same byte order of the machine it was compiled?

Source files are assumed to be in local-Endian, and sink files are
created local-Endian. Cross-platform is in the eye of the user :-D.

Also, I challenge your assertion that Ubuntu on an x86 processor is big
Endian. Endian-ness is a function of the architecture (except some crazy
and/or cool chips that have an Endian-switch like I think some older Macs).

> 2. What are the float values expected by the ATSC demodulator?  In other
> words, what is the expected range of each float?  Should they all be in
> the range (-1,1) or (0,1) or (min float value, max float value) or
> something else?  It looks like the floats are all bounded to 2 bytes and
> the higher two bytes are just not used.

No idea

> 3.  When converting an 8-bit sample to a float, do I need to scale it or
> just cast it to a float?  So if I have a byte with the value of 100,
> could I just something like "scale = 100/255;  i = FLOAT_MAX * scale?"
> Looking at some of the conversion methods included, it seems that a char
> gets simply casted to a float, but I believe this would have a negative
> effect since it causes all the amplitudes to appear weak.

Usually you'd just cast to a float. The demodulator should presumably
handle low-amplitude signals. But see my answer to (2).

> 4. When I specify 8-bit samples from usrp_rx_cfile.py, are these bytes
> signed or unsigned?  I find this important because if I want to scale
> each byte to a float, instead of just casting, I would possibly need to
> do some bit masking to account for this.

Signed.

Good luck!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHTzlty9GYuuMoUJ4RAvDdAJ0ez/tzvBN4WYBM54dqsus2jSbo3gCgm3pv
ot0SaQ5gcSorrETliLcaulI=
=t79U
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Spurious samples in data set??

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please don't send attachments to the GNU radio mailing list.

It's a known issue that the USRP sends some spurious large amplitude
samples right after it is enabled. You can safely ignore them.

- -Dan

Aadil Volkwin wrote:
> Hi
> 
> Attached is code i've used to write a signal to file and subsequently to
> plot the samples.
> additionally i've attached the plot.
> 
> Can anyone tell me what may be causing the huge spike at the beginning
> of the data set?
> 
> thanks,
> 
> Aadil
> 
> 
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMEtPy9GYuuMoUJ4RAtfhAKCFRqkynXeqpy5hnjDjcN0ng4QFAgCfdIZ0
/lZ8rLac2o4PpbiwjsQEoEY=
=0Hxx
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Encoder Integration

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Padalino wrote:
> On 10/29/07, Achilleas Anastasopoulos <[EMAIL PROTECTED]> wrote:
>> PS: I have mixed feelings about all this being implemented on the FPGA:
>> is this a software or a hardware radio?
> 
> In terms of GNURadio, I can agree with the mixed feelings.  I feel
> that GNURadio is a good framework to explore the spectrum and radio
> communications systems.
> 
> In terms of software radio, reprogramming an FPGA with a different
> bitfile is no different than changing a flowgraph, in my opinion.  The
> only thing really hard in the chain is the RF front end for grabbing
> the signals.  It's all "software" from that point on.

Agreed!

> In all honesty, I wouldn't mind if the FPGA were more flexible at
> compile time and less flexible at runtime.  I feel this would trim
> away some of the "fat" associated with being so flexible at runtime,
> and allow for better use of the USRP's FPGA for more low latency
> processing.

In order for SDRs that think of their FPGA code as software (which I
think has to be where this is going to realize its full power), it seems
likely that we will need completely automated and reasonably fast ways
to rebuild the FPGA on the fly. Do these exist?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJhu2y9GYuuMoUJ4RApLhAKC2gVlZYHQeANpbQKTPyr9HfzE6bgCfa7Qd
Zc1C/VJSOgL08B4r/VIrW1Q=
=dQRO
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] BBN module

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think the answer you want is:

cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel

then ./bootstrap && ./configure as you wish from the gr-bbn subdirectory.

- -Dan

Mohammad Hamed Firooz wrote:
> 
> Hi everyone,
> I am going to use BBN code on IEEE802.11b. But these codes need to
> import a module named bbn from gnuradio package. My gnuradio has not
> this module. Where can I find it and how I can add it to my gnuradio
> package.
> 
> Thanks
> hamed
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHHkSCy9GYuuMoUJ4RAut+AJsFGyVhyBc3va/0kozYynJ6FDJR2ACdGpLT
WH0T1Yc5qPMuC9cFso0oyv0=
=gmsI
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] the in-band timestamp

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

My 2c:
I imagine that futuristic uses of the USRP (such as the ones for which
you're explicitly redo-ing the stack) involve dynamically changing the
decimation on the fly. Drive it off the absolute clock to keep some
sense of meaning.

- -Dan

George Nychis wrote:
> Okay, Brian brought this up to me in an off-list discussion that we
> think needs to be discussed about the current timestamp generation.
> 
> Referring to:
> http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/inband_lib/rx_buffer_inband.v#L37
> 
> 
> The current timestamp runs at the decimated rate, when we're tossing it
> up for discussion if it should be driven from the free running 64MHz clock.
> 
> Leo and I are in the middle of implementing/debugging some other
> functionality that I want to finish before touching this, but it's worth
> discussion ahead of time.
> 
> - George
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHHTX1y9GYuuMoUJ4RAs9UAJ0Vfz9vvGy5AdaiL0XphP721hodIgCeINaV
480gAWFq0nHaDTp5v8gRcEw=
=ioAZ
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] saturation with multi_fft.py

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Padalino wrote:
> The CIC filter has some bit-growth associated based on your decimation
> rate.  This growth is deifned for decimations up to 128 in that file.
> It basically takes a different "slice" of the CIC "comb" section at
> the end.
> 
> The reason it might be happening in the FPGA that doesn't have the
> halfband filter is because the halfband filter also decimates by 2 -
> so you would need 1/2 the decimation by the CIC.  So for cases where
> you would normally decimate by 192, the CIC is decimating by 96 and
> the halfband by 2.  In the case where there is no halfband, the CIC
> takes on all the responsibility and the extra growth is not accounted
> for.
> 
> If this was defined for values larger than 128, then the growth
> wouldn't happen and it could all be alleviated in the FPGA.  Hopefully
> this makes sense to everyone.

... and since the maximum USRP decimation is 256, 128 is the most you
would need in the CIC for the standard RBF... and no one ever got around
to/realized it needed to be done for higher decimation values when the
halfband is turned off? Seems logical.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDTuJy9GYuuMoUJ4RAhwQAJ0ekPL6P/9KFdga9KGBb1SIuNQRWACdHYxx
Q1HO5u+HBERTf/B6mlXJGtc=
=copS
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] RFX2400 using 2.4-2.48GHz Patch antennas

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In my experience the USRP stops performing very well at low bitrates.
This is due to the current code's inability to handle large frequency
offsets when the symbol period is that long.

Try it at 250kbps/500kbps.

- -Dan

Joseph Crowley wrote:
> Joseph Crowley wrote:
> 
> Hey,
> Just purchased a couple of RFX2400 transceiver dboards as well as a couple of 
> patch antennas (WA5JVB) and tried running the benchmark program from one USRP 
> to another (both mounted with the RFX boards). However it didn't seem to 
> work. I tried looking for a spike using the fft on the receiver USRP but 
> found only a spike at 2.4GHz (from surrounding wireless hardware) which didnt 
> change during transmission (using benchmark_tx.py). Was just wondering what 
> the problem is if anyone else has encountered it. i.e. is it a problem with 
> the boards? Or antenna? Or is it a problem with the benchmark script?
> 
> Thanks
> -Joseph Crowley
> 
> 
> You'll have to provide more information than that. Which benchmark script and 
> what were the parameters? What was the setup of the experiment (TX-RX 
> distance)? Have you successfully run other GNU Radio applications? Try 
> usrp_siggen and usrp_fft.
> 
> Tom
> 
> The commands being used are:
> 
> ./benchmark_tx.py -f 2.4G -T A --tx-amplitude=1 -s 1000 -r 1 -v -M 5
> 
> ./benchmark_rx.py -f 2.4G -R A -r 1 -v
> 
> used rate of 1 just to set to lowest possible bitrate (for gmsk 35 kb/s)
> 
> Distance have ranged between 1 - 2 metres.
> 
> When using usrp_fft.py on the receiver the transmitter Rf power is showing on 
> the display (pretty large >10db gain from the noise floor).
> 
> Problem now is the receiver is not receiving any packets.
> 
> Thanks 
> Joseph Crowley
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/RAyy9GYuuMoUJ4RAqBdAJ9uTMty7BJggTS8V0LMucwOxGrDgwCfZQ6X
EkrvwevpHy2AaL6lOA110Cw=
=4uoU
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Capturing 12-bit data at 10MHz sample clock?

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It'll involve hacking the FPGA code, but no, it shouldn't be especially
hard.

- -Dan

Jan Schiefer wrote:
> This may be a dumb question, but suppose I changed the USRP ADC clock to
> 10MHz. Would there be a way to get 12-bit integer data across the USB,
> using usrp_rx_cfile.py or something similar? This would result in a
> manageable USB transfer rate of 30MB/s and line up pretty well with the
> bandwidth of the TVRX tuner.
> 
> From poking around, it appears to me that the data transfer across the
> USB is either 2 * 8 bits/sample or 2 * 16. 2 * 12 should be easy enough
> to disentangle?
> 
> Just curious,
>Jan
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG84yay9GYuuMoUJ4RAvjhAKC+VoYbVeE+iakEsoaGvkSjjEvjLwCghgP0
gdhp/Qk4wWoxs+BAo0ZHNjc=
=oQqz
-END PGP SIGNATURE-


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

[Discuss-gnuradio] GNU Radio multicore support

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Old documentation on GNU radio says that it would have transparent
SMP/multicore/SMT support for signal processing by version 2.x; on 20
March 2007 Marcus Leech sent an email claiming

"""
Eventually, Gnu Radio will support multi-threading for processing blocks
that are particularly expensive, I think, which will be much more useful
on multi-core CPUs.  Currently I think only the signal processing and
Gui chains are in different threads.
"""

Is this still true (I certainly don't see SMP use on my two multicore
machines), and if so what has prevented this from happening?

Thanks,

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6u/hy9GYuuMoUJ4RArs/AKCgUY/HUdnqWDIdOnjMMylryGzscACfVN3a
o+NjcO7eRoeIkk9DhxqdaUE=
=lzkn
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Berndt Josef Wulf wrote:
> G'day,
> 
> building current source results in an error due to missing file gr_runtime.i. 
> It appears runtime.i was renamed to gr_runtime.i which was missed in the 
> trunk.
> 
> cheerio Berndt
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

See Johnathan's email of 8/27/2007 11:50 AM PDT:

""
One of the changes is that there are no longer any gr_runtime.* files as
this class has been removed from the code as part of an API change.

However, due to the somewhat broken way we handle SWIG dependencies, a
reference to gr_runtime.i remains in the machine generated dependency
files (gnuradio-core/src/lib/swig/*.d).

This will cause an *already compiled* local copy of the trunk to fail
compilation once it is updated with the latest repository revision.  It
will *not* affect any freshly checked out copies.

If you run into this issue, you can either:

1) Edit gnuradio-core/src/lib/swig/*.d and manually remove the line that
references gr_runtime.i in each one, -OR-

2) Delete gnuradio-core/src/lib/swig/*.d and then run ./config.status
from the top-level directory, -OR-

3) Check out a fresh copy of the trunk and rebuild (simple but overkill.)

Patches welcome from anyone who has a better way of automating tracking
of SWIG dependencies that doesn't create the above issue when a
dependent file is removed.
""

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5avwy9GYuuMoUJ4RAgNhAKDLpORX1kwaKdWiQFFJSSdTD9X90wCfYljT
0+2WiQlUQr0Rvvu8IsZsKyU=
=3hea
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] What is the range of USRP complex sample values

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The maximum (at 16 bits complex samples) data rate across USB on the
USRP is 16 MHz; hence the minimum decimation rate of 4. My understanding
is that this decimation gives more bits -- since you're combining 4
samples together, you can now extrapolate between 12-bit ADC samples for
a higher resolution. So the min/max data range for complex data from the
USRP is -32768/+32767, the full range of the 16-bit short coefficients.

- -Dan

Bahn William L Civ USAFA/DFCS wrote:
> For complex IQ data values, what is the min/max range both for data coming 
> from the USRP and data sent to the USRP?
> 
> There are three obvious guesses:
> 
> 1) Normalized to +/-1.0.
> 2) Direct match to the ADC/DAC ranges.
> 3) Normalized to a nominal ADC/DAC range.
> 
> The first is right out since the values coming back are typically much, much 
> larger than that.
> 
> The second would result in the RX range (which uses a 12-bit ADC) being 
> either 0 to 4095 or -2048 to +2047 while the TX range (which uses a 14-bit 
> DAC) would be either 0 to 16383 or -8192 to +8191. However, while I see both 
> positive and negative values in the RX data stream, I also see values that 
> are well above even the unsigned range.
> 
> This leads me to suspect that the data is being normalized to signed 16-bit 
> values in both directions yielding a range of -32,768 to +32,767 by the 
> simple expedient of left shifting the ADC output by four places and right 
> shifting the DAC output by two places (with sign extension, of course). This 
> seems reasonable as it would make migrating to higher (or lower) resolution 
> ADCs and DACs transparent, at least until devices with greater than 16-bits 
> of resolution are used.
> 
> Is that correct, at least where the useful range of values for complex IQ 
> data is concerned?
> 
> Thanks.
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5PjEy9GYuuMoUJ4RArIrAKCP1fZFwOapnVVXssqgzi2afVWb4wCgrDfS
KBP1t/HGT4QXieKTx63B9R8=
=uztu
-END PGP SIGNATURE-


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

[Discuss-gnuradio] Freq_xlating filter parameter

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The comment for the filters gr.freq_xlating_fir_filter_XXX says (about
the parameter "center_freq"):

/*!
 * Construct a FIR filter with the given taps and a composite frequency
 * translation that shifts center_freq down to zero Hz.  The frequency
 * translation logically comes before the filtering operation.
 */

This implies that the frequency shift should be -center_freq, right?

I think I'm observing the opposite; that is, you pass in the desired
shift. All examples I can find that use this block pass in 0 as the
frequency shift; does anyone else have experience with this block that
can confirm or deny this?

Thanks!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG4Iypy9GYuuMoUJ4RAujGAJ0Rqnx8tyQvLabBtS6qe95oJn/gIwCgmF0Y
EwRcHt95AAVwYtWh+m96tg8=
=OfSO
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] multi-band receiver

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Johnathan Corgan wrote:
> For the receive side, you can use a blks.analysis_filterbank to turn a
> wideband signal with N carriers into N baseband channels equally spaced.
> 
> Then you can attach demodulators to these output ports.
> 
> This is demonstrated in the gr-pager code:
> 
> http://gnuradio.org/trac/browser/gnuradio/trunk/gr-pager/src/usrp_flex_band.py
> 
> Here we capture 1 MHz of USRP spectrum, then create 40 baseband output
> channels at 25 KHz each, then attach 40 decoder blocks to these outputs.

In this example (and indeed, in the code for the analysis_filterbank),
we divide a 1MHz band exactly into 25 kHz channels. However, the
channels at the edge will be attenuated (cite: Matt's email of yesterday
12:11 AM PST). I therefore oversampled the desired passband by 33%,
which causes the resulting wideband signal to not divide evenly into
channel-sized chunks.

If I do some sort of 3/4 resampling should the passband quality suffer?

Thanks!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3wbey9GYuuMoUJ4RAvvUAJ9W9PeZG+mTA1Nlwl3YGZgdG8NrzACbB+Ue
yznc+0nwbfB9J0APeR0mcFw=
=5v5I
-END PGP SIGNATURE-


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

[Discuss-gnuradio] multi-band receiver

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey all,

I'm trying to receive, and send, traffic on a fixed but unknown carrier
frequency within the passband of the USRP. That is, there are many
communication bands, but transmissions happen on only one of k channels.

The trivial approach is to have one translating filter, with a channel
select filter, for each channel and hook them all in parallel to the
receive chain. Then to respond I can have k different callbacks, one for
each channel, which will cause response packets to be sent to one of k
different transmit paths corresponding to the different channels.

Does anyone see a more elegant way to do this? I can imagine that using
an FFT I can discover on which channel a transmission occurs, but AFAIK
there's not a good way for one GNU Radio block to tune another (e.g.
tuning the xlating filter with the FFT).

Thanks!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3vQly9GYuuMoUJ4RAhPXAJ9exiukAgmQt+9CVpXdfXsQZaE4sQCgr3Bv
6w5inh3rPkeSjglh9FeAgHA=
=ERpu
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] frequency ranges for basic tx/rx d'boards

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Note that Matt has claimed in the past (and I've partially verified)
that the Basic boards can go as low as about 100kHz.

- -Dan

Brian Padalino wrote:
> On 8/23/07, George Nychis <[EMAIL PROTECTED]> wrote:
>> Hey all,
>>
>> I'm slightly confused.  I'm trying to find an antenna to use with the
>> basic TX/RX boards to transmit and receive over the air.  What frequency
>> ranges do the basic TX/RX boards do?  After checking the wiki, it just
>> says "baseband."  Doing some research, I think it means a band of
>> frequencies starting at 0 to the highest frequency.  Up until now I've
>> just been using coax, so it hasn't really been relevant.  So what's the
>> highest so I can determine what antennas to purchase.
> 
> Apparently when I put that page together I never noticed the description here:
> http://www.ettus.com/downloads/miscdboards_v3b.pdf
> 
> Which states the Basic series of cards are 1MHz - 250MHz (not baseband
> due to the transformer coupling).
> 
> I've updated the wiki pages to state the correct frequency range and
> description.
> 
> Brian
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzbway9GYuuMoUJ4RAmD/AJoCyZDODoktuBmO9U2wIsSmg8BBAwCdGy9r
1M6plUVynz2BNqShxYFC6E0=
=mTHJ
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Problem with 8-bit option and dropped samples

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lisa Creer wrote:
> On 8/20/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 20, 2007 at 11:15:36PM -0400, Lisa Creer wrote:
>>> I'm testing the -8 option in various example programs, and haven't been
>>> successful in receiving valid data.  The following test resulted in a
>> very
>>> brief, flat line being displayed, then absolutely no data showed on the
>>> graph, but the program continued to run.
>>>
>>>  ./usrp_fft.py -f 100M -d 4 -8
>>> format = 0x288
>>> set_format = True
>> Have you tried increasing the gain?
> 
> 
> Yes, to no avail.
> 
> What daughterboard are you using?
> 
> 
> Basic Rx.
> 
> Do you have an antenna connected?  If so, what kind?
> 
> 
> Yes.  My antenna ignorance will become apparent here, it's what I'd call a
> basic antenna (non-telescoping), vertical antenna 14 inches tall  with a
> strong magnet on the bottom.

This sounds like it's the wrong length to pick up FM stations.

>> I decided to try decimating by 4 without specifying the 8-bit option, and
>> I
>>> received the 'uO' indicating that samples were dropped from the USRP to
>>> host, but data was displayed on the graph, and it was 16MHz
>> wide.  What's
>>> going on?
>>>
>>> ./usrp_fft.py -f 92.7M -d 4
>>> uOuOuOuOuOuOuOuOuOu
>> 64 MS/s / 4 * 4 bytes/S = 64MB/s.  This won't fit across the USB,
>> hence the continuous overruns.
> 
> 
> Wait, I thought the -8 option provided 8-bit  I and 8-bit Q across the USB.
> It sounds like you're saying the samples are still 4 bytes total (2 byte
> each I and Q). So the samples are converted to shorts AFTER they get to the
> host? Then how can we decimate by 4 when using the -8 option? How can we
> cram more data through the USB if it can only handle 32 MB/s?

This calculation is in reference to your immediately preceding run
without -8. With -8, the samples are indeed 2 bytes total, not 4.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGy4/cy9GYuuMoUJ4RAkTCAKCGmZ841O0bj9nsY8mUm6gDVsFJvQCfeWrM
sNFi25ix/mZKSmUrhrGX4Mc=
=D3MK
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Integrate Click Router and GnuRadio

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think Hydra at UT does this.

- -Dan

George Nychis wrote:
> A couple students did this for their master's thesis here two years back
> I think.  Peter had e-mailed me their report, I'm hosting it for you:
> http://www.andrew.cmu.edu/user/gnychis/SDR-PRS-Final.pdf
> 
> I have access to their thesis too, but they're just long drawn out
> versions of the short paper :)
> 
> You may want to try contacting the student authors on the left before
> contacting Peter.  If you can't get a hold of any of them let me know
> and I will ask Peter in my meeting with him this week about access to
> their work.
> 
> https://www.cmu.edu/directory
> 
> It's public information.
> 
> - George
> 
> 
> Li, W David wrote:
>> Hello,
>>
>>  
>>
>> Has anyone done this integration before? My first question is both
>> Click and GnuRadio are in C++ so it would not be hard (in theory) to
>> do so. But I haven’t seen an example of calling GnuRadio APIs in C++.
>> All of them so far are in Python. Is this true? 
>>  
>>
>> -  David Li
>>
>>  
>>
>>
>> 
>>
>> ___
>> 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGyk5Oy9GYuuMoUJ4RAhQ5AKCMpSGtkNDuPai6zKjLb0PfPvWkuACfdLSA
TxuESxLXtVTaRPF/3xvz/dY=
=7MU3
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] USRP hardware purchase

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The USRP has a maximum bandwidth of about 16 MHz (using 8-bit samples
instead of the usual 16), which is not even enough to cover one
802.11b/g channel (22 MHz Nyquist). Thus you'll have a hard time
decoding b/g packets at faster than 1,2 Mbit rates (BBN has done some
work facilitating the recovery of these packets).

On top of that, an (extremely, I think) optimistic lower bound for
latency in a GNU radio system is over 1 millisecond from the RX antenna
through the FPGA over the USB to the computer to your software back over
the USB and out the TX antenna. This makes it _reallly_ hard to get
the 10 _microsecond_ turnaround required for an 802.11b ACK, and carrier
sense is meaningless with such a latency.

Also, see Tom Rondeau's email of 12/05/2006 for more comments, but the
short of it is that you're unlikely to be able to get any sort of
reasonable interoperation between the USRP and commercial 802.11b/g
hardware.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGw67By9GYuuMoUJ4RAqhgAKDENetmsE0mIa9dw3JyE787xo8KMQCfX+Pf
Odcvnn/HpAQ8PDahyfKt0Fo=
=Hre7
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] File format question

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bahn William L Civ USAFA/DFCS wrote:
> Thanks, that helps some.
> 
> I figured that I could put in the literal size of the data, in bytes, but 
> that only helps if it actually matches how the GR blocks are going to process 
> those bytes.
> 
> When possible, I would prefer to use the constants that have been set up so 
> that the code is (1) more readable, and (2) more maintainable. So instead of 
> using "8" for complex, I would like to use gr.sizeof_"whatever". But I don't 
> know what "whatever" needs to be. Where do I find this?
> 
> I'll look at dbpsk.py and tunnel.py when I get my Linux box set back up. Is 
> there a module that takes time domain data and converts it to IQ pairs, or am 
> I responsible for doing that when I generate the file? If so, what LO 
> frequency would I need to use?
> 
> It would be so much simpler if I could just use the generated time domain 
> data directly.
> 
> Thanks!

From
/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py:

sizeof_char = _gnuradio_swig_py_runtime.sizeof_char
sizeof_short = _gnuradio_swig_py_runtime.sizeof_short
sizeof_int = _gnuradio_swig_py_runtime.sizeof_int
sizeof_float = _gnuradio_swig_py_runtime.sizeof_float
sizeof_double = _gnuradio_swig_py_runtime.sizeof_double
sizeof_gr_complex = _gnuradio_swig_py_runtime.sizeof_gr_complex

Those are the constants you want.

When you say generated time domain data, are you talking about (time,
voltage) pairs off of a scope? IIRC scope data is just the I component,
and you can get the Q component from I using standard signal processing
techniques assuming your sampling rate is sufficiently high.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGw4oAy9GYuuMoUJ4RAl6xAJ44btFqFjVOvdVvACG0e/0XUQEN7QCeMFBD
ftSTrvnSYrU2sPjn6hC7PeM=
=dMQB
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] File format question

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bahn William L Civ USAFA/DFCS wrote:
> I have a few questions, but they mostly come down to: What is the data file 
> format when using a file as a signal source?
>

These file_sink and file_source are direct wrappers for the C functions
fwrite and fread and behave exactly as they do. A file is therefore
simply a binary containing {chars,shorts,ints,floats,etc} in
local-endianness.

> Question #1: What is the syntax for the itemsize argument?
> 
> Since the example doesn't use one of the data types mentioned, it is hard to 
> tell what the syntax is supposed to be. For instance, if I want to use 
> gr_complex, do I specify gr.sizeof_gr_complex? If I want to use unsigned 
> char, is it "gr_sizeof_unsigned_char" so as to eliminate the space?
> 
> Question #2: What are all of the options for the itemsize argument?
> 
> It lists "gr_complex", "float", and "unsigned char" yet the example uses one 
> that is not in the list. Are there others?
> 

Itemsize is the size, in bytes, of the object to be written. Valid
useful values are 1 (char), 2 (short), 4 (int/float), 8 (complex);
although I suspect you could put anything fwrite/fread accepted in there
and it would work.

> Question #3: Does the data file format for transmitting match the data file 
> format when receiving?
> 
> Can I take a file that is recorded, say using receive_file_c.py (may not have 
> the file name exactly correct) and use that as a source without modification? 
> If so, what does it mean to use IQ pairs as input data? What does the USRP do 
> with them?
> 

Yes. When I'm working on building a receiver for a certain modulation
scheme, for example, I transmit some data and run usrp_rx_cfile.py on
the receiver, then use a gr.file_source block as input to my receiver
blocks to allow for reproducible testing without polluting the airwaves.

Similarly, you could if you wanted generate a file to transmit by using
a file_sink instead of a usrp_sink and then send it across the USRP with
a file_source -> usrp_sink.

The I/Q pairs are processed by the USRP from files the same way they are
from a normal GNU Radio block such as e.g. the DBPSK modulator (see
dbpsk.py, tunnel.py).

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwhxHy9GYuuMoUJ4RAstQAKC+k5g89aTnmXZsjU9ctb6sqjtCoACgjuCz
18oDQYVVTNeDL4Tx+SV+VQk=
=HBOu
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hsin-mu Tsai wrote:
> On 7/25/07, Dan Halperin <[EMAIL PROTECTED]> wrote:
> I removed all the USB devices from the computer when I was doing the
> experiment. The benchmark script said 32 MB/s throughput can be
> achieved.

Sorry I reread your original email, ... you're now using settings where
the there are no more (or very few) USRP overruns? Is that correct?

In that case it's not the overruns, it's the detector. I suspect there
is too much noise or the gain is set wrong. What reason do you have to
believe that 20% packet loss is not expected? What's the SNR?

Especially at large symbol rates (like 2MHz), there is no reason to
expect that the error performance would be 0% packet loss without
actually knowing the SNR.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp7F8y9GYuuMoUJ4RAs0NAJ9aJsmUF3rgDxThFx1zoP69YDtdBgCfZC5f
QgZU75H7Hs2QGZkYMmkDZ9E=
=XqAu
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hsin-mu Tsai wrote:
> 2. I guess I wasn't very clear in my first e-mail. I tried two
> different kinds of setting with file_sink and file_source:
> 
> a)  TX_blocks -> usrp_source -> usrp board 1 ---physical_channel--->
> usrp board 2 -> usrp_sink -> file_sink
> then decode the signal with
> file_source -> RX_blocks
> 
> b) TX_blocks -> file_sink
> then decode the signal with
> file_source -> RX blocks
> 
> a) still has similar results while b) has 0 packet loss. a) doesn't
> involve real-time decoding (the CPU should have ample time to work
> with the data), but it still has a lot of packet losses.



> One of the weirdest thing is that even when I'm using only usrp_source
> -> file_sink, I can still have a lot of uO when using certain
> fusb_nblock and fusb_block_size setting (and I believe my machine is
> fast enough. I even tried saving the data to a file on the ramdisk).
> How does these settings affect the probability of USRP overrun? If I
> want to avoid samples being dropped, what setting should I use?

Yeah, it sounds like it's not CPU or disk overhead then -- how about
USB? I don't know much about the fast usb settings -- search the archive
for comments from wiser minds than I -- but you should definitely pick
settings that are free of 'uO's.

IIRC 802.15.4 is a 2 MHz (if you think of it as QPSK at twice the symbol
rate, that is) modulation scheme so this is going to be testing the
limits of USB if you sample at 2 4, or 8MHz complex (8, 16, 32 MBps
respectively). Have you benchmarked your USB speed (I think
gnuradio-examples/src/python/usrp/benchmark_usb is the accepted way to
do so these days)? Are there other USB devices attached to the computer?

>> Also, just to make sure, when you connect two USRPs directly make sure
>> to use sufficient attenuation (~40dB I think, check the archives for
>> emails from Matt Ettus for the actual number) with any of the RFX boards
>> to avoid damage to the receiver!
> 
> That's good to know! (I didn't know this.) Is there anyway to make
> sure that my board is not damaged?

Not my area.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp6pSy9GYuuMoUJ4RAtiMAJ4gjAyXOa/Bsb1+/EHp1T6ncV4NYACfcqCn
6JADdFcKteA56Fdp+VDAib8=
=3AXS
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> One interesting thing I noticed is that when I increased fusb_nblock
> and fusb_block_size, it shows a lot of buffer overrun ('uO'). When I'm
> using the default setting, these uO disappear. Why is this happening?
> However, the packet loss ratio are high in both cases. And I also
> tried enabling real time scheduling, but it doesn't have much
> effects.

uO means "USRP Overrun". That is, the USRP is sending data to the
computer faster than the computer can handle it. This probably means
that you are sending at too high a data rate -- the online decoder is
taking too much CPU. When you start logging with the file_source, then
this CPU (and memory, etc) overhead disappears and all samples are
logged. Then when the decoded samples are replayed, your receiver has
ample CPU time to work.

Fixes to decrease CPU load are:

1) Decrease the data rate (you tried this, and it worked!)
2) Insert a pwr_squelch_cc block with gating on to decode only packets
and not all random noise. Note this requires some parameter tuning to
get it to work properly.
3) Optimize the receiver.

Once you've eliminated the uO's, if there are still packet losses, note
that the default GNU radio receivers are not perfect or even necessarily
that great... there might just be some problems recovering from the
default channel distortions. Finally, you can also play with the gain on
each end to attempt to improve the SNR. Which modulation scheme are you
using with which boards at which frequency?

Also, just to make sure, when you connect two USRPs directly make sure
to use sufficient attenuation (~40dB I think, check the archives for
emails from Matt Ettus for the actual number) with any of the RFX boards
to avoid damage to the receiver!

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp55My9GYuuMoUJ4RAthfAJ9/euUrNbUVop+8y0z7ExWmP+uz4QCggR+i
EFcrFGwCGcdrIQKNCt6aGuU=
=O/Dh
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] File usrp_rx_cfile.py

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The data is packed binary data. Each complex samples is stored as 8
bytes, 4 bytes I as a float and 4 bytes Q. You need to use a binary
program to read these files. See read_complex_binary.m for MATLAB code
and the exact same syscalls translate directory into a C program to do
the same thing.

- -Dan

David Lindberg wrote:
> Hello,
> 
> 
> I e-mailed this list last week and have had some issues trying to get the
> file usrp_rx_cfile.py to give me a proper output.  The readme file says
> that
> the output is "single precision complex float values".  Honestly I do not
> know how to convert this data to a proper text that I can analyze.  The
> output file that is written is just a bunch of 'NUL' values when read in
> Notepad++.  When I read it in regular notepad, it is a similar garbled
> message.  The file can be found at this link:
> 
> 
> 
> 
> Please let me know if you have any information in reading this output.
> 
> 
> David Lindberg
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp51Dy9GYuuMoUJ4RAohwAKCM60Ze1XaaZprksEPkTYEBG/+VjgCgyGBN
NWckaooTJlOkB/cRtF70IVI=
=WfU0
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] a question about configuration

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dong Li wrote:
> found four of them can't pass the configuration checks:
> gr-audio-jack
> gr-audio-osx
> gr-audio-portaudio
> gr-audio-windows

You only need these modules if you plan to be using your sound card with
signal processing. The specific configuration errors might tell us more
about what problems you have compiling, but unless you're planning on
building a sound-based application you don't need them.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGl8Q2y9GYuuMoUJ4RAv15AJwL8cWXlXUbCV0+b6kpW9pia2H3dwCdH6QS
VJUlbQvUZHSlTxjSMBmA0UM=
=vs2j
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Demodulation problem

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

pratik hetamsaria wrote:
> hi..
> fg.connect(self.dst,self.chan_filt,self.packet_receiver)
> where self.dst refers to the new file which i want to demodulate.
> 

That should work, as long as self.dst is actually a file _source_ not a
file sink. And the file is in the right format -- have you verified that
the MATLAB code does what it's supposed to?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGkcICy9GYuuMoUJ4RAv9wAJoCxMKVVEoSWUBYY2HynL3iUhjdgQCfZAem
fpbhFlxK1W/oV8TmE5MAJz4=
=Mgta
-END PGP SIGNATURE-


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

[Discuss-gnuradio] delay in tx chain

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've asked a similar question before, so please try and bear with me :).

Is there a way to calculate the delay of all blocks after yours in a
chain? It might be as easy as summing up the histories of all of the
blocks...

As an illustration of why we need this, consider that the filter blocks
often set_history equal to the number of taps. This means that as soon
as a single sample gets sent through, they can begin emitting data.
However, the data that they emit isn't useful -- not until the filter
block is full of samples. If we're streaming, this is fine, a minor delay.

However, packet-based applications send a message and then switch back
to RX mode. The upshot of this is that the ends of packets will get
stuck in the filters and not get pushed out until the next data packet
comes through. This (not end-of-packet-ISI) is why we have to append at
least one nonsense byte to the end of a packet in order to make the CRCs
match, and why that end-of-packet error is deterministic rather than random.

A fix seems to be to appending a number of additional samples (maybe
zero samples) equal to the total pipeline delay to a message in a
message_source. Do we have the facility to do this? Other suggestions?
Comments?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjUNoy9GYuuMoUJ4RAkRhAJ4+duozGplcFxHmiz+qNP7N7m/0CACdGGQ7
Zz8uuwOFeA57mKvf+fy4on8=
=irgt
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] File source woes

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There is a gr_throttle block that you can use to rate-limit your data. I
think the only rate-limiting going on here is CPU time.

- -Dan

John Bratteli wrote:
> I'm attempting to write a script, based on
> usrp_fft.py, that will read a file of gr_complex and
> display it.  It works, except that it plays back much
> faster than it was recorded.  For example, I recorded
> a five second file and gave it to my script.  It
> looked to be correct data, but it finished playback in
> less than a second.  Here's the essential code:
> 
> self.input = gr.file_source(gr.sizeof_gr_complex,
> options.filename, options.loop)
> 
> adc_freq = 64e6 #inherent to USRP
> decim_rate = float(options.decim) #whatever decimation
> rate used in recording
> 
> input_rate = adc_freq / decim_rate
> 
> self.scope = fftsink.fft_sink_c(self, panel,
> fft_size=1024, sample_rate=input_rate)
> 
> self.connect(self.input, self.scope)
> 
> self._build_gui(vbox)
> 
> *
> 
> Any help would be greatly appreciated.
> 
> John Bratteli
> 
> 
>  
> 
> TV dinner still cooling? 
> Check out "Tonight's Picks" on Yahoo! TV.
> http://tv.yahoo.com/
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjTYUy9GYuuMoUJ4RAtmXAKCZ5DF9IoFsySeGQnCqVrfvu+5uQACgvvLE
4PanFN6JXiX5Bi56H/MrYYg=
=nCEo
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] THE USRP in Toronto

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sander Stepanov wrote:
> Hi, I going to buy one THE USRP card but I am not sure
> that it is what I am looking for
> pls help me if sombody have this one in Toronto
> 
> Sandy

You order the USRP from Ettus Research, www.ettus.com.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGhEqOy9GYuuMoUJ4RAnPIAJ9W3WCimAKKb4x5/d0doSndnkW/5wCgogE1
rlrDF7X1dRBy7xUUrvAGsKc=
=4KbQ
-END PGP SIGNATURE-


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

[Discuss-gnuradio] compressed_file_sink/source?

[Dan Halperin]

Has anyone explored inserting a compression algorithm before a file_sink 
 or a file_source? I made a gzip_file_sink, but it just can't keep up 
at low decimation rates. Are there good compression libs that anyone 
would recommend instead?


Similarly, has anyone explored writing a MATLAB script that can load 
compressed data? The only thing I could find was to gunzip and then load 
it normally, but that defeats the whole purpose. The other option would 
be to write a MATLAB module in c that linked with zlib (or implement 
gzip decompression myself in MATLAB), but those both seem to be pretty 
awful solutions.


Thanks!

Dan


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

Re: [Discuss-gnuradio] Help on editing a usrp1_source_c.cc file

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Meenaktchi Venkatachalam wrote:
> Thanks Tarun, this helped.
> 
> Is there anyway to do the opposite? I have 16-bit I and Q data, I would
> like
> to send this data to USRP and transmit
> 
> Thanks
> Meenaktchi

To log data from the USRP: usrp.source_c -> gr.file_sink(complex)
To replay data to the USRP: gr.file_source(complex) -> usrp.sink_c

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGeuVSy9GYuuMoUJ4RAgi+AJ0SW+l/dlQYVpqHm/T3cbZuMym2hQCfTMDF
o9zq9y2gdBX/L5iE1NXm4Sg=
=V91g
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Adding/recovering packet number using packet_utils python class

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tarun Tiwari wrote:
> Hi,
> 
> I was wondering if we can add the packet number using current packet_utils
> python class.
> 
> When I look into the code, I see that we introduce the preamble, access
> code, length of the packet, payoad with crc, and padding for usrp using
> make_packet function. At the same time when I look into the pkt.py , I see
> that msg.to_string() is the whitened_payload_with_crc and msg.arg1() is the
> whitener_offset for unmake_packet function in packet_utils class.
> 
> Now, I understand that the preamble and access codes are removed by the
> timing and frequncy sync blocks in the receiver (please correct me if I am
> wrong), but I could not understand where the packet length, attached with
> the transmitted packet, went or if it was present, how do I get that?

A better way to put it is that the preamble is ignored altogether and
the access code is detected by the framer_sink, which then pulls off the
length field.

> Well, if I add the packet sequence number in the transmitted packet, how
> can
> i recover the sequence number? is it possible with current packet_utils
> python class or I need to write a new class for the same?

Why don't you just put the sequence number as part of the body of the
message and then you don't have to touch packet_utils?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGdDd1y9GYuuMoUJ4RAlR1AJwNcK5H5C5LckVfG7q8T3oi3dVG2QCggBf0
t94tNgy9vErHj0oB3zKK3L8=
=BHHj
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Swig Error in Python from Trunk Build

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Double check that you updated /etc/ld.so.conf and run ldconfig?

- -Dan

John Stralka wrote:
> I am running Feisty Fawn Ubuntu.  I downloaded, built, and installed the GNU 
> Radio via the trunk following the build directions for Feisty on 
> "http://gnuradio.org/trac/wiki/UbuntuInstall";.  As directed, I used the 
> Ubuntu version of swig since I'm using Feisty.  Everything seemed to go ok.  
> My USRP is recognized via USB.  I'm also able to run "test_usrp_standard_tx" 
> and "test_usrp_standard_rx" from "usrp/host/apps".  However, when I attempt 
> to run "benchmark_usb.py" from "gnuradio-examples/python/usrp" I get the 
> following errors:
> 
> [EMAIL PROTECTED]:~/gnuradio/gnuradio-examples/python/usrp$ ./benchmark_usb.py
> Traceback (most recent call last):
>   File "./benchmark_usb.py", line 30, in 
> from gnuradio import gr
>   File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 
> 27, in 
> from gnuradio_swig_python import *
>   File 
> "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", 
> line 23, in 
> from gnuradio_swig_py_runtime import *
>   File 
> "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
>  line 6, in 
> import _gnuradio_swig_py_runtime
> ImportError: libgnuradio-core.so.0: cannot open shared object file: No such 
> file or directory
> 
> Am I missing something during the build?  Any help would be greatly 
> appreciated.  Thank you.
> 
> 
> 
>  
> 
> Never miss an email again!
> Yahoo! Toolbar alerts you the instant new Mail arrives.
> http://tools.search.yahoo.com/toolbar/features/mail/
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGdCSHy9GYuuMoUJ4RAlpuAJ96nOjGd97gKjqpUOygty4xNYX3ZACgkEwL
NPWWDuK9BHLxV9DzryLzLQM=
=Agjg
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] tunnel.py / pick_bitrate.py

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brett L. Trotter wrote:
> I had originally asked Johnathan Corgan about expanding the list called
> sbs_to_mm that has the m&m mu gain for given samples/symbol to include
> higher samples per symbol so that we can use it at very low bitrates. I
> don't know who wrote the script in the first place, but Johnathan had
> indicated he'd get in touch with the author. He's currently out of the
> country I believe and I was hoping to get in contact with the author
> directly. Would you care to email me?

I believe you want to read Tom Rondeau's email of 6 March 2007:

[Discuss-gnuradio] New digital modulation receiver in trunk

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcCzby9GYuuMoUJ4RAsJjAJ0bqMd8ksZBDuwS+mewx5+UzI7poACeKsu1
inxwPbgS8HIjqtfd9u6GE3o=
=etuQ
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] make error

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Blossom wrote:
> Dan, are you running under Debian or Ubuntu?
> 
> If so, all of this is probably a result of the broken version of
> libtool that Debian/Ubuntu ships.
> 
> See the section on "Broken libtool" in the Ubuntu install guide
> http://gnuradio.org/trac/wiki/UbuntuInstall

Yes; sorry that was in the original post but not in the reply.

$ cat /etc/ld.so.conf
/usr/local/lib/

include /etc/ld.so.conf.d/*.conf
/usr/lib/atlas

Is there an ordering problem? That's the only difference I can think of
(I'd test but I'm not sure how to reproduce the bug).

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGaiaHy9GYuuMoUJ4RAlK5AKCRiPsKiMsNeS6X5STOvTfAdOTdOQCgmkxQ
oKfbLWoPQy+lt956/qXqAnk=
=jIx/
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] make error

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dan Halperin wrote:
> Fresh SVN checkout as of this morning, into a new directory (r5734).
> Ubuntu Edgy, everything's upgraded to its newest version, more or less
> along the lines of the install guide that mdickens and I put together on
> the trac.
> 
> 2) Error when compiling mblock
> 
> /bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
> -Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o
> libmblock-qa.la
> g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
> test_mblock.o  ./.libs/libmblock-qa.so -Wl,--rpath -Wl,/usr/local/lib
> ./.libs/libmblock-qa.so: undefined reference to `operator-(mb_time
> const&, mb_time const&)'

I swear sending an email to a support list reduces the MTTR of bugs by a
factor of 100!

That weird linking bug is still around somewhere -- I had done a make
distclean in the old directory but ended up having to go purge all of
/usr/local/lib to get the mblock to compile.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGaFlHy9GYuuMoUJ4RAn9HAJ4yTQR4krNMwnubOESOCQjnTkP5kACguSaX
md5OJovQk8NWvAOh8gS+zAQ=
=LWyb
-END PGP SIGNATURE-


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

[Discuss-gnuradio] make error

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fresh SVN checkout as of this morning, into a new directory (r5734).
Ubuntu Edgy, everything's upgraded to its newest version, more or less
along the lines of the install guide that mdickens and I put together on
the trac.

1) ./configure spits out some stderr messages about
/etc/ld.so.conf.d/*.conf not existing. Is this expected? The next line
is "GNU/Linux ld.so", so I suspect it is just doing detection, but the
test could probably be fixed to avoid the stderr output.

2) Error when compiling mblock

/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
- -Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o
libmblock-qa.la
g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
test_mblock.o  ./.libs/libmblock-qa.so -Wl,--rpath -Wl,/usr/local/lib
./.libs/libmblock-qa.so: undefined reference to `operator-(mb_time
const&, mb_time const&)'
./.libs/libmblock-qa.so: undefined reference to
`mb_class_registry::register_maker(std::basic_string, std::allocator > const&,
boost::shared_ptr (*)(mb_runtime*, std::basic_string, std::allocator > const&,
boost::shared_ptr))'
./.libs/libmblock-qa.so: undefined reference to
`operator<<(std::basic_ostream >&,
mb_message const&)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::mb_mblock(mb_runtime*, std::basic_string, std::allocator > const&,
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to `mb_time::time(mb_time
const&)'
./.libs/libmblock-qa.so: undefined reference to `PMT_F'
./.libs/libmblock-qa.so: undefined reference to
`mb_timer_queue::cancel(boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock_impl::make_accepter(boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::schedule_one_shot_timeout(mb_time const&,
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::cancel_timeout(boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to `mb_mblock::exit()'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::disconnect_component(std::basic_string, std::allocator > const&)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::shutdown_all(boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`mb_protocol_class_init::mb_protocol_class_init(char const*, unsigned int)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::initial_transition()'
./.libs/libmblock-qa.so: undefined reference to `operator+(mb_time
const&, double)'
./.libs/libmblock-qa.so: undefined reference to `PMT_T'
./.libs/libmblock-qa.so: undefined reference to
`mb_timeout::mb_timeout(mb_time const&, boost::shared_ptr,
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to `mb_mblock::main_loop()'
./.libs/libmblock-qa.so: undefined reference to `mb_time::mb_time(double)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::schedule_periodic_timeout(mb_time const&, mb_time const&,
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`mb_mblock::define_component(std::basic_string, std::allocator > const&,
std::basic_string, std::allocator >
const&, boost::shared_ptr)'
collect2: ld returned 1 exit status
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGaFbSy9GYuuMoUJ4RAjY8AKCBtV5obwB+kwU2pQA9zsMNB+bm9QCfZwSX
1DugYB+pzNBZwaPEqNmKaOE=
=E4A8
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] CPM timing recovery

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nothing that modulates data has constant envelope. Plot the amplitude of
a BPSK or GMSK signal (after transmission, not simulation) sometime.

- -Dan

Achilleas Anastasopoulos wrote:
> Bob,
> 
> this is not correct.
> 
> The CPM signal is by definition constant envelope.
> It is defined as
> s(t)=exp(j phi(t))
> where
> phi(t)= 2 pi int_0^t f(t') dt'
> where
> f(t)= h sum_k a_k p(t-kT).
> Selecting the approprate pulse shape p(t) shapes the spectrum of CPM,
> but regardless of the selection it has continuous phase
> (not abrupt transitions) as the name suggests ;-) and constant envelope.
> Thus the method you suggested (looking at the envelope variations)
> will not work.
> 
> Achilleas
> 
> 
> ==
> Since the signal will not really have infinite bandwidth (instantaneous
> transitions from one state to the next),  the envelope will not be of
> constant modulus.  The signal will be amplitude modulated with a
> component due to the data transitions.  Looking at the modulus or
> modulus squared will reveal a line in the fft due to this amplitude
> modulation.
> 
> Bob
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZue7y9GYuuMoUJ4RAtJ0AJwNEeom3VXahGVfdCYX6Sw536RtSACgw5vF
ntNgOm89dQPZkBHQyHTh6zk=
=eu2i
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Getting Started

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark Rader wrote:
> Hi
> 
> I have GNUradion up and running with the USRP board.  I have two daughter
> cards installed.  One is the DBSRX, the second is the RFX1800, and I have a
> 3rd dauther board the TVRX that is not installed.  I can get the thing to
> respond, but I get an error on most of the python scripts.  USRP Open
> Interface:Usb_claim_interface: failed interface 2.
> 
> Next it tells me usrp_basic_rx: cant open rx interface.
> 
> Does anyone have any ideas?  My suspicission is that the device wants all
> slots to be filled.
> 
> Mark RAder

You need USB 2 to run the USRP. See the mailing list archives for more
discussion (e.g.
http://lists.gnu.org/archive/html/discuss-gnuradio/2007-03/msg00435.html)

[Devs, we should really put a better error message in the driver... we
get this question once a month these days]

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUNTXy9GYuuMoUJ4RAnbMAJ9FicglQ8GXQV9yiGEb8G9fcaIBuQCgsDJr
uuhRCCoAVyXKQnT4bRZ+7S8=
=2w3A
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Bluetooth using RFX-2400

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Johnathan Corgan wrote:
> Dominic Spill wrote:
> 
>> I think I may've mis-phrased the question, if I have a single daughterboard 
>> and I tune to 2.44GHz, what are the highest and lowest frequencies that I 
>> should be able to see when I run something like the usrp_fft waterfall 
>> program?
> 
> With a decimation of 8, you will see 64 Msps/decimation = 8 Msps complex
> over USB = 8 MHz passband = 2436 MHz - 2444 MHz.
> 

Has anyone actually implemented using smaller I/Q coefficients and doing
e.g. 16 MHz with 8-bit coeffs or 32 MHz with 4 bits? I'm curious as to
how performance degrades with lower resolution.

32 MHz should be the maximum passband since the A/Ds are at 64 MHz, yes?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGS1oWy9GYuuMoUJ4RAiTBAJ9UgxUD5MLm8Nq/jzgM0v0j5eKTBwCghCWS
ZTr6i2mpwWU6CGn5rHiRmYE=
=43ir
-END PGP SIGNATURE-


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

[Discuss-gnuradio] impulse detection

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Looking at the existing DBPSK detector, it seems that the current
software doesn't do any sort of transmission detection where
demodulation only happens if there's an increase of energy in the air.

It seems you could implement this easily with a block that keeps a
sliding average of the energy and only forwards those samples that are
above the noise floor. Even with schemes like BPSK that experience great
amplitude fluctuation, the energy never drops anywhere near 0.

Comments on problems with doing this that I don't foresee? Advice on how
to decide between noise and signal? I imagine that doing this poorly
will lead to pulses with SNR less than, say, +3 to +10 db being dropped
which would be pretty crappy.

Thanks!

Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGR7awy9GYuuMoUJ4RAkAqAJ9ToKQB+3+TdkBHISMHxxjE8YK2xgCdEHjJ
B80epm9BiUZSQ37hWqYtDyg=
=c1a5
-END PGP SIGNATURE-


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