Problems in benchmark_xx.py (free(), Segmentation fault, overrun, CRC check, FLL)

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

  1. 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

  1. 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.

  1. 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

  1. 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

  1. 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.

On Fri, Nov 25, 2011 at 3:06 AM, Songsong G.
[email protected]wrote:

$ ./benchmark_tx.py -f 450e6 --tx-amplitude=0.02 -r 1M

…U…

/lib/i386-linux-gnu/libpthread.so.0(+0x6b1e)[0xe55b1e]
(and bunch of things representing a memory map follow, I just skipped it)

gr_fir_ccf: using SSE



.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.)

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.

  1. 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!

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.

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.

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.

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

    $ ./benchmark_tx.py -f 450e6 --tx-amplitude=0.02 -r 1M

…U…

    /lib/i386-linux-gnu/libc.so.6(+0x6f862)[0x17f862]

    free(): ~ ****, instead

…U…

    Guest

        Platform: VMWare Workstation 7.x

        Memory allocated: 1.00 GB
        OS: Ubuntu 11.10 32bit

Did you perhaps update to the latest UHD without upgrading Gnu Radio?
There was a significant ABI change that can cause unpredictable
behaviour like this.

I wonder if it’s time for gr-uhd to check the API/ABI version number of
the UHD library below it, and produce at least an proper error, rather
than wandering off into the weeds.

Thank you to all of you who answered to this silly questions.

It’s confusing because I did fresh install several times

Anyway, I’ll try with those advices

Thank you very much

2011/11/27 Marcus D. Leech [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs