I have a number of problems in testing benchmark program under a gr-digital
directory from GR 3.5.0rc0
1. Problem about free() side or segmentation fault on tx
Whatever I select modulation schemes(-m) or bit rate(-r), carrier
frequency(-f) and other options
either a free()-related problem or a segmentation fault must occur.
a. free()-related problem
$ ./benchmark_tx.py -f 450e6 --tx-amplitude=0.02 -r 1M
linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-06d0032
>>> gr_fir_ccf: using SSE
-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.000000MHz...
................................................................................................................................U..................................
....................................................................................................................................................................
...............................................................
............................................................
.........................................
.................................................
............................................................
.......................................................
.............**** glibc detected *** python: free(): invalid pointer:
0x0a42a2a8 ****
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0x17ebc2]
/lib/i386-linux-gnu/libc.so.6(+0x6f862)[0x17f862]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x18294d]
/usr/lib/libboost_thread.so.1.46.1(delete_epoch_tss_data+0x1b)[0x2f947b]
/lib/i386-linux-gnu/libpthread.so.0(+0x6b1e)[0xe55b1e]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d3f)[0xe55d3f]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0x1e20ce]
======= Memory map: ========
00110000-00286000 r-xp 00000000 08:01 918438 /lib/i386-linux-gnu/
libc-2.13.so
(and bunch of things representing a memory map follow, I just skipped it)
Sometimes it says* *** glibc detected *** python: double free(): ~ ****,
instead
b. Segmentation fault
$ ./benchmark_tx.py -f 450e6 --tx-amplitude=0.05 -r 500k --tx-gain=30 -m
dqpsk
linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-06d0032
>>> gr_fir_ccf: using SSE
-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.000000MHz...
........................................................................................U.............................................................................
......................................................................................................................................................................
.
.........................................................
............................................................
..................................................
......................................................................
............................................................
.....................................
.*Segmentation fault*
I feel that if a bit rate is higher, then it occurs more earlier. (I mean
the faster bit rate, the fewer 'dots' and then, Segmentation fault.)
Specification of the PC on the receiver side is like this:
Host
CPU: Intel Core2 Duo P9300 @ 1.60 GHz
RAM: 4.00 GB
OS: Win7 32bit
Guest
Platform: VMWare Workstation 7.x
Memory allocated: 1.00 GB
OS: Ubuntu 11.10 32bit
2. No CPM demod in benchmark_rx.py
It's not a big problem, just curiosity. There is a CPM mod options on
tx.py, but it's invalid option for rx.py
3. No output from rx_callback in benchmark_rx.py
I strongly believe that I have to modify carrier sensing threshold in
receive_path.py for the receiver in order to sense a carrier.
# Carrier Sensing Blocks
alpha = 0.001
*thresh = 30 # in dB, will have to adjust*
self.probe = gr.probe_avg_mag_sqrd_c(thresh,alpha)
Thus, I changed it with the - 60 dB (in my test environment, --tx-gain=30,
--rx-gain=50, then a received signal strength is above -60 dB, observed
with uhd_fft.py), and nothing changed elsewhere.
After changing it, however, when I run benchmark_rx.py, it prints nothing
for received packets
$ ./benchmakr_rx.py -f 450e6 -r 500k --rx-gain=50 -m dqpsk
linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-06d0032
>> gr_fir_ccf: using SSE
-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.000000MHz...
That's all. or, Problem 4. (below) occurs.
4. Overrun on the receiver side
$ ./benchmakr_rx.py -f 450e6 -r 500k --rx-gain=50 -m dqpsk
linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-06d0032
>> gr_fir_ccf: using SSE
-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.000000MHz...
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Lots of 'O's, which indicate Overrun,are printed.
Specification of the PC on the receiver side is like this:
Host
CPU: Intel Core2 Duo P9700 @ 2.80 GHz
RAM: 6.00 GB
OS: Win7 32bit
Guest
Platform: VMWare Workstation 7.x
Memory allocated: 1.00 GB
OS: Ubuntu 11.10 32bit
5. All of received packets fail on CRC check
Once a packet is received (if it really happens,) it always fails to pass
the CRC check.
I did not specify an access code, thus program will use a default access
code on both tx/rx sides.
I also tried changing modulation, carrier sensing threshold, but the result
is same.
And probably because of CRC check failure, it also fails on unpacking
payload. (pktno,) = struct.unpack('!H', payload[0:2]), but I'm not sure.
So, I got rid of a part printing *pktno, *then I got this:
ok = False n_rcvd = (n_rcvd) n_right = 0
6. FLL bugs
I heard that there is a bug on FLL which is essential for *psk mod/demod
Are some of problems I mentioned related with this issue?
Each of them belongs to different issue, but not wanting to spam mails, I
just put together into this.
--
Seokseong Jeon, PhD Candidate
Communication & Networks Lab
IT Convergence Engineering (ITCE), POSTECH, Korea
+82 10 8338 1229, gee.songsong at gmail . com
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
