On 03/16/2012 09:35 PM, Tom Rondeau wrote:
On Fri, Mar 16, 2012 at 3:28 PM, Zhonghua <zhong...@sics.se <mailto:zhong...@sics.se>> wrote:

    On 03/16/2012 06:37 PM, Tom Rondeau wrote:
    On Fri, Mar 16, 2012 at 8:41 AM, Zhonghua <zhong...@sics.se
    <mailto:zhong...@sics.se>> wrote:

        Hi all,

        After a period of using gnu radio, I have a problem of how to
        understand the stream. I got an information from a literature
        says: 'From the high level point-of-view, infinite streams of
        data flow through the ports. At the C++ level,streams are
        dealt with in convenient sized pieces, represented as
        contiguous arrays of the underlying type.' In almost each
        signal processing block we can see the definition of
        'general_work' has this format:
            general_work(int noutput_items,
                            gr_vector_int &ninput_items,
                            gr_vector_const_void_star &input_items,
                            gr_vector_void_star &output_items)
        Some literatures say the 'noutput_items' variable represents
        the items number of one piece of the stream.  So the first
        question is what on earth the size of this variable? where
        dose it be specified? For example if A block connects to B
        block, how can ensure the 'noutput_items' of A block equal to
        the 'ninput_items' (presume B block only has one input stream).
        In an concrete instance, in gr_squelch_base_cc.cc, we can see
        the last program as:
           if (d_state != ST_MUTED)
              out[j++] = in[i]*gr_complex(d_envelope, 0.0);
           else
              if (!d_gate)
                 out[j++] = 0.0;
        If we set d_gate as False(Actually in case of high sample
        rate it has to be set as False), when the input power is
        lower than the threshold(means the d_state should be as
        ST_MUTED), the out[j] shall get nothing. That means at this
        point there is no output data. So how the sequential block
        recognise this point? For instance the sequential block is
        ieee802_15_4_demod, how could it know where is this lost
        point? If only one point lost from the squelch block, is that
        means the whole piece of stream and even the whole package
        could not be demodulated correctly?
        We can set the instance in more precise condition. If there
        are two pieces of stream: stream A and stream B. Assume each
        noutput_items is 10, that is to say we have A[0], A[1] ....to
        A[9] and B[0] to B[9]. If A[0] has lost, then the stream
        entering into the sequential demodulation block is
        A[0](lost),A[1]....A[9]? Or is A[1],A[2]....B[0]?
        If A[0] is valid, A[1] has lost, dose that mean the first
        piece of stream would not be demodulated correctly? If one
        package need both these two pieces of stream, dose it mean
        this package would not be demodulated correctly?

        Any answer is greatly appreciated.

        Sincerely,

        Zhonghua


    Zhonghua,

    This is a really complicated question to answer without giving
    you a full essay. All of this happens in the scheduler, so if you
    want to know more, study the code for the thread-per-block
    scheduler in gnuradio-core/src/lib/runtime. It's the
    gr_block_executor that looks at the read/write pointers to each
    blocks buffer and determines how many samples are available to be
    read and how many samples a block can write.

    Tom

    Hi Tom,

    Thank you for your information. I think you have answered the
    first question that where and how dose the size be determined. To
    the detailed question, do you think if one item lost, all this
    package will lose? And in my last instance, do you think which
    assemblage will be sent to the sequential block? Thank you again!

    Zhonghua


I'm honestly not sure what you are getting at. Where/how would you lose an item?

Tom

Hi Tom,

The background is that we lose some packets when use USRP E100 to implement IEEE802.15.4 protocol(4M sample rate). The computation capacities of the E100 platform is not very good. We think the high sample rate gives the demodulation block too high input load so packets will lose. To decrease the input load of demodulation block, we manage to raise the threshold of the squelch block. But if the threshold is too high, maybe some valid input items of squelch block will be incorrectly filtered. So we need to make sure if only one item lost will make the whole packet lose. From the original code of gr_squelch_base_cc.cc I think the first output item is always at the first position of the output piece no matter what the condition of the input piece. All output items in one piece should be consecutive. For example if input piece has IN[0],IN[1]...IN[5] in which IN[0] and IN[2] are lower than the threshold, the output piece should be OUT[0](IN[1]),OUT[1](IN[3]),OUT[2](IN[4]),OUT[3](IN[5]). There are no OUT[4] and OUT[5]. I don't know how does the subsequent demodulation sample this piece since it has only 4 items although one piece should has 6 items. One thing I think maybe sure is that if IN[2] is necessary but lost just because it is lower than the threshold, the input of demodulation block has changed so the result would not be correct.
I don't know is my understanding right or not.

Zhonghua
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to