|Subject:||Re: [Discuss-gnuradio] What if noutput_itmes is too short?|
|Date:||Fri, 29 May 2015 14:52:20 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0|
On 05/29/2015 01:46 PM, Jeon wrote:
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.
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.
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 .
|[Prev in Thread]||Current Thread||[Next in Thread]|