Hi Marcus,
By mentioning that I spent many hours I wanted to say I'm hardly stuck on
this problem yet! :)
You said the there is no problem that we wait on the source to produce as
long as we want! But this is not true when I have other blocks waiting for
processing!! In other word, when the source produces one packet, I want
this packet go down through blocks and amid of these blocks a message must
tells the source to produce again.
*If the source doesn't produce anything after generating some packets, the
scheduler will be locked on the source and does nothing with other blocks!!*
As you said, the *wait* will work for this source, but it's also has the
same problem I mentioned.
Here is the summary of *random bit generator:*
#include <gnuradio/io_signature.h>
#include <stdlib.h>
#include <time.h>
#include <bitset>
#include <unistd.h>
namespace gr {
namespace my_lte {
lte_random_bit_gen::sptr
lte_random_bit_gen::make(int packet_len) // packet_len: the size of
generating packet bits
{
return gnuradio::get_initial_sptr
(new lte_random_bit_gen_impl(packet_len));
}
/*
* The private constructor
*/
lte_random_bit_gen_impl::lte_random_bit_gen_impl(int packet_len)
: gr::sync_block("lte_random_bit_gen",
gr::io_signature::make(0, 0, 0),
gr::io_signature::make(1, 1, sizeof(char))),
packet_length(packet_len),
{
srand (time(NULL)); // randomizing the seed
set_max_noutput_items(packet_length);
}
lte_random_bit_gen_impl::~lte_random_bit_gen_impl()
{
}
int
lte_random_bit_gen_impl::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
char *out = (char *) output_items[0];
int random_val, nout_written = 0;
for (int i=0; i<packet_length; i++)
{
random_val = rand();
bitset<8> b(random_val);
if (b[0] == 0)
*out = 1;
else
*out = 0;
out++;
nout_written++;
}
// add tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol("length"),
pmt::from_long(packet_length));
cout << "bit generator " << endl ;
return nout_written;
}
On Sun, Jun 1, 2014 at 1:43 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:
> Mostafa,
>
> I know you've been working many hours on this :) so don't worry, you're
> being heard.
>
> Nevertheless, GNU Radio is surely not calling the asking the source
> "crazily" to produce items.
>
> GNU Radio is a streaming-into-buffers architecture, which means that the
> runtime will ask a source to produce output when there is space in the
> output buffer. I fail to see the problem with this, since your source
> can just take as much time as it wants to finish a work call, can
> produce less than noutput_items, and generally should just be as fast as
> it could. Not a single one of the items it produced is going to waste!
>
> It is good practice and done by *every* externally rate-limited source
> to just block in work until enough items can be produced. If you need to
> wait to get more random seed, well, then wait in work(). I admit, that
> gets a little tricky when you want your seed to come in using a message,
> because messages are not going to disturb your work due to design for
> thread-safety.
>
> But then again, before I start proposing wait-notify/condition
> multithreading methods, I'd like to hear a bit about your source and why
> being called often is a problem; that's usually not the case, so chances
> are we might help you find a solution if we understood what's wrong with
> your source ;)
>
> Greetings,
> Marcus
>
> On 01.06.2014 10:56, Mostafa Alizadeh wrote:
> > Hi Mike,
> >
> > No, the throttle isn't a source! It just controls the flow of items in an
> > specific time interval. I don't want this! I want cognitively tell the
> > source produces the random bits after some special procedures have done
> (a
> > message can do this for the source). But the scheduler crazily wants the
> > source to produce items! :)
> >
> > How could I deal with this problem?
> > please.
> >
> > Best,
> >
> >
> >
> > On Sun, Jun 1, 2014 at 1:18 PM, Mike Jameson <mike.jame...@ettus.com>
> wrote:
> >
> >> The "Throttle" block is required if you are not using any external
> >> hardware:
> >>
> >> http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1throttle.html
> >>
> >> Mike
> >>
> >> --
> >> Mike Jameson M0MIK BSc MIET
> >> Ettus Research Technical Support
> >> Email: supp...@ettus.com
> >> Web: http://ettus.com
> >>
> >>
> >> On Sun, Jun 1, 2014 at 9:30 AM, Mostafa Alizadeh <
> m.alizade...@gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>> I worked on GNURadio for many hours. After all, I prepared my blocks in
> >>> c++. However, the source by which I produce random bits (items with
> >>> sizeof(char) ) doesn't work properly! By properly I mean, I wanted
> GNURadio
> >>> to lead me control how it's going to call the *source.* It's crazily
> >>> calling the random bit generator so many times.
> >>>
> >>> I think this is because of the GNURadio's strategy for executing blocks
> >>> to achieve as maximum throughput as possible! So GNURadio translates
> it*
> >>> to call the source as much as possible*.(no matter what is the source,
> >>> here is the random bit generator)
> >>>
> >>> Am I right? If I am, what is the solution?
> >>>
> >>> Best,
> >>> Mostafa
> >>>
> >>> _______________________________________________
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>
> >>>
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
