Just looking at the async message interface for Qt GUI Frequency Sink.
The “freq” output (is that a PMT?) is always, it appears, in terms of
“display” frequency. Which is cool if you’re using the click-to-tune
output to modify (for example) a hardware source, but if you’re using it
to tune (for example) a freq-xlating FIR filter, there’s a
disagreement on semantics.
One could run the Frequency Sink in relative mode in this case. But it
seems like there should be more flexibility in dealing with the contents
of async messages, in situations where the message tag (“freq” in
this case) could have semantics that not everyone who takes such
a tag might agree on.
It should, I think, also be possible to turn such tags into variable
settings in GRC, but I couldn’t find any way to do so.
On 22.03.2015 19:26, Marcus D. Leech wrote:
this case) could have semantics that not everyone who takes such
a tag might agree on.
There’ve been long discussions on this subject, at least one of them at
a dev call. In general, the message format is of the (index, value)
format. For the case of the xlating FIR, all you need to do is change
your x-axis to make the center freq 0, and you’re good. Getting tags and
PMTs right is still a learning process for all of us, but we didn’t want
to add loads of extra settings into the QT sink just so we could get the
tags into any format we liked.
It should, I think, also be possible to turn such tags into variable
settings in GRC, but I couldn’t find any way to do so.
Hmmmm… maybe some block that would work with with the probes could do
that. Would have to be written, though.
M
Indeed, if one uses relative, rather than absolute frequencies in the Qt
Frequency sink, everything is wonderful.
But I think there are, as you observe, deeper questions about the
desired semantics of async messages of this type.
An advantage to the “sets a variable” implementation on the WX GUI side,
is that said variable can be manipulated and scaled as appropriate,
depending on who is consuming it.
It’s early days for the async-message subsystem within GR, and we are
learning as we’re going. No surprises…
On 2015-03-23 02:12, Martin B. wrote:
M
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page [1]
Links:
On Mon, Mar 23, 2015 at 7:12 AM, [email protected] wrote:
It’s early days for the async-message subsystem within GR, and we are
learning as we’re going. No surprises…
I also just want to point out that the format of the messages is
described
in the manual
http://gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1freq__sink__c.html
See the Detailed Description section.
Tom
Yup, I actually deduced that using a Message Debug block to figure out
what it emits.
But not a lot of blocks currently accept async messages for handling
run-time parameters. For example, gr-osmosdr only supports
“conventional” setters.
On 2015-03-23 10:28, Tom R. wrote:
I also just want to point out that the format of the messages is described in
the manual
Just looking at the async message interface for Qt GUI Frequency Sink. The
“freq” output (is that a PMT?) is always, it appears, in terms of “display”
frequency. Which is cool if you’re using the click-to-tune output to modify (for
example) a hardware source, but if you’re using it to tune (for example) a
freq-xlating FIR filter, there’s a disagreement on semantics. One could run the
Frequency Sink in relative mode in this case. But it seems like there should be
more flexibility in dealing with the contents of async messages, in situations
where the message tag (“freq” in this case) could have semantics that not everyone
who takes such a tag might agree on.
[email protected]
Discuss-gnuradio Info Page [1]
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page [1]
Links: