Frequency modulating block

Hi

I just had a few questions regarding the frequency modulatig block. The
current input sample is used in conjuction with the sensitivity
parameter to determine the new phase value. Is this correct? I’m just a
bit confused as to how the phase calculations and the sensitivity
parameter relate to the instantaneous frequency output.

Secondly, I suppose this is a more general question about the vector and
file source blocks. At what rate are they producing data? For a non
repeating vector source of n values, how can I detemine the exact amount
of time it takes for all the values to be used?

Regards

Lance

On Mon, 2006-05-29 at 04:09 -0700, seph 004 wrote:

Secondly, I suppose this is a more general question about the vector
and file source blocks. At what rate are they producing data? For a
non repeating vector source of n values, how can I detemine the exact
amount of time it takes for all the values to be used?

As little as possible. There’s no concept of “rate” in the gnuradio
core. You push samples in, blocks process them, and they come out. You
will always be limited either by I/O speed or CPU speed. (Now, when you
have, e.g. 2 sound cards, and you get stuff from one and push it to the
other, it becomes a much trickier problem since they are under different
clock domains. But I don’t think that this is what you are asking
about.)

Now, there would be nothing stopping you from writing a block that
artificially introduced delays between samples as they were being fed
into the system, e.g. have a separate thread running, give it a rate to
send stuff out at, and every so many ms, it feeds gnuradio with a new
sample.

On Mon, May 29, 2006 at 04:09:17AM -0700, seph 004 wrote:

Hi

I just had a few questions regarding the frequency modulatig
block. The current input sample is used in conjuction with the
sensitivity parameter to determine the new phase value. Is this
correct?

Yes.

I’m just a bit confused as to how the phase calculations and the
sensitivity parameter relate to the instantaneous frequency output.

The instantaneous frequency would be d(d_phase)/dt.

If you feed the modulator a constant value, you’ll get a constant
frequency out.

int
gr_frequency_modulator_fc::work (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const float *in = (const float *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];

for (int i = 0; i < noutput_items; i++){
d_phase = d_phase + d_sensitivity * in[i];
float oi, oq;
gr_sincosf (d_phase, &oq, &oi);
out[i] = gr_complex (oi, oq);
}

// Limit the phase accumulator to [-16pi,16pi]
// to avoid loss of precision in the addition above.

if (fabs (d_phase) > 16 * M_PI){
double ii = trunc (d_phase / (2 * M_PI));
d_phase = d_phase - (ii * 2 * M_PI);
}

return noutput_items;
}

Secondly, I suppose this is a more general question about the vector
and file source blocks. At what rate are they producing data? For a
non repeating vector source of n values, how can I detemine the
exact amount of time it takes for all the values to be used?

They produce data at whatever rate the downstream blocks consume it.
No part of GNU Radio has any a priori knowledge of sample rate. It’s
just samples in / samples out. Sources or sinks that are tied to
external hardware such as an audio card or USRP will consume or
produce at the rate that they’re configured to run at.

Eric

Eric B. wrote:

On Mon, May 29, 2006 at 04:09:17AM -0700, seph 004 wrote:

Secondly, I suppose this is a more general question about the vector
and file source blocks. At what rate are they producing data?

They produce data at whatever rate the downstream blocks consume it.
No part of GNU Radio has any a priori knowledge of sample rate. It’s
just samples in / samples out.

I guess it could be called asynchronous, as it is not synchronized by
some central clock. Blocks are FIFOs, the flow graph connects them
together with sensible buffers, and scedules the blocks (possibly on
multiple processors) so that no buffer is empty at any time.
Is that correct?

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria