Re: [Discuss-gnuradio] Non Graphical Use of gnuradio Tools

[CEL]

Hi Martin,

arguing that this is unrelated to osmocom, but relevant to GNU Radio:
I'm CC'ing the discuss-gnuradio mailing list [1]; I'll recommend
following up there (and taking osmocom-sdr out of CC: when doing that),
unless someone else sees an argument for keeping this discussion here.

So, GNU Radio as a framework doesn't set any constraints on what the
scheduler and blocks do to stdout; especially, the default logger
writes to stdout, so, no matter how you do it, putting the output onto
stdout doesn't work out; it's a shared resource across all components
in GNU Radio.

> Unix and to a lesser degree, DOS handled input and output
> logic elegantly with <, >, | and even tee when one sends output
> to multiple files and unix just turned 50 this Summer so it's
> doing something right.

Yes, but you can only have graphs that are paths this way. GNU Radio
allows for arbitrary cycle-free graphs. So, this only solves a small
subset. It's a mature solution, but for a much smaller problem space,
i.e. not generally applicable to GNU Radio. You put this very nicely!
You're saying:

> … kind of text-based way to string those python GNU
> modules together

and that's the whole point: Unix shell piping can create *strings* of
processing steps. GNU Radio can do more than that – thus, we never
implemented something different. 

> Is there any kind of text-based way to string those python GNU
> modules together to cause them to work as they do when
> connected using GRC?

I'd argue that GNU Radio's python interface allows you to execute

top_block.connect(source_block, processing_block1, processing_block2,
sink_block)
top_block.run()

so, that's a pretty text-based approach :)

Don't forget that it essentially doesn't matter to your OS whether you
run a bash script or a python script – and in this case, python has the
tools that bash is lacking to create complex flow graphs.

So, what to recommend?

First of all, you don't *have* to use GRC to create your flow graphs.
Many of us do, because it gives you kind of a graphical representation
of the Python program that GRC generates and thus is kind of self-
documenting, but really, just write Python :) You'll find that you can
read the flow graph programs that GRC generates pretty well, and base
your programs on that.

No matter how you set up your GNU Radio flow graph, it's a very valid
use case to want something like

python flowgraph.py | grep "alert" > warnings.txt

you can actually do that by

/bin/bash
TEMPDIR=$(mktemp -d)
mkfifo "${TEMPDIR}/fifo"
python flowgraph.py --filename "${TEMPDIR}/fifo" &
grep "alert" < "${TEMPDIR}/fifo" > warnings.txt

The magic happens in your flowgraph, where you'd add a "Parameter"
block to add your "--filename" option, and use that option for the
file name in a file sink :) 

Hope that helps,
Marcus

[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Sun, 2018-08-19 at 13:47 -0500, Martin McCormick wrote:
> If there is a better mailing list for the following question, I will
> gladly take
> it there.
> 
>   I want to use as much of the gnu radio project as
> practical but the graphical way to string various modules
> together isn't terribly useful for computer users who happen to
> be blind.
> 
>   Unix and to a lesser degree, DOS handled input and output
> logic elegantly with <, >, | and even tee when one sends output
> to multiple files and unix just turned 50 this Summer so it's
> doing something right.
> 
>   Is there any kind of text-based way to string those python GNU
> modules together to cause them to work as they do when
> connected using GRC?
> 
>   This could very well be a dumb question as I have only
> scratched at python a few years ago and what I am talking
> about may be similar to a Makefile which is what you use to refer
> to a bunch of C modules that might be in a program.
> 
>   Anyway, I sure hope there is something else out there
> that accomplishes the same job.
> 
>   I have played with the Realtek, RTL2838UHIDIR and it does
> surprisingly well on analog signals so it's time to string some
> of those modules together and try some digital decoding.
> 
> Thanks for any and all constructive suggestions.
> 
> Martin McCormick WB5AGZ

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] Grid/Coordinate placement ('GUI hint' QY/WX) control query

[Mark]

This is perhaps a trivial query about the use of QT (or WX) GUI controls
when trying to design widgets (GUI controls) to position themselves on the
runtime workspace in GNU Radio.

 

For example, if I try to place a QT button control at 'GUI hint' coordinates
0,0,1,1, I can never seem to get the button to span just a small width - the
button spans the take up the entire column workspace at runtime.

 

Furthermore when placing other widgets, despite trying to use the 'GUI Hint'
correctly, the placement and width of controls appear to interfere with one
another and get displaced into unexpected areas of the workspace when the
flow graph is executed at runtime.

 

I've tried to follow what little has been published about how the GUI Hint
function is suppose to work, but the widgets still appear to give odd
behaviours.

 

I shouldn't compare this with say developing GUI's in Visual Studio etc; but
it seems to me that despite being me being able to design flowcharts that
result in fully functional radio systems with GNU Radio and my USRP, I find
the frustration of working with 'GUI Hint' problematic when trying to design
a usable user interface from scratch.

 

