I've been looking into this problem further. I apologize in advance for
the long post. To make things easier, I'll represent the three computers
I'm using as follows:
32deb - 32bit Debian desktop
32red - 32bit Fedora laptop
64red - 64bit Fedora desktop
benchmark_loopback.py:
---------------------
Does not appear to work properly on either 32deb or 32red. When I set
the internal noise channel on in the script, I get random results as
follows. Judging from the correctly running script on the 64 bit system,
this detection happens every 15-20 "real" packets:
ok = False pktno = 8355 n_rcvd = 1 n_right = 0
ok = False pktno = 19 n_rcvd = 2 n_right = 0
ok = False pktno = 46 n_rcvd = 3 n_right = 0
ok = False pktno = 33 n_rcvd = 4 n_right = 0
ok = False pktno = 196 n_rcvd = 5 n_right = 0
... etc.
with different values on each run. When I take the noise channel off
(channelon = False), I get the following results on 32deb (the time
between every packet detection is much longer, about 10-20 times as long
with high variability):
ok = False pktno = 32 n_rcvd = 1 n_right = 0
ok = False pktno = 1 n_rcvd = 2 n_right = 0
ok = False pktno = 32997 n_rcvd = 3 n_right = 0
ok = False pktno = 142 n_rcvd = 4 n_right = 0
ok = False pktno = 109 n_rcvd = 5 n_right = 0
... etc.
Running the above repeatedly gives the same pktno and timing every run.
The same behavior happens on 32red, but the pktnos and timings are
different. I've tried running the CPU at close to 100% utilization on
both 32deb and 32red to see if there is some kind of over/underflow
occurring, but it didn't change the above results.
64red runs correctly, giving the following output:
ok = True pktno = 0 n_rcvd = 1 n_right = 1
ok = True pktno = 1 n_rcvd = 2 n_right = 2
ok = True pktno = 2 n_rcvd = 3 n_right = 3
ok = True pktno = 3 n_rcvd = 4 n_right = 4
ok = True pktno = 4 n_rcvd = 5 n_right = 5
ok = True pktno = 5 n_rcvd = 6 n_right = 6
... etc.
benchmark_rx.py and benchmark_tx.py:
-----------------------------------
I've tried running benchmark_rx and tx with the following
configurations, in both directions:
32deb <-> 32red
32deb <-> 64red
32red <-> 64red
64red USRP 0 <-> 64red USRP 1
using:
./benchmark_tx.py -T A -f 2.4G
./benchmark_rx.py -R A -f 2.4G
In _no_ case was the receiver able to demod any packets at all. In every
run I tested usrp_fft.py to verify that a signal was coming through on
the correct frequency. I exchanged the USRP from 32red to run on 64red,
but that didn't help either.
I created a file sink after the amp block in benchmark_tx on each
computer and tested the beginning of each file against the others. It
seems like the benchmark_tx script is sending the same data to the USRP
in every case, which means the problem is in the RX side(?)
./benchmark_ofdm.py
-------------------
Works correctly on every computer, showing:
ok: True pktno: 0 n_rcvd: 1 n_right: 1
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
ok: True pktno: 1 n_rcvd: 2 n_right: 2
0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
etc...
./benchmark_ofdm_rx.py and ./benchmark_ofdm_tx.py:
-------------------------------------------------
Same configurations as above were tried. In every case except "64red
USRP 0 <-> 64red USRP 1", nothing was demoded at all. With the 64red
transmitting to two connected USRPS with:
./benchmark_ofdm_rx.py -U 1 -R A -f 2.4G
./benchmark_ofdm_tx.py -U 0 -T A -f 2.4G
(added -U to the options to select USRP) I get:
ok: False pktno: 84 n_rcvd: 1 n_right: 0
ok: False pktno: 85 n_rcvd: 2 n_right: 0
ok: False pktno: 86 n_rcvd: 3 n_right: 0
ok: False pktno: 87 n_rcvd: 4 n_right: 0
ok: False pktno: 88 n_rcvd: 5 n_right: 0
The detection is strangely sporadic, with long series of packets not
being demoded, followed by 3-4 second bursts of demods.
--------------
Lastly, running the Packet mod/demod example in GRC in the latest
version works correctly on every system. It displays the sine wave
correctly, and changes it appropriately with parameter modification.
Any suggestions on how to proceed?
Thanks,
Dev
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio