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

[Adeel Anwar]

---------- Forwarded message ----------
From: Adeel Anwar <address@hidden>
Date: Wed, Sep 26, 2012 at 3:52 AM
Subject: Re: [Discuss-gnuradio] using general_work when output rate is not fixed
To: "Rahman, Muhammad Mahboob Ur" <address@hidden>


Mahboob,

uhd usrp sink. Now, the other issue is, when I send pre-recorded GMSK samples to the uhd usrp sink, I still see lot of underruns occuring

If ur aim is to TX discontinuous samples with SOB and EOB tags to avoid under-flows then

1. pre-recorded GMSK samples can be sent using gr_message_burst_source

          http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_6_2


2. u can take following gr-uhd example as a reference and modify it

http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-uhd/examples/c++/tag_source_demo.h



-Adeel

On Tue, Sep 25, 2012 at 12:02 PM, Rahman, Muhammad Mahboob Ur <address@hidden> wrote:

Hi Tom & All,

I am now doing consume_each(noutput_items) but my problem is not solved yet. I have also made sure that my code effectively sends one sob tag and one eob tag per burst of samples.

Questions about new experiment:
Now, I have created yet another simple experiment whose flow-graph is as follows:

uhd usrp source --> my custom block --> uhd usrp sink
                                                       |
                                                       --> file sink

The relevant code of my custom block is below:
int
howto_send_discont::general_work (...) {

  int ninput_items_used_in_this_work_call;
  ninput_items_used_in_this_work_call = 0;

  for (int i = 0; i < noutput_items; i++){

    samp_count++;
    if (samp_count == 1) { out[i] = gr_complex(0.7,0); this->make_sob_tag(this->nitems_written(0)+i);}
    else if (samp_count == 2) { out[i] = gr_complex(0.7,0); this->make_eob_tag(this->nitems_written(0)+i);}
    else if (samp_count == 25000) {
    samp_count = 0; send_tx_pkt = true; pkt_no++; }
    if (send_tx_pkt) {
        pkt_samp_no++;
        ninput_items_used_in_this_work_call++;
        /*if (total_samps_outputted_so_far == 7761) {
               pkt_samp_no = 1; samp_count = 1; total_samps_outputted_so_far = 10000; pkt_no = 0; }
        else if (total_samps_outputted_so_far < 7761){
               total_samps_outputted_so_far++; }*/
        out[i] = gmsk_pkt_samples_2[pkt_samp_no-1];
        if (pkt_samp_no == 1) {
            this->make_sob_tag(this->nitems_written(0)+i);
        }
        else if (pkt_samp_no == 1536) {
            this->make_eob_tag(this->nitems_written(0)+i);
            pkt_samp_no = 0;
            send_tx_pkt = false;
        }
    }

  }

  consume_each (noutput_items);

  // Tell runtime system how many output items we produced.
  return ninput_items_used_in_this_work_call;
}

You can see from the above code that my custom block maintains an internal counter samp_count which causes the custom block to output N samples whenever internal counter's count equals M (N=1536, M=25000 in my case). I use the same counter to initially send a burst of 2 samples to uhd usrp sink after attaching sob and eob tags so as to avoid underflow problem at the transmit side. But my problems are persistent which are:

- I see many zero-valued samples among the first 7761 output samples of my custom block, even when the samples my custom block should output are either constant valued samples or pre-recorded GMSK samples (depending upon which line is uncommented in my above code). Why it is so?

- Even though I have avoided the above mentioned problem by noticing that in my case, after first 7761 samples, all the subsequent samples are correct. So, I use another counter to start all over again (to reset the functionality of my block) once my custom block has sent 7761 samples to uhd usrp sink. Now, the other issue is, when I send pre-recorded GMSK samples to the uhd usrp sink, I still see lot of underruns occuring indefinitely at tx side. Why are the sob and eob tags being ineffective? Moreover, when those GMSK packets are received at another node, the packet decode rate is too low over there (I guess not all of the samples corresponding to many GMSK packets are being transmitted from node1, fix me).


Thanks in anticipation for your help,
Mahboob
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio