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:
flowgraph
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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
