[Discuss-gnuradio] Runtime error

[5G SOLUTIONS _Pvt_ Ltd]

Hi Everyone.
can u please let me know how to solve runtime error issue and also somtimes
device serial number not found.
Thanking you

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

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

[Rensi Mathew]

 I am trying to implement this discussion:[Discuss-gnuradio] Change frequency 
in USRPsource 
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 stringimport 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:
 

  frew_sweep_v1_f
  tutorial_frew_sweep_v1_f
  [tutorial]
  import tutorial
  from gnuradio.digital import packet_utils
  tutorial.frew_sweep_v1_f($initial_freq, $step)
  post_message($msg)
  
    message
    msg
    string
  
  
    in
    message
  
 
  
    out
    message
  


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"), 1)
    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()
    

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

[CEL]

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 +, 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 
> > 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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] runtime error while running flowgraph

[Rensi Mathew]

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

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

when Itried to run the top_block.py block, the following error wasdisplayed:-


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

Traceback(most recent call last):

 File"top_block.py", line 98, in 

 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 youRensi SamAnna University


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

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Sonny Rajagopalan]

Guilty as charged, Marcus :-) Thanks again for your help!

On Tue, Jan 31, 2017 at 12:53 PM, Marcus Müller 
wrote:

> Hi Sonny,
>
> that's why I explicitly asked you to confirm you didn't have multiple
> versions installed before we went down the detailed backtrace route...
>
> Ah well, I'm happy it's sorted out now :)
>
> Cheers,
>
> Marcus
>
> On 31.01.2017 17:59, Sonny Rajagopalan wrote:
>
> Thanks, Kevin!
>
> I think that was the issue. I had, in my early days of learning about SDR,
> installed another version of gnuradio. Also, I was not calling the
> pybombs-installed gnuradio correctly. Instead of
>
> $ pybombs run gnuradio-companion
>
> I was calling it like so:
>
> $ gnuradio-companion
>
> That is another error.
>
> I have everything working as expected now (i.e., got the OP flowgraph (and
> more)) working.
>
> I uninstalled all gnuradio-* components (sudo apt-get remove --purge
> libgnuradio*, and maybe more; try apt list --installed  | grep gnuradio)
> installed by Ubuntu's apt-get and then, using pybombs (see
> https://github.com/gnuradio/pybombs), rebuilt gnuradio and added the
> necessary recipes.
>
> So, here's what I did:
>
> $ apt list --installed  | grep gnuradio
> $ sudo apt-get remove --purge libgnuradio* # again, do the above and this
> line for everything else you may have installed using apt-get, e.g.,
> rtl-sdr, osmosdr etc.
> $ pybombs -vv rebuild gnuradio
> $ pybombs recipes add gr-recipes git+https://github.com/
> gnuradio/gr-recipes.git # may not be needed, but redid anyway.
> $ pybombs recipes add gr-etcetera git+https://github.com/
> gnuradio/gr-etcetera.git # may not be needed, but redid anyway.
> $ pybombs install gr-osmosdr
>
> Marcus, thanks for your on the matter! I hope this helps someone.
>
>
> On Mon, Jan 30, 2017 at 7:50 PM, Kevin Reid  wrote:
>
>> On Mon, Jan 30, 2017 at 11:12 AM, Sonny Rajagopalan <
>> sonny.rajagopa...@gmail.com> wrote:
>>
>>> RuntimeError: list contains invalid format!
>>>
>>
>> FWIW, I've seen this error before, and if I remember correctly it's a
>> symptom of multiple versions installed (such that the GR Python code is not
>> the same version as the GR native code).
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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] RunTime error in runtime_swig.py

[Marcus Müller]

Hi Sonny,

that's why I explicitly asked you to confirm you didn't have multiple
versions installed before we went down the detailed backtrace route...

Ah well, I'm happy it's sorted out now :)

Cheers,

Marcus


On 31.01.2017 17:59, Sonny Rajagopalan wrote:
> Thanks, Kevin!
>
> I think that was the issue. I had, in my early days of learning about
> SDR, installed another version of gnuradio. Also, I was not calling
> the pybombs-installed gnuradio correctly. Instead of 
>
> $ pybombs run gnuradio-companion
>
> I was calling it like so:
>
> $ gnuradio-companion
>
> That is another error.
>
> I have everything working as expected now (i.e., got the OP flowgraph
> (and more)) working.
>
> I uninstalled all gnuradio-* components (sudo apt-get remove --purge
> libgnuradio*, and maybe more; try apt list --installed  | grep
> gnuradio) installed by Ubuntu's apt-get and then, using pybombs (see
> https://github.com/gnuradio/pybombs), rebuilt gnuradio and added the
> necessary recipes.
>
> So, here's what I did:
>
> $ apt list --installed  | grep gnuradio
> $ sudo apt-get remove --purge libgnuradio* # again, do the above and
> this line for everything else you may have installed using apt-get,
> e.g., rtl-sdr, osmosdr etc.
> $ pybombs -vv rebuild gnuradio
> $ pybombs recipes add gr-recipes
> git+https://github.com/gnuradio/gr-recipes.git # may not be needed,
> but redid anyway.
> $ pybombs recipes add gr-etcetera
> git+https://github.com/gnuradio/gr-etcetera.git # may not be needed,
> but redid anyway.
> $ pybombs install gr-osmosdr
>
> Marcus, thanks for your on the matter! I hope this helps someone.
>
>
> On Mon, Jan 30, 2017 at 7:50 PM, Kevin Reid  > wrote:
>
> On Mon, Jan 30, 2017 at 11:12 AM, Sonny Rajagopalan
> >
> wrote:
>
> RuntimeError: list contains invalid format!
>
>  
> FWIW, I've seen this error before, and if I remember correctly
> it's a symptom of multiple versions installed (such that the GR
> Python code is not the same version as the GR native code).
>
>
>
>
> ___
> 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] RunTime error in runtime_swig.py

