On Fri, Nov 25, 2011 at 3:06 AM, Songsong Gee <[email protected]>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: > > 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 > > 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: http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-debug-GNU-Radio-in-Python 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. > > # 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. > > 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: > > 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 > > 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
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
