Re: [Discuss-gnuradio] sync_interpolator

[Miklos Maroti]

Hi Martin,

On Tue, Aug 27, 2013 at 3:07 AM, Martin Braun (CEL)
<address@hidden> wrote:
> 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.

This is not true, unless you rely on the stock gnuradio blocks, like
sync_interpolator for which forecast actually requests "noutput_items
/ interpolation() + history() - 1" input items. If what you are saying
were true, i.e. a general block would always give you 'm' extra input
after the set_history(1+m), then sync_interpolator would only need to
request "output_items / interpolation()" items.

>> 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.

I want to mess around with forecast, I want to understand how these
things interact. Sure, if you stick with stock blocks, then everything
will work, but the stock stuff is not good for me.

>> 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?

It is, because in forecast it asked for that many input items more.

>> 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!

I think you are wrong. You can set_history(1), and request
noutput_items + 10 in your forecast, then you will always have 10 more
extra samples in your general work, so you will see the future. Of
course you should consume noutput_items to maintain it that way.

>> 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.

The question is how large the input buffer is. What I am claiming that
the size of the input buffer is always as large (or larger) as what
you have requested in your forecast method. If you ask for 10 input
samples in your forecast, then you get 10 samples no matter what the
history is!!!

>> 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.

Why? Stock blocks use all of them!

> 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.

I know what I am doing, and I need that behavior, which cannot be
achieves with stock blocks. So the question remains: can you disprove
the above 6 claims?

Best,
Miklos

>
> 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
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>