GNU Radio, One Step at a Time: August 2018

Friday, August 31, 2018

Re: [Discuss-gnuradio] re-initialize multi usrp object

Hi Sanjoy,

> ubuntu 14.04

That is ancient, and Ubuntu's LTS isn't worth the "S" they have in its
name. Don't do this to yourself. Update to the recent LTS release,
18.04.

This is really more of a general UHD question than specific to GNU
Radio – you'll probably be better off discussing this on usrp-users (in
CC:, you need to sign up for that).

> If I use reset command, it gives error on the runtime.
>

Without you telling us what that error exactly is, it's going to be
hard to help you. Can you point me towards where you've found the
"reset command"?

Anyway, the multi_usrp class doesn't have a 'reset' method, but the
shared pointer does. Not quite sure what you want to achieve, so I'm
afraid that you'll have to tell us

* what exactly your code is supposed to do
* what it exactly does (and the error)
* how those differ, and optimally
* a minimal full example that someone could compile and investigate.

The last step seems to be optional, but honestly, it's usually the most
helpful one, for yourself, because it requires you to think about what
exactly you need to do to trigger the unexpected behaviour and thus
gives you the ability to investigate yourself.

Best regards,

Marcus

On Fri, 2018-08-31 at 23:23 +0200, Sanjoy Basak wrote:
>
> Hi All,
> I need to re-initialize multi usrp object in my (c++) application on
> the runtime. How should I reset the multi usrp object?
> If I use reset command, it gives error on the runtime.
> Could anyone tell me what is the correct way to re-initialize the
> multi usrp object?
>
> uhd::usrp::multi_usrp::sptr usrp;
> string args="addr0=192.168.10.1,addr1=192.168.10.2";
> usrp = uhd::usrp::multi_usrp::make(args);
> uhd::usrp::subdev_spec_t subdev("A:0 B:0");
>
> //receive and operate
> ...
>
> //reinitialize usrp
> usrp.reset();
> string args="addr0=192.168.10.1,addr1=192.168.10.2";
> usrp=uhd::usrp::multi_usrp::make(args);
> uhd::usrp::subdev_spec_t subdev("A:0 B:0");
>
> I am using usrp x310, ubuntu 14.04 and uhd 3.9 lts.
>
> Best regards
> Sanjoy
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] re-initialize multi usrp object

On 08/31/2018 05:23 PM, Sanjoy Basak wrote:

Hi All,
I need to re-initialize multi usrp object in my (c++) application on the runtime. How should I reset the multi usrp object?

If I use reset command, it gives error on the runtime.

Could anyone tell me what is the correct way to re-initialize the multi usrp object?

uhd::usrp::multi_usrp::sptr usrp;

string args="addr0=192.168.10.1,addr1=192.168.10.2";

usrp = uhd::usrp::multi_usrp::make(args);

uhd::usrp::subdev_spec_t subdev("A:0 B:0");

//receive and operate

...

//reinitialize usrp

usrp.reset();

string args="addr0=192.168.10.1,addr1=192.168.10.2";

usrp=uhd::usrp::multi_usrp::make(args);

uhd::usrp::subdev_spec_t subdev("A:0 B:0");

I am using usrp x310, ubuntu 14.04 and uhd 3.9 lts.

Best regards

Sanjoy

What is it you wish to "re-initialize"?? You can always destroy the usrp object, and create a fresh one.

But in most cases, I don't see why you need to "reset" the usrp object.

[Discuss-gnuradio] re-initialize multi usrp object

Hi All,

I need to re-initialize multi usrp object in my (c++) application on the runtime. How should I reset the multi usrp object?

If I use reset command, it gives error on the runtime.

Could anyone tell me what is the correct way to re-initialize the multi usrp object?

uhd::usrp::multi_usrp::sptr usrp;

string args="addr0=192.168.10.1,addr1=192.168.10.2";

usrp = uhd::usrp::multi_usrp::make(args);

uhd::usrp::subdev_spec_t subdev("A:0 B:0");

//receive and operate

...

//reinitialize usrp

usrp.reset();

string args="addr0=192.168.10.1,addr1=192.168.10.2";

usrp=uhd::usrp::multi_usrp::make(args);

uhd::usrp::subdev_spec_t subdev("A:0 B:0");

I am using usrp x310, ubuntu 14.04 and uhd 3.9 lts.

Best regards

Sanjoy

Thursday, August 30, 2018

Re: [Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR programer

Hi Kevin,

(inline comments).

On 27-08-18 02:57, Kevin Reid wrote:
> Some partial answers, from memory and not necessarily correct:
Well, they where usefull anyway, so thanks. :-)

