Re: [Discuss-gnuradio] USRP power supply issues
Bob Keyes wrote: Hello, I was happy to be able to borrow a USRP from a friend of mine at MIT. However, it came as just the board with two LFRX and two LFTX 1.0 daughterbouards. No power supply, cables, etc. I dug through what I through was a rather decent pile of wall-warts that I have acquired throughout the years but couldn't find any for 6V. I read the ettus.com web page where it is said that the board can operate off of 5v, But that some boards may require 6V. Which boards are these? I have plenty of 5V adapters that I can use while waiting for a replacement power supply. But I don't want to cause wierd errors due to brown outs. Only the BasicRX and BasicTX really don't need 6V. Everything else basically does. Also, is there a manual for the board I can download somewhere? http://gnuradio.org/trac/wiki/UsrpFAQ Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Boston area GNUradio / USRP meetup?
I've counted just among people who I've met, two groups at Harvard and two groups at MIT who are using or plan to use GNUradio on the USRP. I know of a couple of others who are interested in using it but are waiting for a bit more software to be available for amateur radio use. I wonder if an in-person meetup would be useful, or at least enjoyable. For the academics, it's probably best to do this between semesters, in January. I can arrange a space for up to fifteen or so people at the Harvard Wireless Club without any hassle, could probably get a bigger room if need be. But I am not insisting it be at Harvard. Topics I'd like to cover would be a show-n-tell of the USRP2, some info on other gnuradio devices, perhaps short summaries by each participant of their projects or interests, and perhaps even an in-depth presentation. Lastly, we could have a 'swap-meet' where boards are bought-sold-traded, cables, enclosures, antennas, components, etc. It could also be a good place for personal inter-networking. business card exchange and so forth. If you think this is a good idea or bad, etc., air your views here on the forum. If you just want to say "I am interested", drop me some private email. Once we get a core group of people who would be working on this, I'd move traffic off this list in order to keep the noise down. Regards, Bob Keyes Harvard University rkeyes at fas dot harvard dot edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP power supply issues
Hello, I was happy to be able to borrow a USRP from a friend of mine at MIT. However, it came as just the board with two LFRX and two LFTX 1.0 daughterbouards. No power supply, cables, etc. I dug through what I through was a rather decent pile of wall-warts that I have acquired throughout the years but couldn't find any for 6V. I read the ettus.com web page where it is said that the board can operate off of 5v, But that some boards may require 6V. Which boards are these? I have plenty of 5V adapters that I can use while waiting for a replacement power supply. But I don't want to cause wierd errors due to brown outs. Also, is there a manual for the board I can download somewhere? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to include OFDM package?
Hi All, I am going to TX/RX using OFDM. However, I am using Ubuntu 8.04 and Gnuradio3.1.1, there is no OFDM package included. How should I include the OFDM package? Thanks, Brook -- View this message in context: http://www.nabble.com/How-to-include-OFDM-package--tp20349025p20349025.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a simple qustion about the attenuator for the SMA cable
On Wed, Nov 5, 2008 at 1:02 PM, Bill Stevenson
<[EMAIL PROTECTED]> wrote:
>
>
>
> From: Dan Halperin <[EMAIL PROTECTED]>
> To: Bill Stevenson <[EMAIL PROTECTED]>
> Cc: discuss-gnuradio@gnu.org
> Sent: Wednesday, November 5, 2008 1:08:41 PM
> Subject: Re: [Discuss-gnuradio] a simple qustion about the attenuator for
> the SMA cable
>
> -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-
>
> Hello, Dan
>
> I got it!Thank you so much! But I think we could also attenuate the
> transmitted power by
> setting --tx-amplitude to a reasonable value. Do you think so? What's your
> idea?
Running full output from the output of the daughter board to the input
my damage the daughterboard. Using an attenuator is safer, avoiding
the possibility of coding errors leading to full output power.
Depending on the ammount you lower the tx-amplitude, you also add
quantization noise.
Philip
>
> Thank you!
>
> Bill
>
>
> ___
> 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] a simple qustion about the attenuator for the SMA cable
From: Dan Halperin <[EMAIL PROTECTED]>
To: Bill Stevenson <[EMAIL PROTECTED]>
Cc: discuss-gnuradio@gnu.org
Sent: Wednesday, November 5, 2008 1:08:41 PM
Subject: Re: [Discuss-gnuradio] a simple qustion about the attenuator for the
SMA cable
-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-
Hello, Dan
I got it!Thank you so much! But I think we could also attenuate the transmitted
power by
setting --tx-amplitude to a reasonable value. Do you think so? What's your idea?
Thank you!
Bill
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] install OFDM
Hello Fernando Perez-5, I am trying to install OFDM too. Do you have any clue on how to include those OFDM files to your system? Thanks, Brook -- View this message in context: http://www.nabble.com/install-OFDM-tp20065473p20348808.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_make_io_signaturev
On Wed, Nov 05, 2008 at 01:29:21PM -0600, Brett L. Trotter wrote:
> Are there any examples of how to use this?
>
> Since the current C++ (until C++0x is out) doesn't support vector
> initialization, how does one format the inheritance constructor?
> for example:
> myblock::myblock(...) : gr_block("myblock", gr_make_io_signaturev(4,4,
> std::vector somevec)) { ...}
>
> in what code do I populate somevec? or is there another way to attack this?
Take a look at gr_io_signature.cc. It uses gr_make_io_signaturev to
implement the other versions.
Do you really have more than 3 different kinds of items in your signature?
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_make_io_signaturev
Are there any examples of how to use this?
Since the current C++ (until C++0x is out) doesn't support vector
initialization, how does one format the inheritance constructor?
for example:
myblock::myblock(...) : gr_block("myblock", gr_make_io_signaturev(4,4,
std::vector somevec)) { ...}
in what code do I populate somevec? or is there another way to attack this?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding 371 samples/frame in usrp2
On Wed, Nov 05, 2008 at 07:30:01PM +0100, Mattias Kjellsson wrote:
> Eric Blossom wrote:
>>
>> There are a couple of headers. See usrp2_eth_packet.h
>
> So I have. Regarding the channel and timestamp fields in "struct
> u2_fixed_hdr_t", channel is going to (when implemented) reflect which
> usrp2 you want to "speak" with, when mimo- configured? For instance say
> I have two usrp2 connected with a mimo- cable. Then I send data to
> usrp2#1 on channel #1 and to usrp2#2 on channel #2, while I still use
> channel #0 to configure them? Or is this functionality still to much on
> the drawing- board to be able to say "this is how it's (going to(?))
> work.
Probably too early on this. We'll probably be moving to something
that looks like VRT ("Virtual Radio Transport" a.k.a VITA 49 -- a
format for digitized IF data), and possibly over UDP instead of raw
ethernet. In any event there will be some way to distinguish control
packets from data packets, and for each of those types, some way to
distinguish which logical pipeline (stream) the data is from or for.
The mimo stuff is really just a generalization of support for multiple
streams within a single USRP.
> The timestamp in the same header, supposed to reflect when it's going to
> be sent out on the antenna, when it was received to the usrp2, when it
> left the host- computer, or any of the above, depending on what the
> current time is, and what the timestamp is? Or is this function as well
> in to early stages to say?
On Tx, the timestamp is the time when the samples will be clocked into
the DSP pipeline. On Rx, the timestamp is the time that the first
sample was clocked out of the DSP pipeline. There was a discussion
about this on the list about a month ago with regard to the USRP1
inband code.
If the host cares, it'll have to compute the delay from the head of
the DSP pipeline to the antenna. This is composed of at least the
pipeline delay, the group delay through the DSP filters, any internal
pipeline and group delays in the A/D, etc.
>> (This format is all subject to change.)
> So I have noticed ;)
>> We'll be modifying the code so that it checks
>> for the actual MTU and does the right thing. It's ticket:310.
>>
> I might have some code to do precisely this, but I don't know if it is
> as portable and neat as the rest of the code in here, and as I mentioned
> earlier I'm not sure exactly where U2_MAX_SAMPLES is used, but I guess
> "it's just trail and error, compile and re- write", that does the trick?
The header in question is used by the firmware and the host. We need
to represent (somewhere) the maximum physical buffer size that's
available in the USRP and then derive a maximum number of samples that
the USRP can possibly handle based on that number and the sizes of the
various headers. That will set one upper bound. The MTU of the link,
if configured, is another upper bound. For interfaces that have no
MTU configured, we need some way to figure out if the interface can
handle jumbo frames or not.
If you've got code that figures this out on a variety of OS's, I'd
love to take a look at it.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding 371 samples/frame in usrp2
Eric Blossom wrote: On Wed, Nov 05, 2008 at 06:15:03PM +0100, Mattias Kjellsson wrote: I have been playing with ioctl's today and while browsing the USRP2- code i found that max length of a packet is defined to 371 which results in 1484 bytes of "data", and 16 bytes left, leaving room for the 14 byte ethernet header, but not a 372:nd sample, since each sample is 4 bytes. But when I look at the output of ifconfig my MTU is set to 1500, but when I print out how much data is received from a raw socket (listening to some random network traffic), it tells me it reads max 1514 bytes, which I figured is 1500 bytes of data, and 2*6 bytes mac- addresses + 2 bytes of protocol. This gives me two questions. Is there (probably) something I missed here, or should we be able to increase U2_MAX_SAMPLES to 375 (1500/4 = 375), not that four samples might make a huge difference in the end, but still... And the other question, shouldn't one check for the MTU set by the nic and calculate this number, instead of having it #defined? But then again, it would be a whole lot of re- writing, since U2_MAX_SAMPLES is #defined... Or have I missed some fundamental here? BR Mattias Kjellsson There are a couple of headers. See usrp2_eth_packet.h So I have. Regarding the channel and timestamp fields in "struct u2_fixed_hdr_t", channel is going to (when implemented) reflect which usrp2 you want to "speak" with, when mimo- configured? For instance say I have two usrp2 connected with a mimo- cable. Then I send data to usrp2#1 on channel #1 and to usrp2#2 on channel #2, while I still use channel #0 to configure them? Or is this functionality still to much on the drawing- board to be able to say "this is how it's (going to(?)) work. The timestamp in the same header, supposed to reflect when it's going to be sent out on the antenna, when it was received to the usrp2, when it left the host- computer, or any of the above, depending on what the current time is, and what the timestamp is? Or is this function as well in to early stages to say? (This format is all subject to change.) So I have noticed ;) We'll be modifying the code so that it checks for the actual MTU and does the right thing. It's ticket:310. I might have some code to do precisely this, but I don't know if it is as portable and neat as the rest of the code in here, and as I mentioned earlier I'm not sure exactly where U2_MAX_SAMPLES is used, but I guess "it's just trail and error, compile and re- write", that does the trick? BR //Mattias Kjellsson ___ 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
-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] USRP2 latency calculations
set_freq would not be a good measure, since it takes a while to configure the daughterboard. find() isn't great either, since it waits 10ms to ensure that it's gathered all responses to it's broadcast. set_rx_decim should give a reasonable measurement, as long as you're not streaming data. BTW, I also have code which can be run which actually measures the latency on USRP1, rather than just theoretical calculations that you've found on the wiki: https://www.cgran.org/wiki/ArchitectureLatencyMeasurements It uses pings and some modifications to the Linux kernel to measure latency from host->kernel->USRP, etc. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding 371 samples/frame in usrp2
On Wed, Nov 05, 2008 at 06:15:03PM +0100, Mattias Kjellsson wrote: > I have been playing with ioctl's today and while browsing the USRP2- > code i found that max length of a packet is defined to 371 which results > in 1484 bytes of "data", and 16 bytes left, leaving room for the 14 byte > ethernet header, but not a 372:nd sample, since each sample is 4 bytes. > > But when I look at the output of ifconfig my MTU is set to 1500, but > when I print out how much data is received from a raw socket (listening > to some random network traffic), it tells me it reads max 1514 bytes, > which I figured is 1500 bytes of data, and 2*6 bytes mac- addresses + 2 > bytes of protocol. This gives me two questions. Is there (probably) > something I missed here, or should we be able to increase U2_MAX_SAMPLES > to 375 (1500/4 = 375), not that four samples might make a huge > difference in the end, but still... And the other question, shouldn't > one check for the MTU set by the nic and calculate this number, instead > of having it #defined? But then again, it would be a whole lot of re- > writing, since U2_MAX_SAMPLES is #defined... Or have I missed some > fundamental here? > > BR > Mattias Kjellsson There are a couple of headers. See usrp2_eth_packet.h (This format is all subject to change.) We'll be modifying the code so that it checks for the actual MTU and does the right thing. It's ticket:310. Thanks for your concern, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Regarding 371 samples/frame in usrp2
I have been playing with ioctl's today and while browsing the USRP2- code i found that max length of a packet is defined to 371 which results in 1484 bytes of "data", and 16 bytes left, leaving room for the 14 byte ethernet header, but not a 372:nd sample, since each sample is 4 bytes. But when I look at the output of ifconfig my MTU is set to 1500, but when I print out how much data is received from a raw socket (listening to some random network traffic), it tells me it reads max 1514 bytes, which I figured is 1500 bytes of data, and 2*6 bytes mac- addresses + 2 bytes of protocol. This gives me two questions. Is there (probably) something I missed here, or should we be able to increase U2_MAX_SAMPLES to 375 (1500/4 = 375), not that four samples might make a huge difference in the end, but still... And the other question, shouldn't one check for the MTU set by the nic and calculate this number, instead of having it #defined? But then again, it would be a whole lot of re- writing, since U2_MAX_SAMPLES is #defined... Or have I missed some fundamental here? BR Mattias Kjellsson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 latency calculations
On Wed, Nov 05, 2008 at 04:26:04PM +0100, Mattias Kjellsson wrote: > Hi, > > Wouldn't one be able to use for instance "set_freq()" or find() as a > messure? Although there might be some overhead, you will receive an "ok > I have set the freq"/"Ok here I am"- packet from the usrp2. Although one > could think of more elaborate schemes involving a special OP_CODE > (usrp2_eth_packet.h)... > > Cheers > //Mattias Kjellsson > set_freq would not be a good measure, since it takes a while to configure the daughterboard. find() isn't great either, since it waits 10ms to ensure that it's gathered all responses to it's broadcast. set_rx_decim should give a reasonable measurement, as long as you're not streaming data. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 latency calculations
Hi, Wouldn't one be able to use for instance "set_freq()" or find() as a messure? Although there might be some overhead, you will receive an "ok I have set the freq"/"Ok here I am"- packet from the usrp2. Although one could think of more elaborate schemes involving a special OP_CODE (usrp2_eth_packet.h)... Cheers //Mattias Kjellsson Firas Abbas wrote: Hi, If USRP2 can respond to PING and reply back, then one should be able to measure the delay. Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wideband Spectrum Analyzer
Hi everybody!
I have modified usrp_spectrum_sense.py to plot the results with gnuplot.
There are two files: widespectrum.py and plot.p
I would like everybody to test it and report me the errors and how can I
improve it.
I've used USRPv1 + Flex2400.
Thanks in advance!
Here it goes...
WIDESPECTRUM.PY:
#!/usr/bin/env python
#
# Copyright 2005,2007 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
#
from gnuradio import gr, gru, eng_notation, optfir, window
from gnuradio import audio
from gnuradio import usrp
from gnuradio.eng_option import eng_option
from optparse import OptionParser
from usrpm import usrp_dbid
import sys
import math
import struct
import Gnuplot, Gnuplot.funcutils # Added to view the results
class tune(gr.feval_dd):
"""
This class allows C++ code to callback into python.
"""
def __init__(self, tb):
gr.feval_dd.__init__(self)
self.tb = tb
def eval(self, ignore):
"""
This method is called from gr.bin_statistics_f when it wants to
change
the center frequency. This method tunes the front end to the new
center
frequency, and returns the new frequency as its result.
"""
try:
# We use this try block so that if something goes wrong from
here
# down, at least we'll have a prayer of knowing what went wrong.
# Without this, you get a very mysterious:
#
# terminate called after throwing an instance of
'Swig::DirectorMethodException'
# Aborted
#
# message on stderr. Not exactly helpful ;)
new_freq = self.tb.set_next_freq()
return new_freq
except Exception, e:
print "tune: Exception: ", e
class parse_msg(object):
def __init__(self, msg):
self.center_freq = msg.arg1()
self.vlen = int(msg.arg2())
assert(msg.length() == self.vlen * gr.sizeof_float)
# FIXME consider using Numarray or NumPy vector
t = msg.to_string()
self.raw_data = t
self.data = struct.unpack('%df' % (self.vlen,), t)
class my_top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
usage = "usage: %prog [options] min_freq max_freq"
# Example: ./widespectrum.py 2.23G 2.93G
# that is the maximun range of the USRP Flex2400 device.
parser = OptionParser(option_class=eng_option, usage=usage)
parser.add_option("-R", "--rx-subdev-spec", type="subdev",
default=(0,0),
help="select USRP Rx side A or B (default=A)")
parser.add_option("-g", "--gain", type="eng_float", default=None,
help="set gain in dB (default is midpoint)")
parser.add_option("", "--tune-delay", type="eng_float",
default=1e-3, metavar="SECS",
help="time to delay (in seconds) after changing
frequency [default=%default]")
parser.add_option("", "--dwell-delay", type="eng_float",
default=10e-3, metavar="SECS",
help="time to dwell (in seconds) at a given
frequncy [default=%default]")
parser.add_option("-F", "--fft-size", type="int", default=256,
help="specify number of FFT bins
[default=%default]")
parser.add_option("-d", "--decim", type="intx", default=64,
help="set decimation to DECIM [default=%default]")
parser.add_option("", "--real-time", action="store_true",
default=False,
help="Attempt to enable real-time scheduling")
parser.add_option("-B", "--fusb-block-size", type="int", default=0,
help="specify fast usb block size
[default=%default]")
parser.add_option("-N", "--fusb-nblocks", type="int", default=0,
help="specify number of fast usb blocks
[default=%default]")
(options, args) = parser.parse_args()
if len(args) != 2:
parser.print_help()
sys.exit(1)
self.min_freq = eng_notation.str_to_num(args[0])
self.max_freq = eng_notation.str_to_num(args[1])
if self.min_freq > self.max_freq:
self.min_freq, self.max_freq = self.max_freq, self.min_freq #
swap them
Re: [Discuss-gnuradio] USRP2 latency calculations
Hi, If USRP2 can respond to PING and reply back, then one should be able to measure the delay. Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 latency calculations
On Wed, Nov 05, 2008 at 01:01:14PM +0200, Pauli Rikula wrote: > I foud this wery usefull: http://www.gnuradio.org/trac/wiki/UsrpFAQ/Latency > > Is there similar calculations about the latency of the USRP2? > > If there is not, could someone please do those calculations? > > - Pauli Rikula I did some preliminary measurements a while ago. A round trip from the host to the USRP2 and back was taking about 47us. It mostly depends on how much data you've queued for transmission on the ethernet. YMMV. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help with new install..
Hi, If you installed boost at (for example): /opt/boost_1_36_0/lib then : 1) sudo edit : /etc/ld.so.conf 2) add the line: /opt/boost_1_36_0/lib to it 3) exit and do: sudo ldconfig Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 latency calculations
I foud this wery usefull: http://www.gnuradio.org/trac/wiki/UsrpFAQ/Latency Is there similar calculations about the latency of the USRP2? If there is not, could someone please do those calculations? -- - Pauli Rikula ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Usrp(er) and the serial port of the FX2
Hallo, has anybody written a firmware or an extension the firmware that allows to read and write the CY7C68013 serial port through USB? In my case, the FX2 is only the second processor on the board, and the first uC sends debug data to the serial port. At the moment I have to connect a serial adapter additional to the USB cable to the FX2, which is only used for high speed data. Having both data on the same USB port would come handy. Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help with new install..
Hello list, I have edited the ldconfig conf file as mentioned in the previous email, however now I get this error when I try the dial tone example. Can anyone point me in the right direction? I built the trunk as per the wiki instructions. Thanks for the help, Matt Traceback (most recent call last): File "./dial_tone.py", line 23, in from gnuradio import gr File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 43, 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: libboost_thread-gcc42-mt-1_36.so.1.36.0: cannot open shared object file: No such file or directory Search 1000's of available singles in your area at the new Yahoo!7 Dating. Get Started http://au.dating.yahoo.com/?cid=53151&pid=1011 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