[Sonny Rajagopalan]

Thanks, Kevin!

I think that was the issue. I had, in my early days of learning about SDR,
installed another version of gnuradio. Also, I was not calling the
pybombs-installed gnuradio correctly. Instead of

$ pybombs run gnuradio-companion

I was calling it like so:

$ gnuradio-companion

That is another error.

I have everything working as expected now (i.e., got the OP flowgraph (and
more)) working.

I uninstalled all gnuradio-* components (sudo apt-get remove --purge
libgnuradio*, and maybe more; try apt list --installed  | grep gnuradio)
installed by Ubuntu's apt-get and then, using pybombs (see
https://github.com/gnuradio/pybombs), rebuilt gnuradio and added the
necessary recipes.

So, here's what I did:

$ apt list --installed  | grep gnuradio
$ sudo apt-get remove --purge libgnuradio* # again, do the above and this
line for everything else you may have installed using apt-get, e.g.,
rtl-sdr, osmosdr etc.
$ pybombs -vv rebuild gnuradio
$ pybombs recipes add gr-recipes git+
https://github.com/gnuradio/gr-recipes.git # may not be needed, but redid
anyway.
$ pybombs recipes add gr-etcetera git+
https://github.com/gnuradio/gr-etcetera.git # may not be needed, but redid
anyway.
$ pybombs install gr-osmosdr

Marcus, thanks for your on the matter! I hope this helps someone.


On Mon, Jan 30, 2017 at 7:50 PM, Kevin Reid  wrote:

> On Mon, Jan 30, 2017 at 11:12 AM, Sonny Rajagopalan <
> sonny.rajagopa...@gmail.com> wrote:
>
>> RuntimeError: list contains invalid format!
>>
>
> FWIW, I've seen this error before, and if I remember correctly it's a
> symptom of multiple versions installed (such that the GR Python code is not
> the same version as the GR native code).
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Kevin Reid]

On Mon, Jan 30, 2017 at 11:12 AM, Sonny Rajagopalan <
sonny.rajagopa...@gmail.com> wrote:

> RuntimeError: list contains invalid format!
>

FWIW, I've seen this error before, and if I remember correctly it's a
symptom of multiple versions installed (such that the GR Python code is not
the same version as the GR native code).
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Cinaed Simson]

Try the enclosed Qt version of your HelloWorld.grc:

  HackRFHelloWorld-Qt.grc

But before you do, press the small blue button on the far left hand side
of the HackRF - it's the reset button.

After you hit the reset button, there should be 2 green, 1 orange, and 1
red LED lit.

If a red dot shows up on your gnuradio companion, press it.

I can generate your libUSB error and HackRF errors by running two
instances of HelloWorld at the same time - but I don't get the runtime
error so it may not be the source of your error.


-- Cinaed