>
> On Sun, Aug 26, 2018 at 1:26 PM Kristoff <kristoff@skypro.be
> <mailto:kristoff@skypro.be>> wrote:
>
> - Can somebody explain how to implement a source-block using
> embedded-python?
> In the code I have now, it is implemented as a sync-block, taking
> in a
> signal from a signal-generator block, but that is probably
> (surely!) not
> the correct way to do this.
>
>
> A source block is just a block with no inputs. I haven't yet tried it
> in Python but it /should/ be simply specifying in_sig=[] in the
> __init__. This means that your work function will be called repeatedly
> rather than only when input data is available.
Correct.

Got that to work. Thx!

But do note that you should also use "self.set_output_multiple" to set
the number of bits you will send into the output queue every time the
"work" function is called.

> I did notice that the signal-generator blocks that exists in GRC
> do have
> a input-port that is greyed-out and not connected. I probably need to
> implement something simular.
>
>
> No, gray ports in GRC are message ports for receiving control
> messages. It is a separate additional feature of that block and not
> one you have to implement.
OK. I didn'tknow these block have control-ports. I should look into that :-)

(cut some more interesting stuff .. thx for that :-) )

> - Basically, a pocsag paging-message is a packet, not a continuous
> stream.
> It is possible to create a source-block that creates a stream of a
> limited length and then stop the execution of the graph?
>
>
> There are two things you can do depending on what you need.
>
> You can return -1 from the work function to indicate you are done.
> This propagates to downstream blocks, and causes the top_block.wait()
> call that exists in most GR programs to stop waiting and return, but
> it can instead choose to (reconfigure and) restart the flow graph if
> you have an application where that makes sense.
>
For some reason, tThat didn't work in my case. Returning -1 from the
worker function did not stop the flow-graph.

I do get a lot of "U"s in the console, but the application does not stop.
No idea why this is.

> If you mean you want to pause work and resume when the next packet
> comes along, then your source should just block until more data is
> available. You might need to pad the output with zeroes at the end to
> ensure the packet isn't cut off by sitting in partial buffers.

That DID work, .. starving the output-channel did caused the osmocom
transmitter-module to stop transmit, .. but it did not revive when I
restarted sending data out the egress port.

In my case, it was OK as I only wanted to send one single packet, but it
does not looks to be a sollution for just switching on and off a
transmitter.
OK. It's good enough for what I needed it for.

>
> (I haven't worked with the second approach, so there might be other
> caveats, and there may be better tools — my work with GNU Radio has
> been primarily analog/continuous receiving rather than
> transmitters/transceivers using packets.)
No problem.
Thanks for your reply. It was very helpfull.

Kristoff

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] runtime error while running flowgraph

I am trying to implement this discussion:[Discuss-gnuradio] Change frequency in USRP source automatically (https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00402.html). My objective is to create a block which changes the frequency automatically in steps of 2e6, starting from 2.37e9.

My block has a code given below:

import string

import numpy
import pmt
from gnuradio import gr
from gnuradio import digital

class frew_sweep_v1_f(gr.sync_block):
    """
    docstring for block frew_sweep_v1_f
    """
    def __init__(self,initial_freq=2.37e9, step=2e6):
        gr.sync_block.__init__(self,
            name="frew_sweep_v1_f",
            in_sig=[],
            out_sig=[])

   self.message_port_register_in(pmt.intern('clock'))
       self.message_port_register_out(pmt.intern('sync'))
   self.set_msg_handler(pmt.intern('clock'),self.handler)
        self.freq=initial_freq
        self.step=step

    def handler(self,pdu):
        self.message_port_pub(pmt.intern('sync'),pmt.cons(pmt.intern("freq"),pmt.to_pmt(self.freq)))

self.freq+=self.step

the xml file has a code given below:

<?xml version="1.0"?>
<block>
<name>frew_sweep_v1_f</name>
<key>tutorial_frew_sweep_v1_f</key>
<category>[tutorial]</category>
<import>import tutorial</import>
<import>from gnuradio.digital import packet_utils</import>
<make>tutorial.frew_sweep_v1_f($initial_freq, $step)</make>
<callback>post_message($msg)</callback>
<param>
    <name>message</name>
    <key>msg</key>
    <type>string</type>
</param>
<sink>
    <name>in</name>
    <type>message</type>
</sink>

<source>
    <name>out</name>
    <type>message</type>
</source>

</block>

I inserted this new block between a message block and message debug block.

The new top_block code generated is given below:

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 digital
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.digital import packet_utils
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import pmt
import sys
import tutorial
from gnuradio import qtgui

