[Discuss-gnuradio] Possible to change RFX400 LO tuning step size?

[Newman, Timothy]

Is it possible to change the tuning step size on the RFX400 to something 
different than the 2 MHz step size it's on now?  I've been looking through 
db_flexrf.cc and have had no luck.  

Tim

---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


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

RE: [Discuss-gnuradio] USB latency problem

[Newman, Timothy]

It totally depends on where you implement the latency sensitive components.  I 
believe the best USB can do is a minimum of 100us, and that probably the 
theoretical minimum.  If you need 80-120 us latency, you will definitely need 
to move the latency sensitive components to the FPGA.

Here are a couple more references related to latency in GNUradio and the USRP:
G. Nychis, T. Hottelier, Z. Yang, S. Seshan, P. Steenkiste, "Enabling MAC 
Protocol Implementations on Software-Defined Radios", NDIS 2009
K. Tan, J. Zhang, J. Fang, H. Liu, Y. Ye, S. Wang, Y. Zhang, H. Wu, W. Wang, G. 
Voelker, "Sora: High Performance Software Radio using General Purpose 
Multi-core Processors" 

Tim

---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


From: discuss-gnuradio-bounces+trnewman=vt@gnu.org 
[discuss-gnuradio-bounces+trnewman=vt@gnu.org] On Behalf Of Rushikesh 
Khasgiwale [rushikesh.khasgiw...@mavs.uta.edu]
Sent: Sunday, September 20, 2009 5:17 PM
To: gnuradio
Subject: [Discuss-gnuradio] USB latency problem

I tried to use the usrp for implementing rfid protocols, however the USB
latency is causing a bottleneck and I cannot generate and send the reply
packet before the timeout(I need to send the reply within 80-120 us).
upon reading Thomas Schimd's
paper(http://nesl.ee.ucla.edu/document/show/242), it seems that I may have
to do processing on the fpga itself instead of sending data over usb.

Has anyone else faced a similar problem? CTS packets in 802.11 use
functionality similar to mine, so maybe those who implemented it can help
me.

thanks
-rushikesh



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


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

RE: [Discuss-gnuradio] Editing benchmark_rx.py for spectrum access

[Newman, Timothy]

> Ali Siddiqi wrote:
> >
> > Hi,
> > Did the flowgraph of the code (in which you added the timeout)
involved
> > receive_path???
> >
> > Regards,
> > Ali
> >
> > On Mon, Aug 3, 2009 at 11:21 AM, Dan Rosenqvist 
wrote:
> >
> >>
> >>
> >>
> >> Umair Nasir wrote:
> >> >
> >> > Hi all,
> >> >
> >> > This question is asked a number of times. And I believe it
shouldn't be
> >> > that
> >> > tough. Somebody explain where to put this logic in
benchmark_rx.py
> >> >
> >> > If no data received
> >> > set freq to freq number 2
> >> > else
> >> > stay on the current freq
> >> >
> >> >
> >> > Waiting for a response.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Umair
> >> >
> >> > ___
> >> > Discuss-gnuradio mailing list
> >> > Discuss-gnuradio@gnu.org
> >> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >> >
> >> >
> >>

We have a project here at Virginia Tech where we modified the benchmark
example to perform spectrum sensing and essentially add a dynamic
spectrum access component to it.  The primary goal was to integrate this
gnuradio script with CROSS, our open source cognitive engine, in order
to have CROSS select the channel based on previous experience.  However,
we also have the option to run it without CROSS and select a channel
randomly if a primary user is detected.  Check out the README for more
info on how to do this.

It's a good basic script for figuring out how to do simple spectrum
sensing(probe)/transmission/reception all in one flowgraph.

The benchmark script needs to be copied into
gnuradio-examples/python/digital/ in order for it to function properly.

Basically if you have 2 nodes running this script they will rendezvous
and start exchanging bits.  If another signal comes into the same
channel they will move to another channel.  The channels are hard coded
in right now.  

benchmark_dsa.py script:
https://cornet.wireless.vt.edu/trac/browser/vtcross/trunk/src/cognitive_
engines/DSA_CE/examples/gnuradio-examples

General Info about the cognitive engine:
https://cornet.wireless.vt.edu/trac/wiki/Cross

Tim
---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


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

RE: [Discuss-gnuradio] Re: USRP with USB/IP

[Newman, Timothy]

http://usbip.sourceforge.net/ is an open source project on sourceforge for
this exact thing.  I haven't actually used it, but it's been slowly
developed over the past couple years.

Tim

---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


> -Original Message-
> From: discuss-gnuradio-bounces+trnewman=vt@gnu.org [mailto:discuss-
> gnuradio-bounces+trnewman=vt@gnu.org] On Behalf Of Patrick Strasser
> Sent: Saturday, June 06, 2009 5:49 PM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Re: USRP with USB/IP
> 
> Firas Abbas schrieb on 2009-06-05 21:14:
> > Hi,
> >
> > --- On Fri, 6/5/09, Patrick Strasser 
> wrote:
> >> Hello!
> >>
> >> ednet[1] and RaidSonic[2] sell boxes that can forward USB
> >> ports over via the Linux USB/IP[3] system.
> >>
> >> Patrick
> >>
> >
> > From the web site the transfer rate of these boxes is 10/100Mb/s.
> > So theoretically it should transfer a maximum of 12.5MByte/sec which
> > is far below the required 32Mbyte/sec of USRP1.
> 
> 2 Points:
> 
> 1) USRP is known to be able to transfer maximum 32 MByte/sec, but you
> do
> not need to run at this data rate.
> 
> 2) USB/IP is not limited to this boxes. You can forward USB connections
> from a Linux box to any other Linux box. The mentioned boxes just
> happen
> to do this as their main task. You could do USB over IP forwarding via
> Gigabit Ethernet, that would give you about 100MByte raw transfer rate,
> which should be sufficient for maximum USRP data rates.
> 
> Just wanted to know if anyone used something like this already. I could
> get hold of one Raidsonic part, maybe I'll give it a try. I'm not shure
> if USB/IP supports the transfer modes that the USRP uses.
> 
> Patrick
> --
> Engineers motto: cheap, good, fast: choose any two
> Patrick Strasser 
> Student of Telematik, Techn. University Graz, Austria
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP2 and long cables

