OK, it looks like we have some sort of problem with the RTL8169. Can
you guys run the following program in its own window
while ip -s link show dev eth0 | more -c && sleep 1 ; do : ;done
That will show you stats on the ethernet device. Then run find_usrps
and see how many packets, d
Hi Brett,
I had the same (bad) experience with a RTL-8169 card and USRP2:
approximately 75% of the time "find_usrps" can not detect the USRP2 (the
same for usrp2_fft.py).
I can not confirm the problem (just now I don't have another card with a
different chipset), but I suspect it is related to th
The purpose of this email is to ask if anyone (out of the relatively few
USRP2 users) had happened to bump into this card and had similar
difficulty as well as to determine if this is repeatable on other
systems and thus warn others away from the headache I've encountered.
I've been successful wit
Achilleas Anastasopoulos wrote:
I have noticed that in benchmark_tx/rx (as well as in
benchmark_loopback), there is always
one packet lost in the transmission (always the last).
It is either not transmitted at all (getting out of the USRP)
or is not received. This behavior is persistent rega
I have noticed that in benchmark_tx/rx (as well as in
benchmark_loopback), there is always
one packet lost in the transmission (always the last).
It is either not transmitted at all (getting out of the USRP)
or is not received. This behavior is persistent regardless of packet
size/data-rate/mo
On Mon, 2008-12-08 at 14:51 -0800, Johnathan Corgan wrote:
> On Mon, Dec 8, 2008 at 2:34 PM, Johnathan Corgan
> <[EMAIL PROTECTED]> wrote:
>
> >> /usr/local/include/gnuradio/swig/gr_realtime.i:3: Error: Unable to find
> >> 'gruel/realtime.h'
> >
> > This should have been fixed in a fairly recent
On Mon, Dec 8, 2008 at 2:34 PM, Johnathan Corgan
<[EMAIL PROTECTED]> wrote:
>> /usr/local/include/gnuradio/swig/gr_realtime.i:3: Error: Unable to find
>> 'gruel/realtime.h'
>
> This should have been fixed in a fairly recent version of the trunk,
> without needing any change to the gr-howto code, b
On Mon, Dec 8, 2008 at 2:27 PM, Martin DvH <[EMAIL PROTECTED]> wrote:
> /usr/local/include/gnuradio/swig/gr_realtime.i:3: Error: Unable to find
> 'gruel/realtime.h'
This should have been fixed in a fairly recent version of the trunk,
without needing any change to the gr-howto code, but I'll go ch
Hi,
gr-howto-write-a-block seems broken.
When I try to bootstrap ./configure make
Making all in lib
make[3]: Entering directory
`/pub/projects/gnuradio/svn/trunk/gr-howto-write-a-block/src/lib'
/usr/bin/swig -c++ -fvirtual -python -modern
-I/usr/local/include/gnuradio/swig -I/usr/local/include/
On Mon, Dec 8, 2008 at 1:47 PM, Bob McGwier <[EMAIL PROTECTED]> wrote:
> This is to be used for and will include both FIR and recursive/all pass
> versions of the partition filters.
Excellent. Please coordinate with me on how this gets integrated, as
we're approaching "freeze" on the 3.2 release
I haven't looked at that code in a while. I will take the assignment.
Maureen Quirk and I are doing a Octave and SciPy replacement for fdatool.
Maureen has spent years writing FIR and IIR design code. We are updating it
to use C++ as the code was originally Fortran and written for the Cray
super
On Mon, 2008-12-08 at 08:38 -0800, Firas A. wrote:
> There is comment in optfir.py saying "# FIXME high_passs is broken...".
>
> Can anyone send me an example to regenerate this problem? I have some spare
> time and I think I can help in fixing this problem (If it still exist)
Firas,
Greppi
Douglas Geiger wrote:
> I do now have the BBN code working with hier_block2. It looks like the
> problem I was encountering was the message queue was inside a hier_block
> - but moving it out to the top_block (i.e. bypassing bbn_80211b_pkt.py,
> and just creating the message queue and calling bbn_8
Yihu Li wrote:
> Hi,
>
> I am new to gnuradio and trying to do some work based on 802.11. Through
> my understanding, the current implementations of 802.11-like schemes
> over gnuradio are mostly limitted by the processing delay on and between
> the host computer and USRP boards, eapecially due to
Looks like I failed to copy the list. To expand a little more on this -
setting decimation rates less than 8 with the current code on my machine
results in a screen-full of 'S's, and I still see them occasionally
with decim = 8. Right now I'm experimenting with usrp2_rx_file.py to
record the 25M
Hi there,
I have some question about the MAC related issues over GNU Radio. In
particular, my questions are related to a paper regarding the ADROIT
projected in BBN (see
http://www.bbn.com/resources/pdf/ieee-ntsdr-troxel-adroit.pdf).
1) BBN 802.11 codes and m-blocks.
In BBN's ADROIT paper, BBN pe
Hi,
There is comment in optfir.py saying "# FIXME high_passs is broken...".
Can anyone send me an example to regenerate this problem? I have some spare
time and I think I can help in fixing this problem (If it still exist)
Regards,
Firas
--
View this message in context:
http://www.nabbl
On Mon, Dec 8, 2008 at 1:48 AM, Per Zetterberg <[EMAIL PROTECTED]> wrote:
> A question out of curiosity: you write "non-GNU Radio libusrp library". This
> library is built when I download and compile the trunk. Isn't it a part of
> GNU Radio ? Does python applications use this library ?
To clarif
Hey Tom,
Congratulations!!, you totally deserve that and much more.
Paco.
--
View this message in context:
http://www.nabble.com/Tom-Rondeau-esquire-tp20855890p20896547.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-g
Matt,
> Did you have it working with versions earlier than 10106? Or is the the
> first version with which you tried it?
>
The version 10106 was the first version I ever tried with the USRP2. I
confirmed that the version was updated to 10109 very early in the
morning, my time, but didn't try yet.
A question out of curiosity: you write "non-GNU Radio libusrp library". This
library is built when I download and compile the trunk. Isn't it a part of
GNU Radio ? Does python applications use this library ?
I am looking forward to test when my schedule allows!
BR/
Per
___
21 matches
Mail list logo
