On Fri, Nov 25, 2011 at 3:06 AM, Songsong Gee
<address@hidden> wrote:
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:
CPU: Intel Core2 Duo P9300 @ 1.60 GHz
Platform: VMWare Workstation 7.x
Memory allocated: 1.00 GB
OS: Ubuntu 11.10 32bit
I have never seen that or heard anyone else report it as a problem. I can only guess that it is related to using it in a VM. Please follow this:
And report a backtrace to us to let us know which line of which block is causing this.
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
We don't have a good receiver built for it yet. Contributions are welcome!
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.
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.
Digital modulations are finicky creatures and need a lot of attention. There are many, many options and potential problems when running these guys. I can tell you that I have successfully used these blocks in many implementations for real problems. It's a matter of getting the right settings, which takes knowledge of the RF and comms theory layer and skill with looking at the signals and figuring out where your problems are.
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:
CPU: Intel Core2 Duo P9700 @ 2.80 GHz
Platform: VMWare Workstation 7.x
Memory allocated: 1.00 GB
You're computer can't keep up with the signal processing occurring here. We know there are optimizations that can be made as well as using Volk for many of the blocks to make this work better.
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
That's the same issue as with item 3.
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
The only thing that the FLL should affect in this case is your overruns. The code is not as efficiently written as it could be, and I'm on the hook to fix that. From a signal point of view, it works better than what we had before, so it should not be causing you issues with receiving the signals or with your tx seg faults.
Tom