On 01/30/2017 01:57 PM, Sonny Rajagopalan wrote:
> Hi Marcus, this information I included in the original email, but here
> it is again:
> 
> $ gnuradio-config-info -v
> v3.7.10.1-182-g59136936
> 
> I used PyBOMBS to install gqrx, gnuradio and gr-osmosdr. I have updated
> and removed it so many times, so I wouldn't be surprised if I messed
> something up...
> 
> On Mon, Jan 30, 2017 at 4:54 PM, Marcus Müller  > wrote:
> 
> so, I know it's a bit late to ask that, but how did you install
> gr-osmosdr and GNU Radio? Is this your only GNU Radio installation?
> Did you perhaps update it underway?
> 
> If that's not the case, could you send us what `gnuradio-config-info
> -v` says?
> 
> Best regards,
> 
> Marcus
> 
> 
> On 01/30/2017 10:11 PM, Sonny Rajagopalan wrote:
>> Attached.
>>
>> On Mon, Jan 30, 2017 at 4:10 PM, Marcus Müller
>> > wrote:
>>
>> Huh. Can you share your top_block.py with us?
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 01/30/2017 10:00 PM, Sonny Rajagopalan wrote:
>>> Hi Marcus,
>>>
>>> Appreciate your time with this. This output was observed when
>>> I followed your instructions:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_3.11.0.git-59-g52ca2e0b
>>>
>>> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
>>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri
>>> hackrf bladerf rfspace airspy soapy redpitaya 
>>> Number of USB devices: 13
>>> USB device 1d50:6089: 909864c82c3a2fcf match
>>> Using HackRF One with firmware 2015.07.2 
>>> Traceback (most recent call last):
>>>   File "./top_block.py", line 73, in 
>>> main()
>>>   File "./top_block.py", line 63, in main
>>> tb.start()
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
>>> line 109, in start
>>> top_block_start_unlocked(self._impl, max_noutput_items)
>>>   File
>>> 
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
>>> line 4879, in top_block_start_unlocked
>>> return _runtime_swig.top_block_start_unlocked(*args,
>>> **kwargs)
>>> RuntimeError: list contains invalid format!
>>>
>>>
>>> The following flow graph was used for this:
>>>
>>> Inline image 1
>>>
>>> On Mon, Jan 30, 2017 at 2:48 PM, Marcus Müller
>>> >
>>> wrote:
>>>
>>> Hi Sonny,
>>>
>>> please always make sure to reply to the list!
>>>
>>> Ah, shoot, it backtraces the wrong thread :/ I can help
>>> you get a proper backtrace, but maybe we'll just take it
>>> the other way around:
>>>
>>> Can you please make a clean, new flowgraph, use the
>>> osmocom source. Connect it to a null sink instead of
>>> WXGui and use "No GUI" and "run to completion" in the
>>> block options.
>>>
>>> Does it work now?
>>>
>>> The error you see is emitted by pmt.cc , line 1469 in my
>>> version of GNU Radio. The only case where I saw that
>>> exception ever been thrown myself is when I intentionally
>>> broke message passing by changing message port names.
>>> That is really unlikely to happen normally, so I wonder
>>> where that comes from.
>>>
>>> Right now, my best guess is WX GUI, and that's what I'd
>>> like to rule out. By the way, you should be able to
>>> replace WXGUI with Qt GUI practically everywhere – we're
>>> planning to discard WXGUI completely with the next GNU
>>> Radio release.
>>>
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>>
>>> On 01/30/2017 08:37 PM, Sonny Rajagopalan wrote:
 Here's what I got:

 GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
 Copyright (C) 2014 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Sonny Rajagopalan]

Attached.

On Mon, Jan 30, 2017 at 4:10 PM, Marcus Müller 
wrote:

> Huh. Can you share your top_block.py with us?
>
> Best regards,
>
> Marcus
>
> On 01/30/2017 10:00 PM, Sonny Rajagopalan wrote:
>
> Hi Marcus,
>
> Appreciate your time with this. This output was observed when I followed
> your instructions:
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b
>
> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy soapy redpitaya
> Number of USB devices: 13
> USB device 1d50:6089: 909864c82c3a2fcf match
> Using HackRF One with firmware 2015.07.2
> Traceback (most recent call last):
>   File "./top_block.py", line 73, in 
> main()
>   File "./top_block.py", line 63, in main
> tb.start()
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 109, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
> line 4879, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
> RuntimeError: list contains invalid format!
>
>
> The following flow graph was used for this:
>
> [image: Inline image 1]
>
> On Mon, Jan 30, 2017 at 2:48 PM, Marcus Müller 
> wrote:
>
>> Hi Sonny,
>>
>> please always make sure to reply to the list!
>>
>> Ah, shoot, it backtraces the wrong thread :/ I can help you get a proper
>> backtrace, but maybe we'll just take it the other way around:
>>
>> Can you please make a clean, new flowgraph, use the osmocom source.
>> Connect it to a null sink instead of WXGui and use "No GUI" and "run to
>> completion" in the block options.
>>
>> Does it work now?
>>
>> The error you see is emitted by pmt.cc , line 1469 in my version of GNU
>> Radio. The only case where I saw that exception ever been thrown myself is
>> when I intentionally broke message passing by changing message port names.
>> That is really unlikely to happen normally, so I wonder where that comes
>> from.
>>
>> Right now, my best guess is WX GUI, and that's what I'd like to rule out.
>> By the way, you should be able to replace WXGUI with Qt GUI practically
>> everywhere – we're planning to discard WXGUI completely with the next GNU
>> Radio release.
>>
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 01/30/2017 08:37 PM, Sonny Rajagopalan wrote:
>>
>> Here's what I got:
>>
>> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later > tml>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from python2.7...Reading symbols from
>> /usr/lib/debug//usr/bin/python2.7...done.
>> done.
>> Starting program: /usr/bin/python2.7 ./top_block.py
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthre
>> ad_db.so.1".
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b
>>
>> [New Thread 0x7fffd6481700 (LWP 15978)]
>> [New Thread 0x7fffd5c80700 (LWP 15979)]
>> [New Thread 0x7fffd4eb7700 (LWP 15980)]
>> [New Thread 0x7fffc5124700 (LWP 15981)]
>> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
>> bladerf rfspace airspy soapy redpitaya
>> [New Thread 0x7fffb700 (LWP 15982)]
>> [Thread 0x7fffb700 (LWP 15982) exited]
>> [New Thread 0x7fffb700 (LWP 15983)]
>> [Thread 0x7fffb700 (LWP 15983) exited]
>> [New Thread 0x7fffb700 (LWP 15984)]
>> [New Thread 0x7fffbf7fe700 (LWP 15985)]
>> [Thread 0x7fffbf7fe700 (LWP 15985) exited]
>> [Thread 0x7fffb700 (LWP 15984) exited]
>> [New Thread 0x7fffb700 (LWP 15986)]
>> [New Thread 0x7fffbf7fe700 (LWP 15987)]
>> [Thread 0x7fffbf7fe700 (LWP 15987) exited]
>> [Thread 0x7fffb700 (LWP 15986) exited]
>> [New Thread 0x7fffb700 (LWP 15988)]
>> [New Thread 0x7fffbf7fe700 (LWP 15989)]
>> [Thread 0x7fffbf7fe700 (LWP 15989) exited]
>> [Thread 0x7fffb700 (LWP 15988) exited]
>> [New Thread 0x7fffb700 (LWP 15990)]
>> [Thread 0x7fffb700 (LWP 15990) exited]
>> [New Thread 0x7fffb700 (LWP 15991)]
>> [Thread 0x7fffb700 (LWP 15991) exited]
>> [New Thread 0x7fffb700 (LWP 15992)]
>> [Thread 

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Marcus Müller]

Huh. Can you share your top_block.py with us?

Best regards,

Marcus


On 01/30/2017 10:00 PM, Sonny Rajagopalan wrote:
> Hi Marcus,
>
> Appreciate your time with this. This output was observed when I
> followed your instructions:
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b
>
> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy soapy redpitaya 
> Number of USB devices: 13
> USB device 1d50:6089: 909864c82c3a2fcf match
> Using HackRF One with firmware 2015.07.2 
> Traceback (most recent call last):
>   File "./top_block.py", line 73, in 
> main()
>   File "./top_block.py", line 63, in main
> tb.start()
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 109, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
> line 4879, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
> RuntimeError: list contains invalid format!
>
>
> The following flow graph was used for this:
>
> Inline image 1
>
> On Mon, Jan 30, 2017 at 2:48 PM, Marcus Müller
> > wrote:
>
> Hi Sonny,
>
> please always make sure to reply to the list!
>
> Ah, shoot, it backtraces the wrong thread :/ I can help you get a
> proper backtrace, but maybe we'll just take it the other way around:
>
> Can you please make a clean, new flowgraph, use the osmocom
> source. Connect it to a null sink instead of WXGui and use "No
> GUI" and "run to completion" in the block options.
>
> Does it work now?
>
> The error you see is emitted by pmt.cc , line 1469 in my version
> of GNU Radio. The only case where I saw that exception ever been
> thrown myself is when I intentionally broke message passing by
> changing message port names. That is really unlikely to happen
> normally, so I wonder where that comes from.
>
> Right now, my best guess is WX GUI, and that's what I'd like to
> rule out. By the way, you should be able to replace WXGUI with Qt
> GUI practically everywhere – we're planning to discard WXGUI
> completely with the next GNU Radio release.
>
>
> Best regards,
>
> Marcus
>
>
> On 01/30/2017 08:37 PM, Sonny Rajagopalan wrote:
>> Here's what I got:
>>
>> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> >
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> > >.
>> Find the GDB manual and other documentation resources online at:
>> > >.
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from python2.7...Reading symbols from
>> /usr/lib/debug//usr/bin/python2.7...done.
>> done.
>> Starting program: /usr/bin/python2.7 ./top_block.py
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library
>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_3.11.0.git-59-g52ca2e0b
>>
>> [New Thread 0x7fffd6481700 (LWP 15978)]
>> [New Thread 0x7fffd5c80700 (LWP 15979)]
>> [New Thread 0x7fffd4eb7700 (LWP 15980)]
>> [New Thread 0x7fffc5124700 (LWP 15981)]
>> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri
>> hackrf bladerf rfspace airspy soapy redpitaya 
>> [New Thread 0x7fffb700 (LWP 15982)]
>> [Thread 0x7fffb700 (LWP 15982) exited]
>> [New Thread 0x7fffb700 (LWP 15983)]
>> [Thread 0x7fffb700 (LWP 15983) exited]
>> [New Thread 0x7fffb700 (LWP 15984)]
>> [New Thread 0x7fffbf7fe700 (LWP 15985)]
>> [Thread 0x7fffbf7fe700 (LWP 15985) exited]
>> [Thread 0x7fffb700 (LWP 15984) exited]
>> [New Thread 0x7fffb700 (LWP 15986)]
>> [New Thread 0x7fffbf7fe700 (LWP 15987)]
>> [Thread 0x7fffbf7fe700 (LWP 15987) exited]
>> [Thread 0x7fffb700 (LWP 15986) exited]
>> [New Thread 0x7fffb700 (LWP 15988)]
>> [New Thread 0x7fffbf7fe700 (LWP 15989)]
>> [Thread 0x7fffbf7fe700 

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Sonny Rajagopalan]

Hi Marcus,

Appreciate your time with this. This output was observed when I followed
your instructions:

linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy soapy redpitaya
Number of USB devices: 13
USB device 1d50:6089: 909864c82c3a2fcf match
Using HackRF One with firmware 2015.07.2
Traceback (most recent call last):
  File "./top_block.py", line 73, in 
main()
  File "./top_block.py", line 63, in main
tb.start()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
line 109, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
4879, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: list contains invalid format!


The following flow graph was used for this:

[image: Inline image 1]

On Mon, Jan 30, 2017 at 2:48 PM, Marcus Müller 
wrote:

> Hi Sonny,
>
> please always make sure to reply to the list!
>
> Ah, shoot, it backtraces the wrong thread :/ I can help you get a proper
> backtrace, but maybe we'll just take it the other way around:
>
> Can you please make a clean, new flowgraph, use the osmocom source.
> Connect it to a null sink instead of WXGui and use "No GUI" and "run to
> completion" in the block options.
>
> Does it work now?
>
> The error you see is emitted by pmt.cc , line 1469 in my version of GNU
> Radio. The only case where I saw that exception ever been thrown myself is
> when I intentionally broke message passing by changing message port names.
> That is really unlikely to happen normally, so I wonder where that comes
> from.
>
> Right now, my best guess is WX GUI, and that's what I'd like to rule out.
> By the way, you should be able to replace WXGUI with Qt GUI practically
> everywhere – we're planning to discard WXGUI completely with the next GNU
> Radio release.
>
>
> Best regards,
>
> Marcus
>
>
> On 01/30/2017 08:37 PM, Sonny Rajagopalan wrote:
>
> Here's what I got:
>
> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from python2.7...Reading symbols from
> /usr/lib/debug//usr/bin/python2.7...done.
> done.
> Starting program: /usr/bin/python2.7 ./top_block.py
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b
>
> [New Thread 0x7fffd6481700 (LWP 15978)]
> [New Thread 0x7fffd5c80700 (LWP 15979)]
> [New Thread 0x7fffd4eb7700 (LWP 15980)]
> [New Thread 0x7fffc5124700 (LWP 15981)]
> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy soapy redpitaya
> [New Thread 0x7fffb700 (LWP 15982)]
> [Thread 0x7fffb700 (LWP 15982) exited]
> [New Thread 0x7fffb700 (LWP 15983)]
> [Thread 0x7fffb700 (LWP 15983) exited]
> [New Thread 0x7fffb700 (LWP 15984)]
> [New Thread 0x7fffbf7fe700 (LWP 15985)]
> [Thread 0x7fffbf7fe700 (LWP 15985) exited]
> [Thread 0x7fffb700 (LWP 15984) exited]
> [New Thread 0x7fffb700 (LWP 15986)]
> [New Thread 0x7fffbf7fe700 (LWP 15987)]
> [Thread 0x7fffbf7fe700 (LWP 15987) exited]
> [Thread 0x7fffb700 (LWP 15986) exited]
> [New Thread 0x7fffb700 (LWP 15988)]
> [New Thread 0x7fffbf7fe700 (LWP 15989)]
> [Thread 0x7fffbf7fe700 (LWP 15989) exited]
> [Thread 0x7fffb700 (LWP 15988) exited]
> [New Thread 0x7fffb700 (LWP 15990)]
> [Thread 0x7fffb700 (LWP 15990) exited]
> [New Thread 0x7fffb700 (LWP 15991)]
> [Thread 0x7fffb700 (LWP 15991) exited]
> [New Thread 0x7fffb700 (LWP 15992)]
> [Thread 0x7fffb700 (LWP 15992) exited]
> [New Thread 0x7fffb700 (LWP 15993)]
> [Thread 0x7fffb700 (LWP 15993) exited]
> [New Thread 0x7fffb700 (LWP 15994)]
> Number of USB devices: 13
> USB device 1d50:6089: 909864c82c3a2fcf match
> Using HackRF One with firmware 2015.07.2
> [New Thread 0x7fffbf7fe700 (LWP 15995)]
> Traceback (most recent call last):
>   File 

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Marcus Müller]

Hi Sonny,

please always make sure to reply to the list!

Ah, shoot, it backtraces the wrong thread :/ I can help you get a proper
backtrace, but maybe we'll just take it the other way around:

Can you please make a clean, new flowgraph, use the osmocom source.
Connect it to a null sink instead of WXGui and use "No GUI" and "run to
completion" in the block options.

Does it work now?

The error you see is emitted by pmt.cc , line 1469 in my version of GNU
Radio. The only case where I saw that exception ever been thrown myself
is when I intentionally broke message passing by changing message port
names. That is really unlikely to happen normally, so I wonder where
that comes from.

Right now, my best guess is WX GUI, and that's what I'd like to rule
out. By the way, you should be able to replace WXGUI with Qt GUI
practically everywhere – we're planning to discard WXGUI completely with
the next GNU Radio release.


Best regards,

Marcus


On 01/30/2017 08:37 PM, Sonny Rajagopalan wrote:
> Here's what I got:
>
> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from python2.7...Reading symbols from
> /usr/lib/debug//usr/bin/python2.7...done.
> done.
> Starting program: /usr/bin/python2.7 ./top_block.py
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b
>
> [New Thread 0x7fffd6481700 (LWP 15978)]
> [New Thread 0x7fffd5c80700 (LWP 15979)]
> [New Thread 0x7fffd4eb7700 (LWP 15980)]
> [New Thread 0x7fffc5124700 (LWP 15981)]
> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy soapy redpitaya 
> [New Thread 0x7fffb700 (LWP 15982)]
> [Thread 0x7fffb700 (LWP 15982) exited]
> [New Thread 0x7fffb700 (LWP 15983)]
> [Thread 0x7fffb700 (LWP 15983) exited]
> [New Thread 0x7fffb700 (LWP 15984)]
> [New Thread 0x7fffbf7fe700 (LWP 15985)]
> [Thread 0x7fffbf7fe700 (LWP 15985) exited]
> [Thread 0x7fffb700 (LWP 15984) exited]
> [New Thread 0x7fffb700 (LWP 15986)]
> [New Thread 0x7fffbf7fe700 (LWP 15987)]
> [Thread 0x7fffbf7fe700 (LWP 15987) exited]
> [Thread 0x7fffb700 (LWP 15986) exited]
> [New Thread 0x7fffb700 (LWP 15988)]
> [New Thread 0x7fffbf7fe700 (LWP 15989)]
> [Thread 0x7fffbf7fe700 (LWP 15989) exited]
> [Thread 0x7fffb700 (LWP 15988) exited]
> [New Thread 0x7fffb700 (LWP 15990)]
> [Thread 0x7fffb700 (LWP 15990) exited]
> [New Thread 0x7fffb700 (LWP 15991)]
> [Thread 0x7fffb700 (LWP 15991) exited]
> [New Thread 0x7fffb700 (LWP 15992)]
> [Thread 0x7fffb700 (LWP 15992) exited]
> [New Thread 0x7fffb700 (LWP 15993)]
> [Thread 0x7fffb700 (LWP 15993) exited]
> [New Thread 0x7fffb700 (LWP 15994)]
> Number of USB devices: 13
> USB device 1d50:6089: 909864c82c3a2fcf match
> Using HackRF One with firmware 2015.07.2 
> [New Thread 0x7fffbf7fe700 (LWP 15995)]
> Traceback (most recent call last):
>   File "./top_block.py", line 100, in 
> main()
>   File "./top_block.py", line 95, in main
> tb.Start(True)
>   File
> "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py",
> line 74, in Start
> self.start()
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 109, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
> line 4879, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
> RuntimeError: list contains invalid format!
> 

Re: [Discuss-gnuradio] RunTime error in runtime_swig.py

[Marcus Müller]

Hi Sonny,

that's unusual. Can you run

gdb -ex run -ex bt --args python2
'/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py'

and copy & paste the output backtrace? Ideally, we'd see *exactly* what
crashes where.

Best regards,

Marcus

On 01/30/2017 08:12 PM, Sonny Rajagopalan wrote:
> Hello,
>
> I have a simple flow graph as shown (from this video tutorial
> http://greatscottgadgets.com/sdr/1/):
>
> Inline image 1
>
> The *.py that is created is attached. The code crashes with the
> following error:
>
> Generating:
> '/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py'
>
> Generating:
> '/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py'
>
> Executing: /usr/bin/python2 -u
> /mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b
>
> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy soapy redpitaya 
> Number of USB devices: 13
> USB device 1d50:6089: 909864c82c3a2fcf match
> Using HackRF One with firmware 2015.07.2 
> Traceback (most recent call last):
>   File
> "/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py", line
> 100, in 
> main()
>   File
> "/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py", line
> 95, in main
> tb.Start(True)
>   File
> "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py",
> line 74, in Start
> self.start()
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 109, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
> line 4879, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
> RuntimeError: list contains invalid format!
>
>
> Gnuradio version: v3.7.10.1-182-g59136936, built using PyBOMBS;
> python2.7 and 3.4 on system. I know Cinaed said this is operator
> error, but some pointers for how to fixing this is appreciated.
>
> Any insights into how this can be fixed is appreciated. I raised this
> issue with the HackRF people and they say it is better asked here.
>
> Thanks,
> Sonny.
>
>
> ___
> 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

[Discuss-gnuradio] RunTime error in runtime_swig.py

[Sonny Rajagopalan]

Hello,

I have a simple flow graph as shown (from this video tutorial
http://greatscottgadgets.com/sdr/1/):

[image: Inline image 1]

The *.py that is created is attached. The code crashes with the following
error:

Generating: '/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py'

Generating: '/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py'

Executing: /usr/bin/python2 -u
/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py

linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-59-g52ca2e0b

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy soapy redpitaya
Number of USB devices: 13
USB device 1d50:6089: 909864c82c3a2fcf match
Using HackRF One with firmware 2015.07.2
Traceback (most recent call last):
  File "/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py",
line 100, in 
main()
  File "/mymachine/sdr/gnuradioProjects/flowGraphsFromGRC/top_block.py",
line 95, in main
tb.Start(True)
  File
"/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py",
line 74, in Start
self.start()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
line 109, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
4879, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: list contains invalid format!


Gnuradio version: v3.7.10.1-182-g59136936, built using PyBOMBS; python2.7
and 3.4 on system. I know Cinaed said this is operator error, but some
pointers for how to fixing this is appreciated.

Any insights into how this can be fixed is appreciated. I raised this issue
with the HackRF people and they say it is better asked here.

Thanks,
Sonny.


HackRFHelloWorld.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Runtime error on Mac OSX 10.7

[Michael Dickens]

Hi Matthew - Hmm ... well, testing on 10.7 will be tricky for debugging
purposes. It looks like you installed GR via MacPorts ... yes? This
looks like the same issue as < https://trac.macports.org/ticket/53236[1]
>, yes?  OK; I'm working on fixing this; hopefully this afternoon.
Cheers! - MLD


On Sat, Jan 7, 2017, at 04:06 AM, Matthew Chambers wrote:

> I get the following error when I try to run anything that uses
> gnuradio, such as gqrx, gnuradio-companion or uhd_rx_nogui.
> 

> $ uhd_rx_nogui 

> Traceback (most recent call last):

>   File "/opt/local/bin/uhd_rx_nogui", line 23, in 

> from gnuradio import gr, gru, uhd, audio

>   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/l-
>   ib/python2.7/site-packages/gnuradio/gr/__init__.py", line 56, in
>   
> log.add_console_appender(log_file, " gr::log %d :%p: %m%n")

>   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/l-
>   ib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line 6987,
>   in add_console_appender
> return _runtime_swig.logger_add_console_appender(self, target,
> pattern)
> RuntimeError: unterminated conversion specifier in ' gr::log %d :%p:
> %m%n' at index -1
> 

> I've looked at source code and not knowing python, I'm really don't
> know how to proceed. (I'm a C++/C# guy)
> 

> in runtime_swig.py, 

> 6985 def add_console_appender(self, target, pattern):

> 6986 """add_console_appender(logger self, std::string target,
> std::string pattern)"""
> 6987 return _runtime_swig.logger_add_console_appender(self,
> target, pattern)
> 6988 

> 6989 

> 6990 def add_file_appender(self, filename, append, pattern):

> 6991 """add_file_appender(logger self, std::string filename,
> bool append, std::string pattern)"""
> 6992 return _runtime_swig.logger_add_file_appender(self,
> filename, append, pattern)
> 

> and back one call, in __init__.py

> 49 # Force the preference database to be initialized

> 50 prefs = prefs.singleton

> 51 

> 52 log = gr.logger("log")

> 53 log.set_level(prefs().get_string("LOG", "log_level", "notset"))

> 54 log_file = gr.prefs().get_string("LOG", "log_file", "");

> 55 if(log_file == "stderr" or log_file == "stdout"):

> 56 log.add_console_appender(log_file, "gr::log %d :%p: %m%n")

> 57 else:

> 58 log.add_file_appender(log_file, True, "%r :%p: %c{1} - %m%n")

> 59  

> 60 log_debug = gr.logger("log_debug")

> 61 log_debug.set_level(prefs().get_string("LOG", "debug_level",
> "notset"))
> 62 log_debug_file = gr.prefs().get_string("LOG", "debug_file", "");

> 63 if(log_debug_file == "stderr" or log_file == "stdout"):

> 64 log_debug.add_console_appender(log_debug_file, "gr::log %d
> :%p: %m%n")
> 65 else:

> 66 log_debug.add_file_appender(log_debug_file, True, "%r :%p:
> %c{1} - %m%n")
> 67 




Links:

  1. https://trac.macports.org/ticket/53236#comment:1
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Runtime error on Mac OSX 10.7

[Matthew Chambers]

I get the following error when I try to run anything that uses gnuradio,
such as gqrx, gnuradio-companion or uhd_rx_nogui.

$ uhd_rx_nogui
Traceback (most recent call last):
  File "/opt/local/bin/uhd_rx_nogui", line 23, in 
from gnuradio import gr, gru, uhd, audio
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/gr/__init__.py",
line 56, in 
log.add_console_appender(log_file, " gr::log %d :%p: %m%n")
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py",
line 6987, in add_console_appender
return _runtime_swig.logger_add_console_appender(self, target, pattern)
RuntimeError: unterminated conversion specifier in ' gr::log %d :%p: %m%n'
at index -1

I've looked at source code and not knowing python, I'm really don't know
how to proceed. (I'm a C++/C# guy)

in runtime_swig.py,
6985 def add_console_appender(self, target, pattern):
6986 """add_console_appender(logger self, std::string target,
std::string pattern)"""
6987 return _runtime_swig.logger_add_console_appender(self, target,
pattern)
6988
6989
6990 def add_file_appender(self, filename, append, pattern):
6991 """add_file_appender(logger self, std::string filename, bool
append, std::string pattern)"""
6992 return _runtime_swig.logger_add_file_appender(self, filename,
append, pattern)

and back one call, in __init__.py
49 # Force the preference database to be initialized
50 prefs = prefs.singleton
51
52 log = gr.logger("log")
53 log.set_level(prefs().get_string("LOG", "log_level", "notset"))
54 log_file = gr.prefs().get_string("LOG", "log_file", "");
55 if(log_file == "stderr" or log_file == "stdout"):
56 log.add_console_appender(log_file, "gr::log %d :%p: %m%n")
57 else:
58 log.add_file_appender(log_file, True, "%r :%p: %c{1} - %m%n")
59
60 log_debug = gr.logger("log_debug")
61 log_debug.set_level(prefs().get_string("LOG", "debug_level", "notset"))
62 log_debug_file = gr.prefs().get_string("LOG", "debug_file", "");
63 if(log_debug_file == "stderr" or log_file == "stdout"):
64 log_debug.add_console_appender(log_debug_file, "gr::log %d :%p:
%m%n")
65 else:
66 log_debug.add_file_appender(log_debug_file, True, "%r :%p: %c{1} -
%m%n")
67

Thanks

Matthew A. Chambers, NR0Q
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Runtime error - Empty Device Address in GRC Flowgraph build

[Mark]

Hello,

After installing GRC into Ubuntu 15.05 64bit I get the following error when 
trying to run a GRC flow graph example:-

---

RuntimeError: LookupError: KeyError: No devices found for -
Empty Device Address

---


A uhd_find_device command successfully returns the serial number from my USRP 
B100 in TERMINAL. However, as I say, the flowgraph wont build as it doesn’t 
appear to be able to locate my USRP B100 via its USB connection.

uhd_images_downloader.py successfully runs and running uhd-usrp.rules to 
moves rule file to /etc/udev/rules.d/ carries out ok too.

However, again, I'm still unable to build a successful GRC flowgraph with my 
B100.

I leave the device address empty in the GRC UHD USRP Source block but again, 
GRC wont build the flowgraph and returns the above error message.

Please help as I've spent days trying to get GRC to install and operate 
successfully.

Many thanks in advance,

Mark

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

Re: [Discuss-gnuradio] Runtime error - Empty Device Address in GRC Flowgraph build

[Marcus D. Leech]

On 08/15/2015 06:58 AM, Mark wrote:

Hello,

After installing GRC into Ubuntu 15.05 64bit I get the following error when 
trying to run a GRC flow graph example:-

---

RuntimeError: LookupError: KeyError: No devices found for -
Empty Device Address

---


A uhd_find_device command successfully returns the serial number from my USRP 
B100 in TERMINAL. However, as I say, the flowgraph wont build as it doesn’t 
appear to be able to locate my USRP B100 via its USB connection.

uhd_images_downloader.py successfully runs and running uhd-usrp.rules to 
moves rule file to /etc/udev/rules.d/ carries out ok too.

However, again, I'm still unable to build a successful GRC flowgraph with my 
B100.

I leave the device address empty in the GRC UHD USRP Source block but again, 
GRC wont build the flowgraph and returns the above error message.

Please help as I've spent days trying to get GRC to install and operate 
successfully.

Many thanks in advance,

Mark

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

Have you tried just putting a device address in?

use:

type=b100

in the device address field in your flow-graph



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

Re: [Discuss-gnuradio] Runtime error - Empty Device Address in GRC Flowgraph build

[Marcus Müller]

When running uhd_find_devices, do you happen to use sudo?


On 08/15/2015 07:30 PM, Marcus D. Leech wrote:
 On 08/15/2015 06:58 AM, Mark wrote:
 Hello,

 After installing GRC into Ubuntu 15.05 64bit I get the following
 error when trying to run a GRC flow graph example:-

 ---


 RuntimeError: LookupError: KeyError: No devices found for -
 Empty Device Address

 ---



 A uhd_find_device command successfully returns the serial number from
 my USRP B100 in TERMINAL. However, as I say, the flowgraph wont build
 as it doesn’t appear to be able to locate my USRP B100 via its USB
 connection.

 uhd_images_downloader.py successfully runs and running
 uhd-usrp.rules to moves rule file to /etc/udev/rules.d/ carries out
 ok too.

 However, again, I'm still unable to build a successful GRC flowgraph
 with my B100.

 I leave the device address empty in the GRC UHD USRP Source block but
 again, GRC wont build the flowgraph and returns the above error message.

 Please help as I've spent days trying to get GRC to install and
 operate successfully.

 Many thanks in advance,

 Mark

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 Have you tried just putting a device address in?

 use:

 type=b100

 in the device address field in your flow-graph



 ___
 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

[Discuss-gnuradio] Runtime Error

[Sohaib Khan]

I am using DVB-T dongle RTLSDR2832U with gnu radio, i have installed all the 
required files, but when i compile my flowgraph I get an error.
Runtime Error:Failed to open rtlsdr device.
What is the problem and its solution??

Sohaib bin Altaf
pakistan

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

Re: [Discuss-gnuradio] Runtime Error

[Marcus Müller]

Hello Sohaib,
from http://sdr.osmocom.org/trac/wiki/rtl-sdr:

If the device can't be opened, make sure you have the appropriate rights 
to access the device (install udev-rules from the repository, or run it 
as root).



The osmo project has for your conveniences generated a rule that assigns 
correct access rights to your device as soon as you plug it in.  So in 
your rtl-sdr build folder, run


sudo make install-udev-rules

to install them.

Hopefully that fixed your problem,
Greetings,

Marcus M



I am using DVB-T dongle RTLSDR2832U with gnu radio, i have installed all the 
required files, but when i compile my flowgraph I get an error.
Runtime Error:Failed to open rtlsdr device.
What is the problem and its solution??

Sohaib bin Altaf
pakistan

___
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

[Discuss-gnuradio] Runtime error from boost 1.52 issue on OSX

[Michael McCoy]

I'm writing to describe an issue, and to provide a workaround, related to
gnuradio with boost 1.52.

I built the current gnuradio repo from source on Mac OSX 10.6.8 (satisfied
dependencies using MacPorts).  The build went fine, but only 21% of the
tests were passed with make test.  The error was always the same (here
the verbose output is for qa_max):

46:   File
/Users/mccoy/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_max.py,
line 69, in module
46: gr_unittest.run(test_max, test_max.xml)
[... more tracebacks...]
46:   File
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/suite.py,
line 93, in run
46: for test in self:
46: *RuntimeError: boost thread: thread not joinable: Invalid argument*
*
*
The workaround: Downgrade to boost 1.51.  All tests passed after the
downgrade (except for one, unrelated to this issue).

Instructions to use macports to get old ports are available here:
https://trac.macports.org/wiki/howto/InstallingOlderPort

Note: I tried both python 2.6 and 2.7, since it appears, on its face, to be
a python error.  The output above comes from python 2.7.  Python 2.6 failed
even more frequently.

Regards,
-Mike
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Runtime error from boost 1.52 issue on OSX

[Michael Dickens]

Hi Michael - Quite interesting.  I wonder if the Boost folks know about this 
issue; I doubt it was introduced by MacPorts since mostly they just replicate 
the project's functionality.  I had seen some issues recently, and had wondered 
about them; I'll definitely check into this.  Thanks! - MLD

On Dec 29, 2012, at 1:47 PM, Michael McCoy michael.b.mc...@gmail.com wrote:

 I'm writing to describe an issue, and to provide a workaround, related to 
 gnuradio with boost 1.52.  
 
 I built the current gnuradio repo from source on Mac OSX 10.6.8 (satisfied 
 dependencies using MacPorts).  The build went fine, but only 21% of the tests 
 were passed with make test.  The error was always the same (here the 
 verbose output is for qa_max):
 
 46:   File 
 /Users/mccoy/gnuradio/gnuradio-core/src/python/gnuradio/gr/qa_max.py, line 
 69, in module
 46: gr_unittest.run(test_max, test_max.xml)
 [... more tracebacks...]
 46:   File 
 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/suite.py,
  line 93, in run
 46: for test in self:
 46: RuntimeError: boost thread: thread not joinable: Invalid argument
 
 The workaround: Downgrade to boost 1.51.  All tests passed after the 
 downgrade (except for one, unrelated to this issue).
 
 Instructions to use macports to get old ports are available here:
 https://trac.macports.org/wiki/howto/InstallingOlderPort
 
 Note: I tried both python 2.6 and 2.7, since it appears, on its face, to be a 
 python error.  The output above comes from python 2.7.  Python 2.6 failed 
 even more frequently. 


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

Re: [Discuss-gnuradio] Runtime error from boost 1.52 issue on OSX

[Michael Dickens]

After a bit of sleuthing, it turns out that this was a general Boost issue, not 
just on OSX, discussed on their email list here  
http://boost.2283326.n4.nabble.com/thread-thread-join-throws-in-1-52-0-td4638380.html
 , in their tickets here  https://svn.boost.org/trac/boost/ticket/7669 , and 
fixed waiting for 1.53 to be released  
https://svn.boost.org/trac/boost/changeset/81667 .  So, we don't want to be 
using Boost 1.52 with GNU Radio.  Any (other) GR developer want to block it in 
the CMake build system? - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Runtime error from boost 1.52 issue on OSX

[Johnathan Corgan]

On Sat, Dec 29, 2012 at 11:22 AM, Michael Dickens m...@alum.mit.edu wrote:


 After a bit of sleuthing, it turns out that this was a general Boost
 issue, not just on OSX, discussed on their email list here 
 http://boost.2283326.n4.nabble.com/thread-thread-join-throws-in-1-52-0-td4638380.html,
  in their tickets here 
 https://svn.boost.org/trac/boost/ticket/7669 , and fixed waiting for
 1.53 to be released  https://svn.boost.org/trac/boost/changeset/81667 .
  So, we don't want to be using Boost 1.52 with GNU Radio.  Any (other) GR
 developer want to block it in the CMake build system? - MLD


I'll take care of this, thanks for checking it out.

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