Sorry to resurrect an old thread, but I thought it a worthwhile addition.
A few months ago I posted that I'd created a CentOS / RHEL repository that
included GnuRadio. I'm personally running RHEL 5.4 x86_64 and have gnuradio
(latest stable) RPM installed.
info at:
http://blackopsoft.com/
it's a
Tom Rondeau wrote:
Just the status report from the work done the past couple of weeks on
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I
have merged the code into the trunk so others can use
After coming up with some scripts to generate thousands of 200-byte random
files and attempt to transfer them over a GMSK link, I isolated 5 of 10,000
'files' that cause the packet to be dropped (when the MTU is big enough to
hold the entire 200 bytes- which should be all the time)- most likely
Dan Halperin wrote:
What are the practical effects of automatic transmit/receive switching
on the USRP subdevices (in particular, the RFX2400). If I have a
transmit-only application, will having this option on hurt my
performance in any way? The reason I ask is that if I leave it off,
As you may recall, I had a working build on X86_64 with Fedora Core 6, and
then decided to install n4hy's tree- only to expierence problems with
_gnuradio_swig_python... I totally cleaned things out and rebuilt and
reinstalled the stable tree, and was still missing _gnuradio_swig_python.
After
Brett Trotter wrote:
As you may recall, I had a working build on X86_64 with Fedora Core 6, and
then decided to install n4hy's tree- only to expierence problems with
_gnuradio_swig_python... I totally cleaned things out and rebuilt and
reinstalled the stable tree, and was still missing
I did a bootstrap, configure, make, make install on n4hy's tree and when I
try to run ofdm_benchmark_tx, I get
[EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
Traceback (most recent call last):
File ./benchmark_ofdm_tx.py, line 23, in ?
from gnuradio import gr, gru, modulation_utils
File
Brett Trotter wrote:
I did a bootstrap, configure, make, make install on n4hy's tree and when I
try to run ofdm_benchmark_tx, I get
[EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
Traceback (most recent call last):
File ./benchmark_ofdm_tx.py, line 23, in ?
from gnuradio import gr
26, 2007 at 02:55:29PM -0800, Brett Trotter wrote:
Brett Trotter wrote:
I did a bootstrap, configure, make, make install on n4hy's tree and
when I
try to run ofdm_benchmark_tx, I get
[EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
Traceback (most recent call last):
File
Patrick Strasser wrote:
Some more notes... It's been very late when writing this.
Patrick Strasser wrote:
In general TCP is quite capable
of recovering from lots of errors, but it's busy with itself for this
purpose, which leaves less capacity for its payload. IP does not correct
Greg Troxel wrote:
So the bottom line question is why in the heck would a file transfer
over a
stateless protocol get frozen after a certain number of bytes when it
appears I can ping with large payloads indefinitely?
For the record, anything terribly deep in python or
I switched to NFS for my testing and I can transfer about 600 KiB before it
stalls for a while, but NFS seems to be good enough at re-trying over cruddy
networks, so I was able to transfer a couple MB file and have the hash come
out right, but that's with a lot of thumb twiddling during times
I'm still trying to do gmsk over the LFRX/TX boards and had hoped that my
fpga modification might help. I can get the tunnel up and ping and even copy
about 400-600kb of a file over scp, but then all of a sudden, the
environment deteriorates and the packets stop going through- at first they
go
Brett Trotter wrote:
I'm still trying to do gmsk over the LFRX/TX boards and had hoped that my
fpga modification might help. I can get the tunnel up and ping and even
copy about 400-600kb of a file over scp, but then all of a sudden, the
environment deteriorates and the packets stop going
I've been pondering a few ways to do the wait and ramp down (wait something
like 16 clocks and then ramp down by right shifting on each clock)- but to
do so, I need to know what the last value was so I can shift it. Will
tx_i_*/tx_q_* remain persistent between clocks (my deduction was yes?) If
Eric Blossom wrote:
On Tue, Jan 16, 2007 at 07:41:58AM -0800, Brett Trotter wrote:
I've been pondering a few ways to do the wait and ramp down (wait
something
like 16 clocks and then ramp down by right shifting on each clock)- but
to
do so, I need to know what the last value was so I
an additional note- tested with the original firmware and ctrl+c'ing still
leaves the sine-wave, with my new firmware, it goes away as desired..
I remain perplexed as to why letting the program end normally results in the
tx_empty not happening or the clock stopping or whatever is causing the
So, then we have to go dac side, with ramping, and pay attention to tx_enable
as well...
I'll see what I can do.
Eric Blossom wrote:
On Tue, Jan 16, 2007 at 09:54:00AM -0800, Brett Trotter wrote:
an additional note- tested with the original firmware and ctrl+c'ing
still
leaves the sine
After seeing Matt Ettus' and Eric Blossom's responses regarding fixing the
transmitter to keep it from repeating the last sample seen and ramp down the
value to zero and am left unsure what is the best place to make this
modification. I suppose since this is Matt Ettus' baby, we should go with
doing an strace yields that it tacks on the path I specified on to
/usr/local/share/usrp/rev2 - so it was trying to access
/usr/local/share/usrp/rev2//usr/local/share/usrp/rev2/usrp_std.rbf
My firmware also seems to have no effect- so apparently my tx_empty tweak
doesn't work- any ideas what
20 matches
Mail list logo