[Newman, Timothy]

Has anyone had any experience using a USRP2 with long Ethernet cables,
possibly up to the 100m max?  I don't forsee any problems but I plan on
having several USRP2s distributed throughout a building and having all
the host PC's in central location will simplify things.  Just wanted to
check if anyone has had any good/bad experiences with this.  

 

Thanks,

Tim

 

 

---

Timothy R. Newman, Ph.D.

Wireless @ Virginia Tech

447 Durham Hall

Blacksburg, VA 24061

Phone: 540-231-2041

 

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

[Discuss-gnuradio] USRP2 and long cables

[Newman, Timothy]

Has anyone had any experience using a USRP2 with long Ethernet cables,
possibly up to the 100m max?  I don't forsee any problems but I plan on
having several USRP2s distributed throughout a building and having all
the host PC's in central location will simplify things.  Just wanted to
check if anyone has had any good/bad experiences with this.  

 

Thanks,

Tim

 

---

Timothy R. Newman, Ph.D.

Wireless @ Virginia Tech

447 Durham Hall

Blacksburg, VA 24061

Phone: 540-231-2041

 

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

RE: [Discuss-gnuradio] run AirProbe with first_usrp_decim_112.cfile

[Newman, Timothy]

This question is probably more suited to the AirProbe mailing list.

Tim


-Original Message-
From: discuss-gnuradio-bounces+trnewman=vt@gnu.org on behalf of Jane Chen
Sent: Wed 3/4/2009 8:39 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] run AirProbe with first_usrp_decim_112.cfile
 
Hi all,

