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)
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?
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.
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:
// 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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.