Two more questions: Re: Two GMSK decoders with two msg queue

GNU Radio
1

Hey Eric, Michael and other friends:

My code is working well now. But I met two new problems, which are not
so
crucial, but really important to me.

  1. When I initilize the Viterbi algorithm, I wish that for the first
    trunk
    of data, ninput_items >= Viterbi algorithm’s working length, let’s say
    ninput_items > 100 (only for the first trunk of data, doesn’t matter for
    later ones). Now I am using assert(ninput_items > 100), which may not
    may
    not let me get through. Is there anyway so that I could control the
    number
    of incoming samples?

  2. Another problem is more difficult to describe, the following is part
    of
    my main code:

class my_graph(gr.flow_graph):

def __init__(self, rx_callbackA, rx_callbackB, spb, bt, SNR,

freq_error):
gr.flow_graph.init(self)

    fg = self

    # Tuning Parameters
    gain_mu = 0.002*spb
    omega = spb*(1+freq_error)

    # transmitter
    self.packet_transmitterA = gmsk2_mod_pkts(fg, spb=spb, bt=bt)
    self.packet_transmitterB = gmsk2_mod_pkts(fg, spb=spb, bt=bt)

    adder = gr.add_cc ()

const = gr.multiply_const_cc (0.5)

filesink = gr.file_sink (gr.sizeof_gr_complex, "added.dat")
filesinkA = gr.file_sink (gr.sizeof_gr_complex, "A.dat")
filesinkB = gr.file_sink (gr.sizeof_gr_complex, "B.dat")

    #fg.connect (rx_channel_A, (adder, 0))
    #fg.connect (rx_channel_B, (adder, 1))
    #fg.connect (noise, (adder, 2))
fg.connect (self.packet_transmitterA, (adder, 0))
fg.connect (self.packet_transmitterB, const, (adder, 1))
    # receiver
    self.packet_receiver = Hamkins_demod_pkts(fg,

callbackA=rx_callbackA, callbackB=rx_callbackB,
spb=spb,
gain_mu=gain_mu,
freq_error=freq_error,
omega=omega)

fg.connect (adder, self.packet_receiver)
fg.connect (adder, filesink)
fg.connect (self.packet_transmitterA, filesinkA)
fg.connect (const, filesinkB)
2

Sorry, my previous email is sent by mistake, let me restate my
questions:

Hey Eric, Michael and other friends:

My code is working well now. But I met two new problems, which are not
so
crucial, but really important to me.

  1. When I initilize the Viterbi algorithm, I wish that for the first
    trunk
    of data, ninput_items >= Viterbi algorithm’s working length, let’s say
    ninput_items > 100 (only for the first trunk of data, doesn’t matter for
    later ones). Now I am using assert(ninput_items > 100), which may not
    may
    not let me get through. Is there anyway so that I could control the
    number
    of incoming samples?

  2. Another problem is more difficult to describe, the following is part
    of
    my main code:

class my_graph(gr.flow_graph):

def __init__(self, rx_callbackA, rx_callbackB, spb, bt, SNR,

freq_error):
gr.flow_graph.init(self)

    fg = self

    # Tuning Parameters
    gain_mu = 0.002*spb
    omega = spb*(1+freq_error)

    # transmitter
    self.packet_transmitterA = gmsk2_mod_pkts(fg, spb=spb, bt=bt)
    self.packet_transmitterB = gmsk2_mod_pkts(fg, spb=spb, bt=bt)

    adder = gr.add_cc ()
    const = gr.multiply_const_cc (0.5)

    fg.connect (self.packet_transmitterA , (adder, 0))
    fg.connect (self.packet_transmitterB, const, (adder, 1))

    self.packet_receiver = Separator_demod_pkts(fg,

callbackA=rx_callbackA, callbackB=rx_callbackB,
spb=spb,
gain_mu=gain_mu,
freq_error=freq_error,
omega=omega)

    fg.connect (adder, self.packet_receiver)

Then in the main function, i do
while n < nbytes:
send_pkt_A(struct.pack(’!H’, pktnoA) + ‘A’ + (pkt_sizeA - 3) *
chr(pktnoA & 0xff))
send_pkt_B(struct.pack(’!H’, pktnoB) + ‘B’ + (pkt_sizeB - 3) *
chr(pktnoB & 0xff))
n += pkt_size
print “n now is %d” % n
pktnoA += 1
pktnoB += 1

Here pkt_size is 1500, nbytes is 1M as default. I omit other parts of my
code because they are not so important here. I print the value of n in
the
loop because I want to see when it stops. So the output is sth like
this:
I am stream A’s callback function
ok = True from ‘A’, pktno = 46 len(payload) = 1500 118/118
n now is 108000
I am stream B’s callback function
ok = True from ‘B’, pktno = 247 len(payload) = 1000 119/119
n now is 109500
I am stream B’s callback function
ok = True from ‘B’, pktno = 248 len(payload) = 1000 120/120
I am stream A’s callback function
ok = True from ‘A’, pktno = 47 len(payload) = 1500 121/121
I am stream B’s callback function
ok = True from ‘B’, pktno = 249 len(payload) = 1000 122/122
I am stream A’s callback function
ok = True from ‘A’, pktno = 48 len(payload) = 1500 123/123

