Thanks Dan
Yeah the magic number seemed to be a rate around 300kbps. Getting really good
results now.
Thanks again,
-Joe
In my experience the USRP stops performing very well at low bitrates.
This is due to the current code's inability to handle large frequenc
On Mon, Oct 01, 2007 at 06:07:51PM -0700, Tim Meehan wrote:
> Eric,
>
>
> The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When the
> malloc16Allign is replaced with a regular malloc in the QA code, make check
> fails.
>
> I believe that there is an additional requirement that the dat
A number of people have asked how they can help out on the USRP2
development effort. For now, we have the following:
First, the USRP2 FPGA will have a microprocessor core in it. The one we
have been using has a couple of issues, most notably that it seems to
only run at around 33 MHz. The main
George Nychis wrote:
> Sarang Mandke wrote:
>> USB.
> Eric understands that, but he's asking if you also have the oscilloscope
> program running *while* you're trying to run the OFDM benchmark. You
> must close it before running the benchmark.
>
> - George
My mistake! I am running just OFDM
Sarang Mandke wrote:
Eric Blossom wrote:
On Mon, Oct 01, 2007 at 10:33:25PM +0200, Sarang Mandke wrote:
usrp_basic_tx: can't open tx interface
212, in __init__
fpga_filename, firmware_filename)
File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line
710, in sink_c
retu
Eric Blossom wrote:
> On Mon, Oct 01, 2007 at 10:33:25PM +0200, Sarang Mandke wrote:
>> usrp_basic_tx: can't open tx interface
>> 212, in __init__
>> fpga_filename, firmware_filename)
>> File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line
>> 710, in sink_c
>> return _usr
Eric,
The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When the
malloc16Allign is replaced with a regular malloc in the QA code, make check
fails.
I believe that there is an additional requirement that the data passed to
the low-level SSE code have the real sample start on the 0th or
On 10/1/07, Matt Ettus <[EMAIL PROTECTED]> wrote:
> I think 3.3V LVTTL and LVCMOS are really the same.
>
> Matt
According to this:
http://www.interfacebus.com/voltage_LV_threshold.html
They are, indeed, basically the same.
Brian
___
Discuss-gnur
On Mon, Oct 01, 2007 at 03:33:29PM -0700, Johnathan Corgan wrote:
> Berndt Josef Wulf wrote:
>
> > Has anyone seen this? What is the required revision for portaudio. pkgsrc
> > currently uses portaudio-18.1 which may be a little out-of-date.
>
> I don't have any experience with it but I believe
On Mon, Oct 01, 2007 at 10:33:25PM +0200, Sarang Mandke wrote:
> Hello to all the experts!
> I am doing a mini project on GNU Radio using OFDM. Somehow I am getting
> runtime errors when i try to run the benchmark scripts .
>
> The message i get when trying to run benchmark_ofdm_tx.py is
>
> [EMA
On Mon, Oct 01, 2007 at 03:40:40PM -0400, Tim Meehan wrote:
> Make check does pass, and there appears to be QA code (qa_gr_fir_ccf.cc). I
> am not sure that
> if the QA code actually gets called by a top level "make check" If you
> would like me to look
> into it I can but I suspect whoever wrote
"make check" fails in gr-audio-portaudio with the following error:
File "./qa_portaudio.py", line 24, in ?
import audio_portaudio
File
"/home/wulf/projects/gnuradio/gnuradio/gr-audio-portaudio/src/audio_portaudio.py",
line 6, in ?
import _audio_portaudio
ImportError:
/home/wulf/project
On Mon, Oct 01, 2007 at 01:55:30PM -0500, Nirali Patel wrote:
> Hi,
>
>
> I am working on ntsc tv reception as a precursor to hdtv reception. I am
> using usrp_rx_cfile.py to capture samples to a file from the TV_RX board and
> then playing back using usrp_tv_rcv_nogui.py. The picture displayed d
Nirali Patel wrote:
> Hi Matt,
>
> I modified the usrp_std.v file to make connections to the debug IO pins and
> then on my PC tried to compile the project using Quartus II software. The
> compile went successfully, but later when I opened the Pin-Out file under
> Compilation Report all the signals
Hi Matt,
I modified the usrp_std.v file to make connections to the debug IO pins and
then on my PC tried to compile the project using Quartus II software. The
compile went successfully, but later when I opened the Pin-Out file under
Compilation Report all the signals showed at 3.3V-LVTTL. I had on
Berndt Josef Wulf wrote:
> Has anyone seen this? What is the required revision for portaudio. pkgsrc
> currently uses portaudio-18.1 which may be a little out-of-date.
I don't have any experience with it but I believe portaudio needs
version 19 or newer.
--
Johnathan Corgan
Corgan Enterprises
G'day,
"make check" fails in gr-audio-portaudio with the following error:
File "./qa_portaudio.py", line 24, in ?
import audio_portaudio
File
"/home/wulf/projects/gnuradio/gnuradio/gr-audio-portaudio/src/audio_portaudio.py",
line 6, in ?
import _audio_portaudio
ImportError:
/home
Hello to all the experts!
I am doing a mini project on GNU Radio using OFDM. Somehow I am getting
runtime errors when i try to run the benchmark scripts .
The message i get when trying to run benchmark_ofdm_tx.py is
[EMAIL PROTECTED]:~/gnuradio/gnuradio-examples/python/ofdm$
./benchmark_ofdm_tx.p
Matt, thank you for quick reply!
> Andrey A wrote:
>> Hello!
>>
>> I have two questions about USRP:
>>
>> 1. It is stated on
>> http://www.comsec.com/wiki?UniversalSoftwareRadioPeripheral that USRP
>> can sustain 32 megabytes per second over USB2.0.
>> I'm about to build MIMO 2 antenna transmitter
Make check does pass, and there appears to be QA code (qa_gr_fir_ccf.cc). I
am not sure that
if the QA code actually gets called by a top level "make check" If you
would like me to look
into it I can but I suspect whoever wrote the QA code originally could do it
a lot faster than me:-)
On 10/1
Since Eric's going to be working on this pretty soon, I think I'll take
George's advice and wait a bit.
/Hugh
George Nychis wrote:
Hi Hugh,
So, I opened up a can of worms from that e-mail :) This functionality
is actually scheduled to be worked on by Eric in about two weeks. He
has been ho
Hi,
I am working on ntsc tv reception as a precursor to hdtv reception. I am
using usrp_rx_cfile.py to capture samples to a file from the TV_RX board and
then playing back using usrp_tv_rcv_nogui.py. The picture displayed does not
seem to have horizontal sync (picture keeps moving from left to
Just tried this on my laptop which seems to be using whatever
non-functioning code Tim mentioned. Make check passed successfully.
Dev
Dominik Auras wrote:
Hi!
Does "make check" pass on your system when you set it to use SIMD? It would
be interesting to know if this error is not found with the
Hi!
Does "make check" pass on your system when you set it to use SIMD? It would
be interesting to know if this error is not found with the standard tests.
Dominik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/
Tim,
I reconfigured both my 32 bit laptop and desktop to use the generic,
and they both work now with benchmark_loopback. Unforunately, I still am
unable to communicate between any USRPs with the benchmark_tx and _rx
scripts. Thanks for all your work on this. When I have some free time
I'll
Hi,
Is there any way to read a 1-bit data stream from the digital i/o pins
at the same sample rate as the RF? With modifications to the FPGA it
should be possible, but is there any way to do it in software? We
would like to read and possibly write 1-bit digital control
information at the same rate
26 matches
Mail list logo
