On Sat, May 17, 2014 at 2:38 AM, Activecat <active...@gmail.com> wrote:
> On Fri, May 16, 2014 at 2:01 AM, Marcus Leech <mle...@ripnet.com> wrote: > >> Gnu Radio is a streaming architecture. Sample-rate is actually >> almost-entirely meaningless within the flowgraph, and only really >> has meaning "at the edges" when interfacing to the real world. The >> only exception is the throttle block, and even it doesn't >> produce *precise* sample-rates. >> > > A too-low value of sample-rate (samp_rate) could be hazardous. > > For example, in Jason's flowgraph attached in his previous email, the > settings of the Signal Source block are: > - Sample Rate = 100 > - Frequency = 50 > - Signal Type = Saw Tooth > In this case the output from this block is just a repeating of two float > numbers:- 0.5, 0.0, 0.5, 0.0, 0.5, 0.0, 0.5, 0.0, 0.5, .... > > If the Sample Rate is reduced to 50, then the output becomes a constant > value:- 0.5, 0.5, 0.5, 0.5, ... (this is worse). > > If "Saw Tooth" is the signal pattern that he really wants out from this > Signal Source block, then he needs to set the sample-rate to a high-enough > value, for example, samp_rate=1000. With this value the Signal Source block > will produce output which looks more like Saw Tooth:- > > 0.50, 0.55, 0.60, 0.65, 0.70, 0.75, 0.80, 0.85, 0.90, 0.95, > 0.00, 0.05, 0.10, 0.15, 0.20, 0.25, 0.30, 0.35, 0.40, 0.45, > 0.50, 0.55, 0.60, 0.65, 0.70, 0.75, 0.80, 0.85, 0.90, 0.95, > 0.00, 0.05, 0.10, 0.15, ................. > > Hence, the value of samp_rate does make a significance in the flowgraph. > So, yes and no on that. There's the information theoretic concept of sample rate, which is what you are talking about here. But underneath, we normalize all sample rates relative to 1. So it's the number of samples relative to that which matters. We provide the concept of "sample rate" in the signal generator block only to make it easy to use real values of Hz or cycles/second here. But the frequency you're talking about gets divided by the sample rate before anything else happens. So it's a convenience of representation. Then there's the time-based concept of sample rate, which doesn't matter to a GPP but matters a great deal to physical hardware like your sound card or radio front end. That sample rate has a real physical meaning, and we have to acknowledge this when connecting multiple pieces of hardware together. Basically, we look at rate matching. But the computer or GNU Radio itself doesn't really know anything about 1 us per sample. This is, I think, on of the more complicated concepts to get about software radio. Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
