-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
during my experimenting I connected the qt freq display just directly to
an audio source. sample_rate is set to 44.1k, center freq to 22.05k.
I absolutely did not see what I expected to see, so I connected the
display to a signal source, sending a 1k sinus tone.
Instead of seeing one spike pretty much left on the display, I saw a
spike in the center.
Next I took a 2nd signal source at 5k, put both sources through an add
operator into the display and instead of 2 spikes, there still was only
one spike in the center.
What do I miss here?
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk276YgACgkQbQKZlCdPOMNuKQCgrYd81zx4Om2mLypmuJ62kpRv
JIMAn0tqaWoSIfgat7ZonR4YeUu6A3tT
=07/9
-----END PGP SIGNATURE-----
Next I took a 2nd signal source at 5k, put both sources through an add
operator into the display and instead of 2 spikes, there still was only
one spike in the center.
What do I miss here?
-S
In situations like this, it’s usually helpful to the assembled multitude
here to post
your .grc file, to help in diagnosis, or, post a screen-shot of your
GRC flow-graph
at least. Just makes it easier for people to spot the obvious errors.
Cheers
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
22050Hz.
In a spectrum display I would expect a spike, well, at 1khz, i.e. pretty
much left in the display. With 2 signal sources (at 1 and 5KHz), I would
expect 2 spikes.
Maybe I didn’t get the concept of the qt frequency display right…
Is it a plain stupid spectrum display or does it do some processing on
it’s own? It also doesn’t really seem to matter what I set as bandwidth
and center frequency. Are those parameters only for the axis labels?
The bandwidth is used to determine both the axis labels, and the correct
decimation parameters
to use to produce the desired display rate. The center frequency is
purely used set axis labels.
I’d still recommend posting your .GRC file here.
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/30/2011 05:07 PM, Marcus D. Leech wrote:
In situations like this, it’s usually helpful to the assembled multitude
here to post
your .grc file, to help in diagnosis, or, post a screen-shot of your
GRC flow-graph
at least. Just makes it easier for people to spot the obvious errors.
Well, as I said - I did nothing else but connect a signal source
(cosine, 1kHz) to the qt sink. Sample rate 44.1kHz, center frequency
22050Hz.
In a spectrum display I would expect a spike, well, at 1khz, i.e. pretty
much left in the display. With 2 signal sources (at 1 and 5KHz), I would
expect 2 spikes.
Maybe I didn’t get the concept of the qt frequency display right…
Is it a plain stupid spectrum display or does it do some processing on
it’s own? It also doesn’t really seem to matter what I set as bandwidth
and center frequency. Are those parameters only for the axis labels?
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk28HNUACgkQbQKZlCdPOMN4NACgnhWY+ioIVdMzrfPHb+F90afX
H5EAoJXzAbK9oke6vl2GQ5GF/uSmekmo
=/Qp2
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/30/2011 05:38 PM, Marcus D. Leech wrote:
The bandwidth is used to determine both the axis labels, and the correct
decimation parameters
to use to produce the desired display rate. The center frequency is
purely used set axis labels.
I’d still recommend posting your .GRC file here.
<?xml version='1.0' encoding='ASCII'?>
<flow_graph>
Sat Apr 30 17:25:44 2011
options
id
top_block
_enabled
True
title
author
description
window_size
1200,600
generate_options
qt_gui
category
Custom
run_options
prompt
run
True
realtime_scheduling
_coordinate
(10, 10)
_rotation
0
variable
id
samp_rate
_enabled
True
value
44100
_coordinate
(10, 170)
_rotation
0
gr_add_xx
id
gr_add_xx_0
_enabled
True
type
float
num_inputs
2
vlen
1
_coordinate
(579, 223)
_rotation
0
gr_throttle
id
gr_throttle_0
_enabled
True
type
float
samples_per_second
samp_rate
vlen
1
_coordinate
(716, 235)
_rotation
0
qtgui_sink_x
id
qtgui_sink_x_0
_enabled
True
type
float
name
QT GUI Plot
fftsize
1024
wintype
firdes.WIN_BLACKMAN_hARRIS
fc
22050
bw
44100
plotfreq
True
plotwaterfall
True
plottime
True
plotconst
False
gui_hint
:0,0,1,1
_coordinate
(913, 212)
_rotation
0
gr_sig_source_x
id
gr_sig_source_x_0
_enabled
True
type
float
samp_rate
samp_rate
waveform
gr.GR_SIN_WAVE
freq
1000
amp
1
offset
0
_coordinate
(364, 137)
_rotation
0
gr_sig_source_x
id
gr_sig_source_x_1
_enabled
True
type
float
samp_rate
samp_rate
waveform
gr.GR_SIN_WAVE
freq
5000
amp
1
offset
0
_coordinate
(361, 282)
_rotation
0
<source_block_id>gr_sig_source_x_0</source_block_id>
<sink_block_id>gr_add_xx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
<source_block_id>gr_sig_source_x_1</source_block_id>
<sink_block_id>gr_add_xx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>1</sink_key>
<source_block_id>gr_add_xx_0</source_block_id>
<sink_block_id>gr_throttle_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
<source_block_id>gr_throttle_0</source_block_id>
<sink_block_id>qtgui_sink_x_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</flow_graph>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk28IRIACgkQbQKZlCdPOMNCBwCfc2++pWqm7HUm80Hxkk1QL11m
e7MAn34aLlXuqbiJk+RD6p/BdjjTiQWH
=HRuz
-----END PGP SIGNATURE-----
So the spectrum looks correct. To get the x-axis to display a center
frequency of 22050, you need to check the box “display RF frequencies”.
I think that “display RF frequencies” should be the default behavior,
but I will leave that decision to Tom.
-Josh
On 04/30/2011 07:47 AM, Stefan Gofferje wrote:
Sat Apr 30 17:25:44 2011
Custom
realtime_scheduling
1
type
firdes.WIN_BLACKMAN_hARRIS
plotfreq
samp_rate
amp
1
_rotation
<source_block_id>gr_sig_source_x_1</source_block_id>
<source_block_id>gr_throttle_0</source_block_id>
<sink_block_id>qtgui_sink_x_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</flow_graph>
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/02/2011 01:04 PM, Tom R. wrote:
I ran an audio_source -> qtgui_sink and it looked fine to me. I also
took your grc xml here and ran that and saw the four spikes as expected.
The setting of the center frequency is only to set the axis labels, it
won’t do any translating of the signal or anything. Remember in this
case and with your audio source one, the signal is real, so you will
only have spectral components from -22.05 to 22.05 kHz and the spectrum
will be symmetric around 0 Hz. So “translating” this up to 22.05 kHz
won’t really do anything for you since you have no information over
22.05 kHz, anyways.
I had some off-list conversation with Marcus and I think, I’m getting a
hang of this complex vs. real stuff. Higher math is some 20 years ago
for me :).
However, I wonder, what’s the sense of treating real streams like
complex, and mirroring them.
In the project I have in mind with GNURadio, there would be a
requirement for a spectrum / waterfall display of the NF signal to look
for anything out of the ordinary, especially signals that would be
unhearable on normal receivers because the NF stage would filter them
out. It goes into the direction signal analysis/SIGINT.
Would it make sense, if the display is set to float, to actually show 0
-
- $BANDWIDTH? I got the WX-stuff running (= it doesn’t segfault but it
eats 100% CPU, so it doesn’t react to anything) and the WX-FFT display
does show 0 - $BANDWIDTH/2.
That’s just a suggestion, of course. I’m just imagining that there might
be a few others out there which are also used to analog NF spectrum
displays which show 0 - $BANDWIDTH :).
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk2+iCIACgkQbQKZlCdPOMORygCgrHQ0FwvHhTDopY10dg7U+KQ0
ME8AnjtFs0/h85rw2x49E3HRRLdGyHlr
=IVlG
-----END PGP SIGNATURE-----
On Sat, Apr 30, 2011 at 3:47 PM, Stefan Gofferje
[email protected]wrote:
I ran an audio_source → qtgui_sink and it looked fine to me. I also
took
your grc xml here and ran that and saw the four spikes as expected.
The setting of the center frequency is only to set the axis labels, it
won’t
do any translating of the signal or anything. Remember in this case and
with
your audio source one, the signal is real, so you will only have
spectral
components from -22.05 to 22.05 kHz and the spectrum will be symmetric
around 0 Hz. So “translating” this up to 22.05 kHz won’t really do
anything
for you since you have no information over 22.05 kHz, anyways.
Tom
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/02/2011 01:45 PM, Tom R. wrote:
This might fall into more of a religious/philosophical argument than a
technical one. To me, seeing the negative frequency is very natural,
even if it’s just a mirror. I honestly don’t know if I’m in the majority
or minority on this one, or if it’s a function of how I was taught and
my professors’ ways that have stuck with me. So the way the QT sink
works “feels” more correct to me.
Maybe it’s mathematician/scientist vs. tech guy point of view :). Or HF
vs. NF guy…
I know both views from hardware spectrum displays from the different
worlds. The HF displays I know show baseband +/- $BANDWIDTH/2 and the NF
displays 0 - $BANDWIDTH. I would suppose, the average audio tech guy
would be as confused by the baseband +/- $BANDWIDTH/2 display as I was
:). I am aware that the focus of the GNURadio project is on the HF side
but maybe taking the NF guys into consideration wouldn’t harm :).
Talking practically, the mirrored display is less an issue than “losing”
half of the bandwidth in the display, which might contain interesting
data.
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk2+j7cACgkQbQKZlCdPOMNIKACeJTwYu/rHwnHHfckUUqBfLfnu
O+MAnijQdTbBCsBoZzmrP07UGWQjbi+x
=5IPI
-----END PGP SIGNATURE-----
On Mon, May 2, 2011 at 11:32 AM, Stefan Gofferje
[email protected]wrote:
only have spectral components from -22.05 to 22.05 kHz and the spectrum
In the project I have in mind with GNURadio, there would be a
That’s just a suggestion, of course. I’m just imagining that there might
be a few others out there which are also used to analog NF spectrum
displays which show 0 - $BANDWIDTH :).
Stephen,
This might fall into more of a religious/philosophical argument than a
technical one. To me, seeing the negative frequency is very natural,
even if
it’s just a mirror. I honestly don’t know if I’m in the majority or
minority
on this one, or if it’s a function of how I was taught and my
professors’
ways that have stuck with me. So the way the QT sink works “feels” more
correct to me.
Tom
On Sat, Apr 30, 2011 at 8:40 PM, Josh B. [email protected] wrote:
So the spectrum looks correct. To get the x-axis to display a center
frequency of 22050, you need to check the box “display RF frequencies”.
I think that “display RF frequencies” should be the default behavior,
but I will leave that decision to Tom.
-Josh
It’s the way it is because it’s the way that it’s always been. But as
I’m
splitting out the various graphs to become their own stand-alone
elements
and will eventually allow you to create a GUI figure that doesn’t have
the
box of “stuff” around it, you won’t necessarily see the “display RF
frequencies” check box. In that case, I think you’re right that it makes
more sense to default to what the user told it the center frequency is.
Tom
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/02/2011 03:58 PM, Tom R. wrote:
It’s the way it is because it’s the way that it’s always been. But as
I’m splitting out the various graphs to become their own stand-alone
elements and will eventually allow you to create a GUI figure that
doesn’t have the box of “stuff” around it, you won’t necessarily see the
“display RF frequencies” check box. In that case, I think you’re right
that it makes more sense to default to what the user told it the center
frequency is.
How about making it a parameter? The user can set it as needed then and
if desired create a QT radiobutton to change it in-app.
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk2+rE4ACgkQbQKZlCdPOMMWoQCfbU20t+j/AWaV+c1MoQIrU+Qx
uNsAniGQTwph5n7fTQ19rsLDdqB2EbSL
=2Dq7
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/02/2011 04:12 PM, Tom R. wrote:
It is a parameter, or at least settable by sending the right signal
through the QT API. My plan is to expose everything that we might want
to adjust as a slot as well as a function in the GR block for these
sinks. That gives us multiple ways to set and read these things. Setting
this would be one of those functions/slots. I don’t think that I would
add it as an actual argument to the constructor, though; it doesn’t
really seem important enough for that. As these GUIs are improved, I
think I will make the RF frequencies the default behavior and you can
always call the “display_rf_freqs(False)” (or whatever) from the object
you’ve created.
I was more thinking in GRC categories. You know, make display_rf_freqs a
parameter like sample rate or center frequency of the block which can be
changed by another block which is a Qt radiobutton.
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk2+tqEACgkQbQKZlCdPOMOs2ACfTaeuUNeauyuC6eDRcqBiQ5zj
PdIAnRLYbQJvvxyJombmXE0oJ4jQx3Op
=kbPD
-----END PGP SIGNATURE-----
On Mon, May 2, 2011 at 2:06 PM, Stefan Gofferje
[email protected]wrote:
frequency is.
How about making it a parameter? The user can set it as needed then and
if desired create a QT radiobutton to change it in-app.
It is a parameter, or at least settable by sending the right signal
through
the QT API. My plan is to expose everything that we might want to adjust
as
a slot as well as a function in the GR block for these sinks. That gives
us
multiple ways to set and read these things. Setting this would be one of
those functions/slots. I don’t think that I would add it as an actual
argument to the constructor, though; it doesn’t really seem important
enough
for that. As these GUIs are improved, I think I will make the RF
frequencies
the default behavior and you can always call the
“display_rf_freqs(False)”
(or whatever) from the object you’ve created.
Tom
On 02/05/2011 9:50 AM, Stefan Gofferje wrote:
I was more thinking in GRC categories. You know, make display_rf_freqs a
parameter like sample rate or center frequency of the block which can be
changed by another block which is a Qt radiobutton.
I think what Tom is indicating is that all of the parameters that could
reasonably be set at runtime will be manifested as
methods on the basic objects offered in the Qt GUI stuff.
Once you have that, then the GRC objects can manifest many/all of them
when you create the object from the “palette”. GRC uses XML descriptor
objects to describe underlying Gnu Radio objects, and those XML
descriptors define which underlying Python object methods are called
when you
change a parameter like “frequency” or “display RF frequency” or
“change my underwear”.
I think all of this will come out as a result of the significant
re-structuring of the existing Qt GUI object into distinct objects,
instead of
the “megaobject” that is currently implemented.
On 02/05/2011 9:54 AM, Tom R. wrote:
I’ll answer on Josh’ behalf, since he’s probably not awake yet, over
there on the left coast 
Yes, a lot of the runtime-changeable parameters in GRC are actually
implemented as calls to object methods, not just constructor functions.
Check out the XML sometime to get a feel for how this works. The XML
files for GRC objects basically describe the properties of parameters,
and
which methods to call to change those parameters. Which is how
things like “frequency” on a UHD source block get changed at runtime.
On Mon, May 2, 2011 at 9:50 AM, Stefan Gofferje
[email protected]wrote:
really seem important enough for that. As these GUIs are improved, I
think I will make the RF frequencies the default behavior and you can
always call the “display_rf_freqs(False)” (or whatever) from the object
you’ve created.
I was more thinking in GRC categories. You know, make display_rf_freqs a
parameter like sample rate or center frequency of the block which can be
changed by another block which is a Qt radiobutton.
Ok, that makes sense. It seems pretty easy, too, although I’m not sure
it’s
possible.
Josh, can you have a parameter setting in a GRC block that is no a
constructor argument? Instead, it’s an accessor function that gets
called to
set a value after the block is instantiated?
Tom
On Mon, May 2, 2011 at 10:06 AM, Marcus D. Leech [email protected]
wrote:
like “frequency” on a UHD source block get changed at runtime.
Duh, yes of course that’s how frequency an gain of the UHD blocks are
done.
I’ve made many GRC blocks, but always just the most straight-forward
translation of the object constructor and some callbacks.
Thanks for point that out, Marcus. So yes, Stefan, it’ll be easy to make
a
nicely parameterized GRC block with various settable values and
reasonable
defaults.
Tom
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/02/2011 05:20 PM, Tom R. wrote:
So yes, Stefan, it’ll be easy to make
a nicely parameterized GRC block with various settable values and
reasonable defaults.
Ain’t that nice. If at some point in the far future the spectrum /
waterfall display shows real values only in the positive half, you’d
make an old man very happy :D.
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAk2+/6cACgkQbQKZlCdPOMMxWgCbBLkkWZqWDnOk/ziH2a/q+FWd
NaUAnAsc2G8Ndk1zy/5aXY1xGeCvtFed
=oGhz
-----END PGP SIGNATURE-----