I am learning AirProbe to decode the GSM signal.

OS: fedora 9 (2.6.25.9)
GnuRadio:3.1.3

Following the link,
https://svn.berlin.ccc.de/projects/airprobe/wiki/WorkingWithTheUSRP, I
ran ./go.sh first_usrp_decim_112.cfile, but the GSM scanner showed
nothing as the attachment.

I have no idea if I installed the AirProbe correctly or not.

Can anyone please tell me how to try it out using a recording?

Thank you,
Jane

Attachments:
http://www.ruby-forum.com/attachment/3394/AirprobeScreenshot.tar.gz

-- 
Posted via http://www.ruby-forum.com/.


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



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

RE: [Discuss-gnuradio] starting with usrp2_fft.py

[Newman, Timothy]

I had a similar problem when I was using a PCIe express card.  The problem
was with the drivers flow control.  For some reason the Marvell Yukon2
drivers I was using with the Belkin PCIe gigabit card thought it was getting
overwhelmed with frames and sent a PAUSE frame to the USRP2 and then the
interface just stopped receiving frames, even though the USRP2 was still
pushing them.

 

Anyways, check your Ethernet drivers and figure out how to turn off flow
control pause.

 

Tim

From: discuss-gnuradio-bounces+trnewman=vt@gnu.org
[mailto:discuss-gnuradio-bounces+trnewman=vt@gnu.org] On Behalf Of jeff
.
Sent: Tuesday, March 03, 2009 12:05 PM
To: Johnathan Corgan
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] starting with usrp2_fft.py

 

Hi!

The informations of my development environment are:
Revision: 10526
Last Changed Author: matt
Last Changed Rev: 10524
Last Changed Date: 2009-02-26 01:44:02 -0300 (Qui, 26 Fev 2009)

The informations about my USRP2 are:
firmware: txrx-edk10.1-r10524.bin
FPGA:u2_rev3_ise10.1sp3_r10524.bin

Thank you,

Ps.: For all now :-)

Jeff



2009/3/2 Johnathan Corgan 

On Fri, Feb 27, 2009 at 6:06 AM, jeff .  wrote:

> I'm a newbie. I received my hardware and trying test it.
> I started to test the USRP2 (last release of firmware) and FLEX900 with
the
> "usrp2_fft.py".
> My system is Ubuntu 8.10 and the trunk version of gnuradio.

Can you confirm the version of the USRP2 FPGA code and firmware that
is written to the SD card, as well as the revision number of the
"latest trunk" that you have installed on your system?

Johnathan

 



smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] USRP2 with PCMCIA Gigabit Ethernet

[Newman, Timothy]

I have personally used a Belkin Gigabit express and got it working with a few 
minor configuration changes.  Take a look at:

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

for compatibility reports for different chipsets.

Tim

-Original Message-
From: discuss-gnuradio-bounces+trnewman=vt@gnu.org on behalf of Roberto de 
Matos
Sent: Wed 2/18/2009 5:02 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] USRP2 with PCMCIA Gigabit Ethernet
 
Hi,

Someone knows if the USRP2 works with PCMCIA Gigabit Ethernet 
adapter, like this:
   
http://www.trendnet.com/products/proddetail.asp?prod=235_TEG-PCBUSR&cat=42

My notebook has only 10/100 ethernet, and the USRP2 only works with 
Gigabit ethernet.

Thank you,

Roberto de Matos


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



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

RE: [Discuss-gnuradio] USRP2 PPS and REF

[Newman, Timothy]

Couldn't you just tell the USRP's to start at a specific time to get
them to start in sync?  Rather than in real-time telling them to start
immediately and having that lag.

Tim

---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


