discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: Problem with FIR filter


From: John Wilson
Subject: [Discuss-gnuradio] Re: Problem with FIR filter
Date: Thu, 22 Jul 2010 17:13:09 +0100

So does no one have any idea about this? It doesn't seem like it should be too difficult to solve, I've worked around the problem for the simulations I'm currently running but it's a shame as it reveals a fundamental incapacity for GNU Radio to perform some other interesting simulations and techniques, notably (for me at least) in the area of repeat requests. Currently I'm implementing a type II HARQ repeat request system by dynamically reconfiguring a flow graph during operation, this makes use of the run() command a lot but if every time I run this command every filter in the system is reset it's going to make it almost impossible to implement.

Up to now I've been really impressed with GNU Radio, even to the point of writing a conference paper (for the upcoming NORDIC '10 HF conference in Sweden) about how good the system is in the lab. I think the API is very well written and like how the Python scripting aspect allows code written for testing and simulation of techniques to be plonked straight into a working radio. Unfortunately the problem below seems pretty fundamental and can be treated (at least in the context of how I'm using the software) as a pretty major bug. Does anyone have any opinion on this?

Also if anyone has any information on how the filters are implemented I'll have a go at fixing this myself, I've taken a quick look at the filters folder in the source directory but nothing's jumping out at me and I'm currently pretty busy desperately trying to finish off my thesis!

Cheers,

John



On Tue, Jul 20, 2010 at 7:55 PM, John Wilson <address@hidden> wrote:
Hello,

I've got a problem with the FIR filters in GNU radio. Basically, at the moment I'm using it as a platform to run some simulations on (as I've already written a load of code on it for implementing a digital radio), and one of the tests I'm doing is trying to find the BER through an equaliser. To do this I'm loading a vector source up, running my flow graph with run() and upon completion I'm checking a vector sink for errors. This works fine for a fixed channel. The channel model I'm now using (a Watterson model which I've coded into the flow graph), however, uses a FIR with a large number of taps. Now the problem is that every time I run my flow graph with run(), which presumably also calls wait(), the FIR seems to start from a reset state. Is there any way to keep the contents of the FIR's shift register in situ through calling run() multiple times? Every other signal processing block I have maintains its state through this. For the record I'm not calling stop() at all in the code, which I would expect to reset everything.

I've set up a quick test case to describe this problem,

So if I set up a little top_block like this, which just sends a string of complex symbols valued +1+0j through a FIR filter, and receives the result in block_out;

------------------------------
--------------------------------------------------------------------------------------
class my_top_block(gr.top_block):
  def __init__(self): 
    gr.top_block.__init__(self)
       
    self.data_rate = 1000; 
    self.totbits = 0;
    self.toterrors = 0;
   
    grey_const = ([1, -1])
   
    length = 2
       
    blank = [0x0,] * (length)
    taps = [1,] * 10
       
    self.transmit_source = gr.vector_source_b(blank, False, length);
   
    self.unpack_for_mod = gr.packed_to_unpacked_bb(1, gr.GR_MSB_FIRST)
   
    self.symbol_mapper = gr.chunks_to_symbols_bc(grey_const)
   
    self.fir = gr.fir_filter_ccc(1, taps)
   
    self.v2s = gr.vector_to_stream(1, length)
   
    self.connect(self.transmit_source, self.v2s, self.unpack_for_mod, self.symbol_mapper, self.fir)

    self.connect(self.fir, block_out)
-------------------------------------------------------------------------------------------------------------

Then if I run it from main() like this;

-------------------------------------------------------------------------------------------------------------
def main ():

        tb = my_top_block();
       
        for a in range(20):
           
            tb.run()
           
            for n in block_out.data():

            print n

        block_out.clear()

        tb.transmit_source.rewind()

-------------------------------------------------------------------------------------------------------------

I get as output;

-------------------------------------------------------------------------------------------------------------
>>> gr_fir_ccc: using SSE
(1+0j)
(2+0j)
(3+0j)
(4+0j)
(5+0j)
(6+0j)
(7+0j)
(8+0j)
(9+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(1+0j)
(2+0j)
(3+0j)
(4+0j)
(5+0j)
(6+0j)
(7+0j)
(8+0j)
(9+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(10+0j)
(1+0j)
(2+0j)
(3+0j)
(4+0j)
(5+0j)
(6+0j)
(7+0j)
(8+0j)
.
.
etc
------------------------------------------------------------------------------------------------

Which is wrong (after the first 10 outputs the output should always be (10+0j). Is this a bug? Also does anyone know of any work around?

Cheers,

John


reply via email to

[Prev in Thread] Current Thread [Next in Thread]