Going from GUI to non-GUI operation.

2019-11-14 Thread Glen I Langston
This email is a question concerning the Gnuradio transition from a GUI interface to purely python execution. We’ve developed a series of gnuradio-companion compatible designs that are "just about" perfected from our point of view. Now we’re going from interactive mode to fully automatic startup

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

2019-11-14 Thread Glen I Langston
Thanks Marcus, Concerning your points, I thought I’d edited the Subject line to start a new thread. I’ll be more careful in the future. Also thanks for your clarification of the source code origin. I’ve also directly contacted the folks at SDRPlay. I do think the SDRPlay folks do want to be

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

2019-11-14 Thread CEL
Hi Glen, On Thu, 2019-11-14 at 09:22 -0500, Glen I Langston wrote: > Thanks Marcus, > > Concerning your points, I thought I’d edited the Subject line to > start a new thread. I’ll be more careful in the future. > no worries – just the danger of hiding your own threads! > Also thanks for your

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

2019-11-14 Thread CEL
Hi Glen, first of all: This email nearly eluded my attention – you replied to a completely different topic, and that means email clients will sort your mail under the "Simulated Time?" thread. Simply don't reply to emails if you don't mean to actually reply. Then: The SDRPlay block isn't part of

Re: Going from GUI to non-GUI operation.

2019-11-14 Thread Amr Bekhit
Hi Glen, In the top right corner of the flow you will see the flow properties box. In there you can disable the GUI. You can then run your python file directly, or even call the created class object from another file (have a look inside the main function to see how the flow is instantiated). You

Re: Going from GUI to non-GUI operation.

2019-11-14 Thread Nick Foster
It's a bit wasteful from a CPU cycles standpoint, but you can run your flowgraph unchanged from the command line using xvfb, and no graphical output will be displayed. Nick On Thu, Nov 14, 2019, 8:53 AM Glen I Langston wrote: > Hi Amr, > > Thanks for your suggestion. > > However when I select

Re: Going from GUI to non-GUI operation.

2019-11-14 Thread Marcus D. Leech
On 11/14/2019 11:52 AM, Glen I Langston wrote: Hi Amr, Thanks for your suggestion. However when I select no-gui, then all the QT blocks go RED in my designs in gnuradio-companion. I was hoping that they would instead just go quiet and use the default values. I can, of course, just delete

Re: Going from GUI to non-GUI operation.

2019-11-14 Thread Nate Temple
Hi Glen, One other possible approach could be to separate your processing flowgraph from the display/GUI flowgraph. This could be done with a combo of ZMQ blocks, the Parameter block and XMLRPC blocks. Depending on your data rates, this might not work so great and is a bit wasteful of CPU

Re: Going from GUI to non-GUI operation.

2019-11-14 Thread Glen I Langston
Hi Amr, Thanks for your suggestion. However when I select no-gui, then all the QT blocks go RED in my designs in gnuradio-companion. I was hoping that they would instead just go quiet and use the default values. I can, of course, just delete all the QT blocks, but then when going back to

Re: Going from GUI to non-GUI operation.

2019-11-14 Thread CEL
Hi Glen, On Thu, 2019-11-14 at 11:52 -0500, Glen I Langston wrote: > Hi Amr, > > Thanks for your suggestion. > > However when I select no-gui, then all the QT blocks go RED in my designs in > gnuradio-companion. > > I was hoping that they would instead just go quiet and use the default values.

[Discuss-gnuradio] Alternative to gr-osmosdr for HackRF source/sink blocks?

2019-11-14 Thread Eamon Heaney
Hi, I'm trying to get my HackRF to do burst transmission. As I understand, this isn't possible in gr 3.7, but is possible in 3.8+. However, I've been using gr-osmosdr blocks for the HackRF source/sink, and that isn't compatible with gr 3.8+ yet. Are there any alternatives out there that are

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

2019-11-14 Thread Chris Vine
On Thu, 14 Nov 2019 14:11:22 + Müller, Marcus (CEL) wrote: > Hi Glen, > > first of all: This email nearly eluded my attention – you replied to a > completely different topic, and that means email clients will sort your > mail under the "Simulated Time?" thread. Simply don't reply to emails >

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

2019-11-14 Thread Chris Vine
On Thu, 14 Nov 2019 19:35:13 + Chris Vine wrote: > The original poster can get some information from installing soapy and > doing 'SoapySDRUtil --probe'. I should probably have appended what the probe tells me about my RSP1A, which may or may not apply to his:

creating a 57 KHz signal from 19 KHz reference

2019-11-14 Thread Kristoff
Hi all, I'm again experimenting with GNUradio, now with a flowgraph I found ("rds_rx") to demodulate FM/RDS. One facts about FM/RDS: After demodulation a FM broadcasting signal, the signal contains multiple sub-signals, (among others) a 19 KHz 'stereo pilot' and a PSK (RDS) signal at 57

problems about Installing multiple versions of gnuradio

2019-11-14 Thread mangrove_forest
I want to install two versions of gnuradio on one machine. I first installed gnuradio 3.7 in default directory /usr/local/(and it works normally), and then installed the gnuradio 3.9 in the directory /opt/gnuradio. But the gnuradio 3.7 can't run again,as follows: $ gnuradio-companion Traceback

Re: [Discuss-gnuradio] Alternative to gr-osmosdr for HackRF source/sink blocks?

2019-11-14 Thread George Vd
Hi, try gr-soapy ( https://gitlab.com/librespacefoundation/gr-soapy/tree/maint-3.8 ) :) The maint-3.8 branch is gnuradio 3.8-compatible Cheers On Thu, Nov 14, 2019 at 10:00 AM Eamon Heaney wrote: > Hi, > > I'm trying to get my HackRF to do burst transmission. As I understand, > this isn't

Re: problems about Installing multiple versions of gnuradio

2019-11-14 Thread CEL
You probably have conflicting configuration about paths in ~/.gnuradio; hard to say, actually. Generally, when installing in separate prefixes, it's no good idea to have both prefixes in LD_LIBRARY_PATH etc at the same time - for any given process, only one should be in there. That's no technical