> -Original Message-
> From: discuss-gnuradio-bounces+trnewman=vt@gnu.org
[mailto:discuss-gnuradio-
> bounces+trnewman=vt@gnu.org] On Behalf Of Douglas Geiger
> Sent: Friday, February 13, 2009 2:02 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] USRP2 PPS and REF
> 
> 
>  Ok - so I have packets coming in from both USRP2's now, getting
dumped
> to their separate files.
>  My app prints out the timestamp of each frame that gets sent to the
> copy handler: if my 1PPS source is working properly, should the
> timestamps coming out of the two USRP2's be identical?
>  Another question: no matter what, there is going to be some time
delay
> between when I tell one USRP2 to start, and when I tell the other one
to
> start: with the timestamps I could do something like
> align_on_samplenumbers (but with the timestamps - at least I could do
> this in the copy handler where I have access to this information). Of
> course this requires that the timestamps do end up being based on the
> 1PPS. Should I take that as a sign my USRP2's are not currently
getting
> sync'd to the 1PPS?
>  Thanks,
>  Doug
> 
> --
> Doug Geiger
> Research Assistant
> Communications and Signal Processing Lab
> Oklahoma State University
> http://cspl.okstate.edu
> douglas.gei...@okstate.edu
> doug.gei...@ieee.org
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

RE: [Discuss-gnuradio] Usrp2 and Agere ET131x compatibility

[Newman, Timothy]

If you're in a hurry to get it to work, your best bet is to go out and buy a 
GigE express card.  I doubt that much work is going into looking into specific 
incompatible chipsets. I could be wrong.

Tim
---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041

> -Original Message-
> From: discuss-gnuradio-bounces+trnewman=vt@gnu.org 
> [mailto:discuss-gnuradio-
> bounces+trnewman=vt@gnu.org] On Behalf Of Yc Park
> Sent: Wednesday, February 11, 2009 8:21 AM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Usrp2 and Agere ET131x compatibility
> 
> Hi, guys
> 
> I have two questions:
> 
> - My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
>   Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
> (I see the chipset 'bad'
> here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
> that the linux and ET131 have some problems, not USRP2 and ET131)
> 
> - Granted that the compatibility issue exists, do we have any progress
> on the latest source code of GR or on the USRP2 firmware?
> 
> I'm eager to see it work with my laptop... usrp2 is just sitting on my
> desk for more than a month T.T
> 
> Regards,
> YCpark.
> --
> Posted via http://www.ruby-forum.com/.
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Intel Atom is NICE.

[Newman, Timothy]

There are many more ways than just lumping everything onto a single GPP.  A 
good example is a recent thread on the GNU radio mailing list where the poster 
is using the USRP2 as a standalone radio with no PC.  Pushing key elements to 
other reconfigurable processors, e.g. the USRP2 FPGA, will greatly ease the 
burden of the GPP.  My point is that "big iron" isn't always necessary if 
you're willing to put some work into distributing the work load to other 
processors (a major research issue currently).

Tim


> -Original Message-
> From: discuss-gnuradio-bounces+trnewman=vt@gnu.org 
> [mailto:discuss-gnuradio-
> bounces+trnewman=vt@gnu.org] On Behalf Of Marcus D. Leech
> Sent: Monday, December 29, 2008 8:14 AM
> To: Bob McGwier
> Cc: hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz; 
> discuss-
> gnura...@gnu.org
> Subject: Re: [Discuss-gnuradio] Intel Atom is NICE.


