On Mon, Jun 2, 2014 at 1:27 AM, Mostafa Alizadeh
wrote:
> Activecat,
>
> I think change my topology to get rid of this things. :)
> However, I still believe in that the GNURadio fails in this scenario.
> As we have throttle or message_strobe blocks, I need to have a source
> which generates items
Hi Mostafa,
On 01.06.2014 19:23, Mostafa Alizadeh wrote:
> This is not true because when I produce 1-3 packet of bits, the
> scheduler doesn't go to the other blocks while there is items for
> them! The scheduler calls the random bit generator for about 10 times!!
I have tried that, and can disprov
Hi Mostafa,
this is no good. If you don't tell us why and how you would want to do
that, we can't discuss if and how GNU Radio is lacking.
Really, the GNU Radio architecture wasn't meant for this kind of flow
control, but that's less of a shortcoming than a design choice, keeping
flow graph design
Activecat,
I think change my topology to get rid of this things. :)
However, I still believe in that the GNURadio fails in this scenario.
As we have throttle or message_strobe blocks, I need to have a source which
generates items controlled by another block.
I'll try to see this problem in anothe
Hi Marcus,
On Sun, Jun 1, 2014 at 2:44 PM, Marcus Müller
wrote:
> Hi Mostafa,
>
> > 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!!
>
> Not true. If your block can't produce som
On Sun, Jun 1, 2014 at 4:56 PM, 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
>
Hi Mostafa,
> 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!!
Not true. If your block can't produce something, it's not GNU Radio's
fault your downstream blocks don't have anything to
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
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 prod
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 "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, Mo
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 th
12 matches
Mail list logo
