Hi Jeon, On 05/29/2015 05:25 PM, Jeon wrote: > As I understand, if I consume(0, n), where n is less than > ninput_items, then only n samples at the front of input_items[] are > consumed and unconsumed part remains. And then, at the next call of > general_work(), incoming samples are appended at the end of > input_item[]. Is this right? yes :) > > If it is right, I can get a single whole payload by not consuming > input samples after some time passed... you should always consume as many samples as possible to keep the flow graph running; hence my recommendation to implement the forecast in a manner that guarantees that your work will only be called with "enough" input. > However, I am still doubtful that input_items[] will not be appended > as I think since output buffer at the previous block isn't cleared > enough as `consume()` is not called. the output buffer is completely independent from consume(); space in the output buffer gets freed as soon as the downstream block calls consume(), and gets filled by the amount you produce(). > > Well... Does `forecast()` which you've mentioned make the previous > block can send more streams and the current block can received them? No, forecast is just the method that GNU radio calls to ask "hey, block! If I want you to produce x items, how much input would you need?". In your case, the honest answer for any x>0 would be "I need a whole payload length of items if I should produce anything". If you call set_output_multiple(payload_length), you will be guaranteed enough space for at least one payload per general_work() call.
> So far, I understand `forecast()` acts as just a blocker unless enough > samples are given. It's more of a way of telling GNU Radio what to expect from your block. > > In the developing stage, I am using fixed length payload. But, I want > to make it work with arbitrary length (but not too long). In that case, use a forecast() that adjusts the returned length as soon as your block knows how long the payload will be -- forecast() is really just a hint for GNU Radio, so it doesn't hurt if it's not 100% accurate (i.e. you produce less than what you've "promised" in forecast). Best regards, Marcus > On Fri, May 29, 2015 at 9:52 PM Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: > > Hi Jeon, > > > > On 05/29/2015 01:46 PM, Jeon wrote: >> I am trying to remove `preamble` and `start frame delimiter` from >> a frame and only the payload will be passed to the next block. >> >> While in debugging, `ninput_items` is 7742, and `noutput_items` >> is 4096, for instance. An offset where the frame starts is 790. >> >> Simple calculation gives me that 7742 - 790 = 6952 samples should >> be passed to the next block. But output space given is only 4096. >> Thus, I can only pass 4096 samples and 6952 - 4096 = 2856 samples >> will be discarded. But, I need them to be passed, too. > > There's no reason not to pass through your payload in parts, if > you implement a state machine with a counter for remaining items > to pass through in your block. > However, there's an advantage to waiting for the whole payload to > be on your input at once, which I'll explain further down. > Does your payload always have the same length? In that case, your > forecast should always demand payload_length input items to > produce any amount of output items -- that way, you can make sure > that at *one point*, you get the whole payload into your input buffer. > > No matter what you really do, you will need to use a state machine > of some kind. > In your case, that's comparatively easy: Just check, at the > beginning of each general_work call, whether you're in > pass-through mode, or in "search preamble mode", etc, and let your > work act based upon that. For example, assume you're in search > preamble mode, you find a preamble, so you consume all items up to > the end of that preamble, and set your state to "pass through", > and then return from general_work. Before GNU Radio calls you next > time, it will ask forecast() how many input items you need. > Forecast always says it needs payload_length items, so at the > point where work is actually called in "pass through" mode, you > *should* have at least payload_length input items; let your block > consume and produce these items, switch to "search preamble mode", > and return. > >> >> Even worse, a stream of samples are coming continuously from a >> previous block. > Lucky you! You have GNU Radio, which makes sure there's only one > instance of your general_work being run at once, and presenting > you with all the items you did not consume in the previous > general_work calls. > >> >> Will it be helpful if I have some very long buffer in a block? I >> don't think it works since `noutput_items` is always smaller than >> `ninput_items` every time the block runs `general_work()`. > That's not generally the case. It might be the case here, but that > simply means that the downstream block isn't consuming the whole > buffer, or your upstream items are larger, or your upstream block > is just much faster at producing items than you and your > downstream blocks are at consuming them. > > If you just try to rely on GNU Radio's buffers, you would be safe > from something like buffer overflows happening -- GNU Radio will > only call the upstream's general_work function if there is enough > space in its output buffer (which is your input buffer). > > Personally, I think what you're doing is a complicated task, so I > have a lot of respect for the effort you're putting into this. > I'd try to avoid the complexity by /not/ doing this in one block > -- use a preamble correlator to mark the beginning of your frame > with a stream tag. Then, use a state-machine block to only copy > the payload_length items after such a tag (a whole payload at a > time), adding a tag on the first item containing the length of the > payload as long: > I mentioned above there's an advantage to passing the whole > payload at once; what you have when you have a length tag on the > first item of contigous packet items is a tagged stream. Tagged > stream blocks are a GNU Radio concept dedicated to processing > packeted data, in which work() methods are always called with the > whole packet at once [1]. > > Best regards, > Marcus > > [1] http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto: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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