> While I can heartily agree that for the expansion of SDR into the
> consumer space, you want it to run on low-power processors, etc, I can't
>   agree that "for most operations" you don't need a high-end CPU.
> 
> For example, 802.11 at anywhere approaching 802.11b bitrates needs some
> serious iron, and yet in our world (the world of SDR
>   geeks), wanting to build SDR/GnuRadio-based 802.11b implementations
> seems a fairly common goal.
> 
> In my work in radio astronomy, I've found that despite the relative
> simplicity of the basic functions my software provides--full-bandwidth
>   spectral display, and total power, for one or two channels, big iron
> is necessary.   I recently upgraded to a quad-core Q6600 to replace
>   a dual-core Pentium D 940.  The quad core loses against the dual-core
> because of a difference in maximum clock speed.  I can
>   run the D 940 at 3.2Ghz forever, and it can process a full 8Mhz of
> dual-channel, complex bandwidth.  The Q6600, on the other hand,
>   is unstable above 2.85Ghz or so, and can't sustain more than about
> 5.3Mhz of dual-complex-channel bandwidth without incurring
>   massive USRP overruns.
> 
> Despite the wonderful new multi-threaded Gnu Radio framework, it seems
> that at least one of those threads really needs as many
>   MIPs as the processor can throw at it, because it has to keep up with
> a real-time data source.
> 
> Any time you're dealing with having to suck in (or send out) as much
> bandwidth as the USRP can tolerate, and
>   *actually doing something* with the entire bandwidth, you need
> ManyMIPS(tm).
>   Which means spending $$$ (although, my dual/quad-core system was much
> less than the $1000.00 you quote above).
> 
> --
> Marcus Leech
> Principal Investigator, Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Connection Refused when transmitting

[Newman, Timothy]

I'm not familiar with what code you are using, but you will need to have
a port open on the server you are trying to connect to.  In your case, a
port should be open on port 5000 at 172.20.2.89 in order for your client
code to connect to it.  If you enter 127.0.0.1 then you'll need a server
running on your local computer opening port 5000.  

 

Tim

 

---

Timothy R. Newman, Ph.D.

DNI Post Doctoral Fellow

Wireless @ Virginia Tech

447 Durham Hall

Blacksburg, VA 24061

Phone: 540-231-2041

 

From: discuss-gnuradio-bounces+trnewman=vt@gnu.org
[mailto:discuss-gnuradio-bounces+trnewman=vt@gnu.org] On Behalf Of
Joreen Tan
Sent: Sunday, December 21, 2008 10:31 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Connection Refused when transmitting

 

Hi,
 
I am currently trying to transmit a picture using the TCP transmission.
However, there are some problem regarding the transmission side. It
appears that the port is blocked as there is a socket error which states
'Connection refused'. 
 
please input server IP address: 172.20.2.89
please input esrver port (default is 5000): 5000
Traceback (most recent call last):
  File "MainFrame.py", line 180, in OnTransmit
 s.connect((HOST, PORT))
  File "", line 1, in connect
socket.error: (111, 'Connection refused')
 
The result is the same even if i input the IP address as 127.0.0.1.
 
Help is much appreciated! Thank you so much!

Regards,
Joreen







Get easy photo sharing with Windows Live(tm) Photos. Drag n' drop
 

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

RE: [Discuss-gnuradio] Question about benchmark_tx

[Newman, Timothy]

> The USRP sink is basically the gnuradio device driver for the USRP.
> Look at the USRP library code to see how it actually sends the raw
> data.  It accesses the USRP through the USRP device filesystem.  It's
> not simply just writing something to /dev/usrp..

Whoops I meant USB device system not USRP device system.

Tim


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

RE: [Discuss-gnuradio] Question about benchmark_tx

[Newman, Timothy]

The USRP sink is basically the gnuradio device driver for the USRP.  Look at 
the USRP library code to see how it actually sends the raw data.  It accesses 
the USRP through the USRP device filesystem.  It's not simply just writing 
something to /dev/usrp..

Tim


-Original Message-
From: [EMAIL PROTECTED] on behalf of Mir Ali
Sent: Sun 11/23/2008 2:34 PM
To: Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Question about benchmark_tx
 
Thanks Tom, but I wanted a more specific answer. I know that it writes to
the USRP sink through tranmit_path.py. I want to know how is this sink
referenced as. Is it a device file with a name such as /dev/... etc or is it
referenced as something else. I looked at the whole code and also the
programs that are referred to in the code but didn't find a clear answer.
When we call send_pkt() function where is the payload written to (of course
USRP_Sink) but what is it in terms of a file path.

I hope I put my question in clear words. If I am wrong or misunderstood
something then please correct me.

Thanks again to all and to Tom
Bye
Ali

