We have three important bug fixes recently checked in to the development
trunk and backported to the release 3.1 stable branch. These involve
fairly low-level code, and we’re interested in users confirming the
original bugs are fixed and that there has been no collateral damage.
Users tracking the development trunk or the release 3.1 stable branch
via Subversion can update to the latest revision, recompile, and
reinstall. Once we’re confident with these, we’ll create 3.1.1 release
source tarballs and binary packages.
The three bugs are:
“I and Q channels may get swapped on transmit”
http://gnuradio.org/trac/ticket/179
“std_4rx_0tx.rbf has weird side band on channel 0”
http://gnuradio.org/trac/ticket/195
“benchmark_tx.py / benchmark_rx.py not working on the air”
http://gnuradio.org/trac/ticket/196
The first two of these have been around for quite a while and required
fixes to the USRP FPGA code and re-synthesis of the FPGA bitstreams. The
last was a “brown paper bag” bug introduced with the new top_block and
hier_block2 code.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
In reference to “benchmark_tx.py / benchmark_rx.py not working on the
air”:
I’ve just tested these scripts and they’re now working perfectly. Thanks
for looking into this! I tried out tunnel.py (which worked some months
ago, before the problems with benchmark_tx/rx), but it doesn’t seem to
be working now:
$ sudo ./tunnel.py -f 910M --bitrate 500k -v
gr_fir_fff: using SSE
bits per symbol = 1
Gaussian filter bt = 0.35
Using TX d’board A: Flex 900 Tx MIMO B
Tx amplitude 12000
modulation: gmsk_mod
bitrate: 500kb/s
samples/symbol: 2
interp: 128
Tx Frequency: 910M
bits per symbol = 1
M&M clock recovery omega = 2.000000
M&M clock recovery gain mu = 0.175000
M&M clock recovery mu = 0.500000
M&M clock recovery omega rel. limit = 0.005000
frequency error = 0.000000
Receive Path:
Using RX d’board A: Flex 900 Rx MIMO B
Rx gain: 45
modulation: gmsk_demod
bitrate: 500kb/s
samples/symbol: 2
decim: 64
Rx Frequency: 910M
modulation: gmsk
freq: 910M
bitrate: 500kb/sec
samples/symbol: 2
Carrier sense threshold: 30 dB
Allocated virtual ethernet interface: gr0
You must now use ifconfig to set its IP address. E.g.,
$ sudo ifconfig gr0 192.168.200.1
Be sure to use a different address in the same subnet for each machine.
Then after running ‘$ sudo ifconfig gr0 192.168.200.1’, the tunnel.py
window shows:
Tx: len(payload) = 90
Tx: len(payload) = 54
Tx: len(payload) = 245
Tx: len(payload) = 157
Tx: len(payload) = 78
(and roughly the same on the other system)
But nothing happens after this when I attempt to ping, reset IP, ssh,
etc. Running the benchmark_tx/rx scripts with the printed options above:
$ ./benchmark_rx.py -f 910M --rx-gain 45 -d 64 -S 2 --bitrate 500k -m
gmsk
$ ./benchmark_tx.py -f 910M --tx-amplitude 12000 -i 128 -S 2 --bitrate
500k -m gmsk
Works correctly.
Thanks!
Dev
On Fri, Nov 02, 2007 at 01:41:06PM -0400, Dev R. wrote:
In reference to “benchmark_tx.py / benchmark_rx.py not working on the air”:
I’ve just tested these scripts and they’re now working perfectly. Thanks
for looking into this! I tried out tunnel.py (which worked some months
ago, before the problems with benchmark_tx/rx), but it doesn’t seem to
be working now:
Is it printing "B"s?
If so, that means it’s backing off.
Try experimenting with the the -c CARRIER_THRESHOLD command line
parameter on both sides.
This should all be automatic, but it isn’t.
Patches are definitely welcome.
Eric
On Fri, Nov 02, 2007 at 02:35:29PM -0400, Dev R. wrote:
Is it printing "B"s?
threshold doesn’t appear to have any effect. Actually, trying to do
anything with the application after it sends those 5 TXs does nothing,
(even trying to control-C it), so it may be that it’s just hanging for
some reason. I’ll continue to look into it.
Dev
Thanks for the report. Let us know what you find.
Eric
Eric B. wrote:
Try experimenting with the the -c CARRIER_THRESHOLD command line
parameter on both sides.
This should all be automatic, but it isn’t.
Patches are definitely welcome.
Eric
Unforunately, it’s not printing anything at all. Changing the carrier
threshold doesn’t appear to have any effect. Actually, trying to do
anything with the application after it sends those 5 TXs does nothing,
(even trying to control-C it), so it may be that it’s just hanging for
some reason. I’ll continue to look into it.
Dev
Dev R. wrote:
Unforunately, it’s not printing anything at all. Changing the carrier
threshold doesn’t appear to have any effect. Actually, trying to do
anything with the application after it sends those 5 TXs does nothing,
(even trying to control-C it), so it may be that it’s just hanging for
some reason. I’ll continue to look into it.
This is now fixed (or should be) on the trunk in revision 6799, and in
the 3.1 stable branch in 6801. Please confirm.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
Johnathan C. wrote:
This is fixed as of that revision. Thanks for looking into it.
Dev R. wrote:
This is now fixed (or should be) on the trunk in revision 6799, and in
the 3.1 stable branch in 6801. Please confirm.
This is fixed as of that revision. Thanks for looking into it.
Good. I am building the final 3.1.1 release now.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com