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) > <martin.br...@kit.edu> 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 > >> Discuss-gnuradio@gnu.org > >> 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 > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > 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
pgpkXYxVkhSTc.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