class top_blockRSM_frew_sweepv1(gr.top_block, Qt.QWidget):

    def __init__(self):
        gr.top_block.__init__(self, "Top Blockrsm Frew Sweepv1")
        Qt.QWidget.__init__(self)
        self.setWindowTitle("Top Blockrsm Frew Sweepv1")
        qtgui.util.check_set_qss()
        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", "top_blockRSM_frew_sweepv1")
        self.restoreGeometry(self.settings.value("geometry").toByteArray())

        ##################################################
        # Variables
        ##################################################
        self.samp_rate = samp_rate = 32000

        ##################################################
        # Blocks
        ##################################################
        self.tutorial_frew_sweep_v1_f_0 = Template error: tutorial.frew_sweep_v1_f($initial_freq, $step)
            cannot find 'initial_freq'
        self.blocks_message_strobe_0 = blocks.message_strobe(pmt.intern("freq"), 10000)
        self.blocks_message_debug_0 = blocks.message_debug()

        ##################################################
        # Connections
        ##################################################
        self.msg_connect((self.blocks_message_strobe_0, 'strobe'), (self.tutorial_frew_sweep_v1_f_0, 'in'))
        self.msg_connect((self.tutorial_frew_sweep_v1_f_0, 'out'), (self.blocks_message_debug_0, 'print'))

    def closeEvent(self, event):
        self.settings = Qt.QSettings("GNU Radio", "top_blockRSM_frew_sweepv1")
        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

