[Discuss-gnuradio] No module named RPCConnectionThrift

[Rensi Mathew]

 
when Iam working on python simple_copy_controller.py 127.0.0.1 true,

 itshows 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 

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

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

 fromgnuradio.ctrlport.RPCConnectionThrift import RPCConnectionThrift

ImportError:No module named RPCConnectionThrift

How canI correct this error?



RensiSam

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

Re: [Discuss-gnuradio] No module named RPCConnectionThrift

[CEL]

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 +, Rensi Mathew wrote:
> when I am working on python simple_copy_controller.py 127.0.0.1
>  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 
> 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

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

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

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

[Volker Schroer]

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 
     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] Help needed with message ports [success]

[Michael Dickens]

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] MAKING A NTSC TV RECEIVER

[Martin McCormick]

Andres Campos Santana  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] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

[George Rykowski]

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 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 Dickens]

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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Ali Dormiani]

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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Andres Campos Santana]

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 
 en nombre de 
Martin McCormick 
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  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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio