On Thu, Apr 26, 2007 at 10:22:46PM -0400, Justin Shaw wrote:
> Matt Ettus wrote:
> >Justin Shaw wrote:
> >>... sound from usrp_wfm_rcv.py is jerky and the text UaUaUaUaUa...
> >Use the following option to usrp_wfm_rcv.py:
> >
> > -O plughw:0,0
> >And see if that helps.
> Yup, that did the trick,
On Thu, Apr 26, 2007 at 09:07:33PM -0500, Jim Perkins wrote:
> Unfortunately the motherboard does not have USB2.0 built in. Why do the
> add-in cards have a speed issue?
> -Jim
Why do chip designers design lame chips?
Eric
___
Discuss-gnuradio maili
Matt Ettus wrote:
Justin Shaw wrote:
... sound from usrp_wfm_rcv.py is jerky and the text UaUaUaUaUa...
Use the following option to usrp_wfm_rcv.py:
-O plughw:0,0
And see if that helps.
Yup, that did the trick, thanks.
2. I need to unplug and plug the usrp after each use otherwise I get
Unfortunately the motherboard does not have USB2.0 built in. Why do the
add-in cards have a speed issue?
-Jim
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Justin Shaw wrote:
I finally got the usrp up and running. I am having two problems.
1. I believe that the data rate is overflowing the usb line becuase
the sound from usrp_wfm_rcv.py is jerky and the text UaUaUaUaUa... is
streaming to the screen (about 1-2 times per second). I am running
the
I finally got the usrp up and running. I am having two problems.
1. I believe that the data rate is overflowing the usb line becuase the
sound from usrp_wfm_rcv.py is jerky and the text UaUaUaUaUa... is
streaming to the screen (about 1-2 times per second). I am running the
pre-compiled packag
Jim Perkins wrote:
I got my USRP running today. The first test I ran was the usb speed
test in the examples/usrp folder. It will do up to 16MB/s. The 32
MB/s transfer fails. This is a dual Opteron system with 4G of memory
running Suse 10.1. Any advise on getting to 32 MB/s. I don't
remem
I got my USRP running today. The first test I ran was the usb speed
test in the examples/usrp folder. It will do up to 16MB/s. The 32 MB/s
transfer fails. This is a dual Opteron system with 4G of memory running
Suse 10.1. Any advise on getting to 32 MB/s. I don't remember what
chipset is
On Thu, Apr 26, 2007 at 02:48:34PM -0400, Kevin Rudd (Contractor) wrote:
> Thanks for the suggestion. I dove into the TCP code to try and figure out
> what it was doing. I found my problem. I have to use the following read
> command...
>
> data = pnet(con, 'read', 1000, 'SINGLE', 'NATIVE');
>
Thanks for the suggestion. I dove into the TCP code to try and figure out
what it was doing. I found my problem. I have to use the following read
command...
data = pnet(con, 'read', 1000, 'SINGLE', 'NATIVE');
Now I notice that matlab seems to be lag behind the USRP. So, maybe matlab
is not t
On Thu, Apr 26, 2007 at 01:56:10PM -0400, Brian Padalino wrote:
> When the FX2 detects the have_space pin on the FPGA, does it transfer
> 1 entire buffered USB packet to the FPGA, then re-check the have_space
> pin?
Yes.
> Would it be reasonable to assume a 1 clock delay between the last byte
> o
When the FX2 detects the have_space pin on the FPGA, does it transfer
1 entire buffered USB packet to the FPGA, then re-check the have_space
pin?
Would it be reasonable to assume a 1 clock delay between the last byte
of one 512-byte packet being written to the FPGA and the first byte of
a second
On Thu, Apr 26, 2007 at 12:52:40PM -0400, Kevin Rudd (Contractor) wrote:
> Hello again,
> I have decided to try the GNURadio -> TCP -> MATLAB route. I am running
> into a few problems.
>
> First, I downloaded Jamie Cooley's GNURadio TCP Socket code here...
>
> http://alumni.media.mit.edu/~jco
Hello again,
I have decided to try the GNURadio -> TCP -> MATLAB route. I am running
into a few problems.
First, I downloaded Jamie Cooley's GNURadio TCP Socket code here...
http://alumni.media.mit.edu/~jcooley/gr_experiments/experiments/gr_socket.ht
m
Then I downloaded a free matlab TCP too
How does 'history' relate to i/o data indices? I assume you cannot have
an index < zero.
Say your work function gets common i/o arrays
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
and you set_history(ntaps), I guess that means you get ( noutput_it
On Wed, 2007-04-25 at 08:12 -0700, Eric Blossom wrote:
> On Wed, Apr 25, 2007 at 11:02:13AM -0400, Chuck Swiger wrote:
> > The 2.x gr-atsc seems to be closer to working, at least the flow control
> > (forecast,consume,etc) creates the exact to-the-byte correct quantity of
> > output with no loss of
16 matches
Mail list logo
