Re: [Discuss-gnuradio] Adjusting Sampling Frequency of Custom C++ Source Block Help

[Marcus Müller]

Hi Charles,

On 08.12.2015 03:45, Charles Bridger wrote:

I'm extremely new to this (gnuradio, usrp's, and radios in general) so I apologise if this question doesn't make sense or has obviously been answered else where ( I have up until now been trying to find answers without bothering anyone).

So: welcome! We really don't mind answering questions around here, so don't be afraid to ask anything you can't find an answer to.

I have written my own gnuradio block as a source, i'm trying to replicate the signal source waveform generator to get a grasp on how it is done.

Nice starter project!

My problem is that I don't know how to implement the Sampling Frequency. When I looked at the source of the block I'm trying to replicate I noticed it used a variable called nco to step along the wave it generates.

Currently I for my work method of my source block I have:

float *out = (float *) output_items[0];

for (int i = 0; i < noutput_items; i++)
{
    d_count = d_count + 1;
    out[i] = d_Amplitude * sin(2 * 3.14159 * d_WaveFreq * d_Count/5000000.0);
}

This produces a Sine and lets me control the amplitude and wave frequency nicely, but the purely depends on how fast samples are produced.My question is, how do I do this "properly"? How do I limit the amount of items produces/ how often the sine wave is sampled? I don't understand how the nco class does it in the provided block so I'm hoping for some clarification.

So, this is one thing that people commonly stumble across when they get in contact with GNU Radio-style DSP:
sampling rate is really just a number used to calculate the number of samples your sine takes to make a full period.
GNU Radio doesn't have any concept of real-world sampling rates, and it shouldn't: It just processes the samples it gets as fast as possible. Try it! Take the signal source you get with GNU Radio, set the sampling rate to 10 and the frequency to 1. A period will have 10 samples; the same happens when you set a sampling rate of 1e9 and a frequency of 100e6. When you connect your signal source to a "probe rate" block and let a "message debug" print out the rate at which samples are produced:


you'll see on your console that the sample rate setting has nothing to do with the speed at which samples are produced. They are passed along the flow graph as fast as possible, and since there's no external hardware block in here that actually limits the processing rate, that's as fast as your CPU can run.

I thought of checking the time that each sample was produced and comparing that to the previous one, having a variable controlling allowed time between the two or something like that, but it really comes down to me not really understanding how the items/samples are produced.

So: what you're trying to do is actually build a signal source that combines the features of the signal source with that of the "throttle" block. Throttle does nothing with the signal (really, nothing. It just copies from in- to output), but limits the number of items that pass through it.
It really has no practical value aside from stopping a rate-unlimited block from hogging all your CPU at once, and for visualizations of simulated/recorded signals to slow down things so you can actually see what happens e.g. in a Qt time sink.

Hope that cleared things up a bit; sampling rate is but a number with which some GNU Radio blocks calculate sample-relative frequencies.

Cheers,
Marcus