On 01/15/2010 10:46 AM, Ben Gear wrote:
Hi Eric,
Great to have an update on how the new features are progressing.
m-blocks and the replacement features have been mentioned a few times
on this mailing list in relation to building TDMA MACs. Having VRT
metadata available in gr blocks is going to
On Fri, Jan 15, 2010 at 01:54:24PM -0500, Tom Gross wrote:
>
> I guess I could study the firmware source (if it's in the C code where
> this happens) to figure out what happens if RX is OFF. My assumption
> is that somewhere in the USRP2 code there is some recognition that it
> can't keep up with
On Fri, Jan 15, 2010 at 06:46:47PM +, Ben Gear wrote:
> Hi Eric,
>
> Great to have an update on how the new features are progressing.
> m-blocks and the replacement features have been mentioned a few times
> on this mailing list in relation to building TDMA MACs. Having VRT
> metadata availab
On 01/15/2010 12:39 PM, Matt Ettus wrote:
Yes, that one is actually designed by the same person as the one we
sell. We could carry it as well if there were enough demand.
Matt
Something I wonder about FR4-based patch antennae is the loss factor.
At the higher frequencies
(above 500Mhz
Thanks Eric, that's exactly what I thought. I think in our
application it's probably better to drop data, or at least that's why
things are more stable for us when RX is OFF. Or maybe we should just
slow down a bit. Something to think about.
On Fri, Jan 15, 2010 at 2:07 PM, Eric Blossom wrote
Matt-san,
Congratulations to the WBX announcement. As you know well,
I am using USRP-1 for 150MHz/400MHz satellite beacon experiment,
and the WBX just meets our frequency range. I would like to
test it as soon as possible. But at the same time, I would
like to say that RFX400 is very useful
On Fri, Jan 15, 2010 at 2:07 PM, Eric Blossom wrote:
>
> Actually, PAUSE handling is all handled in the FPGA. When the FIFO is
> getting full, a PAUSE frame is sent on the wire telling the host to
> stop sending for a while.
>
Incidentally my System Engineer/Project Lead points out that if the
Incidentally my System Engineer/Project Lead points out that if the
USRP2 is actually telling the host to stop sending (which certainly
appears to be the case) then we are only able to get overall
throughput with two USRP2s over two gig-e connections comparable to
what we were getting with a sin
yes of course we have two separate gig-e cards. if the usrp2 is
sending us "pause" commands then it seems evident the usrp2 is having
trouble keeping up, not the computer.
On Fri, Jan 15, 2010 at 6:04 PM, Matt Ettus wrote:
>
>> Incidentally my System Engineer/Project Lead points out that if the
Matt,
What is the maximum data rate that the USRP2 transmitter can accept
from the host without firing pause signals back to the host?
-Tom
On Fri, Jan 15, 2010 at 6:04 PM, Matt Ettus wrote:
>
>> Incidentally my System Engineer/Project Lead points out that if the
>> USRP2 is actually telling th
On Fri, Jan 15, 2010 at 15:08, Tom Gross wrote:
> yes of course we have two separate gig-e cards. if the usrp2 is
> sending us "pause" commands then it seems evident the usrp2 is having
> trouble keeping up, not the computer.
The host software, when creating a data stream to be sent to the USR
On 01/15/2010 03:14 PM, Tom Gross wrote:
Matt,
What is the maximum data rate that the USRP2 transmitter can accept
from the host without firing pause signals back to the host?
See my other message. The USRP2 will ALWAYS put out pause frames. In
fact, when the data rate is low it will actuall
On 01/15/2010 03:08 PM, Tom Gross wrote:
yes of course we have two separate gig-e cards. if the usrp2 is
sending us "pause" commands then it seems evident the usrp2 is having
trouble keeping up, not the computer.
First off, the USRP2 will only send pause frames when you are
transmitting, not
Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
We greatly appreciate the information and need to think about stuff on
our end. I've been deliberately vague about our application (not that
I could really explain it even if I felt authorized discuss it). The
thing to remember
Hi,
I got the same error:
make[4]: *** No rule to make target `/../lib/libgnuradio-pager.la',
needed by `_pager_swig.la'. Stop.
make[4]: Leaving directory
`/home/moment/Documents/gnuradio-veljkop/trunk/gnuradio/gr-pager/swig'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/moment/Do
On Fri, Jan 15, 2010 at 17:44, Veljko Pejovic wrote:
> I got the same error:
>
> make[4]: *** No rule to make target `/../lib/libgnuradio-pager.la',
> needed by `_pager_swig.la'. Stop.
> Did anyone find out what is the source of this error is?
I just did a from-scratch rebuild of the current g
In the spirit of more open communication, I've changed the
gnuradio.org configuration to send commit emails from individual
developer repositories to the main commit-gnuradio mailing list. The
upside to this is that it is easier to see what people are working on
before it gets promoted to the main
On 01/15/2010 03:53 PM, Tom Gross wrote:
Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
We greatly appreciate the information and need to think about stuff on
our end. I've been deliberately vague about our application (not that
I could really explain it even if I felt auth
Dear all,
I'm trying to load my own FPGA bitstream. The .rbf file, however, cannot be
loaded due to the errors as below. I've already copied the .rbf file under the
directories /usr/local/share/usrp/rev2 and rev4 as well.
Could you please guide me what the problem or the solution to solve the
Tom-
> Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
>
> We greatly appreciate the information and need to think about stuff on
> our end. I've been deliberately vague about our application (not that
> I could really explain it even if I felt authorized discuss it). The
>
Dear all,
I am new to GNU Radio. I am building a transceiver with turbo encoder and
FQPSK modulator. At the receiver, FQPSK demodulator softly demodulates the
received signals with BCJR algorithm (FQPSK can be viewed as a two-bit input
TCM with 16 states). I simulated the system using C++ co
The throughput depends on how optimal and fast the program you write is.
I'm not familar with Turbo decoder theory. In 2007, we used turbo decoder
from IT++ libary (http://sourceforge.net/apps/wordpress/itpp/). It is faster
than that we wrote. It supports a 64 kbps (One CPU) and 384 kbps (maybe 3
C
hi folks,
I am using BENCHMARK_TX.PY, BENCHMARK_RX.PY to test the
transmission and reception of signals. I have doubts regarding the outpu
that is appearing on the screen.
>>> gr_fir_fff: using SSE
socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted
eth0: socket: No such f
Hi ALL:
I have been trying to get GNURADIO installed on windows, failed with CYGWIN
and then tried with MSYS/MINGW everything went fine until the last, while
executing "make" for gnuradio.
Hi,
I've tried the OFDM example on the USRP2 with minor changes and I didn't
encounter any problems. Be sure that you have the same FFT-length, number of
occupied tones, interpolation/decimation on both the receiver and transmitter.
Have you tried to increase the distance between the transmitte
Shabbir Ahmed wrote:
I have been trying to get GNURADIO installed on windows, failed with
CYGWIN
and then tried with MSYS/MINGW everything went fine until the last, while
executing "make" for gnuradio.
Another antenna to look at.
http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=LPY41
From: discuss-gnuradio-bounces+jewan=its.bldrdoc@gnu.org
[discuss-gnuradio-bounces+jewan=its.bldrdoc@gnu.org] On Behalf Of Marcus D.
Leec
It amazes me how much people will pay for a piece of FR-4 and an SMA
connector.
-Mark
On Fri, Jan 15, 2010 at 10:32 AM, John Ewan wrote:
> Another antenna to look at.
>
>
> http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=LPY41
>
>
>
>
> __
Hi,
I'm testing gnuradio with the beagle board.
I'm using:
- gnuradio 3.2.1 (with neon patch).
- libusb-1.0-0
First, I've tried benchmark_dotprod_fff:
# ./benchmark_dotprod_fff
generic: taps: 256 input: 4e+07 cpu: 1119.820 taps/sec: 9.144e+06
cortex_a8: taps: 256 input: 4e+07 cpu: 4
On 01/15/2010 07:32 AM, John Ewan wrote:
Another antenna to look at.
http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=LPY41
Yes, that one is actually designed by the same person as the one we
sell. We could carry it as well if there were enough demand.
Matt
_
On Thu, Jan 14, 2010 at 10:11:38PM -0500, Tom Gross wrote:
> Following up on my previous email, thinking about this some more:
>
> I'm guessing that we are sending the USRP2 more data than it can
> handle, it is sending pause packets back, which when RX is ON, the
> ethernet card recognizes and sl
Hi Eric,
Great to have an update on how the new features are progressing.
m-blocks and the replacement features have been mentioned a few times
on this mailing list in relation to building TDMA MACs. Having VRT
metadata available in gr blocks is going to give access to timestamps
for Rx samples;
We've tried it with and without a switch - definitely better without the switch.
Thinking about our setup the behavior actually makes sense to me,
although I'm waiting to discuss it with my signal processing guru.
two usrp2s, connected with a mimo cable. the slave is just getting
its clock from
33 matches
Mail list logo
