How to manage time!

Hello everybody,
I want to have a block of, for example, bit generator, which generates
1000
bps. How could I manage the time in a thread (or equivalently in a
block)??
Or saying in general, how could I manage timing for passing data
between
blocks!?

I saw the “Throttle” block of gnuradio in c++ but I didn’t how it
works!!

best,

Hi Mostafa,

I’m not really sure I understand your question:
there is different “times” in DSP:

  1. the times relative to the “information theoretical world”, which
    increases with 1/f_sample per sample
  2. the time relative to the computing machine, which just runs along
    while the computer is busy computing

Throttle is explicitely just a throttle block. For a purely
simulating
flowgraph, you can use it to limit CPU usage. it has no
other purpose. It is a very very rough mapping of the first time to the
second one. It really has no data effect. I emphasisize this, because
that mistake is made so often: it does not change the samples at all. it
just limits the speed they are processed with.

I think your question is “I want to have a sample stream that contains
1000 bits of information for each second worth of samples”. So you have
to calculate how many samples you have per bit at your specified
sampling rate and use that.

Since you write “I saw the trottle block but I don’t know what it does”,
I think you can learn interesting things by working through the
Tutorials on
http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials from top to
bottom. This will clear up a lot of things!

Greetings,
Marcus

On Fri, May 9, 2014 at 1:24 AM, Mostafa A.
[email protected]wrote:

Hello everybody,
I want to have a block of, for example, bit generator, which generates
1000 bps. How could I manage the time in a thread (or equivalently in a
block)??
Or saying in general, how could I manage timing for passing data between
blocks!?

I saw the “Throttle” block of gnuradio in c++ but I didn’t how it works!!

Let me put the answer into layman’s terms.

1). If there is any USRP (or audio block) in the flowgraph, then you
just
need to calculate a sampling rate (samp_rate) value and configure this
to
your bit-generator block.
If this samp_rate value is correct, your bit-gnerator block will
automatically generates output at 1000 bps.
To calculate this samp_rate, you need to look at the flow graph, how the
blocks are interconnected.

2). If there is no USRP (nor audio block) in the flowgraph, it is not
so
critical whether your bit-generator block actually generates output at
1000
bps or 10,000 bps or 100,000 bps.
This is because software simulation can be a fast-forward version of the
actual speed.

3). Throttle block is needed only when there is no USRP (nor audio
block)
in your flow graph, to increase user experience. The settings of the
throttle block has no effect on your simulation result.

Hi Marcus,

I actually want to implement a transmitter. So in this transmitter
different data streams come from different sources with different rates
(or
sample rates). Then all of these streams gather together in a block, may
I
call it “Collector” then it sends the gathered data stream to the USRP
sink. The Collector block should gather the data stream in some
specific
manner to put the streams in a particular frame!

The only thing I don’t know here is how could I generate these
different-rate data?

At the receiver we don’t have any problem like this one, I think,
because
we can set the sample rate for USRP then after detection of the data
streams in the frame we actually could find the
transmitted-dirfferent-rate streams with different rate. :slight_smile:

Any idea please?

best,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mostafa,

you will have to have all your sample streams at the same nominal
sampling rate (which again has nothing to do with the item rate you
described). You do that by resampling.

How you combine these streams is obviously totally part of what your
application has to define.

Greetings,
Marcus

On 09.05.2014 08:14, Mostafa A. wrote:

The only thing I don’t know here is how could I generate these

process samples en block.

Hi Marcus, I did know about the Throttle block and which

1/f_sample per sample 2. the time relative to the computing

passing data

– Sent from my Android device with K-9 Mail. Please excuse my
brevity.

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTbICZAAoJEBQ6EdjyzlHty44IAIPwu9yqultka/oTr5zQq/IY
BlI+b9EE7KXUaxzsjLst1puw0ckiQ5RoDY/fXr9eA+DV9HBGgCFtwCobkn4MTLm0
aKU7DEpJfVpGDhFSmTA9Q/7EJupprccvK9AR4MC8zKx/WyS8avQk+9kJaeeDw7CZ
R94CH/whUDrfyeLLMyzc2cXQMEdHEBj5dqfi9ybNw2EgtsxXM/urBBgK/hTbucvA
sWFcJTD3h3aOKold/Kjn8ksGDmjrfIs5Ym/We62h+sUS+DKDHX3/AnEHA2p7pFGc
9CgxPfTUs6LYKYxogzyoQnx1DtaNVrDq6gI//YceT8WLV4ADTY4xK5U+B8ABjpo=
=2SWS
-----END PGP SIGNATURE-----

On Fri, May 9, 2014 at 2:14 PM, Mostafa A.
[email protected]wrote:

Hi Marcus,

I actually want to implement a transmitter. So in this transmitter
different data streams come from different sources with different rates (or
sample rates).

I feel this was actually the same problem, at
http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html
In this thread Tom’s solution was to set the IO signature as:

gr::io_signature::make2(2, 2, 1000sizeof(type0), 1sizeof(type1))

Whereas Marcus suggests to use resampler block, I agree this approach is
simpler and less confusing especially to new comers like Mostafa.

Pls stay on the list.

Hi Marcus and Activecat,

Thank to you Activecat for your proposed solution to the question. The
method is very interesting to me to use forecast and consume or
setting
right values in the io_signature.
As Marcus said it’s better to use interpolator or decimators to
change
the rates and I know it’s the best.

Marcus I know what you said about sampling theory. But you must notice
that
the higher the sampling rate, the greater the number of samples you get
in
a particular period of time (real world time). In your example the sine
has
a frequency of 1000 ( in real time) but the number of samples of that
sine
function, could be determined with your sampling rate.

