-source producing a SIN wave at, let's say, 1KHz, feed that
into a UHD/USRPx sink tuned to whatever your frequency is.
The tone will appear at TUNED-FREQUENCY+1KHz.
On Mon, May 16, 2011 at 10:02 AM, Marcus D. Leech mle...@ripnet.com
mailto:mle...@ripnet.com wrote:
On 16/05/2011 10:26
On Mon, 2011-05-16 at 15:34 -0500, John Andrews wrote:
I am running it at 2.5GHz.
What magnitude are the samples you're feeding into the USRP sink?
--n
Also, by default the RFX2400 has a TX filter that's centered at 2.441GHz
and about 85Mhz wide at the 3dB points. So, there'll be some
-I'm also running OS11.4.
OS11.4 KDE by default uses pulseaudio as audio-system which might cause
some trouble there :), especially if you haven't installed ALSA or OSS.
If you change to ALSA direct, you'll have the problem that GNURadio
wants the audio hardware exclusively for itself, which
flowgraph with USRP sink and FFT
block only.
USRP Sink:
1. Decimation - 64
2. Frequency - 2.5GHz
3. Gain (dB) - 10
FFT sink has proper settings too.
I am not using any filters as I hope the SNR is high enough.
Thanks
On Mon, May 16, 2011 at 3:47 PM, Marcus D. Leech mle...@ripnet.com
mailto:mle
On 05/16/2011 09:22 PM, Josh Blum wrote:
Aha, no clocking options were implemented on USRP1. Thats why you see
the error. I suppose it would be better to properly handle setting clock
config even though its not really configurable.
-Josh
___
On 05/16/2011 09:50 PM, Josh Blum wrote:
no, many of the parameters when left default yield no code. Part of the
goal of generating nice simple readable code.
-Josh
Hmmm, this will require some thinkage. I just ran into a *similar*
problem when running
Tom's uhd_fft.py on a BASIC_RX,
On 05/16/2011 10:22 PM, Josh Blum wrote:
The UHD should handle all cases and throw a reasonable error like no
antennas to select. Those neglected properties should be filled in for
the sake of completeness.
Whether or not to use an empty string as a pass-through, not so sure.
It seems
What it seems to come down to is a lack of initiative. We are all
willing to wait until someone else does something for us, and then
report on the problems. But it's hard to start something and push it
out there. First, you expose yourself to criticism and bug reports.
You might feel
On 19/05/2011 3:13 PM, Bastien Auneau wrote:
why should I use set_time_next_pps() ? Is it needed to init USRP lock to
GPS time ?
Keep in mind that the PPS support pre-dates the existence of an in
skin GPSDO, and the
*primary* purpose of the GPSDO is to provide a stable 10MHz reference
clock
On 19/05/2011 1:21 PM, Robert McGwier wrote:
Vlad
It is apparent to me that you did not understand Josh's explanation.
Possibly he was not forceful enough. ;-).
This is not an error. It is the mathematical consequence of doing QAM
with rotational symmetries. YOU MUST provide your OWN
On 05/19/2011 09:49 PM, ikjtel wrote:
We're assuming that the design specs for our app say that:
USRP underruns are totally unacceptable
(is this a realistic goal to have in the real world?)
While extended underruns are problematic, a short underrun should be
equivalent to
a
On 05/19/2011 11:51 PM, ikjtel wrote:
Yep - it just so happens that these are digital (P25) channels,
not analog ones, but robust detection/correction protocols at the
higher levels are there to cope with the occasional glitches...
If they fly through the aether, they're analog. Once a
On 05/24/2011 01:26 AM, Eddie Sun wrote:
Hi list,
I have a USRP N210, running on Ubuntu-10.04, when I try to use the
Gnuradio-Companion to make a fm_receiver,
I success generate the python code, but when i try to run it,
it shows
Hi,
There is some information on the mathworks site for this
http://www.mathworks.com/help/toolbox/comm/ref/a1083164701.html#bsnml9_
http://www.mathworks.com/help/toolbox/comm/ref/usrp2receiver.html
http://www.mathworks.com/support/solutions/en/data/1-CUN7JZ/?solution=1-CUN7JZ
On 25/05/2011 12:01 PM, Marc Epard wrote:
On May 25, 2011, at 9:14 AM, Josh Blum wrote:
2) Calibrate the setup. After you tune, the daughterboard LOs will have
different constant phase offsets.
In my experience (with a WBX in a USRP2 and a DBSRX2 in an N210), the phase
offsets can change
Alexander is asking excellent questions and I'm surprised at the tepid
response -- he's got like 4 replies so far? He's the prototype GNU
radio user who needs to maintain his group's IP, he should be
receiving how to's, not INALs. -Jeff
Actually, IANAL is a perfectly-valid response. IP
On 05/25/2011 09:01 PM, Arturo Rinaldi wrote:
i have an issue regarding the SDCC executable in the building of
gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as :
/export PATH=/usr/libexec/sdcc:$PATH
/as written in the build guide but I still get the error in the
Thank you for answering but I cannot understand what you mean with The USRP
is not a measurement receiver. If USRP was not a measurement receiver,
which is its utility? Moreover, if it is not a measurement receiver what is
the result memorized in m.data that is the output of
On 26/05/2011 9:55 AM, Michael Dickens wrote:
It would be great if you could share with the list example code snippets of how
you do the pipes. For example: Where in an online repository one can find such
code.
I think that's what Jeff was getting at: that we are providing IANAL advice
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes the USB on the host system to
freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
On 05/26/2011 08:06 PM, Nick Foster wrote:
The alignment I'm talking about wasn't even relative between RX and TX-
it was between branches of the RX path such as the real and imaginary
components of that path when viewed on the scope.
So, you're talking about splitting I/Q for the
By default Gnu Radio now schedules each block in its own CPU thread. So
there could be
differences in instantaneous latencies down each path.
Also- whether a data is processed at the same time in terms of physical
timeslices in the real world isn't so important, but by
So after discovering that while I had libusb-devel-0.1 and
libusb1-devel-1.0.3 installed on my RHEL-6 machine here (and ubuntu),
gnuradio compiled against 0.1 despite 0.1 being ancient and
unsupported. I then removed libusb-devel and gnuradio fails to configure.
I believe that Gnu Radio
The issue isn't duration- its when the flowgraph shuts down- as the
other thread from someone else is experiencing- it seems to be when the
flowgraph calls lock()/unlock() and stop(). It also only occurs on
bi-directional flowgraphs. But I do agree that there's an improper
shutdown- though I
How do the companies write closed-source drivers for the Linux Kernel
without running into GPL2 issues? I can only recall that there is a
user-land and a kernel-land driver, where the kernel-land is the
only part that is open source. Is this correct?
Perhaps that method could work well?
I
Cool! It would be truly great to see a simplified example of this in
the GnuRadio repository, and at least somehow mentioned on the wiki.
Yes, I suppose it would. I'll put it on my list, but so many other
things to do :-(
The other trick that I use is to use the XMLRPC server stuff that Josh
Problem here is that FIFO's are not very well suited for real-time
operation, IIRC. Have you tried a shared memory and shared signals
across applications?
It depends on what you mean by real time. Certainly FIFO I/O will be
slower than
intra-flowgraph ring buffers, but not so horribly
Real-time is not about performance, but about predictability ;) I have
to be sure that my flowgraph always executes before the deadline is
hit. So everything that introduces jitter is a no-no.
In general, Gnu Radio executes on general-purpose OSes, which means that
there will *always* be
Is there information about what is the biggest latency-injector in GnuRadio?
Nearly all of the basic computational blocks are as blazing-fast as they
can be on a general-purpose
CPU. The biggest latency injector is the scheduler in general, and
the buffer management part of
that scheduler
Hi all,
I'm not sure whether to post this to GnuRadio or to USRP-users, so I
post it here.
We've started a project to implement a custom SDR hardware (which we
plan to open-source later) and we want to reuse as much of USRP FPGA
code as possible. But it will require a good deal of customization
I evaluated latency of a FIFO (actually an ordinary pipe, but the kernel
mechanisms are identical), and measured 30usecs average on my
1.2GHz AMD Phenom system with plenty 'o memory.
I sent timestamps across the FIFO (struct timeval), and the reader
grabbed the local time of day, and
On Sat, May 28, 2011 at 22:06, Marcus D. Leechmle...@ripnet.com wrote:
I evaluated latency of a FIFO (actually an ordinary pipe, but the kernel
mechanisms are identical), and measured 30usecs average on my
1.2GHz AMD Phenom system with plenty 'o memory.
I sent timestamps across the FIFO
On 05/28/2011 03:11 PM, Brett L. Trotter wrote:
I just discovered the not well published --with-fusb-tech=libusb1 option
to configure, hoping to resolve the USRP1 non-uhd crashing issues myself
and one other person are seeing when the flowgraphs do a lock or stop.
Unfortunately, I still see the
On 05/28/2011 06:28 PM, Josh Blum wrote:
Just want to throw this out there because it seems relevant:
http://gnuradio.org/cgit/jblum.git/tree/gruel/src/include/gruel/high_res_timer.h?h=wip/high_res_timerid=71b911d28a391ad0c67540e3658a6680d7449e1f
Yup, I know about clock_gettime().
But
On 05/28/2011 04:28 PM, Alexander Chemeris wrote:
So, while this method is simple and good for non-realtime
applications, it doesn't fit our needs. It may be usable for PHY-MAC
interaction, but even here I'm not sure it would work well.
PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff
I thought the 1 thread execution scheduler was deprecated in gnuradio?
al fayez
You may still turn it off, but the TPB scheduling policy is now the default.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On 05/29/2011 04:50 PM, John Andrews wrote:
Hi All,
I want to know what is the signal coming from the USRP onto the USB
bus. I know that the received signal is a baseband signal and assuming
complex sampling (I have RFX2400 daughterboards) each complex sample
that enters the USB bus is the
On 30/05/2011 8:20 AM, Johannes Schmitz wrote:
The error is coming from the kernel. Can you describe your system setup?
We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
Every time we get the fusb error :(
It seems we have to throw away our USRP1's and move to USRP2...
Johannes
On 30/05/2011 9:41 AM, Johannes Schmitz wrote:
we did not try it under UHD.
Honestly I don't have any experience with UHD.
But do you want to say that the traditional API is not supported anymore?
If yes, what is the best way to get started with UHD?
Johannes
The traditional API is no longer
On 30/05/2011 9:51 AM, Alexander Chemeris wrote:
Linux' pipe implementation is known to be quite slow. I would suggest to
use UNIX sockets instead. They should perform much better in terms of
latency and performance.
Good idea.
I'm dubious of such a claim--the core mechanisms between
I used the following two little programs:
unixdomain.c ==
#include stdio.h
#include sys/socket.h
#include sys/un.h
#include unistd.h
#include string.h
#include sys/time.h
#include time.h
int
main (void)
{
struct sockaddr_un address;
int socket_fd, nbytes;
char
On 05/30/2011 07:29 PM, Thomas Tsou wrote:
On Mon, May 30, 2011 at 5:20 AM, Johannes Schmitzjsem...@gmx.de wrote:
We tried to run the code on Ubuntu 10.04, 10.10 and 11.04.
Every time we get the fusb error :(
It seems we have to throw away our USRP1's and move to USRP2...
I'm not able to
Hi,
I was running uhd_fft.py on USRP N210 with TVRX2 daughter-board. I get
mysterious peak at every 100 MHz center frequency i.e. 100MHz, 200
MHz, even though no antenna is connected. Please help me what is wrong.
Thanks you,
Rahul
Two things:
There is almost always an anomaly near
On Mon, May 30, 2011 at 6:26 PM, Brett L. Trotter br...@webtrotter.com
wrote:
I've seen the error with both fusb tech libusb1 and 0.1 as well as on
various desktops and laptops and operating systems from various vendors.
For what its worth, our USRPs are low serial number (no software
On 05/31/2011 10:15 AM, vanITA1082 wrote:
Thanks.
However we are trying to transmit a packet from a usrp n210 to another usrp
n210 and we are searching for examples do to this simple operation.
How is it possible that are not out there? Do you know any source of simple
examples?
Thanks
On 05/31/2011 08:07 PM, hafiz zimran wrote:
Thanks for help.
I have installed C++ Compiler and followed the instructions as given in
http://www.ettus.com/uhd_docs/manual/html/build.html
Now I have connected usrp2 to PC ( Ubuntu 10.04, gnuradio-3.2.2) and
run the command sudo uhd_find_devices
On 06/01/2011 03:41 PM, Thomas Arcuri wrote:
Hello all,
Currently I am testing a modified version of tunnel.py, but I am
seeing some strange results. My modifications were essentially a
re-factoring to prepare for future additions, however somehow I was
able to receive a transmitted packet
On 06/01/2011 10:10 PM, Yang wrote:
Oh, my problem is the same with yours: I want to change transmit
frequency according to the sensing result from rx side. I tried lock()
and unlock() but cannot work.
You know that you can change frequency at any time, right? You don't
have to lock the
On 06/01/2011 10:35 PM, Yang wrote:
I see you mention your rx and tx chains running at the same time, is
it possible?
Absolutely! As long as the underlying hardware supports full-duplex
operation.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On 06/01/2011 11:07 PM, Yang wrote:
Would you like to expand it in detail or refer me to some places I can
look for? Dose this need 2 antennas on 1 daughterboard? It would be
great if I can build a graph with rx path and tx path and run 2 paths
simultaneously.
Yes, you'll need two antenna,
On 06/02/2011 03:01 AM, mehmet kabasakal wrote:
Hi Marcus,
May i ask you how you calculate the freq error i.e. 12.5 ppm ?
Is there a formula?
Mehmet.
Just take the error in Hz, divide by the expected frequency, and
multiply by 1.0e6
--
Principal Investigator
Shirleys Bay Radio
On 06/02/2011 07:10 AM, Mike Clark wrote:
This comes from a discussion over on the USRP-users mailing list, but
I felt it would be more appropriate to post here. Over on that list,
someone was asking about problems they were having consistently
receiving data on their USRP. My background is in
On 06/02/2011 03:06 AM, rahul sol wrote:
Hi,
first of all thanks very much for the quick reply. Now, I used
XCVR2450 with USRP N210 to receive signals transmitted from network
analyzer. The peak of fft exactly followed change in frequency of
network analyzer.
Additionally, I used TVRX2
On 03/06/2011 12:17 PM, Josh Blum wrote:
Using a USRP1 w/ WBX dboard and UHD, what is the proper way to disable (and
then re-enable) the receiver?
I usually don't think to disable the receiver. Running the transmitter
on demand and always running the receiver is a fine model of use.
Perhaps
On 03/06/2011 12:11 PM, Vlad Stoianovici wrote:
Dear list,
I get a strange error when trying to compile a GRC model:
-- Opening a USRP2/N-Series device...
Traceback (most recent call last):
File /home/vl/GnuRadio/Surse/top_block.py, line 43, inmodule
tb = top_block()
File
On 06/03/2011 04:02 PM, Brenden Smith wrote:
Hello everyone, I am new to GNU Radio and the USRP2, but I have been
playing around and have successfully made a FM receiver. I have a few
questions:
1) When I am receiving AM radio frequencies and demodulating them with
the AM demod block I get
I've found it impossible to create a half-duplex transceiver with WBX
and one antenna in grc. Would an open valve in the transmit chain stop
the transmitter and enable the receiver, or would a closed valve in
the receiver automatically stop the transmitter? I've experimented
with several
Yea, you cannot send samples when you dont want to transmit. There isnt
really such a concept of that in GRC itself, but you certainly can
implement the blocks and control logic and connect them in grc. Someone
should make interesting use of those tagging features as well. :-)
-Josh
Can
Yea, you cannot send samples when you dont want to transmit. There isnt
really such a concept of that in GRC itself, but you certainly can
implement the blocks and control logic and connect them in grc. Someone
should make interesting use of those tagging features as well. :-)
-Josh
\
On 06/04/2011 01:52 PM, Kresimir Dabcevic wrote:
Hi list!
Is it possible to measure RSSI on RFX2400 with N210 motherboard (UHD
drivers)?
From the archives, it seems that read_rssi() is defined only for
XCVR2450,
and read_aux_adc(side,0) described on
On 06/04/2011 02:04 PM, Josh Blum wrote:
There is an rssi sensor:
http://www.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series
from the uhd api:
usrp-get_rx_sensor(rssi)
or in python w/ gr-uhd
usrp.get_dboard_sensor(rssi)
A disadvantage to the get_rx_sensor(rssi) approach is that only
On 06/04/2011 03:58 PM, Marcus D. Leech wrote:
A disadvantage to the get_rx_sensor(rssi) approach is that only some
of the daughter-boards have that (analog) function, and also,
the RSSI is generally sensed at the bandwidth of the RF input to the
down-converter chip, rather than at your
Thanks for the answers Marcus.
How can I fetch my whole signal stream from RX in order to perform
computations
with it - copying just first N elements that come from usrp source with
gr_head or is there another method?
Regards,
Kresimir Dabcevic
All the calculations I mentioned
Hello list,
I'm having a lot of trouble here while trying to make openBTS work with my
USRP1
to play with GSMs.
First of all, a little description of my setup:
Software:
openbts-2.6.0Mamou
gnuradio v3.4.0git-130-g207a2ae7
UHD from git
OS: ubuntu 11.04
# sudo lsusrp
USRP 0 serial
On 07/06/2011 9:58 AM, Eduardo Lloret Fuentes wrote:
Hello.
Can this variable step_size have an arbitrary value? I tried several
times and I always get this message:
(python:3293): Gtk-CRITICAL **: IA__gtk_range_set_range: assertion
`min max' failed
and nothing at the USRP2 output
On 07/06/2011 9:58 AM, Eduardo Lloret Fuentes wrote:
Hello.
Can this variable step_size have an arbitrary value? I tried several
times and I always get this message:
(python:3293): Gtk-CRITICAL **: IA__gtk_range_set_range: assertion
`min max' failed
and nothing at the USRP2 output
On 06/08/2011 12:52 PM, Josh Blum wrote:
here ya go
http://gnuradio.org/cgit/jblum.git/commit/?h=uhd/grc/more_channelsid=593e4b643956b2439fd2d3ac919ac5c8e95d
I'm immediatelygoing to apply this patch, since it apparently increases
my number of motherboards without my having to
send
On 06/08/2011 12:03 PM, Nick Foster wrote:
No coaxial cable should act as an antenna except through shield leakage,
which is VERY low, especially at low frequencies. To verify that this is
the case, attach a 50 ohm SMA termination to the end of your coaxial
cable and measure the amount of signal
On 06/08/2011 09:51 PM, Morgan Redfield wrote:
Ok. I found another problem in my code. The transmit_path has a
multiplier in it that was set to 200 (it could go up to 32768). This
was for the original USRP, but I think UHD needs a signal with
magnitude=1. It seems like the signal was probably
Dear GNU Radio list's members,
I have a set of USRP2+XCVR2450 with the host computers configured with
the *GNU Radio classic drivers* (v.3.3.0).
My main idea is to transmit and receive data through a wireless
connection between the USRP2s. For now, I'm unaware of the PHY
technology but the only
On Thu, Jun 9, 2011 at 12:48 AM, hafiz zimran zimra...@yahoo.com
mailto:zimra...@yahoo.com wrote:
Hi
would u please guide me to upgrade GNURadio software from 3.2.2 to
3.3.0 in Ubuntu 10.04 using Synaptic Package Manager.
Best regards
Zimran Rafique
Version 3.3 is not
On Wed, Jun 8, 2011 at 11:24 PM, Morgan Redfieldredfie...@gmail.com wrote:
I found that centering my FFT on a frequency that's offset from what
I'm transmitting at will remove that central spike. I was able to
finally see the gap in the center of the OFDM boxcar and adjust that.
It looks like in
On 06/10/2011 06:11 AM, Songsong Gee wrote:
I have some difficulties on installing gnuradio and companion with uhd
After struggling with uhd, people advised me to use pre-made
build-gnuradio script
(http://www.sbrac.org/files/build-gnuradio
in
Hi,
What happens to the incoming data from USRP, over the USB bus, when a
gnuradio block takes a lot of time to process its output? Is the data
buffered indefinitely or is it dropped as new samples come in case the
consumption rate is slow.
Thanks
That's what's called an overrun. Data gets
Is the data coming in the buffer FIFO? Is there a way to keep track of
how much data is lost?
Yes, the data are delivered FIFO.
In UHD, you can arrange for there to be timestamps on the data, so you
could look at the data and detect interruptions in the
monotonicity.
As long as overruns
On 14/06/2011 2:52 PM, Tiago Rogério Mück wrote:
Hi,
Have anyone taken a look at this ?
We are still struggling to find a solution to this problem. Any tip
would help a lot.
Thanks,
Tiago
Em 27 de maio de 2011 16:51, Tiago Rogério Mück ti...@lisha.ufsc.br
mailto:ti...@lisha.ufsc.br
Looks like volk/config.guess and volk/config.sub got added to the GIT
repo, and since these are artifact files--that is, files that are
generated *locally* during configuration, GIT now gripes about them
when you do a git pull. They shouldn't appear in the repo
at all, as far as I can
On 06/18/2011 11:33 PM, Johnathan Corgan wrote:
The volk build did not have these in the repository until a few weeks ago.
Johnathan
Well, their presence is causing git pull to balk.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On 06/19/2011 02:34 AM, Johnathan Corgan wrote:
On Sat, Jun 18, 2011 at 20:52, Marcus D. Leech mle...@ripnet.com
mailto:mle...@ripnet.com wrote:
Well, their presence is causing git pull to balk.
Just delete your local copies (or symlinks) of config.sub and
config.guess (in volk
On 20/06/2011 10:05 AM, vanITA1082 wrote:
I am going more deeply into the OFDM example, however I cannot figure out
which is the bit rate of the usrp.
I mean, I know and I can set the bit rate of my application but how fast the
packets are sent out by the usrp?
How can I evaluate the throughput
On 21/06/2011 9:28 AM, John Ackermann N8UR wrote:
In GRC I would like to combine the outputs of several NBFM modulator blocks to
drive a USRP sink. The idea is to output several discrete channels within the
USRP transmit bandwidth, e.g., three signal channels at -30 kHz, 0 kHz, and +30
kHz
On 21/06/2011 12:05 PM, Alexandru Csete wrote
Sorry, I meant multiply with a complex sine or cosine wave of
frequency f, where f is the offset.
Marcus suggested using filters, which will also work but it's a bit
overkill for a simple translation, isn't it?
Alex
Yes, it's overkill, but I
On 06/21/2011 04:40 PM, John Ackermann N8UR wrote:
Thanks, Nick. I missed the sample rate factor because I was thinking of USRP1.
I'll fix that and the fallacy of adding rates, and try again.
Thanks,
John
I have an example, in GRC, attached.
It uses an audio source, which is common to
On 06/21/2011 05:33 PM, Tom Hendrick wrote:
Hello all, I am helping a colleague with the USRP center frequency
tuning functionality and it is my understanding the signal must
contain I and Q values centered at 0Hz.
A real valued signal is generated independently by another program and
is fed
On 06/21/2011 05:33 PM, Tom Hendrick wrote:
Hello all, I am helping a colleague with the USRP center frequency
tuning functionality and it is my understanding the signal must
contain I and Q values centered at 0Hz.
A real valued signal is generated independently by another program and
is fed
On 23/06/2011 8:32 AM, Ralf Wierse wrote:
Hi Jason,
thanks but I am a little confused.
I would say it is in the same process since I have sink and source in the same
GRC setup. The failure shows up when the generated python script instantiates an
UHD devices the second time as far as I
On 23/06/2011 2:31 PM, Nick Foster wrote:
Why would you set the amplitude of the preamble differently than the
actual data?
--n
In the hopelessly-naive assumption that the preamble can be made to be
perfect through brute-force transmit power.
Like you observed earlier, correlation is the
On 23/06/2011 3:03 PM, Colby Boyer wrote:
Or operate your receiver at absolute zero so there is no thermal noise? :D
Infinite SNR. Must have :-)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On 06/23/2011 06:50 PM, sumitstop wrote:
I am using ubuntu Lucid 10.04 LTS.
Did the following thing
Step-1 Installed all the dependencies for ubuntu Lucid 10.04 from the script
given here
http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall
step-2 git clone
I'm working on a multi-channel radiometer, based on USRP2 with the
dual-DDC feature.
I'm trying to come up with channelizing structure that won't overwhelm
my CPU--I'm using
a 6-core Phenom II 1055T, with 4GB of 1333MHz memory.
I need to be able to carve-off 4 channels, with widths between
On 06/24/2011 01:14 AM, Colby Boyer wrote:
Hi Marcus,
Check out a pfb channelizer!
gnuradio-core/src/python/gnuradio/blks2impl/pfb_channelizer.py is a
nice python wrapper for the class and gr_pfb_channelizer_ccf is the
C++ name.
Also if you need to carve out a a shifted part of the
On 06/24/2011 03:03 AM, Eddie Sun wrote:
Thanks for the reply, but i still have some questions.
2011/6/21 John Andrews gnu.f...@gmail.com mailto:gnu.f...@gmail.com
A USRP is a baseband IF receiver. Tune it to the GPS L1 frequency
with the right decimation rate so that you have your
On 24/06/2011 11:45 AM, Patrik Tast wrote:
Hi All,
I can not see in source code where GR is setting the TVRXx gain. I'm
referring to
gnuradio-core/src/lib/io/microtune.cc
If so (not set), what does it default to, max? See page 12 and
forward. The tuner document can be found at
On 24/06/2011 1:06 PM, Patrik Tast wrote:
It came from a VERY old traditional GR build.
I thought *no changes there in source code init stage was altered*
after moving on to uhd, I was wrong.
Time for me to upgrade from trad to uhd. Latest git trad compile
does serve my needs still 100%
On 06/26/2011 02:31 AM, sumitstop wrote:
Today when I tried to install Gnuradio by Marcus Script I got following
message.
Fetching Gnu Radio via GIT...GIT checkout of Gnu Radio failed!
Yesterday it was working fine and I installed it on my two Pc's.
Sometimes the GIT server that hosts the
On 27/06/2011 11:08 AM, sumitstop wrote:
Hi Marcus its more than 48 hours now and still the same message :(
Continuing with script
Installing pre-prequisites...Checking for package libfontconfig1-dev
Checking for package libxrender-dev
Checking for package libpulse-dev
Checking for package swig
On 27/06/2011 3:29 PM, Christopher Dean wrote:
Hi Sumit,
There are two links that we can use to access the current version of
the GNU Radio source: git://gnuradio.org/gnuradio and
http://gnuradio.org/git/gnuradio.git .
As of now, the second link does not work for me, but the first one
On 28/06/2011 12:20 PM, sumitstop wrote:
Hi Marcus
Even after several trials the script exits
giving following error .
Fetching Gnu Radio via GIT...Done
Fetching UHD via GIT...Done
Building UHD...Done building/installing UHD
On 28/06/2011 12:20 PM, sumitstop wrote:
Hi Marcus
Even after several trials the script exits
giving following error .
Fetching Gnu Radio via GIT...Done
Fetching UHD via GIT...Done
Building UHD...Done building/installing UHD
On 06/28/2011 04:44 PM, sumitstop wrote:
Hmmm now it is at least echoing the reason for exiting :)
Could not find appropriate file to download Perhaps the \downloads\
directory structure at ettus.com has changed or is currently invalid
Again the same step by step build :(
I hope it will be
1101 - 1200 of 2855 matches
Mail list logo