On Sun, Nov 23, 2008 at 8:34 AM, Tom Rondeau <[EMAIL PROTECTED]> wrote:

> Mir Ali wrote:
>
>> Hi,
>>
>> Can someone tell me to which device file is the data written to in
>> benchmark_tx.
>>
>> Thanks
>> Ali
>>
>
> The benchmark_tx writes data to the USRP sink through transmit_path.py.
>
> Tom
>
>


-- 
Mir Murtuza Ali
Graduate Student
Center for Wireless Communications
University of Mississippi
University, MS 38677



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

RE: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

[Newman, Timothy]

For both those functions you need to pass in the variable you want assigned the 
value as an input parameter.

 

Look at gnuradio/trunk/gr-usrp2/src/usrp2_source_base.cc for the function 
definitions of adc_rate and daughterboard_id.

 

Tim

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Catalin LACATUS
Sent: Thursday, November 13, 2008 8:48 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Running usrp2_wfm_rcv.py

 

Hello,

-I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I 
got the following error.
¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'adc_rate'¨

 

-After I set the adc_rate=100e6, I got the following error:

 

AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 
'daughterboard_id' 

-Testing ./find-usrps script is running fine with following result.
00:50:c2:85:30:0a hw_rev = 0x0300

My configuration is
-Ubuntu 8.04, with the latest svn (7 days old)-USRP2 with a BasicRX
- I am using Netgear Gigabit switch to connect to fast Ethernet port on my 
laptop. I could not directly connect my Gigabit PCMCIA card to USRP2. 

Please let me know how I can fix the error AttributeError: 
'usrp2_source_32fc_sptr' object has no attribute 'daughterboard_id' 

Thank you,
-Catalin 

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

RE: [Discuss-gnuradio] Usrp_spectrum_sense.py doubts

[Newman, Timothy]

 

Your getting into basic python questions now, maybe check out some
python tutorials first.  The "tap" in that for loop just iterates over
each value in mywindow.  The += is the assignment by addition operator,
it adds the value of "tap*tap" to the value of power.

 

Tim

 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Santi Ortega
Sent: Wednesday, November 12, 2008 11:18 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Usrp_spectrum_sense.py doubts

 

Can anyone explain me this from usrp_spectrum_sense.py (line 55)?

for tap in mywindow:

power += tap*tap


mywindow is done with window.py but I didn't find where is "tap" and
what it means...
Furthermore, Does "+=" means that increase one unit to the result of
tap*tap?

Sorry if I am a little useless...

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

RE: [Discuss-gnuradio] USRP2 AttributeError: 'us rp2_source_32fc_sptr' object has no attribute 'adc_rate'¨

[Newman, Timothy]

The usrp2_fft python code was recently changed to use that adc_rate() call, 
although the actual implementation returns the value to the input pointer 
parameter.  

 

Just change that line in usrp2_fft back to what it was so you can at least test 
it:

 

From:

input_rate = self.u.adc_rate() / self.u.decim() 

 

To:

input_rate = 100e6/options.decim 

 

 

This simply a quick fix, I'm assuming the adc_rate function will be changed to 
return the value the same way as decim() does.

 

 

---

Timothy R. Newman

DNI Post Doctoral Fellow

Wireless @ Virginia Tech

447 Durham Hall

Blacksburg, VA 24061

Phone: 540-231-2041

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Catalin LACATUS
Sent: Friday, November 07, 2008 10:35 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] USRP2 AttributeError: 'usrp2_source_32fc_sptr' 
object has no attribute 'adc_rate'¨

 

Hello,

I tried to run usrp2_fft.py to test my USRP2 board and I got the following 
error.
¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'adc_rate'¨

./find-usrps script is running fine with following result.
00:50:c2:85:30:0a hw_rev = 0x0300

My configuration is
-Ubuntu 8.04, with the latest svn (7 days old)
- I am using Netgear Gigabit switch to connect to fast Ethernet port on my 
laptop. I could not directly connect my Gigabit PCMCIA card to USRP2. 

