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 Rondeau wrote: > On Mon, Mar 23, 2015 at 7:12 AM, <[email protected]> wrote: > >> 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.... > > 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 [2] > > See the Detailed Description section. > > Tom > > On 2015-03-23 02:12, Martin Braun wrote: > > On 22.03.2015 19:26, Marcus D. Leech wrote: > 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. > > 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 > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: ------ [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2] http://gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1freq__sink__c.html
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
