discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Difference between run and start/stop commands


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Difference between run and start/stop commands
Date: Fri, 9 Dec 2005 18:48:57 -0800
User-agent: Mutt/1.5.6i

On Fri, Dec 09, 2005 at 07:25:27PM -0500, address@hidden wrote:
> I know that the best method for correlating a is to use the new GMSK 
> code.  However, I am trying to understand the difference between the 
> run and start/stop/wait commands and also gain additional insight into 
> the simple_correlator function.  When I try to run the below code using 
> the fg.run command it displays the appropriate sequence numbers.  Once 
> it reaches the final packet, the program stops and seems to be waiting 
> for additional input.

Good questions!

    def run (self):
        '''start graph, wait for completion'''
        self.start ()
        self.wait ()
        

start performs a bunch of checks, then fires up the scheduler to
evalate the flow graph.

stop tells the scheduler to stop evaluating the graph.

wait waits for the graph to stop running.

Most graphs will run forever unless you explicity tell them to stop.
The exceptions are those which contain blocks that return -1 from
their work function.  This is a kind of EOF indication.  The most common
block that returns -1 is gr.file_source.  This allows us to process
data from a file and terminate when it's done.  The other block that
has this feature is gr.head(sizeof_item, nsamples).  It returns -1
after it copies nsamples from its input to its output.  Use it when
you want to only run something for a fixed number of samples.

Clear?

In your case, you shouldn't need both instances of head.
One should suffice.

> I suspect that this hang up is caused by the 
> simple_correlator function, but I am not really sure of the details of 
> why.

I'm not sure either.  simple_correlator can return 0, so it's possible
that somehow something's stuck in a loop making no progress.  However,
if the upstream is already in the "done" state, it should stop.  There
may be a bug in the scheduler.

To gather more info, edit
gnuradio-core/src/lib/runtime/gr_single_threaded_scheduler.cc.  
Change the line that says 

  #define ENABLE_LOGGING 0

to

  #define ENABLE_LOGGING 1

then do a make install from gnuradio-core/src/lib

When you run your code, you'll find an ascii log file called sst-0.log
in the current directory.  Examining it might shine some light
on the problem.

> If I replace the fg.run command with the combination of fg.start 
> and fg.stop, the program works fine.  However, I would prefer not to 
> have to hit enter once the program finishes executing.  Why does 
> fg.start/stop work but fg.run not work?  Also, in the check_lfsr 
> function, what is the significance of runlength value?

runlength is the number of consecutive shorts that were right.

BTW, I suspect that there is a problem in either gr_check_lfsr_32k_s
and/or gr_lfsr_32k_source, since when I loopback the FPGA and
feed it a counter it works, but sending it the lfsr it doesn't.
I think something might be hosed in the state machine in check_lfsr.

Eric




reply via email to

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