def main(top_block_cls=top_blockRSM_frew_sweepv1, 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()

in the code, under Blocks, it shows

self.tutorial_frew_sweep_v1_f_0 = Template error: tutorial.frew_sweep_v1_f($initial_freq, $step) cannot find 'initial_freq'

So when I Execute the flowgraph, the error pops up.

Executing: /usr/bin/python2 -u /home/pglab1/top_blockRSM_frew_sweepv3.py

File "/home/pglab1/top_blockRSM_frew_sweepv3.py", line 67
self.tutorial_frew_sweep_v1_f_0 = Template error: tutorial.frew_sweep_v1_f($initial_freq, $step)
^
SyntaxError: invalid syntax

>>> Done (return code 1)

Can someone tell why this error is created in the python code?

Thanking you

Rensi

[Discuss-gnuradio] OFDM Carrier Allocator

Hello, I have trouble assigning parameters to sync words in OFDM Carrier allocator block in gnu radio.

Does anyone has an example to share.

Wednesday, August 29, 2018

[Discuss-gnuradio] GRCon Update - Schedule, Workshops, and Tickets

Hello folks,

The GNU Radio Conference is coming up next month!

The Regular Registration ticket sales will end on Friday. More tickets will be available up to and during the conference, but at Late Registration rate, so register now if you know you're going!

https://www.gnuradio.org/grcon-2018/register/

The schedule and talk descriptions are on the website.

https://www.gnuradio.org/grcon-2018/schedule/

https://www.gnuradio.org/grcon-2018/speakers/

We are very excited about the workshops and tutorials which are being run this year.

* Introduction to the ADALM-PLUTO SDR, Linux's IIO, and Open-Source Toolchains

* Systems Programming on the IIO based radios within the IIO Framework

* Introduction to FPGA Programming on the USRP Using the RFNoC Framework

* DVB-S2/X Block Party - DVB-S2 and DVB-S2X receivers in GNU Radio

* Overview of Machine Learning (ML) Applications using open-source ML/SDR tools in RF systems, Sensing and Navigation

* Antenna Design and Analog Frontend Considerations

* Open Source Licensing Workshop

* Fixing your first GNU Radio bug

https://www.gnuradio.org/grcon-2018/workshops/

Additionally there will be four community and development focused break out sessions.

* Heterogeneous Computing

* GNU Radio Educators Group

* Documentation

* SigMF Breakout Session

https://www.gnuradio.org/grcon-2018/workgroups/

We say it on the site, we'll say it at the conference, and I'll say it every opportunity I have; Our amazing sponsors are essential to us being able to run the conference every year. Their support lets us bring in our keynote speakers, subsidize student attendees, have the talks professionally recorded, and numerous other parts of making the event excellent and run smoothly. Particular thanks to SkySafe for sponsoring the Monday night social event.

https://www.gnuradio.org/grcon-2018/sponsors/

We'll have a few more announcements over the next weeks. The organizing committee and GNU Radio project members very much look forward to seeing many of you at the conference.

Tuesday, August 28, 2018

[Discuss-gnuradio] Changing frequency automatically

My block has a code given below:

import string

self.freq+=self.step

the xml file has a code given below:

</block>

I inserted this new block between a message block and message debug block.

The new top_block code generated is given below:

in the code, under Blocks, it shows

self.tutorial_frew_sweep_v1_f_0 = Template error: tutorial.frew_sweep_v1_f($initial_freq, $step) cannot find 'initial_freq'

So when I Execute the flowgraph, the error pops up.

Can someone tell why this error is created in the python code?

Thanking you

Rensi

Re: [Discuss-gnuradio] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

Thanks for the info, George. I guess since some USB controllers work better or worse with UHD / USRP, these USB adapters will also be better or worse. I bought my MBP touch 2017 USB-C to USB-3 adapters off of eBay -- the least expensive they provided that didn't ship from China (overseas etc) -- and they've worked flawlessly for me. Glad you were able to track the issue down to that adapter! - MLD

On Tue, Aug 28, 2018, at 1:13 PM, George Rykowski wrote:

Michael, thank you for the response. I've discovered the issue and it is the USB-C adapter I was using for the USB connection to the USRP B210. The MacBook Pro 2018 provides 4 USB-C ports, so adapters are generally required. I was using the following:

https://www.amazon.com/gp/product/B07BGTV9J4/ref=ask_ql_qh_dp_hza

Even though it uses 2 USB-C ports to provide power and connectivity, for some reason the adapter would occasionally force an I/O error on the USB interface. I am now using the following Apple adapter, which has worked flawlessly:

https://www.apple.com/shop/product/MJ1K2AM/A/usb-c-digital-av-multiport-adapter

[Discuss-gnuradio] Merging next into master (~3d code contribution freeze starting tomorrow)

Hi, coolest SDR community since Fourier solved his first integral,

so, it's come to the point that I'd like to merge the next branch into
the master branch.

That means we're getting closer to 3.8 – yay!
But it also means that I'll have to freeze the PR pipeline for until
that merge is done - meh.

So, let's coordinate this:

Tomorrow, 7:00 UTC I'll simply stop looking at new PRs until I've
finished the merge and pushed the merge commit. You're still welcome to
submit PRs, but please be aware that you might need to instantly rebase
them after. But, if you've been doing PRs against next in the last
couple weeks (looking at the awesome Volker and Hakon especially here),
then you probably have a fairly good idea whether that rebase will be
hard or not.

The merge is – hopefully – not going to take long. Due to other things
that I need to take care of, I can't spend the whole day on it, but I
hope it'll be done by Friday evening (UTC).

I know there's still plenty of bugs on next, and they'll still be there
on master after the merge. Point is, we've got next into a state that's
actually useful enough for debugging as it passes all unit tests and
GRC is basically useful again. So, let's fix these things on master
instead of some abstract branch called next, and let's have a GNU Radio
3.8. alpha version at GRCon!

If you've got any questions regardinig this, don't be afraid to follow
up here on the mailing list, on IRC, or even in private.

Best regards,
Marcus
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

Michael, thank you for the response. I've discovered the issue and it is the USB-C adapter I was using for the USB connection to the USRP B210. The MacBook Pro 2018 provides 4 USB-C ports, so adapters are generally required. I was using the following:

https://www.amazon.com/gp/product/B07BGTV9J4/ref=ask_ql_qh_dp_hza

Even though it uses 2 USB-C ports to provide power and connectivity, for some reason the adapter would occasionally force an I/O error on the USB interface. I am now using the following Apple adapter, which has worked flawlessly:

https://www.apple.com/shop/product/MJ1K2AM/A/usb-c-digital-av-multiport-adapter

From: Michael Dickens <michael.dickens@ettus.com>
Date: Monday, August 27, 2018 at 3:15 PM
To: George Rykowski <george@rykowski.com>, <discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

Hi George - I haven't seen this error yet, but of course I'm just one Mac UHD / GR user; I'll try testing my B210 for longer. In the meantime, how is UHD & GR installed? If MacPorts, have you tried the "uhd-devel" port? Sometimes it has fixes to the release. - MLD

On Mon, Aug 27, 2018, at 3:46 PM, George Rykowski wrote:

I have been seeing this error regularly for a couple weeks. As I am running my code, the error stops execution, on average, approximately every 10 minutes (though, once or twice, I have received the error quickly in sequence). My code is simple: I am reading in a recorded waveform (using File Source) and sending, over USB3, to a USRP B210 for transmission (using UHD: USRP Sink).

libc++abi.dylib: terminating with uncaught exception of type uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

>>> Done (return code -6)

My laptop is a MacBook Pro 2018 using MacOS High Sierra version 10.13.6, and running GNUradio Companion 3.7.13.4.

Has anyone seen this error? If yes, any hints as to how I can fix?

[Discuss-gnuradio] Enabling and disabling GUI from terminal

Hello,

I want to know if it is possible to enable or disable my flow's GUI from the terminal. I've converter my flow into a python application and I have been running it from the terminal, with all my GUIs disabled and, if I want to enable them, I need to manually do that in the flow and then regenerate the python code. I want to know if it is possible to do that directly from the terminal while running my ./myflow.py or not. I have found this roadmap from GRCon13 that (if I understood correctly) says this was one feature to be implemented. If this is a feature already, can someone indicate where I can learn how to use it?

Best regards,

Guilherme THEIS

Electrical engineering student ENSEIRB-MATMECA/UFPR (Double Degree program)

Élève ingénieur électronicien à ENSEIRB-MATMECA/UFPR (DOUBLE - DIPLOME)
Portable : +33 07 67 05 00 13

Graduando em Engenharia Elétrica - UFPR/ENSEIRB-MATMECA

Contato: +33 07 67 05 00 13

Monday, August 27, 2018

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

Hello everyone.

Well, I tried to put a AGC block before the LPF and I changed some gain values and I could receive some black and white moving images. I can't see it perfectly like the example but I can appreciate shapes and with the hsync, vdelay and hdelay sliders I hope to improve the moving images and the receiver.

Martin, thanks for your help and your time again friend.

De: Discuss-gnuradio <discuss-gnuradio-bounces+andrescampos45=hotmail.com@gnu.org> en nombre de Martin McCormick <martin.m@suddenlink.net>
Enviado: lunes, 27 de agosto de 2018 17:58
Cc: discuss-gnuradio@gnu.org
Asunto: Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

Andres Campos Santana <andrescampos45@hotmail.com> writes:
> I tried to listen to the NTSC channel audio using a FM receiver I made,
> and I got it, I could listen to it perfectly.
>
> That should be a good way to prove that I'm receiving the channel signal,
> for that reason, I don't understand why I just receive a diffuse mix of
> black, white and gray image instead of perceiving a moving black and
> white moving images. I understand I can't receive a colour image due to
> the RTL bw (2MHz).
>
>
> I was talking with Martin and he told me this problem would be due to my
> sound card isn't sampling as fast as the program needs or my proccesing
> unit doesn't support it. I have Intel® Core™ i5-3210M CPU @ 2.50GHz ×
> 4 in a Lenovo Thinkpad t430 computer.
>
> The program that I am guiding myself is well done since in the results
> you can see that black and white television.
>
> What do you think about this problem? Thanks for your help!
>
> Andrés.

        This is martin again. I was confused when I
discussed the sound card not being fast enough. I had a picture
in my mind of the sound card being somehow used to turn all those
2-million samples per second in to a base band video signal.

        In this program, the sound card has nothing to do with
what kind of video you get. The data from the RTL dongle are
processed to decode amplitude modulation so that each 16-bit
sample represents a voltage level from black to white. The
Thinkpad appears to be fast enough but this entire process for
each pixel has no time at all to spare. Every module in that
video chain, both hardware and software, is probably stretched to
the limit of endurance and just one process failing to complete
in time for the next pixel decode is enough to ruin the picture.

        I am not familiar with the Lenovo Thinkpad t430
specifically, but it is a good laptop used by many.

        Desktop and laptop computer design is a sort of war
between cost and capability. With laptops, one also has energy
usage, heat and size. When you see a desktop with a graphics
accelerator video card, it is designed to handle math and
addressing faster than does the standard video display for the
same computer. You could have two of the same model computer
sitting side by side running the same RTL module, operating
system and two identical copies of the same NTSC program. One
might receive the black-and-white signal and the other might just
get a scrambled mess on it's screen. Look inside and you would
probably find that the computer successfully receiving the image
has a graphics accelerator card or some sort of math
accelerator hardware to raise the apparent processing speed of
the system.

        How many remember the math co-processor module one needed
for the early IBM PC's?

        I remember that and never got to do any tests on speed,
but if the software could use the math co-processor, you
supposedly got quite a boost in performance with the same 4.7 MHZ
clock. Ah, those were the days. By the way, if your software
couldn't figure out whether you had a math co-processor, the
co-processor simply helped make your room hotter.

Martin WB5AGZ

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Discuss-gnuradio Info Page - lists.gnu.org

lists.gnu.org

Discuss-gnuradio -- GNU Radio, the Free & Open-Source Toolkit for Software Radio About Discuss-gnuradio

[Discuss-gnuradio] Getting Started Help (MATLAB like vector indexing) [GNU Radio Companion]

Hello SDR community,

I need some guidance into how vector manipulation works in GNU radio companion.

Suppose I have the following MATLAB/Octave code:

Nf = 128;

Nt = 2^10;

F = zeros(Nt/2+1,1);

idxs = (1:round(Nt/Nf)/2:Nt/2)+1

phi = 2*pi*rand(Nf,1);

F(idxs,:) = sqrt(Nt)*exp(1i*phi);

% can't figure out how to manipulate elements of F (vector object in GRC)

What would be the most efficient (development time) way of implementing this? I have spent a couple of hours in GRC messing with vector blocks and I still can't find ways to manipulate indexes of vectors.

Should I make a bare-bones template in GRC and add my own numpy code to get around block limitations?

I feel like GRC was designed with streaming in mind. Vector and matrix manipulation seems really limited with GUI blocks unless I am missing something. Do most people write python code directly for non-streaming situations?

Thank you for your time,

Ali

Re: [Discuss-gnuradio] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

On Mon, Aug 27, 2018, at 3:46 PM, George Rykowski wrote:

I have been seeing this error regularly for a couple weeks. As I am running my code, the error stops execution, on average, approximately every 10 minutes (though, once or twice, I have received the error quickly in sequence). My code is simple: I am reading in a recorded waveform (using File Source) and sending, over USB3, to a USRP B210 for transmission (using UHD: USRP Sink).

libc++abi.dylib: terminating with uncaught exception of type uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

>>> Done (return code -6)

My laptop is a MacBook Pro 2018 using MacOS High Sierra version 10.13.6, and running GNUradio Companion 3.7.13.4.

Has anyone seen this error? If yes, any hints as to how I can fix?

[Discuss-gnuradio] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

I have been seeing this error regularly for a couple weeks. As I am running my code, the error stops execution, on average, approximately every 10 minutes (though, once or twice, I have received the error quickly in sequence). My code is simple: I am reading in a recorded waveform (using File Source) and sending, over USB3, to a USRP B210 for transmission (using UHD: USRP Sink).

libc++abi.dylib: terminating with uncaught exception of type uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

>>> Done (return code -6)

My laptop is a MacBook Pro 2018 using MacOS High Sierra version 10.13.6, and running GNUradio Companion 3.7.13.4.

Has anyone seen this error? If yes, any hints as to how I can fix?

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

This is martin again. I was confused when I
discussed the sound card not being fast enough. I had a picture
in my mind of the sound card being somehow used to turn all those
2-million samples per second in to a base band video signal.

In this program, the sound card has nothing to do with
what kind of video you get. The data from the RTL dongle are
processed to decode amplitude modulation so that each 16-bit
sample represents a voltage level from black to white. The
Thinkpad appears to be fast enough but this entire process for
each pixel has no time at all to spare. Every module in that
video chain, both hardware and software, is probably stretched to
the limit of endurance and just one process failing to complete
in time for the next pixel decode is enough to ruin the picture.

I am not familiar with the Lenovo Thinkpad t430
specifically, but it is a good laptop used by many.

Desktop and laptop computer design is a sort of war
between cost and capability. With laptops, one also has energy
usage, heat and size. When you see a desktop with a graphics
accelerator video card, it is designed to handle math and
addressing faster than does the standard video display for the
same computer. You could have two of the same model computer
sitting side by side running the same RTL module, operating
system and two identical copies of the same NTSC program. One
might receive the black-and-white signal and the other might just
get a scrambled mess on it's screen. Look inside and you would
probably find that the computer successfully receiving the image
has a graphics accelerator card or some sort of math
accelerator hardware to raise the apparent processing speed of
the system.

How many remember the math co-processor module one needed
for the early IBM PC's?

I remember that and never got to do any tests on speed,
but if the software could use the math co-processor, you
supposedly got quite a boost in performance with the same 4.7 MHZ
clock. Ah, those were the days. By the way, if your software
couldn't figure out whether you had a math co-processor, the
co-processor simply helped make your room hotter.

Martin WB5AGZ

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help needed with message ports [success]

Hi Volker - You're welcome & so glad that we got the issue figured out! Which reminds me that I never put together a PR for the changes that would give programmers a clue that a hier2 block isn't meant to do actual "work". I'll add that to my queue & try to get it in before GRCon ... Cheers! - MLD

On Mon, Aug 27, 2018, at 8:50 AM, Volker Schroer wrote:
> Just to report the solution, as it me be usefull for others.
>
> My block was an hier2 block. Hier2 blocks can't handle messages
> directly, they only can serve as a proxy.
>
> So I added a gr::block with no inputs and outputs ( yes, this is
> possible, I did not know before ) that could handle the message.
>
> From my hier2 block I routed the message to my new block and everything
> works fine.
>
> The details can be seen on github
>
> https://github.com/dl1ksv/gr-fcdproplus/tree/gnuradio3.8
>
> Many thanks to MLD, who pointed me into the right direction.
>
> -- Volker

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help needed with message ports [success]

Just to report the solution, as it me be usefull for others.

My block was an hier2 block. Hier2 blocks can't handle messages
directly, they only can serve as a proxy.

So I added a gr::block with no inputs and outputs ( yes, this is
possible, I did not know before ) that could handle the message.

From my hier2 block I routed the message to my new block and everything
works fine.

The details can be seen on github

https://github.com/dl1ksv/gr-fcdproplus/tree/gnuradio3.8

Many thanks to MLD, who pointed me into the right direction.

-- Volker

Am 20.07.2018 um 12:28 schrieb Volker Schroer:
> Hi,
>
> I'm trying to add an message port to my working oot module fcdproplus
> to be able to control the frequency by an message from a qtgui sink.
>
> I used the analog signal source as guide and implemented a message sink
> in the grc description, registered the in port, and defined a handler
> function like described in the tutorial.
>
> I can run my example of a simple fm receiver as before, but when I
> connect the message out port of a qtgui sink to my message in port of my
> oot block,
>
> I get the following error message:
>
>
> ./FMRadio.py
> INFO: Audio source arch: alsa
> Funcube Dongle Pro+ found as: plughw:3,0
> Dongle sucessfully initialized
> Result of Action :+++++
> FCDAPP 20.03
> Lna gain enabled
> Mixer gain enabled
> If gain set to: 10
> Set Frequency to: 94.3 KHz, corrected to: 94300 Khz
> INFO: Audio sink arch: alsa
> Traceback (most recent call last):
> File "./FMRadio.py", line 277, in <module>
>     main()
> File "./FMRadio.py", line 266, in main
>     tb.start()
> File
> "/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/top_block.py",
> line 109, in start
>     top_block_start_unlocked(self._impl, max_noutput_items)
> File
> "/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py",
> line 5678, in top_block_start_unlocked
>     return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
> RuntimeError: fcdproplus(3): insufficient connected output ports (1
> needed, 0 connected)
>
> These are the connections:
>
>
>        ##################################################
>         # Connections
>         ##################################################
>         self.msg_connect((self.qtgui_sink_x_0, 'freq'),
> (self.fcdproplus_fcdproplus_0, 'freq'))
>         self.connect((self.analog_fm_demod_cf_0, 0),
> (self.audio_sink_0, 0))
>         self.connect((self.analog_fm_demod_cf_0, 0),
> (self.audio_sink_0, 1))
>         self.connect((self.fcdproplus_fcdproplus_0, 0),
> (self.low_pass_filter_0, 0))
>         self.connect((self.fcdproplus_fcdproplus_0, 0),
> (self.qtgui_sink_x_0, 0))
>         self.connect((self.low_pass_filter_0, 0),
> (self.analog_fm_demod_cf_0, 0))
>
> If I remove the line
>
> self.msg_connect((self.qtgui_sink_x_0, 'freq'),
> (self.fcdproplus_fcdproplus_0, 'freq'))
>
>
> from my python script he error message disappears.
>
> What am I doing wrong?
>
>
> Any help is appreciated.
>
> -- Volker
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] No module named RPCConnectionThrift

