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. LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL******* 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 10:20:20 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 digital
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import qtgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import sip
import sys
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.qtgui_freq_sink_x_0 = qtgui.freq_sink_c(
1024, #size
firdes.WIN_BLACKMAN_hARRIS, #wintype
0, #fc
samp_rate, #bw
"", #name
2 #number of inputs
)
self.qtgui_freq_sink_x_0.set_update_time(0.10)
self.qtgui_freq_sink_x_0.set_y_axis(-140, 10)
self.qtgui_freq_sink_x_0.set_y_label('Relative Gain', 'dB')
self.qtgui_freq_sink_x_0.set_trigger_mode(qtgui.TRIG_MODE_FREE, 0.0, 0, "")
self.qtgui_freq_sink_x_0.enable_autoscale(False)
self.qtgui_freq_sink_x_0.enable_grid(False)
self.qtgui_freq_sink_x_0.set_fft_average(1.0)
self.qtgui_freq_sink_x_0.enable_axis_labels(True)
self.qtgui_freq_sink_x_0.enable_control_panel(False)
if not True:
self.qtgui_freq_sink_x_0.disable_legend()
if "complex" == "float" or "complex" == "msg_float":
self.qtgui_freq_sink_x_0.set_plot_pos_half(not True)
labels = ['', '', '', '', '',
'', '', '', '', '']
widths = [1, 1, 1, 1, 1,
1, 1, 1, 1, 1]
colors = ["blue", "red", "green", "black", "cyan",
"magenta", "yellow", "dark red", "dark green", "dark blue"]
alphas = [1.0, 1.0, 1.0, 1.0, 1.0,
1.0, 1.0, 1.0, 1.0, 1.0]
for i in xrange(2):
if len(labels[i]) == 0:
self.qtgui_freq_sink_x_0.set_line_label(i, "Data {0}".format(i))
else:
self.qtgui_freq_sink_x_0.set_line_label(i, labels[i])
self.qtgui_freq_sink_x_0.set_line_width(i, widths[i])
self.qtgui_freq_sink_x_0.set_line_color(i, colors[i])
self.qtgui_freq_sink_x_0.set_line_alpha(i, alphas[i])
self._qtgui_freq_sink_x_0_win = sip.wrapinstance(self.qtgui_freq_sink_x_0.pyqwidget(), Qt.QWidget)
self.top_layout.addWidget(self._qtgui_freq_sink_x_0_win)
self.digital_gmsk_mod_0_0 = digital.gmsk_mod(
samples_per_symbol=2,
bt=0.35,
verbose=False,
log=False,
)
self.digital_gmsk_mod_0 = digital.gmsk_mod(
samples_per_symbol=2,
bt=0.35,
verbose=False,
log=False,
)
self.blocks_throttle_0 = blocks.throttle(gr.sizeof_gr_complex*1, samp_rate,True)
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_multiply_const_vxx_0_0 = blocks.multiply_const_vcc((1, ))
self.blocks_multiply_const_vxx_0 = blocks.multiply_const_vcc((1, ))
self.blocks_message_debug_0 = blocks.message_debug()
self.blocks_file_source_0_0_0 = blocks.file_source(gr.sizeof_char*1, '/home/netwis8/gnuradiopractice/srcfile2', True)
self.blocks_file_source_0_0 = blocks.file_source(gr.sizeof_char*1, '/home/netwis8/gnuradiopractice/srcfile1', True)
##################################################
# Connections
##################################################
self.msg_connect((self.blocks_probe_rate_0, 'rate'), (self.blocks_message_debug_0, 'print'))
self.connect((self.blocks_file_source_0_0, 0), (self.digital_gmsk_mod_0, 0))
self.connect((self.blocks_file_source_0_0_0, 0), (self.digital_gmsk_mod_0_0, 0))
self.connect((self.blocks_multiply_const_vxx_0, 0), (self.blocks_throttle_0, 0))
self.connect((self.blocks_multiply_const_vxx_0, 0), (self.qtgui_freq_sink_x_0, 0))
self.connect((self.blocks_multiply_const_vxx_0_0, 0), (self.blocks_stream_mux_0, 1))
self.connect((self.blocks_multiply_const_vxx_0_0, 0), (self.qtgui_freq_sink_x_0, 1))
self.connect((self.blocks_stream_mux_0, 0), (self.blocks_probe_rate_0, 0))
self.connect((self.blocks_throttle_0, 0), (self.blocks_stream_mux_0, 0))
self.connect((self.digital_gmsk_mod_0, 0), (self.blocks_multiply_const_vxx_0, 0))
self.connect((self.digital_gmsk_mod_0_0, 0), (self.blocks_multiply_const_vxx_0_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.qtgui_freq_sink_x_0.set_frequency_range(0, self.samp_rate)
self.blocks_throttle_0.set_sample_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
