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??
If you attach your GRC flowgraph I’ll take a look at it for you.
Mike
–
Mike J. M0MIK BSc MIET
Ettus R. Technical Support
Email: [email protected]
Web: http://ettus.com
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-GRC-tp48237p48266.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Fri, May 16, 2014 at 2:01 AM, Marcus L. [email protected] 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.
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Sat, May 17, 2014 at 9:53 PM, Tom R. [email protected] 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.
On Sat, May 17, 2014 at 2:38 AM, Activecat [email protected] 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