Your GNU Radio was built without Thrift support.
You need to uninstall your GNU Radio, go back to the CMake step in
building it, and make sure all the requirements are met: in this case,
PyThrift and thrift, need to be installed probably. The CMake output
will tell you exactly what is missing.

Best regards,
Marcus

On Mon, 2018-08-27 at 06:57 +0000, Rensi Mathew wrote:
> when I am working on python simple_copy_controller.py 127.0.0.1
> <PORT> true,
> it shows the following error:-
> root@pglab1-HCL-Desktop:/home/pglab1/gnuradio/gr-
> blocks/examples/ctrlport# python simple_copy_controller.py 127.0.0.1
> 9090 true
> Traceback (most recent call last):
> File "simple_copy_controller.py", line 16, in <module>
> radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift')
> File "/usr/local/lib/python2.7/dist-
> packages/gnuradio/ctrlport/GNURadioControlPortClient.py", line 117,
> in __init__
> from gnuradio.ctrlport.RPCConnectionThrift import RPCConnectionThrift
> ImportError: No module named RPCConnectionThrift
> How can I correct this error?
>
> RensiSam
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] runtime error while running flowgraph

Have you first registered the "clock" message port? This looks like
you're trying to set a handler for a message port that doesn't exist.

Also, when asking for help, it's usually very helpful to have your
*exact* code somewhere, not a reference to code that is /similar/.

