|
From: | bob wole |
Subject: | Re: [Discuss-gnuradio] Question about correlate_access_code_bb_impl |
Date: | Tue, 22 Sep 2015 10:00:56 +0500 |
On Mon, Sep 21, 2015 at 6:40 AM, bob wole <address@hidden> wrote:BobCan somebody please tell me why ?I am studying the code of correlate_access_code_bb_impl.cc for understanding its working. I see that the block is derive from "block" class of gr as written in correlate_access_code_bb_ts.h fileI read earlier that blocks derived from "block"/"gr::block" should implement forecast() method, but I did not see any implementation of forecast() in code of correlate_access_code_bb_impl.cc.
class DIGITAL_API correlate_access_code_bb_ts : virtual public block
--First, you have a misunderstanding of the header/source relationship. There are a number of correlate* blocks in GNU Radio (and an unwritten plan to organize them better in the future). The correlate_access_code_bb is one block, and this is a gr::sync_block. The correlate_access_code_bb_ts is another block, and this one is a gr::block.If you look at the code for block.cc, you'll see it implements a forecast function already:voidblock::forecast(int noutput_items, gr_vector_int &ninput_items_required){unsigned ninputs = ninput_items_required.size ();for(unsigned i = 0; i < ninputs; i++)ninput_items_required[i] = noutput_items + history() - 1;}That means that any block that derives from gr::block gets this behavior, which tells the scheduler that given noutput_items, the block needs this many input items to produce that output amount. This is a satisfactory condition for many blocks, so no, you don't /have/ to overload forecast in your derived block if this condition meets your block's behavior.Tom
[Prev in Thread] | Current Thread | [Next in Thread] |