That low power level does not sound right. The power level at the tx
connector should be around 20 dBm.
Note the we recommend terminating the transmit connector to prevent
unlawful emissions. Plenty of power leaks out of the USRP for
desktop testing, even with a termination. Absolutely d
You were right, I did not have a Fortran compiler installed. I installed g77
but still get the same error. I also checked
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/
and there is Python.h in that directory.
Here is a part of config.log
Thanks,
Ilya
config
On Fri, Aug 07, 2009 at 06:52:41PM -0400, Jonathan Coveney wrote:
> It looks like I needed to change the decimation rate. Since cfile uses 16, I
> tried 16 on the side of the demodulator (instead of 200, which is the
> default), and it worked. Is this how it should be? One thing that does
> happen
Milo Wong wrote:
> So, I am going to encode the analog output of audio source(float, -1
> to +1 ??) to digital bit streams(byte) for digital signal Processing
> later on.
What exactly are you trying to accomplish? The samples you get from an
audio source, like any other GNU radio source, have alrea
And it looks like by setting the throttling rate equal to the
adc_rate/decimation rate, I sample the file at the same rate the samples
were written,a nd everything works perfectly. If anyone has anything to say,
though, I do appreciate it.
ON THAT FRONT, though, two things remain:
a) would it be
It looks like I needed to change the decimation rate. Since cfile uses 16, I
tried 16 on the side of the demodulator (instead of 200, which is the
default), and it worked. Is this how it should be? One thing that does
happen is that it KILLS my computer's processing, which I assume the
throttle sho
Hi all,
Here I have a question regarding data type conversion in GRC. Since the
output of audio source is analog signal. So, I am going to encode the analog
output of audio source(float, -1 to +1 ??) to digital bit streams(byte) for
digital signal Processing later on. But I found there's no ADC or
Oops, it's attached now
2009/8/7 Jonathan Coveney
> So, the program will run, but instead of hearing anything, I just get oX
> over and over again.
> http://gnuradio.org/trac/wiki/UsrpFAQ/Gen#OUuainoutput
> It doesn't look like a normal error, and doing a search, I haven't seen it
> before.
>
>
So, the program will run, but instead of hearing anything, I just get oX
over and over again.
http://gnuradio.org/trac/wiki/UsrpFAQ/Gen#OUuainoutput
It doesn't look like a normal error, and doing a search, I haven't seen it
before.
./filesource_fmmod.py
>>> gr_fir_ccf: using SSE
>>> gr_fir_fff: us
-- Forwarded message --
From: Josef Vukovic
Date: 2009/8/7
Subject: Re: [Discuss-gnuradio] OSX configure error
To: "Chukhman, Ilya A."
2009/8/7 Josef Vukovic
>
> 2009/8/7 Chukhman, Ilya A.
>
>> I am having a similar problem. Have you been able to resolve this
>> error?
>
-- Forwarded message --
From: Josef Vukovic
Date: 2009/8/7
Subject: Re: [Discuss-gnuradio] OSX configure error
To: "Chukhman, Ilya A."
2009/8/7 Chukhman, Ilya A.
> I am having a similar problem. Have you been able to resolve this error?
>
> Thanks,
> Ilya
>
No, I am still
Hmmm, didn't I send a patch out way, way, back (last summer?) to convert the
multi_usrp.py code to hier_block2? Perhaps I forgot to hit the send button.
I can't find it in a quick search just now. FWIW, I don't remember ever
getting the multi_usrp_oscope working, but I was mainly working with
multi
Hi All:
I have made changes in the digital-bert folder of GNURadio-3.2.2 for my
system to work with USRP2. I have been able to successfully transmit using
the benchmark_tx.py script. However even after making changes in the
receiving scripts (benchmark_rx.py & usrp_receive_path.py) on the same lin
On Fri, Aug 7, 2009 at 12:49, Jonathan Coveney wrote:
> I can't find one. The _cfile.py files will save samples to a file of my
> specification, but I am trying to test using said samples, and not
> succeeding. If it does not exist, I tried this:
>
> #self.u = usrp.source_c()
On Fri, Aug 07, 2009 at 12:16:31AM -0500, Mir M. Ali wrote:
> Hi,
> I have a problem installing gnuradio on Centos-5. I installed fftw-3.2.2 and
> ran the configure script in gnuradio. It shows this error as it cant find
> the fftw3f.
>
> ecking for FFTW3F... configure: error: Package requirements
On Fri, Aug 07, 2009 at 09:13:52AM +0200, Moritz Fischer wrote:
> Hi all,
>
> after some time searching through the list archives I was not able to
> find out what happened to the multi_usrp.py file which is needed to run
> the the multi_usrp/multi_usrp_rx_cfile.py and
> multi_usrp/multi_usrp_rx_o
I can't find one. The _cfile.py files will save samples to a file of my
specification, but I am trying to test using said samples, and not
succeeding. If it does not exist, I tried this:
#self.u = usrp.source_c()# usrp is data source
self.u = gr.file_source(gr.s
> I have never seen that problem before, but I use 10.1.03, not 11.1. Are
> you just trying to build the SVN release? Are you able to use 10.l
> instead of 11.1?
>
> The problem looks like it's in the Xilinx FIFO core, so maybe if you
> rebuild it with coregen from 11.1 it will work better.
>
On Fri, Aug 07, 2009 at 05:22:16PM +0200, hanwen wrote:
> Hi *,
>
> In usrp_wfm_rcv.py there are two status bar at the bottom of the window, the
> left one showing the result of tune frequency while the other shows the gain
> and volume.
> But in my program I always cannot get two status bar but t
Alan Zubatch wrote:
Hello,
I am trying to implement the USRP2 FPGA HDL using Xilinx ISE 11.1. I have
set-up the file structure and the project options per the makefile for
U2_rev3. It will synthesize and translate (39 BRAM) but fails map with
44BRAM. The BRAM usage at map failure is:
Alan,
checking for Python include path... /opt/local/Library/Frameworks/
Python.framework/Versions/2.5/include/python2.5
checking Python.h usability... no
The PYTHONPATH and rest of 'env' look OK. If you do:
ls /opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/
python2.5/.
do
>> checking whether we are using the GNU Fortran 77 compiler... (cached) no
I'm about 90% sure that the check for python.h uses a fortran script,
and configure fails when the fortran fails. If you don't have fortran
that my be why that step is failing.
Check your config.log for errors pertaining
Hello,
I am trying to install gnuradio and have been following the instructions on
https://radioware.nd.edu/documentation/install-guides/mac-os-x. When running
the ./configure I receive the following error:
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... (ca
Hi *,
In usrp_wfm_rcv.py there are two status bar at the bottom of the window, the
left one showing the result of tune frequency while the other shows the gain
and volume.
But in my program I always cannot get two status bar but there is only one.
I checked the code and cannot find how to set up t
Yes, Iam using this guide :-)
X11 don't helps there are the same errors from runnign ./configure
My .basrc is configured like sugestet in the RadioWare guide.
Please Help :-( me.
2009/8/6 Jonathan Coveney
> Yeah, if it's pointing do 2.3 that should definitely be a problem
>
> Are you using this
2009/8/7 Colin Stagner
> Josef Vukovic wrote:
> > Probably the error is in the PYTHONPATH variable, I installed python
> > 2.5 and in the environmentvariable is mentioned python2.3
> >
> > How can I fix this ?
> Look in ~/.bashrc (if it exists) or ~/.bash_login. You can view these
> files in Tex
Hi all,
after some time searching through the list archives I was not able to
find out what happened to the multi_usrp.py file which is needed to run
the the multi_usrp/multi_usrp_rx_cfile.py and
multi_usrp/multi_usrp_rx_oscope.py in the examples directory.
I found in the svn log, that they haven
27 matches
Mail list logo