Best regards,
Marcus
On Mon, 2018-08-27 at 04:18 +0000, Rensi Mathew wrote:
> I created a block using gr_modtool add -l python -tsync command,
> where I tried to implement this discussion:[Discuss-gnuradio] Change
> frequency in USRP source automatically (https://lists.gnu.org/archive
> /html/discuss-gnuradio/2016-03/msg00402.html)
> And then used this block in a flowgraph connecting to the block USRP
> Source.
> when I tried to run the top_block.py block, the following error was
> displayed:-
> > root@pglab1-HCL-Desktop:/home/pglab1# python top_block.py
> > Traceback (most recent call last):
> > File "top_block.py", line 98, in <module>
> > main()
> > File "top_block.py", line 86, in main
> > tb = top_block_cls()
> > File "top_block.py", line 64, in __init__
> > self.tutorial_frew_sweep_v1_f_0 = tutorial.frew_sweep_v1_f()
> > File "/usr/local/lib/python2.7/dist-
> > packages/tutorial/frew_sweep_v1_f.py", line 40, in __init__
> > self.set_msg_handler(pmt.intern('clock'),self.handler)
> > File "/usr/local/lib/python2.7/dist-
> > packages/gnuradio/gr/gateway.py", line 200, in set_msg_handler
> > self.__gateway.set_msg_handler_feval(which_port, handler)
> > File "/usr/local/lib/python2.7/dist-
> > packages/gnuradio/gr/runtime_swig.py", line 6423, in
> > set_msg_handler_feval
> > return _runtime_swig.block_gateway_sptr_set_msg_handler_feval(self,
> > which_port, msg_handler)
> > RuntimeError: attempt to set_msg_handler_feval() on bad input
> > message port!
> >
> > Can someone help me to correct this error?
> > Thanking you
> > Rensi Sam
> > Anna University
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Sunday, August 26, 2018

