Re: [Discuss-gnuradio] using general_work when output rate is not fixed

[Tom Rondeau]

On Sun, Sep 9, 2012 at 6:39 PM, Rahman, Muhammad Mahboob Ur
<address@hidden> wrote:
> All,
>
> I have made a simple custom block (derived from gr_block class) whose
> general_work() function is given below:
>
> int howto_my_custom_blk::general_work (int noutput_items, gr_vector_int
> &ninput_items, gr_vector_const_void_star &input_items, gr_vector_void_star
> &output_items){
>   const gr_complex *in = (const gr_complex *) input_items[0];
>   const short *trigger = (const short *) input_items[1];
>   gr_complex *out = (gr_complex *) output_items[0];
>
>   int ninput_items_used_in_this_work_call;
>   ninput_items_used_in_this_work_call = 0;
>
>   for (int i = 0; i < noutput_items; i++){
>     if (trigger[i] > 0) {
>         out[i] = in[i];
>         ninput_items_used_in_this_work_call++;
>          if (!tx_sob_sent) { this->make_sob_tag(this->nitems_written(0) +
> i); tx_sob_sent = true; tx_eob_sent = false;}
>
>     }
>     else {
>         if (!tx_eob_sent) { this->make_eob_tag(this->nitems_written(0) +
> i-1); tx_eob_sent = true; tx_sob_sent = false; }
>     }
>   }
>   consume_each (ninput_items[0]);
>
>   return ninput_items_used_in_this_work_call;
> }

Hi Mahboob,

I would consume_each(noutput_items) since ninput_items[0] >=
noutput_items (I'm guessing you are using the standard forecast
function), but you are only looking over noutput_items in your for
loop. So you might have more inputs available that you are looking at
and by consuming all of the inputs, you might be dropping data. So
look at that and see if it solves your main problem.

The other thing is that the way we handled it in the burst detector
was that we send a tag once when the burst signal goes high and then
another when it goes low. It looks like you are sending a tag every
time trigger > 0, which could mean you will be sending a lot of tags
through the system, which can be expensive. This is an optimization
for the scheduler, but a pretty big one since moving
hundreds/thousands of tags a second through the scheduler will
significantly impact the performance.

Hope this helps,
Tom



> Some comments about the block ports:
> In above custom block code,
> - in is an input which comes from uhd_usrp_source and consists of set of
> packets sent by some packet transmitter.
> - trigger is an input which goes high (>0) every time a packet is detected
> and remains high thereafter for the duration of packet. It is essentially
> Tom's energy detection mechanism borrowed from uhd_burst_detector.py.
> - out is the block output which goes to uhd_usrp_sink.
> In short, my custom block receives a set of packets and forwards it to the
> tx side of the usrp.
>
> Now, I have some questions which are as follows:
>
> -  When trigger goes high, the input samples at in (which correspond to the
> received packet) should be copied to the output and then sent to the
> uhd_usrp sink. But this is not the case, as I see using the external
> oscilloscope (and by recording the output out of the block into a file) that
> instead the noise samples are copied to output. Why it is so?
> - As can be seen, general_work() returns ninput_items_used_in_this_work_call
> every time it is called by scheduler. Since trigger remains low most of the
> time, it means general_work() will produce no output samples most of the
> times it is called. But the output port out is connected to uhd_usrp_source
> which will produce underruns every time my custom block does not produce an
> output. I have put sob and eob tags to eliminate this problem but did not
> succeed. Any ideas, what might be wrong?
> - Since my custom block is not a fixed ratio block, how should I override
> the forecast function, or, is it optional and meant for efficiency purposes?
>
>
> Thanks,
> Mahboob
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>