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 KHz
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:
---
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
>
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 cycles.
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 all
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 n
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.
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 debug
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
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 c
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
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 mo
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
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
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 pos
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
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 compa
17 matches
Mail list logo
