Re: [Discuss-gnuradio] sync_interpolator

[Martin Braun (CEL)]

On Tue, Aug 27, 2013 at 02:43:32AM -0500, Miklos Maroti wrote:
> Hi Martin,
> 
> I have checked the tutorials, but they do not give precise details.

http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
discusses the whole concept several times.

> Here is what I have discovered with a general block:
> 
> 1) set_history(1+m) will simply fill your input buffer with m many
> zero items at startup, then your input data will follow.

You're missing the point. In *every* work call, you will have 'm' extra
samples to calculate your output.
 
> 2) If you actually want to see more samples in your work method, then
> you have to increase the requested number of inputs in your forecast
> method by history() - 1.

OK, only mess around with forecast() if you know what you're doing.
If you need the precise history inside forecast(), chances are the
default behaviour will already do what you want.

> 3) To see actual history, you have to do both 1) and 2) and do NOT
> consume in your work method every sample you have requested in
> forecast, only the regular amount so you maintain the proper amount of
> past samples in your input buffer.

In a sync block, the input buffer is always history()-1 larger than the
output buffer. Does this help?

> 4) You can do 2) alone without 1), but then you are going to work with
> "future" samples. So you can always request more input but you are not
> going to consume it, so you will see the future.

If I understand you correctly: No!

> 5) Many blocks (sync, sync_interpolator, sync_decimator, general) will
> actually implement some default behaviour for your forecast method,
> and there they take history() into account. However, if you
> reimplement forecast() and forget to include your history, then in
> your work method you are going to read garbage outside of your input
> buffer (which will be hard to debug).

You will always read garbage *outside* of your input buffer.

> 6) The amount of input items in your work method is exactly the amount
> (or more) you have requested in your forecast, so magically you will
> not have more input data because of set_history() is called.

Let me put it this way: GNU Radio has many ways to configure the
scheduling behaviour. You're not supposed to use *all* of them at once.

Think about what your block is doing. Do you really need to both change
forecast() *and* fiddle with history()? Perhaps you do, but it does seem
unlikely.

MB

> 
> Are these statements correct? Best,
> Miklos
> 
> 
> On Tue, Aug 27, 2013 at 2:19 AM, Martin Braun (CEL)
> <address@hidden> wrote:
> > On Tue, Aug 27, 2013 at 12:11:48AM -0500, Miklos Maroti wrote:
> >> Hi Guys,
> >>
> >> I do not understand how set_history and fixed rate blocks are
> >> interacting. Supposedly, the scheduler can figure out a static
> >> schedule for sync blocks. However, the sync_interpolator is forcasting
> >> this
> >>
> >> int sync_interpolator::fixed_rate_noutput_to_ninput(int noutput_items) {
> >>     return noutput_items / interpolation() + history() - 1;
> >> }
> >>
> >> but consumes only noutput_items / interpolation(). This means, that
> >> the scheduler is making a schedule based on the wrong info, the block
> >> is actually consuming LESS than it has predicted, so how can the
> >> scheduler make optimal schedule?
> >
> > Hi Miklos,
> >
> > Think of the history as the number of *past* input samples it takes
> > to produce one output sample. The classic example is an FIR filter,
> > where you need as many samples as you have taps.
> > Minimum is of course 1 (which means you need only the current sample).
> > This is also the default value.
> >
> > In a sync_interpolator, noutput_items is always an integer multiple of
> > ninput_items. So if you have no history configured, it must consume
> > noutput_items / interpolation(). So what you're seeing is correct
> > (unless you changed your history).
> >
> >> On this point, it is not clear how history() is handled. I searched
> >> the archives, and the wisdom is, that set_history(2) means, that all
> >
> > I'm sure the topic of history() is covered in the tutorials. Also, what
> > you're saying is correct and fits what I just explained above.
> >
> > MB
> >
> >> the ninput_items and noutput_items and their relationship is
> >> completely unchanged, but we have an extra sample at the beginning of
> >> the input buffer. However, the sync_interpolator does not do this, it
> >> actually includes the history amount in the requested input. So does
> >> the scheduler takes history amounts into account, and the
> >> sync_interpolator has a bug, or every block has to add the history
> >> into their forecast?
> >>
> >> This is really confusing. I hope someone can shed some light on this.
> >>
> >> Best,
> >> Miklos
> >>
> >> _______________________________________________
> >> Discuss-gnuradio mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > --
> > Karlsruhe Institute of Technology (KIT)
> > Communications Engineering Lab (CEL)
> >
> > Dipl.-Ing. Martin Braun
> > Research Associate
> >
> > Kaiserstraße 12
> > Building 05.01
> > 76131 Karlsruhe
> >
> > Phone: +49 721 608-43790
> > Fax: +49 721 608-46071
> > www.cel.kit.edu
> >
> > KIT -- University of the State of Baden-Württemberg and
> > National Laboratory of the Helmholtz Association
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

pgpfvwsg62vwB.pgp
Description: PGP signature