# Click-to-tune in Qt GUI Frequency SInk **URL:** \ **Category:** GNU Radio\ **Created:** [March 23, 2015, 3:27am UTC](https://www.ruby-forum.com/t/click-to-tune-in-qt-gui-frequency-sink/234692 "2015-03-23T03:27:53Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 23, 2015, 3:27am UTC](https://www.ruby-forum.com/t/click-to-tune-in-qt-gui-frequency-sink/234692/1 "2015-03-23T03:27:53Z")
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. ---
**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\ **Post date:** [March 23, 2015, 7:13am UTC](https://www.ruby-forum.com/t/click-to-tune-in-qt-gui-frequency-sink/234692/2 "2015-03-23T07:13:36Z")
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 ---
**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\ **Post date:** [March 23, 2015, 3:14pm UTC](https://www.ruby-forum.com/t/click-to-tune-in-qt-gui-frequency-sink/234692/3 "2015-03-23T15:14:46Z")
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 > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) [1] Links: ---
**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\ **Post date:** [March 23, 2015, 3:30pm UTC](https://www.ruby-forum.com/t/click-to-tune-in-qt-gui-frequency-sink/234692/4 "2015-03-23T15:30:21Z")
On Mon, Mar 23, 2015 at 7:12 AM, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 > **[GNU Radio Manual and C++ API Reference: gr::qtgui::freq\_sink\_c Class Reference](https://www.gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1freq __sink__ c.html)** See the Detailed Description section. Tom ---
**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\ **Post date:** [March 23, 2015, 3:46pm UTC](https://www.ruby-forum.com/t/click-to-tune-in-qt-gui-frequency-sink/234692/5 "2015-03-23T15:46:46Z")
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. > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) [1] * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) [1] Links: