Forum: GNU Radio low frequency in GRC

5fd1e4f6f03488a54ea5b31a1ef94886?d=identicon&s=25 jason sam (Guest)
on 2014-05-15 11:07
(Received via mailing list)
I am using GNU Radio Companion 3.7.3...when i set the frequency of my
signal source to low values(in Hz or kHz),i get no signal on my scope or
fft sink??
503e7c2961c7debe24eda2c31330759b?d=identicon&s=25 Mike Jameson (Guest)
on 2014-05-15 12:46
(Received via mailing list)
If you attach your GRC flowgraph I'll take a look at it for you.

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: support@ettus.com
Web: http://ettus.com
D2595f4322a69535ddb92617d17f0eef?d=identicon&s=25 Louis Brown (madengr)
on 2014-05-15 19:54
(Received via mailing list)
Regarding the low sample rate, I have had this issue too when decimating
to
narrow bandwidths.  I assume sample rate is an integer for most blocks
therefore one can't go below 1 samp/sec?

Lou
KD4HSO




--
View this message in context:
http://gnuradio.4.n7.nabble.com/low-frequency-in-G...
Sent from the GnuRadio mailing list archive at Nabble.com.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus Leech (Guest)
on 2014-05-16 13:06
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-05-17 08:39
(Received via mailing list)
On Fri, May 16, 2014 at 2:01 AM, Marcus Leech <mleech@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.
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2014-05-17 15:55
(Received via mailing list)
On Sat, May 17, 2014 at 2:38 AM, Activecat <activecat@gmail.com> wrote:

>
>
> 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
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-05-18 03:04
(Received via mailing list)
Attachment: FM.jpg (50 KB)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-05-18 03:53
(Received via mailing list)
On Sat, May 17, 2014 at 9:53 PM, Tom Rondeau <tom@trondeau.com> wrote:

> 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
>

Thanks for the explanation.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.