Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
Tom, You are right, it doesn't make any sense, I was thinking about the reverse method, taking for example just 10 MHz out of a total band of 12.5 by filtering or resampling, but that is totally different since you have extra band and you just eliminate the extra part, but here you can't just make up the difference between 25 and 32 MHz. Vlad. --- On Tue, 11/30/10, Tom Rondeau trondeau1...@gmail.com wrote: From: Tom Rondeau trondeau1...@gmail.com Subject: Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band? To: Vladutzzz stoianovici_v...@yahoo.com Cc: Discuss-gnuradio@gnu.org Date: Tuesday, November 30, 2010, 4:48 AM On Mon, Nov 29, 2010 at 5:59 PM, Vladutzzz stoianovici_v...@yahoo.com wrote: What would be the best way to work with a 32 MHz band resulting from USRP2? I guess, since the minimum decimation rate is 4 (resulting in a 25 MHz signal band), some kind of interpolation will be required or maybe resampling?! Any ideas on how to proceed? Thanks in advance! Vlad. I'm not entirely sure what you meant by interpolating or resampling, but in case you were talking about what I think you were talking about, that's not going to work. Sure, you can come in at 25 Msps and resample to 32 Msps, but you won't be getting any more information out of the signal by doing that. You'll still only have the information in the original 25 MHz bandwidth, just now sampled at a higher rate (which doesn't make any difference or, frankly, any sense). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Full duplex and half duplex doesnot work
How did you resolve your problem? I have the same problem and reading your post I cannot understand the solution of your one. Thanks in advance blwfsoj wrote: Hi all, Before i start telling about my problem, i want to mention that i have already read the post named help: cannot send after transport endpoint shutdown which is very close to my problem but i could not solve it. I'm trying to transmit from the usrp port A, and then make it receive at the same port using Auto T/R which i expressed by typing -v (isn't it correct) after the benchmark. but some time it works and most of the times its not (not stable), when its not working it shows me the following error: .o...@vecon3:~/Documents/abbasi/programmitx.py -f 12 -m dbpsk -v --tx-amplitude=0.08 -T A gr_fir_ccf: using SSE Modulator: bits per symbol: 1 Gray code: True RRC roll-off factor: 0.35 Tx amplitude 0.08 modulation: dbpsk_mod bitrate: 100kb/s samples/symbol:2 USRP Sink: A: Flex 1200 Tx MIMO B Requested TX Bitrate: 100k Actual Bitrate: 125k Warning: failed to enable realtime scheduling o...@vecon3:~/Documents/abbasi/programmirx.py -f 12 -m dbpsk -v gr_fir_ccf: using SSE Demodulator: bits per symbol: 1 Gray code: True RRC roll-off factor: 0.35 Costas Loop alpha: 1.50e-01 Costas Loop beta:5.62e-03 MM mu: 0.50 MM mu gain: 1.00e-01 MM omega: 2.00 MM omega gain: 2.50e-03 MM omega limit: 0.01 Receive Path: modulation: dbpsk_demod bitrate: 100kb/s samples/symbol:2 usrp_open_interface:usb_claim_interface: failed interface 2 could not claim interface 2: Device or resource busy usrp_basic_rx: can't open rx interface Traceback (most recent call last): File mybenchmark_rx.py, line 112, in module main() File mybenchmark_rx.py, line 101, in main tb = my_top_block(demods[options.modulation], rx_callback, options) File mybenchmark_rx.py, line 45, in __init__ self.rxpath = usrp_receive_path.usrp_receive_path(demodulator, rx_callback, options) File /home/onur/Documents/abbasi/programming/examples/digital/usrp_receive_path.py, line 68, in __init__ self._setup_usrp_source(options) File /home/onur/Documents/abbasi/programming/examples/digital/usrp_receive_path.py, line 73, in _setup_usrp_source self.u = usrp_options.create_usrp_source(options) File /home/onur/Documents/abbasi/programming/examples/digital/usrp_options.py, line 88, in create_usrp_source gain=options.rx_gain, File /home/onur/Documents/abbasi/programming/examples/digital/generic_usrp.py, line 144, in __init__ _generic_usrp_base.__init__(self, **kwargs) File /home/onur/Documents/abbasi/programming/examples/digital/generic_usrp.py, line 63, in __init__ except: raise Exception, 'Failed to automatically setup a usrp device.' Exception: Failed to automatically setup a usrp device. o...@vecon3:~/Documents/abbasi/programming/examples/digital$ ON THE OTHER HAND: when i try the full duplex (use a slot from block A as transmitter and slot from block B as receiver) it also doesnot work. it will not be able to setup the interface. i appreciate your help, regards, -- View this message in context: http://old.nabble.com/Full-duplex-and-half-duplex-doesnot-work-tp27226209p30338716.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] About the directionality of the LP0410 antenna.
On 11/30/2010 10:06 PM, Miok Wah wrote: Hi all, We hope to do some experiments with the LP0410 antenna. Before that, we hope to know more about its characteristics: 1. Is it a directional antenna? 2. If so, is there statistics about its directionality (e.g., beamwidth)? We did not find relevant information in its data sheet. Hope someone who knows about this can help. Thanks! Those antennas are made by Kent electronics: http://www.wa5vjb.com/ They're log-periodic antennas, so they are directional. Here's an article on them: http://www.salsburg.com/Log-Periodic.pdf The original Dwight Isbell article on the LPDA is also available on the web. -- 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] Discrete Lo Frequency Changes in GRC
Hello all, Another question. I need to have essentially a counter that will control what frequency I transmit out of the USRP2. I need to control the rate at which it changes. Currently I use a ramp function to do this. I see there is a vector source that is also possible solution. Im wondering if there are also other solutions I may not have considered that someone could recommend. If my previous email is accurate I might need to wait something like 2 seconds between counts to do what I want in an automated fashion. This seems difficult to do in a processor efficient manner within GRC being that it is sample based and more of a labview style of coding and not Cish where I could set a sleep timer or some other wait function to delay the count. If I understand things right a possible solution is to decimate a source to achieve this, or just use a lower frequency ramp source. However this still requires a lot of cpu time since the source is still outputing samples at the sample frequency regardless of whether they are being used. And if I need a variable amount of time at each count, or non-equally spaced counts this doesn't provide that. I have considered going into the python code and doing this modification in there. However I have zero experience with python so it might take me a bit to do that. Just fishing for suggestions, any help offered is appreciated. Thanks, Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Lo Frequency Change
Hello All, As always thanks for the help. I was doing some timing measurements the other day and was wondering if this seemed reasonable to you all. I did a simple setup in GRC where I had a toggle switch that changed the frequency the usrp used as an LO. I input a constant of 1 into the USRP2 block and then hooked the usrp2 to a highspeed oscilliscope. I used the toggle switch to change the lo frequency back and forth and with the aid of a stopwatch I saw that the change took about 1.2 seconds to take affect. Is 1.2 seconds a reasonable or expected amount of time? Or is this more indicative of something else? Thanks, Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP question for report on gnuradio history
Hello all, I am writing a report on gnuradio and wanted to include a small portion about the history of the USRP. The only info that I have found is from wikipedia, The GNU Radio project created the Universal Software Radio Peripheral (USRP) ... the USRP was developed by Matt Ettus. I was slightly surprised that Matt does not have a wikipedia page yet. Was Matt part of the original gnuradio project? Any good stories, facts, or info on the history of gnuradio (especially the USRP's) would be greatly appreciated. Have a good day, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tesla C2000 series and CUDA and Gnu Radio
Is anyone out there taking another look at CUDA + Gnu Radio? Some of the couple-of-years-old charts I've looked at suggest that speedups for some of the most important transforms we use vary between modest and disappointing. Cross-over points for things like FFTs are usually up in the atmospheric levels of FFT sizes before a CUDA-based transform would win even slightly against a multi-threaded CPU-based FFTW, for example. But that was a couple of years ago. Anything new along those lines? It seems like the kinds of things that do well on a GPU are ones that take a small amount of input data, compute ferociously, and produce modest amounts of output data. Or schemes that might consume deluges of input data, but produce output data only occasionally--a flow that did a bunch of FFTs and produced averaged mag-squared outputs only once in a while might fare well on a GPU. On a related note, has anyone looked at enabling the multi-threaded FFTW stuff? The cross-over points there (between FFTW in a single-thread and FFTW in multiple-threads) seem to be lower-down on the FFT-size curve. -- 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
Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
Thank you Marcus, for the very prompt and exhaustive reply! Mostly it's what I expected, but I am a wee bit worried about the IP addressing process: I need to change the IP of one of the USRP2 modules, how do I do that, considering I use an UDP FPGA image and not UHD? Also, what IPs should I use in the USPR2 source blocks, now that there's 2 of them? Thanks! Vlad. Marcus D. Leech wrote: On 11/30/2010 07:04 PM, Vladutzzz wrote: I am interested in this 2 USRPs approach since I don't have the experience and the knowledge to start messing about inside the FPGA firmware code and have an extra USRP2. How would this go? I tried looking up some info about this topic. I've read some bits and pieces on a few forums. Most of the info is about having one USRP2 module as a transmitter and the other as a receiver. I want them both to be receivers(actually half a receiver) and to complete each other by receiving half of the 32 MHz band (so each would receive 16 MHz). How would the USRPs be connected to the same computer? (MIMO cable?) How will the two 16 MHz bands be attached together to form the 32 MHz one (some kind of 2:1 multiplexing - I'm just guessing here)? I am aware of the great load exerted upon the system resources, but I'm trying to make this work anyway. Thanks. Vlad. Assuming that you have a big-arsed machine to do this with, here goes: Assumptions o phase-coherence between the two isn't an issue (if you're just doing power measurements, it won't be) o you have a very-studly computer o you have two good 1GiGe interfaces Start out with two single-usrp sources, address them as appropriate for your two USRP2s. 16MHz isn't an available bandwidth out of the USRP2, so use 16.7MHz, and band-limit it to exactly 16MHz with an FIR bandpass filter. Your two USRP2s will each be tuned to a frequency that is 16MHz away from each other. Once you have your two band-limited complex signals, detect them, using a complex-to-mag-squared on each of them. Then put the two signals into an adder, and low-pass filter with a single-pole IIR or FIR low-pass filter. Decimate to taste after filtering. -- 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 -- View this message in context: http://old.nabble.com/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30347806.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build BBN_80211 with 4.3.3
Hi! I'm trying to compile the BBN 802.11 component into the Gnuradio 3.2.2.1 framework on i686 Linux, using GCC 4.3.3. mar...@gnuradio012 ~/gnuradio/sw/bbn_80211 % make make all-recursive make[1]: Entering directory `/home/marius/gnuradio/sw/bbn_80211' Making all in config make[2]: Entering directory `/home/marius/gnuradio/sw/bbn_80211/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/marius/gnuradio/sw/bbn_80211/config' Making all in src make[2]: Entering directory `/home/marius/gnuradio/sw/bbn_80211/src' Making all in bbn make[3]: Entering directory `/home/marius/gnuradio/sw/bbn_80211/src/bbn' make[3]: *** No rule to make target `/swig/gnuradio.i', needed by `bbn.cc'. Stop. make[3]: Leaving directory `/home/marius/gnuradio/sw/bbn_80211/src/bbn' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/marius/gnuradio/sw/bbn_80211/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/marius/gnuradio/sw/bbn_80211' make: *** [all] Error 2 So the issue is: make[3]: *** No rule to make target `/swig/gnuradio.i', needed by `bbn.cc'. Stop. I already patched the Makefile.common for the SWIG includes: # swig includes swigincludedir = /usr/include/gnuradio/swig/ SWIGGRFLAGS = -I$(GNURADIO_CORE_INCLUDEDIR)/swig -I$(GNURADIO_CORE_INCLUDEDIR) $(GNURADIO_CORE_CPPFLAGS) This is mentioned two years ago in this list :): http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg15439.html I'm stuck here. Does anybody know how to make it work? Thanks, Marius ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Congratulations to Ettus and the USRP!
Last night, Ettus Research, LLC won the Wireless Innovation Forum's SDR Technology of the Year for the USRP family of products. I'm very pleased that Matt's contributions to the SDR community have been so well received and recognized. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Congratulations to Ettus and the USRP!
Many many congratulations from me and all other community members, usrp is mile stone in SDR technology Sent on my BlackBerry® from Vodafone -Original Message- From: Tom Rondeau trondeau1...@gmail.com Sender: discuss-gnuradio-bounces+smzerocool=gmail@gnu.org Date: Wed, 1 Dec 2010 07:31:06 To: GNURadio Discussion Listdiscuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com Subject: [Discuss-gnuradio] Congratulations to Ettus and the USRP! Last night, Ettus Research, LLC won the Wireless Innovation Forum's SDR Technology of the Year for the USRP family of products. I'm very pleased that Matt's contributions to the SDR community have been so well received and recognized. Tom ___ 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] USRP question for report on gnuradio history
Eric Blossom adapted MIT student Vanu Bose's pspectra (parallelized spectra) software into the first GNU Radio software. That software used a PCI digitizer board, I believe from National Instruments, but it was expensive and not very flexible. We knew of much better digitizer chips, but there was no convenient way to integrate them into a PC-based system. Matt Ettus as working on a Bluetooth chip or macrocell at a commercial company at the time. He noticed the GNU Radio effort, and got interested in contributing. He and Eric designed the original USRP prototypes and modified the GNU Radio software to be able to talk with it over the USB bus. They also designed the daughterboard system and defined the electrical and physical connections to the daughterboards. They released the design under free licenses. Matt ultimately left his job (after finishing the Bluetooth design) and started Ettus Research to reliably produce the USRP, enabling low cost and high performance radio work with GNU Radio. It was a lot of work (he was a 1-man operation and it grew only slowly) and I'm glad he's been well rewarded over the long run for doing it. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [USRP-users] Congratulations to Ettus and the USRP!
Congratulations! On Wed, Dec 1, 2010 at 1:31 PM, Tom Rondeau trondeau1...@gmail.com wrote: Last night, Ettus Research, LLC won the Wireless Innovation Forum's SDR Technology of the Year for the USRP family of products. I'm very pleased that Matt's contributions to the SDR community have been so well received and recognized. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC with two URSP2+DBSRX and UHD
Hi Bob, This is pretty easy to do (but, I can only tell you how to do it in C++)... set_clock_config() in UHD Do you have some code snippet to share? Does the C++ version support streaming data from a slave device through a host URSP2 before sending all data via a single ethernet cable? I am implementing our passive radar in C++ but I thought that GRC is nice for testing. I learnt yesterday that things are not completely available for GRC. But as our project needs to move on I would be highly interested if you can sync (PPS and freq.) two (or more) URSP2s via MIMO and (!) stream the data via a single gigabit Ethernet cable with the current UHD library? This would enable us to place our receivers at arbitrary locations without the need of pulse generators and a 10 MHz reference. Regards, Thomas -- ** Dr. Thomas Hobiger Space-Time Measurement Project Space-Time Standards Group New Generation Network Research Center National Institute of Information and Communications Technology -- 4-2-1 Nukui-Kitamachi, Koganei 184-8795 Tokyo Japan -- email: hobi...@nict.go.jp phone: ++81-042-327-7561 fax:++81-042-327-6664 -- homepage (priv.): http://www.hobiger.org ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1
Nick, Got it working on my USRP2 by changing to line 57 to: self.u = uhd.single_usrp_source(addr=192.168.1.15, uhd.io_type_t.COMPLEX_FLOAT32) and line 119 to: result = self.u.set_center_freq(freq,0) I'm getting 0 aircraft locations in the KML file but the stdout is as follows: (-40) Type 11 (all call reply) from e9fc9f in reply to interrogator 5 (-41) Type 11 (all call reply) from 2c4e09 in reply to interrogator 0 I assume these are Mode-S packets, thus no position info? -- View this message in context: http://old.nabble.com/gr-air-modes%3A-problem-with-uhd-and-USRP1-tp30326133p30336873.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-air-modes: problem with uhd and USRP1
and line 119 to: result = self.u.set_center_freq(freq,0) I intended the channel parameters to default to 0 for the single usrp* blocks. It looks like i missed that. Will fix, thanks. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Windows Build environment -- Cygwin or MinGW?
Kevin Dixon wrote:
I'd like to get started building GNURadio for Windows, using the USRP
1, with the goal of writing some custom blocks. Do people prefer
Cygwin or MinGW style installations? Off the cuff, Cygwin looks more
straightforward. Any opinions?
I use GNU Radio (with USRP1) on both, but prefer MinGW as my production
environment.
Cygwin has more of the prerequisites available as easy-to-install packages,
but they change fairly often, and anytime you update to the latest packages
there is a risk that your next GNU Radio installation may not work. The
last time I tried it, they were in the process of moving from gcc 3.x to
4.x, but their gcc 4.x required some hacks to GNU Radio. At some point, I
expect that 3.x versions of the dependencies will no longer be available and
4.x will be the only option.
MinGW requires a little more work to get all the pieces together, but once
you have a working system it is more likely to continue to work forever.
Neither one is in any way comparable to your typical download-and-run
Windows install. It really helps if you have (or are willing to acquire)
some Unix/Linux experience, or are at least comfortable with using a Windows
cmd shell. I assume you have seen the instructions at
http://gnuradio.org/redmine/wiki/gnuradio/WindowsInstall.
I have attached a rudimentary Python script to install MinGW, MSYS, and GNU
Radio. You need to read the notes at the beginning of the script and edit
it to suit your needs, and you may need to updated the versions and/or
locations of the dependencies. But once you get it right, it could save you
a lot of work.
Good luck with it,
-- Don W.
# Install MinGw, MSYS, GNU Radio, and all it prerequisites (except python)
# on a Windows system.
#
# Python must be installed first in order to run this script. This version
# is based on the Python 2.6.5 Windows installer at
# http://www.python.org/download/
#
import os
import sys
import shutil
import urllib
import subprocess
#
# Install options
#
install_python_packages = True # wants admin privileges, but can do without
install_git = False # requires administrator privileges
install_mingw_and_msys = True
install_gr_prerequisites = False
install_gnuradio_tarball = False
install_gnuradio_git = False
option_usrp = True
option_portaudio = True
option_sdl_video = False # doesn't build
#
# Important locations
#
# Default is to install on drive containing Python executable
# If you override the default, you will need to check the install paths
# used by automated installers
install_drive = os.path.splitdrive(sys.executable)[0]
# install_drive = D: # override default here
# MinGW and MSYS locations
mingw_dir = install_drive+/MinGW
msys_dir = install_drive+/msys/1.0
# GNU Radio install directory
gr_inst_dir = msys_dir+/home/+os.environ['USERNAME']
local_src = msys_dir+/src
local_bin = msys_dir+/local/bin
local_dir = os.path.dirname( local_bin )
sh_env = os.environ
sh_env['PATH'] =
local_bin+;+mingw_dir+/bin;+msys_dir+/bin;+os.environ['PATH']
sh_env['MSYSTEM'] = MINGW32
sh_env['PKG_CONFIG_PATH'] = local_dir+/lib/pkgconfig
pyv = sys.version_info
py_vers = python%d.%d%pyv[0:2]
numpy_vers = 1.4.1
numpy_URL =
http://downloads.sourceforge.net/numpy/numpy-+numpy_vers+-win32-superpack-+py_vers+.exe;
# Python version
py_vers = py%d%d%pyv[0:2]
wxpython_vers = 2.8-win32-ansi-2.8.10.1
wxpython_URL =
http://downloads.sourceforge.net/wxpython/wxPython+wxpython_vers+-+py_vers+.exe;
wxpython_file = sys.exec_prefix+/Lib/site-packages/wxversion.py
sdcc_vers = 2.9.0
sdcc_file = install_drive+/Program Files/SDCC
sdcc_URL = http://downloads.sourceforge.net/sdcc/sdcc-+sdcc_vers+-setup.exe;
mingw_dl = http://downloads.sourceforge.net/mingw/;
mingw_URL = mingw_dl+MinGW-5.1.6.exe
msys_URL = mingw_dl+MSYS-1.0.11.exe
msys_vers = 'msys-1.0.11'
mingw_install_bin = (
'autoconf2.5-2.64-1',
'autoconf-7-1',
'automake1.11-1.11-1',
'automake-4-1',
'libtool-2.2.7a-1',
)
mingw_install_dll = (
)
msys_install_bin = (
'perl-5.6.1_2-1',
'm4-1.4.13-1',
'guile-1.8.7-1',
'patch-2.5.9-1',
)
msys_install_dll = (
('libcrypt-1.1_1-2',0),
('libguile-1.8.7-1',17),
('libgmp-4.3.1-1',3),
('libltdl-2.2.7a-1',7),
('libregex-1.20090805-1',1),
)
msys_install_rtm = (
'libguile-1.8.7-1',
)
xemacs_exe = install_drive+/Program
Files/XEmacs/XEmacs-21.4.22/i586-pc-win32/xemacs.exe
unzip_prog = unz600xn
unzip_file = unzip_prog+.exe
unzip_URL = ftp://ftp.info-zip.org/pub/infozip/win32/+unzip_file
unzip_exe = unzip.exe
glib_file = glib_2.24.0-2_win32.zip
glib_URL = http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.24/+glib_file
gnome_URL_deps = http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/;
pkgconfig_file = pkg-config_0.23-3_win32.zip
pkgconfig_URL = gnome_URL_deps+pkgconfig_file
swig_version = swigwin-1.3.40
swig_file = swig_version+.zip
swig_URL =
[Discuss-gnuradio] Fwd: USRP2 Lo Frequency Change
It appears that the server went down yesterday. I don't know if anyone recieved these messages. I apologize for any Deja vu this causes. Please see the following: -- Forwarded message -- From: Justin Bracken scourc...@gmail.com Date: Tue, Nov 30, 2010 at 11:35 AM Subject: USRP2 Lo Frequency Change To: discuss-gnuradio@gnu.org Hello All, As always thanks for the help. I was doing some timing measurements the other day and was wondering if this seemed reasonable to you all. I did a simple setup in GRC where I had a toggle switch that changed the frequency the usrp used as an LO. I input a constant of 1 into the USRP2 block and then hooked the usrp2 to a highspeed oscilliscope. I used the toggle switch to change the lo frequency back and forth and with the aid of a stopwatch I saw that the change took about 1.2 seconds to take affect. Is 1.2 seconds a reasonable or expected amount of time? Or is this more indicative of something else? Thanks, Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
On 12/01/2010 05:49 AM, Vladutzzz wrote: Thank you Marcus, for the very prompt and exhaustive reply! Mostly it's what I expected, but I am a wee bit worried about the IP addressing process: I need to change the IP of one of the USRP2 modules, how do I do that, considering I use an UDP FPGA image and not UHD? Also, what IPs should I use in the USPR2 source blocks, now that there's 2 of them? Thanks! Vlad. My advice would be to screw up your courage, bite the bullet, and convert to UHD. Theres a UHD utility, usrp2_addr_burner that can be used to change the IP address. The factory address is: 192.168.10.2, you'll need to change it to an address on a different subnet, like 192.168.20.2 or some such. The idea is that you have two GiGE ethernet ports, and you configure your system with the appropriate subnet on each ethernet port, and program your USRP2 addresses accordingly. -- 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
Re: [Discuss-gnuradio] GRC with two URSP2+DBSRX and UHD
-Original Message-
From: Thomas Hobiger [mailto:hobi...@nict.go.jp]
Sent: Tuesday, November 30, 2010 01:04 AM
To: b...@sigmatix.com
Cc: j...@joshknows.com, discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GRC with two URSP2+DBSRX andUHD
Hi Bob,
This is pretty easy to do (but, I can only tell you how to do it in
C++)...
set_clock_config() in UHD
Do you have some code snippet to share? Does the C++ version support
streaming data from a slave device through a host URSP2 before sending
all data via a single ethernet cable?
Thomas,
There is no code that I am aware of that currently does what you want (i.e.,
sync the U2's *and* conveys data from both devices), however, I believe it is
currently being worked on, however I'm willing to be corrected on this.
As I said, sync'ing 2 devices to a single PPS signal is pretty
straightforward, however I think you're looking for more than that.
Using the raw enet drivers the code is essentially...
usrp2::usrp2::sptr u2 = usrp2::usrp2::make(dev, );// dev = device path
(e.g., eth1)
u2-config_mimo(mode);
// mode = (usrp2::MC_WE_DONT_LOCK + usrp2::MC_PROVIDE_CLK_TO_MIMO) //
drive clock to cable
| (usrp2::MC_WE_LOCK_TO_MIMO) // lock for reference from
cable
| (usrp2::MC_WE_LOCK_TO_SMA) // lock to reference
provided by front panel
You need to do the right thing on both ends of the cable.
For UHD (which we're currently transitioning and am still getting up to speed
with), I believe the equivalent code would be something like:
uhd::usrp::simple_usrp::sptr u2 = uhd::usrp::simple_usrp::make(dev);
clock_config_t mode;
mode.ref_source = { REF_AUTO | REF_INT = 'i' | REF_SMA = 's' | REF_MIMO =
'm' }l
mode.pps_source = { PPS_INT | PPS_SMA | PPS_MIMO};
mode.pps_polarity = { PPS_NEG | PPS_POS};
u2-set_clock_config(mode);
As I said, I think what you're actually looking for (clock/pps sync data
over the MIMO cable is in the works, but I could be mistaken).
Obviously syncing more than 2 usrps requires additional hardware (since
without additional hardware you can only connect 2 usrps together).
Hope this helps,
--Bob
I am implementing our passive radar in C++ but I thought that GRC is
nice for testing. I learnt yesterday that things are not completely
available for GRC. But as our project needs to move on I would be highly
interested if you can sync (PPS and freq.) two (or more) URSP2s via MIMO
and (!) stream the data via a single gigabit Ethernet cable with the
current UHD library? This would enable us to place our receivers at
arbitrary locations without the need of pulse generators and a 10 MHz
reference.
Regards,
Thomas
--
**
Dr. Thomas Hobiger
Space-Time Measurement Project
Space-Time Standards Group
New Generation Network Research Center
National Institute of Information and Communications Technology
--
4-2-1 Nukui-Kitamachi, Koganei
184-8795 Tokyo
Japan
--
email: hobi...@nict.go.jp
phone: ++81-042-327-7561
fax:++81-042-327-6664
--
homepage (priv.): http://www.hobiger.org
**
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnu-radio + USRP problem
I'm still trying to get gr-ais going on Beagleboard (Lucid). When I tried to run ais_decode.py, I've got uOuOuO output. On PC everything works fine. My guess - BB simply can't process that much data. So I ran usrp_benchmark on BB to see if this was the problem. 2MB/s and 4MB/s went fine, but with higher data rates it started uOuOuO again. In web I've seen people chatting about some code optimizations for BB, which would allow DSP run faster. Could anyone help? -- View this message in context: http://old.nabble.com/Gnu-radio-%2B-USRP-problem-tp30349099p30349099.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] Windows Build environment -- Cygwin or MinGW?
Just what I was looking for. In this case, it sounds like MinGW is the way to go, especially since we may end up with multiple developers, and a consistent environment would be best. The script looks to be amazing. Thanks so much Kevin On Wed, Dec 1, 2010 at 7:46 AM, Don Ward don2387w...@sprynet.com wrote: Kevin Dixon wrote: I'd like to get started building GNURadio for Windows, using the USRP 1, with the goal of writing some custom blocks. Do people prefer Cygwin or MinGW style installations? Off the cuff, Cygwin looks more straightforward. Any opinions? I use GNU Radio (with USRP1) on both, but prefer MinGW as my production environment. Cygwin has more of the prerequisites available as easy-to-install packages, but they change fairly often, and anytime you update to the latest packages there is a risk that your next GNU Radio installation may not work. The last time I tried it, they were in the process of moving from gcc 3.x to 4.x, but their gcc 4.x required some hacks to GNU Radio. At some point, I expect that 3.x versions of the dependencies will no longer be available and 4.x will be the only option. MinGW requires a little more work to get all the pieces together, but once you have a working system it is more likely to continue to work forever. Neither one is in any way comparable to your typical download-and-run Windows install. It really helps if you have (or are willing to acquire) some Unix/Linux experience, or are at least comfortable with using a Windows cmd shell. I assume you have seen the instructions at http://gnuradio.org/redmine/wiki/gnuradio/WindowsInstall. I have attached a rudimentary Python script to install MinGW, MSYS, and GNU Radio. You need to read the notes at the beginning of the script and edit it to suit your needs, and you may need to updated the versions and/or locations of the dependencies. But once you get it right, it could save you a lot of work. Good luck with it, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio 3.3.0 with USRP2 w/ DBSRX: gain settings vs actual
Hi, I've noticed that with the aforementioned configuration that when I set the gain between 0-40 dB that the actual gain out is 0-70 dB. I've seen this across multiple units. Is there a fix for this? Thanks, David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Congratulations to Ettus and the USRP!
Congratulations! On 01/12/2010 12:31, Tom Rondeau wrote: Last night, Ettus Research, LLC won the Wireless Innovation Forum's SDR Technology of the Year for the USRP family of products. I'm very pleased that Matt's contributions to the SDR community have been so well received and recognized. Tom ___ 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] gr-air-modes: problem with uhd and USRP1
On Mon, 2010-11-29 at 20:16 -0800, madengr wrote: Nick, Got it working on my USRP2 by changing to line 57 to: self.u = uhd.single_usrp_source(addr=192.168.1.15, uhd.io_type_t.COMPLEX_FLOAT32) and line 119 to: result = self.u.set_center_freq(freq,0) That's correct. The Github repo has the latest changes to make this work as well. I'm getting 0 aircraft locations in the KML file but the stdout is as follows: (-40) Type 11 (all call reply) from e9fc9f in reply to interrogator 5 (-41) Type 11 (all call reply) from 2c4e09 in reply to interrogator 0 I assume these are Mode-S packets, thus no position info? Those are interrogator replies which contain no information except the ICAO number of the aircraft and the interrogator ID. --n ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1
On Wed, 2010-12-01 at 13:55 -0500, Allen Vinegar wrote: I am getting output like the following: (-35) Type 11 (all call reply) from ac85cc in reply to interrogator 4 (-34) Type 11 (all call reply) from ac85cc in reply to interrogator 4 (-35) Type 11 (all call reply) from ac85cc in reply to interrogator 4 (-33) Type 4 (short surveillance altitude reply) from ac85cc at 5900ft (-33) Type 0 (short A-A surveillance) from ac85cc at 5875ft (-34) Type 11 (all call reply) from ac85cc in reply to interrogator 0 (-34) Type 0 (short A-A surveillance) from ac85cc at 5825ft (-34) Type 0 (short A-A surveillance) from ac85cc at 5825ft (-34) Type 0 (short A-A surveillance) from ac85cc at 5800ft (-33) Type 0 (short A-A surveillance) from ac85cc at 5600ft (-33) Type 0 (short A-A surveillance) from ac85cc at 5575ft (-36) Type 11 (all call reply) from ac85cc in reply to interrogator 0 However I can't renewed output to GoogleEarth. On occasion I get a plane showing as in the attached file but I can't get a continually renewing display. Those squitters don't contain any position information. The majority (70% or so) of Mode S-equipped aircraft do not broadcast their position via ADS-B. ADS-B packets are type 17 and you will see lat/lon in the text when they come up. The default KML settings only display aircraft which were heard in the last 5 minutes. This is to prevent old data from being displayed on screen. You can edit modes_kml.py to change that timeout if you like. If your display doesn't auto-renew, look at the network link settings in Google Earth. Make sure under the Refresh tab the Time-Based Refresh is set to Periodically and set the timeout to 4 or 5 seconds. --n Any ideas on how to fix? Thank you, Al Vinegar - Original Message - From: madengr rfe...@everestkc.net To: Discuss-gnuradio@gnu.org Sent: Monday, November 29, 2010 11:16 PM Subject: Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1 Nick, Got it working on my USRP2 by changing to line 57 to: self.u = uhd.single_usrp_source(addr=192.168.1.15, uhd.io_type_t.COMPLEX_FLOAT32) and line 119 to: result = self.u.set_center_freq(freq,0) I'm getting 0 aircraft locations in the KML file but the stdout is as follows: (-40) Type 11 (all call reply) from e9fc9f in reply to interrogator 5 (-41) Type 11 (all call reply) from 2c4e09 in reply to interrogator 0 I assume these are Mode-S packets, thus no position info? -- View this message in context: http://old.nabble.com/gr-air-modes%3A-problem-with-uhd-and-USRP1-tp30326133p30336873.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio 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] gr-air-modes: problem with uhd and USRP1
I do have the Refresh tab set to time-based refresh periodically and 5 second timeout. I seem to make one capture with no following renewals. - Original Message - From: Nick Foster n...@ettus.com To: Allen Vinegar tok...@myranch.com Cc: Discuss-gnuradio@gnu.org Sent: Wednesday, December 01, 2010 3:21 PM Subject: Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1 On Wed, 2010-12-01 at 13:55 -0500, Allen Vinegar wrote: I am getting output like the following: (-35) Type 11 (all call reply) from ac85cc in reply to interrogator 4 (-34) Type 11 (all call reply) from ac85cc in reply to interrogator 4 (-35) Type 11 (all call reply) from ac85cc in reply to interrogator 4 (-33) Type 4 (short surveillance altitude reply) from ac85cc at 5900ft (-33) Type 0 (short A-A surveillance) from ac85cc at 5875ft (-34) Type 11 (all call reply) from ac85cc in reply to interrogator 0 (-34) Type 0 (short A-A surveillance) from ac85cc at 5825ft (-34) Type 0 (short A-A surveillance) from ac85cc at 5825ft (-34) Type 0 (short A-A surveillance) from ac85cc at 5800ft (-33) Type 0 (short A-A surveillance) from ac85cc at 5600ft (-33) Type 0 (short A-A surveillance) from ac85cc at 5575ft (-36) Type 11 (all call reply) from ac85cc in reply to interrogator 0 However I can't renewed output to GoogleEarth. On occasion I get a plane showing as in the attached file but I can't get a continually renewing display. Those squitters don't contain any position information. The majority (70% or so) of Mode S-equipped aircraft do not broadcast their position via ADS-B. ADS-B packets are type 17 and you will see lat/lon in the text when they come up. The default KML settings only display aircraft which were heard in the last 5 minutes. This is to prevent old data from being displayed on screen. You can edit modes_kml.py to change that timeout if you like. If your display doesn't auto-renew, look at the network link settings in Google Earth. Make sure under the Refresh tab the Time-Based Refresh is set to Periodically and set the timeout to 4 or 5 seconds. --n Any ideas on how to fix? Thank you, Al Vinegar - Original Message - From: madengr rfe...@everestkc.net To: Discuss-gnuradio@gnu.org Sent: Monday, November 29, 2010 11:16 PM Subject: Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1 Nick, Got it working on my USRP2 by changing to line 57 to: self.u = uhd.single_usrp_source(addr=192.168.1.15, uhd.io_type_t.COMPLEX_FLOAT32) and line 119 to: result = self.u.set_center_freq(freq,0) I'm getting 0 aircraft locations in the KML file but the stdout is as follows: (-40) Type 11 (all call reply) from e9fc9f in reply to interrogator 5 (-41) Type 11 (all call reply) from 2c4e09 in reply to interrogator 0 I assume these are Mode-S packets, thus no position info? -- View this message in context: http://old.nabble.com/gr-air-modes%3A-problem-with-uhd-and-USRP1-tp30326133p30336873.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] always a spike on the FFT at the center frequency
Whenever I run the userp_fft.py script (USRP1, Ubuntu 10.04 and 10.10), there's almost always a large spike (10-20 db above the noise floor) at the center frequency. This is the same for all the daughter boards I've tried (WBX, LFRX, and BasicRX). Why is this? What am I missing? Thanks. -William ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] always a spike on the FFT at the center frequency
On Wed, 2010-12-01 at 16:16 -0500, William Cox wrote: Whenever I run the userp_fft.py script (USRP1, Ubuntu 10.04 and 10.10), there's almost always a large spike (10-20 db above the noise floor) at the center frequency. This is the same for all the daughter boards I've tried (WBX, LFRX, and BasicRX). Why is this? What am I missing? DC offset. It's normal. If it's a problem just tune off center so your frequency of interest isn't at DC. --n Thanks. -William ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CPFSK grc block question ... problem with data types
Hello all,
I am having the following trouble with data types:
I have the following flowgraph working to record FM broadcasts:
{USRP2 source - LPF - FM Demod - File Sink}
Next, I am making another program to transmit the stored FM broadcast audio to
my handheld radio which expects FSK modulation. So I would like to do the
following:
{File source - CPFSK mod - LPF - USRP sink}
The problem is that the grc CPFSK block expects bytes. This means that the
recorded file has to have bytes, but the FM demod only outputs complex or float
data types. Is there a gnu radio function (or grc block) that converts floats
to bytes? Or is there a way to store the audio data as bytes in my first
program?
Thanks in advance for your help,
Mike
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
The problem is that I am in the middle of a project, time is of the essence and I don't have time to start stumbling around with UHD, right now I have to use Simulink, hence UDP. GnuRadio Companion still doesn't work with UHD, right (I am very new to python)? So no chance of UDP working with 2 USRPs at once, huh?! Let me ask you something else then, if I manage to synchronize 2 USRPs working on separate computers to start sensing a band of 16MHz each, and their central frequency being 16MHz apart, saving those two bands in a file , what block (system of blocks) can I use to compose a 32MHz band (and I mean the whole band not just their power measurements) from the two 16MHz halfbands originating from the From File blocks? Naturally the samplerate of the new signal should be the double of that of the halfbands. If I just use a 2:1 multiplex the halfbands appear superimposed and the resulting signal band still occupies 16MHz. Any ideas? Your help is really appreciated, Vlad. Marcus D. Leech wrote: On 12/01/2010 05:49 AM, Vladutzzz wrote: Thank you Marcus, for the very prompt and exhaustive reply! Mostly it's what I expected, but I am a wee bit worried about the IP addressing process: I need to change the IP of one of the USRP2 modules, how do I do that, considering I use an UDP FPGA image and not UHD? Also, what IPs should I use in the USPR2 source blocks, now that there's 2 of them? Thanks! Vlad. My advice would be to screw up your courage, bite the bullet, and convert to UHD. Theres a UHD utility, usrp2_addr_burner that can be used to change the IP address. The factory address is: 192.168.10.2, you'll need to change it to an address on a different subnet, like 192.168.20.2 or some such. The idea is that you have two GiGE ethernet ports, and you configure your system with the appropriate subnet on each ethernet port, and program your USRP2 addresses accordingly. -- 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 -- View this message in context: http://old.nabble.com/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30353714.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] CPFSK grc block question ... problem with data types
The CPFSK block expects digitally encoded data as bits. The file sink
will give you raw demodulated samples. You need to determine what format
your handheld radio expects to see before you can re-encode your saved
data appropriately. FSK describes a digital modulation scheme but says
nothing about the packet or stream format the radio expects.
--n
On Wed, 2010-12-01 at 13:42 -0800, Michael Civ wrote:
Hello all,
I am having the following trouble with data types:
I have the following flowgraph working to record FM broadcasts:
{USRP2 source - LPF - FM Demod - File Sink}
Next, I am making another program to transmit the stored FM broadcast
audio to my handheld radio which expects FSK modulation. So I would
like to do the following:
{File source - CPFSK mod - LPF - USRP sink}
The problem is that the grc CPFSK block expects bytes. This means that
the recorded file has to have bytes, but the FM demod only outputs
complex or float data types. Is there a gnu radio function (or grc
block) that converts floats to bytes? Or is there a way to store the
audio data as bytes in my first program?
Thanks in advance for your help,
Mike
___
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 + WBX How to use a 32 MHz signal band?
Per, At the moment we don't have a MIMO cable, so we're looking for alternative solutions until one makes its way to our lab :) Thank you for your suggestion though, it is much appreciated. All the best, Vlad. Per Zetterberg-2 wrote: On Tue, 2010-11-30 at 08:27 -0800, Vladutzzz wrote: I am interested in this 2 USRPs approach since I don't have the experience and the knowledge to start messing about inside the FPGA firmware code and have an extra USRP2. How would this go? I tried looking up some info about this topic but currently the ettus.com/... resources seem to be down. I've read some bits and pieces on a few forums. Most of the info is about having one USRP2 module as a transmitter and the other as a receiver. I want them both to be receivers(actually half a receiver) and to complete each other by receiving half of the 32 MHz band (so each would receive 16 MHz). How would the USRPs be connected to the same computer? How will the two 16 MHz bands be attached together to form the 32 MHz one (some kind of 2:1 multiplexing - I'm just guessing here)? I am aware of the great load exerted upon the system resources, but I'm trying to make this work anyway. Thanks. Vlad. My suggestion would be to connect the two USRP2s as a MIMO pair, but tune them with 16MHz offset relative to each other. Then you would need to design a way (a signal processing method) to merge the two streams together into a single wide-band stream. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30353755.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] USRP2 + WBX How to use a 32 MHz signal band?
On Wed, 2010-12-01 at 13:53 -0800, Vladutzzz wrote: The problem is that I am in the middle of a project, time is of the essence and I don't have time to start stumbling around with UHD, right now I have to use Simulink, hence UDP. GnuRadio Companion still doesn't work with UHD, right (I am very new to python)? GRC has always worked with UHD. You might try downloading the latest UHD and giving it a shot. So no chance of UDP working with 2 USRPs at once, huh?! No. Let me ask you something else then, if I manage to synchronize 2 USRPs working on separate computers to start sensing a band of 16MHz each, and their central frequency being 16MHz apart, saving those two bands in a file , what block (system of blocks) can I use to compose a 32MHz band (and I mean the whole band not just their power measurements) from the two 16MHz halfbands originating from the From File blocks? Naturally the samplerate of the new signal should be the double of that of the halfbands. If I just use a 2:1 multiplex the halfbands appear superimposed and the resulting signal band still occupies 16MHz. Assuming your signals are mixed to baseband you can interpolate both to 32Msps and mix one sideband up and the other down so they sit where they are supposed to, and then add the signals together. There's probably a smarter (faster) way to do it. --n Any ideas? Your help is really appreciated, Vlad. Marcus D. Leech wrote: On 12/01/2010 05:49 AM, Vladutzzz wrote: Thank you Marcus, for the very prompt and exhaustive reply! Mostly it's what I expected, but I am a wee bit worried about the IP addressing process: I need to change the IP of one of the USRP2 modules, how do I do that, considering I use an UDP FPGA image and not UHD? Also, what IPs should I use in the USPR2 source blocks, now that there's 2 of them? Thanks! Vlad. My advice would be to screw up your courage, bite the bullet, and convert to UHD. Theres a UHD utility, usrp2_addr_burner that can be used to change the IP address. The factory address is: 192.168.10.2, you'll need to change it to an address on a different subnet, like 192.168.20.2 or some such. The idea is that you have two GiGE ethernet ports, and you configure your system with the appropriate subnet on each ethernet port, and program your USRP2 addresses accordingly. -- 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] Gnu-radio + USRP problem
Thunder87 wrote: I'm still trying to get gr-ais going on Beagleboard (Lucid). When I tried to run ais_decode.py, I've got uOuOuO output. On PC everything works fine. My guess - BB simply can't process that much data. So I ran usrp_benchmark on BB to see if this was the problem. 2MB/s and 4MB/s went fine, but with higher data rates it started uOuOuO again. In web I've seen people chatting about some code optimizations for BB, which would allow DSP run faster. Could anyone help? I think http://elinux.org/BeagleBoard/GSoC/2010_Projects/FFTW#Build_Instructions this probably could help.. At least I'll give it a try )) -- View this message in context: http://old.nabble.com/Gnu-radio-%2B-USRP-problem-tp30349099p30353809.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] Tesla C2000 series and CUDA and Gnu Radio
On Wed, Dec 01, 2010 at 01:40:03AM -0500, Marcus D. Leech wrote: On a related note, has anyone looked at enabling the multi-threaded FFTW stuff? The cross-over points there (between FFTW in a single-thread and FFTW in multiple-threads) seem to be lower-down on the FFT-size curve. Marcus, I haven't tried it, but I'd guess that the crossover point is = 16K points. If you try it, let us know what you find. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_fft.py question and benchmark related question
Hi, Can we change the DDC value to 0 in usrp_fft.py? Why is this not 0 as one would expect to input the center frequency same as the baseband frequency; i.e. if I know that my signal is on a carrier at 2.4G then I would use usrp_fft.py to display the spectrum by having the center frequency as 2.4G instead of typing in 2.404G (as DDC is -4M). In benchmark_tx/rx programs do I have to account for this DDC=-4.0M? If one USRP is transmitting at 2.4G ( ./benchmark_tx.py -f 2400M ) then should I have the receiving USRP receiving at 2.404G ( ./benchmark_rx.py -f 2404M )? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tesla C2000 series and CUDA and Gnu Radio
Hi Marcus, Actually we are doing all our processing on the GPU. We use GNURADIO to bring in the data and then run everything on the GPU and only copy back the results. As you wrote in your mail CPU-GPU resp. GPU-CPU copies can be bottlenecks and should be avoided or reduced whenever possible. With the current blocks it only makes sense to utilize the GPU if ALL blocks are also available for the GPU. E.g. if you do a cross-correlation (as we do) it does not make sense to do the FFTs on the GPU, but do the complex multiplication on the CPU as there is a data-transfer GPU-CPU-GPU before you can run the IFFTs. For us the GPU is the device which enables our application to run in real-time, which we could hardly achieve with the CPU. But getting the GPU into GNURADIO is another story, I guess... Regards, Thomas On 12/01/2010 03:40 PM, Marcus D. Leech wrote: Is anyone out there taking another look at CUDA + Gnu Radio? Some of the couple-of-years-old charts I've looked at suggest that speedups for some of the most important transforms we use vary between modest and disappointing. Cross-over points for things like FFTs are usually up in the atmospheric levels of FFT sizes before a CUDA-based transform would win even slightly against a multi-threaded CPU-based FFTW, for example. But that was a couple of years ago. Anything new along those lines? It seems like the kinds of things that do well on a GPU are ones that take a small amount of input data, compute ferociously, and produce modest amounts of output data. Or schemes that might consume deluges of input data, but produce output data only occasionally--a flow that did a bunch of FFTs and produced averaged mag-squared outputs only once in a while might fare well on a GPU. On a related note, has anyone looked at enabling the multi-threaded FFTW stuff? The cross-over points there (between FFTW in a single-thread and FFTW in multiple-threads) seem to be lower-down on the FFT-size curve. -- ** Dr. Thomas Hobiger Space-Time Measurement Project Space-Time Standards Group New Generation Network Research Center National Institute of Information and Communications Technology -- 4-2-1 Nukui-Kitamachi, Koganei 184-8795 Tokyo Japan -- email: hobi...@nict.go.jp phone: ++81-042-327-7561 fax:++81-042-327-6664 -- homepage (priv.): http://www.hobiger.org ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Proper method to update GnuRadio
Is this the proper procedure to update and re-build the GnuRadio source? I'm using the next branch: sudo make uninstall make clean git pull ./configure make make check sudo make install I'd rather not uninstall before I have a successful build; maybe I don't have to. I tried make current, but there was no target for current. Should I rebuild GnuRadio if I updated and rebuild the UHD from Ettus? -- View this message in context: http://old.nabble.com/Proper-method-to-update-GnuRadio-tp30355298p30355298.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ofdm decoder problem on USRP2
Hi, I am trying to build the OFDM decoder on GRC based on the FTW 802.11a/g encoder. At the USRP2 receiver, after CFO compensation, I want to see the QPSK constellation. Basically, the process is: bit stream ofdm mod usrp2 sink usrp2 source -- timing offset comp --- CFO comp ofdm demod - constellation sink Before ofdm_demod, the signal spectrum observed in USRP2_fft is good as far as I know. But after OFDM demod block, I can not receive anything. No data output! :( I read some threads by Veljko, regarding to the parameter setting of OFDM demod block. But I am not sure about the number of tones, SNR. Where can I find the definition of this block? What is the meaning of S and Time out? By the way, my setup environment is ubuntu 9.04 + gnuradio 3.2.2. -- Regards, Guanbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Broken gr_fir_fff ?
Sorry if I can't provide any more debug info, I'm new and ignorant, but I updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now I'm getting two programs with duplicate failure in gr_fir_fff. They just dump back to the shell after 2 seconds with no debug info. Only thing I did in uhd_modes.py was add my ip addr to the uhd src, so I don't think it's modifications I have made. It was working fine last night, but I did update from the repo today. I made some modifications to usrp_flex_band.py to getting it working with the USRP2 and UHD However I made the same mods to usrp_flex.py and it works fine. usrp_flex_band.py uses a 40 channel filter bank which I reduced to 4, in an attempt to debug, since it was causing a core dump, but I think that's a separate issue of thread resources (see the third excerpt below). --- m...@lt6034239[/usr/local/src/gr-air-modes/src/python]$ ./uhd_modes.py -a -g 30 linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101201214203.8fc7521 Current recv sock buff size: 5000 bytes Setting gain to 30 Rate is 400 gr_fir_fff: using SSE m...@lt6034239[/usr/local/src/gr-air-modes/src/python]$ m...@lt6034239[~/gnuradio_apps/pager]$ ./usrp_flex_band.py -g 30 linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101201214203.8fc7521 Current recv sock buff size: 5000 bytes gr_fir_fff: using SSE m...@lt6034239[~/gnuradio_apps/pager]$ m...@lt6034239[~/gnuradio_apps/pager]$ ./usrp_flex_band.py -g 30 linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101201214203.8fc7521 Current recv sock buff size: 5000 bytes gr_fir_fff: using SSE terminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::thread_resource_error ' what(): boost::thread_resource_error Aborted (core dumped) m...@lt6034239[~/gnuradio_apps/pager]$ -- View this message in context: http://old.nabble.com/Broken-gr_fir_fff---tp30355695p30355695.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-air-modes: problem with uhd and USRP1
Nick Foster-4 wrote: On Mon, 2010-11-29 at 20:16 -0800, madengr wrote: Nick, Got it working on my USRP2 by changing to line 57 to: self.u = uhd.single_usrp_source(addr=192.168.1.15, uhd.io_type_t.COMPLEX_FLOAT32) and line 119 to: result = self.u.set_center_freq(freq,0) That's correct. The Github repo has the latest changes to make this work as well. May want to add an parser option string to specify the usrp source address; I have been editing the source code to add it. I believe the UHD documentation says if no address is specified then it uses udp to find the USRP2, however if a firewall is running (as is my case), then it will never find it and err out. http://www.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps -- View this message in context: http://old.nabble.com/gr-air-modes%3A-problem-with-uhd-and-USRP1-tp30326133p30355735.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] Broken gr_fir_fff ?
On Wed, Dec 01, 2010 at 08:05:51PM -0800, madengr wrote: Sorry if I can't provide any more debug info, I'm new and ignorant, but I updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now I'm getting two programs with duplicate failure in gr_fir_fff. They just dump back to the shell after 2 seconds with no debug info. It's unlikely that there's a problem in gr_fir_fff. What version of GNU Radio are you using? What OS, distribution and version? What hardware are you running it on? How much memory does the machine have? Is there anything interesting in /var/log/messages? If there are 100's of blocks in this graph, you may want to reduce the default stack size allocated for each thread. (Even if not used, the virtual address space is reserved.) # Output from an x86_64 machine running Fedora 13 $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63888 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 50 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited The default stack size is 10240k. You can probably reduce this to 4094k (or maybe 2048k) without a problem using: $ ulimit -Ss 4096 Using -S sets the soft limit, which means you can set it back up without being root: $ ulimit -Ss 10240 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] N210 8-bit mode and WBX bandwidth
Hi all, Two related questions: 1) In the datasheet for the N210, the specifications state 50Mhz instantaneous bandwidth in 8-bit mode. I was looking at otw_type.width in the UHD and I can't see an 8 bit mode there. Is 8-bit mode implemented in the fpga/firmware/driver for N210? If not, roughly how far ahead in the roadmap would it be? I apologise if this is a FAQ. 2) The WBX has a fixed filter; I can see in the UHD an indication it's fixed at 40Mhz. Would it be hard to modify the daughterboard to provide 50Mhz of bandwidth? Thanks and regards, Blair. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