Maybe there is no hard and fast rule how to use the 'GUI Hint' function but
if anyone can spare time to offer more detailed guidance on the 'GUI Hint
'function and its usage then I should be very grateful for the
clarification.

 

Thank you if you are able to help,

 

Mark

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

Re: [Discuss-gnuradio] Phase Synchronization Across Channels in X310

[Zhan Yanjun]

Hello Marcus,

Thanks for the reply. Yes, I do expect that there will be a constant phase 
offset that I will be able to compensate offline, however, the issue here is 
that everytime I start a new recording, the phase difference across the cards 
(and even between the 2 channels in the card) is always different. I would 
expect it to be the same everytime I record a signal.

Regards,
YJ

From: Discuss-gnuradio  On 
Behalf Of Marcus D. Leech
Sent: Saturday, 18 August 2018 02:32
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Phase Synchronization Across Channels in X310

On 08/17/2018 05:37 AM, Zhan Yanjun wrote:

Hello everyone,



A while ago I came across an issue in running GNURadio with my version of UHD 
and I have followed instructions from the Ettus website 
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux



Now the UHD version is UHD_3.11.0.HEAD-0-ga1b5c4ae, and the Gnuradio is version 
3.7.13.4, and everything runs fine.


Everything was done on a fresh installation of Ubuntu 18.04.1 LTS.



Now, I want to do synchronous recording of all 4 channels on one X310 SDR 
chassis, but when I check the phase of the signal at each channel, they are not 
in phase.



Initially, I thought that it should have something to do with the internal LO, 
so I tried various combinations of the LO configuration:

1. Internal, companion, companion, companion

2. Internal, companion, external, external

3. Internal, companion, external, companion

4. all internal

But, it still does not work. I have connected the LO RF cables in a criss-cross 
fashion inside the chassis as well to pass the LO configuration to the 
neighbouring 2 channels.



Attached here is a snapshot of the GNURadio flowchart I designed for that 
purpose.



I also tried to install the latest UHD version in my computer, but it is unable 
to work with FPGA image (non-release version). Because the X310 are not mine, I 
cannot update FPGA image.



Have you all come across this issue before? Please share your views on this, 
any help is much appreciated! I have tried installing and reinstalling the 
programs a few times, but the conclusion is still the same, and the phases 
across the channels do not match.



Thanks and regards,

YJ


Don't forget that the LO link cables are of non-zero length electrically, so 
there will be some phase offset between the two cards that you'll need
  to compensate for.

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

Re: [Discuss-gnuradio] Phase Synchronization Across Channels in X310

[Marcus D. Leech]

On 08/19/2018 08:11 PM, Zhan Yanjun wrote:


Hello Marcus,

Thanks for the reply. Yes, I do expect that there will be a constant 
phase offset that I will be able to compensate offline, however, the 
issue here is that everytime I start a new recording, the phase 
difference across the cards (and even between the 2 channels in the 
card) is *always* different. I would expect it to be the same 
everytime I record a signal.


Regards,

YJ

So, I would recommend looking at this app-note here, since gr-doa 
requires that all channels be phase-synchronous with zero phase-offset:


https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2

The gr-doa demonstrator code is here:

https://github.com/EttusResearch/gr-doa


*From:*Discuss-gnuradio 
 *On Behalf Of 
*Marcus D. Leech

*Sent:* Saturday, 18 August 2018 02:32
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Phase Synchronization Across 
Channels in X310


On 08/17/2018 05:37 AM, Zhan Yanjun wrote:

Hello everyone,

A while ago I came across an issue in running GNURadio with my
version of UHD and I have followed instructions from the Ettus
website

https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux



Now the UHD version is UHD_3.11.0.HEAD-0-ga1b5c4ae, and the
Gnuradio is version 3.7.13.4, and everything runs fine.

Everything was done on a fresh installation of Ubuntu 18.04.1 LTS.

Now, I want to do synchronous recording of all 4 channels on one
X310 SDR chassis, but when I check the phase of the signal at each
channel, they are not in phase.

Initially, I thought that it should have something to do with the
internal LO, so I tried various combinations of the LO configuration:

1.Internal, companion, companion, companion

2.Internal, companion, external, external

3.Internal, companion, external, companion

4.all internal

But, it still does not work. I have connected the LO RF cables in
a criss-cross fashion inside the chassis as well to pass the LO
configuration to the neighbouring 2 channels.

Attached here is a snapshot of the GNURadio flowchart I designed
for that purpose.

I also tried to install the latest UHD version in my computer, but
it is unable to work with FPGA image (non-release version).
Because the X310 are not mine, I cannot update FPGA image.

Have you all come across this issue before? Please share your
views on this, any help is much appreciated! I have tried
installing and reinstalling the programs a few times, but the
conclusion is still the same, and the phases across the channels
do not match.

Thanks and regards,

YJ

Don't forget that the LO link cables are of non-zero length 
electrically, so there will be some phase offset between the two cards 
that you'll need

  to compensate for.



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