Best,

On Fri, May 9, 2014 at 2:14 PM, Mostafa A.
[email protected]wrote:

To accomplish this, you need to forecast() and consume() different rates
at
different ports.
Let me give you a sample code similar to your “Collector” block.

Say both block A and block B are directly connected to your Collector
block.
Block A output rate = rate1 = 200ksps
Block B output rate = rate2 = 10kbps
Collector block output rate = 200kbps

Below is the collector_impl.cc:

namespace gr {
  namespace activecat {

    // make
    quad_up2::sptr
    quad_up2::make( float rate1, float rate2 )
    {
      return gnuradio::get_initial_sptr
        (new quad_up2_impl(rate1, rate2));
    }


    // constructor
    quad_up2_impl::quad_up2_impl( float rate1, float rate2 )
      : gr::block( "quad_up2",
              gr::io_signature::make( 2, 2, sizeof(gr_complex) ),
              gr::io_signature::make( 1, 1, sizeof(float) ) ),
          d_rate1( rate1 ),
          d_rate2( rate2 )
    {
        if ( (int)rate1 % (int)rate2 )
            throw std::runtime_error( "quad_up1: rate1 must be exact

multiple of rate2" );

        d_ratio12 = int( rate1 / rate2 );         // equals to 20 in

this example

        set_output_multiple( d_ratio12 );
    }


    // destructor
    quad_up2_impl::~quad_up2_impl()
    { }


    // forecast
    void
    quad_up2_impl::forecast (int noutput_items, gr_vector_int

&ninput_items_required)
{
ninput_items_required[0] = noutput_items / d_ratio12;
//
connected to Block B
ninput_items_required[1] = noutput_items;
// connected to Block A
}

    // general_work
    int
    quad_up2_impl::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 *data = (const gr_complex *)

input_items[0]; // connected to Block B
const gr_complex *clk = (const gr_complex *)
input_items[1]; // connected to Block A
float *out = (float *)
output_items[0];

        if ( noutput_items % d_ratio12 )
        {
            std::cout << "noutput_items = " << noutput_items << ",

d_ratio12 = " << d_ratio12 << std::endl;
throw std::runtime_error(“quad_up2: noutput_items is not
exact multiple of d_ratio12”);
}

        for( int i=0; i < noutput_items; i++)
            out[i] =  clk[i].real() * data[ i/d_ratio12 ].real()  -

clk[i].imag() * data[ i/d_ratio12 ].imag();

        consume(0, noutput_items / d_ratio12);       // consumes 

data
from Block B
consume(1, noutput_items ); // consumes
data from Block A

        return noutput_items;
    }

  } /* namespace activecat */
} /* namespace gr */

Dear Activecat,

To be honest, I’m still confused!! :slight_smile:
I want to have a source which generates a stream in a specific sample
rate
(or approximately, in average). Take a look at Audio source block, or
some
other source blocks, if there any, which takes sample rate as an input.
(for instance USRP source also has this kind of input)
You will see options for sampling frequency in *audio source block *by
that
rate outputs samples of type float. This block that I don’t know how
works,
it’s somehow what I want as a source to run my signal processing chain.

If I could be enable to have such source block, I have nothing else to
be
worry!

Thanks,

Hi Activecat, hi Mostafa,

The only thing I don’t know here is how could I generate these
different-rate data?
The rate of data is really just a property of the values of the samples.
For example, a sine with a frequency of 1000 will have a period of 32
samples for a sample rate of 32000, if you have the same sine at a
sample rate of 64000, its period will be 64 samples… note that
frequency and sample rate are all nothing but relative numbers.

If you have two things in your flow graph that produce signals related
to a different sampling rate (again, there is no awareness of any
sampling rate at all in GNU Radio, it’s just that frequencies you
specify relate to a sample rate that you or your device specify
themselves), you will have to match one sample rate to the other.
That means resampling. To explain using aforementioned example: if you
want to make sense while adding up the two sines, you would resample the
32k sampling rate to 64k, and then add the two sample streams.

This is the very basic idea of digital signal processing: you don’t
really care about the rates at which signals occur - you just math them
hard enough until they match your model.

To accomplish this, you need to forecast() and consume() different rates at
different ports.
Not really. Usually, you use one of the existing resampler blocks. Then
you just use whatever block type with the then equally-sampled streams.

There is very rarely the need for implementing your own forecast with
these kind of streams. For fixed ratio integral resamplers, just use the
decimator or interpolator block types.

I hope to conclude this thread with this. The information-theory
sampling rate vs. processing item rate vs. real time problem is a tough
one to get one’s head around; however, I think trying, playing around
and reading up on things is the right way to go from here for you,
Mostafa; it’s not very useful to discuss this on a mailing list like
this, I’m afraid.

Greetings,
Marcus

Hi Mostafa,

again: Start trying things out!

The Audio source is a hardware bound source, where theoretically
sampling rate and sample production rate match.
That’s only the case for hardware sources/sinks, and GNU Radio has no
chance nor will to enforce that, because it is software running on a
general purpose computer. Your sample stream is totally agnostic of
time. And there’s absolutely no way to change that in a properly
controlled manner.

So stop worrying, start trying, and let’s move away from this strange
thread :slight_smile:

Greetings,
Marcus

On Sat, May 10, 2014 at 3:38 PM, Mostafa A.
[email protected]wrote:

Dear Activecat,
To be honest, I’m still confused!! :slight_smile:

Mostafa,

Marcus and I have done our best to help you.
All the best.