Then it stops!!! Nothing happens after that. It appears to me that the
process goes somewhere and never comes back. The current value of n is
still
far from nbytes, but it just stops there. One possible solution I found
out
was that I could change the “msgq_limit” parameter of the
gr_message_source
in gmsk2_pkt. If I increase “msgq_limit”, the program could go further
and
further, with larger n and processed packets, but still stops some
timeand
never continues.

So could anyone help me address these two things? Thank you very much in
advance!

Dawei

3

On Mon, Oct 16, 2006 at 11:47:13PM -0400, Dawei Shen wrote:

of incoming samples?
You don’t have to consume all the incoming samples. Just consume the
number you want, and return the number of output samples that you
produced (I assume it’s 100) as the result of work or general_work.

  1. Another problem is more difficult to describe, the following is part of
    my main code:

Sorry, I wasn’t clear what your second question was.

On a separate topic, you may want to consider updating to the
subversion trunk, or at least the 3.0 release so that you are using
the latest code and naming conventions for the mod/demod and packet
handling code. It’s not crucial, but there may be stuff we’ve fixed
since you started working. Also, I don’t keep track of the old stuff
in my head, and since you are using something called gmsk2 (that
hasn’t existed for a couple of months), I know that you’re not up to
date :wink:

Eric

4

On Tue, Oct 17, 2006 at 12:00:11AM -0400, Dawei Shen wrote:

class my_graph(gr.flow_graph):

   self.packet_receiver = Separator_demod_pkts(fg,
   send_pkt_B(struct.pack('!H', pktnoB) + 'B' + (pkt_sizeB - 3) *

ok = True from ‘A’, pktno = 46 len(payload) = 1500 118/118
I am stream A’s callback function

So could anyone help me address these two things? Thank you very much in
advance!

Dawei

I suspect you’ve got some kind of deadlock. Without seeing all the
code, it’s hard to know what’s going on. Are you trying to jam the
1MB worth of packets into the queue before fg.start() or fg.run() is
called? If so, it’s no wonder that it dead locks :wink: Neither the
receiver nor the transmitter are running yet and send_pkt_* is just
queueing the packets to be modulated. If you set msgq_limit to 0,
there will be no limit enforced and all the packets to be modulated
will be enqueued (this of course allocates memory to hold everything).

Eric

5

Hi, Eric

Thanks~ setting the msq_limit to 0 solved my problem.

But actually if you take a look my code, I am inserting the packets to
the
queue after calling fg.start()

fg.start()
while n < nbytes:
    send_pkt_A(struct.pack('!H', pktnoA) + 'A' + (pkt_sizeA - 3) *

chr(pktnoA & 0xff))
send_pkt_B(struct.pack(’!H’, pktnoB) + ‘B’ + (pkt_sizeB - 3) *
chr(pktnoB & 0xff))
n += pkt_size
print “n now is %d” % n
pktnoA += 1
pktnoB += 1
So I suspect that’s a multi-theading problem? One of the threads never
returns, maybe.

BTW: I am pretty up to date, my GNU Radio is the newest version and I am
keeping track of what’s new in the GNU Radio community. The reason why I
chose the old GMSK2 code is because the gmsk_test thing is quite neat
and
can be easily extended, so that I could prototype my project easily
without
having to worry about other modules.

Dawei

6

Hi,

I tried the IP tunneling sample that came with GNU Radio which uses
TUN/TAP. I used a Pentium M 1.6 GHz laptop with 480 MB RAM. I noticed
that, when the IP tunneling is turned on, the CPU utilization averages
about 69% and peaks around 93% even when I do not run any application
using the IP tunnel.

This utilization is very high. Is it due to the GMSK algorithm? Is there
any inefficiency in the IP tunneling program that is a significant cause
of the high utilization?

Jeremy Chew

7

On Wed, Oct 18, 2006 at 01:54:17PM +0800, Jeremy Chew wrote:

Hi,

I tried the IP tunneling sample that came with GNU Radio which uses
TUN/TAP. I used a Pentium M 1.6 GHz laptop with 480 MB RAM. I
noticed that, when the IP tunneling is turned on, the CPU
utilization averages about 69% and peaks around 93% even when I do
not run any application using the IP tunnel.

The receiver is always running.

Try turning down the data rate with the -r option. It
defaults to 500kb/sec which may be too high for your system.

This utilization is very high. Is it due to the GMSK algorithm? Is
there any inefficiency in the IP tunneling program that is a
significant cause of the high utilization?

It’s the receiver. Also note that zero effort has been put into
tuning this code. oprofile.sf.net is your friend. patches welcome.

Eric