[Discuss-gnuradio] No module named RPCConnectionThrift

when I am working on python simple_copy_controller.py 127.0.0.1 <PORT> true,

it shows the following error:-

root@pglab1-HCL-Desktop:/home/pglab1/gnuradio/gr-blocks/examples/ctrlport# python simple_copy_controller.py 127.0.0.1 9090 true

Traceback (most recent call last):

File "simple_copy_controller.py", line 16, in <module>

radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift')

File "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py", line 117, in __init__

from gnuradio.ctrlport.RPCConnectionThrift import RPCConnectionThrift

ImportError: No module named RPCConnectionThrift

How can I correct this error?

RensiSam

[Discuss-gnuradio] runtime error while running flowgraph

I created a block using gr_modtool add -l python -tsync command, where I tried to implement this discussion:[Discuss-gnuradio] Change frequency in USRP source automatically (https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00402.html)

And then used this block in a flowgraph connecting to the block USRP Source.

when I tried to run the top_block.py block, the following error was displayed:-

root@pglab1-HCL-Desktop:/home/pglab1# python top_block.py

Traceback (most recent call last):

File "top_block.py", line 98, in <module>

main()

File "top_block.py", line 86, in main

tb = top_block_cls()

File "top_block.py", line 64, in __init__

self.tutorial_frew_sweep_v1_f_0 = tutorial.frew_sweep_v1_f()

