Hi,
I’m trying to figure out the best way to print the decoded data
information
of packets (received through gnuradio) to the user. File outputs are not
really user friendly so I’m thinking of using a message queue out of my
decoding block connected to the WX GUI Terminal Sink.
Is this a good approach? I’m thinking it might not since I can’t find
any
design using the terminal sink on the net.
If this is the right path could someone point me to an easy example of
using the message queue. I’d like to do a quick proof of concept and
output
something like “hello world” on the terminal sink.
Thanks
On 04/15/2014 06:14 AM, Francois Gervais wrote:
I’m trying to figure out the best way to print the decoded data
information of packets (received through gnuradio) to the user. File
outputs are not really user friendly so I’m thinking of using a message
queue out of my decoding block connected to the WX GUI Terminal Sink.
Generally: Don’t use a message queue. Also, I recommend not adding any
WX widgets, unless you hate QT, because we’re trying to move away from
them.
The message passing interface might be a better choice, but the idea in
general is very good.
Is this a good approach? I’m thinking it might not since I can’t find
any design using the terminal sink on the net.
If this is the right path could someone point me to an easy example of
using the message queue. I’d like to do a quick proof of concept and
output something like “hello world” on the terminal sink.
Have a look at the message_debug code. It does most of what you want,
but not in a widget, just on the console.
Martin
hi ,Martin B.
well ,in my impression, the unit of is noisy is dB,so i feel fuzzy about
the volt,
thanks for your reply!
------------------ Original ------------------
From: “Martin B.”;[email protected];
Date: Tue, Apr 15, 2014 04:35 PM
To: "discuss-gnuradio"[email protected];
Subject: Re: [Discuss-gnuradio] Best way to output decoded data to user
On 04/15/2014 06:14 AM, Francois Gervais wrote:
I’m trying to figure out the best way to print the decoded data
information of packets (received through gnuradio) to the user. File
outputs are not really user friendly so I’m thinking of using a message
queue out of my decoding block connected to the WX GUI Terminal Sink.
Generally: Don’t use a message queue. Also, I recommend not adding any
WX widgets, unless you hate QT, because we’re trying to move away from
them.
The message passing interface might be a better choice, but the idea in
general is very good.
Is this a good approach? I’m thinking it might not since I can’t find
any design using the terminal sink on the net.
If this is the right path could someone point me to an easy example of
using the message queue. I’d like to do a quick proof of concept and
output something like “hello world” on the terminal sink.
Have a look at the message_debug code. It does most of what you want,
but not in a widget, just on the console.
Martin
Ah so message queue and message passing interface are two different
things
in gnuradio? Might be why I was confused. So what I want to look at is
this
page right?
http://gnuradio.org/doc/doxygen/page_msg_passing.html
Got it I’ll for the WX widgets, I’ll stop using them. Is there an
official
QT terminal block?
I’ll take a look at pyqt but I’d prefer using official blocks if
possible.
check out gr-pyqt - this might be roughly what you are looking for
I’ve added some very simple python blocks which can send and receiver
pdus with strings stored in pmt u8vectors and can be easily dropped into
a Qt Gui for user interaction
https://github.com/osh/gr-pyqt/commit/7b12b79bc029d483ce71878960b24871ddbfd954
-Tim
On Tue, Apr 15, 2014 at 12:03 PM, Martin B.
[email protected]wrote:
Not yet 
If you want to get your hands dirty, that would be nice…
Martin
Someone actually uses the terminal block? That one in WX has always felt
completely broken to me and I had no interest in duplicating it in QT.
But
hey, if it’s being used, it’s something we would like to have.
Tom
Well I’m thinking if I’m about to print text to user it’s better if it’s
part of the GUI than having some of the information on the GUI and some
on
the underneath console. That way it looks more like a self contained app
to
me.
On 04/15/2014 03:55 PM, Francois Gervais wrote:
Ah so message queue and message passing interface are two different
things in gnuradio? Might be why I was confused. So what I want to look
at is this page right?
http://gnuradio.org/doc/doxygen/page_msg_passing.html
Right.
Got it I’ll for the WX widgets, I’ll stop using them. Is there an
official QT terminal block?
Not yet If you want to get your hands dirty, that would be nice…
Martin
On 04/15/2014 06:18 PM, Francois Gervais wrote:
Well I’m thinking if I’m about to print text to user it’s better if it’s
part of the GUI than having some of the information on the GUI and some
on the underneath console. That way it looks more like a self contained
app to me.
And you’re right. But maybe a ‘terminal’ sink isn’t what we want, but
rather a graphical tag/message debug/dump block?
Martin
On Tue, Apr 15, 2014 at 12:21 PM, Martin B.
[email protected]wrote:
On 04/15/2014 06:18 PM, Francois Gervais wrote:
Well I’m thinking if I’m about to print text to user it’s better if it’s
part of the GUI than having some of the information on the GUI and some
on the underneath console. That way it looks more like a self contained
app to me.
And you’re right. But maybe a ‘terminal’ sink isn’t what we want, but
rather a graphical tag/message debug/dump block?
Martin
Yeah, that sounds better to me. Or just a multi-line text box as a gui
widget. It shouldn’t be difficult for someone to take the QT Number Sink
block and convert that to a multiline text output (and remote the
QwtThermo
widget). Have the number of lines be a constructor parameter and be able
to
resize it at runtime.
Tom
In this scenario would the message passing interface be the best input
type?
Martin B.-2 wrote
Generally: Don’t use a message queue. Also, I recommend not adding any
WX widgets, unless you hate QT, because we’re trying to move away from
them.
The message passing interface might be a better choice, but the idea in
general is very good.
Martin
Is there a reason not to use the message queue; maybe it is being
deprecated? I’m experimenting with it now to pass FFT vectors out of
the
flow into my python script to search for a frequency and tune
demodulator,
and I can poll the queue every 10ms with no issues. Should I be using
another method? I don’t want to write a block just yet.
Thanks,
Lou
KD4HSO
–
View this message in context:
http://gnuradio.4.n7.nabble.com/Best-way-to-output-decoded-data-to-user-tp47578p47611.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On github
https://github.com/dl1ksv/gr-display
there is an qt based simple oot module gr-display that can be used to
display character streams either in an text window or as png picture.
I use this to display ax.25 packets images from weather satellites.
– Volker
Am 15.04.2014 23:36, schrieb madengr:
On 04/15/2014 07:41 PM, Francois Gervais wrote:
In this scenario would the message passing interface be the best input type?
If I could choose, I would give an optional stream input, and search for
tags (print those), as well as a message port.
Martin