Do you think this error is due to any configuration setting?

Thank you,
-C

-
./usrp2_fft.py -f 400M
Traceback (most recent call last):
  File "./usrp2_fft.py", line 267, in 
main ()
  File "./usrp2_fft.py", line 263, in main
app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
36, in __init__
wx.App.__init__ (self, redirect=False)
  File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7836, in __init__
self._BootstrapApp()
  File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7433, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
39, in OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
60, in __init__
self.panel = stdpanel (self, self, top_block_maker)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
81, in __init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "./usrp2_fft.py", line 71, in __init__
input_rate = self.u.adc_rate() / self.u.decim()
AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'adc_rate'
-- 

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

RE: [Discuss-gnuradio] USRP2 siggen error

[Newman, Timothy]

Looks like your MTU is set a bit too small.  Try increasing it to 1500 or maybe 
a bit higher and see what happens.  

/sbin/ifconfig eth0 mtu 1500

Tim

---
Timothy R. Newman
DNI Post Doctoral Fellow
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Natalia Olano
Sent: Monday, November 03, 2008 10:20 AM
To: Eric Blossom; Natalia Olano; Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP2 siggen error

Here is the output, thanks for taking some time in this.
Natalia

[EMAIL PROTECTED]:/home/nol/mobnets/testbed# /sbin/ifconfig eth0
eth0  Link encap:Ethernet  HWaddr 00:1e:37:1e:ee:4a
  inet addr:134.130.222.127  Bcast:134.130.222.255  Mask:255.255.255.0
  inet6 addr: fe80::21e:37ff:fe1e:ee4a/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1
  RX packets:16302010 errors:3 dropped:19 overruns:0 frame:2
  TX packets:21446 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3178136520 (2.9 GB)  TX bytes:3379674 (3.2 MB)
  Base address:0x1840 Memory:fe20-fe22


2008/11/3 Eric Blossom <[EMAIL PROTECTED]>:
> On Mon, Nov 03, 2008 at 11:51:09AM +0100, Natalia Olano wrote:
>> Hello,
>>
>> I am using the USRP2 with an RFX2400 daughterboard in Ubuntu Hardy
>> 8.04.1, installation went fine (used rev 9913 plus the ready made
>> firmware images in http://gnuradio.org/releases/usrp2-bin/trunk) and
>> usrp2_fft.py works perfectly.
>>
>> However, I experience the following problem when invoking usrp2_siggen.py:
>>
>> [EMAIL PROTECTED]:/home/nol/gnuradio_V_9913/gr-utils/src/python# python
>> usrp2_siggen.py -f 2.4G -w 200k
>> ethernet:write_packetv: send: Message too long
>> usrp2_sink_32fc: tx_32fc failed
>>
>> I would appreciate some help
>> Thanks
>> --
>> Natalia Olano
>
> Thanks for pointing out the problem.  I haven't seen this one before.
>
> Can you run this command and post the output?
>
>  $ /sbin/ifconfig eth0
>
> Thanks,
> Eric
>



-- 
Natalia Olano Agüero


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


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

RE: [Discuss-gnuradio] (no subject)

[Newman, Timothy]

You can use any SD card reader available.

 

---

Timothy R. Newman

Wireless @ Virginia Tech

Virginia Tech

447 Durham Hall

Blacksburg, VA 24061

Phone: 540-231-2041

Email: [EMAIL PROTECTED] 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matigakis Emmanouil
Sent: Friday, October 31, 2008 8:07 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] (no subject)

 

Hi,

the SD-Card reader that is available from Ettus Research is specifically
made for the USRP2?
Is it possible to use the SD-Card reader of my laptop to program the
SD-Cards?

We are having problem setting the gain in the USRP2 PGAs. Could it be
because of the firmware?
I saw in another message in the mailing list that there maybe
incompatibilities of the firmware
that was shipped with the USRP2 and the current svn code.

Thanks
Manolis.



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