File "/usr/local/lib/python2.7/dist-packages/tutorial/frew_sweep_v1_f.py", line 40, in __init__

self.set_msg_handler(pmt.intern('clock'),self.handler)

File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line 200, in set_msg_handler

self.__gateway.set_msg_handler_feval(which_port, handler)

File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 6423, in set_msg_handler_feval

return _runtime_swig.block_gateway_sptr_set_msg_handler_feval(self, which_port, msg_handler)

RuntimeError: attempt to set_msg_handler_feval() on bad input message port!

Can someone help me to correct this error?
Thanking you
Rensi Sam
Anna University

Re: [Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR programer

Some partial answers, from memory and not necessarily correct:

On Sun, Aug 26, 2018 at 1:26 PM Kristoff <kristoff@skypro.be> wrote:

- Can somebody explain how to implement a source-block using
embedded-python?
In the code I have now, it is implemented as a sync-block, taking in a
signal from a signal-generator block, but that is probably (surely!) not
the correct way to do this.

A source block is just a block with no inputs. I haven't yet tried it in Python but it should be simply specifying in_sig=[] in the __init__. This means that your work function will be called repeatedly rather than only when input data is available.

I did notice that the signal-generator blocks that exists in GRC do have
a input-port that is greyed-out and not connected. I probably need to
implement something simular.

No, gray ports in GRC are message ports for receiving control messages. It is a separate additional feature of that block and not one you have to implement.

- How do you interface your embedded-python code with variables that

change during run-time? (e.g. a variable mapped to a GUI slider).
How does the embedded-python program known when a variable has changed?

The GRC XML file which describes your block to GRC specifies what to do when one of its parameters have changed. GRC then generates code which, when a GRC "variable" or GUI control changes, tells all the blocks that need to know. This looks like, for example,

<callback>set_center_freq($center_freq)</callback>

That element in a GRC file means that whenever the parameter center_freq has changed — which might be due to any number of variables, since GRC allows input of expressions — GRC will ensure that the block's .set_center_freq() method is called with the new value. center_freq must have been defined in a <param> element elsewhere in the file.

- Basically, a pocsag paging-message is a packet, not a continuous stream.
It is possible to create a source-block that creates a stream of a
limited length and then stop the execution of the graph?

There are two things you can do depending on what you need.

You can return -1 from the work function to indicate you are done. This propagates to downstream blocks, and causes the top_block.wait() call that exists in most GR programs to stop waiting and return, but it can instead choose to (reconfigure and) restart the flow graph if you have an application where that makes sense.

If you mean you want to pause work and resume when the next packet comes along, then your source should just block until more data is available. You might need to pad the output with zeroes at the end to ensure the packet isn't cut off by sitting in partial buffers.

(I haven't worked with the second approach, so there might be other caveats, and there may be better tools — my work with GNU Radio has been primarily analog/continuous receiving rather than transmitters/transceivers using packets.)