Most of the times, the transmission is stable, but there are 3 times bad things pop up. 'L' is shown for one time after running for some time. The following warning is shown twice.
UHD Warning:
x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
thread[thread-per-block[5]: <block gr uhd usrp sink (1)>]: RuntimeError:
x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
The X3xx is connected to the host using 1G Ethernet cable. The network card
is Intel Ethernet Converged Network Adapter X520-DA2. The card can support
10Gbps, but the sfp+ to rj45 adapter can supports only 1Gbps. The output of
lspci is shown below.
lspci
00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers
(rev 07)
00:01.0 PCI bridge: Intel Corporation Sky Lake PCIe Controller (x16) (rev
07)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI
Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H
Thermal subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME
HECI #1 (rev 31)
00:16.3 Serial controller: Intel Corporation Sunrise Point-H KT Redirection
(rev 31)
00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode]
(rev 31)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port
#9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev
31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
I219-LM (rev 31)
01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
Network Connection (rev 01)
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Oland XT [Radeon HD 8670 / R7 250/350] (rev 83)
02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]
Rui
On Wed, Aug 2, 2017 at 1:17 PM, Marcus Müller <muel...@kit.edu> wrote:
> I'd consider that good news, because that definitely means that your PC is
> up to the task of supplying samples fast enough :)
>
> Still, we're getting "L"s. So let's reduce the test case: Same USRP Sink
> as you use here, but with a Null Source directly feeding it. Is that stable?
>
> While we're at it: can you describe how the X3xx is connected? Can you
> maybe even share info on the network card you're using (lspci might help)?
>
> Best regards,
>
> Marcus
>
> On 08/02/2017 06:01 PM, Rui ZOU wrote:
>
> Sorry for the confusion, because I thought whenever a hardware is not used
> throttle block must be used.
>
> This time, no USRP, no throttle block, the rate is 11.6MS/s. The python
> test takes several top CPU consumption PIDs as shown by the htop screen
> capture.
>
> ******* MESSAGE DEBUG PRINT ********
> (((rate_now . 1.14922e+07) (rate_avg . 1.16197e+07)))
> ************************************
>
>
> On Wed, Aug 2, 2017 at 11:45 AM, Marcus Müller <muel...@kit.edu> wrote:
>
>> I'm really confused at this point. In no point in your testing should be
>> Throttle involved. So, please, can you do a test with:
>>
>> Null Source
>> Probe Rate -> Message Debug
>> No UHD USRP Sink
>> No Throttle
>>
>> and tell me a) how fast you were and b) how much CPU you used ?
>> Thanks!
>>
>> Marcus
>>
>> On 08/02/2017 05:18 PM, Rui ZOU wrote:
>>
>> The screen capture of htop when running the python script, test.py, is
>> attached.
>>
>> On Wed, Aug 2, 2017 at 11:10 AM, Rui ZOU <zourui.mkithap...@gmail.com>
>> wrote:
>>
>>> Throttle block is NEVER in use when USRP Sink is used.
>>>
>>> On Wed, Aug 2, 2017 at 11:08 AM, Rui ZOU <zourui.mkithap...@gmail.com>
>>> wrote:
>>>
>>>> USRP sink
>>>>
>>>> On Wed, Aug 2, 2017 at 11:08 AM, Rui ZOU <zourui.mkithap...@gmail.com>
>>>> wrote:
>>>>
>>>>> My previous email shows the rate WITHOUT
>>>>>
>>>>> On Wed, Aug 2, 2017 at 11:05 AM, Marcus Müller <muel...@kit.edu>
>>>>> wrote:
>>>>>
>>>>>> WAIT! Throttle? I didn't see that in either of the flow graphs you
>>>>>> sent me first (twoparatx, onefile2tx)
>>>>>>
>>>>>> Seriously?! Your GRC will even print a warning that you mustn't use
>>>>>> Throttle together with hardware if you have both Throttle and a USRP
>>>>>> sink.
>>>>>>
>>>>>> Remove the Throttle, and try again.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/02/2017 05:00 PM, Rui ZOU wrote:
>>>>>>
>>>>>> Changed to null source, the rate is still around twice the sample
>>>>>> rate (390.625k) for throttle block.
>>>>>>
>>>>>> ******* MESSAGE DEBUG PRINT ********
>>>>>> (((rate_now . 781360) (rate_avg . 786529)))
>>>>>> ************************************
>>>>>>
>>>>>> When the throttle block is bypassed, the rate jumps up to around
>>>>>> 11.3MS/s.
>>>>>>
>>>>>> ******* MESSAGE DEBUG PRINT ********
>>>>>> (((rate_now . 1.16071e+07) (rate_avg . 1.12848e+07)))
>>>>>> ************************************
>>>>>>
>>>>>> The rate is similar to using file source, 0.78MS/s with throttle and
>>>>>> 11.3MS/s when throttle bypassed.
>>>>>>
>>>>>> Rui
>>>>>>
>>>>>> On Wed, Aug 2, 2017 at 10:37 AM, Marcus Müller <muel...@kit.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok, there's something fishy here. That rate (without the USRP Sink)
>>>>>>> is ridiculously low. Can you replace the file_source with a null_source?
>>>>>>> That way, we can rule out storage as the bottleneck.
>>>>>>>
>>>>>>> The probe_rate does nothing but just count how many items fly by,
>>>>>>> and then send a message at its output port every update period. The
>>>>>>> message_debug just prints messages.
>>>>>>>
>>>>>>> If it's not storage: are you perhaps running in a powersaver mode?
>>>>>>> Even so, the rate would be too low. I really don't know what's going
>>>>>>> wrong
>>>>>>> here. Run your flow graph, run "top" in a terminal, check that the
>>>>>>> python
>>>>>>> process and its spawned child threads really consume most of the CPU. If
>>>>>>> that's not the case, you've got something else eating away on your CPU.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Marcus
>>>>>>>
>>>>>>> On 08/02/2017 04:22 PM, Rui ZOU wrote:
>>>>>>>
>>>>>>> Not sure if the debug setup is the expected since it's the first
>>>>>>> time I use the 'Probe Rate' and 'Message Debug' blocks whose functions
>>>>>>> are
>>>>>>> not very clear to me now just after reading the contents under the
>>>>>>> document
>>>>>>> tag. If there are other ways to learn about new blocks, please advise.
>>>>>>>
>>>>>>> The rates I get when the USRP Sink disabled is around 0.78MS/s I
>>>>>>> guess from the debug output, shown below.
>>>>>>>
>>>>>>> ******* MESSAGE DEBUG PRINT ********
>>>>>>> (((rate_now . 782916) (rate_avg . 784937)))
>>>>>>> ************************************
>>>>>>>
>>>>>>> After enabling the USRP Sink, I got lots of 'L's and 2.4MS/s, shown
>>>>>>> below.
>>>>>>>
>>>>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>>>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>>>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>>>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>>>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>>>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>>>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL*******
>>>>>>> MESSAGE DEBUG PRINT ********
>>>>>>> (((rate_now . 2.36319e+06) (rate_avg . 2.36319e+06)))
>>>>>>> ************************************
>>>>>>>
>>>>>>> GRC and python files are attached.
>>>>>>>
>>>>>>> Rui
>>>>>>>
>>>>>>> On Wed, Aug 2, 2017 at 3:57 AM, Marcus Müller <muel...@kit.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Huh, I really don't know what's happening there :/ I sadly don't
>>>>>>>> have the USRP to test this live with me right now, but there's
>>>>>>>> absolutely
>>>>>>>> no timed commands involved¹
>>>>>>>>
>>>>>>>> So, trying to weed out bugs:
>>>>>>>>
>>>>>>>> * I've replaced the USRP sink with a "Probe Rate" block, connected
>>>>>>>> to a "Message Debug"'s print port. I saw samples fly by with more than
>>>>>>>> 7
>>>>>>>> MS/s, so there really shouldn't be a bottleneck here – can you try to
>>>>>>>> do
>>>>>>>> the same and see whether your system can get similar rates? 7MS/s is
>>>>>>>> still
>>>>>>>> far too little for my taste, but that is FM-Modulation-limited²
>>>>>>>> * Can you delete your subdev spec? in a 2-channel case, that should
>>>>>>>> be the implicit one, anyways.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>> ¹ "timed commands" are a USRP feature that allows certain things to
>>>>>>>> happen at well-defined times. You get an L when a timed command
>>>>>>>> reaches the
>>>>>>>> USRP after the specified time has already passed. In your flow graph,
>>>>>>>> all
>>>>>>>> that could happen is that a sample packet reaches the USRP after it
>>>>>>>> should
>>>>>>>> – but that's unlikely, you'd get a "U" instead.
>>>>>>>>
>>>>>>>> ² at least on my machine, most of the time is spent in the FM
>>>>>>>> modulator. Which is kind of annoying, because looking into that, what
>>>>>>>> costs
>>>>>>>> most time is the "keeping the phase within 0;2pi" floating point modulo
>>>>>>>> operation. I might get the urge to fix that.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/01/2017 08:31 PM, Rui ZOU wrote:
>>>>>>>>
>>>>>>>> Hi Marcus,
>>>>>>>>
>>>>>>>> I have fixed the two parallel SISO by removing packeting encoding,
>>>>>>>> using QT GUI instead of WX. But the 'L' indicator still comes on, even
>>>>>>>> sooner than previous version. The GRC and generated python files are
>>>>>>>> attached.
>>>>>>>>
>>>>>>>> Rui
>>>>>>>>
>>>>>>>> On Tue, Aug 1, 2017 at 12:04 PM, Marcus Müller <muel...@kit.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ah, cool, but then I wouldn't start by packetizing data.
>>>>>>>>>
>>>>>>>>> Simply send your file GMSK-Modulated; drop the packet encoding;
>>>>>>>>> think about it: the MIMO coding (usually) happens *after* the data
>>>>>>>>> has been
>>>>>>>>> formed to logical data units.
>>>>>>>>>
>>>>>>>>> A few notes on your flowgraphs: Don't use the WX GUI elements in
>>>>>>>>> new flowgraphs. We have deprecated them, since no-one can maintain
>>>>>>>>> them,
>>>>>>>>> and the Qt GUI sinks have shown to be both more stable and efficient.
>>>>>>>>> As
>>>>>>>>> far as I can foresee your application's needs, Qt has replacements
>>>>>>>>> for all
>>>>>>>>> the WX visualizations you'd need.
>>>>>>>>>
>>>>>>>>> For the receiver, I'd guess you'd first simply start by just
>>>>>>>>> recording from to channels, and then experimenting with things like
>>>>>>>>> cross-correlation, and estimating the channel matrix based on your
>>>>>>>>> known
>>>>>>>>> transmit signal. I wouldn't be surprised if the channel is rather
>>>>>>>>> boring in
>>>>>>>>> your setup – I blindly assume you're doing this indoors, and that
>>>>>>>>> limits
>>>>>>>>> the path difference and the amount of change (and hence, the delay
>>>>>>>>> spread
>>>>>>>>> and the doppler spread) your signals are subject to, especially since
>>>>>>>>> your
>>>>>>>>> bandwidth is so low. Of course, having a flat channel is nice :) but
>>>>>>>>> it
>>>>>>>>> also means that it might be quite hard to get any actual MIMO gain,
>>>>>>>>> because
>>>>>>>>> the two RX antennas might be very correlated. If in doubt, increase
>>>>>>>>> bandwidth. Be agressive with roll-off / Bandwidth factors of your
>>>>>>>>> GMSK.
>>>>>>>>> Cheers,
>>>>>>>>> Marcus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08/01/2017 05:51 PM, Rui ZOU wrote:
>>>>>>>>>
>>>>>>>>> Hi Marcus,
>>>>>>>>>
>>>>>>>>> My goal is to first build a 2-by-2 space multiplexing MIMO using
>>>>>>>>> two X310s and GNU Radio. As I'm new to all this stuff, I'm starting
>>>>>>>>> from
>>>>>>>>> building 2 parallel SISOs. If there are some good kick-start
>>>>>>>>> materials or
>>>>>>>>> any resources, they will be very valuable. Thanks.
>>>>>>>>>
>>>>>>>>> Rui
>>>>>>>>>
>>>>>>>>> On Tue, Aug 1, 2017 at 11:37 AM, Marcus Müller <muel...@kit.edu>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Rui,
>>>>>>>>>>
>>>>>>>>>> sorry, I might simply have missed those, and didn't find your
>>>>>>>>>> first email when I saw your recent one! I apologize.
>>>>>>>>>>
>>>>>>>>>> So, hm, interestingly, we have a severe bug in the packet_encoder
>>>>>>>>>> block (its design is pretty bad, and that triggers an unexpected
>>>>>>>>>> behaviour
>>>>>>>>>> underneath). That might mean the packet_encoder is just consuming
>>>>>>>>>> items as
>>>>>>>>>> fast as it can, without actually producing packets. In other words,
>>>>>>>>>> packet_encoder is broken; you can't use it right now.
>>>>>>>>>>
>>>>>>>>>> The more appropriate way of dealing with data might be in the
>>>>>>>>>> example flowgraphs that you'd find under
>>>>>>>>>> /usr/[local/]share/doc/gnuradi
>>>>>>>>>> o/examples/digital/packet_loopback_hier.grc ; it's a lot more
>>>>>>>>>> complicated, though, and you'd have to write a message / PDU source
>>>>>>>>>> that
>>>>>>>>>> gives you the data you want to transmit, rather than the Random PDU
>>>>>>>>>> block!
>>>>>>>>>>
>>>>>>>>>> I don't really know if that is the way to go. What is it, that
>>>>>>>>>> you want to build? Maybe the mailing list can advise?
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Marcus
>>>>>>>>>>
>>>>>>>>>> On 08/01/2017 05:26 PM, Rui ZOU wrote:
>>>>>>>>>>
>>>>>>>>>> Here are the two flowgraphs I have used. I have tried to attach
>>>>>>>>>> the two files in my first email. Probably failed in doing that. If
>>>>>>>>>> still
>>>>>>>>>> not seen, please let me know so I will try again. Thanks for your
>>>>>>>>>> help.
>>>>>>>>>>
>>>>>>>>>> Running the first flow graph will cause GRC stop responding
>>>>>>>>>> instantly, while the second one can run for a little while and
>>>>>>>>>> produce lots
>>>>>>>>>> of 'L' before going not responsive.
>>>>>>>>>>
>>>>>>>>>> Rui
>>>>>>>>>>
>>>>>>>>>> On Tue, Aug 1, 2017 at 11:09 AM, Marcus Müller <muel...@kit.edu>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Rui,
>>>>>>>>>>>
>>>>>>>>>>> don't know, to me, it looks like replying didn't work out great,
>>>>>>>>>>> since my mail client showed your mail in a new thread. Really,
>>>>>>>>>>> replying to
>>>>>>>>>>> a mailing list mail should be nothing more than hitting the "reply"
>>>>>>>>>>> or
>>>>>>>>>>> "reply all" button.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, even the slowest PC/laptop/Raspberry Pi/… I could think
>>>>>>>>>>> of would be able to deal with these rates, so there's very, very
>>>>>>>>>>> likely
>>>>>>>>>>> something wrong with the GNU Radio flowgraph you're using. Maybe
>>>>>>>>>>> you'd want
>>>>>>>>>>> to share that!
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> Marcus
>>>>>>>>>>>
>>>>>>>>>>> On 08/01/2017 04:59 PM, Rui ZOU wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Marcus,
>>>>>>>>>>>
>>>>>>>>>>> Sorry for leaving the title empty, that's the first time to post
>>>>>>>>>>> to a mailing list. This is also the first time to reply, no sure if
>>>>>>>>>>> I
>>>>>>>>>>> replied correctly.
>>>>>>>>>>>
>>>>>>>>>>> I use 390.625k as the sampling rate because this is the lowest I
>>>>>>>>>>> can get using the Ettus X310 without giving me a warning saying
>>>>>>>>>>> that the
>>>>>>>>>>> sampling rate cannot be provided by the hardware. The application
>>>>>>>>>>> is just
>>>>>>>>>>> transmitting a file using GMSK modulation on the two daughter
>>>>>>>>>>> boards of
>>>>>>>>>>> X310.
>>>>>>>>>>>
>>>>>>>>>>> Rui
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Discuss-gnuradio mailing
>>>>>>>>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>>>
>>>>>>>>>>>
>
>
test.grc
Description: Binary data
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##################################################
# GNU Radio Python Flow Graph
# Title: Test
# Generated: Wed Aug 2 14:05:51 2017
##################################################
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"
from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import sys
import time
class test(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "Test")
Qt.QWidget.__init__(self)
self.setWindowTitle("Test")
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)
self.settings = Qt.QSettings("GNU Radio", "test")
self.restoreGeometry(self.settings.value("geometry").toByteArray())
##################################################
# Variables
##################################################
self.samp_rate = samp_rate = 390.625e3
##################################################
# Blocks
##################################################
self.uhd_usrp_sink_0 = uhd.usrp_sink(
",".join(("addr0=192.168.10.2", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(2),
),
)
self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
self.uhd_usrp_sink_0.set_center_freq(2.41e9, 0)
self.uhd_usrp_sink_0.set_gain(20, 0)
self.uhd_usrp_sink_0.set_antenna('TX/RX', 0)
self.uhd_usrp_sink_0.set_center_freq(2.47e9, 1)
self.uhd_usrp_sink_0.set_gain(20, 1)
self.uhd_usrp_sink_0.set_antenna('TX/RX', 1)
self.blocks_stream_mux_0 = blocks.stream_mux(gr.sizeof_gr_complex*1, (1, 1))
self.blocks_probe_rate_0 = blocks.probe_rate(gr.sizeof_gr_complex*1, 500.0, 0.15)
self.blocks_null_source_0 = blocks.null_source(gr.sizeof_gr_complex*1)
self.blocks_message_debug_0 = blocks.message_debug()
##################################################
# Connections
##################################################
self.msg_connect((self.blocks_probe_rate_0, 'rate'), (self.blocks_message_debug_0, 'print'))
self.connect((self.blocks_null_source_0, 0), (self.blocks_stream_mux_0, 0))
self.connect((self.blocks_null_source_0, 0), (self.blocks_stream_mux_0, 1))
self.connect((self.blocks_null_source_0, 0), (self.uhd_usrp_sink_0, 0))
self.connect((self.blocks_null_source_0, 0), (self.uhd_usrp_sink_0, 1))
self.connect((self.blocks_stream_mux_0, 0), (self.blocks_probe_rate_0, 0))
def closeEvent(self, event):
self.settings = Qt.QSettings("GNU Radio", "test")
self.settings.setValue("geometry", self.saveGeometry())
event.accept()
def get_samp_rate(self):
return self.samp_rate
def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
self.uhd_usrp_sink_0.set_samp_rate(self.samp_rate)
def main(top_block_cls=test, options=None):
from distutils.version import StrictVersion
if StrictVersion(Qt.qVersion()) >= StrictVersion("4.5.0"):
style = gr.prefs().get_string('qtgui', 'style', 'raster')
Qt.QApplication.setGraphicsSystem(style)
qapp = Qt.QApplication(sys.argv)
tb = top_block_cls()
tb.start()
tb.show()
def quitting():
tb.stop()
tb.wait()
qapp.connect(qapp, Qt.SIGNAL("aboutToQuit()"), quitting)
qapp.exec_()
if __name__ == '__main__':
main()
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
